Router or Laptop Out of CPU? Why Your VPN Speed Stops Short

A router advertises fast Wi-Fi and then struggles to encrypt traffic for three devices at once. A laptop reaches a processing limit while the access link still has room to spare. The server is usually blamed first, and it is usually innocent. The limit sits on whichever machine is doing the tunnel work, and finding it means watching that machine rather than the speed test.

The symptom points at one machine, not at the internet

Where the tunnel runs decides which processor pays for it. If the router terminates it, every covered client shares that router budget. If the laptop runs a client, the laptop pays and the router does not. Running tunnels at both ends creates two workloads that can each become the limit on a different day. Naming the machine is the first step, and it is the step people skip when they open a ticket against the provider.

Count the devices between the application and the far end, then mark the one that encrypts. Everything else is a carrier of bytes it cannot read.

Watch per-core load during a transfer

An overall CPU percentage is the wrong instrument, because encryption work often pins a single core while the rest idle. Look at per-core figures during a controlled transfer and watch for one core sitting near saturation. A moderate average with one busy thread is a strong signal, while a high average with no busy thread usually means an unrelated program. The pattern matters more than the number.

mpstat -P ALL 1 5
top -H -b -n 1 | head -20
lscpu | grep -i -E "model name|aes"

The third command tells you whether the processor exposes AES instructions, which changes the cost of the same cipher by a wide margin. It does not tell you whether the VPN implementation is using them, and the gap between those two facts is where most optimisation claims come from.

Separate encryption from packet handling

Encryption is one cost among several. Copying packets between kernel and userspace, routing lookups, firewall rules and interface handling all contribute, and some implementations pay more for copying than for cryptography. Note which counter climbs alongside the transfer rather than trusting the process name to explain every cycle. A userspace tunnel and an in-kernel tunnel can show completely different profiles for identical traffic.

If one core is busy inside the kernel, the remedy differs from a busy userspace thread, and the profile tells you which one you have. That distinction is worth an hour before buying hardware.

Compare like with like before drawing a conclusion

A comparison is only useful if the task, the access network and the endpoint stay the same. Change the server and the result includes that server route and capacity; change the network and it includes the carrier. Use the same file, the same destination and the same time of day, and pause your own background work. If you must change the device, change only the device.

Power and heat change sustained performance, so a short run on a cool machine is not the same measurement as a long transfer on a warm one. Compare similar power conditions and write them down, because a thermal limit looks exactly like a processing limit in a graph.

Use supported offload and verify it actually engaged

Some implementations can move part of the data path into the kernel or into hardware, and availability depends on the client, the operating system, the server and the configuration. Read the documentation for the version you run and use its own status output or logs to confirm the feature is active. An installed package or a checked box is not evidence. The OpenVPN manual documents data-channel options for its own releases, and those options differ between versions.

When a supported change moves the ceiling, re-run both the application task and a bulk transfer, and keep the previous profile so you can revert. A bulk rate that doubles while the application stays slow has moved the bottleneck rather than removed it.

If processor observations do not follow the symptom, return to the network side. Wi-Fi retries, queueing and the exit path produce the same headline result without any CPU involvement at all.