Why gigabit connections lose the most to a VPN
Tunnel overhead is mostly fixed work per packet, and a gigabit line moves roughly twenty times more packets per second than a 50 Mbps one. Slower connections leave the CPU idling; fast ones do not, so the same tunnel costs a much larger share of the capacity.
4 min read
Someone on a 50 Mbps connection turns on a VPN and loses almost nothing. Someone on a gigabit line does the same and lands at 400 Mbps. Both are using the same software and the same protocol, and both results are correct.
The arithmetic
At a 1,500-byte MTU, moving 1,000 Mbps means roughly 83,000 packets per second. Moving 50 Mbps means about 4,100.
Every packet costs the same fixed work regardless of the line speed: encrypt or decrypt it, compute an authentication tag, add and remove headers, look up a route, cross a kernel boundary, handle an interrupt. That work is per packet, not per megabit.
So the gigabit line asks the CPU to do twenty times as much of it. On a slow line the processor is idling and the tunnel is free. On a fast line it is not.
Where the ceiling actually sits
| Hardware | Rough WireGuard ceiling |
|---|---|
| Modern desktop or laptop | Above 1 Gbps, often several |
| Recent phone or tablet | 300 to 800 Mbps |
| Mid-range consumer router | 100 to 400 Mbps |
| Budget router or travel router | 20 to 100 Mbps |
| Streaming stick or TV box | 50 to 200 Mbps |
Those are indicative rather than precise, and OpenVPN figures are considerably lower across the board because it traditionally runs in userspace.
The pattern is what matters: the devices most likely to be carrying a whole household's tunnel are the ones with the least capacity to do it.
Why routers are the worst case
Two compounding reasons.
Consumer routers use modest CPUs designed for switching and NAT rather than cryptography, and many have no AES acceleration at all.
More importantly, most of them offload ordinary NAT to a hardware fast path that never touches the CPU. Encrypted traffic cannot use that path, so enabling a tunnel does not merely add work — it moves every packet from a hardware accelerator onto a slow general-purpose core. That is why the drop is often far larger than people expect, and why the router guide treats throughput as the first thing to measure.
What helps
Use WireGuard. Kernel data path, no userspace copies, and ChaCha20-Poly1305 is fast without hardware acceleration.
Check MTU. A tunnel MTU set unnecessarily low means more packets for the same data, which is precisely the cost that scales.
Move the tunnel off the router. Running it on each device that needs it uses the device's much faster CPU, and leaves the router doing what it is good at.
Use a device with AES-NI if you are running OpenVPN, where the cipher choice still matters a great deal.
Test wired. Wi-Fi may be the real ceiling, and it is easy to blame a tunnel for a limit the radio imposed.
What does not help
Buying a faster internet plan. If the bottleneck is the CPU encrypting packets, more line speed changes nothing — a common and expensive mistake.
Changing the cipher on hardware that accelerates both. On a modern desktop the difference between AES-GCM and ChaCha20 is not what is limiting you.
Measure the ceiling, not the line
Run the speed test with the tunnel up on the device in question, and watch the CPU while it runs. A core pinned at 100 percent is the answer: that device cannot go faster, and nothing about the network will change it.
If the CPU is comfortable and the number is still low, the bottleneck is elsewhere — distance, server load or MTU — and those are the things worth adjusting.
Is it worth caring about
Only if you use the capacity. Streaming 4K needs about 25 Mbps, and a video call needs a fraction of that. A gigabit line running at 400 Mbps through a tunnel is still far more than a household consumes.
The cases where it genuinely matters are large transfers, multi-user households downloading simultaneously, and anyone who bought a fast line specifically to use it. For everyone else this is an interesting number rather than a problem.
Multi-core does not automatically help
A single WireGuard tunnel can be limited by one core, because packets for one peer are often processed on the same queue to preserve ordering. A machine with eight idle cores and one saturated one is a common sight when a tunnel hits its ceiling.
Receive-side scaling and multi-queue network interfaces spread the load across cores, and they work well for many flows and less well for one tunnel carrying everything. That is why a server handling hundreds of peers scales nicely while a single client's throughput plateaus.
The practical consequence is that a faster processor helps more than more cores do, for one tunnel on one machine.
Jumbo frames, briefly
If both ends of a link support frames larger than 1,500 bytes, fewer packets carry the same data and the per-packet cost falls proportionally. That is a real lever inside a datacentre or on a local network.
It is not available across the public internet, where 1,500 is effectively universal and a tunnel has to fit inside it. So it is worth knowing about and almost never worth pursuing for a consumer VPN.
