Mobile SSL VPN + NPS w/ Azure Extension + Azure MFA

Hi Guys,

Just wondering if anyone has gotten this combination to work as of yet - My users currently use Mobile SSL VPN against NPS servers. We also have modern authentication enabled along with MFA on our Azure tenant.

I'd love to have MFA functionality when a user connects using the SSL client. From what I understand, all I really need to do is install the Azure extension on the NPS server, and everything else seems to be configured, but I just can't seem to get a successful connection. During authentication, the second factor is triggered on the users' devices, but after completing the sign in, the connection fails.

Any input would be greatly appreciated!

Fl.

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Flocons

    I'd suggest opening a support case. So long as the Firebox gets a RADIUS access-accept with the correct group (via FilterID or RADIUS attribute 11) than it should work.

    If you'd prefer to do it yourself, running wireshark with the filter "udp.port==1812" on the RADIUS server (or replace that port with the alternate port you're using" should allow you to see the access-accept. Is Attribute 11 defined? If not, you'll need to configure this on the server.

    My guess would be that the group is not coming across, which would make everything seem like it was working, but the user would not be able to access anything. In the firewall logs, you'd likely see red deny logs that say "unhandled MUVPN packet."

    -James Carson
    WatchGuard Customer Support

  • We have this working fine for the IKEv2 vpn but I cannot for the life of me get it working on the ssl-vpn - I default the Radius (NPS) server as the authentication server but it just doesn't work? Has anybody got the ssl-vpn working with Radius and Microsoft authenticator?

  • I have the SSLVPN working with RADIUS and AuthPoint, and I suspect that the Microsoft Authenticator should work. They key is that the SSLVPN needs to have the FilterID set as mentioned above.

    Gregg Hill

  • edited November 2021

    We have this working on a number of clients. Push can work with the higher level of encryption (MS-ChapV2), SMS and OTP need to be dropped down to PAP.

    Azure NPS Extensions will take over your NPS, so you need an NPS server dedicated for Azure MFA. e.g if you have Wireless 802.1x you will find that the NPS extensions will interfere and prevent your wireless clients from connecting due to "an error with a dll" - meaning the Azure NPS extensions.

    RADIUS Client: Add your firewalls IP address
    RADIUS Secret: Common password between both.

    Connection Request Policy:

    • Conditions: Client IPv4 address of the Firewall
    • Settings: Radius Attribute -> Filter-ID = The Name of your SSL VPN Users group e.g VPN-Access, VPN-Contractors etc.

    Network Policies:

    • Conditions:

      • Client IPv4 address of the Firewall
      • User Groups: The Domain Based Security Groups - The name should match the names from your Watchguard.
    • Settings:

      • Access Permission: Grant Access
      • Authentication Method: Unencrypted (PAP,SPAP)

    Finally remember to review the setting under Change Log File Properties - "If logging fails, discard connection requests". By default this is enabled, and out of the box doesnt work properly. This can also cause logon issues that may not be obvious.

  • @Greggmh123 said:
    I have the SSLVPN working with RADIUS and AuthPoint, and I suspect that the Microsoft Authenticator should work. They key is that the SSLVPN needs to have the FilterID set as mentioned above.

    I have it working with the SSLVPN but with Push Notifications and Phone Call only.

    The Filter-Id the main issue with the Azure MFA Extensions currently when using TOTP codes:

    "Also, regardless of the authentication protocol that's used (PAP, CHAP, or EAP), if your MFA method is text-based (SMS, mobile app verification code, or OATH hardware token) and requires the user to enter a code or text in the VPN client UI input field, the authentication might succeed. But any RADIUS attributes that are configured in the Network Access Policy are not forwarded to the RADIUS cient (the Network Access Device, like the VPN gateway). As a result, the VPN client might have more access than you want it to have, or less access or no access."

    https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension

    It doesn't make sense to me why they can make it work for Push and Phone Call but not TOTP codes. Maybe Microsoft can pull some devs off of the "moving functionality to new menus team" and get someone to fix this major issue.

  • we have this working with the push notification to approve on the MS App, couldn't get it working any other way so we've paused the roll out over issues with staff forced to use personal mobile and the ms app.

  • Yeah the SSL vpn usually only supports Push notifications. The Caveat is if you use AuthPoint you may be able to get OTP working if your firewall is 12.7.1 firmware and uses direct integration…

    There has been some bugs with the Microsoft radius stuff and how it interacts with OpenVPN based ssl clients. sonicwall and fortinet users have had the same problem from my experience over the last few months.
  • @DaveDave said:
    We have this working on a number of clients. Push can work with the higher level of encryption (MS-ChapV2), SMS and OTP need to be dropped down to PAP.

    Hi,

    After KB5009543 I'm trying to get SSL VPN to work with MS MFA.
    I can't get push to work without using unencrypted PAP, we don't need sms or OTP. If I understand you correctly you got this to work with Push and MS-ChapV2?

  • sslvpn client doesn't support ms-chapv2, only PAP
    ikev2 and L2TP vpn clients support ms-chapv2

  • @DaveDave said:
    We have this working on a number of clients. Push can work with the higher level of encryption (MS-ChapV2), SMS and OTP need to be dropped down to PAP.

    (...)

    • Settings:
      • Access Permission: Grant Access
      • Authentication Method: Unencrypted (PAP,SPAP)

    Hi Dave
    We are trying to implement VPNSSL with MS-Authenticator, so thank you so much for your post ;)
    To be sure: You first wrote "Push can work with the higher level of encryption (MS-ChapV2)" but then, in your Network Policy settings, "Settings: Authentication Method: Unencrypted (PAP,SPAP)"
    But, if Settings is set to PAP,SPAP...then it is not MS-Chapv2, right? Thanks

  • @stuart_seed said:
    We have this working fine for the IKEv2 vpn but I cannot for the life of me get it working on the ssl-vpn - I default the Radius (NPS) server as the authentication server but it just doesn't work? Has anybody got the ssl-vpn working with Radius and Microsoft authenticator?

    Hi Stuart,
    I know this thread is outdated. But there is exactly what I want to do (Have Azure MFA with IkeV2 and no Authpoint)
    Could you please help me and tell me how to do this ?
    I just made a support ticket but they start to tell me they are not ability to support Azure. So I think it wiil be hard to have some help.
    It's sad to see that concurents do that without problems.
    Thank you very much.

  • edited March 2022

    @Becha69 - Sorry is been a while.

    The OTP code needs to be sent in plaintext i.e not encrypted. If you set MS-Chap V2, Push can work (and I think the Phone Call as well), but any code methods (SMS, App Code) won't work, as the backend is unable to decode and verify the encrypted OTP hence the unencrypted PAP mode.

    @Darnaud

    In your case i'm assuming that you are using the Windows native client for VPN Access? For this to work your method can only support Push notification as there is no way to put the code into the Windows client. When you connect, your VPN will pause and will look like is hung, your Authenticator app should buzz and then you can approve access.

    This method can also be setup to work with Remote Desktop Gateway.

  • @DaveDave said:
    @Becha69 - Sorry is been a while.

    The OTP code needs to be sent in plaintext i.e not encrypted. If you set MS-Chap V2, Push can work (and I think the Phone Call as well), but any code methods (SMS, App Code) won't work, as the backend is unable to decode and verify the encrypted OTP hence the unencrypted PAP mode.

    @Darnaud

    In your case i'm assuming that you are using the Windows native client for VPN Access? For this to work your method can only support Push notification as there is no way to put the code into the Windows client. When you connect, your VPN will pause and will look like is hung, your Authenticator app should buzz and then you can approve access.

    This method can also be setup to work with Remote Desktop Gateway.

    Hi DaveDave,
    Thank you for your answer.
    Do you know how I can do that please ?
    Is this requires AD DS with Azure AD Connect ? All my customers are full cloud.
    Thank you !!!

  • @Darnaud said:

    Is this requires AD DS with Azure AD Connect ? All my customers are full cloud.

    I don't have the full implementation steps (it's somewhere on the Microsoft website), but you need to setup a Windows NPS server as your RADIUS server, then add the Azure MFA extension to it (involves some Powershell from memory to link it to your tenancy).

    Assuming you have Azure MFA already setup, all requests to that Windows NPS (RADIUS) server then get sent to Azure which then triggers the MFA request by way of notification on the user's mobile device.

    I've been testing this with the IKEv2 endpoint but believe it should also work for the SSL VPN endpoint too.

  • I got this working on my end without much effort. A few notes:

    1 - Don't deploy on an existing NPS implementation as the Azure EPS extension will 'break' the local NPS.

    2 - Configure as you normally would based on the Watchguard documentation. https://techsearch.watchguard.com/KB/WGKnowledgeBase?lang=en_US&SFDCID=kA22A000000XZlhSAG&type=KBArticle

    3 - Make sure AD is syncing to Azure.

    4 - Make sure users have licensing for MFA.

    Basically, radius does the same checks to validate as usual, but then sends the request to Azure for the MFA portion. There isn't anything to configure for that action.

  • i'm assuming that you are using the Windows native client for VPN Access . .

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @nityavid
    SSLVPN will be either via the WatchGuard SSLVPN client, or the OpenVPN client.

    For the other VPN types (L2TP, IKEv2) you can use the Windows client.

    For IPSec (IKEv1) you'll need the WatchGuard IPSec client that you can find under your firewall's downloads at software.watchguard.com

    -James Carson
    WatchGuard Customer Support

  • edited October 2023

    I've been trying to get my IKEv2 VPN working with Azure/Entra MFA for over a week now. I've gotten close, but can not get it to send a request to just do a Push auth. If the user in Entra has Phone set as the default, a phone call will process and accepting it will get a successful connection, but can not get it to go through the MS Authenticator app. Any tips on getting that to work. In Wireshark, I'm seeing the Access-Request FB --> NPS/RADIUS, then an Access-Challenge NPS/RADIUS --> FB. I know the Firebox can not process the Challenge response since it's using MS-CHAPv2. I've set the Override OTP to True in the Registry of the NPS server and of course have the Azure NPS Ext installed there. Looking like we'll just go through an Azure VPN at this point. No guide available from WatchGuard past getting IKEv2 setup, unless you're using AuthPoint.

  • @DB_IT said:
    I've been trying to get my IKEv2 VPN working with Azure/Entra MFA for over a week now. I've gotten close, but can not get it to send a request to just do a Push auth. If the user in Entra has Phone set as the default, a phone call will process and accepting it will get a successful connection, but can not get it to go through the MS Authenticator app.

    Because of the way it works, it will only send a request via the default method the user has configured - and if the user has "Phone" set as the default it will do that.
    (Mind you in our tenancies Phone and SMS are deemed insecure so they're disabled - but since it has to be a method that is an "accept" acknowledgement, SMS wouldn't work anyway).

    ie. the user has to have Authenticator set as their default method for the Authenticator app to notify in this scenario.

    I know this as when we first rolled out MFA in our environment my default was using a code generator app, which definitely doesn't work [which you've pointed out], so had to switch to using Authenticator as the default.

Sign In to comment.