Visual walkthrough — NAT traversal, VPN, tunneling

Parent: 4.3.30 NAT traversal, VPN, tunneling (Hinglish)

---

Step 1 — What a packet even is (a box with a nametag)

WHAT: we draw one packet as a rectangle whose width is measured in bytes (a byte = 8 bits = one "letter" of storage).

WHY: everything later is about how wide these rectangles are, so we need a picture where width literally means "number of bytes."

PICTURE: the orange band is the header, the blue band is the payload. Their combined width is the packet's total size.

---

Step 2 — MTU: the doorway every packet must fit through

WHAT: we draw the MTU as a fixed-width doorway of $1500$ bytes and slide packets through it.

WHY this idea and not "just send it": links are not infinite. Hardware reserves a fixed buffer per packet, so there is a hard ceiling. Every byte the header eats is a byte the doorway can no longer spend on your data — that trade-off is the whole derivation.

PICTURE: a packet exactly $1500$ B wide just squeezes through; a wider one is blocked (red).

---

Step 3 — Tunneling: putting the whole packet inside a new envelope

WHAT: rename the original packet the inner packet. Add a new outer header $H_{\text{outer}}$ in front of it. The result is the tunnel packet.

$\text{TunnelPacket}=\underset{\text{new nametag routers read}}{\underbrace{H_{\text{outer}}}}\Vert \underset{\text{the whole old packet, now just "data"}}{\underbrace{[H_{\text{inner}}\Vert \text{payload}]}}$

• The symbol $\Vert$ means "glued next to" (concatenation of bytes).
• $H_{\text{outer}}$ is the only part the routers along the way read.
• The bracketed part is opaque to them — they never look inside.

WHY this tool: routers route by reading the outermost header. Give them a valid public outer header and they will happily carry a packet they don't understand — exactly how a WireGuard or IPsec tunnel smuggles a private packet across the Internet.

PICTURE: the original orange+blue packet shrinks into a single blue "inner" block, and a fresh orange outer header snaps onto the left.

---

Step 4 — The squeeze: outer header eats into the doorway

WHAT: now push the tunnel packet through the same $1500$ B doorway from Step 2. The doorway did not get bigger — but the packet did, because we added $H_{\text{outer}}$.

WHY: this is the crux. The doorway width is fixed by the physical link (call it ${\text{MTU}}_{\text{path}}$, the smallest MTU anywhere along the route). The outer header is mandatory overhead. So whatever space the outer header takes is stolen from the inner packet.

Let us name the outer header's size $h$ (in bytes):

$h=|H_{\text{outer}}|$

The tunnel packet must still obey Step 2's rule:

$\underset{\text{outer header}}{\underbrace{h}}+\underset{\text{whole inner packet}}{\underbrace{L_{\text{inner}}}}\le \underset{\text{doorway}}{\underbrace{{\text{MTU}}_{\text{path}}}}$

Here $L_{\text{inner}}$ is the total size of the inner packet (its own header plus its payload — it all counts as one lump now).

PICTURE: the orange outer header pushes the blue inner block rightward until part of it is jammed against the closed doorway edge — that jammed slice is the space we've lost.

---

Step 5 — Solve for the inner limit: the effective MTU

WHAT: take the inequality from Step 4 and isolate $L_{\text{inner}}$ — the biggest the inner packet is allowed to be.

$L_{\text{inner}}\le {\text{MTU}}_{\text{path}}-h$

We give this largest allowed value its own name, the effective inner MTU:

$\boxed{{\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-h}$

Term by term:

• ${\text{MTU}}_{\text{inner}}$ — the widest packet the tunnel can carry inside.
• ${\text{MTU}}_{\text{path}}$ — the real doorway width of the path (the smallest link MTU).
• $h$ — the bytes stolen by the outer header (and any encryption/auth trailer, in a VPN).

WHY subtraction and not something fancier: headers are a fixed number of bytes added once per packet — a flat toll, not a percentage. A flat toll is removed by subtraction. That's the entire reason the formula is a minus sign.

PICTURE: the doorway bar split into two coloured segments — a fixed orange slice of width $h$ (the toll) and a green slice of width ${\text{MTU}}_{\text{path}}-h$ (what's left for your inner packet).

---

Step 6 — The overhead ratio: how much of your pipe is wasted

WHAT: engineers also want what fraction of the wire is spent on wrapper instead of data. If the inner packet is $L$ bytes and the wrapper adds $h$ bytes, the wrapper's share of the total is:

$\text{overhead ratio}=\frac{h}{L+h}$

• Numerator $h$ — bytes of pure wrapper.
• Denominator $L+h$ — total bytes actually sent on the wire.

WHY a ratio and not just $h$: $28$ wasted bytes is nothing on a big $1472$ B packet but huge on a tiny $40$ B packet. Only the ratio captures "how much of this trip was wasted."

PICTURE: two pie-style bars — a big packet (thin orange sliver of overhead) versus a tiny packet (fat orange overhead) — same $h$, wildly different waste.

---

Step 7 — The degenerate & edge cases (never leave the reader stranded)

WHAT + WHY + PICTURE — four scenarios the formula must survive:

1. No tunnel at all ($h=0$): ${\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-0={\text{MTU}}_{\text{path}}$. The formula collapses to "just the doorway" — sanity check passed: with no wrapper you lose nothing.

2. Wrapper as big as the doorway ($h={\text{MTU}}_{\text{path}}$): ${\text{MTU}}_{\text{inner}}=0$. Zero bytes left for data — the tunnel is pure overhead and can carry nothing. A valid warning sign, not a paradox.

3. Wrapper bigger than the doorway ($h>{\text{MTU}}_{\text{path}}$): the formula goes negative. A negative MTU is physically impossible — it means this path cannot carry this tunnel at all; you must lower the path or shrink the wrapper.

4. Nested tunnels (a tunnel inside a tunnel): each layer subtracts its own header. Two wrappers $h_1,h_2$ give ${\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-h_1-h_2$. The tolls simply stack — which is why a VPN inside a 6in4 tunnel can leave surprisingly little room.

PICTURE: the doorway bar redrawn four times, one per case, with the green "usable" slice shrinking to full, to zero, to negative (hatched red = impossible), to a double-toll stack.

---

The one-picture summary

The whole derivation in one frame: a fixed doorway of width ${\text{MTU}}_{\text{path}}$, an orange toll of $h$ bytes taken by the outer header, and the green remainder ${\text{MTU}}_{\text{path}}-h$ that is the largest inner packet the tunnel can carry.

Recall Feynman: the walkthrough in plain words

Think of shipping a letter through a mail slot that is exactly a fixed size. Your letter is a packet: a small "to/from" band (the header) and the message (the payload). Now suppose the letter must cross a country that won't accept it as-is, so you stuff the whole letter, band and all, into a bigger envelope and write a fresh address on the outside — that's a tunnel. But the mail slot didn't get bigger! The new envelope's own band steals slot-space, so your original letter must now be a little smaller to still fit. How much smaller? Exactly as many bytes as the outer band uses — subtract them, that's the effective inner MTU. If the wrapper is tiny compared to your letter, almost no waste; if your letter is one keystroke, the wrapper dwarfs it and most of the trip is packaging. And the corner cases behave: no wrapper means no loss, a wrapper as big as the slot leaves nothing, a wrapper bigger than the slot means "impossible — won't fit," and stacking two envelopes just pays two tolls.

Recall

Effective inner MTU formula ::: ${\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-h$ Overhead ratio formula ::: $h/(L+h)$ Inner MTU for path 1500 with IP+GRE header (28 B) ::: $1472$ B Overhead ratio for a 12-byte inner packet with h=28 ::: $70\%$ Why is the correction a subtraction, not a percentage ::: the header is a fixed flat number of bytes added once, so it is removed by subtracting.

---

Related: NAT · Firewalls · Port forwarding · TLS · WebRTC · IPv4 exhaustion