Nested VPN Tunnels: Why the Inner One Stalls on Big Packets
Each tunnel spends part of the path's packet budget before the next one starts. Add the headers up and the inner session fails on large packets.
DNS resolves, the SSH session stays up, and then a large upload freezes while a ping to the same host still answers. That split points at packet size rather than a broken tunnel. Nested tunnels reach it at sizes neither tunnel would hit alone. The inner session is fine; it is being handed packets that no longer fit.
Where the path MTU actually goes
Every encapsulation spends bytes before the next layer gets a turn. An Ethernet path offers 1500 bytes to the outer packet, and the outer tunnel takes its share before anything inside it can be addressed. One guessed overhead value will be wrong by exactly the amount that matters.
List the layers in order: access path, outer transport, outer tunnel, inner transport, inner tunnel, application. Count each header once, and keep UDP separate from the tunnel's own header and tag.
Two WireGuard layers, counted once
Take an IPv4 access path with one WireGuard tunnel inside another. The outer layer costs 20 bytes of IPv4, 8 of UDP and 32 for the WireGuard data header plus its authentication tag. Inside that, the inner tunnel needs its own 20-byte IPv4 header and 8-byte UDP header before its second 32 bytes of WireGuard overhead. What is left holds an IPv4 header, a TCP header and the data. An IPv6 outer path costs 40 instead of 20 and leaves 1320.
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
The arithmetic lands on 1340 bytes. One layer under the same rules leaves 1400 for the TCP payload, which is 1500 minus 20, 8, 32, 20 and 20, and the 60-byte difference is exactly the inner encapsulation the second tunnel adds.
Apply 1400 to a nested path and the inner tunnel is 60 bytes short, invisible until a packet is big enough to need them. Padding and a protocol's own fragmentation option move the figures again, so trust the table.
MTU, MSS and fragmentation act in different places
Interface MTU caps what the interface will emit, while TCP MSS clamping changes what a TCP peer is willing to send. Clamping fixes TCP sessions and does nothing for a large UDP datagram, which is how a fix looks successful for one application and silently misses the next. A protocol's own fragmentation option is a third lever with its own failures. Interface MTU is the common first move and the bluntest one.
Bridged and routed tunnels carry different frames, so numbers from another deployment rarely transfer. Path MTU discovery, described in RFC 8201, helps only while the ICMP messages it depends on are allowed through.
Finding the layer that is short
Verify each tunnel alone before nesting them, if the requirements allow a comparison. A fixed-size probe settles it: ping -M do -s 1472 -c 3 10.8.0.1 sends a full 1500-byte IPv4 packet inside that layer. Add the second layer and repeat the same probe, so any failure belongs to a known change.
When a transfer stalls, change one documented parameter at a time and record the failing size. Check the return path too, because nested route recursion can mimic a packet-size problem closely enough to cost an afternoon. A filtered ICMP reply can hide the real limit, so the probe matters more than the reasoning.
Write the budget where the next person will find it
A table with one row per layer outlives a rule of thumb. Keep it beside the tunnel diagram so nobody redoes the arithmetic under pressure.
More tunnels mean more dependencies, so a rollback plan earns its place next to the budget. If the numbers still do not add up, measure the path instead of guessing again. The goal is a figure you can defend, not remember.