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

Leave a comment

22 Comments

  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 ?
    Thanks
    Ben

    Reply
    • 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?

      Reply
      • 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 :

        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 ?

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

      • 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
        https://ibb.co/mN5pzpR

        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
        https://ibb.co/nCnN5GZ

        All is ok !

  2. Mo Popoola

     /  January 16, 2023

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

    Reply
    • Can you connect if you remove the root certificate thumbprint restriction (temporarily) on the RRAS server?

      Reply
      • Mo Popoola

         /  January 17, 2023

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

      • If 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, 2023

        This is for Device tunnel. Thanks for the tips.

  3. In 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!

    Reply
    • Indeed, 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!

      Reply
      • Chris

         /  April 5, 2024

        We had exactly this occur today and this was the solution.

        Many thanks both for your help!

  1. Always On VPN Error 13806 | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading