Chapter 3: Technical Analysis of Modern VPN
Architectures
3.1 Theoretical Foundations of Virtual Private
Networking
Before analyzing specific protocols, it is essential to establish the fundamental mechanisms
that govern VPN performance and security at a theoretical level.
3.1.1 The Mechanics of Tunneling and Encapsulation
The Encapsulation Process: Detailed breakdown of how an original IP packet
(Payload) is wrapped inside a carrier protocol header.
o Overhead Analysis: Theoretical calculation of the "Goodput" vs.
"Throughput." How headers (IP + UDP + VPN Header + Encryption Tag)
reduce the Maximum Transmission Unit (MTU) availability.
o Fragmentation Risks: The impact of exceeding the Path MTU (PMTU),
leading to IP fragmentation, which drastically increases latency and CPU load.
Layer 2 (TAP) vs. Layer 3 (TUN) Tunneling:
o TUN (Network Layer): Routing IP packets only. More efficient, lower
overhead. Used by WireGuard and standard OpenVPN.
o TAP (Data Link Layer): Emulating an Ethernet device to bridge networks.
Allows non-IP traffic (IPX, NETBEUI) but introduces significant "chatter"
(broadcast overhead).
Shutterstock
3.1.2 The "TCP-Over-TCP" Meltdown Phenomenon
Theoretical Problem: Why tunneling TCP traffic (e.g., HTTPs, SSH) inside a TCP-
based VPN tunnel is mathematically flawed.
The Feedback Loop: How packet loss on the outer tunnel causes the inner TCP
session to retransmit, creating a resonance effect that collapses throughput and spikes
latency.
Practical Conclusion: The imperative preference for UDP as the carrier protocol in
modern VPN design.
3.2 Operating System Integration and Processing Modes
This section analyzes where the code runs, which is the single biggest factor in VPN
throughput performance.
3.2.1 User-Space vs. Kernel-Space Processing
The Context Switch Bottleneck:
o User-Space (e.g., Traditional OpenVPN): Traffic must move from the
Network Card (NIC) → Kernel → User Space (for encryption) → Kernel →
NIC. This "context switching" consumes massive CPU cycles.
o Kernel-Space (e.g., WireGuard, IPsec): Traffic stays within the kernel.
Encryption happens "close to the metal."
Performance Implication: Theoretical throughput limits based on CPU clock cycles
and memory copy operations.
3.2.2 The Role of Hardware Acceleration (AES-NI vs. SIMD)
AES-NI: How IPsec and OpenVPN leverage specific CPU instructions (Intel AES-
NI) to offload encryption tasks.
SIMD/Vectorization: How WireGuard’s ChaCha20 cipher utilizes NEON (ARM) or
AVX-512 (Intel) instructions to achieve high speeds without dedicated hardware
support, crucial for mobile/IoT devices.
3.3 Protocol-Specific Technical Analysis
A rigorous breakdown of the three "Modern" giants, analyzing their architectural decisions.
3.3.1 OpenVPN: The Flexible Legacy
Architecture: The modular design using the OpenSSL library for cryptography.
Control vs. Data Channels: Separation of the TLS handshake (Control) from the
actual packet encryption (Data).
Modern Evolution (OpenVPN DCO): Crucial for a modern report. Analysis of
Data Channel Offload (DCO), a recent module that moves OpenVPN's data plane
into the Linux kernel to compete with WireGuard speeds.
3.3.2 WireGuard: The Cryptokey Routing Paradigm
Stateless Design: Unlike other protocols, WireGuard does not maintain complex
connection states. It responds only to valid packets. This creates "stealth" (no response
to unauthenticated scans).
Cryptokey Routing Table: The binding of Public Keys directly to internal IP
addresses within the interface configuration.
The "Opinionated" Crypto Suite:
o ChaCha20-Poly1305: Authenticated Encryption with Associated Data
(AEAD).
o Curve25519: ECDH for Key Exchange.
o BLAKE2s: Hashing.
o SipHash24: Hashtable keys.
Perfect Forward Secrecy (PFS): Implementation via ephemeral keys re-negotiated
every few minutes transparently.
3.3.3 IKEv2/IPsec: The Enterprise Standard
Phase 1 vs. Phase 2:
o Phase 1 (IKE_SA): Establishing the secure channel.
o Phase 2 (CHILD_SA): Negotiating the traffic selectors.
ESP (Encapsulating Security Payload): The actual transport mechanism for
encrypted data.
MOBIKE (RFC 4555): The practical capability allowing the VPN to survive a
change in the client's IP address (e.g., switching from Wi-Fi to LTE) without dropping
the connection.
3.4 Cryptographic Handshake Performance
An analysis of the "Time to First Byte" (Connection Establishment).
3.4.1 The Cost of Negotiation
OpenVPN (TLS Handshake): The multi-round-trip (RTT) requirement (Client
Hello, Server Hello, Cert Exchange, Key Exchange). High latency on unstable links.
IKEv2: Faster negotiation but still requires multiple message exchanges.
3.4.2 The Noise Protocol Framework (WireGuard)
1-RTT Handshake: How WireGuard completes the handshake and sends data in a
single round trip.
Zero-Round-Trip (0-RTT) theory: Potential future capabilities and replay attack
risks.
3.5 Network Traversal and Persistence (Practical
Implementation)
How these theoretical protocols survive in the "dirty" environment of the real internet.
3.5.1 NAT Traversal (NAT-T)
The Problem: How IPsec (ESP) breaks standard Network Address Translation (NAT)
because it lacks port numbers.
The Solution: Encapsulating ESP inside UDP packets (usually Port 4500) to survive
NAT routers.
Keepalives: The necessity of sending "dummy" packets to keep the NAT mapping
table open in the router.
3.5.2 Firewall Evasion and Deep Packet Inspection (DPI)
Traffic Fingerprinting: How WireGuard is easily blocked because its packet headers
are distinct.
Obfuscation Techniques:
o OpenVPN with XOR patch or Stunnel: Wrapping VPN traffic in SSL/TLS to
look like HTTPS traffic.
o TCP Fallback: The practical advantage of OpenVPN utilizing Port 443
(HTTPS) to bypass restrictive corporate firewalls.
3.5.3 MTU Tuning and MSS Clamping
The "Silent Killer" of Performance: Technical explanation of how Maximum
Segment Size (MSS) clamping is used to force TCP sessions to lower their payload
size, preventing fragmentation inside the tunnel.
Why this structure works for your report:
1. It flows logically: Theory → Hardware → Software → Real World.
2. It is thorough: It covers the "Why" (math/physics), not just the "What."
3. It is modern: By including OpenVPN DCO and MOBIKE, you show you are up-to-
date with 2024/2025 standards.
4. It sets up Chapter 4: When you show the results in Chapter 4 (e.g., "WireGuard was
faster"), you can refer back here: "This is due to the kernel-space processing discussed
in Section 3.2.1." This links your report together beautifully.