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.
Zero Trust Network Access (ZTNA) is a term that administrators are likely familiar with, as it is one of the hottest marketing buzzwords in circulation today. ZTNA can mean different things depending on the deployment scenario. ZTNA is fundamentally about enforcing the principle of least privilege for endpoints connecting remotely to the corporate network when it comes to enterprise mobility and remote access.
Trusted Access
Historically, VPNs and even DirectAccess granted full, unrestricted network access to authenticated devices and users. Once the endpoint has an IP address, and in the absence of other controls (routing limitations, firewall access controls, etc.), the user could access any resource on the internal network. The rationale was that authenticated devices and users should be considered “trusted”.
Limitations
The Trusted Access model has some significant limitations. It assumes that all traffic from authorized users and devices is legitimate. However, if an endpoint is compromised, an attacker has broad access to the internal network, which is not ideal from a security perspective.
Zero Trust
Zero Trust Network Access is a concept where administrators define explicitly the minimum level of access required to support remote workers. Instead of granting full network access to the endpoint, controlling access using fine-grained policies is enforced on the VPN connection. Configuring limited network access for Always On VPN clients dramatically reduces exposure of the internal network to compromised endpoints.
ZTNA Management
There is a significant management burden associated with this approach, however. Administrators must identify each application requiring VPN access and determine all associated protocols and ports to be allowed, and internal resources to which they will communicate. Although this task isn’t difficult if clients require access to a small subset of internal resources, it can be a substantial undertaking if clients require access to many internal resources from numerous client applications.
Moving Targets
Making things more challenging is that application and network infrastructure often change constantly, requiring administrators to manage network access continually to ensure application availability. When adding new applications or changing the internal infrastructure, updating the configuration on all remote endpoints will be required.
Updating Always On VPN configuration for devices managed with Microsoft Endpoint Manager (formerly Intune) isn’t difficult. However, it can be more challenging when using PowerShell with System Center Configuration Manager (SCCM) or another endpoint management platform.
Traffic Filters
ZTNA can be configured with Always On VPN using Traffic Filters. With Traffic Filters, administrators can apply fine-grained access control for VPN traffic based on a combination of the following.
Source IP address (IP address, address range, or subnet)
Destination IP address (IP address, address range, or subnet)
Protocol (TCP, UDP, IP, etc.)
Source Port
Destination Port
Endpoint Manager Configuration
Configuring Traffic Filters for Always On VPN connections can be performed using Microsoft Endpoint Manager. Open the Endpoint Manager management console (https://endpoint.microsoft.com), navigate to the Always On VPN device configuration profile, then perform the following steps.
Expand App and Traffic Rules.
Click Add next to Network traffic rules for this VPN connection.
Enter a descriptive name in the Name field.
Select Split tunnel from the Rule type drop-down list.
Enter “6” in the Protocol field.
Enter “3389” in the Lower port and Upper port fields in the Remote port ranges section.
Enter an IPv4 address in the Lower IPv4 address field.
Enter an IPv4 address in the Upper IPv4 address field. Enter the same IPv4 address as the lower address to specify a single host.
Click Save.
The example above shows a traffic filter restricting access to TCP port 3389 (Remote Desktop Protocol) from all VPN clients to the 172.16.0.0/24 network.
Note: Repeat these steps to create as many traffic filters as required for any processes or applications that must communicate over the Always On VPN connection.
XML Configuration
Traffic Filters can also be configured using custom XML. To implement the same Traffic Filter described previously, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.
Note: Address ranges used in Traffic Filters can be defined using CIDR notation in XML, but they are not supported using Microsoft Endpoint Manager today.
Default Deny
When configuring a Traffic Filter for an Always On VPN profile, an implicit “deny all” rule is automatically enabled. Any traffic not explicitly defined in a Traffic Filter will be denied, including unsolicited inbound traffic, which has crucial implications for the device tunnel because it is used commonly for system management of remote devices.
Direction
Traffic Filters are enabled for the Outbound direction only, by default. Beginning with Windows 10 2004, Microsoft introduced support for Inbound traffic filters. Before Windows 10 2004, configuring a Traffic Filter on the device tunnel would break manage-out scenarios by denying all unsolicited inbound network access.
As of this writing, configuring inbound Traffic Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.
To implement a Traffic Filter to allow inbound RDP access from the internal network over the device tunnel, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.
Note: When configuring inbound Traffic Filters, specify the port of the listening process or application using the LocalPortRanges field.
Application Filters
Administrators can combine Application Filters with Traffic Filters to control network access over the Always On VPN connection even more granularly. Applications can be defined by the following.
Package Family Name (PFN) – This is the unique name of a Microsoft Store application. Use the Get-AppxPackage PowerShell command to find the PFN for an application.
File Path – This is the full path to any executable on the file system. For example, c:\Windows\System32\mstsc.exe.
SYSTEM – This allows Windows kernel-mode drivers (such as ping.exe and net.exe) to send traffic over the Always On VPN connection.
As of this writing, configuring Application Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.
Application Filter Examples
Below are three examples showing different Application Filters based on file path, Package Family Name, and SYSTEM.
File Path
This example shows a Traffic Filter configured to allow RDP access to an internal subnet using the native Windows Remote Desktop client (mstsc.exe).
Note: Ping uses ICMP (IP protocol 1), which is a network layer protocol. As such, defining ports for the filter is not required.
IPv6 Compatibility
Sadly, the filtering techniques described in this article do not work when also configuring IPv6 on the Always On VPN connection. As of this writing, enabling Traffic Filters when an IPv6 address is assigned to the VPN interface is not supported. More details can be found here.
Configuring Zero Trust Network Access (ZTNA) with Windows 10 Always On VPN is not trivial. Still, with attention to detail, it can be a highly effective tool to enforce fine-grained network access policies and reduce exposure of the internal network to compromised endpoints. Combining Traffic Filters with Application Filters allows administrators to tightly control Always On VPN access and ensure the principle of least privilege is applied.