VPNs and Tunnels

The trick is Encapsulation: Data, Segment, Packet, Frame applied one more time. Your application sends a normal IP packet to 10.20.0.5. Instead of handing it to the Wi-Fi interface, the kernel hands it to a virtual interface — tun0, wg0 — whose driver is the VPN software. The VPN encrypts the entire IP packet, headers and all, and puts the ciphertext in the payload of a new UDP (sometimes TCP) packet addressed to the VPN endpoint’s public IP. That outer packet crosses the café network and the internet like any other; every router sees only 192.168.4.23 → 203.0.113.50 UDP 51820 and an opaque payload.

At the endpoint, the VPN software decrypts the payload, recovers the original → 10.20.0.5 packet, and injects it into the office network as if it had arrived on a local cable. Replies take the same path in reverse. Neither the application nor the office database knows the tunnel exists; the office sees a packet from the address the VPN assigned you (10.99.0.7), the café sees UDP to one address.

Connecting a VPN does two visible things to the host: a new interface appears, and the routing table gains routes through it. In a split tunnel only the private prefixes go through the VPN (10.20.0.0/16 via wg0); everything else keeps using the default route out of wlan0. The café still sees your ordinary browsing; the office sees only office-bound traffic. In a full tunnel the default route itself is redirected, so all traffic — including public internet — goes to the VPN endpoint first and out from there; the café sees one encrypted flow, and web sites see the office’s public IP.

A full tunnel cannot simply replace the default route, because the outer packets to the endpoint would then be routed into the tunnel too. The usual trick is to add 0.0.0.0/1 and 128.0.0.0/1 via the tunnel — two routes that together cover everything and are both more specific than 0.0.0.0/0, so they win longest-prefix match — plus a single host route for the endpoint’s public IP via the physical interface. WireGuard’s wg-quick does it with a firewall mark and a policy-routing rule instead, to the same effect.

The physical link carries at most 1500 bytes per frame (IP: Best-Effort Delivery Between Machines). The outer packet is a full IP + UDP header plus the VPN’s own header and authentication tag — WireGuard adds 60 bytes over IPv4 (80 over IPv6), IPsec ESP around 50–75, OpenVPN more. So the inner packet can be at most about 1420–1440 bytes, and the virtual interface advertises that smaller MTU: WireGuard defaults wg0 to 1420. Local sockets see the smaller MTU and size their segments accordingly; the local side is fine.

Trouble starts with hosts that do not know about the tunnel. A server on the office network sends 1500-byte packets toward you; the endpoint must either fragment the inner packet before wrapping it, or send back ICMP "fragmentation needed" so the server’s path MTU discovery lowers its size. If that ICMP is filtered anywhere (Firewalls), large packets are silently dropped: SSH logs in but hangs on ls of a big directory, small web pages load and large ones stall, the database connects and the first big result set never arrives. This is the MTU black hole (the mtu-blackhole challenge) with the VPN as the narrowest link. The blunt fixes are TCP MSS clamping at the endpoint (iptables -t mangle ... TCPMSS --clamp-mss-to-pmtu) or a lower MTU on the tunnel.

Remote access VPNs connect one device to a network: the laptop-to-office case above, one tunnel per user, an address assigned from a pool, usually split-tunnelled. Site-to-site VPNs connect two networks through two gateways: every host in 10.20.0.0/16 can reach every host in 10.30.0.0/16 and none of them run VPN software — the gateways hold one tunnel and the routers on each side have a route for the other prefix via their gateway. A cloud VPC connected to an office, or two VPCs in different regions, is site-to-site.

Three protocol families are in real use, and for this lesson the differences are secondary to the shared mechanism. WireGuard is a small, modern kernel module with fixed cryptography and a UDP transport; IPsec is the long-standing standard built into every OS and router, typically with IKEv2 for key exchange; OpenVPN is a user-space TLS-based tunnel that can run over TCP where UDP is blocked. All three do the same thing: authenticate the peer, agree keys, encrypt whole IP packets, and present a virtual interface. Tunnelling over TCP has a specific pathology — TCP inside TCP, where the inner and outer retransmission timers fight — which is why UDP is the default wherever it is allowed.