Always On VPN Error 13806

Troubleshooting Always On VPN Error 691 and 812 – Part 2

As a follow-up to my last post regarding Always On VPN error 13801, this post will cover a similar and related error administrators may encounter, the 13806 error. As mentioned previously, certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this earlier post. Following this guidance, administrators should have no issues with IKEv2 Always On VPN connections. However, it is always possible to encounter an error if any of these certificates are missing or misconfigured.

Error 13806

Much like the error 13801 described previously, 13806 is also common. When an Always On VPN connection using IKEv2 fails, the Windows Application event log will record an event ID 20227 from the RasClient source. The error message states the following:

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

IKE Failed To Find Valid Machine Certificate

Error 13806 translates to ERROR_IPSEC_IKE_NO_CERT, indicating IKE failed to find a valid machine certificate. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.

Device Certificate

For the device tunnel, the most obvious cause of this error is a missing device authentication certificate on the client itself. Ensure the endpoint has a valid certificate issued by the organization’s internal PKI that includes Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2). The certificate must have a subject name matching the device’s FQDN. It must also be valid (not expired), trusted, and not revoked.

Certificate Chain

A 13806 error will occur if the device certificate installed on the client is not trusted or if the client does not trust the certificate installed on the VPN server. Ensure the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores.

VPN Server Certificate

A 13806 error can also occur if the VPN server does not have a properly configured server certificate. Ensure the VPN server has a valid certificate issued by the organization’s internal PKI that includes both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and IP security IKE intermediate (OID 1.3.6.1.5.5.8.2.2) EKUs. The subject name must match the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server (not the server’s NetBIOS name). Again, ensure the certificate is valid (not expired), trusted, not revoked, and all necessary root and intermediate CA certificates are installed in their respective certificate stores.

Certificate Revocation

An expired Certificate Revocation List (CRL) can also result in a 13801 error. Open the Enterprise PKI console (pkiview.msc) on an issuing CA and review the status of all CRLs. If any are expired, resolve any issues preventing the CRL from publishing successfully, then issue a new CRL by running certutil.exe -crl on the issuing CA server.

RRAS Configuration

Another cause of the 13806 error for the user tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13806 can happen if the administrator incorrectly defines a trusted root CA using Set-VpnAuthProtocol. Ensure that the root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices and the VPN server.

Get-VpnAuthProtocol

Root CA Certificate Thumbprint

Resolution

Ensure that devices and VPN servers have correctly configured certificates installed. If the root CA certificate is assigned incorrectly on the VPN server, follow the guidelines detailed here to update the configuration.

Additional Information

Microsoft Windows Always On VPN Error 13801

Microsoft Windows Always On VPN Certificate Requirements for IKEv2

Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue

Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error

Microsoft Windows Always On VPN IKEv2 Security Configuration

Microsoft Windows Always On VPN IKEv2 Fragmentation

Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT

Microsoft Windows Always On VPN IKEv2 Features and Limitations

Always On VPN Error 13801

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this previous post. Following this guidance, administrators should have no issues with IKEv2 Always On VPN connections. However, it is always possible to encounter an error if any of these certificates are missing or misconfigured.

Error 13801

One of the most common errors related to IKEv2 and certificates is 13801. When an Always On VPN connection using IKEv2 fails, the Windows Application event log will record an event ID 20227 from the RasClient source. The error message states the following:

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

IKE Authentication Credentials are Unacceptable

Error 13801 translates to ERROR_IPSEC_IKE_AUTH_FAIL, indicating an authentication failure related to IPsec. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.

Certificate Chain

A 13801 error will occur if the client does not trust the certificate installed on the VPN server. Ensure the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores.

VPN Server Certificate

A 13801 error can also occur if the VPN server does not have a properly configured server certificate. Ensure the VPN server has a valid certificate issued by the organization’s internal PKI that includes both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and IP security IKE intermediate (OID 1.3.6.1.5.5.8.2.2) EKUs. The subject name must match the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server (not the server’s NetBIOS name). Again, ensure the certificate is valid (not expired), trusted, not revoked, and all necessary root and intermediate CA certificates are installed in their respective certificate stores.

Certificate Revocation

An expired Certificate Revocation List (CRL) can also result in a 13801 error. Open the Enterprise PKI console (pkiview.msc) on an issuing CA and review the status of all CRLs. If any are expired, resolve any issues preventing the CRL from publishing successfully, then issue a new CRL by running certutil.exe -crl on the issuing CA server.

RRAS Configuration

Another cause of the 13801 error for the device tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13801 can happen if the administrator incorrectly defines a trusted root CA using Set-VpnAuthProtocol. Ensure that the root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices and the VPN server.

Get-VpnAuthProtocol

Root CA Certificate Thumbprint

Resolution

Ensure that devices and VPN servers have correctly configured certificates installed. If the root CA certificate is assigned incorrectly on the VPN server, follow the guidelines detailed here to update the configuration.

Additional Information

Microsoft Windows Always On VPN Error 13806

Microsoft Windows Always On VPN Certificate Requirements for IKEv2

Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue

Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error

Microsoft Windows Always On VPN IKEv2 Security Configuration

Microsoft Windows Always On VPN IKEv2 Fragmentation

Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT

Microsoft Windows Always On VPN IKEv2 Features and Limitations

Always On VPN Traffic Filters and IPv6

Always On VPN Windows Server RRAS Service Does Not Start

Using Traffic Filters with Always On VPN provides administrators the option to configure a true Zero Trust Network Access (ZTNA) solution for their field-based users and devices. By enabling traffic filtering, network access over the Always On VPN connection can be controlled using fine-grained policies. Traffic Filter rules can be configured to restrict access based source and destination IP addresses, protocols, and source and destination ports. Administrators can further restrict access based on the application generating the traffic.

IPv6

While testing these features recently, I learned that the Microsoft Endpoint Manager (formerly Intune) user interface does not appear to support IPv6 when configuring traffic filter rules. As you can see here, the UI explicitly asks for an IPv4 address and complains when entering an IPv6 address in the address field, as shown here.

Interestingly, it is possible to add IPv6 addresses in XML, as follows.

<TrafficFilter>
   <App>
      <Id>Microsoft.RemoteDesktop_8wekyb3d8bbwe</Id>
   </App>
   <Protocol>6</Protocol>
   <RemotePortRanges>3389</RemotePortRanges>
   <RemoteAddressRanges>2001:470:f109::/48</RemoteAddressRanges>
</TrafficFilter>

Connection Failure

Unfortunately, after loading the XML on a test client, the Always On VPN connection fails with the following error message.

“Can’t connect to <ConnectionName>. Catastrophic failure.”

In addition, the Application event log records an event ID 20227 from the RasClient source with the following error.

“The user <UserName> dialed a connection name <ConnectionName> which has failed. The error code returned on failure is -2147418113.”

Workaround

At this time, the only known workaround is to update the configuration on the RRAS server to use IPv4 addressing for VPN clients.

Summary

Unfortunately, IPv6 is still a second-class citizen when it comes to Always On VPN. Although enabling IPv6 works well in most common deployment scenarios, the Microsoft Endpoint Manager management console often fails to accept IPv6 entries in IP address fields. In addition, some advanced features such as traffic filtering are incompatible with IPv6.

Additional Information

Windows 10 Always On VPN and Zero Trust Network Access (ZTNA)

Windows 10 Always On VPN Windows Server RRAS Service Does Not Start

%d bloggers like this: