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

 

Always On VPN Load Balancing with Kemp in Azure

Always On VPN Load Balancing with Kemp in AzureIn a recent post I discussed options for load balancing Windows Server Routing and Remote Access Service (RRAS) in Microsoft Azure for Always On VPN. There are many choices available to the administrator, however the best alternative is to use a dedicated Application Delivery Controller (ADC), or load balancer. The Kemp LoadMaster load balancer is an excellent choice here, as it is easy to configure and deploy. It is also very cost effective and offers flexible licensing plans, including a metered licensing option.

Deploy LoadMaster in Azure

To provision a Kemp LoadMaster load balancer in Microsoft Azure, open the Azure management console and perform the following steps.

1. Click Create Resource.
2. Enter LoadMaster in the search field.
3. Click on LoadMaster Load Balancer ADC Content Switch.

Always On VPN Load Balancing with Kemp in Azure

4. Choose an appropriate license model from the Select a software plan drop-down list.
5. Click Create.

Prepare Azure Instance

Follow the steps below to provision the Azure VM hosting the Kemp LoadMaster load balancer.

1. Choose an Azure subscription to and resource group to deploy the resources to.
2. Provide instance details such as virtual machine name, region, availability options, and image size.
3. Select an authentication type and upload the SSH private key or provide a username and password.
4. Click Next:Disks >.

Always On VPN Load Balancing with Kemp in Azure

5. Select an OS disk type.
6. Click Next: Networking >.

Always On VPN Load Balancing with Kemp in Azure

7. Select a virtual network and subnet for the load balancer.
8. Create or assign a public IP address.
9. Click Review + create.

Always On VPN Load Balancing with Kemp in Azure

LoadMaster Configuration

Once the virtual machine has been provisioned, open a web browser and navigate to the VM’s internal IP address on port 8443 to accept the licensing terms.

Always On VPN Load Balancing with Kemp in Azure

Next, log in with your Kemp ID and password to finish licensing the appliance.

Always On VPN Load Balancing with Kemp in Azure

Finally, log in to the appliance using the username ‘bal’ and the password provided when the virtual machine was configured.

Always On VPN Load Balancing with Kemp in Azure

Azure Network Security Group

A Network Security Group (NSG) is automatically configured and associated with the LoadMaster’s network interface when the appliance is created. Additional inbound security rules must be added to allow VPN client connectivity.

In the Azure management console open the properties for the LoadMaster NSG and follow the steps below to configure security rules to allow inbound VPN protocols.

SSTP

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 443 in the Destination port ranges field.
7. Select the TCP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.

Always On VPN Load Balancing with Kemp in Azure

IKEv2

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 500 in the Destination port ranges field.
7. Select the UDP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.
12. Repeat the steps below for UDP port 4500.

Always On VPN Load Balancing with Kemp in Azure

Load Balancing SSTP and IKEv2

Refer to the following posts for detailed, prescriptive guidance for configuring the Kemp LoadMaster load balancer for Always On VPN load balancing.

Always On VPN SSTP Load Balancing with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing with the Kemp LoadMaster

Always On VPN Load Balancing Deployment Guide for the Kemp LoadMaster

Summary

Although Windows Server RRAS is not a formally supported workload in Azure, it is still a popular and effective solution for Always On VPN deployments. The Kemp LoadMaster load balancer can be deployed quickly and easily to provide redundancy and increase scalability for larger deployments.

Additional Information

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

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

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

Deploying the Kemp LoadMaster Load Balancer in Microsoft Azure

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 in Azure

Always On VPN and RRAS in AzureWhen deploying Windows 10 Always On VPN, it may be desirable to host the VPN server in Microsoft’s Azure public cloud. Recently I wrote about Always On VPN deployment options in Azure, and in that post I indicated that deploying Windows Server and the Routing and Remote Access Service (RRAS) was one of those options. Although not formally supported by Microsoft, RRAS is often deployed in Azure because it is cost-effective, easy to manage, and provides flexible scalability.

Supportability

It’s important to state once again that although it is possible to successfully deploy Windows Server with RRAS in Azure to support Always On VPN, as of this writing it is not a formally supported workload. If the administrator makes the decision to deploy RRAS in Azure, they must also accept that Microsoft may refuse to assist with troubleshooting in this specific deployment scenario.

Always On VPN and RRAS in Azure

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

Azure Prerequisites

The configuration of RRAS is identical to on-premises, with a few additional steps required by Azure infrastructure.

Windows Server

RRAS can be configured on any Windows Server virtual machine supported in Microsoft Azure. As with on-premises deployments, Server GUI and Core are supported. Domain-join is optional. The server can be deployed with one network interface or two.

Public IP

A public IP address must be assigned to the VPN server’s external network interface, or the internal interface if the VPN server is configured with a single network adapter. The IP address can be static or dynamic. When using a dynamic IP address, configure a CNAME record in DNS that points to the name configured for the IP address in Azure. If using a static IP address, an A host record can be configured pointing directly to the IP address.

Network Security Group

A Network Security Group (NSG) must be configured and assigned to the VPN server’s external or public-facing network interface that allows the following protocols and ports inbound.

  • TCP port 443 (SSTP)
  • UDP port 500 (IKEv2)
  • UDP port 4500 (IKEv2 NAT traversal)

RRAS in Azure

Below are the infrastructure requirements for supporting Windows Server RRAS VPN in Azure.

Client IP Subnet

Static IP address pool assignment must be used with RRAS. Using DHCP for VPN client IP address assignment in Azure is not supported and will not work. The IP subnet assigned to VPN clients by RRAS must be unique and not overlap with any existing Azure VNet subnets. If more than one VPN server is deployed, each server should be configured to assign a unique subnet for its clients.

IP Forwarding

IP forwarding must be enabled on the VPN server’s internal network interface. Follow the steps below to enable IP forwarding.

1. In the Azure portal, open the properties page for the internal network interface for the VPN server.
2. Click IP configurations in the navigation pane.
3. Click Enabled next to IP forwarding.
4. Click Save.

Always On VPN and RRAS in Azure

Routing

Azure must be configured to route IP traffic from VPN clients back to the VPN server. Follow the steps below to create and assign a routing table in Azure.

1. Click Create Resource.
2. Enter “Route Table” in the search field and press Enter.
3. Click Route Table.
4. Click Create.
5. Enter a descriptive name for the route table in the Name field.
6. Choose an appropriate subscription from the Subscription drop-down list.
7. Select the resource group where the VPN server(s) reside.
8. Select the best location to deploy the route table resource from the Location drop-down list.
9. If the administrator wants to have the VPN client IP subnet route information published automatically, select Enabled for Virtual network gateway route propagation.
10. Click Create.

Always On VPN and RRAS in Azure

Once complete, follow the steps below to define the route for VPN clients.

1. Open the properties page for the route table.
2. Click Routes in the navigation pane.
3. Click Add.
4. Enter a descriptive name in the Route name filed.
5. Enter the IP subnet assigned to VPN clients in the Address prefix field.
6. Select Virtual appliance from the Next hop type drop-down list.
7. Enter the IPv4 address assigned to the VPN server’s internal network interface in the Next hop address field.
8. Click Ok.
9. Repeat the steps above for each VPN server configured in Azure.

Always On VPN and RRAS in Azure

Finally, follow the steps below to assign the route table to an Azure VNet subnet.

1. Open the properties page for the route table.
2. Click Subnets in the navigation pane.
3. Click Associate.
4. Click Virtual network.
5. Choose the appropriate Azure VNet.
6. Click Subnet.
7. Choose an Azure VNet subnet to assign the route table to.
8. Click Ok.
9. Repeat the steps above to assign the route table to any Azure VNet subnet that must be accessible by VPN clients. If VPN clients need access to on-premises resources via Azure site-to-site gateway, assign the route table to the Azure VPN gateway subnet.

Always On VPN and RRAS in Azure

Note: Azure only supports the assignment of one route table per subnet. If a route table is currently assigned, the VPN client subnet route can be added to an existing route table, if necessary.

Summary

Administrators have many choices when it comes to support Always On VPN connections hosted in Azure. RRAS on Windows Server can be an effective solution, assuming you can live without formal support. If having a formally supported solution is a hard requirement, consider deploying Always On VPN using the native Azure VPN gateway or another third-part Network Virtual Appliance (NVA).

Additional Information

Windows 10 Always On VPN with Azure Gateway

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Multisite with Azure Traffic Manager

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

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

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

%d bloggers like this: