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
germiermela
/ February 7, 2022Hi Richard, I have got this error today and in my case was the Root CRL… I have forgot to Turn ON my Offline Root CA and deploy the new CRL :), want just to let you know, maybe you want to add it ;).
Richard M. Hicks
/ February 7, 2022Oh yes, expired CRLs could definitely cause this issue. I’ll be sure to update the post soon. Thanks for the tip! 🙂
Richard M. Hicks
/ February 10, 2022I’ve updated this post to include expired CRL as a possible cause for 13801 or 13806 errors. Thanks for the reminder! 🙂
John S
/ November 18, 2025Checked the machine certificate – ok
Checked the device certificate on the client – ok
Checked the CRLs
Checked the root CA
When our previous certificate expired for the always on VPN RRAS server (which is not domain joined), we created a new request using certutil, and signed it with the Certification authority, but now 13806 errors plague our device tunnel. The SSTP user tunnel with EAP works fine still. Made sure that Set-vpnauthprotocol is using the correct root CA, and also CertificateAdvertised is pointing to the server device certificate. Two people have been looking for days and cannot find anything wrong.
cheerful852b0e16eb
/ November 18, 2025Found the fix – missing private key.
Used the CAPI2 log to debug, found in Event Viewer under Application and service logs -> Microsoft -> Windows -> CAPI2
Since our VPN server is outside the domain we used certreq with an INF file to make the manual request, but we did not use certreq -accept -machine C:\file\to\cert.cer to accept back in the cert and attach the private key.
Also, we needed to make sure the certificateadvertised (Set-VpnAuthProtocol) was set to this new cert.
Richard M. Hicks
/ November 19, 2025Glad you were able to get it sorted out quickly!