Worked examples — NAT traversal, VPN, tunneling

---

The scenario matrix

Before working examples, let us enumerate every case class this topic can throw at you. Each example below is tagged with the cell it fills.

Cell	Case class	What makes it different	Example
A	Simple encapsulation overhead	one wrapper, positive-sized packet	Ex 1
B	Stacked / double tunnel (VPN-in-tunnel)	overhead adds up	Ex 2
C	Degenerate: inner packet exceeds effective MTU	fragmentation / drop	Ex 3
D	Limiting case: tiny payload	overhead ratio → near 1	Ex 4
E	Limiting case: huge payload	overhead ratio → 0	Ex 4
F	NAT-type decision (which traversal works?)	full-cone vs symmetric	Ex 5
G	STUN mapping read-off (public IP:port)	table arithmetic	Ex 6
H	Real-world word problem (throughput cost of TURN)	latency + bandwidth	Ex 7
I	Exam twist: encryption expands the payload	crypto overhead ≠ header only	Ex 8

Why a matrix first? So you can see there are no hidden scenarios. Positive/normal, degenerate (too big), the two limits (tiny/huge), and the discrete decision cases (NAT type) — every input space is covered.

---

The two formulas we reuse

Everything here rests on two relations from the parent note. Let us re-anchor them so no symbol is unearned.

Why "ratio" and not just "bytes"? The ratio answers "what fraction of my bandwidth is wasted on wrappers?" — a percentage, comparable across packet sizes. The raw byte count answers "will it fit?". Different questions, different tools.

---

Cell A — Simple encapsulation overhead

1. Add the outer headers. $h=20+8=28$ B. Why this step? GRE stacks an IP delivery header plus its own 8-byte GRE header; both are "outer" bytes the wire carries.
2. Effective inner MTU. ${\text{MTU}}_{\text{inner}}=1500-28=1472$ B. Why this step? The inner packet must fit inside the outer one; 28 B are spent before any inner byte.
3. Does 1400 fit? $1400\le 1472$ ✓ — no fragmentation. Why this step? Always compare $L$ against ${\text{MTU}}_{\text{inner}}$, never against 1500.
4. Overhead ratio. $\frac{h}{L+h}=\frac{28}{1400+28}=\frac{28}{1428}\approx 0.0196=1.96\%$.

Verify: Wrapped packet = $1400+28=1428\le 1500$ ✓ fits the path. Overhead $1.96\%$ means ~98% of wire bytes are useful — plausible for a fat 1400-byte packet.

---

Cell B — Stacked tunnels (double wrap)

1. Sum all outer bytes. $h=60+20=80$ B. Why this step? Each wrapper is opaque to the one outside it; from the wire's view they are just more outer header. Bytes add.
2. Effective inner MTU. $1500-80=1420$ B. Why this step? Both layers eat into the same 1500-B budget.
3. Fit check. $1300\le 1420$ ✓.
4. Overhead ratio. $\frac{80}{1300+80}=\frac{80}{1380}\approx 0.0580=5.80\%$.

Verify: Total on-wire = $1300+80=1380\le 1500$ ✓. Overhead 5.8% > Ex 1's 1.96% — more wrappers, more waste, as expected.

---

Cell C — Degenerate: inner packet too big

1. Effective inner MTU. $1500-73=1427$ B. Why this step? IPsec tunnel mode wraps the entire inner IP packet plus ESP overhead — a hefty 73 B here.
2. Compare. $L=1500>1427$. The wrapped packet would be $1500+73=1573>1500$ B — too big for the path. Why this step? This is exactly the degenerate cell: inner size exceeds effective MTU.
3. Outcome. Either the router fragments it (slow, sometimes blocked by Firewalls) or, if the inner packet has the Don't-Fragment bit set, it is dropped and an ICMP "too big" is returned — which a firewall may swallow, causing a silent stall. Why this step? Look at s01: the red packet is longer than the outer envelope's mouth — it cannot go in whole.
4. Largest safe inner packet. $L_{\max }={\text{MTU}}_{\text{inner}}=1427$ B.

Verify: $1427+73=1500\le 1500$ ✓ exactly fits. One more byte ($1428$) gives $1501>1500$ ✗ — so 1427 is the true ceiling.

---

Cells D & E — The two limits (tiny and huge payload)

1. Tiny payload (cell D). $\frac{40}{1+40}=\frac{40}{41}\approx 0.9756=97.56\%$. Why this step? When $L\to 0$, the fraction $\frac{h}{L+h}\to \frac{h}{h}=1$: almost all bytes are wrapper. This is why interactive traffic (SSH keystrokes, VoIP) is bandwidth-inefficient through tunnels.
2. Huge payload (cell E). $\frac{40}{65000+40}=\frac{40}{65040}\approx 0.000615=0.0615\%$. Why this step? When $L\to \infty$, $\frac{h}{L+h}\to 0$: the fixed wrapper is negligible against a giant payload.
3. The trend. Look at s02: as $L$ grows left→right, the overhead curve falls from ~100% toward 0. The fixed header is a toll: cheap per big truck, expensive per tiny scooter.

Verify: Both limits are bracketed: $0<0.000615<0.9756<1$ ✓. The function $\frac{40}{L+40}$ is strictly decreasing in $L$, so tiny gives the max and huge gives the min. ✓

---

Cell F — Which traversal works? (NAT-type decision)

1. Recall what each NAT does. Full-cone: one public port opened, anyone can use it. Symmetric: a new public port per destination. Why this step? Traversal success depends entirely on whether the port a peer learns via STUN is the same port used to reach the other peer.
2. P learns its mapping via STUN. But P's NAT is symmetric: the port P sees when talking to the STUN server is different from the port it will allocate when talking to Q. Why this step? Q would send to P's STUN-reflexive port — but that port only maps back to the STUN server, not to Q. Q's packet has no matching entry → dropped.
3. Try the reverse direction. P sends to Q's full-cone mapping — that does work (full-cone admits anyone). So P→Q punches a hole. But for a two-way connection ICE needs a working pair; Q→P still fails because of step 2. Why this step? A media connection needs both directions; one-way success is not enough.
4. Decision. Symmetric × anything (except full-cone-with-luck) → fall back to TURN relay.

Verify: Matches the parent rule: "Symmetric NAT → traversal often fails → use TURN." The relay always works because both peers initiate outbound to the relay, each punching its own valid hole. ✓

---

Cell G — STUN mapping read-off

1. Identify the reflexive candidate. The public mapping the peer must use is 198.51.100.7:41000. Why this step? STUN's whole job is to reveal the outside view — the address the NAT table maps back to this host.
2. Why not the private one? 192.168.1.20 is non-routable on the public Internet (RFC 1918). A peer packet aimed there would never leave the peer's own LAN. Why this step? Private ranges (192.168.x.x, 10.x, 172.16–31.x) are reused everywhere; they cannot be globally addressed. See IPv4 exhaustion.
3. Advertise. Host tells peer via signaling: "reach me at 198.51.100.7:41000."

Verify: The reply address = the NAT's outside mapping = 198.51.100.7:41000, matching the table entry 192.168.1.20:52000 ↔ 198.51.100.7:41000. ✓ Port advertised (41000) equals the translated port, not the internal 52000. ✓

---

Cell H — Real-world word problem (TURN cost)

1. Total bitrate through relay. Up + down = $2+2=4$ Mbps. Why this step? TURN relays each direction separately, so both legs consume relay bandwidth.
2. Duration in seconds. $10\text{ min}\times 60=600$ s.
3. Total bits. $4\times 10^6\text{ bit/s}\times 600\text{ s}=2.4\times 10^9$ bits. Why this step? bitrate × time = total bits. Watch units: Mbps = $10^6$ bits/s.
4. Convert to gigabytes. $\frac{2.4\times 10^9\text{ bits}}{8}$ bytes $=3.0\times 10^8$ bytes $=0.3$ GB (using $1\text{ GB}=10^9$ bytes). Why this step? Bandwidth is billed in bytes; divide bits by 8.
5. Cost. 0.3 \text{ GB} \times \0.10/\text{GB} = $0.03$.

Verify: Units cascade: \text{Mbit/s} \to \text{bit} \to \text{byte} \to \text{GB} \to \text{\}$✓.$4\text{ Mbps}\times 600\text{ s} = 2400\text{ Mbit} = 300\text{ MB} = 0.3\text{ GB}, cost \0.03. Cheap per call — but multiply by thousands of concurrent calls and TURN becomes the reason engineers prefer direct traversal. ✓

---

Cell I — Exam twist: encryption expands the payload

1. Padding first. ESP encrypts (payload + 2 trailer bytes) and pads to a 16-byte multiple. Encrypted region before pad = $1400+2=1402$ B. Next multiple of 16 above 1402 is $1408$. Pad bytes = $1408-1402=6$ B. Why this step? Block ciphers (TLS/IPsec often use AES with 16-byte blocks) require input length to be a whole number of blocks — this is real overhead that grows the payload, unlike a fixed header.
2. Sum every added byte. $h=\underset{\text{IP}}{\underbrace{20}}+\underset{\text{ESP}}{\underbrace{8}}+\underset{\text{IV}}{\underbrace{16}}+\underset{\text{pad}}{\underbrace{6}}+\underset{\text{pad/nxt}}{\underbrace{2}}+\underset{\text{ICV}}{\underbrace{12}}=64$ B. Why this step? Encryption overhead = headers + IV + padding + authentication tag — students who count only the IP header get this exam question wrong.
3. Fit check. Wrapped = $1400+64=1464\le 1500$ ✓.
4. Overhead ratio. $\frac{64}{1400+64}=\frac{64}{1464}\approx 0.0437=4.37\%$.

Verify: $1402$ rounded up to a 16-multiple: $1402=16\times 87+10$, so next multiple is $16\times 88=1408$, pad $=6$ ✓. Total $20+8+16+6+2+12=64$ ✓. On-wire $1464\le 1500$ ✓, no fragmentation. ✓

---

Recall

Recall Which formula for "will it fit" vs "how wasteful"?

Fit ::: compare $L$ against ${\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-h$. Waste ::: overhead ratio $=h/(L+h)$.

Recall Ex 3: largest safe inner packet with

$h=73$, path 1500? $1500-73=1427$ B ::: (1428 would overflow to 1501).

Recall Ex 4: overhead limits as payload → 0 and → ∞?

$L\to 0\Rightarrow$ ratio → 100%; $L\to \infty \Rightarrow$ ratio → 0% ::: fixed header is a toll — brutal on tiny packets, negligible on huge ones.

Recall Ex 5: symmetric × full-cone NAT — direct or TURN?

TURN relay ::: symmetric NAT allocates a new port per destination, so the STUN-learned port doesn't match; hole punching fails one way.

Recall Ex 8: why is crypto overhead more than a header?

It adds IV + padding-to-block-size + auth tag ::: padding even grows with payload alignment, not a fixed constant.