4.3.30 · D5Computer Networks
Question bank — NAT traversal, VPN, tunneling
Every answer here is justified, never a bare "true/false". A one-word answer scores zero.
The three pictures this page keeps referring to
True or false — justify
TF1. A NAT router assigns each private host its own public IP address.
False. The whole point of NAT is that many private hosts share one public IP; the router disambiguates replies by rewriting ports (see Figure 1), not by handing out addresses. See NAT.
TF2. NAT was invented mainly for security.
Mostly false. Its purpose was to fight IPv4 exhaustion by sharing one address; the "outsiders can't start connections" effect is a side benefit, not the design goal — a real firewall does security.
TF3. Once IPv6 is everywhere, NAT traversal problems vanish entirely.
True in principle. IPv6 gives every host a globally routable address, so there is nothing to translate — but firewalls may still block unsolicited inbound packets, so reachability logic (like Port forwarding) can persist.
TF4. A tunnel always encrypts the inner packet.
False. Tunneling only wraps one packet inside another (Figure 2) — e.g. 6in4 carries IPv6 in the clear over IPv4. Encryption is what a VPN adds on top; a plain tunnel is fully readable.
TF5. STUN by itself can guarantee two peers connect.
False. STUN only reveals your public mapping; behind symmetric NAT the mapping changes per destination, so what STUN saw is useless to the peer and you must fall back to TURN.
TF6. TURN gives worse privacy than a direct connection because a relay sees your traffic.
Partly true. The relay forwards your packets. Even if the payload is end-to-end encrypted (as in WebRTC) so the relay sees only ciphertext, it still observes metadata — who talks to whom, packet timing, sizes, and outer headers — plus it costs extra latency and bandwidth. Encryption hides content, not the fact and shape of the conversation.
TF7. A VPN makes you anonymous online.
False. Encryption extends only up to the VPN server, which sees everything and can log it; beyond it traffic exits in the clear unless protected by TLS. A VPN moves who you must trust, it doesn't erase you.
TF8. Hole punching disables your NAT's protection and lets attackers in.
False. The punched hole is one specific mapping (your port to that one peer, Figure 3). On restricted-cone NAT, only that peer's IP:port is admitted; a random attacker still has no table entry.
Spot the error
SE1. "The outer header of a tunnel packet carries the private 10.x address so the packet can be routed across the Internet."
Error: it's backwards. The inner header holds the non-routable
10.x address; the outer header carries a public IP so routers can actually deliver it (Figure 2, blue outer layer). See Private IP addressing.SE2. "Because routers must understand the inner protocol to forward a tunneled packet, tunneling is slow."
Error: routers read only the outer header. The inner packet is opaque payload — that's precisely why an IPv4-only path can carry an IPv6 packet without understanding it.
SE3. "With a 1500-byte path MTU and a 28-byte outer header, the inner packet can still be 1500 bytes."
Error: the inner packet must fit inside the outer one, so the effective inner MTU is 1500 minus 28, i.e. 1472 bytes (the pink bracket in Figure 2). Ignoring this is the classic "VPN works but big downloads stall" bug.
SE4. "Full-cone NAT is the hardest to traverse."
Error: full-cone is the easiest — once a port is open, anyone can reach it. Symmetric NAT is the hardest because it allocates a new public port per destination.
SE5. "IPsec transport mode is used for site-to-site VPNs between two networks."
Error: transport mode encrypts only the payload of an existing packet; tunnel mode wraps and encrypts the whole inner IP packet and is the one used for site-to-site links.
SE6. "ICE is a NAT-traversal protocol that replaces STUN and TURN."
Error: ICE is a framework that uses STUN and TURN. It gathers candidates (local, STUN-reflexive, TURN-relayed) and tests pairs to pick the best working one.
Why questions
WQ1. Why does an unsolicited inbound packet to a NAT's public IP get dropped?
The translation entry is created only when the inside host sends first. With no matching table row (the missing bottom row in Figure 1), the router has no private host to map the packet to, so it discards it.
WQ2. Why does making the insider start the connection enable peer-to-peer contact?
The insider's outgoing packet installs a NAT mapping (punches a hole); a reply from the peer then matches that existing hole and passes through, instead of being dropped as unsolicited.
WQ3. Why does symmetric NAT defeat STUN-based hole punching?
Symmetric NAT allocates a different public port for each new destination. The port STUN observed (talking to the STUN server) is not the port used toward the peer, so the advertised mapping is wrong.
WQ4. Why does a VPN wrap a 10.x packet in a second header instead of just sending it?
A
10.x address is non-routable on the public Internet — routers drop it. The outer public-IP header is what survives the journey, carrying the private packet as cargo.WQ5. Why can a TLS-based VPN sneak through restrictive firewalls?
It tunnels over port 443 and looks like ordinary HTTPS traffic, so a firewall that allows web browsing cannot easily distinguish it from normal TLS sessions.
WQ6. Why does every layer of encapsulation reduce the space left for real data?
Each outer header consumes bytes from the fixed path MTU, so the inner payload must shrink to compensate — the overhead is unavoidable, only its size varies.
WQ7. Why is authentication, not just encryption, part of a VPN?
Encryption stops outsiders reading the tunnel, but without authentication an attacker could forge packets that appear to come from the trusted endpoint — auth proves who put the packet in.
WQ8. Why does port-preserving NAT sometimes make traversal easier than port-randomizing NAT?
A port-preserving NAT keeps the inside port number as the public port when it can, so a peer can guess the mapping; a port-randomizing NAT picks an unpredictable public port, so guessing fails and you must learn it via STUN or relay via TURN.
Edge cases
EC1. Both peers are behind the same NAT and try hole punching to each other's public reflexive address — what can go wrong?
Some NATs don't "hairpin" (loop traffic back to their own public IP), so the reflexive path fails; ICE should also try the local candidate addresses, which succeed since both are on one LAN.
EC2. A tunnel's inner packet is exactly the path MTU size and the "don't fragment" bit is set — what happens?
The outer header pushes it over the MTU; the router can't fragment (DF set) so it drops the packet and (ideally) returns an ICMP "too big" — a black-hole if that ICMP is filtered.
EC3. The VPN server itself sits behind NAT — can it still act as a gateway?
Only if a mapping exists for it: it needs Port forwarding or must be the side that initiates, because otherwise clients' inbound packets to it are dropped just like any unsolicited NAT traffic.
EC4. A user runs a VPN and the site uses HTTPS — is the data encrypted twice, and is that wasteful?
Yes, doubly encrypted (VPN tunnel + TLS), which costs a little CPU but is good: TLS protects it beyond the VPN's exit point, where the VPN's encryption has already ended.
EC5. Zero traffic flows through a punched hole for a while — what happens to it?
NAT mappings time out after idle periods, so the hole closes; peers send periodic keepalive packets to refresh the mapping and keep the connection alive.
EC6. A peer has a public IP with no NAT at all — do STUN/TURN still matter?
STUN simply reports the same address it already has (harmless), and no traversal is needed; the connection can be direct, though a firewall could still block inbound and require configuration.
EC7. Your ISP puts you behind carrier-grade NAT (CGNAT) and your home router also NATs — what does this "double NAT" break?
There are now two translation layers, and you don't control the outer one. Port forwarding on your home router is useless because the ISP's CGNAT has no matching entry, and both sides being CGNAT'd often forces a TURN relay since neither can be reached directly.
EC8. Under CGNAT, thousands of subscribers share one public IP — how does that change port behaviour?
The carrier must hand out ports very sparingly across many users, so it tends to behave like symmetric/port-randomizing NAT (new port per flow) — exactly the case where STUN's observed mapping is unreliable and traversal is hardest.
EC9. Is a NAT that preserves the port always safe to rely on for traversal?
No — it may preserve the port until a collision, then silently switch to a random port. Traversal logic must fall back gracefully, because "port-preserving" is a best-effort behaviour, not a guarantee.
Recall Quick self-test: name the failure mode
Symmetric NAT breaks which technique, forcing which fallback? ::: Breaks STUN-based hole punching (wrong port advertised); forces the TURN relay fallback. A tunnel that ignores the outer header size causes which symptom? ::: Oversized inner packets → fragmentation or silent drops (big transfers stall) due to exceeding the effective inner MTU. "VPN = anonymous" fails because encryption ends where? ::: At the VPN server, which sees your traffic and exits it in the clear unless end-to-end TLS protects it. What makes double/carrier-grade NAT harder than a single home NAT? ::: You don't control the outer (ISP) translation layer, so port forwarding fails and CGNAT's per-flow ports often force a relay.