Two VPN Clients, One Routing Table: Who Wins the Default

It looks like two VPN clients fighting over a socket, and the obvious fix must be to uninstall one. In practice they rarely touch the same socket. Each connect rewrites the operating system routing table, and a full-tunnel profile claims the default route. Whichever connected last tends to win, which is why the symptom appears to move between clients.

The conflict lives in the routing table

A virtual adapter plus a default route is how a full tunnel captures traffic. When the second client installs its own default, the older entry is replaced or demoted by metric, and every destination now travels through the newer tunnel. The first client stays connected and still shows a green icon, so the interface is up while the path is gone. That separation between connection state and routing state is what makes the behaviour confusing.

The clients are editors of one shared table. Knowing which edit happened last explains almost every symptom.

Read which tunnel owns the current path

Check the actual decision instead of trusting the client that reports connected. Ask the system which interface would carry a specific destination.

ip route get 10.20.0.5
route print -4

The first command names the interface and source address for one destination, which is the precise question you care about. The route dump shows the competing default entries and their metrics on Windows, so you can see which one currently wins. Run the lookup for a host in each remote network, because one destination can be correct while the other network is unreachable. If the answer names the wrong tunnel, reconnecting will not help; the route policy has to change.

Stop the second client claiming everything

One client should own the default route, and the other should carry only its own prefixes. OpenVPN clients can decline what the server pushes.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignores every pushed route, while pull-filter ignore "redirect-gateway" drops only the default-route directive and keeps pushed DNS and other options. Choose between them based on how much of the server's configuration you still want, then add the specific prefixes the second network needs. Keep DNS in mind, because a resolver pushed by a tunnel that does not carry the lookups returns nothing. Test one known host in each network and confirm the source address the remote side observes.

Overlapping subnets cannot be routed around

When both networks publish the same prefix, the kernel holds one entry for two different places and must choose. A host route cannot invent the missing distinction, and neither can a metric tweak. Renumber one side, or have its administrator translate the remote range so the prefixes differ. Check the real subnets before blaming the clients, since a home router default of 192.168.1.0/24 collides with an office range more often than anyone expects. Record both ranges in the ticket so the next change does not recreate the overlap.

Separate two goals as well: reaching both networks is a routing problem, while chaining tunnels for privacy is a different design with an extra operator in the path. Do not use one to solve the other.