See how much of a circuit survives VPN encapsulation and whether your users fit. Per-packet overhead from the RFCs: WireGuard, IPsec, OpenVPN, SSTP.
At a 1,500-byte IPv4 link. Overhead is per-packet and includes the outer IP header, so goodput rises with a larger MTU.
| Protocol and cipher | Per packet | Goodput | Tunnel MTU | Effective |
|---|---|---|---|---|
| WireGuard VPN | 60 bytes | 96.00% | 1,440 bytes | 96.0 Mbps |
| OpenVPN (AEAD, AES-GCM) | 52 bytes | 96.53% | 1,448 bytes | 96.5 Mbps |
| IPsec ESP (AES-GCM) | 57 bytes | 96.20% | 1,443 bytes | 96.2 Mbps |
| IPsec ESP (AES-CBC + HMAC-SHA-256) | 77 bytes | 94.87% | 1,423 bytes | 94.9 Mbps |
| OpenVPN (CBC + HMAC-SHA-256) | 100 bytes | 93.33% | 1,400 bytes | 93.3 Mbps |
| L2TP/IPsec (AES-CBC + HMAC-SHA-256) | 99 bytes | 93.40% | 1,401 bytes | 93.4 Mbps |
| SSTP (PPP over TLS, AES-GCM) | 75 bytes | 95.00% | 1,425 bytes | 95.0 Mbps |
Figures are the per-packet encapsulation cost at a full MTU, taken from each protocol's specification. Real throughput is also bounded by the gateway's cipher performance and packet rate, by path loss and by how much of your traffic reaches full-size packets.
You might also find these calculators useful
Effective MTU and TCP MSS from real protocol overhead
How much internet speed you need, and how long a transfer takes
Find the bandwidth-delay product and the TCP window a link needs
Calculate network latency: propagation, transmission, and processing delays
A VPN does not slow a link down by a vague percentage. It adds a fixed number of bytes to every packet, and those bytes come out of the same circuit your traffic does. On a 1500-byte Ethernet link, WireGuard over IPv4 spends 60 of every 1500 bytes on encapsulation, so 96 % of the circuit carries tunnelled traffic and 4 % carries headers. Enter your circuit rate and the number of people on it, and this calculator gives you the delivered rate, the shortfall, and the circuit you would need to cover the demand you actually have.
Every tunnelling protocol wraps your packet in headers of its own: an outer IP header to route the tunnel, a transport header where the protocol uses one, the protocol's own header, and whatever the cipher adds — an initialisation vector, block padding, and an authentication tag. Add those up and you have the per-packet cost. Subtract it from the link MTU and what is left is the tunnelled packet that fits in one frame. The fraction of the circuit doing useful work — goodput — is that payload divided by the MTU. The cipher matters more than the protocol name: OpenVPN with AES-GCM costs 52 bytes per packet, and the same OpenVPN with AES-CBC and HMAC-SHA-256 costs 100.
VPN goodput and delivered bandwidth
Work backwards from the demand you expect: the calculator reports the circuit rate needed to deliver a given amount of user traffic through a given tunnel, which is always more than the traffic itself.
Compare every protocol and cipher at your own MTU side by side, in bytes and in delivered Mbps, rather than trusting a ranking that assumes someone else's link.
When a 500 Mbps site reports 466 Mbps through the tunnel and nothing is broken, this shows the missing 34 Mbps as the header cost it is.
Raise the MTU and watch goodput move. On a data-centre link where 9000 bytes is available, the same tunnel wastes a fraction of what it wastes at 1500.
Concurrency, not headcount, is what a VPN concentrator sees. Enter the concurrent figure and the per-user rate to get the number of sessions the circuit actually supports.
The same tunnel that costs 4 % of a 1500-byte link costs 0.7 % of a 9000-byte jumbo-frame link, because the header count is fixed and the payload is not. Any single percentage quoted for a protocol is quietly assuming an MTU.
AEAD ciphers carry one authentication tag and no separate HMAC or on-wire IV. A CBC cipher with a separate HMAC carries an IV, worst-case block padding and a full digest. Between those two, OpenVPN's per-packet cost nearly doubles.
An IPv6 outer header is 40 bytes where IPv4 is 20. That is why WireGuard leaves 1440 bytes on an IPv4 link and 1420 on IPv6 — and why wg-quick defaults to 1420, the figure that is safe on both.
Knowing you get 466 Mbps out of a 500 Mbps circuit does not tell you whether 100 people at 4.8 Mbps each fit. They do not — and they would have fitted the bare circuit. That gap is the whole reason to compute this before buying bandwidth.
A VPN gateway is usually limited by packets per second, not megabits. Small packets multiply the per-packet cost and the per-packet work at the same time, so a link full of short packets can saturate a gateway well under its rated throughput.
At a 1500-byte MTU over IPv4, the per-packet encapsulation cost is 52 bytes for OpenVPN with AES-GCM, 57 for IPsec ESP with AES-GCM, 60 for WireGuard, 75 for SSTP, 77 for IPsec ESP with AES-CBC and HMAC-SHA-256, 99 for L2TP/IPsec, and 100 for OpenVPN with AES-CBC and HMAC-SHA-256. As a share of the circuit that is 3.5 % at the cheapest and 6.7 % at the most expensive. Those figures assume full-size packets; a stream of small packets pays the same header cost on far less payload, so the effective loss is higher.
OpenVPN configured with an AEAD cipher, at 52 bytes per packet over IPv4 — eight bytes less than WireGuard's 60. WireGuard is usually the faster protocol in practice because it runs in the kernel and its cryptography is cheap, but that is a CPU and latency advantage, not a byte-count one. Overhead and speed are different questions, and only overhead is a fixed, calculable number.
Because IKEv2 is not a data-plane protocol. RFC 7296 describes it as "a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations" — it negotiates keys, then ESP carries the traffic. So the per-packet cost of an IKEv2/IPsec tunnel is simply ESP's cost, and choosing IKEv2 tells you nothing about bandwidth. What does change the number is the ESP cipher suite, which is why this calculator lists IPsec by cipher rather than by key-exchange method.
Yes, 8 bytes per packet on IPsec. Native ESP has no transport header at all — RFC 4303 specifies that the header preceding ESP carries protocol number 50, so ESP sits directly inside IP. When a tunnel has to cross NAT, RFC 3948 encapsulates that ESP packet inside a standard UDP header so the translator has ports to work with. That is the extra 8 bytes. WireGuard, OpenVPN and SSTP already run over UDP or TCP, so NAT traversal costs them nothing further.
Two reasons, and only one of them is bandwidth. A TCP header is 20 bytes against UDP's 8, so every packet carries 12 bytes more. The larger problem is behavioural: running TCP inside a TCP tunnel means two independent retransmission and congestion-control loops stacked on each other, so a single lost packet on the outer connection stalls the inner one while both back off. Use TCP transport only where UDP is blocked.
Divide the delivered rate by the per-user rate, not the circuit rate by the per-user rate. A 500 Mbps circuit running OpenVPN with AES-CBC delivers about 466 Mbps, so at 5 Mbps per user it supports 93 concurrent sessions rather than 100. The distinction matters most near the boundary: a demand that clears the circuit but not the tunnel is a shortfall caused entirely by encapsulation, and a larger MTU or a lighter cipher will fix it without more bandwidth.
They reduce it as a share of the circuit, because the header cost is per packet and a 9000-byte frame carries six times the payload of a 1500-byte one. WireGuard's 60 bytes is 4 % of a 1500-byte link and 0.67 % of a 9000-byte one. The catch is that every device along the path has to agree on the larger MTU, which is realistic inside a data centre and generally not across the public internet.