Two Windows VPNs at Once: Which Profile Keeps the Default?

Plug in the second tunnel and the first goes quiet, while both clients still report a healthy connection. Windows has one default route to give, and each profile that claims it takes it from the other. The symptom looks like a VPN outage but it is a routing contest between two profiles. Decide which tunnel should own that route and the rest of the configuration follows.

Only one entry can be the best default

The IPv4 routing table holds a single winning route for destinations that have no more specific match. A VPN profile that installs its own replaces the previous one as soon as it connects, and traffic that used to enter the first tunnel leaves through the second instead. The first tunnel stays up; what disappears is any packet that would have used it for general destinations.

Client status icons cannot show that. They report that a tunnel was established, not which prefixes still route toward it, so the user sees two green icons and a timeout in an application. Reading route print -4 during the failure is more informative than any VPN log.

Name resolution is a second, independent conflict, and fixing the route table alone will not settle it.

What the checkbox installs, and what it removes

The option sits in each VPN profile's adapter properties under IPv4 advanced settings, phrased as using the default gateway on the remote network. Enabled, every connection adds a default route through the tunnel and puts that interface in line for general traffic. Disabled, Windows keeps the route for the tunnel's own subnet and leaves the rest of the table alone.

Clearing it is where most people get stuck. The remote site usually has more than one prefix, and none of those prefixes is inside the adapter subnet, so file servers and management addresses stop answering. The checkbox did not break the tunnel; it removed the broad route that had been covering everything.

Mixed configurations are legitimate and common: a corporate profile keeps the checkbox as a full tunnel, while a lab profile is split so it cannot displace the corporate default.

Choose by what each tunnel must carry

Three questions decide the arrangement. Does this tunnel need to carry ordinary internet traffic, or only addresses inside its own site? Do the two sites use disjoint private ranges? And if the profile is managed by an employer, are you allowed to change its route behaviour at all?

If one tunnel must be full, it owns the default and the other must be split. If neither needs general internet traffic, clear the checkbox on both and let the physical adapter keep the default. If the ranges overlap, stop: 172.22.0.0/16 cannot mean one machine on the corporate side and another on the lab side, and no checkbox resolves that.

Record the decision beside the profile names. A third VPN added next quarter will otherwise repeat the investigation from the beginning.

Add the missing prefixes and test the result

For each split tunnel, add the remote ranges explicitly, using the peer address shown on that adapter instead of the public server address:

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

A PPP adapter uses its peer address as the next hop, while a TAP adapter usually uses the gateway shown on that interface, so read the adapter details rather than copying a number from a guide. Add the persistent flag only after the route has proved correct, and delete old persistent entries before adding replacements. Managed clients may install and protect their own routes, in which case the profile owner has to make the change.

DNS needs a separate pass. Both tunnels can push resolvers, and Windows keeps a per-interface list with a preference order, so a name belonging to the second network can be sent to the first network's resolver. Look at what each adapter actually received before choosing a fix:

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

A per-domain name-resolution policy is usually better than replacing the global resolver list, because that list is shared by every application on the machine and changing it quietly moves unrelated lookups.

Accept the setup with four checks: one resource in each remote network reached by address, a name lookup in each, the internet default still pointing at the physical adapter, and a remote desktop session that survives the second connection coming up.