Exercises — NAT traversal, VPN, tunneling

• NAT rewrites the source IP:port of outgoing packets to the router's public IP:port, keeping a translation table so replies map back — many private hosts share one public address.
• Tunnel wraps a complete packet as the payload of an outer packet so it can cross a network that would not otherwise route it.
• VPN is a tunnel that is also encrypted and authenticated, so two endpoints behave like one private LAN.

• STUN → tells a host its public IP:port as seen from outside.
• TURN → relays traffic through a public server when direct connection fails.
• ICE → the framework that gathers all candidate addresses and picks the best working pair.
• Hole punching → both peers send simultaneously so each outgoing packet opens a NAT mapping the other's packet can use.

Outer overhead $h=20+8=28$ B. The inner packet must fit inside the outer one, so ${\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-h=1500-28=\boxed{1472\text{B}}.$ Figure s01 — what to look for: the cyan outline is the whole 1500 B path budget; the amber block on the left is the $28$ B outer header that is spent before any inner data; the faint cyan block is what remains — exactly $1472$ B. The picture shows the header is subtracted off the front, not added on top.

$\frac{h}{L+h}=\frac{28}{1472+28}=\frac{28}{1500}=0.018\overline{6}\approx 1.9\%.$ So for a full-sized packet the tunnel wastes about $1.9\%$ of the wire on wrapper bytes — small, but it grows sharply for tiny packets (next question).

$\frac{28}{40+28}=\frac{28}{68}\approx 0.4118=41.2\%.$ The same header now costs $41.2\%$ — over 20× worse — because the wrapper is a fixed cost spread over fewer payload bytes.

Most likely symmetric NAT. A symmetric NAT allocates a new public port per destination. The STUN server saw the mapping created for traffic to the STUN server, i.e. 203.0.113.9:40000. When the same host now sends to the peer (a different destination IP:port), the NAT opens a different public port — so the port the STUN server reported no longer describes the path to the peer. The peer sends to a stale mapping and is dropped. This is exactly why symmetric NAT forces a fall-back to TURN.

Notation note: below, the double-headed arrow "$\leftrightarrow$" just means "is paired/associated with" — it marks the two-way link that one NAT table row records between your public mapping and the specific remote peer it was opened for. It is not a subtraction or any operation, just "these two belong together".

First, the two flavours (both are "restricted-cone", they differ in how strict the return filter is):

• Address-restricted cone — an inbound packet is admitted only if its source IP matches an IP the inside host has already sent to; any port from that IP is allowed.
• Port-restricted cone — stricter: the inbound packet's source IP and source port must both match something the inside host sent to.

Now the attack. Your outgoing punch created the pair $(\text{your public IP:port})\leftrightarrow (\mathrm{198.51.100.7}:6000,\text{the peer}).$

• Under address-restricted NAT the filter checks source IP only → it forwards inbound packets whose source IP is 198.51.100.7. The attacker's source 45.10.10.10 fails the IP check → dropped.
• Under port-restricted NAT the filter is even tighter, checking source IP and port → the attacker fails immediately.

Either way the attacker gets in: no. The "hole" is peer-specific (down to the IP, and under port-restricted NAT down to the exact port), not a general open door.

Step 1 — derive the outer overhead byte-by-byte. The $52$ B is not a magic number; it is a sum of concrete header fields for a common IPsec ESP-in-tunnel-mode configuration with AES-CBC + HMAC:

The variable pieces (IV, padding, ICV) are exactly why real ESP overhead fluctuates — worst-case padding can push it well past $32$ B. For this exercise we take a representative ESP contribution of $32$ B ($=8+16+\text{small padding}+\text{trailer}+\text{ICV rounded}$), giving outer total $20+32=52$ B. Always state your ESP assumption; do not memorise "32" as universal.

Step 2 — budget the MTU by subtracting each wrapper, outermost first: $1500-52=1448(\text{after VPN}),$ $1448-20=\boxed{1428\text{B}}(\text{after 6in4}).$ Overheads stack additively because each layer's header sits inside the previous layer's payload. Nested tunnels are the classic cause of "big transfers stall" bugs. Figure s02 — what to look for: three stacked bars for the same 1500 B pipe. The top white outline is the raw path; each lower bar adds another amber (VPN 52 B) or cyan (6in4 20 B) header slice on the left, and the usable payload (faint cyan) shrinks each time — read the labels right-to-left to see $1500\to 1448\to 1428$.

Term reminder — "signalling channel": before any media flows, the two browsers need a way to exchange the lists of candidate addresses they discovered. That out-of-band application channel (typically a small WebSocket/HTTPS connection through your own web server, not the peer-to-peer path itself) is called the signalling channel. It carries only setup metadata, never the media.

1. Each browser gathers candidates — ICE recognises four kinds:
   • host candidate — its own local 192.168.x.x:port.
   • server-reflexive candidate — its public mapping, learned by asking a STUN server "what address do you see me as?"
   • peer-reflexive candidate — a mapping discovered at runtime: when a connectivity check arrives from an address nobody advertised (often because a NAT created a fresh mapping for the peer-to-peer path), the receiver records that newly-seen source as a peer-reflexive candidate and adds it to the pool. This is the quadrant that STUN cannot pre-discover.
   • relayed candidate — an address on a TURN server, reserved in advance.
2. Candidates are exchanged over the signalling channel defined above.
3. ICE pairs local×remote candidates, orders them by priority (host > peer-reflexive > server-reflexive > relayed, because relay is slowest/costliest), and sends connectivity checks (STUN pings) on each pair — these checks are what reveal peer-reflexive candidates.
4. ICE picks the highest-priority pair that actually works. If both sit behind symmetric NAT and no direct pair succeeds, ICE falls back to the TURN-relayed pair — always works, but adds a relay hop. Net effect: direct when possible, relayed only when necessary.

• Tunnel mode. Site-to-site must carry whole inner IP packets addressed to private 10.x hosts across the public Internet. Tunnel mode encrypts the entire inner IP packet and prepends a new outer IP header (gateway→gateway), so the private addresses stay hidden and routable only inside. Transport mode encrypts only the payload and keeps the original IP header — no good when the original addresses are non-routable private ones.
• TLS on 443 for a roaming worker because restrictive networks (hotels, cafés) often block IPsec/UDP but almost never block 443 — the VPN traffic looks like ordinary HTTPS and slips through firewalls.

First, two terms we will need:

• DF (Don't Fragment) flag — a single bit in the IPv4 header. When set, a router that finds the packet too big for the next link is forbidden to fragment it; it must instead drop the packet and send back an ICMP "Fragmentation Needed" message telling the sender the smaller MTU. This mechanism is Path MTU Discovery (PMTUD).
• ICMP black-hole — if a firewall along the way silently discards those ICMP "too big" messages, the sender never learns it must shrink. Large DF packets keep being dropped with no feedback → the transfer just hangs. This broken state is what makes tunnel MTU bugs so maddening.

(a) Inner MTU $=1420-60=\boxed{1360\text{B}}$. (b) MSS is the TCP payload per segment, so subtract the inner IP+TCP header (40 B) from the inner MTU: $\text{MSS}=1360-40=\boxed{1320\text{B}}.$ (c) Bulk downloads use full-size packets that, once wrapped, exceed the path MTU; with the DF flag set they are dropped and — if PMTUD's ICMP feedback is black-holed — never resized, so the transfer stalls, while small browsing requests already fit and feel fine. Clamping MSS to $1320$ B forces every TCP segment to be born small enough that the full wrapped packet survives.

• "My ISP can't read anything" — partly true: the ISP sees only encrypted VPN traffic to the gateway, so this clause is OK for content, though the ISP still sees you use a VPN and the traffic volume.
• "The VPN provider can't read anything" — false. Traffic is decrypted at the VPN server; beyond it the packets exit toward the bank in whatever form the inner protocol dictates. The provider is now the party who sees your traffic. Only end-to-end TLS (HTTPS) keeps the content hidden from the provider too.
• "Fully anonymous" — false. The bank still authenticates you (login, cookies). A VPN changes which IP appears and who you must trust, not who you are. Correct model: a VPN shifts the trust boundary from your ISP/local network to the VPN provider, and encrypts only up to the VPN server. Anonymity and end-to-end secrecy are separate properties provided by other tools.

• host × host candidate pair — only works if both are on the same LAN (not the case for two remote users).
• server-reflexive candidates — useless here: symmetric NAT gives a new port per destination, so the STUN-learned port doesn't apply to the peer path.
• peer-reflexive candidates — symmetric NAT keeps changing the mapping per destination, so even the runtime-discovered address on one check need not survive to the next; unreliable here.
• relayed candidates — the intended fallback, but TURN is blocked, so unavailable. Honest outcome: connection fails. With symmetric NAT on both ends and no working relay, ICE has exhausted its options. This is the textbook scenario where NAT traversal cannot succeed — the only fixes are outside ICE (e.g. Port forwarding / static mapping on one side, IPv6 with a global address, or a reachable relay).

NAT hides you, so an outsider can't knock. STUN tells you the address the world sees; if that's stable, you and a friend knock at the same instant (hole punching) and both doors open. If your NAT changes its port for every friend (symmetric), you give up and route through a helper (TURN). Every wrapper you add — tunnel, VPN, nested tunnel — steals bytes from your packet, so you must shrink the packet (lower MSS) to keep it from being too fat to pass. And a VPN doesn't make you invisible; it just changes who you have to trust with your secrets.