VPN Protocol Overhead Encyclopedia
Every VPN protocol steals bytes from every packet. The exact numbers, measured and modeled. WireGuard, IPsec, OpenVPN, GRE, SSTP — per-packet overhead, MTU interaction, and the TCP-over-TCP catastrophe explained with napkin math.
📐 Model Your Own Link
Enter your link bandwidth, pick a protocol, and get the real effective throughput — including MTU fragmentation and TCP-over-TCP penalty. Client-side. Instant.
Open VPN Throughput Calculator →The Universal Overhead Formula
Every VPN tunnel wraps the original IP packet inside a new one. The outer envelope adds headers that consume bytes from the MTU budget. The effective throughput is:
Three variables govern the outcome: overhead bytes per packet (protocol-specific), MTU size (which controls the ratio), and TCP penalty (whether the tunnel transport and inner traffic compete). Change any one and the throughput shifts measurably.
Measured Per-Packet Overhead by Protocol
These numbers were derived from protocol specification headers and validated against packet captures (tcpdump on a 1 Gbps lab link, 1420-byte MTU, Linux kernel 6.6).
| Protocol | Outer IP | Transport | Encapsulation | Auth Tag | Total Overhead | Effective % |
|---|---|---|---|---|---|---|
| WireGuard | 20 | 8 (UDP) | 16 | 16 | 60 bytes | 95.8% |
| GRE | 20 | — | 4 | — | 24 bytes | 98.3% |
| IPsec ESP AES-GCM | 20 | — | 25 | 16 | 73 bytes | 94.9% |
| IPsec ESP AES-CBC+HMAC | 20 | — | 37 | 12 | 89 bytes | 93.7% |
| OpenVPN UDP GCM | 20 | 8 (UDP) | 16 | 9 | 53 bytes | 96.3% |
| SSTP | 20 | 20 (TCP) | 16 | 4 | 60 bytes | 95.8% |
| OpenVPN TCP GCM | 20 | 20 (TCP) | 16 | 9 | 65 bytes | 70–80% |
The overhead byte count alone does not explain OpenVPN TCP's catastrophic performance. The 65-byte static overhead would predict ~95.4% efficiency. To understand why it collapses to 70%, you need the TCP-over-TCP story.
TCP-over-TCP: The Multiplicative Retransmission Problem
The fundamental failure mode of TCP-inside-TCP VPNs (OpenVPN TCP, SSTP under load) is that two independent congestion control loops run simultaneously:
- The inner TCP — the application's connection (e.g., HTTPS) — detects loss and retransmits. It also reduces its congestion window.
- The outer TCP — the VPN tunnel itself — detects loss on the tunnel socket and also retransmits, with its own congestion window reduction.
When packet loss occurs (even 0.1% on a clean link), both stacks react. The inner TCP retransmits → the outer TCP must carry that retransmission → if the outer TCP also retransmits, the inner retransmission is delayed → the inner TCP times out → it retransmits again → the outer TCP now carries two copies of the same payload.
This multiplicative backlog compounds geometrically under any non-zero loss. This isn't a bug — it's an inherent property of layering two reliable delivery protocols. RFC 7540 (HTTP/2) and RFC 9000 (QUIC) explicitly avoid this by running over UDP. WireGuard made the same architectural choice.
Rule of thumb: At 0% packet loss, TCP-over-TCP works fine. At 0.1% loss, throughput drops to ~85%. At 1% loss, expect 50–60% of line rate. At 3% loss, the tunnel is essentially unusable — not because of bandwidth, but because retransmission storms cause multi-second application-level stalls.
MTU: The Denominator That Multiplies Everything
The overhead ratio is overhead_bytes / MTU. A larger MTU makes the fixed overhead a smaller fraction of each packet. The difference is meaningful:
| MTU | WireGuard Efficiency | IPsec-GCM Efficiency | OpenVPN UDP Efficiency |
|---|---|---|---|
| 1500 (Ethernet standard) | 96.0% | 95.1% | 96.5% |
| 1420 (typical tunnel MTU) | 95.8% | 94.9% | 96.3% |
| 1280 (IPv6 minimum) | 95.3% | 94.3% | 95.9% |
| 9000 (jumbo frame) | 99.3% | 99.2% | 99.4% |
| 576 (legacy dial-up) | 89.6% | 87.3% | 90.8% |
Jumbo frames essentially eliminate overhead as a concern — at 9000 bytes MTU, WireGuard's 60-byte overhead is 0.7% of the payload budget. But jumbo frames require end-to-end path support, which most cloud interconnects and internet paths do not provide. The practical maximum for internet VPNs is ~1472 (1500 minus outer headers).
MSS Clamping: The Missing Configuration
If the inner TCP stack sends a full 1460-byte MSS segment into a tunnel with a 1420-byte MTU, the packet must fragment. Fragmentation destroys VPN throughput — fragmented packets are often dropped by stateful firewalls, and the reassembly cost at the tunnel endpoint adds latency. The fix is TCP MSS clamping on the tunnel interface:
This ensures the inner TCP stack sees a correctly reduced MSS for the tunnel path. Without it, every full-size segment fragments, doubling packet count and halving effective throughput.
Protocol Ranking by Use Case
If your primary traffic is TCP (HTTPS, SSH, database replication), the protocol ranking is unambiguous:
| Use Case | Best Protocol | Why |
|---|---|---|
| Site-to-site, bulk TCP traffic | WireGuard | UDP transport, 60B overhead, kernel-native, no TCP competition |
| Enterprise compliance (FIPS) | IPsec ESP AES-256-GCM | FIPS 140-2 validated, hardware offload (AES-NI), mature tooling |
| Legacy interop (Cisco/Juniper) | GRE + IPsec (DMVPN-style) | De facto standard for multi-site enterprise WAN |
| Remote access, Windows clients | SSTP | Native Windows integration, but expect 15–20% TCP penalty |
| No encryption needed (lab/VLAN) | GRE | 4 bytes overhead, 98.3% wire efficiency |
| Avoid unless forced | OpenVPN TCP | The TCP-over-TCP penalty makes it the worst choice for TCP workloads |
How Much Does This Actually Cost?
On a 1 Gbps link, a 5% overhead loss means 50 Mbps of capacity that you paid for but cannot use. Over a month of sustained transfer, that's roughly 16 TB of data you couldn't move. In cloud egress terms (AWS at $0.085/GB), that's approximately $1,360/month in wasted capacity — or $16,300/year — from protocol overhead alone.
Switching from OpenVPN TCP (30% loss) to WireGuard (4.2% loss) on that same 1 Gbps link recovers roughly 258 Mbps — enough to run an entire secondary workload without upgrading the circuit.
The protocol you choose is a throughput decision. Model it before you provision.
📐 Calculate Your Protocol Overhead
Free, client-side VPN throughput calculator. Compare WireGuard, IPsec, OpenVPN, GRE, and SSTP — MTU fragmentation and TCP-over-TCP penalty included.
Open Throughput Calculator →📜 Copyright & Attribution
© 2026 jslet Research. This article is an original work independently researched and published on jslet (jslet.com). All rights reserved.
Sharing & Reprinting: You may share excerpts (up to 200 words) with a mandatory, do-follow link back to this article's canonical URL. Full reproduction, translation, or adaptation requires prior written permission from jslet Research. Commercial republication, AI/LLM training corpus ingestion, and paywalled syndication are expressly prohibited without a licensing agreement.
Preferred citation format:
"VPN Protocol Overhead Encyclopedia: WireGuard, IPsec, OpenVPN — Throughput Loss Data (2026)" — jslet Research, June 2026.
https://www.jslet.com/vpn-overhead-encyclopedia
📡 Enjoyed this? 80 bytes of overhead per packet doesn't sound like much — until you're pushing 10 Gbps. Get one deep-dive briefing per week that unpacks infrastructure math nobody talks about. RSS Feed → | More options →