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.1and 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.

Always On VPN Certificate Requirements for IKEv2

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

111 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
      • many thanks for clarification and the helpfull blog in many ways!

      • My pleasure!

      • Facing an issue where we have a publicly issued wildcard cert used for SSTP connections, and an internally issued ‘service fqdn’ cert for IKEv2 connections. IKEv2 connections are failing and in the CAPI log we can see they’re attempting to use the wildcard cert with the connection ultimately failing with 800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. We’ve SetVPNAuthProtocol but that only tells the VPN server what root is trusted, not what cert to use. Am I missing something?

      • When you use Set-VpnAuthProtocol to establish the root of trust, it simply means that the authenticating device must present a certificate issued by the PKI. What you are describing sounds more like the VPN server’s IKEv2 certificate isn’t configured correctly. The IKEv2 certificate should have both the Server Authentication and the IP security IKE Intermediate EKUs defined, the latter being the crucial one.

  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
    • I have been hearing reports of many orphaned IKEv2 VPN connections in RRAS, but haven’t found anything causing it definitively. Interesting that you can’t seem to get device tunnel and user tunnel to coexist though. FYI, this is a known issue in Windows 10 1709 and earlier. There were some updates earlier this year for 1803/1809 that should have addressed this though. Details here: https://directaccess.richardhicks.com/2019/04/17/always-on-vpn-updates-to-improve-connection-reliability/.

      Reply
      • Tommy

         /  March 10, 2020

        We’re on W10 1809, even tried 1909 and still had the issues. After research and troubleshooting I found that if the device tunnel is pointing to the same DNS servers as the user tunnel, the 2nd connection to come up will loop (typically the user tunnel). I ended up pointing the computer tunnel to different DNS servers and that kept the 2nd connection from looping.

      • Oh yes, if you can resolve the VPN’s public hostname over the internal DNS servers that can be problematic if they don’t resolve to the public IP address. 🙂

  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
  15. John

     /  January 23, 2020

    Hi,
    I have one other potential cause of the 13801 IKE credentials error.
    In the RRAS server console, edit the server properties, specifically the security tab.
    On authentication methods, ensure that the option to use machine certificates for IKEv2 authentication is selected.
    Now to work on the 809 errors… Even though the firewall allows these through and the F5s are configured to pass traffic on these ports, I still see too many 809 errors.

    Reply
  16. William

     /  March 9, 2020

    Hi Richard, following your blog for a while, thanks for making all this public! I have user tunnels working fine (SSTP), but device tunnels are failing…. Ive spent a couple days trying thing now with no luck so if you have any bright ideas it would be appreciated!

    The workstation and RRAS says IKE failed to find a valid machine certificate when you you rasdial.exe.

    I have exported and imported the root CA on both client and RRAS server trusted roots – this was in a .DER format and imported okay so I am guessing this was fine? I created my root CA (lab environment) with Elliptic curve (ECC256 / ECDSA_P256) and SHA256ECDSA. I have a feeling this may be causing the issues, coudl that be the case? I am going to start inspecting with wire shark tomorrow in case that helps but its starting to get a bit beyond my knowledge!

    The workstation certificate template has all the correct EKUs etc.

    If you have any thoughts it would be much appreciated ,

    Reply
    • So both client and server have the correct root CA certificates installed, but do they both have a certificate issued by this CA also? When use EC certificates you will also have to update your cryptography settings to use EC. By default they will expect an RSA certificate.

      Reply
  17. Matthew

     /  March 31, 2020

    Hi Richard, you’ve helped us before with our always on vpn set up at our hospital. All has been working well, but I’ve come across an issue with our smart card users.The smart cards are for a completely separate system and are nothing to do with the vpn.
    We are using user tunnels.
    The user certs are software certs, (Microsoft Software Key Storage Provider), as TPM ones didn’t work with roaming profiles where we had a mix of TPM and non TPM machines.
    The problem occurs when a smart card is inserted, it propagates its certs to the user store (this is to be expected). But once the smart card is removed the vpn user cert has been archived, and the VPN breaks.
    I’ve found one other person on technet forums with the same problem but they didn’t get a resolution.

    Reply
    • That is quite interesting. Natalie Dellar at Risual in the UK has some experience here. I’ll ask her if she has any insight for us. 🙂

      Reply
      • Matthew

         /  April 1, 2020

        Hi, Richard, thanks but we figured it out. It turns out the NHS Digital HSCIC national spine smart card software deletes ALL user certs upon card removal. As you do!

      • ND

         /  April 1, 2020

        Hi –

        Myself and one of my colleagues have been working with some hospitals and he’s seen a similar issue (I’m wondering with the timing whether you are related to that organisation 🙂 )

        Anyway it seems that the place my colleague is working with has exactly those symptoms, and they are using an identity version Identity Agent v2.2.3.7 with their smart cards. Apparently this is relatively old. They have some clients with IA v2.2.3.9 and are reporting seeing the same problem with that version.

        The different hospital I’ve been working with runs Identity Agent v2.2.3.9 and when I flagged this potential problem to them, they were aware that the software / process dynamically creates stuff in the user personal store but my IT team contact there doesn’t think that newest version removes the certs in the user personal store. (due to CV19 restrictions and workload we haven’t had a chance to test yet). I have a nasty feeling he is wrong though and it does do the same thing.

        However – the hospital my colleague is working have raised a call with the IT software provider, and there is an estimated fix for the IA by 7th April that should hopefully mean it doesn’t behave like this. I know it would need to be rolled out and tested etc.

        I hope that helps,

        ND

      • Thanks for the insight, Nat! 🙂

  18. Shazzad

     /  April 4, 2020

    Hi,

    I am trying to integrate AlwaysOn for Non-domain machines. I have imported the root certificate and the client certificate, installed them in their respective containers, but still it is giving an error saying, “A certificate could not be found that can be used with this Extensible Authentication Protocol”. Can you please advise?

    Reply
    • Make sure that you have all of the root and intermediate CA certificates installed in their respective certificate stores on the client. Also, make sure that the client certificate is configured correctly and that it has a private key associated with it.

      Reply
      • Thomas

         /  May 23, 2020

        Hi Richard, about Shazzad’s request, I need a further clarification.I would use a User Tunner without certificate for non domain pc, so I import only Root CA certificate on client. I followed User Tunnel’s instructions and on Authentication Method field which option I have to choose? Secure Password in the previous field, is It correct?
        Thanks

      • If you are not going to use client certificate authentication then you would only need to make sure the client trusts the root CA. Also, you would define the authentication type as MSCHAPv2.

  19. Hello Richard,
    I’m a tad confused. Should I be using an external CA provider or our company CA to create the AOVPN server certificate? I figured an external provider as the user would need to have a CRL check externally available. So we went downt that road. We created one and the user tunnel connects great. Now I want to try getting the device tunnel working. I know need to add “IP Security IKE Intermediate” in key usage.

    Every time I add “IP Security IKE Intermediate” on the cert request, I enroll the request to our external CA provider but the “IP security IKE intermediate” gets stripped off. I think it’s because I need to choose “Microsoft RSA SChannel Crytographic provider (encryption)” which it does not allow me to do. When I try to check that box in my csr, it states “The selected cryptographic service provider (CSP) cannot be used because a cryptography next generation (CNG) provider is required. Select a CNG provider and try again. Provider type does not match registered value”

    Now if I create a template (with Microsoft RSA Schannel Crytographic provider) on our inhouse CA, and enroll that template, it does have the “IP Security IKE Intermediate”. I can also connect with the device tunnel fine. I assume I could have trouble down the road though with CRL checks.

    Any advice?

    Reply
    • The VPN server will have two certificates, one for IKEv2/IPsec and another for SSTP. It is recommended that the certificate for SSTP be issued by a public CA, as clients check this certificate for revocation. Most private/internal CAs don’t make their CRL publicly available. The IKEv2 certificate should be issued by your internal CA, although it is possible to use a public CA. However, your public CA is most likely issuing you a certificate for a web site, which is why it is dropping the required IPsec IKE Intermediate EKU.

      Reply
  20. Shad Behnke

     /  April 22, 2020

    Hello Richard,

    So odd situation, I have everything with the user tunnel but we had to explore the machine tunnel as we have a lot of issues with things that run pre-logon with our environment. That being said I setup the machine tunnel and now that works, but I seem to have broke the user tunnel and can’t figure it out for the life of me.

    The error I am getting is 812, authentication method does not match. Do you have any insight on what I can dig into?

    Thanks!

    Reply
    • Unusual. When the device tunnel is up is the client resolving the FQDN for the user tunnel correctly?

      Reply
      • Shad Behnke

         /  April 23, 2020

        Got it, had to do with having two groups (user and machine) on the network policy, doh can’t do that. Created a single group and now everything is functioning great! Thanks for your guides and quick answer, made the process a breeze!

  21. JD

     /  May 1, 2020

    Hi Richard

    First of all keep up the brilliant work, your blog is so useful.

    I have a couple of quick questions regarding the RRAS certificates, sorry if I have missed this information in your blog or on the Microsoft site.

    Does the SSTP certificate need IP security IKE intermediate application policy?

    Can the IKE and SSTP have the same public names on the certificate? Of do I need different names?

    How do you ensure each certificate is mapped to each vpn endpoint eg publicly signed certificate to the SSTP and the internally signed certificate to the IKE vpn

    Reply
    • Thanks for the kind words JD! 🙂

      The SSTP certificate does not require the IP security IKE intermediate EKU. Only the certificate used for IKEv2 needs that.

      The SSTP and IKE certificates can have the same public hostname, although it is recommended the SSTP certificate be issued by a public certification authority (CA) and the IKEv2 certificate be issued by your internal, private CA.

      You only have to “map” the SSTP certificate. You do that in the RRAS configuration. There’s no mapping or assignment required for IKEv2. It will automatically select the correct certificate, assuming you have the IP security IKE intermediate EKU configured correctly.

      Reply
      • JD

         /  May 2, 2020

        Thanks for your quick helpful response.

        So I only have to set the SSTP certificate in the security tab of the RRAS servers properties?

        Our internal CA uses ECDSE encryption but the public CA we use for web certificates only issues RSA certificates. I take these encryption types can’t be mixed? so if the vpn is configured for IKE using ECDSA it can’t failover to SSTP with and RSA certificate? I would need to separate VPN profiles?

        With all our users working remotely at the moment its very difficult to automate the vpn configuration. Can you just copy the Rasphone.pbk between users? after looking through the file it doesn’t seem to hold any personal information, are there any issues doing this?

        What are the typical certificate lifetimes do you see for user and machine certificates? or what would you recommend?
        A number of our users use multiple machines, would you recommend storing the users certificate in Active Directory for the user certificate?

        Thanks again
        John

      • Correct. Assign the SSTP certificate on the security tab of the VPN server properties and you’re good to go.

        Yes, you can use an EC certificate for IKEv2 and an RSA certificate for SSTP. No need to create separate profiles. I don’t believe just copying rasphone.pbk from one device to another will work. You can certainly try though. As for certificate lifetimes, typically 1 year is common for server certificates. There’s no value in storing certificates in Active Directory, so I would suggest avoiding that.

        FYI, you can get an EC TLS certificate from DigiCert quite easily. 🙂

  22. JD

     /  May 12, 2020

    Hi Richard

    Do you know if there are any issues when using a Microsoft CA to issue the vpn servers ikev2 certificate using ECDH_P256 algorithm?

    If I use the RAS and IAS server template and change is so I can issue ECDH_P256 using the Microsoft Software Key Storage Provider. then the IKEv2 VPN will not connect, you receive a warning stating it cannot find machine certificates (this is a user tunnel so no machine certificates). If I change the VPN to SSTP it connects fine using ECDH_P256 certificate.

    If I use the RAS and IAS server template and follow the Microsoft always on vpn instructions for configuring the template using RSA then the IKEv2 vpn connects without any issues.

    Root and Intermediate are ECDH_P384 certificates if that helps?

    Reply
    • JD

       /  May 13, 2020

      I think I may have found the issue.

      When you change the certificate template to use the Key Storage Provider and then change from RSA to P256 it will no longer let you add key encipherment to the certificate.

      Do you have any suggestions?

      Reply
      • EC uses Key Agreement, not Key Encipherment, so that’s expected. If you plan to use EC, make sure that both the server and client certificates use EC. You cannot mix RSA and EC keys for IKEv2.

      • JD

         /  May 18, 2020

        Ok its working now

        The user certificates have ECC Public Key and SHA256ECDSA Signature Algorithm

        When the server has a certificate with a RSA public key and SHA256ECDSA Signature Algorithm the connection works as expected.

        As soon as I change the server to a certificate ECC Public Key and SHA256ECDSA Signature Algorithm the connection fails with the warning/error about no machine certificates.
        Until I changed to a custom IPSec policy at both end as per your guide and the connection works again without any errors 🙂 🙂

        Is that what you would expect to happen?

        in my case it looks like a server with an RSA public key and client ECC public did work in the default configuration

        I don’t think I ever tried RSA client and server.

        next test in the lab is to test tpm private key storage but I believe that only works with users having RSA public keys?

        Thanks again for all your help

      • Correct. The key types must match when performing authentication. If the server is EC, the client must be also. It won’t work if the server is EC and the client is RSA, or vice versa.

        Also, I typically don’t recommend using EC certificates for user authentication because, as you have noticed, they aren’t supported for use with TPM. IMO the risk of certificate loss is greater than RSA encryption being compromised. 🙂

  23. JK

     /  May 16, 2020

    Hi Richard, you seem to be the de facto AOVPN pro on the internet and I appreciate the bog and documentation!

    I have a problem when using the Kemp load balancer that hasn’t been easy to solve, even for Kemp support. I started with a single RAS server configured to use IKEv2 machine certificates and verified that config works. A single client can connect directly to the server over the internet as planned using the machine cert issued from my PKI. Following your directions, when I put the Kemp load balancer inline with the single real server the client receives error 13801: IKE authentication credentials are unacceptable. I have the latest kemp firmware and fully patched win10 client and server 2019. The server is using the Kemp eth address as its default gateway when the load balancer is in line. Any ideas?

    Reply
    • That’s quite unusual you would get a 13801 by putting the Kemp load balancer inline only without any other changes. The only thing I can think of would be if the Kemp is configured for site-to-site VPN and instead of forwarding your IKEv2 VPN traffic it is responding itself instead?

      Reply
  24. We’ve got this setup and running fine thanks to these tutorials. However we’d like to get a non domain joined computer on the VPN. Sadly, I am unable to export the user certificate’s private key for the user as previously we set the certificate template not to allow the key to be exported. Am I missing something obvious, or do I need to make a new template?

    Reply
    • The best way to resolve this is to issue user certificates using Intune. It is technically possible to allow certificate to be exportable, but I’d strongly discourage that.

      Reply
      • Daniel Sayles

         /  June 3, 2020

        Richard, thanks so much for taking the time to reply. We’ll look into Intune, we’ve not used it yet.

      • Stu

         /  June 25, 2020

        Hi Richard, I’ve got a domain joined laptop and have deployed a certificate as a test than can have its private key exported. This laptop connects as expected with no problem. If I export the certificate and import it onto a non-domain joined laptop and create the profile that is same as the working laptop, when I try and connect I get a 13801 error in the RASclient log and I get a message of “IKE authentication credentials are unacceptable”. This is for user tunnel, which I thought would work on a non-domain joined machine. Also, I’m using Microsoft PEAP for authentication. Do you have any idea why the non-domain joined laptop cannot connect?

      • I’m assuming the user is logging on with a domain account on the non-domain joined laptop, right? I’d expect it to work, assuming the client trusted the CA that issued the user certificate. Did you make sure that the root CA certificate and any issuing CA certificates were imported correctly on the non-domain joined client?

  25. Hi Richard , Hope you are keeping well and safe.
    our VPN Server Authentication Cert will expire in the next 2 weeks, however i am unsure how to renew it. in certlm.msc, do we go for the option to 1. Renew certificate with the same key -2. renew certificate with new key – or request certificate with new key.

    Also I have notice all our devices have auto renew certificate , do I need to do anything to users devices after the VPN sever certificate has been renewed

    Your advise will be much appreciated.

    Many thanks in advance

    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.
  12. Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC | Richard M. Hicks Consulting, Inc.

Leave a 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: