Why your router's Wi-Fi rating doesn't predict VPN throughput

A router with a 3,000 Mbps Wi-Fi badge can still move encrypted traffic at a fraction of that number, and neither figure is dishonest. The radio rating describes a best-case modulation of the wireless link that the chipset supports; the VPN figure describes how fast one device can push encrypted packets through the router's CPU and out of your access circuit. Those are different layers, different packet sizes, and different measurement methods. Treat the box number as a ceiling nobody reaches, not as a forecast of your tunnel speed.

Step 1: Map the four layers that cap the number

Almost every slow-router complaint I have worked through lands in one of four tiers: the wireless link, the WAN access rate, the forwarding path (NAT, firewall, connection tracking), or the VPN crypto path. They stack, and the slowest tier sets the result. An advertised Wi-Fi rate only talks about the first tier, and it talks about it generously.

That number comes from streams times channel width times the highest modulation the chipset can negotiate. A 2x2 radio on 5 GHz at 80 MHz with 1024-QAM is advertised near 1,200 Mbps, but Wi-Fi is a shared, half-duplex medium: clients take turns, retries and management traffic burn airtime, and TCP adds its own overhead. A client that negotiates the top rate in ideal conditions usually measures well under half of it, and less once neighboring networks appear.

If the table points at the radio, fix the wireless side first: band, channel width, distance. If it points below the radio, the next four steps matter, and no amount of antenna shopping will change them.

Step 2: Take a wired baseline before you touch the radio

Put the laptop on Ethernet and measure the path without the tunnel first, because that gives you a denominator. Run the throughput tool on the far side, the VPS or home server that terminates the VPN, and point the client at its public address so traffic crosses your router and access circuit.

# on the far host (VPN endpoint)
iperf3 -s

# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30

# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4

Two numbers from that block answer different questions. One stream shows the per-connection ceiling, which includes TCP window behavior and any per-flow shaping on the path. Four streams show whether the link has capacity you are failing to use, because parallel flows can fill a pipe that a single flow cannot.

Keep it honest: same host, time of day and duration, with nothing else streaming in the house. A thirty-second bulk transfer is the right unit here, and RFC 6349, the framework for TCP throughput testing, is built on that reasoning, because short bursts and small requests flatter a link. Write the baseline down before you change anything.

Step 3: Run the same test through the tunnel

Now repeat it against the endpoint's tunnel address, same client, duration and stream count, with the tunnel up and no other traffic. The ratio between the two results tells you what encryption and encapsulation cost on that hardware; the absolute number tells you whether it is enough for the job.

Watch the counters while the transfer runs. On WireGuard, wg show reports transferred bytes per peer; on OpenVPN, a status file written on an interval gives you the same view.

watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status

If the tunnel number is close to the wired baseline, the VPN is not your bottleneck and you can stop blaming it. If it is a fraction of the baseline, the loss happened inside the router's encryption and forwarding path, and the next step tells you which part.

One caution: once the exit IP changes, some speed-test services quietly pick a different measurement server, so you end up comparing two destinations. Pin the server address yourself.

Step 4: Read CPU as a path, not an average

A router showing 30 percent total CPU can still be saturated: one tunnel's work tends to land on one core, one interrupt queue or one kernel thread, so the average hides the ceiling. Look at per-core and softirq numbers instead of the dashboard gauge.

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

Three things matter in that output. A single core pinned near 100 percent while the others idle points at a per-connection limit. Heavy %soft or a busy ksoftirqd on one CPU points at receive-side packet processing that is not spreading across queues. And a missing aes flag means the CPU has no AES instructions, so symmetric encryption runs in software and costs far more per packet.

Implementation matters too. A traditional user-space OpenVPN instance processes one tunnel's packets largely in one place, so a fast multi-core box can behave like a single-core one for that tunnel. WireGuard in the kernel spreads work across CPUs, and OpenVPN's data channel offload moves packet handling into the kernel too, but only on builds and platforms that support it. A hardware acceleration claim on the marketing page is not proof that the code path you are running uses it.

Step 5: Decide what to change, in that order

Work down this list and stop at the first line that is true, because changing anything below it will not move the number.

1. Wired direct throughput is below what you pay for: talk to the provider, since the tunnel cannot create capacity the access circuit does not deliver. 2. Wired direct is fine but one core pins during the tunnel test: the router's crypto path is the limit. 3. CPU is idle but the tunnel is slow: check MTU and fragmentation, then the far endpoint's own capacity. 4. Only Wi-Fi clients are slow: change band or channel width, and accept that the advertised rate was never a VPN figure.

When the router really is the limit, the honest options are a device with AES instructions and a faster forwarding path, a kernel-side tunnel such as WireGuard in place of a user-space one, or moving the client onto the device itself so the router stops encrypting. Turning off authenticated encryption to win a benchmark is not one of them; it trades a security property for a number that still will not match the box.

Before buying anything, rerun steps 2 and 3 on the new device with the same server and duration, then compare ratios rather than peaks.