Always On VPN IPsec Root Certificate Configuration Issue

Always On VPN Device Tunnel Status IndicatorWhen configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found here.

Multiple Root Certificates

Administrators may find that when they try to define a specific root certification authority, the setting may not be implemented as expected. This commonly occurs when there is more than one root certificate in the Trusted Root Certification Authorities store for the same PKI.

Always On VPN IPsec Root Certificate Configuration Issue

Certificate Selection

When running the PowerShell command Set-VpnAuthProtocol to define the root certification authority, PowerShell may ignore the administrator-defined certificate and choose a different one, as shown here. This will result in failed IPsec VPN connections from Windows 10 Always On VPN clients using IKEv2.

Always On VPN IPsec Root Certificate Configuration Issue

Certificate Publishing

This issue can occur when root certification authority certificates are published using Active Directory group policy. It appears that Windows prefers Active Directory group policy published certificates over those published directly in the Certification Authorities Container in Active Directory. To resolve this issue, remove any group policy objects that are publishing root certification authority certificates and ensure those root certificates are published in the Certification Authorities container in Active Directory.

PowerShell Script

A PowerShell script to configure this setting that can be found in my Always On VPN GitHub repository here. I have updated this script to validate the defined root certification authority certificate and warn the user if it does not match.

Additional Information

Set-Ikev2VpnRootCertificate.ps1 PowerShell script on GitHub

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Certificate Requirements

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