Setup

Running a VPN on Your Router: What It Fixes and What It Quietly Breaks (2026)

8 min read

The appeal is real: configure once, and the television, the console, the printer and the guest phone are all covered — including the devices that will never run a VPN client. The cost is equally real and rarely stated up front. It is worth knowing both before you reflash anything.

The router becomes the ceiling

Encryption is cheap on a phone because a phone has hardware for it. Consumer routers usually do not. The result is that the tunnel runs at whatever the router's small CPU can encrypt, and that number is often far below your line speed:

  • Typical consumer router, no crypto acceleration. Tens of megabits per second on a modern in-kernel protocol; single-digit to low tens on an older userspace one. A gigabit line becomes a fraction of itself.
  • Router with hardware AES. Substantially better, but the specification matters more than the price — plenty of expensive routers lack it, and plenty of cheap ones have it.
  • Small x86 box or a capable mini-PC. Line rate, because it has the same acceleration your laptop does. This is the configuration that actually delivers what people expect from “VPN on the router”.
Hardware NAT offload is disabled the moment traffic is routed through a tunnel. On many routers that alone costs more throughput than the encryption does, which is why measured results are often worse than the CPU alone would predict.

Protocol support is the second wall

Stock firmware from most vendors speaks a small set of protocols and nothing else. Modern tunnels built on Xray or similar cores are userspace programs, and running one usually means alternative firmware plus enough flash and RAM to hold it. Before planning anything, check three things: whether your model is supported by that firmware, how much free storage it has, and whether the core you need is packaged for it. A 128 MB device with a full package list is a bad place to discover the answer.

What breaks that nobody warns you about

  1. 1Everything shares one exit and one reputation. One device triggering rate limits means captchas for the whole household — the mechanism is in IP reputation and captchas.
  2. 2Local services get confused. Printers, casting, file shares and smart-home hubs rely on discovery across the local network; routing rules that catch everything will catch those too.
  3. 3Banking and delivery apps start asking questions. A phone that suddenly appears in another country all day is a stronger anti-fraud signal than the same phone doing it occasionally.
  4. 4Your kill switch changes meaning. On a router, a tunnel failure takes the entire network offline rather than one app. That is either the point or a disaster, depending on who else is at home — see how kill switches work.
  5. 5Diagnosis gets harder. When one site misbehaves you now have two layers to check, and the router rarely tells you which one failed.

The configuration most people actually want

Policy routing by device: the television and the console go through the tunnel, everything else goes direct. It keeps the router's CPU busy only with the traffic that needs it, leaves laptops and phones on their own clients where they can be switched per app, and stops one device's behaviour from affecting the rest. Most alternative firmware supports it by source address or by interface; the same idea applied per application is split tunnelling.

Before you commit

  1. 1Measure your line speed first, without a tunnel, so you have a baseline to compare against.
  2. 2Set the tunnel up on one computer and measure again. That figure is your upper bound; the router will not beat it.
  3. 3Check the router's CPU during a transfer. If it is pinned, you have found your ceiling and no setting will move it.
  4. 4Verify from a device that has no client of its own — a TV browser opening our leak test is the honest check that the routing actually applies to it.
  5. 5Keep one device outside the tunnel deliberately. When something breaks, comparing the two answers the question in seconds.

FAQ

Will a router VPN slow down devices that are not using it?

It can. Encryption competes for the same CPU that forwards ordinary traffic, and hardware offload is typically disabled once routing goes through a tunnel. On a busy household router the effect is noticeable even for direct traffic.

Can I run a modern VLESS or Xray-based tunnel on a normal router?

Only with alternative firmware, a supported model and enough storage for a userspace core. Stock vendor firmware generally offers a fixed protocol list and no way to extend it.

Is a router setup more secure than a client on each device?

No, it is broader. The same tunnel protects more devices, including ones that cannot protect themselves, but it protects each of them exactly as well and gives you less per-device control.

What about a travel router instead?

A good compromise for hotel and café networks: it covers devices with no client, it is easy to move, and the throughput ceiling matters less when the shared network is the slow part anyway.

Did this help?

Nothing follows from the answer; only we see it.

Send this to someone

Useful to anyone with the same problem.