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

4 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

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: