Chaining Two VPNs: What It Hides and What It Costs

Two nested tunnels do not make you anonymous. They split the observations between two providers, so neither one sees your home address and your destination together. That is a genuine but narrow benefit, and it arrives with routing, DNS and MTU problems that show up the first time you depend on it.

1. Decide what the second hop is for

Write the goal in one sentence before you configure anything. If it is that your ISP cannot see which sites you visit, one tunnel achieves it. If it is that no single provider can link your address to your traffic, two do. If it is that nobody can identify you, no number of hops gets there.

The chain is only as strong as the weaker provider's logging and the account records both of them keep. Payments, signup email and app telemetry sit outside the tunnel entirely.

2. Make the inner endpoint reachable through the outer tunnel

The usual failure is that the inner tunnel never establishes. A full-tunnel outer connection owns the default route, so the inner client's attempt to reach its own endpoint gets swallowed by the outer tunnel and dropped or looped. The inner endpoint needs an explicit route through the outer interface, installed before the inner client starts. Otherwise the handshake races the route and loses.

WireGuard shows the same conflict from the other direction. Each peer's AllowedIPs decides which destinations enter that tunnel, so an inner interface claiming every address also claims the outer endpoint unless a more specific route wins. Overlapping AllowedIPs across two interfaces is a configuration where one side silently loses.

Container chaining makes the separation explicit and the trap obvious. A container with its own namespace, its own default route and a client inside it forwards what the host sends to it; the host does not start using that path by itself. Enable forwarding, add a route for the container's tunnel, and point the service at the container address.

3. Keep DNS on the same path

DNS has to travel where the traffic travels. If the inner provider pushes resolvers and the host still queries the local ones, those lookups reveal exactly the sites the tunnel was meant to hide. Check with a capture on each tunnel interface instead of trusting the client's status panel. A leak here is invisible during normal browsing and obvious in a capture.

Split DNS designs make this harder, because a query for a local name can legitimately belong outside the tunnel. Write the exception list deliberately rather than discovering it from whichever resolver happened to answer.

4. Set MTU before users find out for you

MTU is the other predictable casualty. Two encapsulations subtract two headers, and an outer tunnel that already lowered the path MTU leaves less room inside. The symptoms are familiar: small requests succeed, large transfers and TLS handshakes stall.

ip link set dev wg1 mtu 1280 is the blunt fix, and clamping MSS on the forwarder is the tidier one. Retrying the connection is not a fix at all.

5. Test the failure you will actually get

Break the outer tunnel on purpose and watch what happens. A chain that silently falls back to a direct path when the outer hop dies is worse than no chain, because it leaks at precisely the moment you believed you were covered. A kill switch that stops all traffic is the behaviour to aim for. Record the result, since you will not want to rediscover it mid-incident.

Latency and a second point of failure are the standing costs. Two hops also mean two support queues when something breaks at an inconvenient hour.