Azure P2S: One Windows Client Missing Routes After a VNet Change

Two laptops authenticate to the same Azure point-to-site gateway, and only one can reach the newly connected VNet. Both show Connected, so authentication is not the difference; the destination routes they hold are. Start from the client that fails, compare a single destination, and only then decide whether the gateway package or the local route table owns the gap.

Start from the client that fails, not the gateway

Confirm the topology before blaming the laptop. Check which VNets are connected to the gateway VNet and whether the new network is peered directly or reached through a separate site-to-site tunnel. If the new VNet is not connected to the gateway VNet at all, no client package can route to it, and the working laptop is the anomaly to explain. Write the answer down, because it decides whether you are debugging a client or a gateway.

Once the topology checks out, put the two laptops side by side. Same gateway, same address pool, same protocol and same client build is the comparison you want; anything else is a second variable you will have to eliminate later.

Compare one destination with route print

Pick a permitted resource IP and compare both laptops twice: disconnected, then connected. On Windows, route print -4 lists IPv4 routes with destination prefix, interface, next hop and metric. Record the row that would actually win for that destination rather than counting entries that contain the word VPN.

Selection is longest prefix first, then metric, so a more specific local route can beat the tunnel route without looking wrong. If the intended destination is inside 10.24.0.0/16, a healthy client shows a matching route on the VPN interface while the failing client sends the same address to its default gateway.

A conflicting local prefix can produce the same symptom. Before adding anything, decide which of the two cases you have: no tunnel route at all, or a tunnel route that loses to a more specific one.

TTL expired is not a route-distribution bug

A ping that returns TTL expired in transit says the packet used up its hop allowance, which usually means a forwarding loop rather than a broken VPN driver. Windows ping accepts a TTL up to 255, and raising the value does not repair a loop; it only delays the same error. Treat the message as a path symptom, not as evidence about route distribution.

Use tracert -4 10.24.1.10 to see where the path repeats. If the same two hops appear over and over, look for a route that sends tunnel-bound traffic back into the tunnel or into a local router that forwards it back.

Regenerate the package on the gateway that owns it

Microsoft documents that Windows client packages must be downloaded and installed again after relevant topology changes. Get the current package from the Azure gateway that serves this profile, then apply it with the supported process for that client. Replacing an unrelated VPN application executable is not the same operation as regenerating gateway-specific settings. Downloading the package again is cheap; guessing at local routes is not.

Reconnect and re-read the route for the original destination. Keep the before and after rows with the change record so the result is more precise than reinstalled the client.

The Azure P2S routing scenarios separate directly peered VNets from networks reached through other tunnels, and a new package cannot make peering transitive. Some Windows site-to-site or BGP scenarios also need manually configured remote routes, so package refresh is not a universal route-distribution mechanism.

Keep a temporary route temporary

A manual route can isolate a missing client route, but build it from the actual design: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, without the persistent flag, so it disappears at reboot. Choose the interface index and next hop from the connected VPN adapter, not from a guess.

Do not leave an experimental route in place as a permanent competing owner. Future profile updates may add the same prefix with a different metric, and then the manual entry silently decides which path wins. Record the removal step in the change.

Once the correct route is active, test the target application rather than a ping. If packets reach Azure but the service still fails, check the network security group and the return path, because those are separate from whether the laptop learned the prefix.