Troubleshooting Always On VPN Errors 691 and 812

Troubleshooting Always On VPN Errors 691 and 812When 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.”

Troubleshooting Always On VPN Errors 691 and 812

The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 812”.

Troubleshooting Always On VPN Errors 691 and 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.”

Troubleshooting Always On VPN Errors 691 and 812

The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 691”.

Troubleshooting Always On VPN Errors 691 and 812

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 

Windows 10 Always On VPN and the Future of DirectAccess

Leave a comment

16 Comments

  1. Richard van de Ven

     /  February 28, 2018

    Good 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

    Reply
    • This 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. 🙂

      Reply
  2. I 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.

    Reply
  3. Peter

     /  July 16, 2018

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

    Reply
  4. Cedric

     /  March 19, 2019

    Hello,
    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!

    Reply
  5. Ian

     /  April 11, 2019

    Our 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?

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

      Reply
    • Daniel

       /  April 30, 2019

      I have exactly the same problem. Did you solve it?
      In our configuration is only one NPS server.

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

  6. Hi 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?

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

      Reply
      • Moudy

         /  October 19, 2019

        Hi 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

      • An 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, 2019

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

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

Leave a Reply to Ian Cancel 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: