Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune

Always On VPN Device Tunnel and Custom Cryptography Native Support Now in IntuneMicrosoft recently announced support for native Windows 10 Always On VPN device tunnel configuration in Intune. Previously administrators had to use the complicated and error-prone custom XML configuration to deploy the Windows 10 Always On VPN device tunnel to their clients. That is no longer required with this recent Intune update. In addition, administrators may now specify custom cryptography settings for IPsec Security Association (SA) parameters for IKEv2 for both device tunnel and user tunnel connections. This effectively eliminates the requirement to use custom ProfileXML for most deployment scenarios.

Device Tunnel Configuration in Intune

Follow the steps below to configure and deploy a Windows 10 Always On VPN device tunnel using the native Intune user interface.

Create Profile

1. Open the Microsoft Endpoint Manager admin center (devicemanagement.microsoft.com).
2. Navigate to Devices > Configuration Policies.
3. Click Create profile.
4. Choose Windows 10 and later from the Platform drop-down list.
5. Choose VPN from the Profile drop-down list.
6. Click Create.

Profile Settings

Proceed with the profile configuration as you would normally, providing the VPN connection name, VPN server name(s), and choosing the option to register IP addresses with internal DNS. Next use the following steps to define a device tunnel connection and specify custom cryptography for IPsec SA parameters for IKEv2.

Configure a Device Tunnel

1. Select IKEv2 from the Connection type drop-down list.
2. Click Enable in the Always On section.
3. Select Machine Certificates from the Authentication method section.
4. If the computer certificate is provisioned using Intune, select the client authentication certificate (not required if the computer certificate is provisioned using on-premises Active Directory).
5. Click Enable in the Device Tunnel section.

Define Custom Cryptography

Follow the steps below to implement minimum security baseline cryptography settings for IKEv2.

IKE Security Association Parameters

1. Select AES-128 from the Encryption algorithm drop-down list.
2. Select SHA2-256 from the Integrity check algorithm drop-down list.
3. Select 14 from the Diffie-Hellman group drop-down list.

Child Security Association Parameters

1. Select CBC-AES-128 from the Cipher transform algorithm drop-down list.
2. Select HMAC-SHA256-128 from the Authentication transform algorithm drop-down list.
3. Select 14 from the Perfect forward secrecy (pfs) group drop-down list.

Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune

Important Note: The IPsec security association parameters outlined above are the minimum recommend security baseline for IKEv2 and are compatible with all supported versions of Windows Server RRAS. It is recommended that authenticated cipher suites (GCM) be used whenever possible. However, GCM ciphers are not supported for encryption prior to Window Server 1803. Administrators should review these security settings and adjust the parameters to meet their specific security requirements.

Server Configuration

When defining custom cryptography settings for IKEv2 for device tunnel deployment, it is critical that the server be configured using identical parameters. Failure to use matching cryptography settings on the client and server will result in error code 13868, which indicates an IPsec policy mismatch.

A PowerShell script to configure IKEv2 security association parameter minimum security baselines on the RRAS server as outlined above can be found here. The commands to make these changes on the Azure VPN gateway can be found in this post.

Caveats

While Microsoft has made great strides to ensure better support for Always On VPN configuration using the native Intune UI, there are a few critical settings are still not supported. In these scenarios the administrator must deploy Always On VPN using custom XML, as described here and here.

Custom Cryptography

IKEv2 custom cryptography settings are only exposed when IKEv2 is selected as the connection type. It appears that defining custom cryptography settings for IKEv2 when the connection type is set to Automatic is not supported at this time. If you wish to specify the Automatic connection type and use custom cryptography settings for IKEv2 you will need to deploy the device tunnel using custom ProfileXML.

IPv6

IPv6 routing when configuring split tunneling for Always On VPN in Intune is not supported.

Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune

Additional Information

Windows 10 Always On VPN Policy Mismatch Error

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Always On VPN Bug in Windows 10 2004

Always On VPN Bug in Windows 10 2004While performing Always On VPN evaluation testing with the latest release of Windows 10 (2004), a bug was discovered that may result in failed VPN connections, but only under certain conditions. Specifically, the failure occurs when both the device tunnel and user tunnel are configured on the same client, and the user tunnel is configured to use IKEv2 exclusively.

Error 829

After upgrading to Windows 10 2004, and when the device tunnel and user tunnel are both deployed and the user tunnel is configured to use IKEv2, the administrator will notice that if the device tunnel connection is established, the user tunnel connects successfully but is then terminated abruptly with error code 829.

Always On VPN Bug in Windows 10 2004

Note: This can happen in reverse if the user tunnel is established before the device tunnel for some reason. In this scenario the user tunnel would be connected but attempts to establish the device tunnel would result in failure.

Error 619

If the user tunnel connection is initiated using rasdial.exe or rasphone.exe, the error code returned is 619.

Always On VPN Bug in Windows 10 2004

Always On VPN Bug in Windows 10 2004

Workaround

The workaround for this issue is to either use a single tunnel, or if both user tunnel and device tunnel are required, configure the user tunnel to use the SSTP VPN protocol instead of IKEv2.

Additional Information

Windows 10 Always On VPN Device Tunnel Only Deployment Considerations

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