What a VPN kill switch actually does

The name suggests a switch that kills something. What it actually is, in every implementation, is a firewall rule: drop any packet whose route is not the tunnel. Understanding it as a rule explains both what it guarantees and where it has gaps.

The problem it solves

A VPN drops. Networks change, servers restart, laptops sleep, phones move between cells. Without a kill switch, applications notice nothing: the operating system falls back to the ordinary route and traffic continues in the clear.

That is the worst state, because nothing about the experience changes. Pages load, the client may still show connected for a while, and your traffic is visible to the network the entire time.

The two implementations

Application-level. The VPN client installs firewall rules when it connects and removes them when it disconnects. This is what most desktop clients do.

It works while the client is running. It does not cover the window between the network coming up at boot and the client starting, and it does not survive the client crashing in an unusual way.

System-level. The operating system enforces it, independently of any app.

Android's "block connections without VPN", available once always-on VPN is enabled, is the clearest example. It applies from boot, it does not depend on the app running, and when it engages the phone genuinely has no network. That is a materially stronger guarantee than an app-level rule.

Linux gets the same property from persistent firewall rules, installed independently of wg-quick rather than by its PostUp.

Building one by hand

The rule from WireGuard's own documentation rejects anything leaving that does not carry the tunnel's firewall mark:

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

Two details in there are worth noticing. It excludes packets destined for local addresses, so the machine can still talk to itself. And it works by mark rather than by address, so the tunnel's own encrypted packets — which must reach the server outside the tunnel — are permitted.

Every kill switch has to solve that second problem. A naive rule that blocks everything not on the tunnel interface blocks the tunnel itself.

What it does not cover

Traffic that already left. A DNS lookup answered a second before the drop is gone.

IPv6, in weaker implementations. A switch that blocks IPv4 and not IPv6 leaves every dual-stack site reachable around it.

Local network traffic, usually deliberately, so printers and casting keep working. On a home network that is fine. On a café network the local network is everyone else in the café.

The boot window, unless it is system-level.

A tunnel that is up but broken. If the interface exists and the handshake died twenty minutes ago, the switch sees a healthy interface and allows traffic that goes nowhere. This is the failure that produces the most confused reports.

Testing yours

Do not test by clicking disconnect: a well-behaved client tears down in an orderly way and the switch has every chance to engage.

Test by killing the VPN process while traffic is flowing. Traffic should stop immediately and completely, including IPv6. Anything that continues for more than a moment is a gap.

Should you leave it on

Yes, with one caveat: know that it is on. A kill switch that engages looks exactly like a broken network, and the most common support question it generates is from someone whose device has no connectivity after the VPN app was updated or removed.

The trade is that a device with the switch on either has a protected connection or none. If you would rather be online than protected in that moment, the switch is not what you want — and it is worth being clear with yourself about which of those you are choosing.

Once it is on, verify the normal path still works with what is my IP rather than assuming. On Android in particular, the combination of always-on, lockdown and battery-optimisation exemption is the configuration that behaves predictably.

Per-app kill switches

Some clients let you name applications that must never run outside the tunnel, rather than blocking everything. The rules are the same firewall rules, scoped to those processes.

This is a reasonable middle ground on a machine where losing all connectivity is disruptive but one particular application must never leak. It is weaker than the whole-machine version in an obvious way: anything you did not name is not covered, including software you install later.

Why "kill switch" is a slightly misleading name

Nothing is killed. Connections are not torn down; packets are simply dropped. An application with an open connection will usually sit and wait rather than receive an error, which is why the symptom is hanging rather than a clear failure message.

That matters when diagnosing. A machine behind an engaged kill switch does not report "no network" — it reports nothing at all, and applications time out one by one.

What a provider can and cannot promise

A kill switch is entirely client-side. It is a rule on your machine, enforced by your operating system, and the provider's servers have no part in it. That is worth knowing because it means the guarantee depends on the quality of the client rather than on anything about the network, and it is one of the few security properties you can verify yourself without trusting anyone.