Two VPN Hops on One Pi: Which Route Carries Which Peer

Two tunnel addresses on one small board look like a mistake, and the reflex is to delete one. That reflex breaks the thing it was meant to tidy. A host carrying two hops holds one address per attachment, and each address is selected by a different route. The question worth asking is which route picks which carrier for which destination, not how many addresses exist.

Three destinations that need different carriers

A two-hop chain is three destination classes stacked, and each one is carried by a different attachment. The outer peer has to be reached over the physical link. The inner peer has to be reached through the outer tunnel. The covered application's destination has to be reached through the inner tunnel, whose own transport is carried by the outer one.

Fill the rows in with the reader's real addresses before touching a route, because the table is only useful once it is concrete. A working chain satisfies all four rows at the same time, and a half-working chain usually satisfies one of them with the wrong carrier. Reading the wrong row as the failure is what turns a routing problem into an afternoon of edits.

Addresses have roles, not a count

Linux permits several addresses on one interface and several tunnels on one host, so a count says nothing about correctness. What matters is which address belongs to which attachment, and whether the route for a given peer selects the attachment you meant. Three views answer that from three directions, and they are worth reading in the same order every time.

The address inventory shows what exists and which attachment owns it. The route table answers the carrier question for ordinary destination traffic. The policy view answers it again for traffic selected by source or mark, which is the normal arrangement when two clients share one host.

ip -4 addr show
ip -4 route show table all
ip rule show

Deleting an address because the list looks long can remove part of the path, and deleting a route because it looks redundant does the same thing more quietly. Neither produces an error; the peer simply stops answering on the path you intended while staying reachable by another. An application that reports the inner peer's exit address does not prove the traffic crossed the outer tunnel, since direct access produces the same observation. That gap between an observation and a proof is why the carrier gets checked at the routing layer.

Activation order beats a fixed sleep

If the inner client depends on an address or a route that the outer client supplies, activation has to wait for that resource rather than for a delay. A sleep works until the day the outer tunnel is slow, and then it fails intermittently in a way nobody can reproduce. Dependency-based ordering removes the guess and costs nothing beyond describing the dependency once. Interface names are not an ordering mechanism either.

The kernel hands out names such as tun0 and tun1 in creation order, and that order can change across reboots or reconnects. Bind configuration to an identity the tooling provides, or to a name you assign deliberately. A name you choose is a contract; a name the kernel chooses is an accident.

Keep each client's transport out of the other's application route, and be precise about what the OpenVPN 2.6 routing options actually promise. The documented default-redirection mechanism keeps a client able to reach its own remote peer through the gateway that already existed, which cuts one specific recursion loop. It does not turn one client into another client's carrier, so the rest of the chain remains your design. Where the chain needs a policy rather than a route, write an explicit source or mark rule and test it with the traffic it is meant to match.

What happens when the outer hop dies

Before the chain counts as complete, decide what happens when the outer hop disappears. The inner client's transport dies with it, and the next move is a policy question rather than a technical one: fail, retry, or reconnect directly over the physical link. That third outcome is the one to think about. It silently converts a two-hop design into a one-hop design at the moment the user believes coverage is still intact.

If two hops are mandatory, the inner client must be unable to establish a direct path when the outer one is gone, and the way to know is to break the outer hop and watch what the inner one does. An approved fallback is a legitimate answer, but it has to be written down, tested and communicated. A fallback nobody documented is indistinguishable from a leak during an incident review.

DNS and the other address family belong to the same decision. A locally generated lookup follows the host's own policy rather than a forwarded client's, so the resolver that works for forwarded traffic may not be the one the host itself uses.

Accept each layer in the order you built it

Test in the order the chain was built: the outer tunnel alone, then the inner client's transport through the outer tunnel, then the application through the inner tunnel. Every acceptance has to be a fresh connection rather than a page that was already open. Then break and restore each layer separately and watch what the next one does.

The fallback result is the most valuable observation here, and the one a public-IP page never shows. Save the peer paths, the addresses they use and that outcome beside the configuration, because the happy path is not the part that gets questioned later.