Always On VPN administrators migrating their endpoints to Windows 11 may encounter a scenario where Always On VPN randomly disconnects when the VPN profile is deployed using Microsoft Intune. The same configuration deployed to Windows 10 devices works reliably, however. In addition, Always On VPN profiles deployed using PowerShell (natively or with SCCM) or PowerON DPC do not experience this problem.
Troubleshooting
Administrators troubleshooting this issue will find the root cause is associated with the Always On VPN profiles being removed and replaced each time the device syncs with Intune. This occurs even if there are no changes to the configuration. Removing and replacing the Always On VPN profiles on each device sync is unnecessary, of course, but is also highly disruptive to connected users.
Intune and XML
The Intune team identified the issue, and a fix was made available in the August update. However, many of you have reported the issue persists with some Windows 11 clients after installing the latest updates. Further investigation indicates that although the issue has been resolved when using Intune and the native VPN device configuration profile template, the problem still occurs when using the Custom device configuration template.
Workaround
Microsoft is aware of the issues with deploying Always On VPN client configuration settings using XML in Intune, but there’s no indication when or if they will fix it. Until then, administrators have two options to address this problem.
Native VPN Template
When deploying Always On VPN client configuration settings to Windows 11 endpoints, use the native VPN device configuration template, as shown here.
Using the native VPN template does have some limitations, however. The following settings are not exposed using the native VPN template and can only be configured using XML.
If you must use XML, I’ve had some success by ensuring the order of XML settings is exactly as Intune expects. Follow the steps below to confirm the XML settings order in your XML configuration file.
Compare the order of settings to your existing XML.
Make changes to ensure all settings in your XML are in the same order as the extracted XML.
Publish a new XML configuration file using Intune and test.
I’ll caution you that this workaround doesn’t always work reliably. Some customers report that this solved their problems entirely, while others have indicated it does not. My testing shows the same results. Let us know in the comments below if this works for you!
Always On VPN DPC version 3.0 includes the following new functionality Always On VPN administrators are sure to find useful.
Traffic filters – Support for enabling traffic filters for both device tunnel and user tunnel are now supported in DPC, greatly simplifying the task of creating access control lists to enforce zero-trust network access (ZTNA) policies.
Enhanced security – The option to disconnect the VPN connection if the VPN server does not present a cryptobinding TLV is now enabled by default. This often-overlooked security setting ensures VPN client connections are not intercepted by detecting man-in-the-middle attacks.
Device tunnel enhancements – Administrators can now display the device tunnel connection and status in the Windows UI.
Backup connection – Always On VPN DPC now supports the configuration and deployment of a backup VPN connection, which is helpful when Always On VPN connectivity is disrupted.
Hostname routing – Administrators can now define hostnames in the routing table. Hostnames are resolved on the endpoint and converted to IP addresses for including in the routing table.
Smart card authentication – Always On VPN DPC now supports smart card authentication as an authentication option in addition to client authentication certificates.
Learn More
Interested in learning more about Always On VPN DPC? Fill out the form below and I’ll provide you with additional information or visit aovpndpc.com to sign up for a free trial.
The two most common VPN protocols used with Always On VPN are Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). Each protocol has its advantages and disadvantages. For example, IKEv2 has better security options, but SSTP is more firewall-friendly and reliable.
IKEv2 with SSTP Fallback
Instead of selecting one protocol over the other, some administrators may choose to configure Always On VPN to prefer IKEv2, then fall back to SSTP if IKEv2 is unavailable. Unfortunately, there is no way to configure this using Intune, XML, or PowerShell. To change this setting, the administrator must update the VPN configuration file (rasphone.pbk) and change the value of VpnStrategy to 14. While editing a text file is easy, doing it at scale is more complicated. The setting can be changed using Intune proactive remediation or a PowerShell script. However, it’s even easier using Always On VPN DPC. Simply enable the VPN Protocol advanced setting in group policy and choose IKEv2 First, SSTP Fallback.
Interface Metric
Another common problem Always On VPN administrators encounter is name resolution, specifically when the endpoint uses a wired local connection. Here, name resolution queries may fail or return incorrect IP addresses. This happens because the wired connection has a lower network interface metric than the VPN tunnel adapter. Once again, there is no option for changing this setting using Intune or XML. Administrators can update the interface metrics using PowerShell, but it is not persistent. To fully resolve this, the administrator must edit the rasphone.pbk file. With Always On VPN DPC, enable the VPN Tunnel Metric group policy setting and enter a value lower than the wired connection to solve this problem.
IKE Mobility
The Windows VPN client includes support for IKE Mobility, which allows an IKEv2 VPN connection to reconnect automatically after a loss of network connectivity. IKE Mobility is enabled by default, and the network outage time is set to 30 minutes. However, this setting can have negative side effects, especially when VPN servers are behind a load balancer. Reducing the network outage time or disabling it completely can improve failover if a VPN server goes offline. Here again, this setting cannot be changed using Intune, XML, or PowerShell; it is only configurable in rasphone.pbk. With Always On VPN DPC, enable the Network Outage Time advanced setting in group policy and choose a value that meets your requirements.
Exclusion Routes for Office 365
Force tunneling ensures that all network traffic on the client is routed over the VPN tunnel, including Internet traffic. However, Always On VPN supports exclusion routes which allow administrators to exempt selected traffic from the VPN tunnel when force tunneling is enabled. Commonly this is configured for trusted cloud applications like Microsoft Office 365. Defining exclusion routes for cloud services is more complicated than it sounds. Many cloud services, including Microsoft Office 365, have multiple IP addresses that are constantly changing. This makes keeping Always On VPN clients updated with the correct list of IP address exclusions quite challenging. With Always On VPN DPC, administrators can enable the Exclude Office 365 from VPN group policy setting, allowing the endpoint to automatically configure the necessary exclusion routes for Office 365 IP addresses. Importantly, Always On VPN DPC periodically monitors this list of IP addresses and ensures that endpoints are continually updated with Office 365 exclusion routes as they change to ensure reliable connectivity.
IP Routing
Always On VPN administrators must define which IP addresses and networks are routed over the VPN tunnel when split tunneling is enabled. However, Intune has a known issue that may pose a challenge in some environments.
IPv6
Although IPv4 routes can be configured using the Intune UI, IPv6 routes cannot. This is because the Intune UI does not correctly validate the default IPv6 prefix length, insisting that the administrator use a value between 1 and 32. 🤦♂️
However, the Always On VPN DPC Allowed Routes group policy setting happily accepts the proper IPv6 prefix.
Route Metrics
In addition, there is no option to define the metric values for routes configured using Intune. Assigning non-default route metrics is required to resolve routing conflicts in some scenarios. Defining route metrics requires custom XML. The Always On VPN DPC Route Metric group policy settings allow administrators to define route metrics as required.
Are you interested in learning more about PowerON Platforms Always On VPN DPC? Fill out the form below, and I’ll contact you with more information. In addition, you can visit aovpndpc.com to register for an evaluation license.
