The short version: a VPN connection isn't a permanent state — it's a network session that can drop. Wi-Fi roams, cellular tower handoffs, server restarts, packet-loss spikes, app suspensions, and OS sleep cycles all routinely interrupt the tunnel. When the tunnel drops, the operating system's default routing rule says "if there's no specific route, use the physical interface" — meaning your traffic falls back to your real connection, sending your real IP to whatever you were just talking to. A kill switch is the mechanism that says "no, just stop sending traffic until the tunnel is back up." Conceptually simple. In implementation, the term has been used to mean at least three quite different things, with very different failure modes.
Why kill switches exist — the silent-fallback problem
Consider what happens without a kill switch. You're at a coffee shop with the VPN connected. You're reading email through a webmail client. The Wi-Fi has a brief outage — maybe two seconds. The VPN client tries to reconnect, but the underlying network is gone so the reconnection fails. After 30 seconds the network comes back. Now what happens depends on the VPN client's behavior:
- Without a kill switch — the moment Wi-Fi comes back, your operating system's default route reverts to the Wi-Fi interface. The VPN client is still trying to reconnect, but your apps don't wait. Your webmail's background sync sends the next request out over the bare Wi-Fi, using your real IP, with whatever DNS resolver the network handed you. By the time the VPN finishes reconnecting (5-20 seconds later), the leak has already happened.
- With a kill switch — when the VPN disconnects, the kill switch installs a firewall rule that blocks all traffic that isn't going through the tunnel. Even when Wi-Fi comes back, your apps can't send anything until the VPN session is fully restored. The webmail's sync request fails with a network error (the app retries), but no traffic leaves your device over the bare interface.
The silent-fallback problem is the central thing kill switches are designed to solve. It's not "the VPN crashed and now I'm browsing in the clear" — it's the much subtler case where the VPN is briefly unavailable, your apps don't know that, and they leak in the gap.
The three kinds of kill switch
When vendors say "kill switch," they could mean any of these three architectures. The differences matter because the failure modes differ.
1. System-wide kill switch (firewall-based)
The strongest model. The VPN client installs a firewall rule on the operating system — using pf on macOS, the Windows Filtering Platform on Windows, iptables or nftables on Linux, or a system network extension on iOS/Android — that drops every outbound packet that isn't destined for the VPN server's IP. When the VPN is up, the tunnel itself routes traffic to the VPN server, so packets pass. When the VPN is down, nothing matches the "allow" rule, so everything is blocked. The firewall rule remains in place even if the VPN client crashes, because the OS firewall is independent of the application that installed the rule.
2. App-level kill switch (per-application)
Instead of blocking all traffic, the kill switch only blocks specific apps you've added to a list. When the VPN drops, those apps lose network connectivity until the VPN returns; other apps keep working normally. This is useful for very specific scenarios — protecting a specific browser, IRC client, or BitTorrent client — but it's weaker as a general defense because it leaves a large attack surface (the system tray apps, background services, OS components, and the apps you forgot to add to the list).
3. Network-level firewall (always-on VPN)
On Android specifically, there's a stronger primitive than the kill switches that VPN apps implement themselves: the system-level "Always-on VPN" setting with "Block connections without VPN" enabled. This is the OS itself enforcing the rule — Android refuses to route any non-VPN traffic at all, regardless of which app is asking. Even if the VPN app crashes, the OS holds the line. This is the most robust kill-switch behavior available on mobile and it's strictly stronger than app-implemented kill switches.
How each kind actually works at the OS layer
The implementation details matter because they predict the failure modes. A firewall-based kill switch fails when the firewall API is buggy. An app-based kill switch fails when the app crashes. An OS-enforced always-on VPN fails essentially never, unless you reboot into safe mode.
iOS implementation — NetworkExtension and on-demand rules
iOS doesn't expose a literal "kill switch" API to third-party VPN apps. What it does expose is the NetworkExtension framework's "on-demand rules" mechanism: rules that say "whenever any app tries to make a network connection that doesn't match an exception, force the VPN to connect first." If the VPN can't establish, the connection request hangs. From the user's perspective, this behaves like a kill switch — but it's actually a "force VPN on" rule rather than a "block everything if VPN is down" rule. The functional outcome is similar; the implementation is different.
The NetworkExtension API also supports the includeAllNetworks flag (added in iOS 14) which makes the VPN a system-level network filter — even traffic from the kernel and system services is forced through the VPN. With that flag set, the VPN really does function as a full kill switch, with the OS guaranteeing that no traffic escapes outside the tunnel. Not every VPN vendor enables it; the flag has compatibility implications.
Android implementation — Always-on VPN + Block connections without VPN
Android's strongest kill-switch behavior is found in Settings, then Network & internet, then VPN, then the gear icon next to your VPN, then the two toggles: "Always-on VPN" and "Block connections without VPN." When both are on, the Android system itself — not the VPN app — refuses to route traffic until the VPN is connected. The VPN app can crash, be force-quit, or be uninstalled, and the rule persists. The official Android developer documentation describes the mechanism in detail. This is the gold standard for kill-switch behavior on consumer mobile devices.
macOS implementation — system network extensions
macOS 11 (Big Sur) and later run VPNs through the System Extension framework — the same architecture that supports content filters and system-level network filters. The kill switch is typically implemented as a packet-filter rule (pf) installed by the VPN client, combined with a network extension that holds the route table modification. When the VPN drops, the pf rule remains in place and continues to block traffic until the VPN re-establishes. If the VPN client itself crashes, behavior depends on whether the system extension is configured to remain loaded — well-designed clients keep the rules in place; poorly-designed clients drop them on crash and leak.
Windows implementation — Windows Filtering Platform
Windows VPNs typically implement the kill switch by installing Windows Filtering Platform (WFP) filter rules that block traffic on the physical adapter while allowing traffic on the virtual VPN adapter. The filters persist across VPN client process restarts (they're owned by the kernel filter layer, not the user-space app), so even if the VPN app crashes, the filter remains. The risk is that some VPN clients use lower-quality firewall rule strategies — e.g., manipulating Windows Defender Firewall through PowerShell or netsh — which can be bypassed by other firewall rules or by misconfiguration.
When kill switches fail — leak conditions to know about
A kill switch is not a perfect guarantee. There are well-documented conditions under which traffic can leak even with a kill switch enabled. Each VPN vendor handles these differently; some are addressed by careful implementation, others are unavoidable without OS-level cooperation.
DNS poisoning during the connection bootstrap
To connect to the VPN server, the VPN client first has to resolve the server's hostname. If the kill switch is enforcing "no traffic without VPN," but the VPN client itself needs to do a DNS lookup to find the VPN server, there has to be an exception — and that exception is a small leak surface. A malicious local network could poison the DNS response and redirect the VPN client to a fake server. Most clients handle this by using a hard-coded IP for the VPN server, or by pinning the TLS certificate so a redirected server doesn't validate. Cheap VPN clients sometimes skip this step.
IPv6 leaks
If your network has IPv6 connectivity but the VPN client's kill switch only blocks IPv4 traffic, your IPv6 traffic can flow out the bare interface even when the kill switch is "active." This is one of the most common real-world leak modes. The fix is for the VPN client to install matching IPv6 firewall rules. Many older clients don't. Always test for IPv6 leaks after enabling a kill switch by running a leak test.
Captive portals (Wi-Fi sign-in pages)
Coffee shops, airports, and hotels often require you to log in through a captive portal before you can reach the internet — including the VPN server. A strict kill switch will refuse to let you reach the captive portal because the captive portal isn't the VPN server. Most VPN clients have a "pause kill switch for captive portal" mode that you have to manually enable. While paused, you're unprotected, so don't browse anything sensitive until the kill switch is back on. The OS-native always-on VPN on Android handles this slightly more elegantly via the system captive portal detection, but the trade-off is the same.
App-suspend and background-restart races
On mobile, the OS may suspend the VPN app to save battery. When the app resumes, there's a small window where the tunnel is being re-established. If the kill switch is implemented at the OS level (via includeAllNetworks on iOS or always-on VPN on Android), there's no leak. If the kill switch is implemented purely in the app, there can be a brief window where the OS has resumed apps but the VPN hasn't reconnected, and apps making network calls during that window will leak.
Boot-time race
On desktop, the period between booting up and the VPN client starting is unprotected. Network-aware apps that auto-start (Mail, Slack, Steam, system update checks) often make connections before the VPN is up. A robust kill switch installs its firewall rule as a persistent boot-time rule so that even at boot, traffic is blocked until the VPN connects. Most consumer VPN clients don't do this; the rule only applies after the client starts.
Kill switch types compared
| Type | What it blocks | OS support | Common failure modes |
|---|---|---|---|
| System-wide firewall | All non-VPN traffic at the kernel level | macOS, Windows, Linux; iOS via includeAllNetworks | IPv6 leaks if rules are IPv4-only; boot-time race; DNS bootstrap exception |
| App-level (per-app block list) | Only listed apps' traffic | Windows, some macOS clients | Apps not on the list keep leaking; OS components leak; system services leak |
| OS-enforced always-on VPN | All traffic at the OS level, regardless of app crash | Android (Always-on VPN + Block without VPN), iOS (NetworkExtension on-demand) | Captive portal sign-in is blocked until you pause; very few other failure modes |
| Application-monitor (the weak form) | Nothing directly; just closes specified apps when VPN drops | Some Windows clients still ship this | Race between detection and closure leaks; not really a kill switch |
What "always-on VPN" really gives you that an app-level kill switch doesn't
The most important distinction in 2026 is between vendor-implemented kill switches and OS-enforced always-on VPN. Here's why the OS-enforced version is meaningfully stronger:
- Survives VPN app crashes. If the VPN app crashes for any reason, an app-level kill switch dies with it. The firewall rule it installed may or may not persist depending on implementation. An OS-enforced rule is held by the OS itself and continues to apply.
- Survives reboots. Many app-level kill switches install rules at app launch and tear them down at app exit, leaving a gap at boot. OS-level always-on settings are honored from the first network packet the OS routes after boot.
- Covers system services. Cloud sync, OS update checks, push notification daemons, and other OS-level services don't go through normal VPN client routing. OS-enforced always-on covers them; an app-level kill switch may not.
- Cannot be bypassed by user mistake. An app-level kill switch has a toggle in the app's UI. A user (or another app with permissions) can disable it. OS-level always-on is in system settings and is harder to flip accidentally.
On Android, prefer the OS-enforced version: turn on "Always-on VPN" and "Block connections without VPN" in system settings, and treat the VPN client's own kill switch as a supplement. On iOS, look for VPN clients that opt into includeAllNetworks; that's the equivalent flag and it provides similar guarantees.
What Casper does — the honest answer
Casper's Cloak uses an OS-integrated kill switch on each platform — includeAllNetworks on iOS so the OS itself enforces the no-leak rule, the always-on VPN settings on Android, and packet-filter rules at the kernel layer on macOS. The behavior is the same across all three: when the tunnel drops, all traffic stops, including IPv6 and including OS-level services. When the tunnel comes back, traffic resumes. There's no toggle to forget, no per-app list to maintain, no IPv6 carve-out.
We pair this with threat protection and threat shield for active filtering against known-malicious domains, so the tunnel isn't just a routing layer — it's actively rejecting connections to phishing, malware C2, and known-bad infrastructure. The kill switch is the bottom-layer guarantee that nothing bypasses the filtering when the tunnel briefly drops. The combined effect: even on hostile networks like those covered in our public Wi-Fi attacks writeup, you don't get the "two seconds of plaintext" window that an app-level-only kill switch leaves open.
Our position on kill switches generally: it's a baseline expectation, not a premium feature. Any consumer VPN that doesn't offer one in 2026 is missing a basic safety mechanism. For the threat-modeling background on why this matters at the system level, the NSA's guidance on selecting and hardening remote-access VPNs covers the architectural reasoning in detail, with a recommendation in favor of full-tunnel architectures backed by kernel-level enforcement.
Bottom line
"Does this VPN have a kill switch" is the wrong question. The right questions are: where in the stack is the kill switch enforced (app, system, or OS), does it cover IPv6, does it persist across app crashes and reboots, and is it on by default. If the answers are "OS level," "yes," "yes," and "yes," the kill switch is doing its job. If the answers are "app level only," "no," "depends," and "off by default," you have a kill switch in name but not in protection.
The simple practice: on Android, turn on system-level always-on VPN with "Block connections without VPN." On iOS, use a VPN client that enables includeAllNetworks. On desktop, verify after install by running a leak test, then briefly disconnect the VPN server side (or pull your network cable) and confirm that traffic actually stops. If the leak test still shows your real IP, the kill switch isn't working as advertised — investigate before you trust it.