A Real VPN Kill Switch
forcing specific traffic through a VPN at the router level, with a rule that fails closed instead of quietly leaking your real IP.
if you’ve got any workload that should always exit through a VPN — a download client, anything privacy-sensitive — don’t rely on a per-host firewall alias, and don’t rely on an in-container VPN client alone. give it its own network segment and enforce the routing structurally.
this is the pattern i landed on after finding a half-finished attempt at exactly this sitting in my own router config from an earlier me — WireGuard server disabled, gateway bound to the wrong interface, an alias that resolved to my entire LAN instead of the one host it was supposed to cover. it never actually worked, and worse, if i’d flipped it on as-is it would’ve either routed nothing or routed everything. quietly.
that’s the failure mode this pattern is built to avoid.
the core idea
two firewall rules, in order, on whatever network the VPN-bound traffic lives on:
| # | action | source | gateway | why |
|---|---|---|---|---|
| 1 | pass | this network | VPN gateway | forces matching traffic through the tunnel instead of the default route |
| 2 | block | this network | (none) | catches anything rule 1 couldn’t route — i.e. the VPN is down — and drops it |
rule order is the whole mechanism. firewalls evaluate top-down, first match wins. if the kill-switch rule isn’t directly below the force-route rule, or lives on a different interface, traffic can leak your real IP the moment the tunnel drops.
setting up the tunnel
a few fields worth double-checking on the WireGuard side, since these are the ones that actually caused my original setup to silently fail:
- enable both the server instance and the peer — easy to leave one disabled after initial setup, which is exactly what happened to me
- public key should auto-derive from the private key on save — if it stays empty, the private key itself is bad
- assign the WireGuard instance as its own interface, separate from the client network — the gateway needs to point at that, not at the network the VPN-bound devices live on. this was the actual bug in my original attempt: gateway bound to the client-side network instead of the tunnel
- monitor IP should be something reachable inside the tunnel — pinging the provider’s public endpoint over WAN doesn’t verify the tunnel itself is healthy, it’ll show “up” even when the tunnel’s broken
selecting which traffic gets the VPN treatment
two options:
- host alias — explicit IP list. fragile. someone has to remember to keep it updated, and a stale or wrong alias can silently cover far more (or less) than intended. this is what broke my first attempt.
- network membership — match on “this segment’s network” directly. structural. a device either lives there or it doesn’t, no list to drift out of sync.
network membership wins whenever you can dedicate a whole segment to VPN-only traffic. it’s the difference between a rule that can be misconfigured with a typo and one that can’t.
test it properly
- connect a device on the VPN-bound network, check its egress IP against any “what’s my IP” service — should show the VPN exit, not your real WAN IP
- confirm devices outside that network still exit normally
- disable the VPN peer on purpose and confirm the bound device loses connectivity entirely instead of falling back to WAN — that’s the kill switch actually doing its job. skipping this step means you’ve built something that looks right and might not be.
that last test is the one people skip, and it’s the only one that actually proves the “kill switch” part of “kill switch.”