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)

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Always On VPN Clients Prompted for Authentication when Accessing Internal ResourcesWhen deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) with client authentication certificates, the administrator may encounter a scenario in which the user can establish a VPN connection without issue, but when accessing internal resources they are prompted for credentials and receive the following error message.

“The system cannot contact a domain controller to service the authentication request. Please try again later.”

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Resolution

This can occur if one or more domain controllers in the enterprise have expired or missing domain controller authentication certificates. To ensure seamless single sign-on to internal resources, ensure that all domain controllers have a certificate issued by the internal certification authority (CA) that includes the Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2), KDC Authentication (1.3.6.1.5.2.3.5), and Smart Card Logon (1.3.6.1.4.1.311.20.2.2) Enhanced Key Usage (EKU). Administrators can duplicate the Kerberos Authentication template for this purpose.

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Additional Information

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training

 

Renew DirectAccess Self-Signed Certificates

Renew DirectAccess Self-Signed CertificatesImportant! Updated July 15, 2019 to support all versions of Windows Server including Windows Server 2012 and 2012 R2. Also added functionality to renew self-signed certificates individually.

When DirectAccess is deployed using the Getting Started Wizard (GSW), sometimes referred to as the “simplified deployment” method, self-signed certificates are created during the installation and used for the IP-HTTPS IPv6 transition technology, the Network Location Server (NLS), and for RADIUS secret encryption. Administrators may also selectively choose to use self-signed certificates for IP-HTTPS, or when collocating the NLS on the DirectAccess server. The RADIUS encryption certificate is always self-signed.

Renew DirectAccess Self-Signed Certificates

Certificate Expiration

These self-signed certificates expire 5 years after they are created, which means many DirectAccess administrators who have used this deployment option will need to renew these certificates at some point in the future. Unfortunately, there’s no published guidance from Microsoft on how to accomplish this. However, the process is simple enough using PowerShell and the New-SelfSignedCertificate cmdlet.

PowerShell Script on GitHub

The PowerShell script to renew DirectAccess self-signed certificates has been published on GitHub. You can download Renew-DaSelfSignedCertificates.ps1 here.

Important Considerations

When the IP-HTTPS and NLS scripts above are executed, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy (the RADIUS encryption certificate can be updated without impacting users). This will require connecting to the internal network locally or remotely using another VPN solution. In addition, internal clients that are not online when this change is made will be unable to access internal resources by name until they update group policy. If this happens, delete the Name Resolution Policy Table (NRPT) on the client using the following PowerShell command and reboot to restore connectivity.

Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false

Additional Information

PowerShell Recommended Reading for DirectAccess Administrators

Top 5 DirectAccess Troubleshooting PowerShell Commands

 

 

Always On VPN and Azure MFA ESTS Token Error

Always On VPN and Azure MFA ESTS Token ErrorConfiguring Multifactor Authentication (MFA) is an excellent way to ensure the highest level of assurance for Always On VPN users. Azure MFA is widely deployed and commonly integrated with Windows Server Network Policy Server (NPS) using the NPS Extension for Azure MFA. Azure MFA has a unique advantage over many other MFA providers in that it supports MFA when using Protected Extensible Authentication Protocol (PEAP). This makes Azure MFA the solution of choice for integrating with Windows 10 Always On VPN deployments using client certificate authentication, a recommended security configuration best practice.

NPS Configuration

Installing and configuring the NPS extension for Azure MFA is straightforward. Configuration guidance from Microsoft can be found here.

Connection Issues

After installing the NPS extension for Azure MFA, administrators may find that Always On VPN connections fail and the user is never challenged for authentication. The connection eventually times out and returns the following error message.

“A connection to the remote computer could not be established, so the port used for this connection was closed.”

Always On VPN and Azure MFA ESTS Token Error

In addition, the Application event log on the Windows 10 client contains an Event ID 20221 from the RasClient source that includes the following error message.

“The user [username] dialed a connection named [connection] which has failed. The error code returned on failure is 0.”

Always On VPN and Azure MFA ESTS Token Error

NPS Event Log

Reviewing the event logs on the NPS server reveals more information. The Security event log contains an Event ID 6274 from the Microsoft Windows security auditing source that includes the following error message.

“Network Policy Server discarded the request for a user. Contact the Network Policy Administrator for more information.”

Always On VPN and Azure MFA ESTS Token Error

ESTS Token Error

Digging deeper in the operational event log on the NPS server, the AuthZAdminCh log (Applications and Services Logs > Microsoft > AzureMfa > AuthZ) contains an Event ID 3 from the AuthZ source indicating an ESTS_TOKEN_ERROR message.

Always On VPN and Azure MFA ESTS Token Error

Troubleshooting ESTS Token Error

Follow the steps below to troubleshoot the ESTS_TOKEN_ERROR.

Prerequisites

Ensure that all prerequisites are met. Validate the user is being synced to Azure Active Directory and that it is properly licensed for Azure MFA.

Certificates

As part of the NPS extension configuration, a certificate is created on the NPS server that is uploaded to Azure Active Directory. To validate the certificate was created and uploaded correctly, follow the troubleshooting guidance found here.

Enterprise Applications

The Azure Multi-Factor Auth Client and the Azure Multi-Factor Auth Connector enterprise applications must be enabled to support the NPS extension for Azure MFA. To confirm they are enabled, open an elevated PowerShell command window on the server where the Azure AD Connector is installed and run the following PowerShell commands.

Import-Module MSOnline
Connect-MsolService

Get-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” | Select-Object DisplayName, AccountEnabled

Get-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” | Select-Object DisplayName, AccountEnabled

Always On VPN and Azure MFA ESTS Token Error

If either or both enterprise applications are not enabled, enable them using the following PowerShell commands.

Set-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” -AccountEnabled $True

Set-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” -AccountEnabled $True

Once complete, restart the IAS service on the NPS server using the following PowerShell command.

Restart-Service IAS -PassThru

Additional Information

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing Strategies

Deploy Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes Now Available

Always On VPN Updates to Improve Connection Reliability

Always On VPN Updates to Improve Connection ReliabilityA longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.

Recent Updates

The good news is that most of these issues have been resolved with recent updates to Windows 10 1803 and 1809. Specifically, the February 19, 2019 update for Windows 10 1803 (KB4487029) and the March 1, 2019 update for Windows 10 1809 (KB4482887) include fixes to address these known issues. Administrators are encouraged to deploy Windows 10 1803 with the latest updates applied when implementing Always On VPN. Windows 10 1809 with the latest updates applied is preferred though.

Persistent Issues

Although initial reports are favorable for these updates and based on my experience the effectiveness and reliability of Windows 10 Always On VPN is greatly improved, there have still been some reports of intermittent VPN tunnel establishment failures.

Possible Causes

During my testing, after applying the updates referenced earlier both device tunnel and user tunnel connections are established much more consistently than before the updates were applied. I did encounter some issues, however. Specifically, when coming out of sleep or hibernate, VPN connections would fail to establish. Occasionally VPN connections would fail after a complete restart.

NCSI

After further investigation it was determined that the connectivity failure was caused by the Network Connectivity Status Indicator (NCSI) probe failing, causing Windows to report “No Internet access”.

Always On VPN Updates to Improve Connection Reliability

Cisco Umbrella Roaming Client

In this instance the NCSI probe failure was caused by the Cisco Umbrella Roaming Client installed and running on the device. The Umbrella Roaming Client is security software that provides client protection by monitoring and filtering DNS queries. It operates by configuring a DNS listener on the loopback address. NCSI probes are known to fail when the DNS server is running on a different interface than is being tested.

Resolution

Microsoft released a fix for this issue in Windows 10 1709. The fix involves changing a group policy setting to disable interface binding when perform DNS lookups by the NCSI. You can enable this setting via Active Directory group policy by navigating to Computer Configuration > Administrative Templates > Network > Network Connectivity Status Indicator > Specify global DNS. Select Enabled and check the option to Use global DNS, as shown here.

Always On VPN Updates to Improve Connection Reliability

For testing purposes this setting can be enabled individual using the following PowerShell command.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force

Third-Party Software

As Always On VPN connectivity can be affected by NCSI, any third-party firewall or antivirus/antimalware solution could potentially introduce VPN connection instability. Observe NCSI operation closely when troubleshooting unreliable connections with Always On VPN.

Additional Information

Windows 10 1803 Update KB4487029

Windows 10 1809 Update KB4482887

Cisco Umbrella Roaming Client Limited Network Connectivity Warning

Network Connectivity Status Indicator (NCSI) Operation Explained

Always On VPN Device Tunnel Does Not Connect Automatically

When configuring a Windows 10 Always On VPN device tunnel, the administrator may encounter a scenario in which the device tunnel does not connect automatically. This can occur even when ProfileXML is configured with the AlwaysOn element set to “true”.

Always On VPN Device Tunnel Does Not Connect Automatically

Manual Connection

An administrator can establish a device tunnel connection manually using rasdial.exe however, indicating no issues with connectivity or authentication that would prevent a successful automatic connection.

Always On VPN Device Tunnel Does Not Connect Automatically

Root Cause

This scenario will occur when the device tunnel configuration is applied to a Windows 10 Professional edition client.

Always On VPN Device Tunnel Does Not Connect Automatically

Device Tunnel Support

The Windows 10 Always On VPN device tunnel is supported only on Windows 10 1709 or later Enterprise edition clients that are domain-joined. To ensure the device tunnel connects automatically, upgrade to Windows 10 Enterprise 1709 or later and join it to a domain.

Always On VPN Device Tunnel Does Not Connect Automatically

Source: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#device-tunnel-requirements-and-features

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Device Tunnel Missing in the Windows UI

Deleting a Windows 10 Always On VPN Device Tunnel

Always On VPN SSTP Connects then Disconnects

Always On VPN SSTP Connects then DisconnectsWhen Always On VPN clients are configured to use the Secure Socket Tunneling Protocol (SSTP) with Windows Server Routing and Remote Access Service (RRAS), administrators may encounter a scenario in which a client can establish a VPN connection using SSTP successfully, but is then disconnected immediately. The system event log contains an entry with Event ID 6 from the RasSstp source that includes the following error message.

“The SSTP-based VPN connection to the remote access server was terminated because of a security check failure. Security settings on the remote access server do not match settings on this computer. Contact the system administrator of the remote access server and relay the following information.”

Always On VPN Connect and Disconnect with SSTP

Common Causes

The two most common causes of this issue are when SSTP is configured for SSL offload, and when a VPN client is on a network where SSL inspection is taking place.

SSTP Offload

The most common cause of this issue is when SSL offload is configured for SSTP on an external load balancer or application delivery controller (ADC). To prevent interception from a Man-in-the-Middle attack, the VPN client sends the certificate hash of the SSL certificate used when the VPN connection was established. If this information does not match what is configured on the RRAS server, the connection is assumed to be compromised and the connection is immediately dropped.

SSL Inspection

Another scenario where this issue may occur is when a VPN client is behind a network device configured to perform SSL deep-packet inspection (DPI). SSTP VPN clients will be unable to connect to the VPN server in this scenario.

Resolution

When offloading SSL to another device, the RRAS server must be configured to know which SSL certificate is being presented to remote clients. This information is stored in the following registry key.

HKLM:\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters\SHA256CertificateHash

However, this registry entry requires a binary value, which makes it a challenge to configure manually. To resolve this problem, it is recommended that the same SSL certificate installed on the load balancer/ADC also be installed on the VPN server (even though SSL will be offloaded). To do this, first import the SSL certificate and private key in to the Local Computer certificate store, then open the RRAS management console and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Uncheck Use HTTP in the SSL Certificate Binding section.
  4. Select the appropriate SSL certificate from the Certificate drop-down list (click View to verify).
  5. Click Apply.

This will add the correct SSL certificate information to the registry. Next, re-enable HTTP for SSL offload by performing the following steps.

  1. Check Use HTTP in the SSL Certificate Binding section.
  2. Click Apply.

PowerShell Configuration

If the SSL certificate cannot be installed on the VPN server, or to automate this configuration across multiple servers remotely, download and run the Enable-SstpOffload PowerShell script from my GitHub repository here and run the following command.

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

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Additional Information

Windows 10 Always On VPN Load Balancing and SSL Offload

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

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

 

Troubleshooting Always On VPN Error Code 809

When testing an Always On VPN connection, the administrator may encounter a scenario where the VPN client fails to connect to the VPN server. On the Windows 10 client the error message states 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

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 named [connection name] with has failed. The error code returned on failure is 809.”

Troubleshooting Always On VPN Error Code 809

Connection Timeout

The error code 809 indicates a VPN timeout, meaning the VPN server failed to respond. Often this is related directly to network connectivity, but sometimes other factors can come in to play.

Troubleshooting VPN Error Code 809

When troubleshooting VPN error code 809 the following items should be carefully checked.

  • Name Resolution – Ensure the VPN server’s public hostname resolves to the correct IP address.
  • Firewall Configuration – Confirm the edge firewall is configured properly. Inbound TCP port 443 is required for the Secure Socket Tunneling Protocol (SSTP) and inbound UDP ports 500 and 4500 are required for the Internet Key Exchange version 2 (IKEv2) protocol. Make sure that any NAT rules are forwarding traffic to the correct server.
  • Load Balancer Configuration – If VPN servers are located behind a load balancer, make certain that virtual IP address and ports are configured correctly and that health checks are passing. For IKEv2 specifically, it is crucial that UDP ports 500 and 4500 be delivered to the same backend server. This commonly requires custom configuration. For example, on the KEMP LoadMaster the administrator will configure “port following”. On the F5 BIG-IP a  custom “persistence profile” must be configured. On the Citrix NetScaler a “persistency group” must be defined.

IKEv2 Fragmentation

VPN error code 809 can also be caused by IKE fragmentation when using the IKEv2 VPN protocol. During IKEv2 connection establishment, payload sizes may exceed the IP Maximum Transmission Unit (MTU) for the network path between the client and server. This causes the IP packets to be fragmented. However, it is not uncommon for intermediary devices (routers, NAT devices, or firewalls) to block IP fragments. When this occurs, a VPN connection cannot be established. However, looking at a network trace of the connection attempt, the administrator will see that the connection begins but subsequently fails.

Troubleshooting Always On VPN Error Code 809

Enable IKEv2 Fragmentation Support

The IKEv2 protocol includes support for fragmenting packets at the IKE layer. This eliminates the need for fragmenting packets at the IP layer. IKEv2 fragmentation must be configured on both the client and server.

Client

IKEv2 fragmentation was introduced in Windows 10 1803 and is enabled by default. No client-side configuration is required.

Server

IKEv2 is commonly supported on many firewall and VPN devices. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, IKEv2 fragmentation was introduced in Windows Server 1803 and is also supported in Windows Server 2019. It is enabled via a registry key. The following PowerShell command can be used to enable IKEv2 fragmentation on supported servers.

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

Validation

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 and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Hands-On Training Classes

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

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

%d bloggers like this: