Two OpenVPN Clients on One Linux Host: Who Owns the Route?

Both profiles report connected and one of them is quietly carrying traffic meant for the other. Two clients on one host is a supported arrangement; two clients with no owner for each prefix is not. The work is less about bringing the second tunnel up than about deciding which process may claim which route. Walk it in the order below and the configuration follows from the answers.

Start by Asking What the Second Tunnel Is For

Three situations look identical on the status line and need different designs. A destination split sends one prefix through the office profile and another through the lab profile, with neither claiming a default route. A per-application split usually keeps one full tunnel and steers specific traffic with policy rules. Failover keeps exactly one tunnel up at a time, which means the second must not start automatically.

Write the case down before opening any configuration file, because that answer decides everything after it.

The commonest broken setup is two full tunnels that both pushed a default route, where whichever connected last wins and the first keeps pretending. That state looks intentional from the status line and wastes a day from the routing table. Naming the case first makes it impossible rather than merely unlikely.

Look at the Pools Before the Routes

Two servers can easily hand out addresses from one private range, and when they do, the client ends up with two interfaces inside a single prefix. No destination can then be attributed to an interface by address, because both look equally correct. Renumber one pool rather than inventing a rule to break the tie.

Check the local network too, since a home or office LAN overlapping a tunnel range creates the same ambiguity from the other side. Compare the addresses on the host with both server configurations before blaming the client. A pool change on a lab server is a five-minute fix, while a policy-routing workaround for an overlapping prefix is a permanent tax on everyone who reads the configuration later. Decide which of those you want before choosing where to intervene.

Two address families means two rounds of this check. IPv6 pools collide as quietly as IPv4 ones.

Give Each Profile an Owner

One instance per profile, one configuration file per instance, and one name that identifies the pair. On Debian-style packaging the name after the at-sign selects the file, which is why two profiles sharing an instance name can never both work. Confirm the mapping from the installed unit rather than from a tutorial.

systemctl cat [email protected]
ip -4 addr show

Then decide who installs routes, which is a policy question rather than a syntax question.

When the two servers push incompatible sets, either add route-nopull and list only the prefixes each profile needs, or let one keep its default route and steer the rest by policy rule. Two processes both installing a default route end with a single winner and nobody able to say why. Once the two tunnels carry traffic for different sources, a reply can exit by the wrong one, and the pattern that holds up is a connection mark restored on replies and steered into its own table. Scope the marks so the tunnels' own encrypted packets never match them.

Verify Per Tunnel, Then Stop One

Once both are up, take three readings: the address on each tunnel device, the route to a host that lives behind each one, and the path a destination outside both would take. A plain route listing stops describing the final lookup as soon as rules are in play, so ask the kernel what it would actually pick. Then stop one instance and watch what disappears. If stopping the first disturbs the second, something is still shared between them: a route, a device name, or a firewall rule nobody separated.

ip rule show
ip route get 203.0.113.9

Bring the stopped profile back and repeat the same checks, because a tunnel that works once after a reboot and never again is a lifecycle bug wearing a routing costume.

Record which profile owns which prefix in the deployment notes, beside the pool ranges. Two tunnels are a deliberate arrangement, and the next reader needs the boundary visible before touching either profile. Without that note, the boundary gets rediscovered by whoever is on call when the shared prefix finally breaks.