VPNs

Encrypted tunnels — IPsec, OpenVPN, and WireGuard

VPN Architectures

A VPN creates an encrypted tunnel between endpoints, making it appear as if they share a private network even when communicating over the public internet. The architecture determines how many tunnels exist and who connects to whom.

Site-to-Site

Connects two entire networks over an encrypted tunnel. All traffic between the networks is automatically routed through the VPN. Common for connecting offices, data centers, or cloud VPCs.

Remote Access

A single device (laptop, phone) connects to a network. The VPN client creates a tunnel to the VPN server, and the device gets an IP on the remote network.

Full Mesh

Every node connects directly to every other node. No central server bottleneck — traffic takes the shortest path. This is the Tailscale/Nebula model.

All nodes have direct encrypted tunnels to each other — no central hub

IPsec

IPsec is the original VPN standard, operating at Layer 3 (network layer). It's built into every major OS kernel and is the default for site-to-site VPNs in enterprise and cloud environments. It's powerful but notoriously complex to configure and debug.

IKE (Internet Key Exchange)

Before IPsec can encrypt traffic, peers must authenticate and agree on encryption parameters. This negotiation happens in two phases via IKE (usually IKEv2).

ESP (Encapsulating Security Payload)

ESP is the protocol that actually encrypts and authenticates the data. It's IP protocol 50 (not TCP or UDP — it's its own protocol at the IP layer).

Tunnel Mode vs Transport Mode

OpenVPN

OpenVPN is a TLS-based VPN that runs in userspace (not kernel). It's been the de facto standard for remote access VPNs for over a decade — mature, well-understood, and widely deployed.

WireGuard

WireGuard is a modern VPN protocol designed to be simpler, faster, and more secure than IPsec and OpenVPN. It's built into the Linux kernel since 5.6 (2020) and is the foundation for Tailscale, Mullvad, and many other modern VPN products.

Design Philosophy

Cryptographic Primitives

Cryptokey Routing

This is WireGuard's core innovation. The public key → allowed IPs mapping IS the routing table. There's no separate routing configuration — the tunnel configuration IS the routing.

Peer's Public Key aB3d...xY9z= → AllowedIPs 10.0.0.2/32, 192.168.1.0/24

This mapping says: packets destined for 10.0.0.2 or 192.168.1.0/24 should be encrypted with this peer's key. Packets received from this peer must have source IPs in these ranges.

Stateless and Roaming

WireGuard Configuration Example

# /etc/wireguard/wg0.conf

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

# Enable IP forwarding and NAT
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; \
         iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; \
           iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Laptop
PublicKey = LAPTOP_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32

[Peer]
# Phone
PublicKey = PHONE_PUBLIC_KEY
AllowedIPs = 10.0.0.3/32

# /etc/wireguard/wg0.conf

[Interface]
Address = 10.0.0.2/24
PrivateKey = LAPTOP_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
# Server
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.5:51820
AllowedIPs = 0.0.0.0/0
# ↑ Route ALL traffic through VPN
# Use 10.0.0.0/24 for split tunnel

PersistentKeepalive = 25
# ↑ Send keepalive every 25s
# Needed when client is behind NAT
# Keeps the NAT mapping alive

    # Generate key pair

    $ wg genkey | tee privatekey | wg pubkey > publickey


    # Bring up the interface

    $ wg-quick up wg0


    # Check status

    $ wg show

    interface: wg0

      public key: aB3d...xY9z=

      private key: (hidden)

      listening port: 51820


    peer: Kf5x...bN2w=

      endpoint: 198.51.100.42:38291

      allowed ips: 10.0.0.2/32

      latest handshake: 42 seconds ago

      transfer: 1.48 MiB received, 3.21 MiB sent
  

IPsec vs OpenVPN vs WireGuard