Always On VPN and IKEv2 Fragmentation

The IKEv2 protocol is a popular choice when designing an Always On VPN solution. When configured correctly it provides the best security compared to other protocols. The protocol is not without some unique challenges, however. IKEv2 is often blocked by firewalls, which can prevent connectivity. Another lesser know issue with IKEv2 is that of fragmentation. This can result in failed connectivity that can be difficult to troubleshoot.

IP Fragmentation

IKEv2 uses UDP for transport, and typically most packets are relatively small. The exception to this is when authentication takes place, especially when using client certificate authentication. The problem is further complicated by long certificate chains and by RSA keys, especially those that are greater than 2048 bit. If the payload exceeds 1500 bytes, the IP packet will have to be broken in to smaller fragments to be sent over the network. If an intermediary device in the path is configured to use a smaller Maximum Transmission Unit (MTU), that device may fragment the IP packets.

IP Fragmentation and Firewalls

Many routers and firewalls are configured to drop IP fragments by default. When this happens, IKEv2 communication may begin initially, but subsequently fail. This typically results in an error code 809 with a message stating the following.

“Can’t connect to [connection name]. The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g. firewalls, NAT, routers, etc.) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.”

Always On VPN and IKEv2 Fragmentation

Troubleshooting

When troubleshooting potential IKEv2 fragmentation-related connection failures, a network trace should be taken of the connection attempt on the client. Observe the packet sizes during the conversation, especially IKE_AUTH packets. Packet sizes exceeding the path MTU will have to be fragmented, as shown here.

Always On VPN and IKEv2 Fragmentation

Measuring Path MTU

Measuring the path MTU between the client and server can be helpful when troubleshooting fragmentation related issues. The mtupath.exe utility is an excellent and easy to use tool for this task. The tool can be downloaded here.

Always On VPN and IKEv2 Fragmentation

IKEv2 Fragmentation

To address the challenges with IP fragmentation and potential connectivity issues associated with network devices dropping fragmented packets, the IKEv2 protocol itself can be configured to perform fragmentation at the IKE layer. This eliminates the need for IP layer fragmentation, resulting in better reliability for IKEv2 VPN connections.

Both the server and the client must support IKEv2 fragmentation for this to occur. Many firewall and VPN vendors include support for IKEv2 fragmentation. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, the feature was first introduced in Windows Server 1803 and is supported in Windows Server 2019. Windows 10 clients support IKEv2 fragmentation beginning with Windows 10 1803.

Enabling IKEv2 Fragmentation

Windows 10 clients support IKEv2 fragmentation by default. However, it must be enabled on the server via the registry. The following PowerShell command will enable IKEv2 fragmentation support on Windows Server 1803 and later.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\” -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

A PowerShell script to implement IKEv2 fragmentation can be found on my GitHub here.

Validation Testing

Once IKEv2 fragmentation is configured on the VPN server, a network capture will reveal the IKE_SA_INIT packet now includes the IKEV2_FRAGMENTATION_SUPPORTED notification message.

Always On VPN and IKEv2 Fragmentation

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

RFC 7383 – IKEv2 Message Fragmentation

IEA Software MTU Path Scan Utility

Windows 10 Always On VPN Hands-On Training Classes

Always On VPN IKEv2 Connection Failure Error Code 800

Always On VPN administrators may encounter a scenario in which Windows 10 clients are unable to establish an IKEv2 VPN connection to a Windows Server Routing and Remote Access Service (RRAS) server or a third-party VPN device under the following conditions.

  1. The VPN connection is configured using ProfileXML.
  2. ProfileXML includes the <CryptographySuite> element.
  3. The VPN server is configured to use a custom IPsec policy.
  4. The VPN server supports only IKEv2.
  5. The <NativeProtocolType> in ProfileXML is set to Automatic.

When these specific conditions are met, the client will be unable to connect to the VPN server using IKEv2. The error message states:

The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly.

Always On VPN IKEv2 VPN Connection Failure Error Code 800

In addition, the event log will include an error message from the RasClient source with event ID 20227 that includes the following error message.

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

Always On VPN IKEv2 VPN Connection Failure Error Code 800

A manually configured VPN connection using IKEv2 will connect successfully under these same conditions, however.

IKEv2 Error Code 800

Error code 800 translates to ERROR_AUTOMATIC_VPN_FAILED, which is somewhat ambiguous. The error description is:

Unable to establish the VPN connection. The VPN server may be unreachable, or security parameters may not be configured properly for this connection.

Digging Deeper

A network trace of the IKEv2 VPN connection reveals the true source of the problem, which is a failure of the client and server to successfully negotiate an IKEv2 security association (SA). During the SA initiation process, the parameters offered by the client are unacceptable to the server, resulting in a NO_PROPOSAL_CHOSEN notification being returned by the server.

Always On VPN IKEv2 VPN Connection Failure Error Code 800

Custom Cryptography Settings Ignored

It appears that the Always On VPN connection ignores the custom cryptography settings defined in the CryptographySuite element in ProfileXML. However, this only occurs when the NativeProtocolType is set to Automatic. Presumably, this is a bug. 🙂

Workaround

As a workaround, set the NativeProtocolType to IKEv2. When NativeProtocolType is set to IKEv2, the VPN connection recognizes the IKEv2 parameters defined in the CryptographySuite element and the VPN connection will be established successfully.

Additional Information

Always On VPN IKEv2 Security Configuration

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer

Always On VPN IKEv2 Security Configuration

Always On VPN IKEv2 Security ConfigurationWhen deploying Windows 10 Always On VPN, many administrators choose the Internet Key Exchange version 2 (IKEv2) protocol to provide the highest level of security and protection for remote connections. However, many do not realize the default security parameters for IKEv2 negotiated between a Windows Server running the Routing and Remote Access Service (RRAS) and a Windows 10 VPN client are far less than ideal from a security perspective. Additional configuration on both the server and the client will be required to ensure adequate security and protection for IKEv2 VPN connections.

Windows 10/11 and RRAS IKEv2 Defaults

In their default configuration, a Windows 10 or 11 client connecting to a Windows Server running RRAS will negotiate an IKEv2 VPN connection using the following IPsec security parameters.

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

This information can be obtained by opening an elevated PowerShell command window and running the following command.

Get-NetIPsecMainModeSA | Select-Object -First 1

Always On VPN IKEv2 Security Configuration

This can also be confirmed by viewing a network trace as shown here.

Always On VPN IKEv2 Security Configuration

These IPsec security parameters might have been acceptable in the 90’s, but they certainly are not today. 🙂

Improving IKEv2 Security

To provide a baseline level of protection to meet today’s requirements for security and privacy for IKEv2 VPN connections, the following are the minimum recommended IPsec security parameters.

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

RRAS Custom IPsec Policy

To implement these recommended security baselines for IKEv2 on a Windows Server running RRAS it will be necessary to define a custom IPsec security policy. To do this, open an elevated PowerShell command window and run the following commands on each RRAS server.

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

Restart the Remote Access Management service for the changes to take effect.

Restart-Service RemoteAccess -PassThru

Always On VPN IKEv2 Security Configuration

Note: A PowerShell script to implement the custom IPsec security policy settings shown above can be downloaded here.

Root Certificate

It is essential to define the root certification authority for which to accept IPsec security associations (SAs) for IKEv2 VPN connections. Without this setting configured, the VPN server will accept IPsec SAs using any certificate issued by a CA defined in its Trusted Root Certification Authorities certificate store. To configure this setting, open an elevated PowerShell window and run the following commands.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru
Restart-Service RemoteAccess -PassThru

Note: A PowerShell script to implement the root certificate name to accept can be found here.

CRL Checking

By default, RRAS does not enforce CRL checks for IKEv2 VPN connections. Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter (guidance above) and set the following registry key to enable this functionality.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force
Restart-Service RemoteAccess -PassThru

Note: A PowerShell script to configure root certificate settings and enforce CRL checking can be downloaded here.

Windows 10 Client Settings

The IPsec policy must match on both the server and the client for an IKEv2 VPN connection to be successful. Unfortunately, none of the IKEv2 IPsec security association parameters proposed by default on Windows 10 clients use 2048-bit keys (DH Group 14), so it will be necessary to define a custom IPsec security policy on the client to match the settings configured on the server.

To configure a matching IPsec security policy on an individual Windows 10 VPN client, open an elevated PowerShell command window and run the following command.

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Always On VPN IKEv2 Security Configuration

Restore Defaults

In the process of testing, it may be necessary to restore the default IKEv2 configuration on both the client and the server. This can be accomplished by running the following PowerShell commands.

Server – Set-VpnServerConfiguration -RevertToDefault

Client – Set-VpnConnectionIPsecConfiguration -ConnectionName [connection_name] -RevertToDefault -Force

Always On VPN XML Settings

To implement a custom IPsec policy using the minimum recommended security settings for an Always On VPN connection using IKEv2, add the following settings to your ProfileXML.

<VPNProfile>
 <NativeProfile>
  <CryptographySuite>
   <AuthenticationTransformConstants>SHA256128</AuthenticationTransformConstants>
   <CipherTransformConstants>AES128</CipherTransformConstants>
   <EncryptionMethod>AES128</EncryptionMethod>
   <IntegrityCheckMethod>SHA256</IntegrityCheckMethod>
   <DHGroup>Group14</DHGroup>
   <PfsGroup>PFS2048</PfsGroup>
  </CryptographySuite>
 </NativeProfile>
</VPNProfile>

Why Not AES 256?

In the examples above you’ll notice that I’ve chosen to use AES128 and not AES256. This is by design, as AES256 does not provide any practical additional security in most use cases. Details here.

Enhanced Security and Performance

The settings outlined above are considered the minimum security baseline configuration for Always On VPN with IKEv2. These setting are considered secure by today’s standard and offer maximum interoperability with non-Microsoft VPN gateways.

To further improve security and performance for IKEv2, consider implementing Elliptic Curve Cryptography (EC) certificates and using Galois Counter Mode (GCM) cipher suites such as GCMAES128 for authentication and encryption.

Additional Information

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Connection Failure Error Code 800

Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer