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).


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.


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


  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.

    • 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.

  2. Maik

     /  January 30, 2020

    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.

    Best Regards

    • 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!

  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!

    • 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.

  4. Robyn Bredvick

     /  May 11, 2020

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

  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


    • 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.

      • 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


      • Failure is often the best teacher. 😉

  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: Logo

You are commenting using your 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: