When configuring Windows 10 Always On VPN using the Routing and Remote Access Service (RRAS) on Windows Server 2012 R2 and Extensible Authentication Protocol (EAP) authentication using client certificates, clients attempting to establish a VPN connection using Internet Key Exchange version 2 (IKEv2) may receive the following error.
“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.”
The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 812”.
Always On VPN clients using the Secure Socket Tunneling Protocol (SSTP) may receive the following error.
“The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.”
The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 691”.
Resolution
These errors can occur when Transport Layer Security (TLS) 1.0 has been disabled on the RRAS server. To restore functionality, enable TLS 1.0 protocol support on the RRAS server. If disabling TLS 1.0 is required for compliance reasons, consider deploying RRAS on Windows Server 2016. TLS 1.0 can be safely disabled on Windows Server 2016 without breaking EAP client certificate authentication for Windows 10 Always On VPN clients.
Additional Information
Windows 10 Always On VPN Hands-On Training
What’s the Difference Between DirectAccess and Windows 10 Always On VPN?
5 Important Things DirectAccess Administrators Should Know About Windows 10 Always On VPN
3 Important Advantages of Windows 10 Always On VPN over DirectAccess
Richard van de Ven
/ February 28, 2018Good afternoon,
We are implementing Always on VPN, When computer boots it is setting up a VPN tunnel as we can se in the RRAS server, so far everything goes oké. But as soon as we login to the system the tunnel drops and in the event log we see error:1000 with message “svchost.exe RASMAN” crashed.
Do you have explenation for this? We running WIN2016 server and WIN10 1709build on a Surface book 2
Kind regards
Richard van de Ven
Richard M. Hicks
/ February 28, 2018This is a known issue. Microsoft is working on a fix as we speak. Keep watching the web site as I’ll make an announcement as soon as the fix is released. 🙂
andychips
/ June 4, 2018I had this problem (Error 812) and found that some of the following settings weren’t correct:
Make sure the user is a member of the AD group which should have delegated permissions to the Certificate Auto-Enrollment GPO, and permissions to the appropriate Network Policy on the NPS server.
Hope that helps someone else.
Peter
/ July 16, 2018Our Always On VPN just suddenly stopped working (17/07/18) without any configuration changes with the exact same error messages.
We had the VPN connection setup to verify the server’s identity by validating the certificate “when connecting” and for the “select authentication method”. This worked fine since last year.
I got it working again by adding the connect to these servers and specify the FQDN under “When connecting” but un-ticked the “Verify the server’s identity by valuating the certificate” under the configuration of the selected authentication method.
Has anybody ran into the same problem? I just wonder if MS introduced any behavioral changes that could cause this?
The only other thing I spotted is that the root certificate of the CA is expiring in less than 4 weeks however all certs are still valid.
Cedric
/ March 19, 2019Hello,
Thanks for all your very helpful articles.
We have a RRAS server for the VPN connections and another serveur PKI / NPS, both windows 2019 standard, and it seems that this second server windows firewall blocks the connection.
When the firewall is on, the client has a 812 error, but it manages to connect when the firewall is deactivated. I checked the ports 1645, 1646, 1812, 1813 are configured by default for NPS server and allowed on the firewall.
Is there something else to open on the NPS server?
Thanks for your help!
Richard M. Hicks
/ March 19, 2019This is a known issue with NPS on Windows Server 2019. I wrote about it here: https://directaccess.richardhicks.com/2018/11/27/always-on-vpn-and-windows-server-2019-nps-bug/. However, I need to update this post because there’s an even easier way to fix it. Simply run the following commands in an elevated command window and restart the server.
sc sidtype IAS unrestricted
Hope that helps!
Ian
/ April 11, 2019Our RRAS server is installed on Server 2016 as is the NPS server (separate boxes) Our VPN clients are connecting via IKEv2 tunnel deployed via SCCM. Most of the time the clients connect without an issue, however, sometimes clients get the message “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.” an immediate retry connects so there is no policy mismatch for these users on the NPS server.
TLS 1.0 has not been disabled on the RRAS server. All investigations seem to lead to a dead end? Has anyone experienced this?
Richard M. Hicks
/ April 11, 2019The only time I’ve ever seen that happen is if the NPS server and VPN client aren’t configured to use the same authentication scheme. If you have more than one NPS server I’d make sure the configuration is the same on both servers.
Daniel
/ April 30, 2019I have exactly the same problem. Did you solve it?
In our configuration is only one NPS server.
Richard M. Hicks
/ April 30, 2019The resolution is to enable support for TLS 1.0 if you are running Windows Server 2012 R2. It is recommended that Windows Server 2019 be used for RRAS when implementing Always On VPN however.
Matthew
/ June 26, 2019Hi Richard. Similar to Ian and Daniel I also have this issue. 4xRRAS on Windows server 2016 talking to 4xNPS on Windows Server 2016 (2xLocal and 2xAzureMFA). Clients are all windows 10 1809 and are patched up to date.
Clients get error 812 randomly. No discernible pattern for users affected, RRAS server or NPS server they are connecting to and usually if they hit close on the error and reconnect they get straight on.
Any ideas?
Richard M. Hicks
/ June 26, 2019812 errors (RAS/VPN policy errors) can of course be caused by misconfiguration on the VPN/NPS server and/or client. However, if a client works at least once, that would indicate that authentication policies are configured correctly and it should work every time. When 812 errors occur randomly it indicates a possible communication issue with the NPS server. It might seem unintuitive, but if the VPN server can’t reach an NPS server it will return the same error (812). I’d have a close look at that.
Moudy
/ October 19, 2019Hi Richard, I have server 2016 running the RRAS and Server 2019 running the NPS. It’s fresh setup for the AlwaysOn VPN and couldn’t get the client to connect to the server, I keep getting the 812 error “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.” I have triple checked the polices, the authentication method on the NPS and the VPN profile on the client they defintely using the EAP (PEAP) and the user certifcate installed on the client via autoenrollment.
I checked the logs on the RRAS server and I could see this…
“CoId={30B5CBD6-D1FF-4B77-EEA0-5D80EE4E4A9A}: The following error occurred in the Point to Point Protocol module on port: VPN2-127, UserName: . 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.”
On the NPS server loads of this error…
A RADIUS message was received from the invalid RADIUS client IP address 192.168.1.100 (not sure it’s related).
I have tried to adjust the VPN profile on the client and used the machine certificate and I was able to connect within seconds
I will be grateful if you can help me out with this one. Thanks
Richard M. Hicks
/ October 21, 2019An error 812 can sometimes be deceiving. Although the message seems to indicate there was an authentication policy mismatch, it could also mean that the VPN server was unable to contact the NPS server too. Since you are running NPS on Windows Server 2019, it might be a known issue related to a bug with the Windows firewall. Details here:
https://directaccess.richardhicks.com/2018/11/27/always-on-vpn-and-windows-server-2019-nps-bug/
I believe this bug has been addressed, so if your Windows Server 2019 NPS server is fully updated you shouldn’t need this workaround. That said, the error message stating you received a RADIUS message from an invalid client IP address would seem to indicate perhaps an NPS configuration issue. Make sure the VPN server is configured as a RADIUS client on your NPS server using the correct IP address.
Mahmoud Abdelrahman
/ October 22, 2019Thanks Richard for your reply, my 2019 server is fully updated however I ran this work around but unfortunately didn’t work, I even tried installing new NPS on another 2016 server but still the same exact issue, I ended up using EAP-MSCHAP v2 and updated the NPS policies accordingly and it worked prefctly fine, it’s the only the EAP that refuses to connect which I don’t know why.
Richard M. Hicks
/ October 22, 2019Ok, have to assume there’s some mismatch between the client’s EAP configuration and your NPS server’s configuration. You’ll have to look closely at those policies to determine where the mismatch might be.
Julien
/ February 13, 2020Hi,
I had the error ID 20227 & 812 on my RAS server.
The problem was with our private PKI (two tier with a offline Root CA). The Root CA ‘s revocation list has expired.
So we had just :
– switch on the Root CA
– renew the revocation list with command line : certutil -crl
– copy the new revocation list in the certificat repository
– verify the PKI health with pkiview.msc
Richard M. Hicks
/ February 14, 2020Thanks for sharing! Good point that PKI needs to be healthy and functioning for Always On VPN to work correctly. CRLs are often overlooked! When they expire they can certainly break things, as you no doubt learned. 🙂
Mr Bunne
/ February 25, 2020I just wanted to leave this comment here as I found another solution for this problem. I have been troubleshooting this for some weeks now (!). And no suggested solution have worked. But the exakt same error codes apply.
Problem is, as I understand it, too large MTU packages coming from the client to RRAS server and finally to NPS server when negotiating EAP parameters.
Fix (this is a copy from https://www.sonicwall.com/support/knowledge-base/authentication-failed-due-to-an-eap-session-timeout-the-eap-session-with-the-access-client-was-incomplete/170627144617977/):
On the NPS Server
Click Start, click Administrative Tools, and then click Network Policy Server.
Double-click Policies, click Network Policies, and then in the details pane double-click the policy that you want to configure.
In the policy Properties dialog box, click the Settings tab.
In Settings, in RADIUS Attributes, click Standard.
In the details pane, click Add. The Add Standard RADIUS Attribute dialog box opens.
In Attributes, scroll down to and click Framed-MTU, and then click Add. The Attribute Information dialog box opens.
In Attribute Value, type a value equal to or less than 1344. Click OK, click Close, and then click OK.
Thanks for this forum and all that help to contribute here. Life saver.
Hope this helps someone.
Richard M. Hicks
/ February 26, 2020There are many scenarios in which you can encounter these errors. This article covers just some of those. It is certainly possible that an internal network device is blocking IP fragments, preventing authentication from working correctly. Setting the Framed-MTU value in NPS might certainly help in this scenario.
Microsoft documentation for this can be found here: https://support.microsoft.com/en-us/help/883389/how-to-reduce-the-eap-packet-size-by-using-the-framed-mtu-attribute-in.
Vasile Jichin
/ March 11, 2020Hello Always ON VPN fans, just a heads-up, the error 812 could also occur in the following two scenarios :
1) if you have a duplicate RootCA of your enterprise CA in both Trusted Root CA and IntermediateCA on the client – just remove the certificate in the IntermediateCA and it goes fine
2) if you have no DNS resolution from the VPN/RAS server to the NPS(internal) server. Configure your network adapter properties and register the correct internal DNS IP address(on the VPN/RAS), reboot the server and connection should be fine.
Cheers!
Richard M. Hicks
/ March 11, 2020Thanks for the tips Vasile!
Vasile Jichin
/ March 17, 2020My pleasure
victor bassey
/ August 19, 2020Hello Richard, as part of a client security requirement, they need to disable TLS 1.0 and 1.1, and also SSL v3.0. The client environment is Windows 10 (1909), VPN and NPS are Server 2019 (1809). Are you aware of any issue disabling this protocols could cause?
Regards
Victor Bassey
Richard M. Hicks
/ August 19, 2020Shouldn’t be a problem at all. There’s a known issue if you are using Windows Server 2016, but if you’re using Windows Server 2019 you’re ok. 🙂
victor bassey
/ August 20, 2020Thanks for the response Richard. Really appreciate.
On Wed, 19 Aug 2020, 15:44 Richard M. Hicks Consulting, Inc., wrote:
> Richard M. Hicks commented: “Shouldn’t be a problem at all. There’s a > known issue if you are using Windows Server 2016, but if you’re using > Windows Server 2019 you’re ok. :)” >
Iiro Auvinen
/ February 15, 2021Hi, We have this problem with load balanced aovpn setup(2x rras and 2 x nps). the first connect of the morning produces this error and after that everything works smooth. No errors on the server side. Only info event on nps that server has connected to DC sever with ldap.
Seems to also happen if no new connections in a period of time and nps closes ldap connection to the dc and has to reopen the ldap connection.
All servers are 2019.
Any idea why this is happening?
I tried the ias unrestricted but without luck
Richard M. Hicks
/ February 24, 2021You could try increasing the default timeout value for RADIUS authentication to see if that helps.