Virtual Private Networks (VPN)

How VPNs Work

A VPN creates an encrypted tunnel between your device and a remote server. All your internet traffic routes through this tunnel, hiding your IP address and protecting data from eavesdroppers on public networks. Unlike a direct connection where your ISP sees both origin and destination, a VPN routes all traffic through the VPN server, making the server appear as the traffic origin to external sites.

The technical process: your device establishes a TLS or IPsec session with the VPN server, encapsulating all IP packets inside encrypted containers. The VPN server decapsulates these packets and forwards them to the actual internet destinations. Return traffic follows the reverse path. This happens at either the network layer (IPsec) or application layer (OpenVPN SSL/TLS), depending on the protocol.

VPN Protocols

WireGuard

WireGuard is a modern VPN protocol designed for simplicity, speed, and cryptographic excellence. Unlike legacy VPN protocols with hundreds of thousands of lines of code, WireGuard aims for approximately 4,000 lines— making it auditable and formally verifiable.

Cryptographic Foundation

WireGuard uses the Noise Protocol Framework (Noise_IK pattern) for its key exchange. The handshake employs Curve25519 for elliptic curve Diffie-Hellman key exchange, which generates shared secrets without transmitting private keys. The protocol provides:

• Perfect Forward Secrecy (PFS): Each session uses ephemeral key pairs; compromise of long-term keys does not reveal past sessions
• Replay Protection: Counter-based packet IDs prevent replay attacks
• Key Compromise Impersonation Resistance: The handshake design prevents an attacker who has compromised a static private key from impersonating the peer
• Zero Round-Trip Time (0-RTT) Resumption: Previously connected peers can resume without full handshake

Data Protection

WireGuard uses ChaCha20-Poly1305 for authenticated encryption with associated data (AEAD). ChaCha20 is a stream cipher that encrypts data in 64-byte blocks, combined with Poly1305 for message authentication. This combination provides both confidentiality and integrity—any tampering is detected and rejected.

BLAKE2s (256-bit output) handles keyed hashing for packet authenticity, while HKDF (HMAC-based Key Derivation Function) derives subkeys from the master secret for encryption and authentication.

Protocol Operation

WireGuard operates exclusively over UDP (typically port 51820). Each packet contains only the sender's index, encrypted payload, and authentication tag. No packet headers or nonces are transmitted in the clear. The keepalive interval (default: 25 seconds) maintains NAT and firewall mappings.

Formal Verification

WireGuard was formally verified using the Tamarin prover, a cryptographic protocol verification tool. The proof demonstrates that WireGuard's handshake achieves strong security guarantees under the computational model. This verification was published in 2017 and is one of the first VPN protocols to receive such rigorous analysis.

# WireGuard interface configuration (Linux)
[Interface]
PrivateKey = <client-private-key>
Address = 10.0.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

OpenVPN

OpenVPN is an open-source VPN protocol that uses SSL/TLS for key exchange and can run over either UDP (preferred) or TCP. It was created by James Yonan and released in 2001. The protocol has evolved through versions 2.x which added server-side multi-client support.

SSL/TLS Handshake

OpenVPN leverages the mature OpenSSL library for its cryptographic operations. The TLS handshake establishes a secure channel using X.509 certificates for authentication. Both client and server must present valid certificates signed by a shared CA (Certificate Authority).

The handshake supports multiple cipher suites including AES-256-GCM for authenticated encryption, RSA or ECDSA for authentication, and various Diffie-Hellman groups (ECDH or FFDH) for key exchange.

Tunnel Modes

Route-based (TUN): Creates a virtual TUN interface that intercepts IP packets. Used for most VPN scenarios, routing traffic based on destination IP address.

Bridging mode (TAP): Creates a virtual TAP interface that intercepts Ethernet frames. Required for non-IP protocols like IPv6 or when layer 2 bridging is needed. TAP mode is less efficient but necessary for certain enterprise applications.

Authentication Methods

• Static key: Pre-shared secret for small deployments (deprecated for security)
• Certificate-based: X.509 certificates with CA validation
• Username/Password: Combined with certificate or alone via auth-user-pass-verify plugin
• Multi-factor: Combining certificates with PAM or RADIUS authentication

Network Traversal

OpenVPN excels at traversing firewalls and NAT. In TCP mode, it can tunnel through HTTP proxies using the CONNECT method. It can also use port sharing with an HTTPS server. The protocol uses a single UDP or TCP port, making firewall rule configuration straightforward.

# OpenVPN server configuration
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem

server 10.8.0.0 255.255.255.0

keepalive 10 120
cipher AES-256-GCM
auth SHA256

# Push routes to clients
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"

IPsec

IPsec (Internet Protocol Security) is a protocol suite that operates at the network layer (Layer 3), securing IP packets through authentication and encryption. Unlike application-layer VPNs, IPsec is transparent to applications and user traffic, making it ideal for enterprise deployments.

Architecture Components

Authentication Header (AH): Provides data integrity and authentication for IP packet headers and payload using HMAC with MD5 or SHA. AH does not encrypt the payload. It protects against replay attacks using sequence numbers. AH is rarely used today due to compatibility issues with NAT (it authenticates IP headers that change during NAT translation).

Encapsulating Security Payload (ESP): Provides confidentiality through encryption and optional authentication. ESP in tunnel mode encrypts the entire original IP packet including headers. This is the most commonly used IPsec protocol.

Security Associations (SA)

An SA is a simplex (unidirectional) agreement between communicating parties defining security parameters. Parameters include: SPI (Security Parameter Index), destination IP, protocol (AH or ESP), encryption algorithm, authentication algorithm, keys, and lifetime. SAs are established via IKE (Internet Key Exchange).

IKEv2 (RFC 4306)

IKEv2 is the modern key exchange protocol. A simplified exchange (IKE_SA_INIT + IKE_AUTH) establishes the IKE SA. For child SAs (IPsec SAs), it uses CREATE_CHILD_SA. IKEv2 includes:

• MOBIKE: Mobility and Multi-homing Protocol for roaming between networks
• Redirect Mechanism: Load balancing across multiple gateways
• Session Resumption: Ticket-based session resumption for fast reconnection

Transport vs Tunnel Mode

Transport mode: Original IP header preserved. ESP/AH encrypts only the payload. Used for host-to-host IPsec. The IP header remains visible, which can leak destination information.

Tunnel mode: Entire original IP packet (header + payload) is encrypted and wrapped in a new IP header. Used for gateway-to-gateway or host-to-gateway VPNs. Provides complete privacy of the original packet headers.

NAT-Traversal (NAT-T)

IPsec packets use protocol 50 (ESP) or protocol 51 (AH), which many NAT devices cannot traverse. NAT-T encapsulates ESP packets inside UDP port 4500 datagrams, allowing IPsec to work through NAT devices. Detection of NAT occurs during IKE negotiation, and both peers automatically switch to NAT-T if needed.

L2TP/IPsec

Layer 2 Tunneling Protocol (L2TP) provides the tunneling mechanism while IPsec provides encryption. This combination is specified in RFC 3193.

L2TP Operation

L2TP creates PPP (Point-to-Point Protocol) frames over UDP (port 1701) and encapsulates them. L2TP has two components:

• L2TP Access Concentrator (LAC): Initiates tunnel connection on behalf of client
• L2TP Network Server (LNS): Terminates tunnels and processes PPP frames

Double Encapsulation

L2TP/IPsec suffers from double encapsulation overhead: PPP frame is wrapped in L2TP, which is wrapped in UDP, which is wrapped in ESP encryption, which is wrapped in a new IP header. This adds 50-70 bytes per packet, contributing to slower performance compared to WireGuard or native IPsec.

The flow: Application data → PPP encapsulation → L2TP encapsulation → UDP encapsulation → IPsec encryption (ESP) → New IP header

PPTP

Point-to-Point Tunneling Protocol was developed by Microsoft, Ascend, and others in 1996. It was the first widely deployed VPN protocol, shipping with Windows NT 4.0 and later Windows 95 dial-up networking.

Protocol Architecture

PPTP uses a TCP connection (port 1723) for control messages (session establishment and termination) and GRE (Generic Routing Encapsulation, protocol 47) for data encapsulation. The PPP payload is encrypted using Microsoft Point-to-Point Encryption (MPPE).

Security Vulnerabilities

PPTP's security is fundamentally broken. MS-CHAPv2, the authentication protocol PPTP relies on, has known vulnerabilities:

• Dictionary attacks: MS-CHAPv2 is vulnerable to offline dictionary attacks on captured handshakes
• MPPE injection: Attackers can inject packets without knowing the key due to RC4 stream cipher weaknesses
• No key derivation: MPPE derives session keys from password hash alone, not a proper KDF

In 2012, Microsoft acknowledged PPTP should no longer be used, recommending IPsec or TLS-based VPNs instead.

Encryption Fundamentals

Modern VPN protocols rely on cryptographic primitives that provide confidentiality, integrity, and authentication. Understanding these primitives helps evaluate protocol security.

VPN Features

Kill Switch

A kill switch prevents all network traffic when the VPN connection drops, avoiding any traffic leaks to the ISP or local network. Implementation varies:

• Firewall-based: Rules block all non-VPN traffic when tunnel is down (NordVPN, ProtonVPN)
• Interface-based: Brings down the physical interface when VPN drops (WireGuard with iptables)
• Application-level: Individual apps configured to only use VPN interface

True kill switches handle multiple failure scenarios: VPN server disconnect, client crash, network transition (WiFi to cellular), and sleep/wake cycles.

Split Tunneling

Split tunneling routes some traffic through the VPN while allowing other traffic to use the regular internet connection. Three modes:

• Include routes: Only specified destination subnets go through VPN
• Exclude routes: All traffic goes through VPN except specified destinations (streaming services, gaming servers)
• Application-based: Specific applications use VPN while others use regular connection

Split tunneling reduces latency for local services and bandwidth load on VPN servers, but creates asymmetric routing that can cause issues with some services. Enterprise split tunneling typically includes corporate network routes.

Multi-Hop (VPN Chaining)

Multi-hop routes traffic through two or more VPN servers in different jurisdictions. This makes traffic analysis significantly more difficult since no single server sees both origin and destination. Implementation:

• Nested VPN: Client → VPN Server 1 → VPN Server 2 → Internet
• Tor integration: VPN → Tor or Tor → VPN for layered anonymity
• Onion routing: Some VPN providers offer multi-hop with automatic server rotation

Obfuscation (Stealth Modes)

Obfuscation disguises VPN traffic to look like regular HTTPS traffic, evading deep packet inspection (DPI) that identifies VPN protocols. Methods include:

• SSL masking: Wrapping VPN traffic in SSL/TLS to mimic HTTPS
• Protocol translation: Converting UDP VPN traffic to HTTP POST requests
• Shadowsocks integration: Using Shadowsocks protocol for VPN obfuscation
• Domain fronting: Routing through CDN fronting different domains

Business VPNs vs Consumer VPNs

Enterprise and consumer VPNs serve different purposes and have different security models.

Zero Trust Network Access (ZTNA)

Modern enterprises are moving away from castle-and-moat VPNs toward Zero Trust Network Access. ZTNA verifies every user and device before granting access to specific resources, regardless of network location. The principle: "never trust, always verify."

Limitations and Considerations

• Provider trust: The VPN provider sees all your traffic; choose providers with verified no-logs policies and audited infrastructure
• Performance: Encryption/decryption overhead, tunneling encapsulation, and server distance all add latency
• IPv6 leaks: Many VPNs only tunnel IPv4; IPv6 traffic may leak outside the tunnel
• DNS leaks: DNS queries may bypass the VPN tunnel if not properly configured
• WebRTC leaks: WebRTC can discover real IP addresses even when VPN is active
• Kill switch reliability: Not all implementations handle all failure scenarios

Protocol Comparison

Alternative Tunneling Methods

Beyond traditional VPN protocols, several alternative technologies provide privacy, anonymity, or traffic tunneling. These serve different threat models and use cases—each is covered in detail on its own dedicated page.

• Tor: Distributed anonymity network using layered encryption across three-relay circuits. High anonymity for both clients and hidden services. Read full Tor reference
• SOCKS Proxy: Session-layer protocol for relaying TCP/UDP through SOCKS4/4a/5 proxies. Read full SOCKS reference
• Shadowsocks: AEAD-encrypted proxy protocol for censorship circumvention. Read full Shadowsocks reference
• I2P: Garlic-routed anonymous network for internal eepsites and peer-to-peer communication. Read full I2P reference
• DNS Tunneling: Encapsulating data in DNS queries via iodine, dnscat2. Read full DNS tunneling reference
• ICMP Tunneling: ptunnel-ng tunnels TCP over ICMP echo packets. Read full ICMP tunneling reference
• HTTP CONNECT: TCP tunneling through HTTP proxies for HTTPS traffic. Read full HTTP CONNECT reference
• ProxyChains: LD_PRELOAD-based proxy chaining for UNIX applications. Read full ProxyChains reference

VPNs and Social Media Age Verification Bans

VPNs are the primary bypass mechanism for age-verification-based social media restrictions. When a user connects to a VPN server in a country without equivalent age mandates, the platform sees the VPN server's foreign IP address and applies the rules of that jurisdiction—bypassing the age gate entirely. This is the most widely documented circumvention method following the implementation of the UK Online Safety Act (July 2025) and Australia's Social Media Minimum Age Act (December 2025).

VPN downloads topped UK and Australian app store charts immediately following enforcement dates. eSafety Commissioner Julie Inman Grant claimed quality VPNs cost "thousands of dollars," despite market prices showing unlimited plans from A$20/month. VPN providers have refused to comply with data retention demands from both jurisdictions.

Platforms detect VPN bypass through IP blocklisting of known VPN server addresses, DPI of VPN protocol signatures, SNI analysis, and behavioral correlation. Bypass countermeasures include residential proxies (IP addresses from consumer ISPs in target countries), protocol obfuscation (making OpenVPN look like HTTPS), and TLS 1.3 with ECH encrypting the destination hostname.

The fundamental technical reality: banning VPN access to social media is equivalent to banning encrypted internet traffic, which is the entire modern web. Read the comprehensive reference: Social Media Age Bans and Bypass Methods