What’s New in Always On VPN DPC 4.3.1

The latest release of PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC), version 4.3.1, is now available for download. This recent update includes fixes for previously known issues. In addition, it contains some critical new features administrators will find helpful in addressing the challenges they face with Always On VPN client configuration.

What Is DPC?

Always On VPN DPC is a solution to manage Always On VPN client configuration settings. It was originally designed to be used with on-premises Active Directory but can also be deployed with Microsoft Intune. DPC streamlines the configuration and management of client settings and includes many advanced features to fine-tune and optimize Always On VPN.

What’s New in 4.3.1

The following essential features are new in the 4.3.1 release of DPC.

Add Device Tunnel Routes to User Tunnel

Always On VPN administrators can now configure DPC to add device tunnel routes to the user tunnel automatically. This configuration option ensures that all traffic flows of the user tunnel when both user and device tunnels are established.

Note: This feature also requires administrators to define route metric options in DPC. Ensure the user tunnel route metrics are set to a lower value than the device tunnel metrics for proper operation.

Restart RasMan

Always On VPN connections occasionally fail with error 602 (ERROR_PORT_ALREADY_OPEN). The workaround for this is to restart the RasMan service on the endpoint. DPC now supports automatically restarting the RasMan service when this error occurs, ensuring reliable operation for Always On VPN connections.

Machine Certificate Filtering

DPC 4.3.1 now includes a feature to allow administrators to enable machine certificate filtering for Always On VPN device tunnels. This addresses a challenge when the endpoint has multiple machine certificates in its local computer certificate store when the VPN server is configured to accept a certificate with a specific custom application policy (EKU).

Additional Features

In addition, the updated DPC agent core service now run as x64 processes. Also, DPC now supports VPN server FQDNs longer than 63 characters (good news for those using DPC with Azure VPN gateway!).

Download DPC

For those customers currently licensed for Always On VPN DPC you can download the latest release here.

https://support.poweronplatforms.com/support/solutions/articles/8000066807

Not using DPC?

If you’re not using DPC, you are missing out! You can learn more about DPC and register for a free evaluation by visiting the link below.

https://aovpndpc.com

Optionally, you can fill out the form below and I’ll provide you with more information.

Additional Information

PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune

Always On VPN Client Routes Missing

Choosing an Enterprise VPN

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.

Get-VpnConnection -Name <Connection Name> | Select-Object -ExpandProperty Routes

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.

Additional Information

Always On VPN Routing Configuration

Always On VPN Default Class-based Route and Microsoft Endpoint Manager/Intune

Always On VPN Class-Based Default Route and Intune

`Always On VPN Class-Based Default Route and IntuneIn 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.

Always On VPN Class-Based Default Route and Intune

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).

Always On VPN Class-Based Default Route and Intune

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.

Additional Information

Deploying Windows 10 Always On VPN with Intune and Custom XML

Deploying Windows 10 Always On VPN Device Tunnel with Intune and Custom XML

Windows 10 Always On VPN Routing Configuration

Windows 10 Always On VPN Device Tunnel Operation and Best Practices