Two VPN Clients at Once: Who Wins the Default Route?

Running two VPN clients at once is a routing argument, not a privacy setting. Whichever tunnel owns the more specific route receives the traffic, and the other one sits connected but idle. The corporate gateway then sees a connection arriving from the personal exit, while the corporate client on your machine still sees every adapter. Deciding which of those two facts matters is the whole exercise.

The route table picks one winner

Capture the table before and after the corporate client starts, and read the interface column rather than the destination alone. A plain default route from the outer tunnel is easy to displace, because a /1 pair is more specific than /0. The literal pair 0.0.0.0/1 and 128.0.0.0/1 covers the whole IPv4 space in two halves and beats any single default. Once it is installed, the outer tunnel still shows connected and carries nothing.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

Policy routing can override the main table entirely, so read the rules as well as the routes. A rule that sends marked traffic to another table wins before the main table is consulted. That is how one application can stay on the physical link while everything else uses the tunnel.

ip rule show

Windows settles it with metrics

On Windows the winner is the route with the lowest metric for the destination, and two clients can both install a default route with different metrics. Read the table and the interface configuration together, because the adapter with the lower metric is not always the one you expect. A client that also sets an interface metric can move the default without adding a single route. The adapter that loses stays up and simply receives nothing.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

Compare the two outputs and name the interface that owns 0.0.0.0/0. If both clients claim it, the metric decides, which is why an order-of-connection test can look inconsistent across machines. If neither output shows a default gateway, the client is not running full-tunnel and the chain argument is moot.

Two observers, two different views

The remote gateway sees one connection arriving from the outer exit plus whatever the client forwards into its tunnel. The local client sees adapters, routes and the existence of another tunnel, because it runs with privileges to create them. Splitting those views is the point; claiming the client cannot notice is not.

Assume the client can enumerate whatever it likes, and plan for the gateway's view instead. A design that depends on the client staying blind is one update away from breaking.

DNS and IPv6 are where the chain leaks

DNS follows whichever resolver setting wins, and that is not necessarily the path the packets take. A corporate resolver reached through the corporate tunnel is consistent with the design; a local resolver reached outside it is not, and it exposes names the tunnel was meant to hide. IPv6 is the second leak: a dual-stack host keeps using IPv6 toward destinations the tunnel only carries over IPv4. Check the families separately, because an IPv4-only tunnel says nothing about IPv6 routes or resolvers.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

Fix the resolver and the IPv6 route deliberately rather than stacking a second tunnel on top. Double encapsulation also costs MTU, so a smaller inner MTU is the first thing to try when pages stall after the chain comes up. A resolver that answers quickly is not evidence that it is the right resolver.