The Kill Switch Is a Firewall Rule, Not a Panic Button

The name is theatrical and the mechanism is boring, which is the good news: a kill switch is a set of firewall rules that refuse to route packets anywhere except the tunnel. Nothing is being killed. Something is being forbidden. The interesting question is what happens in the moments before the rule is in place.

The problem it exists to solve

Tunnels drop. Not dramatically — a handover from wifi to mobile data, a laptop waking from sleep, a server rotating out for maintenance, a few seconds of packet loss that outlast the keepalive.

Without intervention, your operating system does the sensible thing: the tunnel interface disappears, the route through it becomes invalid, and everything falls back to the ordinary default gateway. Your traffic keeps flowing, uninterrupted and unprotected, out of the front door. Nothing warns you. The reconnection notice, when it eventually arrives, is about the reconnection.

The exposure window is usually seconds. Whether seconds matter depends entirely on what you are doing, and the honest answer for a lot of people is that they do not.

Two kinds, and only one is worth having

Application-level. You nominate a list of programs and the client closes or suspends them when the tunnel drops. This covers exactly what you remembered to nominate, which is never the background updater, the cloud sync client, the messaging app that reconnects on its own schedule, or the telemetry that ships regardless. It is better than nothing and it is not much better than nothing.

System-level. The client installs firewall rules — nftables, pf, WFP, depending on the platform — that permit traffic only on the tunnel interface, plus whatever narrow exception is needed to reach the VPN server itself. Everything else is dropped at the kernel, by processes that never get a vote. This is the one people mean when the feature matters.

If a client offers both, the system-level one is the setting. If it only offers the application one, that is worth knowing before you rely on it.

The gap nobody advertises

There is a window between "the tunnel is dead" and "the rules are applied", and its size depends on how the failure is detected.

If the client notices because the interface went away, the reaction is essentially instant. If it notices because a keepalive timer expired, the window is however long that timer is — commonly 15 to 25 seconds — and during it the tunnel is already gone. Packets that left in that window left in the clear.

Well-built clients close the gap by installing the restrictive rules first and only opening them once the tunnel is verified, so the failure mode is no connectivity rather than unprotected connectivity. This is what "always-on" or "lockdown" or "block connections without VPN" usually means in a settings screen, and it is the setting worth finding: it also covers the boot window, the several seconds after login when the network is up and the VPN client has not started yet.

Per platform

• Android has this built in and it is excellent. Settings → Network → VPN → the gear icon → Always-on VPN plus Block connections without VPN. It is enforced by the OS, so it survives the VPN app crashing, which app-level switches by definition do not.
• iOS has no user-facing kill switch. What it has is on-demand rules, which reconnect aggressively, and a supervised-device configuration most people cannot use. Third-party apps approximate the rest. Treat iOS as best-effort.
• Windows clients use the Windows Filtering Platform, which is the right mechanism. The common failure is a client that removes its rules when it exits uncleanly — reboot after a crash rather than assuming.
• macOS clients use pf or a network extension. Both are fine; extensions survive updates more gracefully.
• Linux, if you run WireGuard directly, can do it in the config with no client at all. A PostUp rule that drops anything not leaving wg0, and a matching PreDown, is about six lines and does not depend on anyone's app.

Test it, because the setting is not the behaviour

The test takes a minute and is the only thing that tells you anything.

1. Connect the VPN. Start a continuous ping to a public address: ping 1.1.1.1.
2. Kill the VPN process — Task Manager, Activity Monitor, pkill. Do not press Disconnect.
3. Watch the ping. It should stop immediately and stay stopped. If replies keep arriving, traffic is escaping.

Using the Disconnect button is the wrong test and produces a false pass. Disconnecting is a deliberate act, so most clients tear the rules down on purpose. What you are testing for is the accident, so you have to cause an accident.

Worth repeating the test after any major client update. Kill switches are quietly regressed more often than any other VPN feature, because nobody's release checklist has "unplug the internet" on it.

When you should not turn it on

A kill switch makes your machine's connectivity depend on one company's servers being reachable. On a bad day that means no internet at all, in a way that looks like a broken laptop rather than a working policy, and the person it confuses most is the one who set it up three months ago.

It also breaks local network access unless the client has a LAN exception — printers, NAS, casting, the router's admin page. Most clients have that exception; not all have it on.

Decide by threat model. If a specific observer must never see a specific flow, turn it on and test it. If the VPN is there so hotel wifi cannot see much, a few seconds of exposure during a handover is not the thing that will hurt you, and there are better places to spend the aggravation — such as making sure you do not have a DNS leak the other 100% of the time.

Questions people actually ask