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 vpn.example.net, the subject field of the certificate must include vpn.example.net, as shown here.

Always On VPN Certificate Requirements for IKEv2

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

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 (1.3.6.1.5.5.7.3.2).

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 (1.3.6.1.5.5.7.3.2).

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

70 Comments

  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.

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

      Reply
      • Tor Marius

         /  January 21, 2019

        helo,
        i’m trying to set up alwayson vpn connection for external buisiness partners. I have created a aduser(with same name as they use to logonn theyr computer). loged on a computer with that user and exported the vpn certificate and the root certificate. i have then immported both of those certificates on a non domain computer. it seems like the computer establish the link to the ras server, but i get error 13801.
        any suggestions of what i am doing wrong?
        The vpn is created wit powershellscript(same i use at domain computers). on domain computers the soulouting works fine!

      • Error 13801 indicates a problem with IKE credentials. I’d have to assume that there’s an issue with certificate configuration somewhere. I’d have a close look at that and see what you can find out.

      • Tor Marius

         /  January 22, 2019

        i have followed this when i created the certificate: https://4sysops.com/archives/active-directory-group-policy-and-certificates-for-always-on-vpn/#configuring-certificate-services-for-remote-access

        i notis one difference, on VPN server sertificate, from what you have. the client authentication application policie is chosen in my certificate template, but not in yourse. can thant be the difference?

      • Shouldn’t make a difference. The minimum requirements are Server Authentication and IPsec IKE Intermediate. If the template also includes Client Authentication that’s fine, but it isn’t strictly required and certainly wouldn’t negatively affect operation.

  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

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

      Reply
      • 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 VPN.myPublicDomain.com, and an alternative name of VPN.myInternalDomainName.com (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 VPN.myInternalDomainName.com = myVpnServerIP. Then configured the VPN connection on my Win10 computer to connect to VPN.myInternalDomainName.com

    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 = VPN.myPublicDomain.com (but the value in the top right pane is just VPN….. Is that expected? Any ideas where else to troubleshoot?

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

      https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-server-infrastructure

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

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

      Reply
  4. Hello
    You mentioned that IKEv2 needs a certificate from a internal CA. For SSTP there is written “it is recommended that the SSL certificate used for SSTP be issued by a public Certification Authority (CA). Public CAs typically have their Certificate Revocation Lists (CRLs) hosted on robust, highly available infrastructure”.
    What about a solution and the certificate requirements if we wanna use IKEv2 and SSTP together on the same VPN Server. Can we use a public certificate for both protocols

    Reply
    • If you plan to support both IKEv2 and SSTP you’ll have two certificates installed on the VPN server then. The public SSL certificate is configured for SSTP, and the private internal certificate will be used for IKEv2. It is possible to use a public certificate for IKEv2, but then that means that anyone with a certificate issued by that CA could potentially connect to your VPN server. 😉

      Reply
  5. Wes

     /  February 18, 2019

    Hi Richard, in regards to the Device and Client Tunnels, if a user who has never logged into the device before is at home say and they attempt a login they’ll be able to authenticate using the device tunnel but they won’t be able to connect to the client tunnel until they have a certificate?

    Reply
    • Correct. The device tunnel gives the client the ability to log on without having cached credentials, but if you’re using client certificate authentication the certificate will have to be provisioned prior to the first logon.

      Reply
  6. Joe

     /  March 19, 2019

    Hi Richard, we are using a device tunnel only configuration to replace Direct Access, but how can we limit which devices can actually connect using Always On VPN? By default our domain auto-enrolls all computers to have computer certificates which are required for other means. In Direct Access this could be limited by a simple AD group.

    Reply
    • Hi Joe,

      The device tunnel uses only the computer certificate for authentication. This means any device that has a computer certificate issued by ANY CA the server trusts will be accepted, by default. If you’ve followed my guidance you have chosen a specific CA, your internal private CA, to trust for device tunnel connections.

      The only way to further restrict Always On VPN device tunnel connections is to only provision those settings to devices you want to allow to connect, or use a different CA to issue the certificates. There are no other options to selectively allow/deny device tunnel connections by security group, unfortunately.

      Reply
  7. Kristof

     /  March 20, 2019

    Hey Richard,

    Is there any restriction on the version of the Certificate Authority?
    We currently have a Server 2008 R2 Certificate Authority, but when checking the Microsoft documentation, a Server 2012 R2 environment is used, which have more configuration options than my 2008 R2 environment.

    Can this cause issues for the certificates?

    Thanks,

    Kristof

    Reply
  8. Hi Richard, I don’t know if you can help here.
    I have a handful of clients which won’t connect when ‘Connect automatically’ is checked on the user tunnel. If checked, they get the error “This connection is already being dialled”. If left unchecked they can manually connect OK every time.
    I’ve narrowed it down to a User certificate being issued by Skype For Business. It seems that when you launch Skype it checks for the existence of this certificate and creates one if it doesn’t exist.
    If I delete the Skype certificate, AlwaysOn auto-connects perfectly. I can therefore only assume that AlwaysOn is choosing the wrong one when left to connect automatically. Can I force AlwaysOn to use the right certificate? Your thoughts are welcome.

    Reply
    • Common problem. I’ve got a blog post in the queue that addresses this specific issue too. Hope to get that published soon. Until then, you’ll need to enable certificate filtering in your EAP configuration. On the “Smart Card or Other Certificates” properties page click the “Advanced” button. There you’ll be able to select the specific CA and EKU that is presented by the client for authentication. If that’s not clear, drop me an email and I’ll send you some screen shots. Hopefully I’ll get that post up soon. 🙂

      Reply
      • Andy Chips

         /  May 14, 2019

        Wow – I don’t know where you figured that out! I just get the feeling that all these nuggets of info you keep giving us aren’t available to the man in the street like me. Nevertheless, I shall give that a go. Thank you so much.

      • Just experience my friend. 🙂 Let me know how it goes!

      • Success!
        All I had to do was enable and specify ‘Certificate Issuer’ and the problem was resolved. I didn’t have to specify the EKU.
        I can’t thank you enough.
        I guess I’m going to have to fix this for all users by re-issuing a modified certificate from our CA.

      • Great! You shouldn’t need to issue a new certificate however. You will have to update your EAP configuration to specify the certificate selection piece and push the new profile out to all your users though. 🙂

      • Yes, of course. Doh.

      • Hi Richard,
        Due to a recent requirement by a third party network device I had to change our internal CA’s Root Certificate signing from RSASSA-PSS to RSASHA256. Renewing the Root certificate then caused AD to publish our Trusted Root CA twice. I don’t know why that is, but this means that all our AlwaysOn users can’t now connect as their VPN connection is specifying the wrong/old CA.
        Unless I’m mistaken this means I’m going to have to recreate the user tunnel Profile.XML file and get everyone to recreate their connections based on this new configuration. Should this type of symptom be happening? Will the same thing happen when the Root Certificate renews in the allotted ‘n’ years’ time, as they do?

      • If you make changes to your PKI (new hierarchy or even just renew the CA’s certificate) then yes, you’ll have to update settings on the Always On VPN client. Unfortunately this does involve updating settings on the client, which of course means having to reprovision Always On VPN to all of your devices. And yes, if in the future you renew CA certificates you’ll have to do this again. :/

      • Richard,
        Thanks for that confirmation. It reassures me greatly that I hadn’t done the wrong thing and that the consequences were to be expected. Knowing this now I can plan accordingly for the next time.
        As ever, much appreciated, and even more so considering it’s the 4th July!
        Andy.

      • I’d like to clarify here (for completeness) that you will only have to update Always On VPN client configuration if you have followed EAP configuration best practices and are validating NPS servers certificates during authentication. If you’ve disabled those settings and aren’t using certificate filtering then renewing certificates on an existing PKI is not impactful. However, implementing a new PKI hierarchy would require provisioning new certificates to clients before changing over.

  9. Hi Guys,

    I am working on deploying Always on VPN , our current CA sits on windows sever 2008 r2 . Would this be possible for certificate enrollment or do we need to migrate CA to 2012 R2 . please advise

    Thanks

    Francis

    Reply
    • You should be able to implement Always On VPN using a 2008 R2 CA server. You may not be able to do advanced things like TPM and key attestation or using EC cryptography, but at a basic level it should work.

      Reply
      • Thanks Richard . really appreciate

      • Thanks for your responds . 

        Just to confirm Under Cryptographic what will be the best  Cryptographic Providers option on 2008 r2 for Users certificate  since “Microsoft Platform Crypto Provid”e is unavailable on 2008R2? 

      • If you’re not going to specify the Microsoft Platform Crypto Provider to ensure that keys are stored on the client’s TPM, I’d suggest selection the option “Requests can use any provider available on the subject’s computer”.

      • Hi Richard  

        I have managed to set up User tunnel AOVPN windows 10 1809  , I have deployed it to few machines using SCCM and it seems to work fine when I manually click on connect . however  Auto connect does not seems to work , we always have to click on the vpn template and click connect to get it working , I though the whole idea of  AOVPN was to automatically connect. I have been trying to troubleshoot this for the last few days with no luck.   I will appreciate any type of advise or assitance. 

        Many thanks 

      • You’re right, Always On VPN should automatically connect and be “always on”. 🙂 When you provisioned your clients using SCCM, how specifically was that done? Did you use native SCCM functionality? Or did you deploy a PowerShell script with custom ProfileXML?

      • Hi Richard , thanks for the quick reply . I deployed powershell script with custome ProfileXML .

      • Great. 🙂 As long as your ProfileXML includes the statement [AlwaysOn]true[/AlwaysOn] it should connect automatically. Note the lowercase “t”. That’s important. If it still isn’t connecting automatically, have a look at your trusted network detection setting. If that’s not configured correctly that could be the cause. Also, make sure the VPN profile name is not included in the AutoTriggerDisabledProfilesList registry entry found here: HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Config. If it is there, remove it and test again. Hope that helps!

      • Thanks . I was looking at micrsoft xml template when they run Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_VPNv2_01 . I notice they have true in their result after runing the comman . I run the same command and I dont see true in my result xml result . could that be an issue?

      • Thanks . I was looking at micrsoft xml template when they run Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_VPNv2_01 . I notice they have (AutoTriggertrue/AutoTrigger) in their result after runing the comman . I run the same command and I dont see (AutoTriggertrue/AutoTrigger) in my xml result . could that be an issue?

      • Quite possibly. Your best bet is to either use the Microsoft provided guidance for creating the ProfileXML and PowerShell script here or you can use the scripts and sample configurations found on my GitHub here.

  10. Hi Richard, Given IKEv2 server authN would use internal CA certificates. Do this mandate that the CRLs are published externally for the remote clients to be able to validate?

    Reply
    • No, not at all. The VPN server performs the revocation check, not the client. As long as the VPN server can access the CRL you’re good. However, there’s a catch. 😉 There’s a bug in Windows Server RRAS that prevents RRAS from performing the CRL check. A fix was just released for Windows Server 2016. A fix for Windows Server 2019 is forthcoming. Details here: https://rmhci.co/rrascrlcheck.

      Reply
  11. Bailey

     /  August 2, 2019

    Hi! I’m wondering if you’ve experienced any issues using a Server 2019 Certification Authority. I can’t seem to get the AlwaysOn to work if my certificates are from a 2019 Server, however, if I use 2012 R2 or 2016 certs it works fine. The error I get while connecting is the following:
    The connection tells me: IKE authentication credentials are unacceptable

    Event LOG on client:
    The user “user” dialed a connection named “VPN TEST” which has failed. The error code returned on failure is 13801.

    and on the server side I see:
    The following error occurred in the Point to Point Protocol module on port: VPN2-127, UserName: . Negotiation timed out

    I’m led to believe its an issue with the VPN server certificate but I was curious if you had seen this before. Thanks!

    Reply
    • Most interesting. I’ve not yet deployed Always On VPN with a Windows Server 2019 PKI. It sure sounds like there’s some sort of limitation there though. I’ll do some testing soon and see if I can replicate. Stay tuned for more details later… 🙂

      Reply
  12. Igor

     /  November 6, 2019

    Hello, massive thanks for sharing your insight and experience. I’m tying to create user certificates based IKEv2 VPN on Server 2019 infrastructure with RSA4096/SHA512 CA and certificates. No luck so far. Everything works just fine until first try to connect on client computer (error 13806, event ID 20227) It’s over week now, I tried almost everything and I’m pretty sure all steps I’ve done are correct. My question is: can I avoid using SHA1 hashes? Is there working scenario without SHA1? I haven’t tried Server 2016. Thank you very much.

    Reply
    • You most definitely don’t have to use SHA-1. I’ve only ever deployed IKEv2 using RSA 2048 with SHA-2 or using EC P256 with SHA-2. Both work flawlessly. Using 4096/SHA-512 is a bit out of the ordinary for end entity certificates, but I’m not aware of any limitation that would prevent it from working. Have you tried using RSA 2048 and SHA-2 just to see if everything works?

      Reply
  13. Tommy

     /  November 20, 2019

    We have setup device and user based tunnels, both using IKEv2. Both connect just fine independently, but when both are connected simultaneously the user tunnel constantly disconnects and reconnects creating multiple orphaned sessions on the RRAS server. Any ideas?

    Reply
  14. Elliot

     /  November 29, 2019

    Hi Richard, Having a few issues with the client tunnel intermittently not connecting – gives you Error 798. A certificate exists and worked say the day before but for some reason can’t see or use the cert.

    Its the only certificate in the personal store and I have implemented the EKU option to solve some of the Modem is already being dialed issues.

    Delete and re-add of the certificate usually fixes the error, but annoying for end users.

    Any ideas?

    Reply
    • That’s quite odd. I can’t imagine why the same certificate works one day and not the next. I’d suggest enabling CAPI2 logging to see if that sheds any light on this. Perhaps it will provide a clue as to why it is failing.

      Reply
  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.
  9. Always On VPN IKEv2 Load Balancing with F5 BIG-IP | Richard M. Hicks Consulting, Inc.
  10. Always On VPN IKEv2 Features and Limitations | Richard M. Hicks Consulting, Inc.
  11. Always On VPN Clients Prompted for Authentication when Accessing Internal Resources | Richard M. Hicks Consulting, Inc.

Leave a Reply to Richard M. Hicks Cancel reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: