When implementing Windows 10 Always On VPN, administrators may encounter errors 691 or 812 when establishing a VPN connection. There are several different configuration issues that will result in these errors. For example they may occur when TLS 1.0 has been disabled on the RRAS server when installed on servers prior to Windows Server 2016. It can also happen if a user’s Active Directory account is configured to deny dial-in access and the NPS server is not configured to ignore user account dial-in properties. Another scenario that can result in 691/812 errors is when the Active Directory security groups are configured as conditions on the Network Policy Server (NPS) Network Policy. See below for more details.
SSTP and Error 691
When attempting to establish an Always On VPN connection using the Secure Socket Tunneling Protocol (SSTP), administrators may encounter the following error message.
“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.”
In addition, an error 691 with event ID 20227 from the RasClient source can be found in the Application event log on the client.
“The user <domain\user> dialed a connection named which has failed. The error code returned on failure is 691.”
IKEv2 and Error 812
When attempting to establish an Always On VPN connection using Internet Key Exchange version 2 (IKEv2), administrators may encounter the following error message.
“The connection as 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 error 812 with event ID 20227 from the RasClient source can be found in the Application event log on the client.
NPS Event Log
On the NPS server the administrator will find an entry in the application event log with event ID 6273 from the Microsoft Windows security auditing source and the Network Policy Server task category indicating the network policy server denied access to the user. Looking closely at this event log message shows Reason Code 48 and the following reason.
“The connection request did not match any configured network policy.”
Group Membership
As stated earlier, another scenario in which administrators will encounter errors 691 and/or 812 is when the Network Policy on the NPS server is configured incorrectly. Specifically, and administrator may wish to grant access to more than one group but intend for access to be granted to users who are a member of any of them. Conversely, they may wish to require access in all specified groups to gain access to the VPN. Configuring each of these conditions is subtly different, however.
Open the NPS management console on the NPS server and follow the steps below to configure user group conditions correctly for the following scenarios.
Any Group
1. Right-click the Always On VPN network policy and choose Properties.
2. Click on the Conditions tab.
3. Click the Add button.
4. Click User Groups.
5. Click Add.
6. Click Add Groups.
7. Enter the name of the group you want to grant access to.
8. Click Ok.
9. Repeat the steps 6-8 above to specify additional groups.
All Groups
1. Right-click the Always On VPN network policy and choose Properties.
2. Click on the Conditions tab.
3. Click the Add button.
4. Click User Groups.
5. Click Add.
6. Click Add Groups.
7. Enter the name of the group you want to grant access to.
8. Click Ok.
9. Repeat steps 3-8 above to specify additional groups (you must go back to the Add button on step 3!).
Andy Chips
/ July 29, 2020Thank you Richard. Articles like this are gold dust to technicians on the ground like me.
Richard M. Hicks
/ July 29, 2020My pleasure! And trust me, I know their value. I search for error codes and message every day on the Internet! Happy to help someone solve their issue for sure. It’s my way of paying it back I guess. 🙂
digitalfix
/ September 20, 2021Hi Richard, not sure if you have tested this yet, but I’m seeing error 812 on Windows 11 clients in our test lab. Same accounts can connect just fine using Windows 10. On Win 11, device tunnel connects, but User tunnel throws the 812 error. Have checked as far as I can, scratching my head now
Richard M. Hicks
/ September 20, 2021Are your clients performing NPS server validation? If so, I’ve had some reports that Windows 11 is now case-sensitive and may fail if the case doesn’t match exactly what’s on the certificate. You can try disabling this feature temporarily to see if that works.
digitalfix
/ September 21, 2021Hi Richard, yes they are performing NPS validation. I’ll check the case against the certificate and update the profile and test, thank you 🙂
Siebe
/ February 22, 2022At this moment we have a similar issue in our organization. We have a total of about 8000 concurrent users who can work with the Always on VPN. But there are 15-20 users who are unable to connect using the certificate. Only userid+password works.
We replaced the password, Certificate, reinstalled the workstation and replaced the hardware for all. Still no solution. We logged a ticket with Microsoft and they did not know what causes the 812 message with the particular users.
Richard M. Hicks
/ February 22, 2022I have several customers with the same issue. Works fine for most, some not. Also, some clients will work fine for days/weeks/months, then stop working. Certificate is fine, but VPN complains there’s no certificate. No success with Microsoft on this issue to date. :/