VPNs, tunnels, and overlay networks

A tunnel is a packet inside a packet

Tunneling means carrying a complete packet as the payload of another packet. That is encapsulation from Lesson 2-2, applied at the same layer instead of a lower one, so an IP packet ends up inside an IP packet.

[ outer IP ][ tunnel header ][ inner IP ][ TCP ][ data ]
   \_ routed by the internet _/   \_ the real conversation _/

The internet routes the outer packet and never inspects the inner one. Whatever address the inner packet uses, private or otherwise, is meaningless to the routers in between and perfectly meaningful at both ends of the tunnel.

A VPN (virtual private network) is a tunnel plus encryption plus authentication. The tunnel provides reach, the crypto provides privacy, and the authentication decides who is allowed in. Four distinct reasons to build one, and they have different requirements:

1. Remote access. A laptop anywhere gets an address inside the office network and can reach internal services. 2. Site to site. Two offices join their private networks over the internet, so 10.1.0.0/16 and 10.2.0.0/16 route to each other. 3. Privacy from the local network. Everything leaves your machine encrypted, so the coffee shop's Wi-Fi and the ISP see only tunnel traffic to one endpoint. 4. Overlays. Build a virtual layer 2 or layer 3 network across an arbitrary physical one, which is how cloud and container networking works.

Notice that reason 3 moves trust rather than eliminating it. The local network can no longer see your traffic, and the VPN provider now can. That is a valid trade when you trust the provider more than the coffee shop, and it is not a general increase in privacy.

The technologies, and what layer each wraps

Three of these deserve a note.

IPsec is a suite rather than a protocol. ESP (encapsulating security payload) provides encryption and integrity and is what everyone uses. AH (authentication header) provides integrity only and is largely abandoned, partly because it covers fields that NAT rewrites, which makes it incompatible with NAT. IPsec's key exchange, IKEv2, is a separate negotiation on UDP port 500, and NAT traversal moves the data to UDP 4500.

WireGuard is worth knowing as a design lesson. It is a few thousand lines of code with no cipher negotiation at all, one fixed modern suite, and keys that are simply listed in the configuration. Its predecessors were large, configurable, and correspondingly hard to audit. Less choice turned out to be more security.

VXLAN wraps layer 2 frames, which is what makes it different in kind. A 24 bit VNI identifies up to 16 million virtual networks, against the 4094 VLANs of Lesson 3-2, and because the wrapper is UDP the virtual network can span any routed infrastructure. That is precisely how a cloud provider gives thousands of customers isolated networks over one shared physical fabric.

Two costs you will meet immediately

The MTU shrinks. The tunnel header is not free, and it comes out of the same 1500 bytes from Lesson 3-3.

physical MTU                     1500
outer IPv4 header                 -20
UDP header                         -8
WireGuard header and auth tag     -32
usable inner MTU                 1440

If the inner interface still claims 1500, the sender builds packets that cannot fit, and with DF set they are dropped. Combine that with a firewall blocking ICMP and you get the classic tunnel symptom: SSH connects and the shell works, then any command with long output freezes. Small packets fit, large ones do not. Setting the tunnel interface MTU correctly, or clamping TCP MSS on the tunnel, is the fix.

Routing decides what actually goes through. A VPN client works by installing routes, so read the routing table to know what the tunnel carries.

Full tunnel gives one consistent egress point for policy and logging, and it sends video calls on a detour through headquarters. Split tunnel is faster and leaves non company traffic outside your visibility. Neither is wrong, and mixing them up by accident is what produces "the VPN made everything slow".

A related detail worth checking: a full tunnel should also push its own DNS resolvers, otherwise name lookups still go to the local network and reveal which internal hostnames you are asking about, which is called a DNS leak and is a routing oversight rather than a crypto failure.

Overlay, underlay, and where this is heading

Two words that make cloud networking documentation readable:

- The underlay is the real physical network of switches, routers, and links, addressed with real addresses and routed normally. - The overlay is the virtual network built on top of it with tunnels, with its own addresses that the underlay never routes.

Container and cloud platforms are overlays. A pod address is meaningful only inside the overlay, packets between hosts are wrapped in VXLAN or a similar encapsulation, and the underlay simply carries UDP between physical hosts. Understanding this splits debugging cleanly in two. Is the underlay delivering the outer packets, and is the overlay mapping the inner addresses correctly? They are separate questions with separate tools, and answering them in that order saves hours.

One closing shift in thinking. The tunnel model assumes a trusted inside and a hostile outside, with the VPN as the door. That assumption weakens once employees work anywhere, workloads run in several clouds, and a compromised laptop is already inside. The zero trust approach instead authenticates and authorizes every individual request, regardless of where it came from, so being on the network grants nothing by itself. In practice, identity aware proxies and per service authentication increasingly replace "connect the VPN and everything is reachable". The tunnel technologies stay useful, they just stop being the security boundary.