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 and IP security IKE intermediate (OID 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.


Root CA Certificate Thumbprint


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

Leave a comment


  1. Ben

     /  March 16, 2022

    Hi 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 ?

    • So, 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, 2022

        I think i got the point…!
        I used internal pki certificate and i should use public certificate.

        Thanks for the reply Richard.

      • You should be using internal certificates for authentication, FYI. 🙂

      • Ben

         /  May 9, 2022

        Hi 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 :

        I don’t have log from the server, maybe there is a way to get debug log somewhere ?
        Any idea to help me ?

      • In 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, 2022

        Thank 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

        Certificate and chain on my Win10 client

        Certificate and chain on my NPS server

        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.

      • It 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, 2022

        Found 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.

      • Ok, that will certainly cause the problem too! 😉

        Did you define the correct DNS suffix in your VPN configuration?

      • Ben

         /  May 12, 2022

        I think everything is ok in my VPN_Profile.xml

        Did i miss something ?

        Thanks again.

      • A 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, 2022

        Here is the pkiview status

        All is ok !

Leave a Reply

%d bloggers like this: