Always On VPN Book Available for Pre-Order

Great news! My new book, Implementing Always On VPN, is now available for pre-order on Amazon.com. This new book, scheduled for release in late 2021, is a comprehensive implementation guide for Windows 10 Always On VPN. Drawing on many years of experience deploying Always On VPN for organizations worldwide, it covers all aspects of an Always On VPN deployment, including planning and design, prerequisite gathering, infrastructure preparation, and client deployment.

In addition, it contains detailed, prescriptive guidance for advanced configuration options such as application and traffic filtering and proxy server configuration. Cloud deployments using Azure VPN gateway and Virtual WAN are covered, and it includes guidance for configuring Azure MFA and Conditional Access.

Also, the book includes thorough guidance for provisioning certificates using Microsoft Endpoint Manager/Intune using both PKCS and SCEP. It outlines options for high availability for VPN and authentication infrastructure and provides details for ongoing system maintenance and operational support.

Finally, the book has an entire chapter dedicated to troubleshooting and resolving common (and not so common!) issues encountered with Windows 10 Always On VPN.

Reserve your copy today. Pre-order Implementing Always On VPN now!

Chapter List

  1. Always On VPN Overview
  2. Plan an Always On VPN Deployment
  3. Prepare the Infrastructure
  4. Configure Windows Server for Always On VPN
  5. Provision Always On VPN clients
  6. Advanced Configuration
  7. Cloud Deployments
  8. Deploy Certificates with Intune
  9. Integrating Azure MFA
  10. High Availability
  11. Monitor and Report
  12. Troubleshooting

Always On VPN Error 853 on Windows 11

Recently I did some validation testing with Always On VPN on Windows 11, and I’m happy to report that everything seems to work without issue. However, a few readers have reported 853 errors when establishing an Always On VPN connection after upgrading to Windows 11.

Can’t Connect

After upgrading to Windows 11, an Always On VPN connection may fail with the following error message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure the certificate used for authentication is valid.”

Error 853

In addition, the Application event log records an event ID 20227 from the RasClient source that includes the following message.

“The user <username> dialed a connection name <connection name> which has failed. The error code returned on failure is 853.”

Server Identity

This error will occur when using Protected Extensible Authentication Protocol (PEAP) authentication. Specifically, it can happen when the option to verify NPS server validity by its certificate is selected, and an explicit list of NPS servers is defined, as shown here.

Case Sensitive

In this specific scenario, Windows 11 now appears to be case-sensitive when it compares the NPS server name entered in the NPS configuration to the Subject Name on the certificate returned by the server. For example, if the Subject Name (or Subject Alternative Name, if present) entry on the NPS server certificate is nps.lab.richardhicks.net, using NPS.lab.richardhicks.net will not match and return an 853 error.

Windows 11

Case matching when validating the NPS server certificate is a change in behavior from Windows 10. Before Windows 11, this comparison was case-insensitive, and any combination of case would match if the entire hostname matched. Going forward, it appears Microsoft has also decided to require case matching to validate the server certificate.

Recommendations

Administrators should look carefully at the server certificate issued to the NPS server and ensure their client configuration accurately reflects the hostname in a case-sensitive manner to ensure a smooth migration from Windows 10 to Windows 11.

Additional Information

Troubleshooting Windows 10 Always On VPN Error 853

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing

Always On VPN Authentication Failure with Azure Conditional Access

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Integrating Microsoft Azure Conditional Access with Windows 10 Always On VPN has several important benefits. The most important is that it allows administrators to improve their security posture by enforcing access polices that can be dynamically applied. For example, requiring multifactor authentication (MFA) for privileged users (e.g., administrators) or sign-ins that appear to be risky, the type of device they are connecting with, the health of the endpoint, and much more.

Authentication Failure

When configuring Always On VPN to support Azure Conditional Access, administrators may expeirence a failed authentication during preliminary testing. Specifically, an event ID 20227 from the RasClient source may be encountered with the following error message.

“The user <username> dialed a connection named <connection name> which has failed. The error code returned on failure is 812.”

Looking at the event logs on the Network Policy Server (NPS) server reveals an event ID 6273 from the Microsoft Windows security auditing source with Reason Code 258 and the following Reason.

“The revocation function was unable to check revocation for the certificate.”

Root Cause

When Azure Conditional Access is configured for Always On VPN, a short-lived certificate (1 hour lifetime) is provisioned by Azure. This certificate does not include revocation information because, by design, a short-lived certificate does not need to be revoked. However, by default NPS always checks revocation when client authentication certificates are used for authentication. Since the certificate does not include this information, certificate revocation fails.

Resolution

The way to resolve this issue is to disable certificate revocation checking for Protected Extensible Authentication Protocol (PEAP) authentication requests. To do this, open an elevated PowerShell window on the NPS server and run the following command.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\’ -Name IgnoreNoRevocationCheck -PropertyType DWORD -Value 1 -Force

Once complete, restart the NPS server for the changes to take effect.

Additional Information

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing

Windows 10 Always On VPN Network Policy Server (NPS) Server 2019 Bug

Troubleshooting Always On VPN Error 853

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Using Windows Server Network Policy Server (NPS) servers is a common choice for authenticating Microsoft Windows 10 Always On VPN user tunnel connections. The NPS server is joined to the domain and configured with a Network Policy that defines the authentication scheme used by clients for authentication when establishing an Always On VPN connection. Protected Extensible Authentication Protocol (PEAP) using client authentication certificates recommended for most Always On VPN deployment scenarios.

Can’t Connect

Users establishing an Always On VPN user tunnel connection using PEAP and client authentication certificates may encounter a scenario in which a VPN connection attempt fails with the following error message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure that the certificate used for authentication is valid.”

Error 853

In addition, the Application event log records an event ID 20227 from the RasClient source that includes the following error message.

“The user <username> dialed a connection named <connection name> which has failed. The error code is 853.”

Missing NTAuth Certificate

Error code 853 is commonly caused by a missing issuing Certification Authority (CA) certificate in the NTAuth store on the NPS server. The NPS server must have the issuing CA certificate included in this store to perform authentication using client certificates. You can see the contents of the NTAuth certificate store by opening an elevated command window on the NPS server and running the following command.

certutil.exe -enterprise -viewstore NTAuth

Install Certificate

To install the issuing CA server’s certificate into the NTAuth store, copy the CA certificate to the NPS server, open an elevated command window, then run the following command.

certutil.exe -enterprise -addstore NTAuth <issuing CA certificate>

Once complete, view the store again, and you’ll see the issuing CA certificate listed in the NTAuth certificate store.

Additional Information

Troubleshooting Always On VPN Error Code 858

Troubleshooting Always On VPN Error Code 864

Always On VPN and Windows Server 2019 NPS Bug

Always On VPN Network Policy Server (NPS) Load Balancing

Microsoft Network Policy Server (NPS) Reason Codes

Always On VPN Continue Connecting Prompt

Using the Extensible Authentication Protocol (EAP) with client certificates is the recommended best practice for authentication for Windows 10 Always On VPN deployments. EAP, and especially Protected EAP (PEAP), has a lot of settings to configure and it is not uncommon to encounter issues related to some parameters being defined incorrectly. This post covers one of the more common issues related to EAP/PEAP misconfiguration.

Action Needed?

When establishing an Always On VPN user tunnel connection, users may find the connection does not complete automatically, and they are informed that additional action is needed.

Clicking on the VPN connection and then clicking Connect prompts the user with the following message.

“Action needed. Continue connecting? We don’t have enough info to validate the server. You can still connect if you trust this server.”

Common Causes

This message can occur when (EAP) is used and is configured to perform server validation with a restricted set of NPS servers, as shown here.

NPS Server Certificate

The NPS server performing authentication for the connection request must have a certificate that includes a subject name that matches one of the names of the NPS servers defined in the EAP configuration. The certificate must be issued by the organizations private certification authority (CA).

EAP Configuration

Alternatively, the client-side EAP configuration may be incorrect. Although the NPS server may have the correct hostname configured on its certificate, it may not be entered correctly on the client. Ensure the hostname listed in the “Connect to these servers” field matches the subject name or SAN of the NPS server certificate defined in the network policy used for the Always On VPN user tunnel. Look carefully at the syntax when defining multiple NPS servers. Multiple servers are separated by a semi-colon and there are no additional spaces. Missing either one of these critical details will result in connection prompts. Also, ensure that all NPS servers used for authentication (those defined on the VPN server) are included in this list.

Note: Administrators must ensure that all VPN clients have updated their EAP configuration before adding additional NPS servers to the environment. Failure to do so will result in connection prompts.

Security Best Practice

To be clear, the behavior above is not ideal from a security perspective. Validating the NPS server before authenticating is crucial to ensuring the highest level of security and assurance, preventing credential theft from a man-in-the-middle attack. For this reason, it is recommended that users not be given the choice to authorize an NPS server. Authorized NPS servers should be defined by administrators exclusively. This is accomplished by selecting the option “Don’t ask user to authorize new servers or trusted CAs” in the Notifications before connecting drop-down list, and by selecting the option “Don’t prompt user to authorize new servers or trusted certification authorities“.

Additional Information

Always On VPN Network Policy Server (NPS) Load Balancing

Always On VPN and Windows Server 2019 NPS Bug

Always On VPN Updates for Windows 10 2004

Always On VPN Updates for Windows 10 2004Microsoft recently made available an update for Windows 10 2004 that includes many important fixes for outstanding issues with Windows 10 Always On VPN. KB4571744 (build 19041.488) addresses many challenges faced by Always On VPN administrators today, including the following.

TPM

This update addresses an issue that prevents hash signing from working correctly using the Microsoft Platform Crypto Provider for Trusted Platform Module (TPM). This issue can occur when administrators configure Always On VPN to use Protected Extensible Authentication Protocol (PEAP) with client certificate authentication using a FortiGate security device.

Sleep/Hibernate

This update also addresses issues with Windows 10 Always On VPN failing to automatically reconnect when resuming from sleep or hibernate. I’ve written about issues with Always On VPN and sleep/hibernate in the past. This is an issue that has plagued Always On VPN since its introduction, so let’s hope this finally provides some meaningful relief from this persistent problem.

Certificate Authentication

When both the Always On VPN device tunnel and user tunnel are provisioned to a Windows 10 clients, user tunnel connections may be authenticated using the machine certificate and not EAP/PEAP. This can result in connections that are not validated as intended, and allowing a user to bypass configured NPS policies, MFA requirements, or conditional access rules. This update includes a fix for this issue, restoring proper authentication for the user tunnel when the device tunnel is also provisioned.

Device and User Tunnel Coexistence

A bug that first appeared when Windows 10 2004 was introduced prevented a device tunnel and user tunnel Always On VPN connection from being established to the same VPN server if the user tunnel used Internet Key Exchange Version 2 (IKEv2). This update restores full functionality under those conditions.

Update KB4571744

To resolve these issues with Windows 10 Always On VPN as well as others, download and install update KB4571744 today. If you are experiencing any of these issues with releases of Windows 10 prior to 2004, look for updates for those build to come later this year.

Additional Information

September 3, 2020 – KB4571744 (OS Build 19041.488) Preview

Windows 10 Always On VPN Connection Issues after Sleep or Hibernate

Windows 10 Always On VPN Bug in Windows 10 2004

Troubleshooting Always On VPN Error 691 and 812 – Part 3

Troubleshooting Always On VPN Error 691 and 812 – Part 2When 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.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

In addition, an error 812 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2Group 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.

Troubleshooting Always On VPN Errors 691 and 812

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!).

Troubleshooting Always On VPN Errors 691 and 812

Additional Information

Troubleshooting Always On VPN Error 691 and 812 – Part 1

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Always On VPN Device Tunnel Only Deployment Considerations

Always On VPN Device Tunnel Only Deployment ConsiderationsRecently I wrote about Windows 10 Always On VPN device tunnel operation and best practices, explaining its common uses cases and requirements, as well as sharing some detailed information about authentication, deployment recommendations, and best practices. I’m commonly asked if deploying Always On VPN using the device tunnel exclusively, as opposed to using it to supplement the user tunnel, is supported or recommended. I’ll address those topics in detail here.

Device Tunnel Only?

To start, yes, it is possible to deploy Windows 10 Always On VPN using only the device tunnel. In this scenario the administrator will configure full access to the network instead of limited access to domain infrastructure services and management servers.

Is It Recommended?

Generally, no. Remember, the device tunnel was designed with a specific purpose in mind, that being to provide pre-logon network connectivity to support scenarios such as logging on without cached credentials. Typically, the device tunnel is best used for its intended purpose, which is providing supplemental functionality to the user tunnel.

Deployment Considerations

The choice to implement Always On VPN using only the device tunnel is an interesting one. There are some potential advantages to this deployment model, but it is not without some serious limitations. Below I’ve listed some of the advantages and disadvantages to deploying the device tunnel alone for Windows 10 Always On VPN.

Advantages

Using the device tunnel alone does have some compelling advantages over the standard two tunnel (device tunnel/user tunnel) deployment model. Consider the following.

  • Single VPN Connection – Deploying the device tunnel alone means a single VPN connection to configure, deploy, and manage on the client. This also results in less concurrent connections and, importantly, less IP addresses to allocate and provision.
  • Reduced Infrastructure – The device tunnel is authenticated using only the device certificate. This certificate check is performed directly on the Windows Server Routing and Remote Access Service (RRAS) VPN server, eliminating the requirement to deploy Network Policy Server (NPS) servers for authentication.
  • User Transparency – The device tunnel does not appear in the modern Windows UI. The user will not see this connection if they click on the network icon in the notification area. In addition, they will not see the device tunnel connection in the settings app under Network & Internet > VPN. This prevents casual users from playing with the connection settings, and potentially deleting the connection entirely. It’s not that they can’t delete the device tunnel however, it’s just not as obvious.
  • Simplified Deployment – Deploying the device tunnel is less complicated than deploying the user tunnel. The device tunnel is provisioned once to the device and available to all users. This eliminates the complexity of having to deploy the user tunnel in each individual user’s profile.

Disadvantages

While there are some advantages to using the device tunnel by itself, this configuration is not without some serious limitations. Consider the following.

  • IKEv2 Only – The device tunnel uses the IKEv2 VPN protocol exclusively. It does not support SSTP. While IKEv2 is an excellent protocol in terms of security, it is commonly blocked by firewalls. This will prevent some users from accessing the network remotely depending on their location.
  • Limited OS Support – The device tunnel is only supported on Windows 10 Enterprise edition clients, and those clients must be joined to a domain. Arguably the device tunnel wouldn’t be necessary if the client isn’t domain joined, but some organizations have widely deployed Windows 10 Professional, which would then preclude them from being able to use the device tunnel.
  • Machine Certificate Authentication Only – The device tunnel is authenticated using only the certificate issued to the device. This means anyone who logs on to the device will have full access to the internal network. This may or may not be desirable, depending on individual requirements.
  • No Mutual Authentication – When the device tunnel is authenticated, the server performs authentication of the client, but the client does not authenticate the server. The lack of mutual authentication increases the risk of a man-in-the-middle attack.
  • CRL Checks Not Enforced – By default, RRAS does not perform certificate revocation checking for device tunnel connections. This means simply revoking a certificate won’t prevent the device from connecting. You’ll have to import the client’s device certificate into the Untrusted Certificates certificate store on each VPN server. Fortunately, there is a fix available to address this limitation, but it involves some additional configuration. See Always On VPN Device Tunnel and Certificate Revocation for more details.
  • No Support for Azure Conditional Access – Azure Conditional Access requires EAP authentication. However, the device tunnel does not use EAP but instead uses a simple device certificate check to authenticate the device.
  • No Support for Multifactor Authentication – As the device tunnel is authenticated by the RRAS VPN server directly and authentication requests are not sent to the NPS server, it is not possible to integrate MFA with the device tunnel.
  • Limited Connection Visibility – Since the device tunnel is designed for the device and not the user it does not appear in the list of active network connections in the Windows UI. There is no user-friendly connection status indicator, although the connection can be viewed using the classic network control panel applet (ncpa.cpl).

Summary

The choice to deploy Windows 10 Always On VPN using the device tunnel alone, or in conjunction with the user tunnel, is a design choice that administrators must make based on their individual requirements. Using the device tunnel alone is supported and works but has some serious drawbacks and limitations. The best experience will be found using the device tunnel as it was intended, as an optional component to provide pre-logon connectivity for an existing Always On VPN user tunnel.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Features and Limitations

Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Operation and Best PracticesUnlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.

Device Tunnel Use Cases

The device tunnel is designed to allow the client device to establish an Always On VPN connection before the user logs on. This enables important scenarios such as logging on without cached credentials. This feature is crucial for organizations who expect users to log on to devices the first time remotely. The device tunnel can also be helpful for remote support, allowing administrators to manage remotely connected Always On VPN clients without having a user logged on. In addition, the device tunnel can alleviate some of the pain caused by administrators resetting remote worker’s passwords, or by users initiating a Self-Service Password Reset (SSPR).

Device Tunnel Requirements

The device tunnel requires Windows 10 Enterprise edition 1709 or later, and the client device must be joined to the domain. The device tunnel must be provisioned in the context of the local system account. Guidance for configuring and deploying a Windows 10 Always On VPN device tunnel can be found here.

Device Tunnel Authentication

The device tunnel is authenticated using a certificate issued to the client device, much the same as DirectAccess does. Authentication takes place on the Routing and Remote Access Service (RRAS) VPN server. It does not require a Network Policy Server (NPS) to perform authentication for the device tunnel.

Always On VPN Device Tunnel Operation and Best Practices

CRL Checking

Eventually an administrator may need to deny access to a device configured with an Always On VPN device tunnel connection. In theory, revoking the client device’s certificate and terminating their IPsec Security Associations (SAs) on the VPN server would accomplish this. However, Windows Server RRAS does not perform certificate revocation checking for Windows 10 Always On VPN device tunnel connections by default. Thankfully an update is available to enable this functionality. See Always On VPN Device Tunnel and Certificate Revocation for more details.

Configuration Best Practices

As the device tunnel is designed only to support domain authentication for remote clients, it should be configured with limited access to the on-premises infrastructure. Below is a list of required and optional infrastructure services that should be reachable over the device tunnel connection.

Required

  • All domain controllers
  • Enterprise DNS servers (if DNS is running on servers other than domain controllers)

Optional

  • All issuing certification authority (CA) servers
  • All certificate services online HTTP responders
  • All certificate services Online Certificate Status Protocol (OCSP) servers
  • System Center Configuration Manager (SCCM) distribution point servers
  • Windows Server Update Services (WSUS) servers
  • Management workstations

Limiting Access

Limiting access over the Always On VPN device tunnel can be accomplished in one of the following two ways.

Traffic Filters

The administrator can configure traffic filters on the device tunnel to restrict access only to those IP addresses required. However, be advised that when a traffic filter is enabled on the device tunnel, all inbound access will be blocked. This effectively prevents any remote management of the device from an on-premises system over the device tunnel.

Host Routes

An alternative to using traffic filters to limit access over the device tunnel is using host routes. Host routes are configured with a /32 prefix size and define a route to a specific individual host. The following is an example of host route configuration in ProfileXML.

Always On VPN Device Tunnel Operation and Best Practices

Note: A PowerShell script that enumerates all enterprise domain controllers and outputs their IP addresses in XML format for use in ProfileXML can be found here.

Caveats

Some organizations may have hundreds or even thousands of domain controllers, so creating individual host route entries for all domain controllers in profileXML may not be practical. In this scenario it is recommended to add host routes only for the domain controllers that belong to the Active Directory site where the VPN server resides.

Supportability

Do not use the <DomainNameInformation> element in ProfileXML or enable force tunneling for the device tunnel. Neither of these configurations are supported.

Tunnel Coexistence

The device tunnel can be safely deployed in conjunction with the user tunnel whenever its functionality is required.

DNS Registration

If the device tunnel and user tunnel are both deployed, it is recommended that only one of the tunnels be configured to register in DNS. If the device tunnel is configured to register its IP address in DNS, be advised that only those devices with routes configured in the device tunnel VPN profile will be able to connect remotely to Always On VPN clients.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Troubleshooting Always On VPN Error 691 and 812 – Part 2A while back I wrote about troubleshooting and resolving Windows 10 Always On VPN errors 691 and 812. There are numerous issues that can result in these errors, and in that post I pointed out they can be caused by disabling TLS 1.0 on Windows Servers prior to Windows Server 2016. However, administrators may encounter a another scenario in which they receive errors 691 or 812 which is related to Active Directory user account configuration.

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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

Troubleshooting Always On VPN Error 691 and 812 – Part 2

In addition, an error 812 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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 65 and the following reason.

“The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Resolution

There are two options available to address this issue. The user account in Active Directory can be configured to grant access or allow access to be controlled via NPS network policy, or the NPS network policy can be configured to ignore user account dial-in properties.

User Account

Follow the steps below to change Network Access Permission on an individual user’s Active Directory account.

  1. Open the Active Directory User and Computers (ADUC) management console (dsa.msc) and double-click the user’s account.
  2. Select the Dial-in tab.
  3. In the Network Access Permission section select the option to Allow access or Control access through NPS Network Policy.

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Note: If you do not see the dial-in tab, open the ADUC console on a domain controller. The dial-in tab is not displayed when using the Remote Server Administration Tools (RSAT) for Windows clients.

Network Policy

Follow the steps below to configure NPS network policy to ignore user account dial-in properties.

  1. Open the NPS management console (nps.msc) and double-click the Always On VPN network policy.
  2. In the Access Permission section select Ignore user account dial-in properties.
  3. Click Ok to save the changes.

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Additional Information

Windows 10 Always On VPN Troubleshooting Error 691 and 812

%d bloggers like this: