A while back I described in detail how to configure a Windows 10 Always On VPN device tunnel connection using PowerShell. While using PowerShell is fine for local testing, it obviously doesn’t scale well. In theory you could deploy the PowerShell script and XML file using System Center Configuration Manager (SCCM), but using Microsoft Intune is the recommended and preferred deployment method. However, as of this writing Intune does not support device tunnel configuration natively. The administrator must create a ProfileXML manually and use Intune to deploy it.
Device Tunnel Prerequisites
I outlined the Always On VPN device tunnel prerequisites in my previous post here. To summarize, the client must be running Windows 10 Enterprise edition and be domain-joined. It must also have a certificate issued by the internal PKI with the Client Authentication EKU in the local computer certificate store.
ProfileXML
To begin, create a ProfileXML for the device tunnel that includes the required configuration settings and parameters for your deployment. You can find a sample Windows 10 Always On VPN device tunnel ProfileXML here.
Note: Be sure to define a custom IPsec policy in ProfileXML for the device tunnel. The default security settings for the IKEv2 protocol (required for the device tunnel) are quite poor. Details here.
Intune Deployment
Open the Intune management console and follow the steps below to deploy an Always On VPN device tunnel using Microsoft Intune.
Create Profile
1. Navigate to the Intune portal.
2. Click Device configuration.
3. Click Profiles.
4. Click Create profile.
Define Profile Settings
1. Enter a name for the VPN connection in the Name field.
2. Enter a description for the VPN connection in the Description field (optional).
3. Select Windows 10 and later from the Platform drop-down list.
4. Select Custom from the Profile type drop-down list.
Define Custom OMA-URI Settings
1. On the Custom OMA-URI Settings blade click Add.
2. Enter a name for the device tunnel in the Name field.
3. Enter a description for the VPN connection in the Description field (optional).
4. Enter the URI for the device tunnel in the OMA-URI field using the following syntax. If the profile name includes spaces they must be escaped, as shown here.
./Device/Vendor/MSFT/VPNv2/Example%20Profile%Name/ProfileXML
5. Select String (XML file) from the Data Type drop-down list.
6. Click the folder next to the Select a file field and chose the ProfileXML file created previously.
7. Click Ok twice and then click Create.
Assign Profile
Follow the steps below to assign the Always On VPN device tunnel profile to the appropriate device group.
1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the Windows 10 client devices.
4. Click Select.
5. Click Save.
Demonstration Video
A video demonstration of the steps outlined above can be viewed here.
Additional Information
Windows 10 Always On VPN Device Tunnel Configuration using PowerShell
Windows 10 Always On VPN IKEv2 Security Configuration
Deleting a Windows 10 Always On VPN Device Tunnel
Windows 10 Always On VPN Device Tunnel Missing in the UI
Video: Deploying Windows 10 Always On VPN User Tunnel with Microsoft Intune
Tim
/ August 28, 2019After spending quite some time testing, am I right in saying there is an issue deploying a Device Tunnel and a User Tunnel via Intune when wanting both connections to use TrustedNetworkDetection? What I am seeing is the device or user tunnel can be deployed perfectly individually, however, if both device and user tunnels are deplyed via Intune and TrustedNetworkDetection is enabled – the user tunnel never initiates a connection as the Device Tunnel connects and is seen to be on the TrustedNetwork – not using the TrustedNetworkDetection option on either the device or user tunnel would mean a really untidy deployment. If I roll out the Device Tunnel using a PowerShell script or SCCM (again a PowerShell script) then the Device Tunnel connects with TrustedNetworkDetection and so does the User Tunnel (deployed via Intune) – Anyone else seen this? Are Microsoft aware?
Richard M. Hicks
/ August 28, 2019A while back there were issues with Windows 10 and trusted network detection that exhibited this exact behavior, but those were resolved quite some time ago. If you running 1803/1809 that’s been updated since February/March, you should have those fixes. Are you deploying Always On VPN with Intune using the native UI or custom ProfileXML?
Tim
/ August 29, 2019Everything is using ProfileXML – The native UI doesn’t provide all the options needed for some strange reason – It would be great if Microsoft included all the options in the native UI as that would certainly remove any syntax errors that may be contained in the XML. I thought the TrustedNetworkDetection was fixed too – but this is the first time I have created both User and Device Tunnels via Intune and there seems to be an issue – I am running August 19 Cumulative Update for Windows 10 1803 and I am seeing this issue. The issue does not occur if I create the Device Tunnel with PowerShell and the User Tunnel with Intune – only when using Intune for both. Is this something that others are experiencing / others can test?
Richard M. Hicks
/ August 29, 2019Very strange. Might be time to engage with Microsoft support. Perhaps this bug is back?
tim
/ September 11, 2019I’m having an odd issue with a device tunnel configuration. I can’t seem to find ANY documentation on the correct .xml configuration for a device tunnel with Force Tunneling turned on. I have a completely working device tunnel with split tunneling however if i change SplitTunnel to ForceTunnel under the RoutingPolicyType section it fails to install the VPN on the endpoints with an error saying the Parameter is Incorrect. Im probably missing something but again, super hard to find any good full examples of the configuration file except for on your site.
Thanks in advance.
Richard M. Hicks
/ September 12, 2019Using force tunneling with the device tunnel is not common, but I think it should work. When using force tunneling you must remove the DisableClassBasedDefaultRoute option and also any routes. Give that a shot and let me know what happens.
Tim
/ September 12, 2019Interestingly I just got this working a few hours ago, I had to leave the DisableClassBasedDefaultRoute option in and set it to false. If i tried removing this (which common sense says you should) it failed to install the VPN adapter with a configuration error. I also had to remove all of the route entries as you mentioned as well.
Thanks for your help!
Richard M. Hicks
/ September 12, 2019Interesting. Good to know!
Tim
/ September 13, 2019Tim? Are you deploying this via Intune? If so – when the device configuration is applied to a computer which user / object does Intune report as Successfully installing the profile for the Device Tunnel? The reason I ask is that whenever I deploy a Device Tunnel via Intune it is always installed as a User, and it breaks the Always On function of the User Tunnel (I guess it’s because a user can only have 1 Always On profile and with the Device tunnel being rolled out as a user it breaks the User Tunnel) Thanks for any confirmation.
Richard M. Hicks
/ September 16, 2019If you are deploying the device tunnel and it is being installed in the context of the user it sounds like you have the OMA-URI defined incorrectly. Have a close look at that and see what’s up. It should start with ./Device, not ./User.
Tim
/ September 16, 2019yes i’m using Intune to deploy, I haven’t seen this behavior. While it does show a deployment to a user, it also shows the device deployment. I have had both user and device tunnel running at the same time with no issues, both deployed by intune.
Tim
/ September 17, 2019I can confirm that my device tunnel OMA-URI is: “./Device/Vendor/MSFT/VPNv2/Device%20Tunnel/ProfileXML”
Can you both try something for me on one of your machines managed by Intune? Can you delete both the User and Device Tunnel from that machine – and then perform a sync when logged in as a Always On VPN user on that machine. This should install the Device and User Tunnel again – then go and check Intune and see who installed each Configuration Profiles? I am wondering if Intune installed the Device Tunnel when the machine was logged in as a different user to the one who has the User Tunnel Always On VPN installed. I am seeing that if the user is logged in then Intune installs both the Device Tunnel and User Tunnel as that user which breaks alwayson=true for the User Tunnel as only one profile can be AlwaysOn and that is always the Device Tunnel. Any info / screenshots you have would be great to help me sort this out.
Richard M. Hicks
/ September 17, 2019Sure. Will test as soon as possible. I’ll warn you that it might be a bit though. I’m full engaged this week and on vacation the next two weeks after. 😉
Kevin
/ February 26, 2020Hi Richard,
I’ve managed to get a device tunnel deployed to the devices via inTune and this method. My question is, does this method allow you to update the routes on the tunnel. So for example, if 6 months we add a new subnet that is needed, is it as simple as updating the profile.xml uploading back to the same configuration profile and it auto updates based on assignment? Or do you need to create a new configuration profile? Or is there another method?
thanks
Kevin
Richard M. Hicks
/ February 26, 2020You should be able to simply update the ProfileXML and the settings will be updated on clients accordingly. I tested this a while back and that was my experience anyway. I’d suggest you do some testing yourself just to confirm though.
Let me know what you find!
Kevin
/ February 26, 2020Hi Richard,
Indeed that appears to auto update and at next re-connect the route is visible. Interestingly we are using device tunnel with machine cert, but the VPN shows as VPNProfileUser?
Richard M. Hicks
/ February 27, 2020Good to know! 🙂 Where specifically does it say VPNProfileUser? On the client you should only see the connection in the classic Windows network control panel (ncpa.cpl) or by using the PowerShell command Get-VpnConnection -AllUserConnection.
Kevin
/ February 27, 2020I think I spotted it in the OMA-URI, so It makes sense now. It made me wonder when the tunnel wouldn’t connect, but I’ve got this down due to , as our domain resolves internal and external, so I’ve changed this to a DC and it appears more stable at detecting and then connecting. Thank you for your help and the article, I had a powershell mechanism to push this out via intune, but this is much neater and simpler to update routes.
Kevin
/ February 27, 2020slight type there, “due to “
Kevin
/ February 27, 2020TrustedNetworkDetection
Max Ruegnitz
/ March 23, 2020Hi Richard,
For Users and their devices who traverse both the LAN and WAN are there configuration settings for triggering the VPN based on their network location?
Richard M. Hicks
/ March 23, 2020Yes. You would simply configure Trusted Network Detection (TND), which uses the internal network’s DNS suffix to determine network location. An interface on your LAN would have a matching internal DNS suffix, so the VPN would not connect. If you were outside the network, the DNS suffix would not be present and the VPN connection will establish automatically.
Jarrett B.
/ August 6, 2020I have this working with Intune and SCEPMan, but i have an odd issue where my VPN Profile comes out named ‘Example Profile%Name’
I can’t seem to find the proper lingo for the XML to specify a Profile Name, can you provide any pointers?
Richard M. Hicks
/ August 6, 2020Are you using native Intune VPN profile configuration or custom XML?
Jarrett B
/ August 6, 2020I resolved it. I hadn’t noticed the profile name is specified in the OMA-URI path.
Thanks! Great guide!
Fabian
/ January 31, 2022Hi Richard,
I am having an odd issue:
Trying to deploy the ProfileXML [./Device/Vendor/MSFT/VPNv2/Device%20VPN/ProfileXML]
I get the error
0x87D101A9 Syncml(425): The requested command failed because the sender does not have adequate access control permissions (ACL) on the recipient.
But I can’t find any documentation on ACLs for OMA-DM. The devices are AD joined and Azure AD Hybrid joined Intune Co-Managed. I am kinda clueless.
Greetings
Fabian
Richard M. Hicks
/ February 1, 2022What version of Windows? And how are you deploying this profile? With Intune and custom XML? Or PowerShell?
Bertrand
/ January 16, 2023Hello Richard,
Do you recommend using native Intune VPN profile or custom XML?
We face regular VPN P2S device tunnel disconnections and I am wondering if it comes from Intune configuration.
Richard M. Hicks
/ January 16, 2023I prefer to use custom XML as it gives me more control over the Always On VPN client configuration settings for both the device and user tunnels. However, I don’t know if using one or the other would impact connection reliability. If you are using native Intune, you could certainly try using custom XML to see if that helps, though. FYI, there’s a known issue with Windows 11 and Intune where the Always On VPN tunnels are removed and replaced during every device sync that causes connectivity loss. It does not appear to affect Windows 10, however. Microsoft is aware of the issue and working on it as we speak. No ETA for a fix, unfortunately.