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
Ben
/ March 16, 2022Hi Richard,
I’m stuck with this error on my “user Tunnel” for a while.
I have double checked everything :
Certificate chain on VPN server and client : ok
VPN server certificate with the correct EKUs : ok
Certification CRL available on http from everywhere : ok
VpnAuthProtocol configured with Enterprise CA (?) ok or i should use Root CA ?
The “Device Tunnel” is up and running automatically.
I’m using Windows Server 2019 and Windows 10 20H2 and 21H2.
Any other things to check ?
Thanks
Ben
Richard M. Hicks
/ March 16, 2022So, device tunnel works but user tunnel doesn’t? 13801 is usually certificate-related, somehow. Does the subject name on the certificate match what you’re calling in the VPN profile?
Ben
/ March 17, 2022I think i got the point…!
I used internal pki certificate and i should use public certificate.
Thanks for the reply Richard.
Richard M. Hicks
/ March 17, 2022You should be using internal certificates for authentication, FYI. 🙂
Ben
/ May 9, 2022Hi Richard,
I have check my certificates and CRL/OCSP configuration everything is ok (certutil -url mycert.cer and retrieve all urls).
Subject on VPN server certificate have our public VPN url.
When i try to connect the user tunnel i always get an error 13801 :
https://ibb.co/f9z8s3m
https://ibb.co/gyc12P0
https://ibb.co/KbXMfC4
I don’t have log from the server, maybe there is a way to get debug log somewhere ?
Any idea to help me ?
Richard M. Hicks
/ May 9, 2022In my experience, 13801 is caused by one of the things I wrote about in this post. Most commonly it is a missing root or intermediate CA certificate, either on the client or the server. Also, it could be caused by a the server being configured to require the wrong root CA certificate using Set-VpnAuthProtocol.
Just for good measure, open pkiview.msc on your issuing CA and make sure there are no errors showing. If there are, correct them and continue testing.
Ben
/ May 9, 2022Thank you so much for taking time to answer me. I’m working on that User Tunnel for days and weeks…and i don’t know what i’m doing wrong…
Certificate and chain on my VPN server with public url
https://ibb.co/18DpkgF
https://ibb.co/GTpCkxz
Certificate and chain on my Win10 client
https://ibb.co/sHBC6Ny
Certificate and chain on my NPS server
https://ibb.co/pvcnWj8
https://ibb.co/CwZdPNp
I was wondering if it could be an encryption issue, i’m using strong ciphers and maybe it’s not acceptable by server or client ? Device tunnel is always up and running.
Thanks again.
Richard M. Hicks
/ May 10, 2022It is not likely to be an issue related to encryption, as that would result in a different error message. This one is specifically related to authentication.
Ben
/ May 11, 2022Found my issue.
EAP was missing in the “UserAuthProtocolAccepted” in the Set-VpnAuthProtocol.
Both User and Device tunnel are up and running.
Now i’m facing DNS issue. Computer cannot resolve anything. Internal DNS is set on both configuration.
I try to change metric to priorize DNS on VPN connection but it’s not working.
Richard M. Hicks
/ May 11, 2022Ok, that will certainly cause the problem too! 😉
Did you define the correct DNS suffix in your VPN configuration?
Ben
/ May 12, 2022I think everything is ok in my VPN_Profile.xml
https://ibb.co/mN5pzpR
Did i miss something ?
Thanks again.
Richard M. Hicks
/ May 12, 2022A few things I noticed here. First, NRPT isn’t supported on the device tunnel. You should remove the DomainNameInformation element from your XML. Also, I’m not sure if entering only the RemoteAddressRange is supported. I would have to test that and see if it works. It may require a protocol and port to work. I’d suggest removing the traffic filter entirely just for testing to ensure it works without it.
Ben
/ May 10, 2022Here is the pkiview status
https://ibb.co/nCnN5GZ
All is ok !
Mo Popoola
/ January 16, 2023Hi Richard,
Thank you for always helping out with issues and sharing your knowledge.
We are testing a Hybrid Azure AD join device with Always On VPN, so that users can log on the first time.
We deployed a Device tunnel via Intune but this doesn’t connect and returns an error 13801:
Going through your blog, we have ensured the following;
Certificate Chain: the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores through MS Intune and Computer certificate using SCEP.
Cryptography settings match those on the RRAS and no policy mismatch error. SCEP cert is issued ‘devicename.domian.local and has Client Authentication EKU.
VPN Certificate: The VPN server is valid and 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 matches the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server.
Certificate Revocation: Reviewed the status of all CRLs on the Enterprise PKI console (pkiview.msc) on an issuing CA, they are all OK, no errors.
RRAS configuration: The root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices.
Can you help, please?
Richard M. Hicks
/ January 16, 2023Can you connect if you remove the root certificate thumbprint restriction (temporarily) on the RRAS server?
Mo Popoola
/ January 17, 2023Thanks for the quick respons. Removing the root cert thumbprint didn’t work, unfortunately. However, deleting the Intune MDM certificate seems to have resolved the error. Guess it was trying to use this cert for authentication as it also has client auth eku..
Now we’re getting an 809 error which we are trying to resolve.
Thank you for your help.
Richard M. Hicks
/ January 17, 2023If this is a user tunnel, I’d suggest enabling certificate filtering in your EAP configuration to ensure the correct certificate is selected. If this is for a device tunnel you can use the Set-VpnConnection -MachineCertificateEKUFilter command to specify the correct certificate.
Mo Popoola
/ January 17, 2023This is for Device tunnel. Thanks for the tips.
Volker Mauel
/ March 17, 2024In case anyone runs into the same thing:
If there are multiple Certificates the RRAS server could use, he will chose one at random it seems.
To fix:
$cert1 = ( Get-ChildItem -Path cert:LocalMachine\my | Where-Object -FilterScript { $_.Subject -Like “*CN=[YOUR_CERT_CN_HERE]*” } )
Set-VpnAuthProtocol -CertificateAdvertised $cert1
Thanks for your guides!
Richard M. Hicks
/ March 17, 2024Indeed, in very rare cases this setting is required. I think I’ve only ever had to do it once, but it can be helpful in some cases. Thanks!
Chris
/ April 5, 2024We had exactly this occur today and this was the solution.
Many thanks both for your help!