Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMasterA recent update to the Kemp LoadMaster load balancer may cause failed connections for Always On VPN connections using IKEv2. SSTP VPN connections are unaffected.

Load Balancing IKEv2

When using the Kemp LoadMaster load balancer to load balance IKEv2, custom configuration is required to ensure proper operation. Specifically, the virtual service must be configured to use “port following” to ensure both the initial request on UDP port 500 and the subsequent request on UDP port 4500 are sent to the same real server. This requires the virtual service to be configured to operate at layer 7. Detailed configuration guidance for load balancing IKEv2 on the Kemp LoadMaster load balancer can be found here.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Issues with LMOS 7.2.48.0

A recent release of the Load Master Operating System (LMOS) v7.2.48.0 introduced a bug that affects UDP services configured to operate at layer 7, which includes IKEv2. This bug breaks Always On VPN connections using IKEv2, resulting in failed connections. When this occurs, the administrator may encounter an error 809 message for device tunnel or user tunnel.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Update Available

Administrators who use the Kemp LoadMaster load balancer to load balance Always On VPN IKEv2 connections and have updated to LMOS 7.2.48.0 are encouraged to update to LMOS 7.2.48.1 immediately. This latest update includes a fix that resolves broken IKEv2 load balancing for Always On VPN. Once the LoadMaster has been updated to 7.2.48.1, Always On VPN connections using IKEv2 should complete successfully.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN Load Balancing with Kemp LoadMaster in Azure

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Microsoft Intune NDES Connector Setup Wizard Ended PrematurelyA Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises to support certificate deployment for non-domain Windows 10 Always On VPN clients. 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.

Setup Wizard Ended Prematurely

When installing the Microsoft Intune Connector, the administrator may encounter a scenario where the setup wizard fails with the following error message.

“Microsoft Intune Connector Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard.”

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Cryptographic Service Provider

This error can occur if the NDES server certificate template is configured to use the Key Storage Provider cryptography service provider (CSP). When configuring the certificate template for the NDES server, the Legacy Cryptography Service Provider must be used, as shown here.

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft Intune

 

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 Load Balancing for RRAS in Azure

Always On VPN Load Balancing for RRAS in AzurePreviously I wrote about Always On VPN options for Microsoft Azure deployments. In that post I indicated that running Windows Server with the Routing and Remote Access Service (RRAS) role for VPN was an option to be considered, even though it is not a formally supported workload. Despite the lack of support by Microsoft, deploying RRAS in Azure works well and is quite popular. In fact, I recently published some configuration guidance for RRAS in Azure.

Load Balancing Options for RRAS

Multiple RRAS servers can be deployed in Azure to provide failover/redundancy or to increase capacity. While Windows Network Load Balancing (NLB) can be used on-premises for RRAS load balancing, NLB is not supported and doesn’t work in Azure. With that, there are several options for load balancing RRAS in Azure. They include DNS round robin, Azure Traffic Manager, the native Azure load balancer, Azure Application Gateway, or a dedicated load balancing virtual appliance.

DNS Round Robin

The easiest way to provide load balancing for RRAS in Azure is to use round robin DNS. However, using this method has some serious limitations. Simple DNS round robin can lead to connection attempts to a server that is offline. In addition, this method doesn’t accurately balance the load and often results in uneven distribution of client connections.

Azure Traffic Manager

Using Azure Traffic Manager is another alternative for load balancing RRAS in Azure. In this scenario each VPN server will have its own public IP address and FQDN for which Azure Traffic Manager will intelligently distribute traffic. Details on configuring Azure Traffic Manager for Always On VPN can be found here.

Azure Load Balancer

The native Azure load balancer can be configured to provide load balancing for RRAS in Azure. However, it has some serious limitations. Consider the following.

  • Supports Secure Socket Tunneling Protocol (SSTP) only.
  • Basic health check functionality (port probe only).
  • Limited visibility.
  • Does not work with IKEv2.
  • Does not support TLS offload for SSTP.

More information about the Azure Load Balancer can be found here.

Azure Application Gateway

The Azure Application Gateway can be used for load balancing RRAS SSTP VPN connections where advanced capabilities such as enhanced health checks and TLS offload are required. More information about the Azure Application Gateway can be found here.

Load Balancing Appliance

Using a dedicated Application Delivery Controller (ADC), or load balancer is a very effective way to eliminate single points of failure for Always On VPN deployments hosted in Azure. ADCs provide many advanced features and capabilities to ensure full support for all RRAS VPN protocols. In addition, ADCs offer much better visibility and granular control over VPN connections. There are many solutions available as virtual appliances in the Azure marketplace that can be deployed to provide RRAS load balancing in Azure.

Summary

Deploying Windows Server RRAS in Azure for Always On VPN can be a cost-effective solution for many organizations. Although not a formally supported workload, I’ve deployed it numerous times and it works quite well. Consider using a dedicated ADC to increase scalability or provide failover and redundancy for RRAS in Azure whenever possible.

Additional Information

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN and RRAS in Microsoft Azure

Windows 10 Always On VPN with Microsoft Azure Gateway

Always On VPN and RRAS with Single NIC

Always On VPN and RRAS with Single NICI’m commonly asked “can Windows Server with Routing and Remote Access Service (RRAS) be configured with a single network interface?” This is likely because the official Microsoft documentation references only a multihomed dual NIC configuration, leading many to believe it is a strict requirement.

Single NIC

Deploying Windows Server RRAS with a single network interface is indeed supported and works without issue. There are no functional limitations imposed by using a single network interface. All features are fully supported in this scenario. The choice to use one or two network interfaces is purely a design choice, driven by several factors such as current network configuration and security requirements.

Dual NIC

Although a single NIC configuration is fully supported, there are some important advantages associated with mulithome dual NIC deployments. The following should be considered when deciding between single NIC and dual NIC VPN configurations.

Traffic Segmentation

Having separate internal and external network connections provides logical and physical separation of trusted and untrusted network traffic. Terminating connections from Always On VPN clients on the Internet in an isolated perimeter or DMZ network yields positive security benefits.

Firewall Configuration

Using two network interfaces allows for a more restrictive Windows Firewall policy to be applied to the external interface. This reduces the exposure of running services on the RRAS server to untrusted networks. This is especially critical if the VPN server is Windows Server RRAS and it is joined to a domain.

Network Performance

For very busy RRAS servers, having two network interfaces can improve network performance. With two network interfaces, network traffic is distributed between two network adapters, reducing utilization on each interface.

Dual NIC Best Practices

When deploying an RRAS server with dual NICs, the following recommendations for network interface configuration should be followed.

IP Addressing

Each network interface must be assigned an IP address from a unique subnet. Having both NICs on the same subnet is not supported.

Default Gateway

The default gateway should be configured on the external facing network interface only. The internal interface should not be configured with a gateway. Rather, static routes to any remote internal networks should be configured.

To add a static route on a Windows Server, open an elevated PowerShell command window and run the following command.

New-NetRoute -AddressFamily IPv4 -DestinationPrefix 10.0.0.0/8 -InterfaceAlias ‘Internal’ -NextHop 172.21.12.254

DNS

For domain-joined RRAS servers, corporate DNS servers should be configured on the Internal network interface only. No DNS servers should be configured on the external interface. If the server is not joined to a domain, DNS servers can be configured on whichever interface has connectivity to the defined DNS servers.

NAT

When the RRAS server is behind a device performing Network Address Translation (NAT), the NAT should be configured to translate only the destination address (DNAT). This allows the VPN server (or load balancer for multiserver deployments) to see the client’s original source IP address, which ensures efficient traffic distribution and meaningful log data.

Client, Service, and Protocol Bindings

All unnecessary clients, services, and protocols should be unbound from the external network interface. It is recommended that only the IPv4 and IPv6 protocols be enabled on the external interface, as shown here. Again, this reduces exposure for the server to the untrusted external network.

Always On VPN and RRAS with Single NIC

Summary

The dual NIC, multihomed configuration is generally recommended for most deployments as it offers security and performance advantages over the single NIC configuration. For organizations with less demanding security requirements, a single NIC deployment can be deployed safely without compromising functionality or supportability. In addition, a single NIC deployment may be the best option when multiple networks aren’t readily available.

Additional Information

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

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Hands On Training

Always On VPN DNS Registration Update Available

Always On VPN DNS Registration Update AvailableWhen configuring Always On VPN, administrators have the option to enable DNS registration for VPN clients. When this option is set, VPN clients will register the IP address assigned to their VPN interface in the internal DNS. This allows client devices to be managed using their hostname from the internal network whenever they are connected remotely.

DNS Registration

DNS registration is enabled in one of two ways, depending on how Always On VPN client devices are managed.

Intune

When using the native Microsoft Intune UI to manage Always On VPN profiles, DNS registration can be configured by selecting Enabled next to Register IP addresses with internal DNS in the Base VPN settings section.

Always On VPN DNS Registration Update Available

ProfileXML

When using custom ProfileXML with PowerShell, SCCM, or Intune, the administrator will define the RegisterDNS element to enable DNS registration.

Always On VPN DNS Registration Update Available

Known Issues

Some users have reported unexpected behavior when DNS registration is enabled. Specifically, under some circumstances the VPN client will register the IP address of the VPN network interface along with the IP address of its public network interface (Wi-Fi, Ethernet, etc.). However, the VPN client can only be managed using the VPN interface. If the VPN client’s hostname resolves to its public IP address, manage out will fail.

This appears to happen only when Name Resolution Policy Table (NRPT) rules are defined in Intune DNS settings, or if the DomainNameInformation element is defined in ProfileXML.

Always On VPN DNS Registration Update AvailableAlways On VPN DNS Registration Update Available

Resolution

Microsoft recently released fixes for this DNS registration issue for Windows 10. The fix for this issue is included in the following updates.

Windows 10 1803 – KB4507466
Windows 10 1809 – KB4505658
Windows 10 1903 – KB4505903

Additional Configuration

After installing the update, the following registry entry must be defined on each VPN client.

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 1

To enable this setting, open an elevated PowerShell window and run the following command.

New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\’ -Name DisableNRPTForAdapterRegistration -PropertyType DWORD -Value 1 -Force

Once complete, restart the client device for the changes to take effect. After validation testing is complete, the registry entry can be deployed to Always On VPN clients using Active Directory group policy preferences or Intune.

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Updates to Improve Connection Reliability

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes

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

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)

Deploying Always On VPN with Intune using Custom ProfileXML

Deploying Always On VPN with Intune using Custom ProfileXMLWhen deploying Windows 10 Always On VPN using Microsoft Intune, administrators have two choices for configuring VPN profiles. They can use the native Intune user interface (UI) or create and upload a custom ProfileXML. The method chosen will depend on which features and settings are required.

Microsoft Intune

Intune has an intuitive user interface (UI) that can be used to configure and deploy Always On VPN profiles to Windows 10 clients. Guidance for using the UI to deploy Windows 10 Always On VPN with Microsoft Intune can be found here. However, Intune does not expose all Always On VPN settings to the administrator, which can be problematic.

Missing from Intune

At the time of this writing, the following Always On VPN settings cannot be configured natively using the Intune UI.

To implement any of the above features or settings the administrator must create and upload a custom ProfileXML.

ProfileXML

ProfileXML is a node within the VPNv2 Configuration Service Provider (CSP). When configuring Always On VPN using the Intune UI, each setting is configured individually. By contrast, the ProfileXML node includes all Always On VPN settings in a single configuration file. It can be deployed using Intune or PowerShell. Sample ProfileXML files for both user and device tunnels can be downloaded from my GitHub repository.

ProfileXML and Intune

I’ve already documented how to deploy an Always On VPN device tunnel configuration using Intune, so this post will focus on deploying the user tunnel using ProfileXML.

Once ProfileXML has been configured, open the Intune management console and follow the steps below to deploy it using Intune.

Create Profile

1. In the navigation pane click Device Configuration.
2. Click Profiles.
3. Click Create Profile.
4. Enter a descriptive name for the new VPN profile.
5. Select Windows 10 and later from the Platform drop-down list.
6. Select Custom from the Profile type drop-down list.

Custom OMA-URI Settings

1. In the Custom OMA-URI Settings blade click Add.
2. Enter a descriptive name in the Name field (this name will appear in the Windows UI on the client).
3. Enter ./User/Vendor/MSFT/VPNv2/Always%20On%20VPN/ProfileXML in the OMA-URI field. I’ve used Always On VPN as an example here, but you can use any text you like. If it includes spaces they must be escaped using %20, as shown here. Also, don’t forget to include the leading “.“.
4. Select String (XML file) from the Data type drop-down list.
5. Click the folder next to the Select a file field and select your ProfileXML file.
6. Click Ok.

Deploying Always On VPN with Intune using Custom ProfileXML

Important Note: The File contents window must show the contents of your ProfileXML. If the contents are unreadable the XML file contains encoding that will not work. If this happens, copy the contents of your ProfileXML to another new text file and upload again.

Assign Profile

Follow the steps below to assign the Always On VPN profile to the appropriate user group.

1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the target users.
4. Click Select.
5. Click Save.

Deploying Always On VPN with Intune using Custom ProfileXML

Demonstration Video

A demonstration video with guidance for deploying a Windows 10 Always On VPN user tunnel using the native Microsoft Intune UI as well as custom ProfileXML can be found here. The custom ProfileXML guidance starts at 7:52.

Additional Information

Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN Device Tunnel using PowerShell

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN LockDown Mode

Windows 10 Always On VPN Scripts and Sample ProfileXML Files on GitHub

Always On VPN SSTP Load Balancing with Kemp LoadMaster

Always On VPN SSTP Load Balancing with Kemp LoadMaster The Windows Server Routing and Remote Access Service (RRAS) includes support for the Secure Socket Tunneling Protocol (SSTP), which is a Microsoft proprietary VPN protocol that uses SSL/TLS for security and privacy of VPN connections. The advantages of using SSTP for Always On VPN is that it is firewall friendly and ensures consistent remove connectivity even behind highly restrictive firewalls.

Load Balancing SSTP

In a recent post, I described some of the use cases and benefits of SSTP load balancing as well as the offloading of TLS for SSTP VPN connections. Using a load balancer for SSTP VPN connections increases scalability, and offloading TLS for SSTP reduces resource utilization and improves performance for VPN connections. There are positive security benefits too.

Note: A comprehensive reference with detailed, prescriptive guidance for configuring the Kemp LoadMaster for Always On VPN can be found in the Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers. Download this free guide now!

Configuration

Enabling load balancing on the Kemp LoadMaster platform is fundamentally similar to load balancing HTTPS web servers. However, there are a few subtle but important differences.

Health Check

Using a standard TCP port check on the LoadMaster will not accurately reflect the health of the SSTP service running on the RRAS server. In addition, using a simple TCP port check could yield unexpected results. To ensure accurate service status monitoring, it is recommended that HTTP or HTTPS health checks be configured instead.

Real Server Check Method

Open the Kemp LoadMaster management console and follow the steps below to enable HTTP/HTTPS health checks for SSTP.

1. Expand Virtual Services in the navigation pane.
2. Click View/Modify Services.
3. Click Modify on the SSTP VPN virtual service.
4. Expand Real Servers.
5. Select HTTPS Protocol from the Real Server Check Method drop-down list. Alternatively, if TLS offload is enabled select HTTP Protocol.
6. In the URL field enter /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ and click Set URL.
7. In the Status Codes field enter 401 and click Set Status Codes.
8. Check the box next to Use HTTP/1.1.
9. Select Head from the HTTP Method drop-down list.

Always On VPN SSTP Load Balancing with Kemp LoadMaster

TLS Offload

It is generally recommended that TLS offload not be enabled for SSTP VPN. However, if TLS offload is desired, it is configured in much the same way as a common HTTPS web server. Specific guidance for enabling TLS offload on the Kemp LoadMaster load balancer can be found in the Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers. Details for configuring RRAS and SSTP to support TLS offload can be found here.

Certificates

When enabling TLS offload for SSTP VPN connections it is recommended that the public SSL certificate be installed on the RRAS server, even though TLS processing will be handled on the LoadMaster and HTTP will be used between the LoadMaster and the RRAS server. If installing the public SSL certificate on the RRAS server is not an option, additional configuration will be required. Specifically, TLS offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be found here.

Once the script has been downloaded, open an elevated PowerShell command window and enter the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

Example:

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the LoadMaster and the RRAS server will be sent in the clear using HTTP. In some instances, TLS offload is required only for traffic inspection, not performance gain. In this scenario the LoadMaster will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the LoadMaster and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the LoadMaster and the RRAS server. Using different certificates on the RRAS server and the load balancer is not supported.

Additional Information

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

Windows 10 Always On VPN SSTP Load Balancing and SSL Offload

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN ECDSA SSL Certificate Request for SSTP

Windows 10 Always On VPN SSTP Connects then Disconnects

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

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

 

%d bloggers like this: