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 IKEv2 Load Balancing and NAT

Always On VPN IKEv2 Load Balancing and NATOver the last few weeks, I’ve worked with numerous organizations and individuals troubleshooting connectivity and performance issues associated with Windows 10 Always On VPN, and specifically connections using the Internet Key Exchange version 2 (IKEv2) VPN protocol. An issue that appears with some regularity is when Windows 10 clients fail to connect with error 809. In this scenario, the server will accept connections without issue for a period of time and then suddenly stop accepting requests. When this happens, existing connections continue to work without issue in most cases. Frequently this occurs with Windows Server Routing and Remote Access Service (RRAS) servers configured in a clustered array behind an External Load Balancer (ELB).

Network Address Translation

It is not uncommon to use Network Address Translation (NAT) when configuring Always On VPN. In fact, for most deployments the public IP address for the VPN server resides not on the VPN server, but on an edge firewall or load balancer connected directly to the Internet. The firewall/load balancer is then configured to translate the destination address to the private IP address assigned to the VPN server in the perimeter/DMZ or the internal network. This is known a Destination NAT (DNAT). Using this configuration, the client’s original source IP address is left intact. This configuration presents no issues for Always On VPN.

Source Address Translation

When troubleshooting these issues, the common denominator seems to be the use of Full NAT, which includes translating the source address in addition to the destination. This results in VPN client requests arriving at the VPN server as appearing not to come from the client’s original IP address, but the IP address of the network device (firewall or load balancer) that is translating the request. Full NAT may be explicitly configured by an administrator, or in the case of many load balancers, configured implicitly because the load balancer is effectively proxying the connection.

Known Issues

IKEv2 VPN connections use IPsec for encryption, and by default, Windows limits the number of IPsec Security Associations (SAs) coming from a single IP address. When a NAT device is performing destination/full NAT, the VPN server sees all inbound IKEv2 VPN requests as coming from the same IP address. When this happens, clients connecting using IKEv2 may fail to connect, most commonly when the server is under moderate to heavy load.

Resolution

The way to resolve this issue is to ensure that any load balancers or NAT devices are not translating the source address but are performing destination NAT only. The following is configuration guidance for F5, Citrix ADC (formerly NetScaler), and Kemp load balancers.

F5

On the F5 BIG-IP load balancer, navigate to the Properties > Configuration page of the IKEv2 UDP 500 virtual server and choose None from the Source Address Translation drop-down list. Repeat this step for the IKEv2 UDP 4500 virtual server.

Always On VPN IKEv2 Load Balancing and NAT

Citrix ADC

On the Citrix ADC load balancer, navigate to System > Settings > Configure Modes and check the option to Use Subnet IP.

Always On VPN IKEv2 Load Balancing and NAT

Next, navigate to Traffic Management > Load Balancing > Service Groups and select the IKEv2 UDP 500 service group. In the Settings section click edit and select Use Client IP. Repeat these steps for the IKEv2 UDP 4500 service group.

Always On VPN IKEv2 Load Balancing and NAT

Kemp

On the Kemp LoadMaster load balancer, navigate to Virtual Services > View/Modify Services and click Modify on the IKEv2 UDP 500 virtual service. Expand Standard Options and select Transparency. Repeat this step for the IKEv2 UDP 4500 virtual service.

Always On VPN IKEv2 Load Balancing and NAT

Caveat

Making the changes above may introduce routing issues in your environment. When configuring these settings, it may be necessary to configure the VPN server’s default gateway to use the load balancer to ensure proper routing. If this is not possible, consider implementing the workaround below.

Workaround

To fully resolve this issue the above changes should be made to ensure the VPN server can see the client’s original source IP address. If that’s not possible for any reason, the following registry key can be configured to increase the number of established SAs from a single IP address. Be advised this is only a partial workaround and may not fully eliminate failed IKEv2 connections. There are other settings in Windows that can prevent multiple connections from a single IP address which are not adjustable at this time.

To implement this registry change, open an elevated PowerShell command window on the RRAS server and run the following commands. Repeat these commands on all RRAS servers in the organization.

New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\’ -Name IkeNumEstablishedForInitialQuery -PropertyType DWORD -Value 50000 -Force

Restart-Service IKEEXT -Force -PassThru

Additional Information

IPsec Traffic May Be Blocked When A Computer is Behind a Load Balancer

Windows 10 Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Windows 10 Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster

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

Always On VPN Error Code 858

Always On VPN Error Code 858When configuring Windows 10 Always On VPN using Extensible Authentication Protocol (EAP), the administrator may encounter a scenario in which the client connection fails. The event log will include an event ID 20227 from the RasClient source that includes the following error message.

“The user [domain\username] dialed a connection named [connection name] which has failed. The error code returned on failure is 858.”

Always On VPN Error Code 858

RasClient Error 858

RasClient error code 858 translates to ERROR_EAP_SERVER_CERT_EXPIRED. Intuitively, this indicates that the Server Authentication certificate installed on the Network Policy Server (NPS) has expired. To resolve this issue, renew the certificate on the NPS server.

Additional Information

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

Windows 10 Always On VPN and Windows Server 2019 NPS Bug

Windows 10 Always On VPN Error Code 864

Microsoft Intune NDES Connector Error 0x80004003

Microsoft Intune NDES Connector Error 0x80004003To support certificate deployment for non-domain Windows 10 Always On VPN clients, a Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Connection Status Error

After installing the Microsoft Intune Connector, the administrator may encounter the following error message.

“An error occurred while connecting to the Intune Service. Error code is 0x80004003. The NDES Connector will retry the connection as soon as possible.”

 Microsoft Intune NDES Connector Error 0x80004003

IE Enhanced Security Configuration

This error can occur if Internet Explorer Enhanced Security Configuration (ESC) is enabled. To resolve this issue, disable ESC for administrators and users by opening the Server Manager on the NDES server and performing the following steps.

1. In the navigation pane click Local Server.
2. Click the On link next to IE Enhanced Security Configuration.
3. Click Off in the Administrators section.
4. Click Off in the Users section
5. Click Ok.

Microsoft Intune NDES Connector Error 0x80004003

Once complete, restart the NDES Connector service using the following PowerShell command.

Restart-Service NDESConnectorSvc -PassThru

Additional Configuration

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Troubleshooting Always On VPN Error Code 864

When configuring an Always On VPN connection, the administrator may encounter a scenario in which a VPN connection fails using either Internet Key Exchange version 2 (IKEv2) or Secure Socket Tunneling Protocol (SSTP). On the Windows 10 client the error message states the following.

“Can’t connect to [connection name]. The remote access connection completed, but authentication failed because a certificate that validates the server certificate was not found in the Trusted Root Certification Authorities certificate store.”

Troubleshooting Always On VPN Error Code 864

In addition, the Application event log records an error message with Event ID 20227 from the RasClient source. The error message states the following.

“The user [username] dialed a connection name [connection name] which has failed. The error code returned on failure is 864.”

Troubleshooting Always On VPN Error Code 864

NPS Server Certificate

Error code 864 is commonly caused by a missing or invalid server certificate on the Network Policy Server (NPS) performing authentication for VPN clients. The NPS server must have a certificate installed in its local computer certificate store from a trusted certification authority (CA) that includes the following.

Subject Name

The subject name must match the hostname defined in the EAP configuration for VPN clients. This may be the NPS server’s hostname but could also be an alias when NPS load balancing is configured.

Troubleshooting Always On VPN Error Code 864

Enhanced Key Usage

The NPS server certificate must include the Server Authentication Enhanced Key Usage (EKU).

Troubleshooting Always On VPN Error Code 864

NPS Policy Configuration

The NPS server certificate must also be selected in the network policy used for VPN client authentication. To confirm correct certificate configuration, open the properties for the Always On VPN network policy and follow the steps below.

1. Select the Constraints tab.
2. Highlight Authentication Methods.
3. Highlight Microsoft: Protected EAP (PEAP) in the EAP Types field.
4. Click Edit.
5. Select the NPS server certificate from the Certificate issued to drop-down list.

Troubleshooting Always On VPN Error Code 864

Ensure the NPS server certificate is also used for client certificate authentication by performing the following steps.

1. Highlight Smart Card or other certificate.
2. Click Edit.
3. Select the NPS server certificate from the Certificate issued to drop-down list.
4. Click Ok.

Troubleshooting Always On VPN Error Code 864

Additional Information

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

Always On VPN IKEv2 Policy Mismatch Error

Always On VPN IKEv2 Policy Mismatch ErrorThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice for Windows 10 Always On VPN deployments where the highest levels of security and assurance are required. However, as I’ve written about in the past, often the default IKEv2 security settings are less than desirable. Before using IKEv2 VPN in a production environment the administrator will need to update these security settings accordingly.

Connection Failure

When configuring Windows Server Routing and Remote Access Service (RRAS) or a third-party VPN appliance to support IKEv2 using custom security policies, the administrator may encounter a scenario in which a connection cannot be established due to a policy mismatch error. When the connection attempt fails, an error will be recorded in the Windows Application event log from the RasClient source with Event ID 20227. The error message states the following:

“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13868.”

Always On VPN IKEv2 Policy Mismatch Error

Error Code 13868

Error code 13868 translates to ERROR_IPSEC_IKE_POLICY_MATCH. Essentially this error indicates that the IKEv2 security policy on the client did not match the configuration on the server.

Server Configuration

To view the current IKEv2 IPsec policy configuration, open an elevated PowerShell command window and run the following command.

Get-VpnServerIPsecConfiguration

Always On VPN IKEv2 Policy Mismatch Error

Client Configuration

To ensure interoperability, the VPN client must be configured to use the same IKEv2 security policy as defined on the sever. To view a VPN client’s currently configured IKEv2 security policy, open an elevated PowerShell command window and run the following command.

Get-VpnConnection -Name [connection name] | Select-Object -ExpandProperty IPsecCustomPolicy

Always On VPN IKEv2 Policy Mismatch Error

Note: If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.

Updating Settings

Guidance for configuring IKEv2 security policies on Windows Server RRAS and Windows 10 can be found here.

Summary

IKEv2 policy mismatch errors can be resolved easily by ensuring both the VPN server and client are configured to use the same IPsec security policies. Use the PowerShell commands in the above referenced above to validate settings and make changes when necessary.

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Features and Limitations

Show-VpnConnectionIPsecConfiguration PowerShell script on Github

Set-IKEv2SecurityBaseline PowerShell script on Github

Error Importing Windows Server RRAS Configuration

Error Importing Windows Server RRAS Configuration Windows Server and the Routing and Remote Access Service (RRAS) is a popular choice for Windows 10 Always On VPN deployments. It is easy to implement and support, offers flexible scalability, and is cost-effective. In addition, it provides support for a TLS-based VPN protocol which is required for many deployments.

Configuration Backup

When deploying RRAS to support Always On VPN, it’s an excellent idea to export the configuration once all settings have been finalized. Often this is done by opening an elevated command window and running netsh.exe ras dump and piping the output to a text file, as shown here.

netsh.exe ras dump > rasconfig.txt

Import Error

Importing a saved configuration is accomplished by opening an elevated command window and running netsh.exe exec [filename], as shown here.

netsh.exe exec rasconfig.txt

Oddly, this doesn’t work by default. The import will fail and return the following error message.

“The following command was not found: ■.”

Error Importing Windows Server RRAS Configuration

Root Cause

Importing the RRAS configuration fails because the default configuration output is saved in Unicode format. Inexplicably this encoding is not recognized by netsh.exe when importing the configuration.

Workaround

Follow the steps below to save the configuration file in a format that can be imported using netsh.exe.

1. Open the exported configuration file using notepad.exe.
2. From the Menu bar choose File > Save As.
3. From the Encoding drop-down list choose ANSI.
4. Click Save.

Error Importing Windows Server RRAS Configuration

Once complete, import the file using netsh.exe exec [filename]. Restart the RemoteAccess service to apply the changes.

PowerShell

Administrators can use PowerShell to export the RRAS configuration and ensure the correct encoding format is used by default. To do this, open an elevated PowerShell window and run the following command.

Invoke-Command -ScriptBlock {netsh ras dump} | Out-File [filename] -Encoding ASCII

You can also find PowerShell script to import and export RRAS configuration on my Github.

Export-VpnServerConfiguration.ps1

Import-VpnServerConfiguration.ps1

Additional Information

Windows 10 Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Windows 10 Always On VPN Protocol Recommendations for Windows Server Routing and Remote Access Service (RRAS)

Always On VPN RasMan Errors in Windows 10 1903

Always On VPN RasMan Errors in Windows 10 1903After deploying or upgrading to Windows 10 1903, administrators may find that Windows 10 Always On VPN connections fail to establish successfully. Always On VPN connections continue to work for Windows 10 1809 and earlier clients, however.

Important Note: The issue described in this article has been addressed in KB4505903 (build 18362.267) released July 26, 2019.

RasMan Event Log Errors

When this occurs, the application event log contains an error with Event ID 1000 that includes the following information.

“Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005”

Always On VPN RasMan Errors in Windows 10 1903 Administrators may find that Windows 10 Always On VPN connections fail after deploying or upgrading to Windows 10 1903. Always On VPN connections continue to work for Windows 10 1809 and earlier clients. RasMan Event Log Errors When this occurs, the application event log contains an error with Event ID 1000 that includes the following information. “Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005” Root Cause RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix. Workaround As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell. Group Policy Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps. 1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds 2. Double-Click Allow Telemetry. 3. Select Enabled. 4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security). 5. Click Ok. Registry Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting. HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1 Note: The AllowTelemetry value can be removed entirely, if desired. PowerShell PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting. New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely. Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry Restart Required Once these changes have been made, restart the client and test the Always On VPN connection. Additional Information asdf

Root Cause

RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix.

Workaround

As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell.

Group Policy

Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps.

1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds
2. Double-click Allow Telemetry.
3. Select Enabled.
4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security).
5. Click Ok.

Always On VPN RasMan Errors in Windows 10 1903 Administrators may find that Windows 10 Always On VPN connections fail after deploying or upgrading to Windows 10 1903. Always On VPN connections continue to work for Windows 10 1809 and earlier clients. RasMan Event Log Errors When this occurs, the application event log contains an error with Event ID 1000 that includes the following information. “Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005” Root Cause RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix. Workaround As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell. Group Policy Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps. 1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds 2. Double-Click Allow Telemetry. 3. Select Enabled. 4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security). 5. Click Ok. Registry Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting. HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1 Note: The AllowTelemetry value can be removed entirely, if desired. PowerShell PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting. New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely. Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry Restart Required Once these changes have been made, restart the client and test the Always On VPN connection. Additional Information asdf

Registry

Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting.

HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1

Always On VPN RasMan Errors in Windows 10 1903 Administrators may find that Windows 10 Always On VPN connections fail after deploying or upgrading to Windows 10 1903. Always On VPN connections continue to work for Windows 10 1809 and earlier clients. RasMan Event Log Errors When this occurs, the application event log contains an error with Event ID 1000 that includes the following information. “Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005” Root Cause RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix. Workaround As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell. Group Policy Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps. 1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds 2. Double-Click Allow Telemetry. 3. Select Enabled. 4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security). 5. Click Ok. Registry Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting. HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1 Note: The AllowTelemetry value can be removed entirely, if desired. PowerShell PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting. New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely. Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry Restart Required Once these changes have been made, restart the client and test the Always On VPN connection. Additional Information asdf

Note: The AllowTelemetry value can be removed entirely, if desired.

PowerShell

PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting.

New-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\’ -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force

Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely.

Remove-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\’ -Name AllowTelemetry

Service Restart Required

Once these changes have been made, restart the Remote Access Connection Manager service (RasMan) using the Services mnagement console (services.msc) or by running the following PowerShell command.

Restart-Service RasMan -PassThru

Optionally, the client can be rebooted to apply these changes.

Additional Information

Windows 10 1903 Known Issues

 

Always On VPN and Azure MFA ESTS Token Error

Always On VPN and Azure MFA ESTS Token ErrorConfiguring Multifactor Authentication (MFA) is an excellent way to ensure the highest level of assurance for Always On VPN users. Azure MFA is widely deployed and commonly integrated with Windows Server Network Policy Server (NPS) using the NPS Extension for Azure MFA. Azure MFA has a unique advantage over many other MFA providers in that it supports MFA when using Protected Extensible Authentication Protocol (PEAP). This makes Azure MFA the solution of choice for integrating with Windows 10 Always On VPN deployments using client certificate authentication, a recommended security configuration best practice.

NPS Configuration

Installing and configuring the NPS extension for Azure MFA is straightforward. Configuration guidance from Microsoft can be found here.

Connection Issues

After installing the NPS extension for Azure MFA, administrators may find that Always On VPN connections fail and the user is never challenged for authentication. The connection eventually times out and returns the following error message.

“A connection to the remote computer could not be established, so the port used for this connection was closed.”

Always On VPN and Azure MFA ESTS Token Error

In addition, the Application event log on the Windows 10 client contains an Event ID 20221 from the RasClient source that includes the following error message.

“The user [username] dialed a connection named [connection] which has failed. The error code returned on failure is 0.”

Always On VPN and Azure MFA ESTS Token Error

NPS Event Log

Reviewing the event logs on the NPS server reveals more information. The Security event log contains an Event ID 6274 from the Microsoft Windows security auditing source that includes the following error message.

“Network Policy Server discarded the request for a user. Contact the Network Policy Administrator for more information.”

Always On VPN and Azure MFA ESTS Token Error

ESTS Token Error

Digging deeper in the operational event log on the NPS server, the AuthZAdminCh log (Applications and Services Logs > Microsoft > AzureMfa > AuthZ) contains an Event ID 3 from the AuthZ source indicating an ESTS_TOKEN_ERROR message.

Always On VPN and Azure MFA ESTS Token Error

Troubleshooting ESTS Token Error

Follow the steps below to troubleshoot the ESTS_TOKEN_ERROR.

Prerequisites

Ensure that all prerequisites are met. Validate the user is being synced to Azure Active Directory and that it is properly licensed for Azure MFA.

Certificates

As part of the NPS extension configuration, a certificate is created on the NPS server that is uploaded to Azure Active Directory. To validate the certificate was created and uploaded correctly, follow the troubleshooting guidance found here.

Enterprise Applications

The Azure Multi-Factor Auth Client and the Azure Multi-Factor Auth Connector enterprise applications must be enabled to support the NPS extension for Azure MFA. To confirm they are enabled, open an elevated PowerShell command window on the server where the Azure AD Connector is installed and run the following PowerShell commands.

Import-Module MSOnline
Connect-MsolService

Get-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” | Select-Object DisplayName, AccountEnabled

Get-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” | Select-Object DisplayName, AccountEnabled

Always On VPN and Azure MFA ESTS Token Error

If either or both enterprise applications are not enabled, enable them using the following PowerShell commands.

Set-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” -AccountEnabled $True

Set-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” -AccountEnabled $True

Once complete, restart the IAS service on the NPS server using the following PowerShell command.

Restart-Service IAS -PassThru

Additional Information

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

Deploy Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes Now Available

%d bloggers like this: