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

21 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
  1. Always On VPN Error Code 858 | 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.

%d bloggers like this: