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
Some Guy
/ November 8, 2021Great reminder. I would extrapolate a more general moral from the story: [b]if it’s not working the way you’re asking it to, make sure what you’re asking makes sense[/b].
I spotted the subnetting error immediately when reading this story, but I can definitely relate to the feeling of innocently making an error like that and then getting stuck trying to troubleshoot a seemingly impossible problem.
Richard M. Hicks
/ November 8, 2021Great advice! If you do a LOT of networking I’m sure it is easier to spot incorrect subnets like that. I do a fair amount though and I missed it. However, I knew enough to verify it. 🙂 On a somewhat related note, I can’t tell you how often I find administrators using 172.100.40.0/20 (as an example) thinking it is a private IP address range. 😉
Mark
/ February 22, 2022Hi,
Just wondering, do I always use the same MaskBits the the Get-Subnet returns? For example… if I have an UP 103.122.54.0 and the Get-Subnet returns 103.0.0.0/8 is that what I use? Or is there a particular prefixsize I should be using in this scenario
Mark
/ February 22, 2022Just want to double confirm – if I want to route particular public IP’s and hostnames via the VPN, would I follow the same steps?
Richard M. Hicks
/ February 22, 2022No. If you want to route a *specific* public IP address over the VPN tunnel you would specify a /32 mask. Of course, you could use a broader mask if the public website has multiple IP addresses in a given subnet.
Lenny
/ December 2, 2022Hello Richard,
Thank you for all your work on always on VPN, it helped me a lot to deploy it in my company.
Since this week, we hare facing a new issue.
Sometimes, our vpn user tunnel does miss all our routes from our split tunnel configuration.
Strangely, this issue is really random, it can happen in SSTP, in IKEV2, in both of our RAS server.
So it looks like the issue is based on our VPN profile, but as I said, it’s working well most of the time.
When this happen, we just have to disconnect and reconnect the VPN, and routes are coming back. We may need to to that more than once for it works.
When the issue is present, if we do a Get-VpnConnection -Name ‘VPN’ | Select-Object -ExpandProperty Routes
Routes are showing correctly, but not with a route print.
If you have any information about that, would be greatfull !
Thanks a lot !
Richard M. Hicks
/ December 2, 2022Wow, that’s unusual. That’s not something I’ve seen myself. Just for good measure, though, do you see the routes if you run the following PowerShell command when this happens?
Get-NetRoute -AddressFamily IPv4
Lenny
/ December 15, 2022Hello, with that command I do not see the routes too.
We have a device VPN used at the same time, and routes are always working for it.
But still same issue from the user one.
Richard M. Hicks
/ December 15, 2022If you restart the VPN connection then the routes appear?
Lenny
/ December 20, 2022Hello, yes if I restart it routes are coming back (not always, we may need to restart it like more than once for it works)
Richard M. Hicks
/ December 20, 2022That’s quite unusual. I’m not sure what would cause that, honestly.
James Hawksworth
/ February 3, 2023I’m also seeing this, but only on some devices, not everyone. VPN connects on login, but nothing works due to the lack of routes until you disconnect and reconnect. Very strange!
Richard M. Hicks
/ February 3, 2023That is weird.
André
/ May 12, 2023Hello, we configured a Device Tunnel. But the added routes are not active once the Device Tunnel is activated. only the route for the VPN Vnet itself is visible. All other routes to company internall vnets are not present and thus not reachable.
Get-VpnConnection -AllUserConnection | Select-Object -ExpandProperty Routes does not show any entries. (entries are only shown when using user tunnel). Also route print does not show the entries.
Is there anything different with device tunnel regarding the routes? as far as i read, those routes should also be supported with device tunnel… any idea? Thanks
Richard M. Hicks
/ May 12, 2023Take a close look at how you’ve configured your routes. If they are not properly formatted, they won’t appear in the routing table. More details here: https://directaccess.richardhicks.com/2021/11/08/always-on-vpn-client-routes-missing/.
Flo-TPG
/ November 27, 2023false
” – is this available now in Windows 11 23h2?
The documentation still says its available since 21h2 which you mentioned isn’t true:
https://learn.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp#deviceprofilenameuserascredentials
We struggle with UseRasCredentials is getting set to =1.
We’re using custom XML via Intune.
We run your famous remediation script hourly. A few users have issues with SQL and SSPI errors like:
“The Service Principal Name (Delegation) configuration has been set incorrectly
Server Connect URL: “net.tcp://server01.domain.local:7146/NAVProd01/Service”.
SPN Identity: “DynamicsNAV/server01.domain.local:7146″
A call to SSPI failed, see inner exception”
Setting UseRasCredentials=0 helps to fix this but it looks like, it’s getting set back to =1 (not sure when, you mentioned on every VPN connect?)
Richard M. Hicks
/ November 28, 2023I don’t believe the UseRasCredentials setting in XML is supported in any current release of Windows today. I haven’t tested 23H2, though.
You can use Intune Remediations to update rasphone.pbk, but this has limitations. For example, if the setting is changed while the VPN is connected, the change won’t take effect until the VPN is restarted. Also, if the VPN profile is removed and replaced (a known issue when using Windows 11 with custom XML) you end up with a new VPN profile each time the device syncs. This restores the default setting for UseRasCredentials which means the remediation must run again (and potentially another VPN restart will be required).
Alternatively, you could implement the setting using group policy by enabling the following setting.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication = Enabled
Ultimately this is a registry setting somewhere, but I can’t seem to find that reference right now. I’ll post it when I find it, though.
Hope that helps!