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.
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.
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.
Interestingly, the default Windows firewall rule allowing inbound UDP port 1812 is enabled and set to allow for all profiles.
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.
Steve
/ September 26, 2019I 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.
Richard M. Hicks
/ October 7, 2019When 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.
Joe Pochedley
/ October 2, 2020haha… 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*
Richard M. Hicks
/ October 2, 2020It would appear that Microsoft has no immediate interest in fixing this bug, huh? :/
Maik
/ January 30, 2020Hi,
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
Richard M. Hicks
/ January 30, 2020I 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!
Rob Nunley
/ May 6, 2020My 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!
Richard M. Hicks
/ May 14, 2020I’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.
Robyn Bredvick
/ May 11, 2020Thank you for this post! Finally was able to get connected after running this command.
Richard M. Hicks
/ May 14, 2020Great to hear! 🙂
Javier
/ May 12, 2020Hi 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
Richard M. Hicks
/ May 14, 2020Have 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, 2020Dear 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
Richard M. Hicks
/ May 18, 2020Failure is often the best teacher. 😉
Robbie Wallis
/ July 25, 2020Having 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
Richard M. Hicks
/ July 25, 2020Did 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.
Robbie Wallis
/ July 25, 2020I “fixed” this. Problem was two fold security on the object and not being in a group I thought I was 😀
Richard M. Hicks
/ July 25, 2020Glad you got it sorted out! 🙂
Simon Rae
/ September 14, 2020Hi 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!
Richard M. Hicks
/ September 15, 2020There are a number of crucial steps that have to be performed to make Azure conditional access work with Always On VPN. Have a look at the following published guidance from Microsoft. It’s like you’ve overlooked something here.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/ad-ca-vpn-connectivity-windows10
Owen
/ November 13, 2020I 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!
GW
/ November 23, 2020Hello 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!
Richard M. Hicks
/ November 24, 2020Very 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
Maik
/ November 24, 2020To 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
Dennis
/ January 8, 2021Hello 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 [email protected] 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
Richard M. Hicks
/ January 9, 2021I’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!
nikk
/ October 16, 2022Hello Richard,
I hope it is permissible to ask a general question here:
Some instructions say that the client authenticates itself to the VPN gateway with its user certificate when setting up the user tunnel.
Other instructions say that only the RADIUS server alone is responsible for authentication when using the user tunnel. What is right?
Best regards,
nikk
Richard M. Hicks
/ October 21, 2022RADIUS is used in either case. So, it really depends on how you have the VPN server configured. If you select Windows authentication it will use its local RADIUS instance. It requires no additional RADIUS configuration. If you use a remote RADIUS server, then you must select the RADIUS authentication option and define those servers accordingly.
Chris Lacroix
/ April 9, 2024Is the bug still present in Server 2022 we will gladly upgrade if it fixed? We are using NPS on server 2019 and once / week randomly we have the problem and need to reboot out NPS, we tried to implement a more permanent fix (Get-NetFirewallRule -DisplayGroup “Network Policy Server” | where DisplayName -like “*RADIUS*” | Set-NetFirewallRule -Service Any) however it doesn’t work
Richard M. Hicks
/ April 9, 2024No, it is not. This bug affects only Windows Server 2019 servers. 🙂