When configuring Always On VPN for Windows 10 and Windows 11 clients, administrators may encounter a scenario where an IPv4 route defined in Microsoft Endpoint Manager/Intune or custom XML is not reachable over an established Always On VPN connection. Further investigation indicates the route is added to the configuration on the endpoint but does not appear in the routing table when the connection is active.
Routing Configuration
When split tunneling is enabled, administrators must define routes to IP networks that are reachable over the Always On VPN connection. The method of defining these routes depends on the client configuration deployment method.
Endpoint Manager
Using Microsoft Endpoint Manager, administrators define IP routes in the Split Tunneling section of the configuration settings for the Always On VPN device configuration profile. Routes are defined by entering the destination prefix and prefix size. In this example, the 10.0.0.0/8 and 172.21.12.0/21 IPv4 networks are defined for routing over the Always On VPN tunnel.
Custom XML
Using custom XML deployed using Microsoft Endpoint Manager, System Center Configuration Manager (SCCM), or PowerShell, routes are defined in the XML file using the following syntax.
Client Configuration
Validate the routing configuration has been implemented on the endpoint successfully by running the following PowerShell command.
As you can see here, the IPv4 routes 10.0.0.0/8 and 172.21.12.0/21 are included in the client’s Always On VPN configuration, as shown below.
Missing Route
However, after establishing an Always On VPN connection, the 172.21.12.0/21 network is not reachable. To continue troubleshooting, run the following PowerShell command to view the active routing table.
Get-NetRoute -AddressFamily IPv4
As you can see above, the only IPv4 route in the VPN configuration added to the routing table is the 10.0.0.0/8 network. The 172.21.12.0/21 IPv4 route is missing.
Network Prefix Definition
IPv4 routes missing from the Always On VPN client’s routing table result from incorrect network prefix definition. Specifically, the IPv4 route 172.21.12.0/21 used in the example here is not a valid network address. Rather, it is a host address in the 172.21.8.0/21 network, as shown below.
The Get-Subnet PowerShell cmdlet is part of the Subnet PowerShell module. To install this module, run the following PowerShell command.
Install-Module Subnet
Resolution
Using the example above, enabling access to the 172.21.12.0/21 subnet would require defining the IPv4 prefix in the routing configuration as 172.21.8.0/21. The moral of this story is always validate routing prefixes to ensure they are, in fact, network addresses and not host addresses.
Web proxy servers are not as common today as they once were, but a few organizations still leverage them to provide secure Internet access for their employees. Commonly they are used to inspect and control Internet traffic and to enforce acceptable use policies. Some organizations may wish to extend this protection to Always On VPN clients in the field by enabling force tunneling. Administrators can define a web proxy server for Always On VPN connections globally for web traffic or individual websites or domains.
VPN Proxy
A VPN web proxy server can be defined when the Always On VPN user tunnel connection uses force tunneling. Although you can still configure a VPN web proxy server with split tunneling enabled, it will not work. It is only functional when force tunneling is in use.
Administrators can configure a VPN web proxy server using the Microsoft Endpoint Manager UI or custom XML deployed with Endpoint Manager or PowerShell. Administrators can define a VPN web proxy server explicitly, or a proxy automatic configuration (PAC) file can be specified.
Note: VPN proxy server settings only work when force tunneling is enabled. Force tunneling is an unsupported configuration for the device tunnel, making the global proxy server setting for the device tunnel unsupported.
Proxy Autoconfiguration
Perform the following steps to configure a VPN web proxy server with a PAC file in Endpoint Manager.
Expand the Proxy section in the Configuration settings of the Always On VPN configuration profile.
Enter the URL for the PAC file in the Automatic configuration script field. Be sure to include the port number in the URL when using a non-standard port.
Leave the Address and Port number fields blank.
Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.
To configure a VPN web proxy server with a PAC file using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.
Explicit Proxy
Perform the following steps to configure an explicit VPN web proxy server in Endpoint Manager.
Enter the IP address, hostname, or fully qualified domain name (recommended) in the Address field.
Enter the port number in the Port number field.
Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.
To configure an explicit VPN web proxy server using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.
Namespace Proxy
Administrators can also define VPN web proxy servers on a per-namespace or per-hostname basis. Namespace VPN proxy servers can be helpful for scenarios where routing public websites over the Always On VPN connection is required. Most commonly, this is necessary because the public website restricts access to the IP address of the on-premises Internet gateway.
A namespace VPN proxy server is implemented using a Name Resolution Policy Table (NRPT) rule. At the time of this writing, a bug in Microsoft Endpoint Manager prevents administrators from deploying this option using the UI.
As you can see here, administrators can specify a proxy server as part of an NRPT rule in the Endpoint Manager UI. Notice this section of the UI validates the proxy FQDN correctly.
However, when you try to save the configuration profile, Endpoint Manager returns the following error.
“Unable to save due to invalid data. Update your data then try again: ProxyServerUri must be a valid URL or be empty.”
Interestingly, when entering a URL such as http://proxy.lab.richardhicks.net:8080/ in the Proxy field, the Endpoint Manager UI accepts it and successfully validates. But according to the VPNv2 Configuration Service Provider (CSP) reference, the value must be entered as an IP address. A hostname or FQDN also works based on my testing. Entering a URL as shown in the example above will not work at all.
With that, the only way to implement a namespace VPN web proxy server is to use custom XML. To do this, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.
Include the leading “.” to specify the entire domain, as shown above. Omit the leading “.” to specify an individual host (for example, app.richardhicks.com). Repeat this section for each additional host or domain, as required.
Caveat
Unfortunately, the Microsoft Internet Explorer web browser is the only browser that functions with the namespace VPN web proxy server. All modern web browsers, including Microsoft Edge, ignore the namespace proxy setting entirely, which seriously limits this feature’s usefulness in most organizations today.
Workaround
If routing a public website over the Always On VPN tunnel is required, adding its IP address(es) to the Always On VPN connection’s routing table is needed. However, doing this presents some unique challenges, as public websites frequently have many IP addresses, which are often dynamically changing. Also, it is common for public websites to pull content from many different domains or use Content Delivery Networks (CDNs), making the problem of identifying which IP addresses to add to the Always On VPN connection’s routing table even more challenging. Further, administrators must update the client configuration each a public website’s IP address changes, adding significant management overhead.
Summary
Routing client Internet traffic through an on-premises web proxy server for Always On VPN clients works well when force tunneling is enabled. Administrators can explicitly define a web proxy server or use a proxy automatic configuration (PAC) file. All web browsers work without issue in this scenario. Using a namespace proxy is only effective when browsing with Microsoft Internet Explorer. All modern web browsers, including Microsoft Edge, ignore namespace proxy settings.
In a recent post, I described how to configure routing for Windows 10 Always On VPN clients. In that article, I shared guidance for disabling the class-based default route in favor of defining specific routes for the VPN client. While this is easy enough to do when you use custom XML (deployed via PowerShell, SCCM, or Intune), there is a known limitation when using the native Intune UI that could present some challenges.
Intune VPN Profile Configuration
Defining specific routes is easy to do in Intune using the native VPN configuration profile. In the Configuration settings expand Split Tunneling and click Enable. The administrator can then add routes by entering their Destination prefix and Prefix size, as shown here.
Class-Based Default Route
The limitation with using Intune to configure routes is that there is currently no option to disable the class-based default route as there is with custom XML. This means the routes shown in the example above will be added to the client, but the class-based route will also be added automatically, as shown here (class-based default route highlighted with the arrow).
Considerations
In most cases, the inclusion of the class-based default route along with the administrator-defined routes will not be a problem. However, in some scenarios, it could yield unexpected results. Specifically, Always On VPN clients may have unintended access to some networks over the VPN tunnel. This is most significant for the Always On VPN device tunnel, where it is common to limit access to only specific resources using individual host routes.
Workaround
Today there is no option to disable the class-based default route using the native Intune UI. Your only option is to deploy the Always On VPN profile using custom XML, as described here.
In a recent post, I described 
