App Kill Switch vs Firewall Kill Switch: What Each Blocks

Kill switch on a feature list tells you almost nothing about what happens when the tunnel drops. One implementation closes selected processes, another installs packet filters at the operating system boundary, and a third simply tries to reconnect. The difference shows up in the seconds after a failure, not on the settings screen. Work through these checks in order and stop at the first one you cannot answer, because that is where your real coverage ends.

Name the enforcement mechanism first

Process termination is an application-lifecycle feature. It finds selected programs after a detected tunnel failure and closes them. Anything that is not the main process survives: helper services, background sync, and any application started a second later all have their own lifecycle and their own timing.

Packet filtering is an operating system feature. It refuses traffic that does not follow the permitted path, which is a stronger promise, but only across what the rule actually matches. Address family, interface, excluded applications and exceptions decide that, not the label in the client.

Does the block outlive the client?

Ask four questions in this order: what happens on a crash, on a manual quit, on logout, and on reboot. A rule maintained by the client itself is usually removed during a graceful shutdown and often left behind after a crash. A rule installed into the platform store can behave the other way round, surviving both the client and, occasionally, the uninstall.

Quit the client in the middle of a long download and watch whether the transfer stalls or continues.

Look for the standard holes

IPv6 is the first one. A rule written for IPv4 addresses leaves IPv6 traffic unaffected, and plenty of clients only write the v4 half. The second is the interface: USB tethering, a second Wi-Fi adapter and a cellular modem may not be included in a rule scoped to the primary connection. Excluded applications and local-network exceptions are the third.

On Windows you can read the installed rules rather than trusting the toggle: Get-NetFirewallRule -DisplayName '*VPN*' and netsh wfp show filters both show what exists. On Linux, iptables -S, ip6tables -S and nft list ruleset cover the common cases, and comparing all three is the point.

DNS is the usual leak

Blocking TCP while leaving UDP 53 open gives you a very convincing kill switch that still answers every hostname lookup. The same applies when DNS is handed to a resolver on another interface, or when the client blocks v4 only and the resolver is reachable over v6.

With the tunnel down, resolve one known name and see whether an answer comes back. If it does, traffic is not fully blocked no matter what the status icon says.

Test the transition, not the toggle

Turning the VPN off from its own menu is a graceful shutdown, and graceful is the case every implementation handles well. The transition that matters is the rude one: kill the tunnel process, pull the network, let the server stop answering. Then start a request and watch whether it fails or quietly uses the physical link.

A result from one laptop does not transfer to a phone or a router. Different platform APIs, different defaults, and on Android the difference is stark: always-on with blocking is enforced by the system rather than the client, so it keeps working when the client does not. The Android VPN guidance describes that split.

Keep a way back

System-level blocking has the opposite failure mode. Filters that outlive the client can leave a machine with no network at all after an uninstall, which is a support call with no obvious cause. Before enabling any kill switch that writes platform rules, note how it is removed, and keep the vendor repair path where you can find it.

If you cannot answer the crash, IPv6, DNS and transition checks for your client, treat it as an app-level switch with known gaps and plan accordingly.