Running a VPN on your router, and when not to
Putting the tunnel on the router covers every device on the network, including televisions and consoles that cannot run VPN apps. The costs are a throughput ceiling set by the router's CPU, one exit country for the whole household, and no way to exclude a single device.
4 min read
A router VPN is the only way to cover devices that cannot run a VPN app: Samsung and LG televisions, games consoles, older streaming boxes, smart speakers, anything with a network stack and no app store worth the name. It is also the setup people most often regret, because the costs are invisible until you hit them.
What you gain
- Everything is covered, including devices you forgot were on the network.
- Nothing is installed anywhere. A guest's phone that joins the Wi-Fi is tunnelled without them doing anything.
- One configuration to maintain rather than one per device.
- Devices that cannot be configured at all are handled, which is the whole reason most people do it.
What you give up
Throughput. This is the big one. A router's CPU is slow, and encryption is CPU work. A consumer router that routes a gigabit happily will often manage 50 to 200 Mbps through a WireGuard tunnel, and considerably less through OpenVPN. The line speed you pay for stops being the number that matters; the router's crypto throughput does.
One exit country for everyone. Your partner's banking app now appears to be in another country, along with every regional service in the house.
No per-device control. Excluding one device means a policy-based routing rule, which most consumer firmware cannot express.
A single point of failure. When the tunnel drops, the whole house is offline or the whole house is exposed, depending on how the firewall is configured.
Which routers can do it
| Firmware | WireGuard | Notes |
|---|---|---|
| OpenWrt | Yes | Best support; packages wireguard-tools and luci-proto-wireguard |
| MikroTik RouterOS 7 | Yes | Cannot import a wg-quick file; needs a RouterOS script |
| AsusWRT (recent) | Yes | Built-in client, straightforward interface |
| ISP-supplied boxes | Usually not | No VPN client and no firmware replacement |
If your router is an ISP box with locked firmware, the options are replacing it, putting a second router behind it, or abandoning the router route entirely.
The configuration, in outline
Whatever the firmware, a WireGuard client on a router needs the same five
things: a private key, an address, the server's public key, the server's
endpoint, and AllowedIPs. Set AllowedIPs to 0.0.0.0/0, ::/0 for a full
tunnel.
Then three router-specific pieces that a desktop client would handle for you:
- A route sending LAN traffic into the tunnel interface.
- A firewall zone for the tunnel, with masquerading on, so LAN addresses are translated to the tunnel address.
- MTU, set explicitly. 1420 is right for Ethernet; PPPoE lines need 1412.
MikroTik is the awkward one because RouterOS cannot read a wg-quick profile at
all. VPNmine generates a RouterOS script for that case, and the
router page covers the one line you must check — the default
LAN subnet in the script is MikroTik's factory 192.168.88.0/24, which is wrong
for most installations.
Measure before and after
Run the speed test from a wired device before you configure anything, then again with the tunnel up. The gap is what your router's CPU costs you, and it is the number that decides whether this arrangement is tolerable.
If the drop is severe, three things help: pick a nearby server, use WireGuard rather than OpenVPN, and check whether the router has hardware acceleration that the tunnel is bypassing. Many consumer routers offload plain NAT to a hardware path and cannot offload encrypted traffic at all, which is why the difference is often much larger than expected.
The arrangement most people should actually use
A travel router or a second router carrying the tunnel, with the main router untouched. Devices that need the tunnel join that network; everything else stays on the house network at full speed.
It costs a small piece of hardware and removes every downside except throughput on the tunnelled devices. For a household where one television needs a tunnel and nobody else does, it is strictly better than converting the whole network.
Confirm it works
From a device behind the router, open what is my IP. The address should be the server's. Check from a second device too: a routing rule that catches one subnet and not another is a common misconfiguration and looks perfectly healthy from the device that happens to be covered.
