Why Router VPN Speeds Can Be Slow

A common complaint goes like this: the home internet runs at a good speed, the VPN on a laptop is fine, but once the VPN moves onto the router every device in the house crawls. Pages that took a second now take five, video buffers, and a speed test shows a fraction of the plan you pay for. People then blame the VPN service, the provider or the weather.

In most cases, the cause is not mysterious and is not a single thing. A router is a small, low-power computer doing a heavy job, and a VPN tunnel asks it to do extra work on every packet. This article walks through the router-specific reasons a VPN can be slow, shows how to measure which one applies to you, and lists fixes in order of effort. For the general reasons any VPN changes speed, read why internet speed changes with a VPN; this article stays with what is different when the router is the one running the tunnel.

What a router has to do when it runs a VPN

Without a VPN, a home router mostly forwards packets. Many routers include special hardware, sometimes called a hardware switch or packet accelerator, that moves packets from one port to another without bothering the main processor. That is how a cheap router can pass a gigabit line.

With a VPN tunnel, every packet that goes through the tunnel needs three extra jobs:

1. Encrypt it on the way out, or decrypt it on the way in.
2. Wrap it in a new packet with extra header information.
3. Hand it to the main processor (the CPU) because the acceleration hardware usually cannot do those steps.

The third point matters most. Routers often skip their fast path for tunnelled traffic, so the main CPU handles it. If that CPU is a small chip that also runs Wi-Fi management, DHCP, DNS and the web interface, the encryption work competes with everything else.

The same pattern happens on a laptop, but a laptop CPU is many times stronger and often has dedicated instructions for encryption. The router has the same job and a smaller engine.

Cause 1: the router CPU is the ceiling

The most frequent reason is simple: the processor cannot encrypt faster than a certain rate. When the speed through the tunnel is about the same no matter which location you pick, and your CPU usage is high during a transfer, you have found it.

Signs:

• Speed is capped near the same figure on every test, such as 40 or 80 Mbps, even though the plan is much faster.
• The router's status page shows one core near 100 percent during a download.
• The router becomes sluggish in other ways while the test runs: the admin page is slow to load, Wi-Fi ping rises.

What affects the ceiling:

• Processor class. Entry-level chips top out low; mid-range chips with several cores do far better.
• Hardware encryption support. A CPU with AES instructions encrypts much faster than one without. Look at the router's specifications.
• Single-core use. Many tunnel implementations use one core for one tunnel. A four-core router may still be limited by one core.
• The tunnel technology. Newer designs aim to be lighter on the CPU. A short overview of the trade-offs is in WireGuard vs OpenVPN, and the WireGuard whitepaper explains the design goals. What you can use depends on what your VPN service supports on routers.

Cause 2: hardware acceleration is switched off or bypassed

Some routers offer a feature often called flow offloading, hardware NAT or fast path. It speeds up ordinary traffic enormously. With some firmware versions, turning on a VPN, quality-of-service rules or certain firewall features disables it for the whole router, including traffic that does not use the VPN.

So you may see two effects together: tunnelled traffic is slow because of the CPU limit, and the normal traffic is also slower than before because the acceleration was switched off globally.

Check:

1. Run a speed test with the VPN disabled but all your other router settings unchanged.
2. Compare with the speed before you installed any VPN configuration.
3. If the plain connection also got slower, look in the router settings for acceleration or offload options and read what turns them off.

Router software differs widely, so look at the vendor's documentation for your model rather than copying a stranger's guide.

Cause 3: packet size (MTU) problems

Tunnelling makes each packet larger. If the packet size settings do not account for it, large packets must be split into two, which wastes time, or they get dropped and must be retransmitted. The classic symptom is that small pages load fine but large downloads crawl or stall.

Path MTU Discovery is the mechanism meant to find the right size automatically, but it depends on certain error messages getting through. When a firewall filters them, the system guesses wrong.

Try this, changing one thing at a time:

1. Download a large file and note the speed.
2. Lower the tunnel's MTU by 40 to 80 bytes, or turn on MSS clamping if the router offers it.
3. Download again. If it jumps up, you found the cause.
4. Keep the highest value that works reliably.

Cause 4: distance and the route to the VPN location

The router cannot make a distant server near. Every extra thousand kilometres adds delay, and on some routes the path between your internet provider and the VPN location is congested at certain hours. The delay is what the latency figure measures.

On a router, this is easy to overlook because you set the location once and then forget it. Try another location from the list your VPN service gives you, test at two different times of day, and compare. If a nearer location is much faster, the old choice was the problem, not the router. The article on how a VPN affects ping separates latency, jitter and packet loss if you need to dig deeper.

Cause 5: Wi-Fi, double NAT and other home-network factors

Sometimes the VPN gets blamed for problems that were already there.

• Wi-Fi. Walls, distance and neighbours' networks slow wireless more than any tunnel. A laptop at the far end of a flat may only receive a fraction of what the router receives. Test with a cable first.
• Double NAT. If the VPN router sits behind another router, such as an ISP box, two layers of address translation add delay and sometimes break features.
• Too many users at once. With the VPN on the router, one small chip handles the entire family's video, downloads and calls together. One person's large download slows everyone else's.
• Old cables and ports. A network cable that negotiates at a lower speed, or a port stuck at 100 Mbps, limits everything behind it.
• Background traffic. Backups, game updates and cloud photo uploads can fill the tunnel without anyone noticing.

A measuring method that finds the cause

Guessing wastes days. Use a fixed procedure and write the numbers down.

1. Baseline. Connect a computer by cable to the router. Run a speed test with the VPN off. Note download, upload and ping.
2. With the VPN, same cable. Turn the tunnel on and repeat. Note the difference.
3. Watch the CPU. During the second test, check the router's CPU load. High use means a processor limit.
4. Other location. Switch to another VPN location and test again.
5. Different time. Repeat in the evening and in the morning.
6. Wi-Fi test. Now test over Wi-Fi from the room where you usually sit.
7. Single device vs router. Install the VPN app on the computer, turn off the router tunnel and test again. This shows what the laptop can do on its own.

A worked example: a plan of 300 Mbps gives 290 on the cable with the VPN off. With the router tunnel on, it gives 60, and the CPU sits at 100 percent. With the VPN app on the laptop and the router tunnel off, the laptop gets 220. The conclusion is clear: the router's processor is the limit, not the VPN service or the line.

Result pattern	Probable cause
VPN off is also slow	Line, Wi-Fi, cable or ISP, not the VPN
VPN off is fast, VPN on is capped at a low number, CPU high	Router processor
VPN on is slow only for large downloads	MTU or MSS
One location slow, another fast	Distance or route congestion
Slow only at certain hours	Congestion on the path
Speed is fine on the laptop app, poor on the router	Router hardware or firmware

Fixes, from cheapest to most expensive

1. Choose a nearer location and test again.
2. Fix the MTU or MSS as described above.
3. Reduce the load. Pause large downloads and cloud backups while you test.
4. Update the router firmware. Updates sometimes improve encryption speed.
5. Move only some devices through the tunnel. If the router supports it, send the devices that need protection through the VPN and leave the rest on the plain connection. The idea resembles split tunneling, done by device.
6. Use apps on key devices instead. The laptop and phone encrypt for themselves, and the router goes back to forwarding packets. XPASS customers can use the free VPNclient app, and the download page lists the official versions for iPhone, Android, Windows and macOS.
7. Replace the router with a stronger one. A device with a faster processor and encryption support is the real fix when the CPU is the ceiling. Research the model's measured VPN throughput, not just its Wi-Fi rating.
8. Use a separate firewall box. Some households place a small PC-based firewall in front of the Wi-Fi router for tunnelling.

For the broader question of when a router makes sense at all, see VPN router vs VPN app, and for a step-by-step walkthrough of the install itself, the router setup guide.

Expectations worth setting

Be wary of marketing numbers for router VPN speeds. The headline figure is often a lab result for one setting, with large packets and a strong test machine. Real homes involve small packets, many users and mixed Wi-Fi. A fair expectation is that a router tunnel will be slower than the plain line, by an amount that depends on the router, and that the answer is measured, not guessed.

Also remember that speed is only one measure. If the tunnel protects a smart TV and a tablet that watch video at modest rates, a router that delivers 60 Mbps through the tunnel is perfectly fine. If you need it for 4K streams on three TVs plus large work uploads, the numbers matter more.

Summary

A VPN on a router is slow most often because the router's small processor must encrypt everything and its fast hardware path is bypassed. Other causes are acceleration being disabled, MTU problems, distance to the VPN location, Wi-Fi and double NAT. Measure with a cable, VPN off and on, watch the CPU, try another location and compare with an app on a single device. Then fix in order: location, MTU, load, firmware, selective routing, apps on key devices, and finally stronger hardware.

If you want to try the app route first, the pricing page shows the passes you can start with.