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

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

  7. Julien

     /  February 13, 2020

    Hi,
    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

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

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

    Reply
  9. Vasile Jichin

     /  March 11, 2020

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

    Reply
  10. Hello 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

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

      Reply
      • victor bassey

         /  August 20, 2020

        Thanks 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. :)” >

  1. Troubleshooting Always On VPN Error 691 and 812 – Part 2 | Richard M. Hicks Consulting, Inc.
  2. Troubleshooting Always On VPN Error 691 and 812 – Part 3 | Richard M. Hicks Consulting, Inc.

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