Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft IntuneWindows 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

  1. Open the Microsoft Intune management portal.
  2. Click Device configuration.
  3. Click Profiles.
  4. Click Create profile.

Deploying Windows 10 Always On VPN with Microsoft Intune

  1. Enter a name for the VPN profile.
  2. Enter a description (optional).
  3. From the Platform drop-down menu select Windows 10 and later.
  4. From the Profile type drop-down menu select VPN.
  5. In the Settings section click Configure.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define VPN Profile Settings

  1. Click Base VPN.
  2. Enter a name for the connection.
  3. 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.
  4. Enter a description and provide the FQDN for any additional VPN servers, as required.
  5. From the Connection type drop-down list choose the preferred connection type.
  6. In the Always On section click Enable.
  7. Select Enable to Remember credentials at each logon (optional).
  8. Click Select a certificate.
  9. Choose a client authentication certificate and click Ok.
  10. Paste the contents of eapconfig.xml (saved previously) in the EAP Xml field.
  11. Click Ok.

Deploying Windows 10 Always On VPN with Microsoft Intune

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

Deploying Windows 10 Always On VPN with Microsoft Intune

After configuring any required additional settings, click Create.

Assign VPN Profile

  1. Click Assignments.
  2. From the Assign to drop-down menu choose Selected Groups.
  3. Click Select groups to include.
  4. Choose an Azure Active Directory group to apply the VPN profile and click Select.
  5. Click Save.

Deploying Windows 10 Always On VPN with Microsoft Intune

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

 

Leave a comment

91 Comments

  1. Jason Jones

     /  May 22, 2018

    Yup, getting there slowly – the VPN CA guidance should also be published soon including updated Intune steps

    Reply
  2. Florian TPG

     /  May 22, 2018

    Nice article. As always 😉

    Reply
  3. froand

     /  June 11, 2018

    Hi richard

    Great article as always 🙂
    Isn’t AOVPN only supported with IKEv2?

    Reply
  4. Zack

     /  November 16, 2018

    I’m looking at deploying device tunnel through an intune custom profile. Could you post an example? What OMA-URI should be used?

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

      Reply
      • Greg

         /  February 17, 2019

        Any news on this Device Tunnelvia Intune deployment post?

      • Sorry, not yet. It’s in the article queue though. Hope to have something published in the near future. 🙂

      • Greg

         /  February 23, 2019

        I’ve since figured it out with the hint you gave the other user. It’s much the same as the user method!

      • Correct. 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, 2019

        I’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?

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

  5. Hi,
    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 🙂

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

      Reply
  6. Hello,
    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?

    Reply
    • If your EAP configuration is configured to use client certificate authentication, then yes, you must select a certificate in Intune.

      Reply
      • Thank 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!!

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

  7. Ronald Bevers

     /  August 14, 2019

    Hello 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?

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

      Reply
      • Ronald Bevers

         /  August 18, 2019

        This 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.

      • The 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, 2020

        I 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!

  8. Travis

     /  September 3, 2019

    Hi 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

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

      Reply
  9. Hi 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.

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

      Reply
  10. Paddy Berger

     /  January 23, 2020

    Hi 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

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

      Reply
      • Paddy Berger

         /  February 4, 2020

        Ok, 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?

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

  11. Zack

     /  February 26, 2020

    How 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”)

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

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

      • Hoping 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. :/

  12. KHANH NGUYEN

     /  February 27, 2020

    How you can add or export username and pwd in the Xml file?

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

      Reply
  13. Geraldo

     /  July 2, 2020

    Richard,
    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?

    Reply
    • I’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?

      Reply
  14. NotBillGates

     /  July 7, 2020

    Hi 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.

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

      Reply
      • Ronald

         /  July 9, 2020

        As 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.

      • If 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. :/

  15. Scott K

     /  July 23, 2020

    Hey 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?

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

      Reply
  16. Hello 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?

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

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

      • Odd that it returns like that. Have to assume another GPO is adding it somewhere?

  17. Hi 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?

    Reply
    • This 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. :/

      Reply
      • Hi, 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

      • That’s a good solution if your devices are domain joined, for sure. 🙂

  18. Patrick

     /  June 21, 2021

    Is there any way to resync the AOVPN profile if a user mistakenly deleted the AOPVN profile?

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

      Reply
      • Patrick

         /  June 21, 2021

        Hi, 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.

  19. Hi, 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

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

      Reply
  20. Charlee Ult

     /  September 7, 2021

    Hi 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.

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

      Reply
      • Ronald

         /  September 9, 2021

        This 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, 2021

        Thanks Richard, how can I resolve this issue of not passing internet traffic?

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

  21. Rik Pasman

     /  January 19, 2022

    Hi 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

    Reply
    • Hi Rik. Which tunnel isn’t working as expected? Device tunnel or user tunnel? Or both?

      Reply
      • Rik

         /  January 21, 2022

        Hi Richard,

        It is regarding a user tunnel on Azure Domain Joined devices.

        Rik

      • Ok, 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. 🙂

  22. Woz

     /  February 14, 2022

    Hi 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.

    Reply
    • If 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?

      Reply
  23. Rik Pasman

     /  July 5, 2022

    Hi 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

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

      Reply
  24. Chris W

     /  November 10, 2023

    Hi 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

    Reply
    • Hi 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!

      Reply
      • Chris Walker

         /  November 14, 2023

        Hi 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

      • Yes, 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, 2023

        Ugh. 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 🙂

      • 😉

      • Chris Walker

         /  November 14, 2023

        Yup, 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

      • You 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, 2023

        Nope – 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 🙂

      • Ok, in that case you wouldn’t need a RADIUS server. Don’t hesitate to reach out again if there’s anything else you need!

  1. Always On VPN Client DNS Server Configuration | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Routing Configuration | Richard M. Hicks Consulting, Inc.
  3. Always On VPN and Azure MFA ESTS Token Error | Richard M. Hicks Consulting, Inc.
  4. Deploying Always On VPN with Intune using Custom ProfileXML | Richard M. Hicks Consulting, Inc.
  5. Microsoft Intune NDES Connector Setup Wizard Ended Prematurely | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading