How VPNs Work: Tunneling Protocols and Encryption

A Virtual Private Network (VPN) creates an encrypted tunnel between your device and a remote server, routing your internet traffic through that tunnel so it appears to originate from the server rather than from your actual location. Unlike Tor, which prioritizes anonymity through multi-hop onion routing, a VPN prioritizes privacy and security through a single encrypted hop to a trusted provider. The tradeoff is straightforward: you are shifting trust from your local network (your ISP, the coffee shop Wi-Fi) to the VPN operator.

From a networking perspective, VPNs are fascinating because they operate at the intersection of cryptography, routing, and tunneling. A VPN client creates a virtual network interface on your device, assigns it an IP address from the VPN provider's address space, and manipulates the routing table so that traffic destined for the internet flows through this virtual interface rather than directly out your physical one. The encrypted packets travel across the public internet as ordinary UDP or TCP traffic — routed by BGP through the usual chain of autonomous systems — but their contents are opaque to every network in between.

This article breaks down the three dominant VPN protocols in use today — WireGuard, IPsec, and OpenVPN — examining the cryptographic primitives, key exchange mechanisms, and packet formats that make each one work. We will also cover split tunneling, DNS leak prevention, and how VPN traffic interacts with BGP routing at the infrastructure level.

The Tunnel Concept: Encapsulation and Virtual Interfaces

Every VPN, regardless of protocol, relies on the same fundamental networking trick: encapsulation. The original IP packet that your application generates is wrapped inside a new IP packet, with the VPN server's address as the destination. The inner packet is encrypted; the outer packet is what actually traverses the internet.

When you connect to a VPN, the client software creates a virtual network interface — typically named something like tun0 (a layer-3 tunnel interface) or tap0 (a layer-2 tunnel interface that can carry Ethernet frames). The client then modifies your system's routing table to direct traffic through this interface. When a packet arrives at the virtual interface, the VPN client encrypts it, wraps it in a new UDP or TCP packet addressed to the VPN server, and sends it out the physical interface. At the server end, the reverse happens: the outer packet is stripped, the inner packet is decrypted, and the original packet is forwarded to the internet.

The result is that your traffic appears to originate from the VPN server's IP address. Anyone observing your local network sees only encrypted packets flowing to a single destination. The websites and services you connect to see the VPN server's IP address, not yours. The AS path for your traffic now includes the VPN provider's network as the origin, and a looking glass query on your real IP address would show your ISP's prefix, while the destination server would see the VPN provider's prefix.

WireGuard: Modern Minimalism

WireGuard is the newest of the three protocols and, by a wide margin, the simplest. Created by Jason Donenfeld and merged into the Linux kernel in March 2020 (kernel 5.6), WireGuard consists of roughly 4,000 lines of code — compared to over 600,000 for OpenVPN and its OpenSSL dependency. This extreme simplicity is not a limitation but a deliberate design philosophy: a smaller codebase is easier to audit, harder to get wrong, and faster to execute.

WireGuard operates exclusively over UDP and presents itself as a network interface (like wg0). It is a layer-3 tunnel only — it carries IP packets, not Ethernet frames. There is no concept of a "connection" or "session" in the traditional sense. WireGuard is stateless from the protocol's perspective: it simply encrypts packets and sends them. If no packets are flowing, no bandwidth is consumed.

The Noise Protocol Framework

WireGuard's handshake is built on the Noise Protocol Framework, specifically the Noise_IKpsk2 pattern. Noise is a framework for building cryptographic handshake protocols, designed by Trevor Perrin (one of the Signal Protocol co-creators). Instead of using the complex negotiation machinery of TLS, Noise defines a fixed sequence of Diffie-Hellman operations that produce shared keys.

The IKpsk2 pattern means:

• I — the initiator's static public key is sent immediately (not encrypted initially, but later authenticated)
• K — the responder's static public key is known to the initiator beforehand (pre-configured)
• psk2 — a pre-shared symmetric key is mixed in at the second step (providing post-quantum resistance and an additional authentication factor)

The handshake consists of exactly two messages — one from initiator to responder, one back. Each message contains an ephemeral Diffie-Hellman public key and encrypted payloads. The cryptographic operations performed during the handshake are:

1. Message 1 (Initiator to Responder): The initiator generates an ephemeral Curve25519 keypair. It performs three DH operations: (a) ephemeral-initiator with static-responder, (b) static-initiator with static-responder, and (c) ephemeral-initiator with static-responder again — each result being mixed into the handshake hash via HKDF. The initiator's static public key is encrypted with ChaCha20-Poly1305 using a key derived from (a), providing identity hiding. A MAC and timestamp are included to prevent replay.
2. Message 2 (Responder to Initiator): The responder generates its own ephemeral keypair. It performs DH operations: (d) ephemeral-responder with ephemeral-initiator, (e) ephemeral-responder with static-initiator. The pre-shared key is mixed in at this point. Both sides now have identical chaining key material from which two symmetric transport keys are derived — one for each direction.

The entire handshake fits in two UDP packets totaling about 304 bytes. After the handshake, data is encrypted with ChaCha20-Poly1305 using the derived transport keys. Keys are rotated every 2 minutes or every 2^64 - 1 messages (whichever comes first), triggering a new handshake transparently.

Cryptokey Routing

WireGuard introduces a concept called cryptokey routing, which elegantly unifies the IP routing table with the cryptographic peer table. Each WireGuard peer is configured with:

• A public key (Curve25519, 32 bytes)
• An endpoint (IP address and UDP port, optional — can be learned from incoming packets)
• A list of allowed IPs — the IP prefixes that this peer is permitted to send from and receive to

When WireGuard receives a plaintext packet on the wg0 interface for transmission, it looks up the destination IP in the allowed-IPs table to find the corresponding peer and its public key. It encrypts the packet using that peer's session key and sends it to the peer's endpoint. When an encrypted packet arrives from a peer, WireGuard decrypts it and checks that the inner source IP is within that peer's allowed-IPs range — if not, the packet is silently dropped.

This is routing and access control in one operation. There is no separate firewall rule or IP-to-key mapping needed. A typical client configuration looks like this:

[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
Address = 10.200.100.8/24
DNS = 10.200.100.1

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.com:51820

The AllowedIPs = 0.0.0.0/0, ::/0 line means all IPv4 and IPv6 traffic should route through this peer — a full tunnel. Changing this to AllowedIPs = 10.0.0.0/8, 192.168.1.0/24 would create a split tunnel, routing only traffic to those specific subnets through the VPN.

WireGuard's Packet Format

WireGuard defines only four message types, each with a fixed format:

• Type 1: Handshake Initiation (148 bytes) — ephemeral public key, encrypted static key, encrypted timestamp, MAC1, MAC2
• Type 2: Handshake Response (92 bytes) — ephemeral public key, encrypted nothing (just proves key knowledge), MAC1, MAC2
• Type 3: Cookie Reply (64 bytes) — used for DoS mitigation under load
• Type 4: Transport Data (variable) — 4-byte header, 8-byte counter (used as nonce), encrypted payload, 16-byte Poly1305 tag

The MAC1 field in handshake messages is a keyed MAC over the message using a key derived from the responder's public key. This allows the responder to quickly reject packets from parties that do not know its public key — without performing any expensive cryptographic operations. The MAC2 field is only set when the responder is under load and has issued a cookie challenge, providing a rate-limiting mechanism similar to TCP SYN cookies.

IPsec: The Enterprise Standard

IPsec (Internet Protocol Security) is a suite of protocols that has been part of the internet standards since the mid-1990s. Unlike WireGuard and OpenVPN, which are monolithic protocols, IPsec is a framework consisting of multiple sub-protocols that handle key exchange, encryption, and authentication separately. It operates at the network layer (layer 3) and can be implemented directly in the operating system kernel or in dedicated hardware.

IPsec has two major components: a key exchange protocol (IKE) and data protection protocols (ESP and AH).

IKE: Internet Key Exchange

Before any traffic can be encrypted, the two IPsec peers must agree on cryptographic parameters and exchange keys. This is handled by IKE (Internet Key Exchange), currently at version 2 (IKEv2, RFC 7296). IKEv2 replaced the much more complex IKEv1, which had two separate phases and multiple exchange modes.

IKEv2 establishes two types of Security Associations (SAs):

• IKE SA — a secure channel between the two peers for exchanging control messages (protected by the IKE session keys)
• Child SA (IPsec SA) — the actual data encryption parameters used by ESP to protect user traffic. Multiple Child SAs can exist under a single IKE SA.

The IKEv2 handshake typically requires two round trips (four messages):

1. IKE_SA_INIT exchange (2 messages): The initiator and responder exchange Diffie-Hellman public values, nonces, and propose cryptographic algorithms (cipher suites). After this exchange, both sides compute a shared secret and derive the IKE SA keys. All subsequent IKE messages are encrypted.
2. IKE_AUTH exchange (2 messages): Both sides authenticate using certificates, pre-shared keys, or EAP (Extensible Authentication Protocol). They also negotiate the first Child SA (IPsec SA) — specifying the traffic selectors (which IP ranges/ports to protect), the ESP algorithms, and the SA lifetime. The traffic selectors function similarly to WireGuard's allowed-IPs, defining which traffic should be encapsulated.

IKEv2 supports MOBIKE (RFC 4555), which allows a VPN connection to seamlessly survive changes in IP address or network interface — essential for mobile devices that switch between Wi-Fi and cellular. It also supports NAT traversal natively by encapsulating ESP packets in UDP port 4500 when a NAT device is detected between peers.

ESP: Encapsulating Security Payload

ESP (Encapsulating Security Payload, RFC 4303) is the protocol that actually encrypts and authenticates user traffic. It is identified by IP protocol number 50. ESP provides both confidentiality (encryption) and integrity (authentication). Each ESP packet contains:

• SPI (Security Parameters Index) — a 32-bit identifier that tells the receiver which SA (and therefore which keys and algorithms) to use for decryption
• Sequence Number — a 32-bit counter for anti-replay protection (extended to 64 bits in modern implementations)
• Encrypted Payload — the original packet (or just the payload, depending on mode), encrypted with the negotiated cipher
• Padding — to align the ciphertext to the block size
• ICV (Integrity Check Value) — a MAC over the entire ESP packet for authentication

Modern ESP implementations typically use AES-GCM (which provides both encryption and authentication in a single operation) or AES-CBC with HMAC-SHA-256 for integrity. The most current standard, RFC 8221, recommends AES-GCM with 128- or 256-bit keys and ChaCha20-Poly1305 as an alternative.

AH: Authentication Header

AH (Authentication Header, RFC 4302) provides data integrity and authentication but not encryption. It is IP protocol number 51. AH computes an ICV (integrity check value) over the entire IP packet — including most of the outer IP header fields. This means AH can detect modifications to the IP header itself (such as changes to the source or destination address), which ESP cannot do because it only authenticates the payload.

In practice, AH is rarely used today. ESP with authenticated encryption (AES-GCM) provides both confidentiality and integrity, making AH redundant for most use cases. AH is also incompatible with NAT (because NAT modifies the IP header, which breaks AH's integrity check), which is a severe limitation given the prevalence of NAT in modern networks.

Tunnel Mode vs. Transport Mode

IPsec can operate in two modes, which determine what gets encrypted and how the packets are structured:

Tunnel mode encapsulates the entire original IP packet — header and all — inside a new IP packet with ESP. The outer IP header has the tunnel endpoints (the VPN gateways) as source and destination, while the inner IP header (now encrypted) has the original source and destination. This is the mode used for VPNs, site-to-site connections, and any scenario where you want to hide the original IP addresses from intermediate networks.

Transport mode encrypts only the payload of the original IP packet, leaving the original IP header intact. The ESP header is inserted between the IP header and the transport-layer (TCP/UDP) header. This mode is used for end-to-end encryption between two hosts that communicate directly — no tunnel, no encapsulation. Transport mode is used by protocols like L2TP/IPsec, where L2TP provides the tunneling and IPsec provides the encryption.

In tunnel mode, the overhead is larger because there are two IP headers: the original (encrypted) and the new outer header. For IPv4, this adds 20 bytes; for IPv6, 40 bytes. Combined with the ESP header (8 bytes), IV (typically 8-16 bytes), padding, and ICV (12-16 bytes), the total overhead is typically 50-70 bytes per packet — significant for small packets like VoIP.

OpenVPN: The Established Workhorse

OpenVPN is an open-source VPN protocol that has been in widespread use since the early 2000s. Unlike WireGuard (which implements its own cryptographic handshake) and IPsec (which uses IKE), OpenVPN leverages the TLS protocol for its key exchange and control channel. This was a pragmatic choice: by reusing TLS, OpenVPN inherits a well-audited, widely-deployed cryptographic library (OpenSSL or mbed TLS) and the entire X.509 certificate infrastructure.

OpenVPN separates its operation into two distinct channels:

The Control Channel

The control channel handles authentication, key exchange, and tunnel parameter negotiation. It is a full TLS session running over a reliable transport layer that OpenVPN implements on top of UDP (or TCP, if configured). The control channel uses:

• TLS 1.2 or 1.3 for the handshake, supporting standard cipher suites (e.g., TLS_AES_256_GCM_SHA384 for TLS 1.3)
• X.509 certificates for server (and optionally client) authentication, with a configurable CA chain
• Optional tls-auth or tls-crypt — a pre-shared HMAC key that authenticates and (with tls-crypt) encrypts control channel packets, providing a first line of defense against unauthenticated probing and DPI (Deep Packet Inspection)

Once the TLS handshake completes, OpenVPN uses the secure control channel to exchange data channel keys. The control channel remains active for the duration of the connection, handling periodic key renegotiation (typically every 3600 seconds or 2^32 bytes of data).

The Data Channel

The data channel carries the actual tunneled traffic. It uses symmetric keys derived during the control channel exchange, but it does not use TLS for data encryption — instead, it uses a custom format for efficiency. The data channel supports:

• AES-256-GCM (recommended, provides authenticated encryption)
• AES-256-CBC + HMAC-SHA-256 (older default, encrypt-then-MAC)
• ChaCha20-Poly1305 (supported in newer versions)

Each data channel packet consists of: an opcode (1 byte), a peer-id (3 bytes, for multiplexing), a packet-id (4 or 8 bytes, for replay protection), and the encrypted payload. When using AES-GCM, the packet-id doubles as the IV/nonce.

OpenVPN supports both TUN (layer 3, IP packets) and TAP (layer 2, Ethernet frames) modes. TAP mode is useful for bridging scenarios where you need to carry non-IP protocols or broadcast traffic, but TUN mode is more common for standard VPN use.

OpenVPN over TCP vs. UDP

OpenVPN can run over either TCP or UDP. UDP is preferred because it avoids the TCP-over-TCP problem: when you encapsulate TCP traffic inside a TCP tunnel, both the inner and outer TCP stacks react to packet loss independently, potentially causing exponential retransmission and catastrophic throughput collapse. When the outer TCP detects a loss, it retransmits — but the inner TCP also detects the delay and reduces its window. When the retransmitted outer packet arrives, the inner TCP may have already retransmitted, creating duplicate data and wasted bandwidth.

However, TCP mode is sometimes necessary for traversing restrictive firewalls that block UDP traffic. OpenVPN can run on TCP port 443, making it indistinguishable from HTTPS traffic to simple port-based firewalls (though deep packet inspection can still identify it by its handshake patterns).

Protocol Comparison

The three protocols represent different points in the design space, each with distinct strengths:

WireGuard excels in simplicity, performance, and battery life. Its fixed cryptographic suite (no cipher negotiation) eliminates an entire class of downgrade attacks. The kernel implementation achieves 1+ Gbps throughput easily on modern hardware. Its weakness is limited configurability — no TCP fallback, no username/password authentication, no built-in IP address assignment (requiring external tools like wg-quick).

IPsec (IKEv2) excels in enterprise environments, mobile device support (built into iOS, Android, Windows, and macOS natively), and standards compliance. MOBIKE support makes it the best choice for mobile VPNs that need to survive network transitions. Its weakness is complexity — the standards span dozens of RFCs, implementations vary, and debugging interoperability issues between vendors can be challenging.

OpenVPN excels in flexibility, firewall traversal, and ease of deployment with PKI. Its client runs on virtually every platform, and the TLS-based architecture is familiar to network administrators. Its weakness is performance — as a userspace application, every packet crosses the kernel-userspace boundary twice, limiting throughput compared to kernel-based WireGuard and IPsec. OpenVPN 3.x and DCO (Data Channel Offload) kernel modules partially address this.

Split Tunneling

Split tunneling is a VPN configuration where only some traffic flows through the VPN tunnel while the rest uses the default internet connection directly. This is a routing decision, not a cryptographic one — the VPN client manipulates the system's IP routing table to achieve it.

In a full tunnel configuration, the VPN client sets the default route (0.0.0.0/0) to point through the VPN interface. All traffic — regardless of destination — goes through the tunnel, gets encrypted, and exits at the VPN server. This provides maximum privacy but adds latency to all connections and routes everything through the VPN provider's network.

In a split tunnel configuration, only specific destination prefixes are routed through the VPN. For example, a corporate VPN might route 10.0.0.0/8 (the internal network) through the tunnel while allowing direct internet access for everything else. On Linux, this looks like:

# Full tunnel: default route through VPN
ip route add default via 10.8.0.1 dev tun0

# Split tunnel: only corporate traffic through VPN
ip route add 10.0.0.0/8 via 10.8.0.1 dev tun0
ip route add 172.16.0.0/12 via 10.8.0.1 dev tun0
# Default route remains via the physical interface

Split tunneling also has security implications. When enabled, traffic to non-tunneled destinations flows directly from the client, potentially leaking information about the user's real IP address. Conversely, forcing a full tunnel through a corporate VPN means all personal browsing passes through the employer's network — a privacy concern for the user. The decision is fundamentally about trust boundaries: what traffic do you trust the VPN to handle, and what traffic do you trust your local network to handle?

In WireGuard, split tunneling is controlled by the AllowedIPs parameter on the peer configuration. In IPsec, it is controlled by traffic selectors negotiated during the IKE_AUTH exchange. In OpenVPN, the server pushes routes to the client via the control channel, and the client can be configured to accept or ignore these pushed routes.

DNS Leak Prevention

One of the most common VPN privacy failures is the DNS leak — where your DNS queries bypass the VPN tunnel and go directly to your ISP's DNS resolver, revealing the domains you visit even though the actual traffic is encrypted through the VPN.

DNS leaks happen because configuring VPN routing and configuring DNS resolution are separate operations. Even if all your IP traffic routes through the VPN, your operating system may still use the DNS resolver it learned from DHCP on the local network — which is typically your ISP's resolver. The DNS query itself (A example.com?) is a UDP packet to the resolver's IP address (e.g., your ISP's 192.168.1.1), and if that address is not routed through the VPN, the query bypasses the tunnel entirely.

Proper DNS leak prevention requires multiple mechanisms working together:

• Push VPN DNS — The VPN server provides its own DNS resolver address, and the client configures it as the primary (or only) DNS server. WireGuard does this with the DNS directive; OpenVPN pushes it via push "dhcp-option DNS 10.8.0.1".
• Route DNS traffic through the tunnel — Ensure that DNS queries to the VPN's resolver actually go through the tunnel. In a full-tunnel configuration, this happens automatically. In a split-tunnel, the VPN DNS server's IP must be in the routed prefixes.
• Block non-tunnel DNS — On Windows, the operating system may send DNS queries to all configured interfaces simultaneously (the "smart multi-homed name resolution" feature). Properly configured VPN clients set the tunnel interface's metric lower than the physical interface, or use Windows Firewall rules to block outbound port 53 on non-tunnel interfaces.
• Use DNS over HTTPS or DNS over TLS — Encrypting DNS queries provides an additional layer of protection, though it only helps if the DoH/DoT resolver is the VPN provider's server (or routed through the tunnel).

IPv6 DNS leaks are particularly insidious. Many VPNs only tunnel IPv4 traffic, but if your system has IPv6 connectivity, DNS queries may go out over IPv6 directly — bypassing the IPv4-only tunnel entirely. Modern VPN clients mitigate this by either tunneling IPv6 traffic as well or disabling IPv6 on non-tunnel interfaces while the VPN is active.

VPNs and BGP: Infrastructure-Level Routing

VPN traffic does not exist in a vacuum — it traverses the same BGP-routed internet infrastructure as all other traffic. Understanding how VPN providers interact with BGP provides insight into both performance and privacy.

Large VPN providers operate their own autonomous systems and announce their IP prefixes via BGP. For example, a VPN provider with servers in 50 countries might have IP allocations from each region's RIR (ARIN, RIPE, APNIC, etc.) and peer with local ISPs and internet exchange points. When you connect to a VPN server in Amsterdam, your encrypted traffic travels from your ISP to the VPN provider's AS, following the BGP-selected best path. The decrypted traffic then exits the VPN server and enters the internet from the VPN provider's network, following a potentially very different AS path to reach the destination.

This has implications for performance. In a full-tunnel VPN, a connection from New York to a server in New Jersey might actually travel: New York -> VPN server in Frankfurt -> New Jersey — crossing the Atlantic twice. The added latency can be substantial. This is why VPN providers with many server locations, good peering relationships, and strategically placed servers (often at major IXPs) provide better performance.

From a BGP visibility perspective, VPN traffic is invisible. A looking glass or BGP monitoring system sees the outer packets — traffic between your IP address and the VPN server. The actual destinations you are communicating with are hidden inside the encrypted tunnel. At the VPN server end, the decrypted traffic appears to originate from the VPN server's IP, blending in with traffic from all other users of that server. You can use god.ad to look up a VPN server's IP address and see which AS operates it, what prefix it belongs to, and what the AS path looks like.

MPLS VPNs and BGP/MPLS L3VPN

It is worth briefly distinguishing consumer VPNs from MPLS VPNs used by enterprises and service providers. A BGP/MPLS L3VPN (RFC 4364) is fundamentally different from a WireGuard or OpenVPN tunnel. In an MPLS VPN, the service provider uses BGP to exchange VPN routing information between Provider Edge (PE) routers, with each customer's routes kept in a separate VRF (Virtual Routing and Forwarding) instance. Traffic is forwarded through the provider's core network using MPLS labels, not encryption — the isolation comes from label separation, not cryptography.

MPLS VPNs use special BGP address families — VPNv4 and VPNv6 — which prepend a Route Distinguisher (RD) to each prefix to make customer routes unique even if they overlap (e.g., two customers both using 10.0.0.0/8 internally). Route Targets (RT), carried as BGP extended communities, control which VRFs import and export routes. This is a completely different use of the word "VPN" — there is no encryption, no tunnel endpoint on the customer's device, and the "virtual private" part comes from logical separation within the provider's infrastructure.

Advanced Topics

Perfect Forward Secrecy

All three modern VPN protocols provide Perfect Forward Secrecy (PFS). PFS means that compromise of long-term keys does not compromise past session keys. This is achieved by using ephemeral Diffie-Hellman key exchange for every session (or rekey).

In WireGuard, every handshake uses fresh ephemeral Curve25519 keys, and the static keys are only used for authentication — the transport keys are derived from the ephemeral exchange. Even if an attacker steals a peer's static private key, they cannot decrypt previously recorded traffic because the ephemeral keys were discarded after use.

In IPsec, PFS is achieved when the IKE_AUTH or CREATE_CHILD_SA exchange includes a new Diffie-Hellman key exchange (the KE payload). Without this, Child SAs derive their keys from the IKE SA's key material, meaning compromise of the IKE SA keys would compromise all Child SA keys. Most modern configurations enable PFS for Child SAs.

In OpenVPN, PFS comes from the underlying TLS handshake. TLS 1.3 mandates ephemeral key exchange (DHE or ECDHE) — static RSA key exchange, which lacked PFS, was removed entirely. When OpenVPN renegotiates keys (every reneg-sec interval), a new TLS handshake occurs with fresh ephemeral keys.

MTU and Fragmentation

VPN encapsulation adds overhead to every packet — the outer IP header, UDP header, VPN protocol header, and the encryption overhead (IV, authentication tag, padding). This reduces the effective Maximum Transmission Unit (MTU) available to applications. If an application sends a packet that, after encapsulation, exceeds the physical link's MTU (typically 1500 bytes for Ethernet), the packet must be fragmented or rejected.

WireGuard typically sets the tunnel MTU to 1420 bytes (for IPv4 outer) or 1400 bytes (for IPv6 outer), accounting for the 60-80 bytes of encapsulation overhead. IPsec overhead varies by mode and cipher but is typically 50-70 bytes. OpenVPN overhead is around 30-70 bytes depending on the cipher and whether tls-auth/tls-crypt is enabled.

Fragmentation is problematic for performance. If the outer packet exceeds the path MTU, it may be fragmented at the IP layer, which doubles packet processing overhead at the receiver. Worse, many firewalls and middleboxes drop IP fragments. The solution is Path MTU Discovery — the tunnel sets the Don't Fragment (DF) bit on outer packets, and intermediate routers send ICMP "Fragmentation Needed" messages when the packet is too large. The VPN endpoint then adjusts the tunnel MTU accordingly. However, some networks block ICMP, creating "black holes" where large packets silently disappear. This is a common cause of mysterious VPN connectivity issues where small requests work but large downloads stall.

VPN Obfuscation and Censorship Circumvention

In countries with strict internet censorship, VPN protocols are actively detected and blocked. DPI (Deep Packet Inspection) systems can identify VPN traffic by protocol signatures — WireGuard's initial handshake packet is a fixed 148 bytes, IPsec uses distinctive protocol numbers (ESP=50, AH=51), and OpenVPN has recognizable opcode patterns in its first packet.

Several techniques are used to evade detection:

• Obfsproxy / Pluggable Transports — originally developed for Tor, these tools wrap VPN traffic in protocols that look like random data or legitimate HTTP/HTTPS traffic
• Stunnel / SSL wrapping — encapsulating OpenVPN inside a standard TLS connection on port 443, making it look like ordinary HTTPS
• Shadowsocks / V2Ray — proxy protocols designed specifically for censorship circumvention, which can tunnel VPN traffic
• Domain fronting — using a CDN's shared IP infrastructure to disguise the true destination of traffic (largely blocked by major CDNs now)

The cat-and-mouse game between censors and circumvention tools is an active area of development. Modern DPI systems can detect VPN traffic through statistical analysis of packet sizes and timing, even when the content is encrypted and the protocol signatures are obfuscated.

Multi-Hop and Nested VPNs

Some VPN providers offer multi-hop (or "double VPN") connections, where traffic passes through two or more VPN servers in sequence. Your traffic is encrypted twice: the first server decrypts one layer and re-encrypts to the second server, which decrypts the second layer and forwards to the destination. This is conceptually similar to Tor's onion routing but with only two hops and with the VPN provider controlling all nodes (unlike Tor, where relays are operated by independent volunteers).

Multi-hop VPNs provide an additional layer of protection: even if one server is compromised or legally compelled to log traffic, it only sees encrypted traffic going to another server — not the client's identity and destination simultaneously. However, the latency cost is significant, and the security improvement is only meaningful if the two servers are in different jurisdictions and operated by different entities (or at least different infrastructure).

Security Considerations and Threat Models

A VPN is not a magic privacy shield. Understanding what a VPN does and does not protect against is essential for making informed security decisions:

What a VPN protects against:

• Your ISP seeing which websites you visit (they see only encrypted traffic to the VPN server)
• Public Wi-Fi eavesdropping (the coffee shop cannot see your traffic)
• IP-based geolocation and tracking (websites see the VPN server's IP, not yours)
• Some forms of censorship (the censor cannot see the destination of your traffic)

What a VPN does NOT protect against:

• The VPN provider itself logging your traffic (you are shifting trust, not eliminating it)
• Browser fingerprinting, cookies, and JavaScript-based tracking
• Compromised endpoints (malware on your device can see unencrypted traffic before it enters the tunnel)
• Traffic analysis by a global passive adversary (who can correlate entry and exit traffic by timing and volume, even without decrypting it)
• DNS leaks if the VPN client is misconfigured
• BGP hijacks that reroute the outer VPN packets themselves — though the encryption prevents reading the content, an attacker could disrupt the connection or perform traffic analysis

For true anonymity (hiding your identity from the destination and from network observers), Tor is the appropriate tool. For encrypting traffic from an untrusted local network and shifting your apparent location, a VPN is the right choice. For protecting site-to-site traffic between offices, IPsec tunnel mode or WireGuard are the standard solutions.

The Cryptographic Stack: Summary

Each protocol makes different choices for its cryptographic primitives, but they all follow the same pattern: asymmetric key exchange to establish a shared secret, symmetric encryption for data, and authentication to ensure integrity.

WireGuard's lack of cipher agility is both its greatest strength and its limitation. By fixing the cryptographic suite, WireGuard eliminates downgrade attacks and reduces implementation complexity. But if a vulnerability is found in Curve25519 or ChaCha20, every WireGuard deployment in the world must be updated simultaneously — there is no way to negotiate a fallback. WireGuard addresses this by versioning: a future WireGuard version would use a different protocol identifier, and peers would negotiate the version at the protocol level rather than negotiating individual algorithms.

Looking Up VPN Infrastructure

You can use god.ad to investigate VPN providers' network infrastructure. Look up a VPN server's IP address to see which autonomous system operates it, what prefix the IP belongs to, the AS path to reach it, and whether the prefix has valid RPKI ROA entries. This can reveal interesting details: some VPN providers operate their own ASNs, while others rent IP space from hosting providers. Some providers use anycast for their DNS resolution but unicast for VPN endpoints. The subnet size can hint at the scale of their server deployments.

Try looking up a VPN server IP in the BGP Looking Glass to see how it fits into the internet's routing infrastructure — you might be surprised at what the BGP data reveals about your VPN provider's network.