Always On VPN Intermittent 13801 Error

Always On VPN error 13801 is common when establishing an IKEv2 VPN connection. Typically, the issue is related to a configuration error or a problem with certificate deployment. However, administrators may encounter the 13801, an IKE authentication error, intermittently. Configuration errors are binary. If there is a misconfiguration, IKEv2 never works at all. However, a configuration error seems unlikely since the connection works occasionally yet fails at other times.

Client Authentication

The minimum application policy (Enhanced Key Usage, or EKU) requirement for the device authentication certificate for IKEv2 is Client Authentication (1.3.6.1.5.5.7.3.2). When intermittent 13801 errors occur, administrators may find multiple certificates in the local computer certificate store with the Client Authentication EKU issued by different certificate authorities. Commonly, Intune-managed Windows devices may include several certificates with Client Authentication.

Certificate Selection

When Windows attempts to establish an Always On VPN IKEv2 connection, and there are multiple certificates in the local computer certificate with Client Authentication defined, Windows must choose one certificate to use for the connection. If Windows chooses incorrectly, you will receive the 13801 IKE authentication failure error. If Windows selects the right one, the connection succeeds.

Resolution

There are several ways to resolve this issue. The best way is to update the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). When Windows encounters multiple client authentication certificates in the local computer certificate store, it will prefer any certificate with the IP security IKE intermediate application policy for IKEv2 VPN connections. Including the IP security IKE intermediate application policy on the Always On VPN device authentication certificate ensures proper certificate selection when multiple client authentication certificates are present.

Note: This change must be made to the Intune certificate enrollment template when using Intune with PKCS or SCEP.

Certificate Template

To update an existing Always On VPN device authentication certificate to include the IP security IKE intermediate application policy, open the certificate templates management console (certtmpl.msc) and perform the following steps.

  1. Right-click the VPN device authentication certificate template and choose Properties.
  2. Select the Extensions tab.
  3. Click on Application Policies.
  4. Click Edit.
  5. Click Add.
  6. Select the IP security IKE intermediate application policy.
  7. Click Ok.
  8. Click Ok.
  9. Click Ok.

Once complete, any certificates issued after this change is applied will now include the IP security Ike intermediate application policy.

Force Renewal

Administrators may wish to update all certificates immediately rather than wait until they renew to receive the new setting. The course of action depends on how certificates are issued.

On-Premises

When issuing certificates using Active Directory Certificate Services (AD CS) on-premises, right-click the Always On VPN device authentication certificate template and choose Reenroll All Certificate Holders. This will force all domain-joined clients with Autoenroll permissions on the template to renew their certificate on their next enrollment cycle, regardless of the certificate’s lifetime.

Intune

Follow the steps below to force re-enrollment for all certificate holders when deploying certificates using Intune.

SCEP Add the IP Security IKE Intermediate application policy to the Intune VPN policy. After this change is applied, Intune will reenroll all endpoints.

PKCS – A new Intune device configuration policy must be created that includes the IP security IKE intermediate application policy. Assign the new policy and remove the old one to replace all certificates.

PowerShell

It’s also possible to resolve this issue using PowerShell. Administrators can use the Set-VpnConnection PowerShell cmdlet to select a certificate based on the root certification authority (CA) or a specific custom application policy defined on the Always On VPN device authentication certificate. Be sure to add the -AllUserConnection switch when working with the device tunnel.

Root CA

Open a PowerShell command window and run the following command.

$RootCA = Get-Child-Item -Path Cert:\LocalMachine\My\<thumbprint of root CA certificate>
Set-VpnConnection -Name <name of VPN profile> -MachineCertificateIssuerFilter $RootCA

Application Policy

Open a PowerShell command window and run the following command.

Set-VpnConnection -Name <name of VPN profile> -MachineCertificateEKUFilter <OID>

Note: When using a custom application policy Windows will return a warning message stating the EKU could not be validated. You can safely disregard this warning.

Intune Remediation

While running PowerShell commands locally might be helpful for troubleshooting and targeted evaluation testing, deploying settings via PowerShell at scale is challenging. For those organizations managing their devices using Microsoft Intune, I’ve published a few detection and remediation scripts on GitHub to perform these tasks.

Summary

The intermittent Always On VPN 13801 IKE authentication credentials are unacceptable error message is best resolved by updating the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). Although using PowerShell also works, it doesn’t scale effectively. SCCM or Intune remediations can help, but I’d encourage you to update the certificate template as best practice instead.

Additional Information

Troubleshooting Always On VPN Error 13801

Troubleshooting Always On VPN Error 13806

Troubleshooting Always On VPN Error 13868

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

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

Organizations migrating on-premises applications, data, and infrastructure to the cloud may also consider terminating Always On VPN connections there. Using one of the native Azure VPN services might be compelling at first glance. After all, having an Azure-managed VPN gateway service sounds intuitive. However, some severe limitations exist for using Azure VPN services for Always On VPN deployments.

Azure VPN Gateway

The following are limitations for Always On VPN with Azure VPN gateway.

Authentication Methods

Azure VPN gateway supports both EAP and machine certificate authentication. However, it can only support one authentication method at a time. With only EAP or certificate authentication, administrators must choose between a device or user tunnel. A single Azure VPN gateway cannot support both at the same time. For native Entra ID joined devices, this is not a problem. However, for native on-premises Active Directory or hybrid Entra ID joined devices, this is a problem, as the device tunnel is essential in these scenarios.

Note: Technically speaking, administrators could deploy another Azure VPN gateway to work around this limitation. However, Azure limits VPN gateway deployments to one per virtual network. This requires administrators to deploy a second VPN gateway in a separate virtual network, which then requires virtual network peering to be enabled, complicating the configuration greatly.

SSTP

Although the Azure VPN gateway supports SSTP, it is, unfortunately, a second-class citizen. Today, all SKUs of the Azure VPN gateway are limited to just 128 SSTP connections (256 in active/active mode). There is currently no way to increase this. If more than 256 connections are required, you must use IKEv2.

RADIUS

In addition, there is currently no option to change the default timeout value (30 seconds) for RADIUS authentication requests. This short timeout value presents a challenge when using MFA with the NPS extension or with Azure Conditional Access, as users may be unable to respond to the push notification before the timeout expires, resulting in failed authentication attempts.

In addition, Azure does not support routing traffic to on-premises RADIUS servers over ExpressRoute connections. In this scenario, administrators must route RADIUS traffic to on-premises servers over a site-to-site connection.

Geographic Redundancy

Geographic redundancy using Azure Traffic Manager (or another global server load balancer) with two or more gateways is not supported when using the Azure VPN gateway. Azure manages the certificate used on the gateway, which includes a certificate with the subject name of the individual gateway. There is no option to supply a custom certificate with a global hostname in the subject, which is required to support geographic redundancy. With that, administrators are limited to the redundancy provided natively by the Azure VPN gateway.

IPv6

Azure does not support Azure VPN gateway in a virtual network that includes IPv6 addressing.

Azure Virtual WAN

Azure Virtual WAN includes many of the same limitations as the Azure VPN gateway, in addition to the following.

SSTP

Unlike the Azure VPN gateway, there is no support for SSTP in Azure Virtual WAN.

IPv6

IPv6 is not currently supported at all in Azure Virtual WAN.

Summary

Intuitively, it seems that leveraging native Azure VPN gateway services would be ideal. However, due to the limitations outlined in this article, administrators must decide carefully if any of these prevent adoption in their environment. Although not formally supported, many organizations deploy Windows Server Routing and Remote Access (RRAS) servers in Azure to address these limitations.

Additional Information

Always On VPN Options for Azure Deployments

Always On VPN with Azure Gateway

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN and RRAS in Azure

What is Azure VPN Gateway?

What is Azure Virtual WAN?

Always On VPN October 2023 Security Updates

Once again, it’s time to patch! After several quiet months, there are a few crucial updates Always On VPN administrators will want to get deployed soon. Thankfully, the impact of the security updates related to Always On VPN is low this time, as there is only one Remote Code Execution (RCE) vulnerability, and it’s for a legacy protocol that should be in limited use today.

IKEv2

CVE-2023-36726 addresses a security vulnerability in Windows Internet Key Exchange (IKE) that can lead to privilege escalation. An attacker who successfully exploits this vulnerability can elevate privileges to that of the local SYSTEM.

L2TP

This month’s update discloses several Layer Two Tunneling Protocol (L2TP) vulnerabilities. The following CVEs all address a vulnerability where an attacker can send a specially crafted protocol message to a Windows Routing and Remote Access Service (RRAS) server, which could lead to remote code execution on the server.

Mitigation

The impact of the L2TP security vulnerabilities should be minimal in most organizations. L2TP is a legacy VPN protocol not commonly used for Always On VPN. However, misconfiguration can leave vulnerable RRAS servers exposed. Administrators must ensure that inbound UDP port 1723 is not open from the Internet. In addition, L2TP should be disabled on the RRAS server if not in use. See the article on the May 2023 security updates for details.

Additional Information

October 2023 Security Updates