VPN Throughput Calculator
Work out the realistic throughput of a VPN tunnel for your link, protocol, cipher and CPU. Names the bottleneck (link, encryption, or TCP receive window) so you know what to change to get more speed.
Explain like I'm 5 (what even is this calculator?)
Tell it how fast your line is, which VPN you use, which cipher, and how strong the device doing the encryption is. It tells you how fast the tunnel will actually go, what percentage of your line that is, and which part of the chain is holding you back. If the answer is "encryption-bound", you need a faster device or a lighter cipher. If it's "link-bound", your VPN is doing as well as it can.
Estimate VPN throughput
Fill in the form and press the button to see realistic VPN throughput.
Realistic throughput:
Percent of link:
Bottleneck:
Round-trip latency through the tunnel:
Prove it
The maths, end to end, so you can audit it.
Per-packet protocol overheads are taken from the published header sizes for each protocol (WireGuard 60 bytes, IPsec/IKEv2 ~73 bytes, OpenVPN-UDP ~78 bytes, OpenVPN-TCP ~94 bytes, L2TP/IPsec ~85 bytes). CPU/cipher figures are realistic sustained single-tunnel benchmarks across low, mid and high-end hardware. The TCP receive-window cap uses a 128 KB window, which is a fair real-world figure for window-scaled TCP through an OpenVPN-TCP tunnel.
Save this calculator: press Ctrl + D to bookmark it in your browser.
Why VPN throughput is rarely line speed
People buy a gigabit line, switch on a VPN, run a speed test, and see 200 Mbps. That is not the VPN failing. It is the VPN exposing the cost of encrypting every packet, wrapping it in a tunnel header, and shipping it through a server somewhere else. The line is one ceiling. The CPU on the device doing the encryption is another. The protocol's framing overhead is a third. On TCP-mode tunnels across long distances, the inner TCP receive window is a fourth. The actual throughput is whichever ceiling is lowest, and naming that ceiling is the whole job of this calculator.
WireGuard, OpenVPN, IPsec and L2TP, in plain terms
WireGuard is the modern default. It runs in-kernel on Linux and modern home routers, the protocol header is small, and it uses ChaCha20-Poly1305 by default, which is fast on every CPU. On the same hardware, WireGuard is consistently the fastest of the bunch. OpenVPN is older, written for portability, runs in userspace, and is largely single-threaded. UDP mode is the faster of the two; TCP mode is the slow one and the only one that hits a receive-window ceiling on long links. IPsec/IKEv2 is the corporate workhorse, in-kernel on most platforms, fast, but heavier per-packet than WireGuard. L2TP/IPsec wraps L2TP inside IPsec, which adds a touch of overhead on top of IPsec on its own; it is mostly there for legacy compatibility and you should not pick it for new deployments.
Why CPU class matters more than people think
Cipher throughput on a low-end router without AES-NI hardware acceleration sits around 80-100 Mbps for AES, regardless of whether the line is 100 Mbps or 1 Gbps. Slot the same VPN onto a desktop CPU with AES-NI and you can punch through 2-3 Gbps of AES-256-GCM. The cipher you should pick depends on the CPU. Without AES-NI, ChaCha20-Poly1305 wins by a large margin, which is exactly why WireGuard chose it as the default. With AES-NI, AES-128-GCM and AES-256-GCM are the fastest options. Picking the wrong cipher for your hardware is the single most common reason a VPN underperforms.
What "RTT-bound" means and why only OpenVPN-TCP gets it
Inside an OpenVPN-TCP tunnel there is a single outer TCP stream carrying all your inner traffic. That outer stream is subject to the textbook TCP throughput cap: window size in bytes, multiplied by eight, divided by round-trip time in seconds. With a 128 KB window and a 145ms transcontinental round-trip, that cap lands around 7 Mbps. Your line could be a hundred times faster and the tunnel still cannot exceed it. UDP-based protocols (WireGuard, OpenVPN-UDP, IPsec/IKEv2) carry independent inner flows, so the cap does not apply. This is the standing argument against TCP-mode VPNs over long links and why WireGuard is the right choice for any cross-continent connection.
Common mistakes when sizing a VPN
- Picking AES-256 on a cheap router. ChaCha20 will be two to three times faster on the same hardware.
- Using OpenVPN-TCP because the docs default to it. Switch to UDP wherever the network will let you. TCP-in-TCP is a known anti-pattern.
- Blaming the VPN provider for slow speeds on a slow CPU. If your home router is the endpoint and it has no AES-NI, the provider cannot fix that.
- Forgetting MTU. A 1500-byte MTU loses 4-6% to framing, which is fine. Lower MTUs lose more, which adds up at gigabit speeds.
- Comparing speed-test results without isolating variables. Same CPU, same protocol, same cipher, same server distance, otherwise you are measuring noise.
How to act on the result
If the calculator says you are link-bound, the VPN is doing as well as physics allows on that line. If you want more, you need a faster line. If it says encryption-bound, your CPU is the limit: switch cipher (ChaCha20 if no AES-NI, AES-GCM if you have it), or move the VPN endpoint to a faster device. If it says RTT-bound, you are on OpenVPN-TCP across a long link and the receive-window cap is killing you: switch to a UDP-based protocol. WireGuard is usually the right answer.
Related calculators
VPN throughput is one bottleneck. These cover the line behind it.
Frequently asked questions
Why is my VPN slower than my internet connection?
Three things cap a VPN: the underlying link, the CPU available to encrypt and decrypt every packet, and, for OpenVPN over TCP, the receive window relative to the round-trip time. On a fast line with a slow CPU, encryption is the bottleneck. On a slow line with a fast CPU, the line is the bottleneck. On OpenVPN-TCP across an ocean, the TCP receive window inside the tunnel is the bottleneck.
Should I use WireGuard or OpenVPN?
WireGuard, almost always, for raw throughput. It runs in-kernel, has a small protocol overhead per packet, and uses ChaCha20-Poly1305 by default which is fast on every CPU. OpenVPN runs in userspace, is largely single-threaded, and pays a real penalty against WireGuard on the same hardware.
Why does ChaCha20 sometimes beat AES?
AES is fastest on CPUs that have AES-NI hardware acceleration. ChaCha20-Poly1305 is software-only, but well enough tuned that it beats AES on devices without AES-NI: cheap routers, old phones, low-power embedded gear. WireGuard picked ChaCha20 as default for that reason.
What does RTT-bound mean for OpenVPN-TCP?
OpenVPN over TCP wraps your inner traffic inside an outer TCP stream. That outer stream is subject to the standard TCP throughput cap: window size times eight, divided by round-trip time. Across a long link the cap lands at single-digit Mbps regardless of how fast the line is. UDP-based protocols do not have this cap.
Does the MTU really matter?
Modestly. With a 1500-byte MTU and a 60-byte WireGuard header, 4% of every packet is framing rather than payload. The default 1500 is right for most home connections. Lower it only if you are hitting fragmentation symptoms.