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 13806 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 Book Available for Pre-Order

Great news! My new book, Implementing Always On VPN, is now available for pre-order on Amazon.com. This new book, scheduled for release in late 2021, is a comprehensive implementation guide for Windows 10 Always On VPN. Drawing on many years of experience deploying Always On VPN for organizations worldwide, it covers all aspects of an Always On VPN deployment, including planning and design, prerequisite gathering, infrastructure preparation, and client deployment.

In addition, it contains detailed, prescriptive guidance for advanced configuration options such as application and traffic filtering and proxy server configuration. Cloud deployments using Azure VPN gateway and Virtual WAN are covered, and it includes guidance for configuring Azure MFA and Conditional Access.

Also, the book includes thorough guidance for provisioning certificates using Microsoft Endpoint Manager/Intune using both PKCS and SCEP. It outlines options for high availability for VPN and authentication infrastructure and provides details for ongoing system maintenance and operational support.

Finally, the book has an entire chapter dedicated to troubleshooting and resolving common (and not so common!) issues encountered with Windows 10 Always On VPN.

Reserve your copy today. Pre-order Implementing Always On VPN now!

Chapter List

  1. Always On VPN Overview
  2. Plan an Always On VPN Deployment
  3. Prepare the Infrastructure
  4. Configure Windows Server for Always On VPN
  5. Provision Always On VPN clients
  6. Advanced Configuration
  7. Cloud Deployments
  8. Deploy Certificates with Intune
  9. Integrating Azure MFA
  10. High Availability
  11. Monitor and Report
  12. Troubleshooting

Always On VPN Options for Azure Deployments

Always On VPN Options for Azure DeploymentsOrganizations everywhere are rapidly adopting Microsoft Azure public cloud infrastructure to extend or replace their existing datacenter. As traditional on-premises workloads are migrated to the cloud, customers are looking for options to host VPN services there as well.

Windows Server

Windows Server with the Routing and Remote Access Service (RRAS) installed is a popular choice for on-premises Always On VPN deployments. Intuitively it would make sense to deploy Windows Server and RRAS in Azure as well. However, at the time of this writing, RRAS is not a supported workload on Windows Server in Azure.

Always On VPN Options for Azure Deployments

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines/

Although explicitly unsupported, it is possible to deploy Windows Server and RRAS in Azure for Always On VPN. In my experience it works well and can be an option for organizations willing to forgo formal support by Microsoft.

Azure Gateway

Options for supporting Always On VPN connections using native Azure VPN infrastructure depend on the type of VPN gateway chosen.

VPN Gateway

The Azure VPN Gateway can be configured to support client-based (point-to-site) VPN. With some additional configuration it can be used to support Windows 10 Always On VPN deployments. Azure VPN gateway supports either IKEv2 or SSTP VPN protocols for client connections. The Azure VPN gateway has some limitations though. Consider the following:

  • A route-based VPN gateway is required
  • A maximum of 1000 concurrent IKEv2 connections are supported when using the VpnGw3 or VpnGw3AZ SKUs (2000 supported in active/active mode)
  • A maximum of 128 concurrent SSTP connections are supported on all gateway SKUs (256 supported in active/active mode)
  • The gateway can be configured to support either device or user connections, not both.

Virtual WAN

Azure Virtual WAN is the future of remote connectivity for Azure. It includes support for client-based VPN (currently in public preview at the time of this writing), but only supports IKEv2 and OpenVPN VPN protocols for client connections. SSTP is not supported at all. Further, OpenVPN is not supported for Windows 10 Always On VPN, leaving IKEv2 as the only option, which poses some potential operational challenges. Virtual WAN offer much better scalability though, supporting up to 10,000 concurrent client-based VPN connections. Like the Azure VPN gateway, Azure Virtual WAN can be configured to support either device or user connections, not both.

Virtual Appliance

The most supportable option for hosting VPN services in Azure for Windows 10 Always On VPN is to deploy a third-party Network Virtual Appliance (NVA). They are available from a variety of vendors including Cisco, Check Point, Palo Alto Networks, Fortinet, and many others. To support Windows 10 Always On VPN, the NVA vendor must either support IKEv2 for client-based VPN connections or have a Universal Windows Platform (UWP) VPN plug-in client available from the Microsoft store. Click here to learn more about Always On VPN and third-party VPN devices.

Note: Be careful when choosing an NVA as some vendors support IKEv2 only for site-to-site VPN, but not client-based VPN!

Hybrid Deployments

For organizations with hybrid cloud deployments (infrastructure hosted on-premises and in Azure), there are several options for choosing the best location to deploy VPN services. In general, it is recommended that client VPN connections be established nearest the resources accessed by remote clients. However, having VPN servers hosted both on-premises and in Azure is fully supported. In this scenario Azure Traffic Manager can be configured to intelligently route VPN connections for remote clients.

NetMotion Mobility

The NetMotion Mobility purpose-built enterprise VPN is a popular replacement for Microsoft DirectAccess. It is also an excellent alternative for enterprise organizations considering a migration to Always On VPN. It is a software-based solution that can be deployed on Windows Server and is fully supported running in Microsoft Azure. It offers many advanced features and capabilities not included in other remote access solutions.

Summary

Administrators have many options for deploying VPN servers in Azure to support Windows 10 Always On VPN. Windows Server and RRAS is the simplest and most cost-effective option, but it is not formally supported by Microsoft. Azure VPN gateway is an interesting alternative but lacks enough capacity for larger deployments. Azure Virtual WAN is another option but has limited protocol support. Deploying an NVA is a good choice, and NetMotion Mobility is an excellent alternative to both DirectAccess and Always On VPN that is software-based and fully supported in Azure.

Additional Information

Windows 10 Always On VPN with Azure Gateway

Windows 10 Always On VPN and Third-Party VPN Devices

Windows 10 Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN Multisite with Azure Traffic Manager

Comparing DirectAccess and NetMotion Mobility

Deploying NetMotion Mobility in Microsoft Azure