Router VPN throughput and why CPU is the ceiling
Consumer routers offload ordinary NAT to a hardware fast path that never touches the CPU. Encrypted traffic cannot use that path, so enabling a tunnel moves every packet onto a slow general-purpose core. That is why the drop is far larger than people expect.
4 min read
A router advertised as handling gigabit throughput is describing what its hardware forwarding path can do. That path is a switching engine that moves packets between interfaces without the CPU examining them in detail. It is very fast and it cannot encrypt anything.
Turn on a VPN and every packet leaves that path and lands on a general-purpose core that is usually modest, often without AES acceleration, and now responsible for encrypting, authenticating and re-framing every one.
That is why the drop is a cliff rather than a slope.
Rough expectations
| Router class | WireGuard throughput |
|---|---|
| Budget or travel router | 20 to 80 Mbps |
| Mid-range consumer | 100 to 300 Mbps |
| High-end consumer | 300 to 600 Mbps |
| Small x86 appliance | 1 Gbps and above |
OpenVPN figures are typically a third to a half of the WireGuard ones on the same hardware, because it traditionally runs in userspace with a packet copy in each direction.
These are indicative. The only number that matters is the one your hardware produces on your line.
Measuring it
Run the speed test from a wired device behind the router, with the tunnel down and then up. Watch the router's CPU during the tunnelled run if the firmware exposes it.
A core pinned at 100 percent is a complete answer: that is the ceiling, and nothing about the network will raise it. A comfortable CPU with poor throughput points elsewhere — distance, server load or MTU.
What actually helps
Use WireGuard rather than OpenVPN. Kernel data path, cheaper cipher, less work per packet. Frequently doubles throughput on the same hardware.
Check MTU and MSS clamping. A tunnel MTU set too low means more packets for the same data, which is precisely the cost that scales. Missing MSS clamping produces stalls that look like a throughput problem and are not.
Pick a nearby exit. Latency limits throughput independently of CPU.
Disable anything else CPU-hungry. Traffic inspection, QoS on some firmware, and per-client statistics all compete for the same core.
What does not help
A faster internet plan. If the ceiling is the CPU, more line speed changes nothing.
More RAM. This is not a memory-bound workload.
A newer router with a similar CPU. Marketing throughput figures describe the hardware path, not the encrypted one. Look for a review that measured a tunnel specifically, or for a device that advertises crypto acceleration.
The alternative worth considering
Do not put the tunnel on the router at all.
Running a VPN client on each device that needs it uses that device's much faster CPU. A laptop or a phone encrypts several hundred megabits without effort, and the router goes back to doing what it is good at. The cost is configuring more devices and leaving out anything that cannot run a client.
The middle option is a second router, or a travel router, carrying the tunnel only for the devices that need it. Everything else stays on the main network at full speed, and the ceiling only applies where you chose to accept it.
When a router tunnel is still the right answer
- Televisions, consoles and appliances that cannot run a client.
- Households where the requirement is that everything is covered without anyone configuring anything.
- Connections slower than the router's tunnel ceiling, where the ceiling is irrelevant. On a 60 Mbps line, a router managing 150 Mbps through WireGuard costs nothing at all.
That last case is more common than the benchmarks suggest, and it is why the router guide starts by asking what your line speed actually is before worrying about the hardware.
What crypto acceleration does and does not cover
Some router chipsets advertise hardware cryptography engines. Whether they help depends entirely on whether the tunnel's implementation uses them.
IPsec is the best-supported case, because the acceleration was generally built for it. WireGuard's ChaCha20-Poly1305 is frequently not accelerated at all, which sounds bad and mostly is not — the cipher was designed to be fast in software precisely for this class of hardware.
So a router advertising an encryption engine may show excellent IPsec throughput and unremarkable WireGuard throughput, and that is not a defect. Read benchmarks for the protocol you will actually run.
Two tunnels are worse than one
Running a site-to-site tunnel and a client tunnel on the same router divides the same core between them. Throughput does not halve neatly — context switching costs something — but it comes close enough that the plan should assume it.
If a router is carrying more than one tunnel and a household's traffic, the realistic answer is a device with a faster CPU rather than tuning.
The number to check before buying
Ask for a measured WireGuard throughput figure for the specific model. It is rarely on a box and frequently in a community forum or a firmware project's hardware table. That single number predicts the experience better than every other specification combined, and the gap between two routers with identical advertised speeds can be a factor of five.
