Always On VPN and Windows Server 2019 NPS Bug

Note: This post updated March 19,2019 to reflect new workaround configuration guidance.

When deploying a Windows Server 2019 Network Policy Server (NPS) to support a Windows 10 Always On VPN implementation, administrators may encounter the following error when attempting to establish a VPN connection on a remote Windows 10 client.

Can’t connect to [connection name].

The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

Always On VPN and Windows Server 2019 Network Policy Server Bug
In addition, an event ID 20227 from the RasClient will be recorded in the application event log with the following error message.

The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 812.

Always On VPN and Windows Server 2019 Network Policy Server Bug

Common Causes

Always On VPN error code 812 indicates an authentication policy mismatch between the client and the server. This often occurs when, for example, the server is configured to use Protected Extensible Authentication Protocol (PEAP), but the client is configured to use Microsoft CHAP Version 2 (MS-CHAP v2).

Troubleshooting

Carefully review the authentication policy on both the client and server to ensure they match. Next, enable firewall logging on the NPS server to log both allowed and dropped packets. Attempt another VPN connection and observe the firewall logs. In this example the firewall is dropping packets inbound on UDP port 1812.

Always On VPN and Windows Server 2019 Network Policy Server Bug

Interestingly, the default Windows firewall rule allowing inbound UDP port 1812 is enabled and set to allow for all profiles.

Always On VPN and Windows Server 2019 Network Policy Server Bug

Windows Server 2019 Bug

It appears that Microsoft’s recently released Windows Server 2019 has a bug that prevents NPS from working correctly out of the box. Specifically, it looks like the default Windows firewall rules to allow inbound UDP port 1812 (RADIUS authentication) and inbound UDP port 1813 (RADIUS accounting) do not work.

Resolution

To resolve this issue, open an elevated command window and enter the following command.

sc.exe sidtype IAS unrestricted

Once complete, restart the server and the default Windows Firewall rules for NPS traffic will work correctly.

Additional Information

Windows 10 Always On VPN NPS Load Balancing Strategies

Leave a comment

28 Comments

  1. Steve

     /  September 26, 2019

    I found the same error when configuring a Remote Desktop Services environment, and found your article when checking for any issues between Always On VPN and Server 2019, which I’m about to deploy. My workaround was to create custom firewall rules that mirrored the in-built rules – I like your solution better.

    Reply
    • When I first discovered this bug I created custom firewall rules as a workaround. However, a support engineer from Microsoft turned me on to this fix which is much simpler. 🙂 BTW, I believe this issue was resolved at some point by Microsoft. The last time I built a clean NPS server and applied the latest updates I didn’t have to make this change.

      Reply
      • Joe Pochedley

         /  October 2, 2020

        haha… I wish it was fixed at some point. It’s now Oct 2020 and I just spent an hour troubleshooting a new Server 2019 NPS install to support 802.1x RADIUS authentication for WiFi … Using a fully patched Server 2019 (1809) …. Still a problem. *sigh*

      • It would appear that Microsoft has no immediate interest in fixing this bug, huh? :/

  2. Maik

     /  January 30, 2020

    Hi,
    i have a general question for NPS (maybe RRAS static ip addresses).
    Is it possible to configure, that the Always On VPN User gets first the ADUC Dial-In static ip address? Than, as fallback, from the RRAS static address pool.

    Thanks
    Best Regards
    Maik

    Reply
    • I have no idea. 😉 That’s not something I’ve ever tested or configured. You’ll have to do some testing and see if that works. If you do, let me know how it goes!

      Reply
  3. Rob Nunley

     /  May 6, 2020

    My NPS and VPN servers are fully patched windows 2019. The device tunnel connects just fine but the user tunnel keeps failing with event code 20227 and error code 812. However, before ID 20227 in event viewer I have events 20223 and 20224 both saying a link has been established. For testing, windows FW is turned off on both servers. What additional troubleshooting can I perform to find the cause of the issue? Thanks!

    Reply
    • I’d suggest looking at the event logs on the NPS server. It should provide more detail as to why the connection was rejected. Look for event IDs 6272 and 6273.

      Reply
  4. Robyn Bredvick

     /  May 11, 2020

    Thank you for this post! Finally was able to get connected after running this command.

    Reply
  5. Javier

     /  May 12, 2020

    Hi Richard,

    First of all: Thanks a lot for posting all this AOVPN information!!! It is very helpful.

    I am having this issue in 2 sites with 4 RRAS and 4 NPS servers. The interesting part is that in both locations, NPS servers 1 and 2 work but 3 and 4 don’t.

    Servers 1 and 2 were deployed by a different colleague that left the office so I cannot ask him.

    I have reviewed certificate, Windows fw (OFF), network ports between RRAS and NPS servers and, of course, all settings and I cannot find a clue on how to make this work (I have also applied the resolution to the bug)

    Do you have any idea on where I should continue troubleshooting?

    Thanks a lot in advance.

    Best regards

    Javier

    Reply
    • Have a look at the event log on the NPS server. It should give you an idea if it is receiving authentication requests, and if so, why it is accepting or rejecting them. If you don’t see any requests at all, either allowed or denied, then it is likely a networking issue and the authentication requests are never reaching the server. If it is an issue with the radius client configuration or missing/misconfigured shared secret, the event log will indicate that.

      Reply
      • Javier

         /  May 18, 2020

        Dear Richard,

        Thanks a lot for your suggestion but I finally found the root cause: it was on the client side configuration.

        As I was testing on a single computer, I had forgotten to add the new NPS servers (3 and 4) on the client side settings (as I am testing, I configured the connection manually in the past and forgot on this part).

        One good thing about this is that I will remember this issue in the future.

        For sure I will be recommending your site to all my colleagues!

        Best regards

        Javier

      • Failure is often the best teacher. 😉

  6. Robbie Wallis

     /  July 25, 2020

    Having an issue whereby if I specify a group in the NPS network policy policy the connection fails. If I remove the group the user connects fine. Any ideas the user belongs to all the groups I have tried. Using EAP and user certificates. NPS is on Server 2019

    Robbie

    Reply
    • Did you specify just one group in the NPS policy? I ask because if you have specified more than one group there are two ways to do that, one is an OR and the other AND. Also, when the connection fails what does the event log on the NPS server say? It should give you a reason for denying the request.

      Reply
    • Robbie Wallis

       /  July 25, 2020

      I “fixed” this. Problem was two fold security on the object and not being in a group I thought I was 😀

      Reply
  7. Simon Rae

     /  September 14, 2020

    Hi Richard,

    Thanks for providing such excellent documentation on this topic. I’m getting this error but only after following the MS steps on enabling conditional access. I suspect this is because my Azure AD UPN is different from my on-premise UPN so NPS is not matching the subject name in the Azure VPN client cert to an on-premise AD account. My NPS server logs are showing a reason code error “IAS_NO_SUCH_DOMAIN”.

    Any thoughts?

    Thanks!

    Reply
  8. I was about to punch someone in the face today because for three hours I was troubleshooting this issue and my frustrations and anger levels were reaching the point of no return. Found this post and tried it; rebooted the server and voila! Connected! Thank you very much (again!) for your helpful posts. Have a great weekend!

    Reply
  9. Hello Richard!

    Thank you for this life saving blog. Helped me many times!

    We’re getting this error for about 10 of our 700 users. Error follows this specific users (tested with non working user on client devices that’s working for other users, same error).

    One RAS and one NPS with same build (Windows Server 2019 version 1809 (OS Build 17763.1577)).

    Ran “sc.exe sidtype IAS unrestricted” and rebooted NPS but no difference.

    Checked firewall logging, no dropped packets logged on NPS from RAS or vice versa.

    In event viewer on RAS we see error: “CoId={6D16447D-BFD0-5C9A-386E-285358121149}: The following error occurred in the Point to Point Protocol module on port: VPN2-708, UserName: . Negotiation timed out”.

    In event viewer on NPS we can’t see any errors etc related to NPS.

    Also did a trace with Wireshark on both servers. We can see alot of RADIUS Access-Request from RAS. NPS answers with a RADIUS Access-Challenge around 9 times out of 10. But the 10th time it looks like NPS instead answers with a RADIUS Access-Accept. How’s the packet traffic between RAS and NPS supposed to look? A few request/challenge back and forth before ending with an accept from NPS?

    We’re stuck! Any ideas/tips on something worth looking over is greatly appreciated!

    Reply
    • Very strange. If it works for some or any of your users it should work for all. Cleary it doesn’t appear to be a configuration issue at least. With that, there are a number of messages sent between the client and NPS server before the request is accepted. This is normal, and ultimately what you’re looking for at the end is the Access-Accept message. Also, the event log is your friend here and should have information about why any authentication request was rejected. If you don’t see that, make sure auditing is enabled on the NPS server using the following command.

      auditpol.exe /set /subcategory:”Network Policy Server” /success:enable /failure:enable

      Reply
  10. Maik

     /  November 24, 2020

    To GW
    Do you use EKUs to identify the user certificate?
    Till last week, we had the same problem, 390 users work and 10 not. All same config.
    Then i figured out, that when i disable the custom EKU “BusinessName VPN” (Client VPN Configuration) it works for all users, now.

    Best Regards
    Maik

    Reply
  11. Dennis

     /  January 8, 2021

    Hello Richard,

    every time I log in with a SSTP Connection with authenticate through the NPS Server (Username or Certificate) I get an eventlog error with:

    The user xxxx@xxxx.local connected from x.x.x.x but failed an authentication attempt due to the following reason: The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

    But the User can connect without any Problems. On the NPS Server I can see no error in the event log.

    Do you have any idea on where I should continue troubleshooting?
    Thanks.

    best regards,
    Dennis

    Reply
    • I’d suggest enabling auditing on the NPS server and having another look. 🙂

      auditpol.exe /set /subcategory:”Network Policy Server” /success:enable /failure:enable

      Happy hunting!

      Reply
  1. Always On VPN Error Code 858 | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Continue Connecting Prompt | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

<span>%d</span> bloggers like this: