Windows 10 Always On VPN is the replacement for Microsoft’s popular DirectAccess remote access solution. It provides the same seamless, transparent, always on remote connectivity as DirectAccess. Where DirectAccess relied heavily on classic on-premises infrastructure such as Active Directory and Group Policy, Always On VPN is infrastructure independent and is designed to be provisioned and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune.
Intune and Always On VPN
Until recently, provisioning Windows 10 Always On VPN connections involved manually creating a ProfileXML and uploading to Intune using a custom profile. This has proven to be challenging for many, as the process is unintuitive and error prone.
A recent Intune update now allows administrators to create a basic Windows 10 Always On VPN deployment. Although it still has its limitations, it will go a long way to making the adoption of Always On VPN easier.
Prerequisites
Certificates must first be provisioned to all clients before deploying Windows 10 Always On VPN using Intune. In addition, if using a third-party VPN client, the VPN plug-in software must be installed prior to deploying the VPN profile.
Test VPN Connection
It is recommended that a test VPN connection be created on a client machine locally before deploying an Always On VPN profile using Intune. This allows the administrator to test connectivity and validate Extensible Authentication Protocol (EAP) settings. Once complete, run the following PowerShell commands to extract the EAP configuration settings to a file for later publishing with Intune.
$Vpn = Get-VpnConnection -Name [Test VPN connection name]
$Xml = $Vpn.EapConfigXmlStream.InnerXml | Out-File .\eapconfig.xml -Encoding ASCII
Deploying Always On VPN with Intune
Follow the steps below to deploy an Always On VPN connection using Intune.
Create a VPN Profile
- Open the Microsoft Intune management portal.
- Click Device configuration.
- Click Profiles.
- Click Create profile.
- Enter a name for the VPN profile.
- Enter a description (optional).
- From the Platform drop-down menu select Windows 10 and later.
- From the Profile type drop-down menu select VPN.
- In the Settings section click Configure.
Define VPN Profile Settings
- Click Base VPN.
- Enter a name for the connection.
- Enter a description and provide the Fully Qualified Domain Name (FQDN) of the VPN server. If it will be the default server select True and click Add.
- Enter a description and provide the FQDN for any additional VPN servers, as required.
- From the Connection type drop-down list choose the preferred connection type.
- In the Always On section click Enable.
- Select Enable to Remember credentials at each logon (optional).
- Click Select a certificate.
- Choose a client authentication certificate and click Ok.
- Paste the contents of eapconfig.xml (saved previously) in the EAP Xml field.
- Click Ok.
Define Additional Settings
You can also configure the following optional VPN settings using Intune.
- Apps and Traffic Rules
- Conditional Access
- DNS Settings
- Proxy
- Split Tunneling
After configuring any required additional settings, click Create.
Assign VPN Profile
- Click Assignments.
- From the Assign to drop-down menu choose Selected Groups.
- Click Select groups to include.
- Choose an Azure Active Directory group to apply the VPN profile and click Select.
- Click Save.
Limitations
Although the ability to provision Always On VPN using Microsoft Intune without using a custom profile is welcome, it is not without its limitations. At the time of this writing, only Always On VPN user profiles can be configured. A device tunnel, which is optional, must be configured manually using a custom profile. In addition, the Intune user interface lacks the ability to define settings for the following parameters:
- Custom IKEv2 cryptography policy
- Exclusion routes
- Lockdown mode
To make changes to the default settings for any of the above parameters, a ProfileXML must be created manually and provisioned with Intune using a custom policy.
Additional Information
Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell
Windows 10 Always On VPN Certificate Requirements for IKEv2
Windows 10 Always On VPN and the Name Resolution Policy Table (NRPT)
Windows 10 Always On VPN Hands-On Training
Jason Jones
/ May 22, 2018Yup, getting there slowly – the VPN CA guidance should also be published soon including updated Intune steps
Richard M. Hicks
/ May 22, 2018Great, looking forward to it! 🙂
Jason Jones
/ June 15, 2018Live! https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/ad-ca-vpn-connectivity-windows10
Richard M. Hicks
/ June 15, 2018Excellent! 🙂
Florian TPG
/ May 22, 2018Nice article. As always 😉
froand
/ June 11, 2018Hi richard
Great article as always 🙂
Isn’t AOVPN only supported with IKEv2?
Richard M. Hicks
/ June 13, 2018No. Always On VPN not only works with IKEv2, but with SSTP, L2TP, and even PPTP. The latter two are legacy protocols and aren’t recommended, however. More details here: https://directaccess.richardhicks.com/2018/01/22/always-on-vpn-protocol-recommendations-for-windows-server-routing-and-remote-access-service-rras/.
Jason Jones
/ June 13, 2018There a couple of scenarios where only IKEv2 is supported – Lockdown VPN and Device Tunnel are only supported with the IKEv2 protocol
Richard M. Hicks
/ June 13, 2018I was aware that the device tunnel can only use IKEv2 but didn’t realize that lockdown VPN required it as well. I’ve not yet had a customer ask about that scenario, and haven’t done any testing myself with it either. Looking at the CSP I see that it is only deployed in the ./Device profile, so now that makes sense. 😉
Thanks for the clarification! 🙂
Zack
/ November 16, 2018I’m looking at deploying device tunnel through an intune custom profile. Could you post an example? What OMA-URI should be used?
Richard M. Hicks
/ November 17, 2018I’ve got a blog post in the works on this. 🙂 The OMA-URI for the device tunnel is ./Device/Vendor/MSFT/VPNv2/Example%20Profile%Name/ProfileXML.
Greg
/ February 17, 2019Any news on this Device Tunnelvia Intune deployment post?
Richard M. Hicks
/ February 23, 2019Sorry, not yet. It’s in the article queue though. Hope to have something published in the near future. 🙂
Greg
/ February 23, 2019I’ve since figured it out with the hint you gave the other user. It’s much the same as the user method!
Richard M. Hicks
/ February 23, 2019Correct. Just requires a slightly different OMA URI and some slight changes to ProfileXML. I will still publish something in the future though. 🙂
Greg
/ March 8, 2019I’m having some troubles with some of our device tunnels. I can pin this down mostly to poor routers at some of our sites and this will be remedied, but in the interim i’ve forced scheduled tasks running from a SYSTEM context to rasdial the connection every 5 minutes.
This works fine for the moment, but i’ve been wondering how one might implement an additional trigger for say mstsc.exe.
I’ve been looking at the anatomy of the VPNv2 CSP, but I can’t seem to make it translate nicely to the ProfileXML used in Intune.
Any tips or examples? Or should “AlwaysOn” trump everything else either way?
Richard M. Hicks
/ March 9, 2019Always On should be “always on”. 😉 It doesn’t always work like that, unfortunately. This has been a persistent issue plaguing many Always On VPN early adopters, to be honest. Microsoft has been struggling to with VPN tunnel persistence for quite some time. The good news is that Microsoft has released some updates recently to address these issues. My preliminary testing shows positive results. If you’re running at least Windows 10 1803, make sure you are fully up to date and test again. Hopefully you’ll see more consistent and stable connectivity then. 🙂
markcagatandavis
/ March 14, 2019Hi,
Wonderful article!! I am not sure if this is an issue or if it’s something else and you are able to assist me. I have setup VPN-AlwaysOn and everything works wonderfully! But I have a slight problem with host names… I can ping, nslookup and UNC to the FQDN of any server. I can ping to host names and nslookup host names, but I can’t UNC to host names… Would you happen to know why? I have followed your guide to the T. Any assistance would be greatly appreciated 🙂
Richard M. Hicks
/ March 15, 2019I’d have to assume the DNS suffix is not configured correctly. Look at that setting in your ProfileXML closely and make sure it matches your internal namespace.
Mark Klerkx
/ June 25, 2019Hello,
Currently I am implementing AOV at a customer and unfortunately InTune will not deploy the configuration.
The error is “not applicable” at the users in the assigned group.
I did some tests with changing Pro to Ent (because I thought it could be the Windows version).
The only difference with your tutorial is that we did not select a certificate.
Is that required? I don’t think so, because it could be blanc and I have some deployments at other customers which do not an InTune deployed certificate as well.
Do you have any clue what could be wrong?
Richard M. Hicks
/ June 25, 2019If your EAP configuration is configured to use client certificate authentication, then yes, you must select a certificate in Intune.
markklerkx
/ June 25, 2019Thank you for your quick reply!
It is all about certificates 🙂
The client certificate is deployed by Windows AD. Just a described in almost all tutorials.
The configuration on Windows 10 is refering to Root certificates and the NPS server.
I execute all actions as described in part 4 of this tutorial:
https://www.petenetlive.com/KB/Article/0001403
Afterwards, I made an “export” and copy the eapconfig part of the xml file to the InTune VPN profile.
So, I am not aware that I select anything look like “client certificate”.
Where should I look in this proces to find the cause?
Thank you in advance!!
Richard M. Hicks
/ June 25, 2019If you followed that guide to the letter you selected EAP authentication with Smart Card or Certificate. That would require that you specify that certificate in Intune when you create the profile. Another option would be to create your own custom ProfileXML and deploy that with Intune. I’ve documented that beginning at 7:53 in this YouTube video: https://www.youtube.com/watch?v=DQg0DLQA9ew.
Ronald Bevers
/ August 14, 2019Hello Richard,
Nice article, thanks for the great explanation.
Unfortunately I have an Issue. I followed your steps and just set the configuration at Base VPN. When I save the configuration I get the following error:
Unable to save due to invalid data. Update your data then try again: Device targeting should be used with Machine Authentication method only.
It seems it doesn’t except my EAP xml data. The data is generated as mentioned in your article on a reference device which has a working Always On VPN connection running. I also tried to use the XML data from the VPN_profile.ps1 file which has been generated while configuring the VPN connection, following Microsoft TechNet article. When I run this script on the device, the VPN connection comes available and works perfectly.
Do you have any ideas why I get this error message when configuring the VPN settings in Intune?
Richard M. Hicks
/ August 15, 2019I’ve not seen this message myself, but it sounds like perhaps you have the OMA-URI configured incorrectly? The clue is “Device targeting should be used with Machine Authentication method only”. The ./Device/Vendor/MSFT/VPNv2 URI is for the device tunnel. If you try to upload ProfileXML for a user tunnel (that includes user authentication) I would expect that error.
Ronald Bevers
/ August 18, 2019This would make sence, but I didn’t use any OM-URI setting to set up device tunnel.
So what I did is go to the following Microsoft article: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections
Here I found the EAP XML to use and changed the TrustedRootCA values and server names.
After this I compared this with the xml data I used from the PowerShell script to deploy Always On VPN and noticed that all the https:// links in the data where set to http:// (so without the s). I changed this in my configuration so all values would have https and after using this as the EAP XML data in the VPN configuration profile in Intune, it excepted the data.
So it wasn’t a device tunnel issue but clearly an error in the XML data. Strangely that this data is excepted when using the method described by Microsoft and using the PowerShell script from Microsoft which I used to created the VPN profile. I will also try to change the Powershell script to see if VPN still works and if so, I will just use https on all situations.
Richard M. Hicks
/ August 18, 2019The recommended best practice to configure EAP is to create a template connection and configure it using the UI. Once you’ve tested and validated that it works, you can export the EAP configuration to XML file using my PowerShell script found here: https://github.com/richardhicks/aovpn/blob/master/Get-EapConfiguration.ps1. You can upload the XML to Intune or add it to your existing ProfileXML.
Fabian Wolswijk
/ October 26, 2020I had this message today also. I reconfigured an existing device tunnel profile to an user tunnel profile and somehow Intune doesn’t let you save the configuration. I made a new profile for a user tunnel with exact the same configuration and settings and it saved just fine without this error.. Maybe it’s yhe order that Microsoft writes the settings away and thinks you’re tryinng to make an user tunnel with device specific settings becuase they were already there. Or maybe I’m talking just BS 🙂
Eitherway, this solved it for me!
Travis
/ September 3, 2019Hi Richard,
The field ‘authentication certificate’ where you have selected ‘VPN User Certificate’ – is this pulled from the VPN server once you’ve added the server entry.
We have a client who has added the VPN server but no certificates show up when selecting that option. It says “No certificates available. Create one first.”
We’re still learning about their environment so I don’t know the full details – Do you know why that might be?
Do we have to import the certificates into Intune — I think they might be using SCEP.
Thanks,
Travis
Richard M. Hicks
/ September 10, 2019When you deploy Always On VPN using the native Intune UI (as opposed to using custom ProfileXML) then you have to specify during the configuration which certificate to use for authentication. The only way Intune knows about this is if it is configured to deploy that certificate (using NDES/SCEP or PFX).
xsnakedoctor
/ October 11, 2019Hi Richard,
Thanks for posting all of this incredible information online. We’re looking to deploy AOVPN in our own environment in the coming months. At the moment, we’re using Meraki’s Client VPN solution but it has its shortcomings. One of the things we tried doing was a deployment of the VPN profile through Intune. There’s a field for the Eap Xml but Meraki’s solution requires PAP. I take it there’s no way to get the PAP Xml and use it in the same field? I’m not 100% on the technology so this may not even be possible or feasible. Hopefully that question makes sense! Not quite related to AOVPN but I’m looking forward to deploying the connection through Intune once we get AOVPN up and running.
Richard M. Hicks
/ October 11, 2019To begin, EAP and PAP are two different authentication protocols. Intune only supports EAP authentication for VPN profiles, so you’re kind of limited there. Also, Always On VPN supports only MS-CHAP v2 and EAP, no PAP. If you are using PAP because it is required by your MFA provider, you’ll need to find another MFA solution that supports one of these protocols.
Paddy Berger
/ January 23, 2020Hi Richard,
Is it possible to configure intune to push always on vpn to a laptop which is newly built and off the domain (i.e. brand new laptop, with no computer or user certificate). So one that is shipped directly to a user rather than pre-built by us first
Richard M. Hicks
/ January 30, 2020Absolutely. If you are planning to use client certificate authentication (highly recommended!) then you’ll also need to provision that certificate using Intune. You can do that using the Microsoft Intune PFX connector. Details here: https://docs.microsoft.com/en-us/intune/protect/certficates-pfx-configure.
Paddy Berger
/ February 4, 2020Ok, so what I am trying to achieve is configuring a brand new laptop shipped to a user, using autopilot to configure OOBE and also join to local domain (Hybrid Azure domain join), I was told that the laptop needs to be in the internal domain so that it is able to ping the DC to complete hybrid domain join. Therefore felt, vpn connection is required if the laptop is external, is this something doable?
Richard M. Hicks
/ February 7, 2020You can provision a device tunnel Always On VPN profile to your Autopilot devices to provide prelogon connectivity. This will allow you to domain-join devices remotely.
Zack
/ February 26, 2020How do we push the more secure VPN encryption settings via Intune Configuration Profile?
(e.g. “$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force”)
Richard M. Hicks
/ February 27, 2020If you are using IKEv2 and want to use custom cryptography settings, there are two ways to accomplish this. The first is to include the Custom Cryptography element in your ProfileXML and publish that using Intune. Alternatively you could use the native Intune UI to create the VPN profile, then deploy a PowerShell script to update the cryptography settings on the client post deployment. The first option is definitely preferred though. 🙂
Zack
/ February 27, 2020Thanks, that’s what I figured. I ended up using the first option, and it works well enough.
I wish the Intune VPN settings provided dropdowns for the encryption settings, like Intune’s BitLocker settings do.
Richard M. Hicks
/ February 27, 2020Hoping Microsoft adds it in the future. It would eliminate most of the need for using custom ProfileXML for the user tunnel. It’s still the only option for the device tunnel at this point though. :/
KHANH NGUYEN
/ February 27, 2020How you can add or export username and pwd in the Xml file?
Richard M. Hicks
/ February 28, 2020I’m not sure why you would want to do that, and it’s definitely not a good idea if you could, but I don’t believe it is possible. User credentials aren’t typically part of the VPN configuration anyway. They are provided by the user when they connect.
Geraldo
/ July 2, 2020Richard,
I keep receiving the same error when attempting the connection stating that there is no certificate to use for EAP. I am attempting to do the VPN tunnel using Intune and have deployed a user certificate utilizing NDES and my on-prem CA. This device is only Azure AD Joined, no hybrid domain joined but I have seen examples of this working. Any thoughts?
Richard M. Hicks
/ July 7, 2020I’m assuming the certificate is being delivered correctly and it appears in the user’s certificate store? If so, does it have a private key? Is it valid and completely trusted?
NotBillGates
/ July 7, 2020Hi Richard,
So I had previously built the AlwaysOn environment on premise and deployed with SCCM (ouch) but the client now is moving to an Azure AD joined device model. As such they want to use their existing AlwaysOn infrastructure for these devices. I’ve built out the NDES/SCEP environment so users and devices can get certificates which is working well. The device tunnel is deployed with a custom device configuration and I’ve used the above guide for deploying the user tunnel with the native VPN profiles option.
One question, does the connection type have to be IKEv2 for the user tunnel? When I created this on premise we used automatic, which is good as it will usually try SSTP and failback to IKEv2 I find, HTTPS tends to be less restricted out in the ether.
Do you know whether setting Automatic via Intune breaks the EAP as I notice the option disapears when you enable that.
Richard M. Hicks
/ July 7, 2020No, IKEv2 isn’t explicitly required for the user tunnel. You can easily set it to automatic and it will prefer SSTP and then use IKEv2 as a fallback.
Ronald
/ July 9, 2020As far as I can tell is that the order has changed when setting the protocol to automatic. First IKEv2 and next SSTP. After that the rest of the protocols. If you only want IKEv2 and SSTP, than disable the other ports on the RAS server.
Richard M. Hicks
/ July 10, 2020If you create a manual VPN connection, yes, Automatic prefers IKEv2 and uses SSTP as a fallback. However, when you create an Always On VPN connection it works in reverse. When you use Automatic with Always On VPN it prefers SSTP over IKEv2. You can see this in rasphone.pbk for an Always On VPN conneciton. VpnStrategy will be set to 6. Not sure why the behavior is different between manual VPN and Always On, but it is. :/
Scott K
/ July 23, 2020Hey Richard,
Quick question. I am in the process of deploying a new RootCA in the same AD Domain. My first test creating a User certificate worked, however it was not accepted by the VPN server, giving me the error “a certificate could not be found that can be used with this extensible authentication protocol”. The VPN already has the ROOTCA cert in its Root CAs location because it is an ADCS CA. What changes do I need to make to get AOVPN working with the new CA?
I can see in our current profile.xml that the thumbprint of the old RootCA is entered in duplicate. Is that needed to have two of the exact same lines for ? Do I just need to add the thumbprint of the RootCA cert to our current profile.xml? If so, is there a way to update this for end users without having to reinstall VPN?
Richard M. Hicks
/ July 23, 2020If you have already deployed the Always On VPN profile you will need to update the EAP configuration to reflect the new root CA, and also update the certificate filtering requirements if you’ve specified those. Commonly when I configure Always On VPN I use certificate filtering to ensure that a client authentication certificate from the specified root CA is selected. You’ll need to update that to make things work. Once you’ve got a working profile you can export the EAP configuration in XML format and use that for future connections. If you are using Intune you can simply upload this new EAP configuration XML and you’re good to go. If you are using SCCM or something else, you’ll have to run a PowerShell script to update existing VPN connections to use the new EAP configuration, or simply remove the profile entirely and re-create from scratch.
Matt
/ May 18, 2021Hello Richard,
We’ve been using AOVPN for over a year now and it’s worked great. We use SCCM for deployment. I’m just starting to test Intune now. I deployed a profile successfully using Intune. I use split tunneling and it has always worked great. However, for whatever reason, when I make a DNS name in the NRPT table to not use our internal DNS for it, it is not working when I deploy it through intune. It does show with no NameServers when I use Get-DnsClientNrptRule. However, when I ping the dns entry, it resolves to it’s internal IP and not it’s external IP like I want it to. Any ideas?
Richard M. Hicks
/ May 20, 2021That’s strange. I typically don’t use the NRPT, so I’ve not encountered this scenario myself. Are you using both the device tunnel and the user tunnel together? If so, it’s possible that it is resolving over the device tunnel.
Matt
/ May 21, 2021Hello Richard,
After more testing, I realized NRPT wasn’t working no matter how I deployed it. I then realized that DNSPolicyConfig was causing NRPT to be ignored. I setup a GPO to remove the registry entry again. It appears to come back so the GPO will keep removing it.
Richard M. Hicks
/ May 24, 2021Odd that it returns like that. Have to assume another GPO is adding it somewhere?
Matt
/ May 18, 2021Hi Richard,
I’m testing AOVPN by Intune. I noticed any time I make a change on the device configuration, it updates the computer as expected. Unfortunately, it clears the metric change as well. You have any methods of updating the metric at the same time Intune redeploys the AOVPN Device profile?
Richard M. Hicks
/ May 20, 2021This is going to be a problem until Microsoft introduces support for the interface metric in ProfileXML. When Intune needs to change settings in the VPN profile, it actually removes it entirely and redeploys it. As you’ve discovered, this means the interface metric value gets wiped out along with it. Typically you won’t be making changes to the configuration that often, but when you do, you’ll have to follow up with interface metric changes again. :/
Matt
/ May 25, 2021Hi, Richard. great news. I came across a way to update the metric automatically. I seen it on a Reddit post. We can simply use a GPO preference “INI File” update. I already tested it and it applies the metric automatically. Nice!!
File path: %appdata%\Microsoft\Network\Connections\Pbk\rasphone.pbk
Section Name: Name of vpn connection
Property Name: IpInterfaceMetric
Property Value: 4
Richard M. Hicks
/ May 25, 2021That’s a good solution if your devices are domain joined, for sure. 🙂
Patrick
/ June 21, 2021Is there any way to resync the AOVPN profile if a user mistakenly deleted the AOPVN profile?
Richard M. Hicks
/ June 21, 2021Endpoint Manager will automatically add the VPN profile on the next refresh cycle if someone deletes the Always On VPN profile. It will also be reapplied if you force sync. I do this often when I’m testing. 🙂
Patrick
/ June 21, 2021Hi, we have seen several deployments where it does redeploy right after the next refresh cycle or force sync. Sometimes it take a few minutes, but we have also seen it redeploys only after several hours or even one day.
Patrick
/ June 22, 2021Hi, I noticed an error in my previous comment. We have seen several deployments where it does NOT redeploy right after the next refresh cycle or force sync. Sometimes it take a few minutes, but we have also seen it redeploys only after several hours or even one day. So I was wondering if there is any other way to speed up the process
Richard M. Hicks
/ June 22, 2021That’s unusual. I’m not aware of any way to speed this up outside of issuing a device sync either in Endpoint Manager or on the client iteslf.
Charlee Ult
/ September 7, 2021Hi Richard,
I would like to setup forced tunnel VPN on azure to access resources both on azure and on prem. Current environment setup is – on prem connected via site to site VPN to azure. P2S will need meet security compliance due to split tunnelling, I believe not possible to route all traffic through the VPN?. Users are all currently remote, I have their devices managed in Intune. Can you suggest a few VPN solutions? Preferably would like to have a solution hosted on azure.
Richard M. Hicks
/ September 8, 2021You can enable force tunneling when using Azure VPN gateway or Azure Virtual WAN (or RRAS in Azure for that matter) and the client should be able to reach all Azure and on-premises resources (assuming routing and ACLs allow it). However, your user’s Internet traffic won’t pass. Azure does not allow traffic to the Internet when using force tunneling.
Ronald
/ September 9, 2021This is correct. The same for split tunneling, where it is not possible to direct traffic through the VPN tunnel and after that sending it from Azure to Internet. This is possible when you are using for example a traditional RAS server but is not supported and not possible with Azure VPN.
We have seen this for example when the customer is only allow to open a website based on a certain IP-address (IP-whitelisting on the website), which is the external IP of the customers office. With Azure VPN this will not work.
Charlee Ult
/ September 9, 2021Thanks Richard, how can I resolve this issue of not passing internet traffic?
Richard M. Hicks
/ September 14, 2021For individual sites, you could just add their IP address. Azure doesn’t support routing all traffic (0.0.0.0/0) to the Internet, however.
Rik Pasman
/ January 19, 2022Hi Richard,
We have a situation where we are replacing the AO VPN infrastructure at a client. This means a new certificate template, new NPS server, new VPN (RAS) server, new PKCS certificate configuration profile in Intune and a new VPN configuration profile in Intune. But still using the same root CA.
All these new components are configured using your best practices. We have a working implementation but now we face some issues in migrating from the old VPN connection to the newly configured VPN connection.
One thing we noticed is that the VPN connection is working with both the old and the new certificate (based on different certificate templates). We would have expected the VPN connection only to work with the certificate which is received from the PKCS configuration profile we select at “Authentication certificate” during the setup of the VPN configuration profile.
Can you explain why this is not working, or if we have configured something wrong?
It is a problem for us, because this is interfering with our migration plan.
With kind regards,
Rik Pasman
Richard M. Hicks
/ January 20, 2022Hi Rik. Which tunnel isn’t working as expected? Device tunnel or user tunnel? Or both?
Rik
/ January 21, 2022Hi Richard,
It is regarding a user tunnel on Azure Domain Joined devices.
Rik
Richard M. Hicks
/ January 21, 2022Ok, thanks for the clarification. If you are issuing certificates from the same root of trust, then any certificate issued by a CA in that hierarchy will be trusted for authentication if it has the Client Authentication EKU. Specifying the certificate in the VPN profile settings doesn’t change that. In fact, you don’t even have to set that setting and it will still work. Honestly, I’m not even sure why that setting is in Intune, really. The VPN profile is going to look in the local user certificate store for an appropriate certificate regardless. 🙂
Woz
/ February 14, 2022Hi Richard, Thanks for sharing knowledge on this. i have a question. for split tunneling, it requires to entire the destinations as IP addresses. However for Microsoft updates, Microsoft only publishes URLs. how do you tackle this problem?
Thank you in advance.
Richard M. Hicks
/ February 15, 2022If you are using split tunneling, Microsoft update traffic would go outside of the tunnel by default. Are thinking about exclusion routes with force tunneling, perhaps?
Rik Pasman
/ July 5, 2022Hi Richard,
In a previous reply on this post you mention the following:
“Absolutely. If you are planning to use client certificate authentication (highly recommended!) then you’ll also need to provision that certificate using Intune. You can do that using the Microsoft Intune PFX connector. Details here: https://docs.microsoft.com/en-us/intune/protect/certficates-pfx-configure.”
We also provision certificates this way, but what we see is that certificates aren’t renewed. When the expiration threshold expires, a second certificate is issued to the client. This results in a client with 2 valid certificates for the remaining time of the threshold.
How can we configure the environment, that either the certificate is being renewed, or the “old” certificate is removed upon issuing the “new” certificate?
Thanks
Rik
Richard M. Hicks
/ July 6, 2022That’s a side-effect of how the Intune certificate connector works, unfortunately. Unless it is causing problems for you, it’s easy to ignore. If you want to remove old certificates you’d have to write some PowerShell code to do that cleanup yourself.
Chris W
/ November 10, 2023Hi Richard,
I’ve been tearing my hair out trying to get device AOVPN to work pre-logon so that we can deploy devices remotely after ‘resealing’ devices using Autopilot pre-provisioning.
I’ve followed this doc (https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/trying-out-autopilot-hybrid-join-over-vpn-in-your-azure-lab/ba-p/1606723) to the letter; and everything works *except* the VPN connecting itself. If I log on as a local admin I can see that the VPN configuration and required device cert have made it to the machine during ESP; but for whatever reason the VPN isn’t connecting automatically.
What am I missing here? This setup was not initially done by me (I’ve only joined the business recently) but in following the above doc (and the NDES docs it links) a lot of it was already in place. Without tearing it down and starting again (which I can’t do as users are using the existing AOVPN) I can’t tell what I’m missing.
Thanks in advance!
Chris
Richard M. Hicks
/ November 10, 2023Hi Chris. Are you deploying your endpoints with Enterprise Edition or Professional Edition? If using Pro, there’s some additional work to do. Details here.
https://directaccess.richardhicks.com/2021/04/19/always-on-vpn-and-autopilot-hybrid-azure-ad-join/
Let me know!
Chris Walker
/ November 14, 2023Hi Richard,
Enterprise – I’ve seen your doc on that already 🙂
One thing I’m finding confusing is the relationship between our on-premise stuff and Azure. Does RADIUS still need to be involved? Or is NDES the only thing on-premise is doing?
Thanks!
Chris
Richard M. Hicks
/ November 14, 2023Yes, you’ll still need a RADIUS server either on-premises or in Azure that’s joined to your domain to provide authentication for the Always On VPN user tunnel. And you will need NDES or PKCS if you want to deliver certificates to endpoints managed with Intune. 🙂
Chris Walker
/ November 14, 2023Ugh. No actually my test device is Windows Pro. I didn’t even realise; I wiped it from USB and expected it to be Enterprise.
Testing your scripts currently. Hopefully I won’t be back 🙂
Richard M. Hicks
/ November 14, 2023😉
Chris Walker
/ November 14, 2023Yup, that appears to have worked.
We don’t have RADIUS set up for this, instead we have the NDES server provide a User certificate (via Intune Config Profile) which authenticates AOVPN that way.
I notice that the behaviour is that the Device VPN doesn’t connect automatically once a user has logged in; I just assumed it would remain connected constantly. I fine with how it is; but why is it this way? It’d be good to understand the functionality
Richard M. Hicks
/ November 14, 2023You must have RADIUS configured somewhere. NDES is only for certificate issuance. RADIUS performs the authentication with supplied credentials, in this case your user authentication certificate.
The device tunnel is supposed to stay connected at all times. However, in practice this doesn’t always happen. Honestly, though, it’s a welcome scenario. We don’t need the device tunnel once the user tunnel is connected, so if it drops it won’t affect anything anyway. 🙂
Chris Walker
/ November 15, 2023Nope – no RADIUS. I’ve triple checked this time! All our RADIUS server is doing is handling Access Point authentications.
Based on what I’ve seen in the configurations, we’re using an Azure Point-to-Site Always On User Tunnel using Azure Certificates for authentication; as documented here: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal
Thanks for your help; your site has been a valuable resource in figure out Microsoft’s eccentric mess 🙂
Richard M. Hicks
/ November 15, 2023Ok, in that case you wouldn’t need a RADIUS server. Don’t hesitate to reach out again if there’s anything else you need!