How to Set Up WireGuard VPN on Your Home Router: Remote Access, Kill Switches, and Split Tunneling Explained

WireGuard has replaced OpenVPN as the go-to VPN protocol for home routers, and for good reason: it uses a fraction of the CPU, establishes tunnels in milliseconds rather than seconds, and its codebase is small enough to be meaningfully audited for security. Running WireGuard on your router — rather than on each device individually — means every phone, laptop, and smart TV on your network gets automatic VPN protection with no per-device app required. This guide walks through the complete setup: server configuration, remote client access, kill switch, and split tunneling.

WireGuard vs OpenVPN on a Router: Why It Matters

OpenVPN is CPU-intensive. On a mid-range router with a 1 GHz MIPS processor, OpenVPN typically caps out at 20–40 Mbps due to the overhead of its TLS negotiation and cipher suite. WireGuard uses ChaCha20-Poly1305 encryption with hardware acceleration on modern ARM chips, regularly sustaining 200–400 Mbps on the same class of hardware. For a household streaming 4K while connected to a VPN, that difference is the gap between a working setup and a throttled one.

WireGuard is also a “stateless” protocol — peers are identified by public keys rather than connection state, so a roaming client (a phone switching from WiFi to cellular) reconnects to the tunnel almost instantly without a full re-handshake. See our WPA2 vs WPA3 guide for how WireGuard’s key-based authentication compares to WiFi security protocols.

Which Routers Support WireGuard Natively

Not every router can run WireGuard. You need either firmware that includes WireGuard kernel support or a router with enough flash storage to install OpenWrt. Here’s the current router landscape:

• ASUS routers (firmware 3.0.0.4.388 and later): ASUS added native WireGuard server and client support to its stock firmware in late 2023. Models including the RT-AX88U Pro, RT-BE96U, and ROG Rapture GT-BE98 Pro can run a WireGuard server directly from the web UI under VPN → VPN Server → WireGuard. No third-party firmware required.
• TP-Link routers (select models): Certain TP-Link business-class routers support WireGuard via the web admin at Advanced → VPN Server → WireGuard. Consumer Archer models generally require OpenWrt for WireGuard support.
• GL.iNet routers: GL.iNet routers run a customized OpenWrt build with WireGuard pre-installed and a polished GUI. The GL-MT3000 (Beryl AX) and GL-AXT1800 (Slate AX) are popular choices for a dedicated WireGuard gateway.
• OpenWrt (any compatible router): OpenWrt 23.05 and later includes WireGuard in the default package repositories. Any router with at least 64 MB of RAM and 16 MB of flash running OpenWrt can become a WireGuard server.

Setting Up the WireGuard Server on Your Router

The following steps apply broadly across firmware types. The exact menu names differ, but the concepts are identical.

1. Generate a server key pair. In the router’s WireGuard interface, click “Generate” or run wg genkey | tee server_private.key | wg pubkey > server_public.key on OpenWrt via SSH. The private key stays on the router; the public key goes into each client’s config.
2. Assign a VPN subnet. Pick a private subnet that doesn’t overlap with your home LAN. If your home uses 192.168.1.0/24, use 10.0.0.1/24 for the WireGuard interface. The router gets 10.0.0.1; clients receive addresses like 10.0.0.2, 10.0.0.3, etc.
3. Set the listen port. WireGuard defaults to UDP port 51820. You can use any UDP port, but avoid ports already in use by other services.
4. Configure port forwarding. Log into your ISP modem or gateway and forward UDP port 51820 to your router’s LAN IP. If your router IS the gateway (bridge mode from ISP), this step is already handled. For CGNAT subscribers, see our CGNAT guide — you’ll need a VPS relay or a service like Tailscale if your ISP assigns a shared public IP.
5. Create a peer (client) entry. For each remote device, generate a key pair on the client side, paste the client’s public key into the router’s peer list, and assign it an allowed IP (e.g., 10.0.0.2/32).

Configuring the Remote Client

On the connecting device — a phone, laptop, or remote router — install the WireGuard app (iOS, Android, Windows, macOS, and Linux all have official clients). The client config file looks like this:

[Interface]
PrivateKey = <client-private-key>
Address = 10.0.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <server-public-key>
Endpoint = your.home.ddns.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

The AllowedIPs = 0.0.0.0/0 line routes all client traffic through the tunnel — this is full-tunnel mode. For split tunneling (below), you’ll replace this with specific subnets. The PersistentKeepalive = 25 sends a keepalive packet every 25 seconds to keep the tunnel alive through NAT on mobile connections. If your home IP changes, set up a free DDNS service (Duck DNS, No-IP, or your router’s built-in DDNS) and use the hostname as the endpoint.

Adding a Kill Switch

A kill switch blocks all internet traffic if the WireGuard tunnel goes down unexpectedly, preventing your real IP from leaking. On Linux and OpenWrt, this is implemented with firewall rules in the WireGuard config’s PostUp and PreDown hooks:

[Interface]
...
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

On ASUS routers with stock firmware, the kill switch is a toggle in the WireGuard client settings labeled “Block non-VPN traffic if tunnel is down.” On GL.iNet routers, it appears in the VPN dashboard as “VPN Kill Switch.” For Windows and macOS WireGuard clients, enable “Block untunneled traffic (kill switch)” in the tunnel settings.

Split Tunneling: Route Only Some Traffic Through the VPN

Split tunneling lets you keep home network access for local resources (NAS, printers, home automation) while routing internet traffic through the VPN. On the client config, replace AllowedIPs = 0.0.0.0/0 with the specific subnets you want tunneled:

# Route only home LAN traffic through the tunnel (remote access only)
AllowedIPs = 192.168.1.0/24, 10.0.0.0/24

# Route everything except local subnets through VPN
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1

The first example is pure remote access: only traffic destined for your home LAN or the VPN subnet goes through the tunnel; all other internet traffic exits locally. This is the right choice for accessing your NAS or home server remotely without routing all your internet browsing through your home connection. The second example routes all internet traffic through the VPN while still allowing local subnet access — useful for a travel laptop that needs both home-network resources and VPN-protected browsing. Tools like the WireGuard AllowedIPs calculator make it easy to generate the correct CIDR notation for your specific split-tunneling requirements.

Dynamic DNS: Handling a Changing Home IP

Most home internet connections have a dynamic public IP that changes periodically. Rather than updating every client config when the IP changes, set up a DDNS hostname that always resolves to your current home IP. ASUS routers include free DDNS at WAN → DDNS. OpenWrt users can install the ddns-scripts package and configure Duck DNS or Cloudflare as the provider. Point your WireGuard Endpoint at the DDNS hostname rather than a raw IP address, and clients will reconnect automatically after an IP change.

Testing the Tunnel

Once the tunnel is active on a remote client, verify it’s working correctly: visit a site like whatismyip.com and confirm it shows your home’s public IP, not your current location’s ISP. Run wg show on the router to see active peers, their last handshake time, and bytes transferred. A successful handshake within the last 3 minutes confirms the tunnel is live. For latency-sensitive use cases like gaming through a VPN, check our high ping troubleshooting guide to understand the tradeoffs between VPN overhead and local latency.