Internet 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.
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).
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).
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).
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
Matthew
/ May 14, 2018If 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.
Richard M. Hicks
/ May 16, 2018Yes, 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).
Tor Marius
/ January 21, 2019helo,
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!
Richard M. Hicks
/ January 21, 2019Error 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, 2019i 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?
Richard M. Hicks
/ January 22, 2019Shouldn’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.
Ian Burnell
/ July 25, 2018Richard – 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
Richard M. Hicks
/ July 25, 2018That 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, 2018Yes – 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…
Richard M. Hicks
/ July 30, 2018Error 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.
Drew
/ August 12, 2018I 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?
Drew
/ August 13, 2018I 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
Richard M. Hicks
/ August 14, 2018The 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. 🙂
Richard M. Hicks
/ August 14, 2018As 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. 🙂
urs egli
/ January 22, 2019Hello
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
Richard M. Hicks
/ January 23, 2019If 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. 😉
urs egli
/ January 23, 2019many thanks for clarification and the helpfull blog in many ways!
Richard M. Hicks
/ January 24, 2019My pleasure!
Gavin Ashton
/ April 1, 2020Facing 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?
Richard M. Hicks
/ April 1, 2020When 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.
oderbang
/ May 26, 2022Is there any downside to just using internal certificates for both SSTP and IKEv2 ?? all our workstations are domain joined and have our local CA int he Trusted root store anyway??
Richard M. Hicks
/ May 26, 2022Yes. If the CRL is unreachable for any reason your clients will fail to connect. If you’re confident your infrastructure is fully redundant and highly available, you can accept that risk and internal certificates will work just fine. However, public certification authorities have incredibly robust and resilient CRL infrastructure, most geographically disturbed using CDNs to ensure not only reliable operation but high performance as well. That’s why I push for public CA certificates as much as possible.
Public CA certificates are relatively inexpensive, but if cost is somehow a barrier to adoption you could always use the free Let’s Encrypt TLS certificates. It adds some administrative overhead because the certificates expire every 90 days, but the process of enrolling for them can be fully automated.
https://directaccess.richardhicks.com/2021/10/04/always-on-vpn-sstp-with-lets-encrypt-certificates/
Hope that helps!
Wes
/ February 18, 2019Hi 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?
Richard M. Hicks
/ February 23, 2019Correct. 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.
Joe
/ March 19, 2019Hi 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.
Richard M. Hicks
/ March 19, 2019Hi 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.
John Gilbert
/ May 5, 2021Hi Richard,
I am looking to restrict the certificates available to be chosen, by specifying an extension in the VPN certificate (which only this certificate will have).
Might this approach be of benefit to the individual who was looking to restrict the certificate?
Richard M. Hicks
/ May 5, 2021Indeed, and thanks for pointing that out. If a computer certificate is deployed to all devices, but not all devices require VPN access, a certificate could be issued to devices using a custom EKU OID. You could then configure the VPN server to accept only certificates with that custom OID using the following PowerShell command.
Set-VpnAuthProtocol -CertificateEKUsToAccept [custom EKU okd]
Kristof
/ March 20, 2019Hey 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
Richard M. Hicks
/ March 21, 2019Not to my knowledge. I would think a Windows Server 2008 R2 CA would work just fine for Always On VPN.
Andy Chips
/ May 14, 2019Hi 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.
Richard M. Hicks
/ May 14, 2019Common 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. 🙂
Andy Chips
/ May 14, 2019Wow – 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.
Richard M. Hicks
/ May 14, 2019Just experience my friend. 🙂 Let me know how it goes!
Andy Chips
/ May 16, 2019Success!
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.
Richard M. Hicks
/ May 16, 2019Great! 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. 🙂
Andy Chips
/ May 16, 2019Yes, of course. Doh.
Richard M. Hicks
/ May 17, 2019😉
Andy Chips
/ July 4, 2019Hi 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?
Richard M. Hicks
/ July 4, 2019If 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. :/
Andy Chips
/ July 4, 2019Richard,
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.
Richard M. Hicks
/ July 4, 2019I’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.
francisadu1
/ June 12, 2019Hi 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
Richard M. Hicks
/ June 13, 2019You 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.
francisadu1
/ June 14, 2019Thanks Richard . really appreciate
francisadu1
/ June 14, 2019Thanks 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?
Richard M. Hicks
/ June 14, 2019If 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”.
francisadu1
/ June 27, 2019Hi 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
Richard M. Hicks
/ June 27, 2019You’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?
francisadu1
/ June 27, 2019Hi Richard , thanks for the quick reply . I deployed powershell script with custome ProfileXML .
Richard M. Hicks
/ June 27, 2019Great. 🙂 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!
francisadu1
/ June 27, 2019Thanks . 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?
francisadu1
/ June 27, 2019Thanks . 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?
Richard M. Hicks
/ June 27, 2019Quite 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.
ecrgvp
/ June 19, 2019Hi 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?
Richard M. Hicks
/ June 19, 2019No, 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.
ecrgvp
/ June 19, 2019Thanks Richard.
Bailey
/ August 2, 2019Hi! 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!
Richard M. Hicks
/ August 3, 2019Most 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… 🙂
Igor
/ November 6, 2019Hello, 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.
Richard M. Hicks
/ November 10, 2019You 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?
Jan Olbrecht
/ July 31, 2020I’ve run into this as well and traced it down to our VPN server having multiple certs from the internal CA and not picking the right one for IKE. We fixed this by using
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -CertificateAdvertised $IKECert -PassThru
-Jan
Richard M. Hicks
/ August 1, 2020There are some cases where the certificate you define using Set-VpnAuthProtocol can be overridden. It can occur if there are multiple certificates for the same CA in the computer’s certificate store.
Tommy
/ November 20, 2019We 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?
Richard M. Hicks
/ November 21, 2019I 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/.
Tommy
/ March 10, 2020We’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.
Richard M. Hicks
/ March 11, 2020Oh 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. 🙂
Elliot
/ November 29, 2019Hi 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?
Richard M. Hicks
/ December 5, 2019That’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.
Pascal
/ November 18, 2020Hey Richard,
I have the same error today, and have been getting these for the past few months or so. Most strange thing is this always happens on thursday mornings. But always at random machines.
798 Errors are from the User tunnel.
13801 are errors we got from the Device tunnel.
If i connect the affected machine with a different method and run “gpupdate /force” the problem is solved. (for both tunnel types) We do use certificate auto enrollment.
If need, ill update on a later time.
Regards
Pascal
PS. You are my goto source for AOVpn stuff. Thanks for the bundles of information.
Richard M. Hicks
/ November 24, 2020I’m hearing others report similar issues where authentication fails until the client updates group policy, then it starts working again. No idea what the issue is yet. Let me know if you learn something interesting though. 🙂
Raphael Eymann
/ January 31, 2021Did someone find a solution for this? We have the same problem – clients are connecting fine but we have everyday a random client failing with 13801. After gpupdate everything is fine. It cant find the source of this error.
Richard M. Hicks
/ February 5, 2021I certainly haven’t. Doesn’t happen too often, but when it does it is terribly frustrating.
Pascal D
/ February 6, 2021I have posibaly found the issue on out end. CRL isent exposed to the internet. So every 3 weeks with a 2 week delta you have this issue.
Solution is to move that date to 13 weeks and no delta. Rising this issue only 4 times a year or setting up a small website with your crl.
User tunnel sstp has an option to completely skip crl check with a register setting.
Sorry for bad typing. I am on a mobile device.
Richard M. Hicks
/ February 10, 2021Thanks Pascal. As an FYI, this is why it is recommended to use a public certificate for SSTP. No issues with CRL checks and you don’t have to disable them to get it to work. 🙂
John
/ January 23, 2020Hi,
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.
Richard M. Hicks
/ January 30, 2020If you are seeing “random” 809 errors that could be related to load balancer configuration. Details here:
https://directaccess.richardhicks.com/2018/09/17/always-on-vpn-ikev2-load-balancing-with-kemp-loadmaster/
https://directaccess.richardhicks.com/2019/03/11/always-on-vpn-ikev2-load-balancing-with-f5-big-ip/
https://directaccess.richardhicks.com/2020/01/20/always-on-vpn-ikev2-load-balancing-with-citrix-netscaler-adc/
William
/ March 9, 2020Hi 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 ,
Richard M. Hicks
/ March 10, 2020So 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.
Matthew
/ March 31, 2020Hi 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.
Richard M. Hicks
/ March 31, 2020That 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. 🙂
Matthew
/ April 1, 2020Hi, 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, 2020Hi –
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
Richard M. Hicks
/ April 1, 2020Thanks for the insight, Nat! 🙂
Daniel Bryant
/ April 30, 2023I am experiencing the same issue with NHS Smartcards removing all user certs when the Smartcard is removed. We are running the latest IA agent but no luck. Just wondered if you managed to find a fix?
Shazzad
/ April 4, 2020Hi,
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?
Richard M. Hicks
/ April 5, 2020Make 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.
Thomas
/ May 23, 2020Hi 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
Richard M. Hicks
/ May 25, 2020If 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.
Matt
/ April 9, 2020Hello 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?
Richard M. Hicks
/ April 10, 2020The 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.
Shad Behnke
/ April 22, 2020Hello 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!
Richard M. Hicks
/ April 22, 2020Unusual. When the device tunnel is up is the client resolving the FQDN for the user tunnel correctly?
Shad Behnke
/ April 23, 2020Got 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!
JD
/ May 1, 2020Hi 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
Richard M. Hicks
/ May 1, 2020Thanks 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.
JD
/ May 2, 2020Thanks 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
Richard M. Hicks
/ May 2, 2020Correct. 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. 🙂
JD
/ May 12, 2020Hi 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?
JD
/ May 13, 2020I 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?
Richard M. Hicks
/ May 14, 2020EC 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, 2020Ok 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
Richard M. Hicks
/ May 18, 2020Correct. 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. 🙂
JK
/ May 16, 2020Hi 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?
Richard M. Hicks
/ May 18, 2020That’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?
djsayles
/ May 22, 2020We’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?
Richard M. Hicks
/ May 22, 2020The 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.
Daniel Sayles
/ June 3, 2020Richard, thanks so much for taking the time to reply. We’ll look into Intune, we’ve not used it yet.
Stu
/ June 25, 2020Hi 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?
Richard M. Hicks
/ June 29, 2020I’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?
francisadu1
/ June 4, 2020Hi 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
Richard M. Hicks
/ June 4, 2020I’d suggest renewing the certificate with a new key. Nothing should be required on the client side to support this.
Michael Panagos
/ July 16, 2020For device tunnel Always On VPN, do you know how to tell the Windows 10 VPN client which certificate to select if there are multiple in the computer’s personal certificate store? It seems to choose the newest certificate and we are seeing some Azure certificates (we are using hybrid domain join) being selected instead of the one from our internal CA. Looking at the VPNv2 CSP spec (https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp), there looks to be a “NativeProfile/Authentication/Certificate/Issuer” value that is coming soon.
Richard M. Hicks
/ July 16, 2020Best way to do this is to use Set-VpnAuthProtocol -RootCertificateToAccept and specify the trusted CA to use for the connection. Have a look at the Server Configuration section of this post: https://directaccess.richardhicks.com/2017/12/11/always-on-vpn-windows-10-device-tunnel-step-by-step-configuration-using-powershell/.
Michael Panagos
/ July 16, 2020I very much appreciate the response but the issue is not with the server insomuch as with the clients. The Windows 10 clients have multiple certificates in the machine store and they are choosing the wrong certificate to use and failing. I would like to ensure the Windows 10 devices are picking the correct certificate to identify themselves.
Richard M. Hicks
/ July 16, 2020Correct. When you make this change on the server, the server will tell the client which CA is trusted. The client will then choose a certificate issued by that CA.
Beau
/ August 9, 2020I’m having the same/similar problem Michael Panagos is. I have a “Computer” and “VPN” cert (with a custom EKU) issued from the same CA, and sometimes the machine tunnel will try to use the “Computer” template cert instead of the “VPN” templated cert. I have the CertificateEKUsToAccept configured on the server, specifying our custom EKU, but it seems to not be used when selecting a certificate. Is this normal?
Richard M. Hicks
/ August 10, 2020I would expect that to work, but I haven’t done any testing myself with this very specific use case. Did you also define CertificateAdvertised as well? If not, perhaps give that a shot and let me know what you find.
IJustKnowStuff
/ August 28, 2020Hi Richard, I’ve since found the problem. There’s also an option to configure the Device Tunnel on the client to filter for the EKU.
Set-VPNConnection -Name $ProfileName -MachineCertificateEKUFilter $CustomEKU
After including this as part of the tunnel configuration on my devies, it resolved all of my problems related to the certificate selection. There’s also the option “MachineCertificateIssuerFilter” to specify the Issuer if desired.
I don’t have “CertificateAdvertised” configured on the server, and honestly I still don’t 100% understand what that configuration does, even after reading Microsoft’s page on the Set-VpnAuthProtocol command.
Richard M. Hicks
/ August 28, 2020Glad you got it worked out!
Charles
/ October 5, 2020Hi Richard,
Can you please suggest Any other possible solution in the below concept?
REQUIREMENT: Windows 10 Autopilot:
Our goal is that when the new user logs in to the new Windows 10 laptop using his Office 365 credentials from the external network, the new user will be able to start his project work without any contact with the IT staff.
The below configuration is needed when the user login using Office 365 credentials For the first time.
1) Join Azure AD,
2) Enroll the device in Intune,
3) Install Apps and Policies as client required,
4) Joined the machine On-premise AD
5) VPN connect automatically
I have configured the below steps in Intune that are required during login using Office 365 credentials For the first time:
1) Need Join Azure AD,
2) Enrollment the device in Intune,
3) Install Apps and Policies as client required,
4) Joined the machine On-premise AD
5) VPN connect automatically
Final Step – After the machine joined to the On-premise domain its need to be connected to the always-on VPN for login the machine using domain account – I am stuck in this step
In a Hybrid environment autopilot features Microsoft suggests:
External users can use the VPN to communicate the On-premise Environment during autopilot.
Client Environment have used Always-on and SonicWALL VPN
Note: I already achieved the Hybrid autopilot features in Windows 10 machine using SonicWALL VPN and its working perfectly and meets our requirement. Also, I showed the demo with Client
Client request to achieve the above features using Always-on VPN
I tried to do the achieved the Hybrid autopilot features in Windows 10 machine using Always-on VPN But Facing issue.
Issue – After enrolled in the machine the always-on VPN is not connected automatically.
The client has configured the always-on VPN in the below procedure in their On-premise environment.
1) User-Based VPN – how always-on VPN worked user-based means, the user needs to log in the machine using domain credentials and install the root certificate, after install, the root certificate, the VPN network adapter is connected automatically.
But our goal is after enrolling the new machine the VPN should connect automatically – I have configured the VPN adapter and root certificate using Intune (the Intune is pushed the policies when the device during enrollment at that time.)
Note: the VPN adapter configured and the certificate is installed perfectly. here the issue is – Intune has pushed the root certificate to the system account, not in domain account. But the certificate is needed to be installed for the domain account.
2) Device-Based VPN – the client has configured one GPO in on-premise AD and that GPO has pushed the policy, in particular OU and GROUP. during domain Join the machine need to place in that OU.
If the machine is not placed in the OU then the VPN will not be working. – During the first login the machine should be connected to their network for pushing the GPO.
OUR issue is – when I connect the machine from an external network it requires a VPN for login with a domain account. But for connecting the always-on VPN the machine should be in the client network for pushing the GPO to the machine.
My Suggestion – Client needs to change the ROOT certificate configuration in the VPN server (like, when we install the certificate in the system account the VPN should be connected)
Richard M. Hicks
/ October 13, 2020Using the device tunnel with Autopilot definitely works, as I know some of my systems management friends are doing this today. As long as the VPN server supports device certificate authentication and the certificate is deployed to the device before first logon, your user should be able to log on to the domain without cached credentials. If the device tunnel isn’t starting automatically, it could be because the device isn’t running enterprise edition.
Colin
/ October 26, 2020Rich, when the VPN server (RAS server) certificate is expiring, I assume it will not auto renew because it was manually requested correct? So what would be the process for renewing this one?
Richard M. Hicks
/ October 26, 2020Automatic renewal can be configured if you select the option to “use subject information from existing certificates for autoenrollment renewal requests”. This is on the Subject Name tab of the certificate template properties below the “Supply in the request” button. If you enable this setting and configure the VPN server to use certificate autoenrollment via GPO, it should renew automatically going forward. You can do this before the certificate expires and make sure it renews successfully. You can even test it beforehand by right-clicking the certificate template and choosing “Reenroll all certificate holders” to force it to renew before expiration. If you want to renew it manually, you use the same process you used to create it in the first place.
Colin
/ October 26, 2020The template for the certificate is set to 2003 compatibility mode and that seems to make the option you mentioned grayed out. Is there any hard in changing the compatibility mode of this certificate template to something higher that supports the option, like 2012 R2 or something like that? If I can do that then I will change the setting and force a renew like you said and all should be well.
Richard M. Hicks
/ October 26, 2020In that case you will have to re-create the template. You can’t change the compatibility mode once you’ve saved the template once. 🙂
Colin
/ October 27, 2020If I re-create the template does that mean I cannot auto renew the existing certificate and will have to create/request a new one?
If I have to create a new one, does it affect or impact anything that requires my attention outside of just installing the new certificate on the VPN server?
Do the renew with same key or renew with new key right-click options work in this scenario?
Richard M. Hicks
/ October 27, 2020If you re-create the template using the same name I think it will automatically renew. You can test that for sure though. Best to renew with a new key and I believe the right-click options will work. I’d suggest forcing an automatic renewal though just to know that is working.
Colin
/ October 28, 2020If I edit/manage the existing template it is acting like I can change the compatibility mode. Are you saying it can’t be changed for a technical reason or can’t be done at all? I ask because it looks like it will let me make the change.
Sorry for the barrage of questions surrounding this, I just don’t want to cause an issue to many people when remote work is so important right now.
Richard M. Hicks
/ October 28, 2020I though it wouldn’t let you change it after it was deployed. If it will let you, go for it! 🙂
Colin
/ November 2, 2020So I changed the compatibility settings from 2003/XP to 2016/2016 and it enabled the option to use the existing subject name for renewal. I forced all certificate holders to renew, did a gpupdate on the server and it updated the certificate with a new expiration date while retaining all the settings etc..
I did notice the schema number of the template did not change from 2 but it did increment on the version to 100.1, 100.2, 100.3 or something like that.
TLDR; Changing the compatibility mode, ticking the setting to use the same subject name, and forcing a renewal from the template appears to have worked.
Richard M. Hicks
/ November 2, 2020Awesome. 🙂
Fredrik
/ December 9, 2020Hi Richard,
We are testing/evaluating AOV at our office.
We are using DA today and we want the user experience to be the same, connect automatically.
We use smart card login for our clients.
We are using device and user tunnel.
Our setup is IKEv2 and EAP using smart card login for user tunnel (Server 2016). It is working but we have one issue. User tunnel should connect automatically after user logged on to the computer.
But today the user must click on VPN user tunnel connection, connect, enter pin-code for smart-card and then we are connected.
My question is: Is it possible to get auto-connect using smart card authentication?
Richard M. Hicks
/ December 9, 2020I don’t believe you will get a fully seamless user tunnel connection using smart cards, unfortunately. The user must enter their PIN, which obviously requires user interaction. I’m not sure there’s anything you can do about that.
Raphael Eymann
/ January 26, 2021I am using RAS Server 2019 with Windows 10 Clients. After changing CA to SHA256 and renrolling all certs it is working fine. Just one client has Error 13801 but the client cert is fine. I checked multiple settings but nothing helped with this client.
Kirsty
/ February 1, 2021Hi.
I’m trying to run the User VPN tunnel when we have 2 users certs from different CAs.
We’re swapping our PKI service so i’m trying to make this as seamless as possible!
I can add both thumbprints into the profile XML delivered by Intune.
I have both root & intermediate certs installed on the clients and the servers
I have set the VPN servers to use the old/existing Root cert as the default.
The VPN connects automatically if i have the old/existing user cert.
As soon as the new cert installs the VPN won’t connect. The error is the 812 code & auth method used by the server.
If i delete the new cert it connects again.
Is it even possible to do this?
Richard M. Hicks
/ February 5, 2021Interesting dilemma. The issue here is the NPS policy can only be configured to use one certificate. I’m not sure how to get around this. It might be possible to create second policy that uses the new certificate, but you’d have to figure out a way to differentiate client requests. Perhaps moving users from one group to another? You could then have two NPS policies that apply to different groups, each using a different certificate.
KIrsty
/ February 8, 2021Yeah its a little frustrating!. Does it mean that the 2 client certs can’t exist at the same time? So when we do have to swap out the PKI service its going to be a big bang approach?
Richard M. Hicks
/ February 10, 2021I’m not sure. I’d have to do some testing to see if there’s a workaround. It might be possible, but would require different NPS policies.
Johan
/ February 19, 2021Hi!
Thanks for this superbly helpful blog! I have a question regarding user tunnel authentication: You mention that it is best practice to authenticate using a user certificate. Why is this preferable and which alternative would present the least disadvantages?
I ask because this will require a user to have logged in on the computer on-premises so that auto-enrollment of a user certificate can occur before being able to open a user tunnel remotely. This presents a problem for us during these times, where we would like to send the computer home to a user ready to go.
Kind regards,
Johan
Richard M. Hicks
/ February 24, 2021You could switch to MS-CHAPv2, but this presents a security risk. In this scenario, it would be best to also integrate MFA to mitigate the risk of someone logging in with lost/stolen credentials. Alternatively, you could use Intune to deploy certificates to users in the field. That would be the preferred method.
rommel kast
/ March 5, 2021Hi Richard,
Is it required to have a public accessible crl for ao vpn ikev2? I did read your sstp crl error blog post, but does this also apply to ikev2?
Regards,
Richard M. Hicks
/ March 9, 2021No, just the SSTP TLS certificate.
IJustKnowStuff
/ March 15, 2021Does the that mean you could have two certificates?
One cert generated with your internal PKI for IKEv2 with the “IP security and IKE intermediate” EKU, and then a separate SSTP SSL certificate that doesn’t require the IKE EKU?
Both would have the appropriate CN and SAN entries required still.
Richard M. Hicks
/ March 16, 2021Absolutely. This is how I’ve configured every single VPN server I’ve ever deployed. 🙂 I use a TLS certificate for SSTP that’s issued by a public CA, and a certificate issued by the private internal CA for IKEv2/IPsec. Each certificate will have the public FQDN as the subject name.
IJustKnowStuff
/ March 16, 2021Just to clarify, in your use cases, does your private internal CA that issued the RRAS Server’s IKEv2/IPsec cert have a public CRL? Or does the client not query CRL when it’s connecting to the RRAS server when establishing an IKEv2 connection.
Richard M. Hicks
/ March 17, 2021No. The certificate used for IPsec, issued by your internal CA, does not require the CRL to be publicly available.
Chris Cooke
/ April 13, 2021Hi Richard,
we have deployed AOVPN using machine certificate authentication. The user/client machine certificates are configured with the relevant extensions, the server certificates are also configured with the relevant extensions. All works fine on the whole. We have a strange issue whereby random workstations that have a valid certificate get IKE authentication credentials are unacceptable error for no apparent reason. The VPN server refuses to connect the client. This error then ceases after approx 4 hours and the client machine can connect again. Is this a known Windows 10 issue, or am I missing something?
Many thanks in advance.
Chris Cooke
Richard M. Hicks
/ April 13, 2021That’s quite odd. It sounds like a bug to me, to be honest. If it works once, then fails, then works again later, clearly it isn’t a certificate or configuration issue. The only thing I can think of that would be potentially problematic is not including the “IP security IKE intermediate” EKU on the certificate used for IKE/IPsec. That can certainly cause issues like this.
Chris Cooke
/ April 14, 2021Hi Richard,
many thanks for the reply. The client certificate is configured as follows:
IP security IKE Intermediate (1.3.6.1.5.5.8.2.2)
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
The VPN server certificate itself is configured as follows:
CN = vpn.sherryfitz.ie
EKU as per above.
Furthermore the VPN server is pulling the client certificate as per above via group policy auto enrolment. Might that be an issue?
Many thanks again.
Chris.
Richard M. Hicks
/ April 14, 2021Possibly. Best way to know for sure is to remove it and test. I doubt that’s the issue, but it’s a good idea to at least eliminate the possibilyt.
IJustKnowStuff
/ April 13, 2021Do the problem devices have more than one certificate in the Computer store with the same name? That sounds very similar to a problem I had when devices were presenting the wrong certificate to the RRAS server.
Our resolution was to use a custom EKU for the device cert, and configure the clients using “Set-VpnConnection -MachineCertificateEKUFilter $CustomEKU” to ensure the correct machine certificate was being used.
This way you are 100% sure the correct certificate is being selected.
Unless it’s just your Set-VpnConnectionIPsecConfiguration settings being mismatched.
For troubleshooting, can also suggest manually attempting the connection using “rasphone.exe” as it generally provides more informative errors.
Chris Cooke
/ April 15, 2021Thanks guys. We’ve attempted the fixes as outlined. Hopefully it does the trick. I’ll leave things a few days and I’ll reply with confirmation.
Many thanks again.
Chris.
Martin B
/ July 15, 2021I found an issue today were, although auto renew works in the office, a client that had been connected via AOVPN 100% of the time didn’t auto renew. As so as it had an alternative connection it renewed the certificate.
Richard M. Hicks
/ July 15, 2021Interesting. Automatic certificate renewal *should* work over VPN. It would be interesting to learn more about why it was failing in this scenario.
Yanal Mash
/ August 24, 2021Hello Richard, thank you for this site and all the info you put together for AlwaysON, you made my life so much easier, thank you!
I have a question. We are using Kemp for Geo balancing but it’s not working as expected. When using google DNS, for example, the source IP of the recursive lookups is google’s IP, which sometimes is a location far and Kemp sends clients to the wrong site. There is an OPT (client address) option in TCP that google uses to show the originating client IP, but Kemp doesn’t use that. So basically I can’t use Location based balancing. Support could not help.
What I ended up with is having to use Fixed Weighted load balacning making one site primary and one secondary. But for that to work, I need to use two different URLs depending on the user location. For that to work, I have to use a SAN cert. While is works fine with SSTP, it’s not working for IKE, it seems that IKE only looks at the subject name, not the SANs.
Is there anyway to make IKE work with a SAN cert? or will I have to deploy multiple servers, one for each of the URLs I want to use?
Richard M. Hicks
/ August 25, 2021This is a fundamental limitation for most geographic load balancers in that the client’s location is determined by the source IP address of the DNS query, which is can be very different from the location of the client itself. It works reasonably well in most scenarios, but there are times when it doesn’t. In my experience, geographic load balancing is better than DNS round-robin (or nothing at all), but it isn’t 100% accurate.
As for making IKEv2 work with SAN certificates, that shouldn’t be a problem. I configure that all the time and my lab is currently configured like that now. It should work for you as well.
Nirzhar
/ January 12, 2022Hi Richard,
Great articles. Your articles has helped me a lot to understand the concept and how to configure. I have one question. Is it possible to use certificate from external provider (e.g. Comodo, Entrust, etc) on VPN server? This requirement has been arisen from Security team. The certificate generated from internal CA has issuer name (CA server name) and they find this a risk to have it in a server that is exposed externally. Can you point me to right direction please?
Thanks
Richard M. Hicks
/ January 12, 2022You’re talking about the certificate used for IKEv2 specifically, not the certificate used for TLS and SSTP, right?
Nirzhar
/ January 13, 2022Hi Richard,
Yes it is for IKEv2. I am not enabling SSTP. Thanks
Richard M. Hicks
/ January 13, 2022Great, thanks for the clarification. So, it is technically possible to use a public certificate for the IKEv2 certificate. However, this introduces a serious security vulnerability. Specifically, anyone with a certificate from the same public CA would be able to authenticate their device to your VPN server. Also, the IKEv2 certificate on the VPN server isn’t exposed publicly like a TLS certificate is, so there’s no real risk to using an internal certificate.
Nirzhar
/ January 14, 2022Thank you Richard for explaining that. I have one more question if you do not mind. In the case of SSL certificate, it is easy to check the issuer and the details of the certificate. In the case of IKEv2, is it possible for an attacker to retrieve the certificate details? If so, how can this risk be eliminated or minimized?
Richard M. Hicks
/ January 14, 2022I’m not sure, to be honest. It certainly isn’t easy. You’d probably have to craft some custom packets to send to the server to see the certificate. There might be some tools out there that do this, but again, I’m not certain. I’ll do some research on this and let you know if I learn anything more.
Nirzhar
/ April 22, 2022Hi Richard,
We have successfully manged to connect and connect to all resources internally. However we are facing another issue.
We are seeing a strange behaviour. Both tunnel connects and can reach all resources internally. However after few minute of client being inactive, connection drops. We have tested it to be between 4-5 min. Both tunnel shows connected and RAS still shows it active. Using rasdial to disconnect and reconnect works but it stops working again after few minutes. If we let the laptop to go to sleep and log back in everything is back to normal but drops again after being inactive for few minutes. We have tried changing IKEv2 idle time out from default 5 min to 120 min but it did not helped.
Could you point us in some right direction please? Have you or anyone in the tech community encountered such issue before? Any help would be appreciated.
Richard M. Hicks
/ April 22, 2022This isn’t something I’ve encountered myself. Sounds unusual, for sure. Is this happening for both tunnels? And are both user and device tunnels using IKEv2?
Nirzhar
/ April 22, 2022Yes it is happening for both tunnels. They both using IKEv2. We have played around with RAS IKEv2 idle timeout and session timeout in Load balancer but no luck so far. We have opened a case with MS, going through the logs they think it could be something in the network but we have not been able to locate it yet.
Richard M. Hicks
/ April 22, 2022I’d suggest switching the user tunnel to SSTP. I’d be curious to see if it has something to do with both tunnels using IKEv2. Also, is your load balancer configured to pass the client’s source IP address to the RRAS server? If not, that can certainly cause problems for IKEv2.
Nirzhar
/ April 22, 2022Yes Load balancer is configured to pass the traffic with client’s IP address and we see this reaching RAS server. It is working when the client is not idle and has active session. We can see both tunnel is being used and all good. It drops when the session goes idle.
Richard M. Hicks
/ April 22, 2022Do you see this same behavior with only a single tunnel established?
Nirzhar
/ April 22, 2022Yes. Tested removing device tunnel. With user tunnel only also shows the same behaviour. Havent tested the other way though
Richard M. Hicks
/ April 22, 2022Unusual. It’s possible a network device inline is timing out the connection. Although it’s UDP, so perhaps it is related to NAT. Maybe a state table flushing too quickly? 5 minutes would be out of the ordinary, but you never know. It would be interesting to put a client on the same subnet as the VPN server and see if it still exhibits the same behavior.
The other things to think about are GPOs if your servers or clients are domain-joined. It might be worthwhile to place them in a dedicated GPO with blocked inheritance to make sure some policy isn’t interfering. In addition, if you have any non-Microsoft security software running on the server or client it would be best to remove them (not just disable them) to ensure they aren’t the culprit.
Nirzhar
/ May 5, 2022Thanks for your guidance Richard. We managed to find it. Load balancer was constantly changing the source port when forwarding traffic to the server. RAS server would expect port 500/4500 but Load balancer was sending them using high ports above 25000 and even that was changing. When we configured LB to keep the source port constant, it never dropped. It has been about a week no issues so far. Microsoft hasn’t mentioned anywhere that the source port has to be constant. You should test this and add it to your documentation. We spent a lot of time on this, it might help some other people.
However we are seeing another hiccup. When we trialled failover scenario, it is taking about 5 min to failover to second server. We tried lowering network outage time in RAS but that did not helped. There are some session timeout values in LB but it is already 1 min. Any idea how we can lower this. Mobility is set to default of 30 min?
Richard M. Hicks
/ May 5, 2022If you are using IKEv2 with multiple VPN servers behind a load balancer I’d suggest disabling IKE mobility on your endpoints. It seems to help during failover scenarios based on my experience. However, there’s almost always a delay even under the best circumstnaces. It never seems to failover instantly, unfortunately.
Nirzhar
/ May 6, 2022Hi Richard,
If I disable Ikev2 mobility, doesnt that cause issue when user move between different access points. Is there any other downside of disabling mobility?
You mentioned there is always some delay in failing over. From your experience, how long does it take normally (in the case of multiple vpn server behind load balancer)? At the moment I am seeing 2-5 min in our setup.
Richard M. Hicks
/ May 6, 2022Not for Always On VPN. It is common for the device tunnel to take several minutes to failover. I would say 2-5 minutes isn’t out of the ordinary based on my experience.
Nirzhar
/ January 17, 2022Thank you Richard for the explanation.
sukafun
/ April 4, 2022Hi Richard, I’ve removed the internal CA root certs and user cert from a domain joined machine and switched auth to Microsoft Secure password (EAP-MSCHAP v2). I was able to connect to VPN just using my username & password.
Does that mean IKEv2 is not as secure as SSTP which must use a user cert?
Is there anyway to enforce server to accept only EAP + user cert?
If a user creds got compromised, an attacker can create a VPN client manually and connect to VPN.
Cheers
Suka
Richard M. Hicks
/ April 5, 2022Not at all. If you could connect with just your username and password, that tells me you have different authentication methods configured that shouldn’t be. Your NPS policy should require a certificate only and not accept username/password. Have a close look at that and see what you can find.
sukafun
/ April 4, 2022I actually restarted the computer and it came up with the IKE authentication creds error due to the fact that the root cert is missing.
As a minimum you need to have the root cert installed in the VPN client I guess because we ran this command on the server?
$VPNRootCertAuthority = “RootCA”
$RootCACert = (Get-ChildItem -Path cert:LocalMachine\root | Where-Object {$_.Subject -Like “*$VPNRootCertAuthority*” })
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru
Richard M. Hicks
/ April 5, 2022Those commands are only for the device tunnel. They won’t have any effect for user tunnel connections using IKEv2.
sukafun
/ April 5, 2022Hi Richard again, in regards to this command Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept
I understand that it specifies the authentication protocols that are allowed and as you can see MS-CHAPv2 is not specified. So how come the server accepts EAP-MS-CHAPv2 requests?
Richard M. Hicks
/ April 6, 2022I’d have a look at your NPS policy. It may be allowed there within EAP.
Noa
/ March 1, 2023Can i deploy Always On VPN without IPsec IKE Intermediate and only with Server Authentification?
Richard M. Hicks
/ March 1, 2023Technically, yes. However, if you have more than one certificate in the VPN server’s computer certificate store that includes the Server Authentication EKU, RRAS may select the wrong certificate to use for IPsec. It’s highly recommended that your IKEv2/IPsec certificate include the IP security IKE intermediate EKU to ensure proper operation.