Microsoft recently announced support for native Windows 10 Always On VPN device tunnel configuration in Intune. Previously administrators had to use the complicated and error-prone custom XML configuration to deploy the Windows 10 Always On VPN device tunnel to their clients. That is no longer required with this recent Intune update. In addition, administrators may now specify custom cryptography settings for IPsec Security Association (SA) parameters for IKEv2 for both device tunnel and user tunnel connections. This effectively eliminates the requirement to use custom ProfileXML for most deployment scenarios.
Device Tunnel Configuration in Intune
Follow the steps below to configure and deploy a Windows 10 Always On VPN device tunnel using the native Intune user interface.
Create Profile
1. Open the Microsoft Endpoint Manager admin center (devicemanagement.microsoft.com).
2. Navigate to Devices > Configuration Policies.
3. Click Create profile.
4. Choose Windows 10 and later from the Platform drop-down list.
5. Choose VPN from the Profile drop-down list.
6. Click Create.
Profile Settings
Proceed with the profile configuration as you would normally, providing the VPN connection name, VPN server name(s), and choosing the option to register IP addresses with internal DNS. Next use the following steps to define a device tunnel connection and specify custom cryptography for IPsec SA parameters for IKEv2.
Configure a Device Tunnel
1. Select IKEv2 from the Connection type drop-down list.
2. Click Enable in the Always On section.
3. Select Machine Certificates from the Authentication method section.
4. If the computer certificate is provisioned using Intune, select the client authentication certificate (not required if the computer certificate is provisioned using on-premises Active Directory).
5. Click Enable in the Device Tunnel section.
Define Custom Cryptography
Follow the steps below to implement minimum security baseline cryptography settings for IKEv2.
IKE Security Association Parameters
1. Select AES-128 from the Encryption algorithm drop-down list.
2. Select SHA2-256 from the Integrity check algorithm drop-down list.
3. Select 14 from the Diffie-Hellman group drop-down list.
Child Security Association Parameters
1. Select CBC-AES-128 from the Cipher transform algorithm drop-down list.
2. Select HMAC-SHA256-128 from the Authentication transform algorithm drop-down list.
3. Select 14 from the Perfect forward secrecy (pfs) group drop-down list.
Important Note: The IPsec security association parameters outlined above are the minimum recommend security baseline for IKEv2 and are compatible with all supported versions of Windows Server RRAS. It is recommended that authenticated cipher suites (GCM) be used whenever possible. However, GCM ciphers are not supported for encryption prior to Window Server 1803. Administrators should review these security settings and adjust the parameters to meet their specific security requirements.
Server Configuration
When defining custom cryptography settings for IKEv2 for device tunnel deployment, it is critical that the server be configured using identical parameters. Failure to use matching cryptography settings on the client and server will result in error code 13868, which indicates an IPsec policy mismatch.
A PowerShell script to configure IKEv2 security association parameter minimum security baselines on the RRAS server as outlined above can be found here. The commands to make these changes on the Azure VPN gateway can be found in this post.
Caveats
While Microsoft has made great strides to ensure better support for Always On VPN configuration using the native Intune UI, there are a few critical settings are still not supported. In these scenarios the administrator must deploy Always On VPN using custom XML, as described here and here.
Custom Cryptography
IKEv2 custom cryptography settings are only exposed when IKEv2 is selected as the connection type. It appears that defining custom cryptography settings for IKEv2 when the connection type is set to Automatic is not supported at this time. If you wish to specify the Automatic connection type and use custom cryptography settings for IKEv2 you will need to deploy the device tunnel using custom ProfileXML.
IPv6
IPv6 routing when configuring split tunneling for Always On VPN in Intune is not supported.
Additional Information
Windows 10 Always On VPN Policy Mismatch Error
Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway
Windows 10 Always On VPN IKEv2 Load Balancing and NAT
ND
/ July 27, 2020Nice – thanks for the info
Tim
/ August 21, 2020Hi Richard, It#s great that the Device Tunnel is now supported in Intune, but I am still finding some settings that can be set in the XML are not available via Intune. One example of this is the Route Metric.
And listed in the documentation as:
VPNv2/ProfileName/RouteList/routeRowId/Metric
Added in Windows 10, version 1607. The route’s metric.
Do you know how I can set the route metric for a Device Tunnel in Intune?
Richard M. Hicks
/ August 23, 2020Indeed, there are still a few crucial settings that aren’t exposed in the Intune UI, which means you’ll still have to use custom ProfileXML in some cases. :/
Tim
/ August 24, 2020Do you know if Microsoft are working to add all the settings available in the XML to the Intune selection menus? If not, how can we prompt them to look into it?
Richard M. Hicks
/ August 24, 2020I don’t expect they are. Best way to press them on this is to open a support case. 🙂
Matthew
/ October 21, 2020Hi Richard, this is a welcome addition to the native profile capability. If only it were not at the expense of being able to configure Automatic as the tunnel type.
This is important as having the Automatic strategy allows for fall back to SSTP when network providers prevent IKEv2 being used. It isn’t acceptable to only be able to do this at the cost of cryptographic security though.
In terms of the behaviour of setting the tunnel type to Automatic in the native profile which in turn prevents the custom cryptographic setting being applied. It’s noteworthy that I have observed this also causing the same behaviour when using profileXML…
I suspect a bug!
Richard M. Hicks
/ October 24, 2020Oh yes, it is a bug. I’ve documented that in the past here: https://directaccess.richardhicks.com/2019/01/07/always-on-vpn-ikev2-connection-failure-error-code-800/.
JR
/ November 25, 2020I can not find anywhere to “Disable Class Based Default Route” in the Intune VPN setup. Am I just missing it or is that another feature of the profileXML that is missing from the UI. Doesn’t that totally defeat the purpose of trying to limit connectivity to only critical machines (DCs, SCCM, Management out PCs)?
Richard M. Hicks
/ November 30, 2020This is yet another crucial setting that is missing from the Intune UI. If you want to enable this setting you’ll have to use custom XML instead. And yes, this is problematic for device tunnel connections where you want to limit access by defining specific routes. :/
James A
/ January 11, 2021Here’s the uservoice I made for this https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/42372121-allow-configuration-of-disableclassbaseddefaultrou
Richard M. Hicks
/ January 18, 2021Thanks!
James A
/ January 11, 2021How can I debug this and find what settings are actually on the client? I have this configured in Intune, but on rekeying the child SA, the client (20H2) is only sending AES/SHA/no PFS and DES/SHA/no PFS* based on the fortigate debug logs and so the VPN drops. Get-WmiObject -Class MDM_VPNv2_01 -Namespace root\cimv2\mdm\dmmap returns nothing. Get-NetIPSecMainModeSA says AES256/SHA256/DH2 which is correct for the parent SA. Get-NetIPsecQuickModeSA shows a bit more, but just inbound and outbound tunnels, not the child SA.
*(it also sends that for the initial connection but the strongswan wiki says “There is one important aspect that affects IKEv2. The keys for the CHILD_SA that’s implicitly created with the IKE_AUTH exchange will always be derived from the IKE keys even if PFS is configured. So if the peers disagree on whether to use PFS or not (or on the DH groups) it will not be known until the CHILD_SA is first rekeyed with a CREATE_CHILD_SA exchange (and fails). This is also the reason why you won’t see a DH group in the status output of the daemon until the SA is first rekeyed. For IKEv1 that’s different as each Quick Mode exchange uses the complete proposals, so already the first IPsec SA will use PFS according to the configuration.”)
Richard M. Hicks
/ January 18, 2021On the server I use Get-VpnServerConfiguration to view IPsec policy settings. On the client I use the following PowerShell script.
https://github.com/richardhicks/aovpn/blob/master/Show-VpnConnectionIPsecConfiguration.ps1
James A
/ January 18, 2021Oh yeah, I tried get-vpnconnection |Select-Object -ExpandProperty IPsecCustomPolicy but that also returns nothing (at the moment, sometimes it has returned what I’d expect). The server is a fortigate and its debugs show its offering what I expect. I have a case open with Intune support, we’ll see what they say.
Richard M. Hicks
/ January 21, 2021Keep me posted!
sebus
/ September 13, 2022I have the exact Custom Cryptography configured in Intune GUI, but user gets Policy match error, till I run by hand:
$connection = “AO VPN”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force
Makes no sense to me
Richard M. Hicks
/ September 15, 2022That’s odd. This is for a device tunnel, correct?