Always On VPN Certificate Requirements for IKEv2

Always On VPN Certificate Requirements for IKEv2Internet Key Exchange version 2 (IKEv2) is one of the VPN protocols supported for Windows 10 Always On VPN deployments. When the VPN server is Windows Server 2016 with the Routing and Remote Access Service (RRAS) role configured, a computer certificate must first be installed on the server to support IKEv2. There are some unique requirements for this certificate, specifically regarding the subject name and Enhanced Key Usage (EKU) configuration. In addition, some deployment scenarios may require a certificate to be provisioned to the client to support IKEv2 VPN connections.

Server Certificate

The IKEv2 certificate on the VPN server must be issued by the organization’s internal private certification authority (CA). It must be installed in the Local Computer/Personal certificate store on the VPN server. The subject name on the certificate must match the public hostname used by VPN clients to connect to the server, not the server’s hostname. For example, if the VPN server’s hostname is VPN1 and the public FQDN is, the subject field of the certificate must include, as shown here.

Always On VPN Certificate Requirements for IKEv2

In addition, the certificate must include the Server Authentication EKU ( Optionally, but recommended, the certificate should also include the IP security IKE intermediate EKU (

Always On VPN Certificate Requirements for IKEv2

Client Certificate

Client certificate requirements vary depending on the type of VPN tunnel and authentication method being used.

User Tunnel

No certificates are required on the client to support IKEv2 when using MSCHAPv2, EAP-MSCHAPv2, or Protected EAP (PEAP) with MSCHAPv2. However, if the option to verify the server’s identity by validating the certificate is selected when using PEAP, the client must have the certificates for the root CA and any subordinate CAs installed in its Trusted Root Certification and Intermediate Certificate Authorities certificate stores, respectively.

User Tunnel with Certificate Authentication

Using certificate authentication for the user tunnel is the recommended best practice for Always On VPN deployments. A client certificate must be installed in the Current User/Personal store to support PEAP authentication with smart card or certificate authentication. The certificate must include the Client Authentication EKU (

Always On VPN Certificate Requirements for IKEv2

Device Tunnel

A computer certificate must be installed in the Local Computer/Personal certificate store to support IKEv2 machine certificate authentication and the Always On VPN device tunnel. The certificate must include the Client Authentication EKU (

Always On VPN Certificate Requirements for IKEv2

More information about configuring the Always On VPN device tunnel can be found here.

Additional Information

Always On VPN with Trusted Platform Module (TPM) Certificates

Always On VPN Protocol Recommendations for Windows Server 2016 RRAS

Always On VPN and Windows Server RRAS

Always On VPN Training

Leave a comment


  1. Matthew

     /  May 14, 2018

    If we we deploy Always On VPN, we would want to deploy it to not only our own laptops, but also to laptops of certain business partner’s laptops that we do not manage.
    For their laptops (we would treat them as BYOD), they would only need a user tunnel since their is no benefit to a device tunnel. They only need the connection to access our intranet, file shares and for remote desktop access to internal systems.
    The client certificate requirements state that you only need to import it into the user certificate store. I assume the user can do that without requiring admin rights.
    What method is used to configure Always On VPN on devices where we have no central management? Powershell? If so, do the Powershell commands require admin rights?
    If a BYOD device is lost/stolen, how do you block VPN access from just that device? I know you can disable the user in AD, but that would also block the user from accessing resources from any other device they have.

    • Yes, if you aren’t going to use Microsoft Intune, you can use Powershell if you like. It doesn’t scale very well, but it does work. You should be able to import user certificates without requiring administrative rights. Also, creating user VPN connections does not require administrative rights. As for blocking connections, you can do that by disabling their AD user account or just removing the user from the VPN users security group (assuming you’ve restricted VPN access to a specific group).

  2. Ian Burnell

     /  July 25, 2018

    Richard – are the AOVPN certificates created on the ROOT-CA Server or the issuing server SUB-CA. I have created them on the sub-ca and am getting error 812 trying to authenticate

    • That would depend on how you configured your PKI. Can I assume you are using EAP with client certificate authentication then? The 812 is an authentication policy mismatch, meaning the server might be expecting EAP but the client sends MS-CHAP v2, for example. Look close at your authentication settings and ensure they match on both sides. If you are using client certificate authentication, make sure you choose the correct server certificate on the NPS server.

      • Ian Burnell

         /  July 30, 2018

        Yes – I have followed the Microsoft article and also other forums. PEAP using certificates. I can see Authentication-type of 11 in the NPS logifle which I believe is correctly PEAP. Does the Cryptography settings have to match the Windows 10 user? i.e. Key Storage Provider. Tried updating but still getting event id 20227 error 812 on client , error 259 on NPS server logs. On VPN server get 20255 error occurred on Point to Point module port VPN2-125… authentication method does not match…

      • Error 812 is a policy mismatch error, so it must be off on one side or the other. Keep in mind that if you’ve made any changes to the default settings for IKEv2 cryptography settings, those must match on the client and VPN server.

  3. Drew

     /  August 12, 2018

    I have run into an issue trying to implement this for the first time. My internal CA has issued a cert for the VPN server with the subject name of, and an alternative name of (the domain names are not the same).

    But I kept getting an event ID 20227 error on client with error code “13801”. For giggles, I changed my hosts file so = myVpnServerIP. Then configured the VPN connection on my Win10 computer to connect to

    And I was able to connect!! So I think the config is correct but there is something wonky with my cert Subject name.

    The VPN server cert has a subject name of what I was expecting. The value is correct, in the bottom pane of the window the subject name value shows as CN = (but the value in the top right pane is just VPN….. Is that expected? Any ideas where else to troubleshoot?

    • Drew

       /  August 13, 2018

      I am still not sure what I did wrong in my previous certificate configuration but I have a working solution at this time. The MS TechNet article provides some advice for the subject name and alternate name which did not work in my scenario, however, another bloggers post provided a suggestion that did work by using the VPN servers hostname in the subject common name and the public full DNS name of the VPN address that clients use in the alternate name. I have also found that using the same full public DNS name in the subject common name and alternate DNS name also works. I’m not sure what is preferred, but know that MS’s TechNet suggestions did not work:

      A) Subject name, in Value, enter the name of the external domain
      B) Alternative Name, in Value, enter all of the server names clients

      • The public hostname should be included in the subject and subject alternative name fields on your certificate. No other entries are required. If you have it configured like that it should work. 🙂

    • As long as the certificate subject name matches your public hostname, everything should work. If you have any SAN entries, the public hostname should be included in that list. However, to avoid any potential for conflict, I would recommend that the certificate have only the public hostname listed in the SAN entry list. I’ve never had a problem at all using that configuration, and honestly, there’s no real reason to have multiple SAN entries anyway. 🙂

  1. Deploying Windows 10 Always On VPN with Microsoft Intune | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Client DNS Server Configuration | Richard M. Hicks Consulting, Inc.
  3. Always On VPN SSL Certificate Requirements for SSTP | Richard M. Hicks Consulting, Inc.
  4. Always On VPN Routing Configuration | Richard M. Hicks Consulting, Inc.
  5. Always On VPN IKEv2 Load Balancing with KEMP LoadMaster | Richard M. Hicks Consulting, Inc.
  6. Always On VPN IKEv2 Security Configuration | Richard M. Hicks Consulting, Inc.
  7. Always On VPN IKEv2 Connection Failure Error Code 800 | Richard M. Hicks Consulting, Inc.
  8. Always On VPN IKEv2 and SSTP Fallback | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: