Virtual Private Network (VPN)

What is a VPN?

A virtual private network builds an encrypted tunnel across untrusted networks so remote parties communicate as if locally connected. Two deployment shapes dominate infrastructure work. Site-to-site VPNs connect networks to networks — your data center to a VPC via IPsec (AWS Site-to-Site VPN gives you a redundant pair of tunnels, ~1.25 Gbps each, in minutes — the fast, cheap counterpart to Direct Connect). Remote-access VPNs connect individual users to a network, historically the corporate perimeter’s front door.

The protocol landscape, briefly

IPsec rules site-to-site (hardware support everywhere, BGP-friendly). WireGuard rewrote expectations for the rest — a deliberately tiny cryptographic design, kernel-fast, with connection setup and roaming behavior that makes OpenVPN feel baroque; it now underpins most modern mesh/overlay products (Tailscale et al.). TLS-based VPNs persist mainly where traversing hostile middleboxes on 443 matters.

The strategic decline of remote-access VPN

The corporate VPN’s security model — authenticate once, receive broad network reachability — is exactly the flat-network assumption zero trust rejects: one phished credential yields lateral movement across everything routable. The replacement pattern (identity-aware, per-application access) is eating remote-access VPN steadily. Site-to-site is different: networks genuinely need network-level links, and there VPN remains unambiguous best practice — encrypted, cheap, and the standard backup path under Direct Connect.

What people get wrong

• Full-tunnel-everything remote access, hairpinning all user traffic through HQ for latency nobody enjoys and inspection nobody reads.
• Treating VPN presence as authorization — the tunnel authenticates the connection, not what it may touch.
• Forgetting overlapping CIDRs — site-to-site between networks that both picked 10.0.0.0/16 means NAT contortions forever.

Primary source: WireGuard — protocol whitepaper