Ultimate System Design For Beginners: VPN Explained

Understanding how a Virtual Private Network (VPN) works is essential when designing secure distributed architectures. This chapter explores how VPNs encrypt traffic, alter visible IP addresses, address common security myths, and impact server-side sizing during system design.

1. Why Do We Need a VPN? (The Problem Statement)

When connecting to the internet—especially from open or untrusted public networks like cafes, airports, or railway stations—devices are exposed to security vulnerabilities.

• Data Exposure on Public Networks: Raw internet traffic passing through untrusted Wi-Fi can be intercepted, monitored, or logged by malicious actors.
• ISP Tracking: Internet Service Providers (ISPs) can track every domain, website, and endpoint a user visits.
• Geo-Restrictions and Censorship: Certain applications or services restrict access based on geographic IP locations.
• Need for Secure Remote Access: Organizations require secure channels for employees to connect to internal private networks from remote locations without exposing internal services to the public internet.

2. Core Mental Model: The Encrypted Tunnel Analogy

Think of standard internet browsing as mailing a postcard: anyone handling the mail along the postal route can read the message contents and see the sender and destination addresses.

A VPN acts like a locked steel briefcase placed inside a heavy courier box:

1. The user places their data packet inside an encrypted digital container (the VPN tunnel).
2. The courier (ISP) only sees the outermost address pointing to the VPN gateway, completely blind to the true final destination inside.
3. Upon reaching the VPN gateway, the outer layer is removed, the inner packet is decrypted, and it is forwarded to its final destination.

Device (Laptop)
   |
   | encrypts data and wraps in VPN packet
   v
VPN Client (Runs on Device)
   |
   | transmits over encrypted VPN Tunnel (ISP cannot read destination)
   v
VPN Gateway / Server
   |
   | decrypts packet and forwards to destination on Internet
   v
Final Web Destination

3. Standard Internet Connection vs. VPN Connection

To fully grasp the architectural transformation, let's contrast a direct connection against a VPN-routed connection.

4. Step-by-Step Data Flow Walkthrough

Understanding the exact journey of a packet helps clarify how a VPN client and server interact.

5. Common Myths vs. Industry Reality

There are several widespread misconceptions about what a VPN can and cannot do. System designers must understand these security boundaries to avoid false architectures.

Myth 1: "A VPN makes you completely unhackable."

• Reality: A VPN stops common network-level attacks on local or untrusted networks (such as packet sniffing, man-in-the-middle attacks, and simplistic DNS hijacks).
• Limitation: It does not protect against endpoint attacks, malware, phishing campaigns, vulnerable operating systems, compromised account credentials, or malicious websites.

Myth 2: "Government agencies and ISPs cannot snoop on you."

• Reality: Local network sniffers and ISPs cannot inspect the contents of a well-configured encryption tunnel.
• Limitation: VPN providers themselves can be subpoenaed, targeted with legal orders, or compromised. Furthermore, advanced adversaries can perform traffic timing correlation across multiple network vantage points to de-anonymize users. A VPN provides privacy and encryption, not absolute anonymity.

6. System Design Considerations and Trade-offs

When incorporating VPNs into large-scale system architecture, engineers must evaluate several crucial performance and routing factors:

A. Full-Tunnel vs. Split-Tunnel Strategy

• Full-Tunnel VPN: All client device traffic (internal corporate tools AND external personal browsing) is forced through the VPN tunnel.
  • Pros: Maximum enterprise security and centralized auditing.
  • Cons: High bandwidth consumption on corporate gateways and unnecessary latency for public web traffic.
• Split-Tunnel VPN: Only traffic destined for internal corporate subnets goes through the VPN, while general internet traffic bypasses the VPN directly.
  • Pros: Saves bandwidth and reduces gateway load.
  • Cons: Exposes non-VPN traffic to local network risks.

B. Hardware Sizing and CPU Intensity

• Encryption Overheads: Cryptographic operations (such as AES-GCM, ChaCha20, or TLS handshakes) are CPU-intensive.
• Node Scaling: When designing VPN gateways to handle thousands of concurrent remote workers, engineers must provision adequate CPU cores, allocate hardware accelerators (like AES-NI instruction sets), or deploy horizontally scalable clusters of VPN nodes behind load balancers.

7. Summary and Key Takeaways

• Encrypted Tunnelling: A VPN creates a secure, encrypted tunnel from a client device to a gateway, wrapping data packets to shield them from local network sniffers and ISPs.
• IP Masking: External websites see the IP address of the VPN server rather than the user's actual device IP address.
• ISP Blindness: While ISPs can see that data is moving to a VPN server, they cannot see the final destination or packet contents of a well-encrypted tunnel.
• Security Boundaries: VPNs protect against local network eavesdropping and man-in-the-middle attacks, but they do not prevent malware, phishing, endpoint compromises, or targeted legal tracking.
• Traffic Routing Strategies: System designers must choose between full-tunnel (all traffic routed) and split-tunnel (only internal traffic routed) based on bandwidth and security constraints.
• Resource Sizing: Encrypting and decrypting traffic at scale is highly CPU-intensive, requiring proper hardware sizing and node allocation during system design.