VPN Throughput Testing: A Practical Guide for Real Numbers

You connect to your VPN. Things feel slower. You open Speedtest, run it once, see a number, and have no idea whether that’s normal, the VPN’s fault, your ISP’s fault, the test server’s fault, or some combination. A single Speedtest run inside a VPN tunnel tells you almost nothing because too many variables changed at once.

Testing VPN throughput properly means structuring the test so the VPN tunnel is the only variable. That requires more than tapping Go on Speedtest. This post walks through how to measure real VPN throughput with iperf3, identify where the bottleneck actually is, and benchmark commercial VPNs against your bare connection.

What a VPN actually does to throughput

A VPN adds three sources of overhead:

1. Encryption. Every byte gets encrypted on send and decrypted on receive. On modern CPUs with AES-NI, this is fast — but it’s never free.
2. Encapsulation. Each original packet gets wrapped in a tunnel packet (IPsec, WireGuard, OpenVPN, IKEv2). The wrapper adds bytes that don’t carry your data.
3. Routing. Traffic that would have gone directly to the destination now goes through the VPN server first, often in another country. Adds latency, which on long-distance links bounds TCP throughput.

The combined effect is that VPN throughput is typically 50–85% of bare-line throughput, depending on the protocol, CPU, and tunnel topology. Anything below 50% is a sign something is wrong.

The right way to measure

For a meaningful VPN throughput number, you need:

1. A bare baseline. Run iperf3 with the VPN disconnected, against the same remote server you’ll later test through the VPN. Record the result.
2. The same test, through the VPN. Connect the VPN, run iperf3 again against the same remote server. Same parameters (protocol, duration, parallel streams).
3. Three repetitions of each. One test is noise. Three is a pattern.

Comparing the means gives you the actual VPN overhead. Comparing the ranges tells you if the VPN is unstable (some connections fine, others much worse).

A minimum credible setup

What you need:

• A remote iperf3 server. Three options, in increasing order of usefulness:
  1. A public iperf3 server in the same region (rough baseline, free, sometimes flaky).
  2. A rented $5/month VPS in a city your VPN has an exit node near (much better isolation, $60/year).
  3. A friend’s home server, on a different ISP (the most realistic real-world peer test).
• Two known states: VPN off and VPN on. Verify the VPN is actually up by checking your IP at whatismyipaddress.com before the second test.
• The iperf3 client. Phone, laptop, or any device with the app.

Optional but useful: a way to confirm the test is going through the tunnel and not leaking out around it. Some VPN clients have a “kill switch” or routing-leak indicator. Without that confirmation, you might be measuring bare-line throughput while thinking you’re measuring the VPN.

What to look at in the result

Beyond the bandwidth number, two other metrics matter for VPN testing:

• Retransmits (TCP). A working VPN with normal overhead has retransmit counts comparable to the bare line. Retransmits 5x higher inside the tunnel mean the tunnel is dropping or reordering packets — a real problem, not just throughput overhead.
• Latency increase. VPN routes traffic through the exit server, so RTT grows. From a UK home to a UK iperf3 server: bare-line RTT ~10 ms, through a UK-exit VPN ~12–15 ms (small extra hop), through a US-exit VPN ~80–100 ms (transatlantic). The added RTT directly bounds single-stream TCP throughput.

Isolating where the bottleneck is

If VPN throughput is much lower than bare line, the suspect list is:

1. VPN-server CPU. The remote VPN server has finite CPU budget. At peak, a shared VPN endpoint may CPU-cap your throughput regardless of your line speed. Test at off-peak hours; if performance jumps, it was server-side load.
2. Your CPU. On older devices, especially without AES-NI hardware acceleration, encryption itself caps throughput. Check CPU during the test. If it’s pinned, you found the bottleneck.
3. MTU mismatch. VPN headers reduce the effective MTU. If your VPN client doesn’t lower the MTU automatically, packets get fragmented and throughput crashes. Most modern clients handle this; some corporate IPsec setups don’t.
4. Protocol choice. WireGuard is fast (10–30% overhead). OpenVPN is slow (20–50% overhead). IPsec is usually fast on hardware-accelerated clients, slow on others. If your VPN supports multiple protocols, try each.
5. Wrong exit node. A “closest server” auto-pick may route you 800 km away because of how the VPN’s load balancing works. Try manually selecting an exit node in your country.

The discipline is to change one variable at a time and rerun the test. Three runs per configuration, compare.

Realistic numbers for common VPN setups

Rough expectations, on a ~1 Gbps bare line, against an in-region endpoint:

VPN type	Typical throughput	Notes
WireGuard, local exit	700–900 Mbps	Lowest overhead protocol, modern hardware
WireGuard, foreign exit	200–500 Mbps	Latency dominates over distance
OpenVPN UDP, local exit	400–600 Mbps	More CPU-intensive
OpenVPN TCP, local exit	200–400 Mbps	TCP-in-TCP is fundamentally slow
IPsec/IKEv2, local exit	500–800 Mbps	Highly hardware-dependent
Corporate IPsec to office	100–400 Mbps	Often constrained by remote firewall CPU
Commercial VPN, busy time	150–400 Mbps	Shared exit node contention

If your numbers are far below these ranges, the VPN provider, protocol, or your local setup has a problem worth investigating. If you’re inside these ranges, the throughput is normal for the technology — the question becomes whether you can live with it.

The “VPN makes it faster” case

A surprising number of people find their internet faster through a commercial VPN than without. Almost always, this means the ISP is shaping traffic the VPN tunnel hides. You can verify this by running the same iperf3 test:

• Bare line, peak hours: 250 Mbps.
• Same test, through VPN, same exit country, peak hours: 600 Mbps.

If you see that pattern reproducibly, you have evidence of ISP traffic shaping. (See the throttling investigation post for a full procedure.)

Corporate VPN considerations

Corporate IPsec or SSL-VPN to a head-office concentrator has its own failure modes:

• CPU on the corporate firewall. Many older Cisco ASAs, FortiGates, and SonicWalls cap aggregate VPN throughput at a few hundred Mbps regardless of individual link speeds. The vendor’s data sheet number is theoretical maximum; reality is often half.
• MTU mismatch from the home side. Home routers don’t always negotiate MTU correctly through IPsec. Set the laptop’s NIC MTU to 1400 or 1380 if you see fragmentation.
• Split tunnelling vs full tunnel. Full tunnel sends all traffic through the corporate VPN, including Netflix and Zoom. Split tunnel routes only corporate destinations. Performance and user experience are dramatically different.

iperf3 inside the corporate tunnel to an iperf3 server inside the corporate network is the cleanest way to characterise this. If the IT team will set up a temporary iperf3 server on the inside, you can document exactly what the tunnel delivers — useful for justifying firewall upgrades or split-tunnel configurations.

When the VPN is the bottleneck and you can’t change it

Sometimes the answer is “this is just how fast this VPN is, and we have to live with it.” If that’s the case:

• Use the VPN selectively. Most “always-on VPN” setups are over-engineering. Use VPN for sensitive sites and bare line for everything else.
• Switch protocols if the provider supports it. WireGuard if available; OpenVPN UDP over TCP if not.
• Get closer to the exit. A “nearby” exit node is usually faster than a “private” one across the world.
• Upgrade the device. A phone or laptop without AES-NI hardware is a real cap. A modern Mac or PC removes it.

Bottom line

Speedtest inside a VPN tunnel is theatre, not diagnosis. The real numbers come from iperf3 against the same remote endpoint, with the VPN off and on, repeated three times in each state. If the overhead is normal (50–85% of bare line), the VPN is working as designed. If it’s worse, the bottleneck is identifiable — usually CPU, protocol, MTU, or exit-node placement — and you can fix or work around it.