VPN

A VPN (Virtual Private Network) creates an encrypted tunnel between two endpoints over an untrusted network (usually the Internet). Two main use cases:

1. Remote access — laptop joins a corporate / VPC network from a coffee shop.
2. Site-to-site — connect two networks (office ↔ AWS VPC, or VPC ↔ VPC) so they look like one.

How a VPN actually works

[ Laptop 192.168.1.50 ]
       ↓ encapsulate + encrypt
[ Encrypted UDP/TCP packet over Internet ]
       ↓
[ VPN concentrator (server) on 203.0.113.10 ]
       ↓ decrypt + decapsulate
[ Forwarded onto private network 10.0.0.0/16 as if local ]

The VPN client adds a virtual network interface (e.g. tun0). Apps see it as a regular network interface and can reach 10.0.0.x directly.

Three protocols you’ll meet

Vendor wrappers (Tailscale, NetBird, Twingate) sit on WireGuard and add identity, NAT traversal, and key distribution. Cloud equivalents (AWS Client VPN) wrap OpenVPN.

IPsec basics

Two phases:

1. IKE (Internet Key Exchange) over UDP 500/4500 — peers authenticate (PSK or certificate) and negotiate encryption parameters.
2. ESP (Encapsulating Security Payload) — actual encrypted tunnel. Two modes:
   • Tunnel mode (typical): the entire original IP packet is encrypted and re-wrapped in a new IP packet. Used for VPN gateways.
   • Transport mode: only the payload is encrypted; original headers stay. Used for end-to-end IPsec on the same network.

IPsec works but is famously fiddly to configure — phase 1 / phase 2 mismatches, NAT-T issues, MTU problems.

WireGuard — the modern default

Why people picked it up so fast:

• Tiny config — [Peer] blocks with public keys.
• No certificate machinery; just public/private keypairs.
• Stateless on the wire (looks like noise UDP packets to outside observers).
• Roams across networks (your phone switches Wi-Fi → 4G → it stays connected).
• Kernel module since Linux 5.6 → fast.

Minimal config:

[Interface]
PrivateKey = <server private key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client public key>
AllowedIPs = 10.8.0.2/32

AllowedIPs doubles as a routing table on the server side and an ACL (“only accept packets from this peer with these source IPs”).

Split tunneling

Two modes for outbound traffic on the client:

Corporate VPNs default to full tunnel. Cloud VPNs (Tailscale, AWS Client VPN) default to split — only 10.0.0.0/16 (your VPC) goes through, youtube.com goes direct.

Site-to-site VPN

Connects two networks at the gateway level. No client software on the workloads.

Office network 192.168.0.0/24
       ↓
[ Office router with IPsec ] ─── encrypted tunnel ───  [ AWS Virtual Private Gateway ]
                                                                ↓
                                                         VPC 10.0.0.0/16

Now an EC2 instance at 10.0.5.5 and a desktop at 192.168.0.42 can talk directly. AWS Site-to-Site VPN gives you a managed IPsec endpoint.

For higher throughput / lower latency than the public Internet, replace the VPN with AWS Direct Connect (a dedicated physical line). VPNs cap around 1.25 Gbps; Direct Connect goes to 100 Gbps.

VPN vs Zero Trust (BeyondCorp model)

VPN = “if you’re inside the network, you’re trusted.” Once an attacker pivots inside, lateral movement is easy.

Zero Trust = every request authenticated + authorized regardless of network location. No “inside.” Tools: Tailscale ACLs, Cloudflare Access, IAP, BeyondCorp.

In practice, modern teams use a Zero-Trust mesh (Tailscale, Twingate) and treat the network itself as untrusted. The VPN tunnel is still there, but it’s not the security boundary.

VPN + DNS pitfalls

When you connect to a VPN, the client usually rewrites your DNS resolver to a private one (so internal names like db.internal.example.com resolve). Common bugs:

• DNS leak — some apps cache an old resolver and bypass the VPN.
• Split-DNS misconfiguration — internal names resolve, public names don’t (or vice versa).
• macOS sometimes ignores VPN-pushed DNS (scutil --dns to debug).

VPN performance

Encryption costs CPU. Typical hits:

• Throughput: 70–95% of raw network bandwidth on modern hardware (AES-NI in CPU helps).
• Latency: +1–10ms (extra hop and crypto).
• MTU: tunnel headers reduce effective MTU by 50–80 bytes. If the path doesn’t honor PMTU discovery, large packets get dropped → “small requests work, big ones hang.” Set MSS clamping on the VPN.

Common interview confusions

• “VPN encrypts your traffic from end to end.” — only between you and the VPN concentrator. From there to the destination, the packet is decrypted (unless it’s HTTPS already).
• “VPN means I’m secure on public Wi-Fi.” — partially true: it stops the café Wi-Fi from snooping plaintext traffic. But HTTPS already does that for most browsing.
• “VPN and proxy are the same.” — VPN works at L3 (every packet from the client tunneled); proxy works at L7 (per-application, app must be configured).

Interview angle

• “What problem does a VPN solve?” — encrypted tunnel between two endpoints over an untrusted network; lets you reach private networks remotely or join two networks together.
• “IPsec vs WireGuard vs OpenVPN — when each?” — IPsec for site-to-site and AWS managed VPN; WireGuard for modern remote access (small, fast, simple); OpenVPN for legacy or where TLS-port 443 disguise is needed.
• “Split tunnel vs full tunnel?” — full = all traffic via VPN (privacy/policy, slower); split = only VPN-destined traffic via VPN (fast, exposes the rest of your traffic to your local network).
• “Why are companies replacing VPNs with Zero Trust?” — VPN trusts the network; once inside, lateral movement is easy. Zero Trust authenticates per request regardless of location.
• “Why is your VPN slow despite a fast Internet connection?” — encryption CPU cost, extra hop, lower effective MTU. Check MSS clamping if large transfers hang.