On this page
A gigabit fiber connection does not guarantee gigabit VPN transfers. The tunnel adds packet overhead, but encryption is only one part of the gap: CPU limits, server load, packet size, peering, and test methodology can matter just as much.
Instead of blaming a protocol after one speed test, build a repeatable baseline and separate byte overhead from processing bottlenecks. The result is a practical answer to two questions: how fast can this setup transfer useful data, and what should you change next?
Calculate the transfer you actually care about
Begin with application payload, not the number printed on the internet plan. A backup job cares about bytes delivered and elapsed time. A video call also cares about latency variation and loss. A VPN can affect those outcomes differently, so a single download score cannot describe the whole connection.
Use the Bandwidth & Transfer Time Calculator below with a representative file size and measured connection speed. Try several overhead assumptions to see how much scheduling margin your backup window needs. These are planning scenarios, not measured claims about a specific protocol or provider.
Keep units straight: a decimal gigabyte contains eight gigabits, while a gibibyte uses a different byte count. Likewise, Mbps and MB/s differ by a factor of eight before protocol effects. Record the units your test software reports so a unit conversion does not become an imaginary performance regression.
Do not apply the same penalty twice. If your input speed is already measured application throughput through the VPN, extra overhead generally belongs at zero for that prediction. Apply a scenario allowance when starting from link capacity or another rate that has not already accounted for the tunnel.
Separate packet expansion from processing cost
A tunnel adds encapsulation bytes: outer IP headers, transport headers, authentication data, and protocol-specific fields. The ratio depends on packet size. Small interactive packets devote more of each transmitted byte to headers than large bulk-transfer packets do.
Encryption also consumes CPU time, but its cost cannot be represented by one universal percentage. Hardware acceleration, implementation, processor architecture, and available cores all change the outcome. Some workloads concentrate on one busy core while the machine's overall CPU percentage still looks comfortable.
WireGuard generally uses UDP encapsulation with a deliberately small protocol design. OpenVPN offers more configuration choices, and acceleration or data-channel offload can change its processing path. Consult the WireGuard documentation and OpenVPN community resources before comparing implementations with different features enabled.
There is also path capacity. Your access link may be fast while the route to the VPN endpoint is congested or geographically distant. Traffic then travels from that endpoint to its final destination, introducing another route and another potential bottleneck. An encryption benchmark on localhost cannot establish that either network segment has enough headroom.
Build a controlled baseline with iperf3
Use a server you control on a network capable of exceeding your expected test rate. Install iperf3 at both ends, restrict its firewall exposure to authorized clients, and stop the listener afterward. Do not test public machines without permission or leave a benchmark port broadly accessible.
On that server, start a temporary listener. On the client, compare a single stream, reverse direction, and a few parallel streams. Replace the documentation address with your server's actual reachable address.
# On the controlled test server
iperf3 -s
# On the client
iperf3 -c 198.51.100.20 -t 30
iperf3 -c 198.51.100.20 -t 30 -R
iperf3 -c 198.51.100.20 -t 30 -P 4Run each test without the tunnel, then with it, while keeping the destination and test duration fixed. Confirm the test destination actually follows the tunnel route. Otherwise, a split-tunnel policy can produce impressive numbers that never exercised encryption.
The iperf3 documentation explains test options and output. Parallel streams help distinguish a single-flow limitation from aggregate capacity, but they do not replicate every application. Repeat each case several times and retain the median plus the range, not just the best result.
Use wired Ethernet for the baseline. Verify link negotiation, pause large downloads, and avoid comparing a quiet morning baseline with a congested evening VPN run. Change one variable per round.
Measure CPU, routing, and packet-size symptoms
On Linux, inspect per-core utilization while the transfer is active. The following commands use common utilities; mpstat comes from the sysstat package and may require installation. Substitute your actual test destination.
ip route get 198.51.100.20
mpstat -P ALL 1
ip -s link
tracepath 198.51.100.20A saturated core suggests a processing bottleneck, but the responsible work may include encryption, packet handling, or another process. Compare CPU behavior on the VPN client and server when you control both. Do not assume the slower side is always your laptop.
Investigate MTU problems if small requests work but large transfers stall or repeatedly retransmit. Encapsulation reduces available inner-packet space. Path MTU discovery depends on network feedback, which some paths mishandle. Record the current tunnel MTU, test a lower value supported by your client, and revert if there is no consistent improvement. Randomly lowering MTU is not a general speed optimization.
Latency under load can reveal a different issue: queue buildup at a bottleneck. The gaming and bufferbloat guide covers why saturated uploads can hurt interactive traffic even when bulk throughput looks good. More encryption performance will not fix an oversized queue by itself.
Turn measurements into a useful tuning decision
Calculate the relative throughput change using your paired measurements: subtract tunnel throughput from baseline throughput, divide by baseline throughput, and multiply by one hundred. Label that result observed throughput reduction, not encryption overhead. It includes every changed part of the route and software stack.
Return to the transfer-time calculator with the measured tunnel throughput to estimate a real backup duration. Add time for application setup, many small files, storage limitations, and retries separately. A bulk network estimate is a lower-bound planning aid, not a guaranteed job completion time.
If CPU is limiting, compare a supported alternative protocol or a more capable endpoint. If the remote route is limiting, compare another authorized endpoint while holding the test server constant. If the application alone is slow, investigate disk speed, compression, and application concurrency before changing network policy.
Keep security settings intact during performance tuning. Do not disable authentication or use obsolete encryption merely to improve a benchmark. For related router constraints, see the low-power VPN benchmarking guide. A slightly slower configuration that remains reliable and maintained is usually more useful than a fragile peak score.
Key takeaways
- Separate packet overhead from CPU cost, path congestion, and application limits.
- Compare controlled, repeated tests with the same server and both traffic directions.
- Verify that benchmark packets actually travel through the VPN.
- Diagnose per-core saturation, MTU symptoms, and queueing independently.
- Estimate job duration from measured useful throughput without subtracting tunnel overhead twice.
Reach designers & developers at work
Put your product next to the tools people use every day. One sponsor per placement, no tracking pixels.
Become a sponsor
