Two OpenVPN tunnels on one Linux host: who owns the route?

Two profiles connected, and one of them is quietly carrying traffic meant for the other. A Linux host can run both OpenVPN clients at once without difficulty. What it cannot do is decide for you which process may claim which prefix. That decision has to be made before the second tunnel comes up, not after a resource stops answering.

Start from the job the second link has to do

An office reachable through one profile and a lab reachable through another needs both tunnels up and neither one claiming everything. A single stubborn application that must leave through the second profile needs a policy rule rather than a second default. A standby link needs only one tunnel running at a time, so the spare should not start with the machine.

Those are three different configurations, and they get confused because all three begin the same way: a second profile and a successful connection. Write the intended arrangement down first, then configure towards it. A sentence of intent saves an hour of packet captures.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

The first command lists the instances that are running, including any started by hand outside the manager. The second prints the current default claim, which is the state you will have to explain later.

Overlapping pools break before routing does

Two servers will cheerfully assign addresses out of the same 10.8.0.0/24. The client then holds two interfaces inside one prefix with nothing to say which destination belongs to which, and the resulting behaviour looks like a routing fault but is really a numbering one. Renumbering a pool costs a configuration edit; every routing workaround afterwards costs a weekend. Check the pool before you add a route for it.

Look at the local LAN as well. A home LAN numbered 192.168.1.0/24 that one tunnel also exposes produces the same ambiguity, and the symptom is a hostname that resolves while the connection never completes. That looks like a name resolution fault until you print the routes.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Compare both outputs against the two server configurations before touching the client. If the prefixes overlap, stop and renumber, because no amount of restarting will separate them.

Give every profile its own unit and every prefix an owner

Each profile gets its own instance name and its own configuration file, so the instance called office loads office.conf while the one called lab loads lab.conf. Confirm that mapping through the service manager instead of trusting a directory listing, since a drop-in can change which file is loaded. Getting the mapping wrong means you tune the profile that is not running.

Then settle who installs routes. When the servers push incompatible sets, either refuse the push and list the prefixes yourself, or let one profile keep the default and steer the other with policy rules. Two processes both installing a default end with a silent winner and no written record of the decision.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

The first shows the unit with any override that changes its arguments. The second shows whether the profile accepts pushed routes at all, which is the switch that decides everything downstream.

Marks keep replies on the interface they arrived from

When each tunnel serves different sources, a reply can leave by the wrong link and the connection dies after the first packet. The pattern that holds is to mark arriving packets by input interface, restore that mark on the reply, and give each mark a table with its own default gateway.

Loose reverse-path filtering usually has to be relaxed for the affected interfaces, because a reply legitimately arrives on a link the main table would never choose. Keep the marks narrow so they never capture the tunnels' own encrypted traffic, which would send the tunnel through itself.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Read the existing rules before adding another. Duplicate priorities and forgotten tables are the usual reason a mark policy appears to have no effect at all.

Prove isolation by stopping one link

With both tunnels up, record each interface address, the route to one host behind each tunnel, and the path an unrelated destination takes. Ask the kernel for the lookup rather than reading a single table, because one table never shows the final decision.

Then stop one instance and watch its interface and routes vanish while the other carries on. A break in the survivor means the two still share a device name, a route or a firewall rule that nobody separated.

Bring the stopped profile back and repeat the same checks. When a tunnel survives only the first start after a reboot, you are looking at a lifecycle defect rather than a routing design.