The kill switch: the small detail that decides whether a VPN actually protects you
A VPN is only as good as the moment its tunnel drops. Here is what the kill switch is, why most implementations are weak, and how to verify yours actually works.
SecurityA VPN tunnel is going to drop. Not maybe — definitely. Networks switch, routers reboot, your laptop sleeps, your phone hands off between Wi-Fi and cellular. Each of those events is a microsecond where your traffic could leak out the back door, no longer encrypted, no longer through our exit. The kill switch is the thing that decides whether that microsecond turns into a real exposure or stays harmless.
What it is, mechanically
A kill switch is a piece of code that watches the tunnel interface. If the interface goes down for any reason — an explicit disconnect, a network change, a process crash, a phone going to sleep — the kill switch immediately blocks all outbound network traffic until the tunnel is back up. From the operating system's perspective, the route to the internet has been replaced with a brick wall.
On Linux this is implemented with nftables/iptables rules that drop everything not destined for the VPN interface. On macOS it is a Network Extension that owns the default route and refuses to fall back. On Windows it is a WFP (Windows Filtering Platform) callout. On iOS and Android the OS itself provides primitives for this — "Always-on VPN" plus "Block connections without VPN."
Why most implementations are weak
Three common failure modes turn a kill switch into theatre:
- Application-level only. The VPN app blocks itself but the OS still routes other traffic normally. If the app crashes, the wall is gone.
- No protection during reconnect. The tunnel drops; the app starts a reconnect; in the meantime the OS routes via the LAN. By the time you notice, your client has phoned home.
- Fails open on system events. Some implementations release the firewall when the user logs out, the laptop sleeps, or the device upgrades — exactly the moments traffic is most likely to leak.
How a strong kill switch behaves
- Kernel-level. Lives below the application, so a crashing app or stuck process cannot release it.
- Default-deny on every state change. When the tunnel goes down, the firewall is closed in the same syscall that releases the route. There is no window between "tunnel gone" and "firewall up."
- Survives sleep, log-out, fast-user-switch, and OS upgrades. Persistent rules, reapplied on boot.
- LAN-only escape valve, configurable. Some users need to print or AirDrop while connected. The kill switch should let through RFC1918 (10.x, 192.168.x) only if you opt in, and never the wider internet.
How to verify yours
Test 1 — yank Wi-Fi mid-session
Open the speed test. Start a download. Disable Wi-Fi for 5 seconds, then re-enable. The download should pause and then resume — not silently failover to your real IP and continue.
Test 2 — kill the VPN process
On a desktop, find the VPN process in Activity Monitor / Task Manager and force-quit it. Open a fresh browser tab and try to load anything. The page should fail to load until the app reconnects. If pages load through your real IP, the kill switch was app-level only.
Test 3 — sleep the laptop
Connect, close the laptop lid for one minute, open it again. The very first packets after wake should be tunnelled, not leaked. Many VPNs leak the first few seconds because the kill-switch firewall is restored before the tunnel is, but never the other way.
PlanetProxy specifically
Our kill switch is kernel-level on every desktop platform and uses the OS-blessed primitives on iOS and Android. It defaults to closed across all state transitions: the firewall comes up before the tunnel goes down, and the tunnel comes back up before the firewall comes down. We test the three scenarios above on every build before release; the test is automated and reports go in our changelog.
Frequently asked
Should I always have the kill switch on?+
Yes, unless you have a specific reason not to. The performance cost is zero; the security benefit is meaningful. Our default is on for all new accounts.
What if my VPN provider does not have a kill switch?+
Then assume any tunnel drop is exposing your traffic. Many users layer a host-level firewall (Little Snitch on macOS, simple iptables on Linux) for the same effect.
Run PlanetProxy for seven days, on us.
Same purple tile cards you see on this page, plus the green lock and a 50 ms hop to wherever you want to be.
Start the trial →More from the dispatch
SecurityPP · DispatchHow to read a no-logs audit (without the marketing gloss)Security · 8 minHow to read a no-logs audit (without the marketing gloss)
Every VPN claims "no logs". A small fraction back the claim with an audit. An even smaller fraction publish the audit. Here's how to actually read one.
- SecurityPP · DispatchPost-quantum cryptography: why "harvest now, decrypt later" is the threat that mattersSecurity · 8 min
Post-quantum cryptography: why "harvest now, decrypt later" is the threat that matters
A large quantum computer is probably still years away. The recordings of your traffic from this afternoon are not. Here is what HNDL actually means, what NIST finalised in 2024, and what "post-quantum ready" looks like for a VPN that is not just selling a sticker.
- SecurityPP · DispatchAI-powered phishing in 2026: how the attack changed and what works against itSecurity · 7 min
AI-powered phishing in 2026: how the attack changed and what works against it
The "Nigerian prince with three typos" is gone. The replacement is fluent in your dialect, knows your boss's name, and can call you in your CFO's voice from 60 seconds of podcast audio. Here is what the data says, what defences are actually holding, and which "best practices" are now folklore.