What happens when your VPN disconnects? Kill switch.

A VPN kill switch's job is simple to describe: when the VPN connection drops, prevent traffic from leaking out of the tunnel. The implementations across VPN providers vary widely, and the differences matter. A kill switch with a multi-second leak window during a VPN drop defeats the entire purpose of having a kill switch.

This is the technical version. What kill switches actually do, the two main implementation patterns, why kernel-level matters, and how to test that yours works.

What "kill switch" actually means

When your VPN client establishes a tunnel, your traffic goes through it. When the tunnel breaks — server failure, network change, sleep/wake cycle, protocol-level interruption — the question is what happens to traffic during the break.

Three possible behaviours:

Traffic continues over your real connection. Your real IP becomes visible to destinations. The encryption that was supposed to be on is off. Anyone watching the network sees what you are doing. This is what happens with no kill switch at all.
Application-level kill switch detects the drop and stops traffic. The VPN client's daemon notices the tunnel is down, then takes action to block traffic. The detection has latency (the daemon polls; the network stack reports drops with delay; the action takes time to apply). The leak window is typically 1-30 seconds.
Kernel-level kill switch blocks all traffic except VPN tunnel from the start. Firewall rules at the OS kernel level block everything that is not in the VPN tunnel. When the VPN drops, the rules are still there blocking everything; new traffic cannot exit until the VPN reconnects. There is no detection latency because there is nothing to detect — the rules block by default and only allow VPN traffic.

Most VPN providers implement something. The question is which.

How VPN connections drop

Worth understanding because it shapes what the kill switch has to handle. Drops happen for various reasons:

Server-side failures. The VPN server crashes, restarts, or has its network interface flap. Recovery: client reconnects, possibly to a different server.

Network changes on the client. Switching from Wi-Fi to Ethernet. Switching Wi-Fi networks. Sleeping the laptop and waking it. The VPN tunnel breaks because the underlying network changes; the client has to re-establish.

Protocol-level issues. WireGuard handshake timeout (the peer does not respond within 90 seconds of the last handshake). OpenVPN keep-alive failure. VLESS Reality TLS session timeout.

Active interference. A network operator or DPI system blocks the VPN connection mid-session. The connection drops and the client cannot re-establish until the network changes or the protocol switches.

Client crashes. The VPN client process dies for any reason.

Boot / shutdown windows. The system has network access before the VPN client starts (boot) and after the VPN client shuts down (shutdown). During these windows, traffic can leak even if the kill switch is otherwise solid.

A complete kill switch handles all of these. An application-level implementation handles them with detection latency at each event. A kernel-level implementation handles them by default-blocking everything not in the tunnel.

Application-level kill switch: how it works

Most VPN clients implement this:

The client establishes the tunnel.
The client polls the tunnel state on a timer (typically 1-5 second interval).
When the poll detects a dropped tunnel, the client tells the OS to stop traffic — usually by changing the routing table or by issuing system calls to block specific connections.
When the tunnel reconnects, the client undoes the block.

The leak windows:

Between drop and detection. If the poll interval is 5 seconds, the leak window can be up to 5 seconds.
Between detection and action. OS calls take time. Routing table changes propagate. The system has time to send packets out the wrong interface during this gap.
Between client crash and OS-level recovery. If the VPN client process dies, the OS has nothing telling it to block traffic. Without other guarantees, traffic flows freely until the client restarts and re-establishes the kill switch.
At boot before the client starts. Same issue: traffic can flow freely before the VPN client is up.

Some applications-level implementations are more robust than others — they crash-recover cleanly, they apply blocks at the network adapter level rather than at the routing table, they integrate with the OS's network-state notifications. NordVPN's kill switch, ExpressVPN's Network Lock, Surfshark's kill switch all have varying degrees of sophistication. None of them are kernel-level filter-based across all platforms.

Kernel-level kill switch: how it works

A different approach: install firewall rules at the OS kernel level that block all traffic except traffic to the VPN endpoint and traffic in the VPN tunnel. The rules are persistent across client crashes, reboots, sleep/wake.

On Windows, this means Windows Filtering Platform (WFP) filters. WFP is the kernel-level packet-filtering subsystem Windows uses for its built-in firewall and for third-party security products. Filters at the WFP layer apply to every packet that enters or leaves the network stack, regardless of which application sends them.

On macOS, the equivalent is pf (packet filter) rules.

On Linux, iptables or nftables rules at the kernel level.

The pattern across all three:

The VPN client (or its installer) registers kernel-level rules that block all traffic except:
- Traffic to the VPN provider's server endpoints (for the VPN to be able to connect)
- Traffic in the VPN tunnel (for actual user traffic to flow)
The rules persist across client crashes, reboots, sleep/wake.
When the VPN client establishes a tunnel, traffic flows. When the tunnel drops, traffic stops because the rules still block everything not in the tunnel.
There is no detection-and-action gap because there is nothing to detect — the default state is "blocked except for tunnel."

Fexyn's kill switch on Windows is WFP-based. The WFP filter rules are installed by the helper service (a SYSTEM-privileged service that has the rights to install kernel-level filters) and persist across boots. When the user starts the VPN client, the helper service brings up the tunnel and traffic flows. When the tunnel drops, the WFP rules still block everything; no traffic exits until the tunnel comes back.

Boot-time persistence

The harder problem: what happens during boot, before the VPN client has started?

Without boot-time persistence, the system has internet access during boot (for connecting to corporate networks, downloading Windows updates, syncing time with NTP servers) before the VPN client comes up. During this window, anything that is auto-launched on boot can communicate over the unencrypted connection.

Boot-time persistent kill switches install WFP rules that survive reboots. The rules block all traffic during boot until the VPN client comes up and brings up the tunnel. The VPN client at start-up signals the WFP rules to allow tunnel traffic; until that signal, the system has no internet access.

This is more aggressive than what most users want — your laptop genuinely cannot reach the internet during boot until the VPN is up. But for users with strong privacy requirements (journalists, activists, certain corporate users), boot-time persistence is the only way to prevent boot-window leaks.

Fexyn supports boot-time persistence as a configurable option. Default is off (because it confuses new users when their laptop seems "broken" at boot before they realise the VPN has not started yet). Enabling it is one toggle in app settings.

How to test your kill switch

The honest test:

Start your VPN. Verify it is connected (check IP at ipleak.net or a similar service — should show the VPN exit IP).
Open a torrent client or any application that sends continuous traffic. Note your real IP at ipleak.net.
Disable your network adapter (or unplug Ethernet, or turn off Wi-Fi). The VPN connection drops because the network is gone.
Wait 30 seconds. The VPN's reconnection attempts will fail because the network is gone.
Re-enable your network adapter. Note what happens.

What you want to see: traffic does not start flowing immediately when the network comes back. Traffic only starts flowing once the VPN has reconnected. Run ipleak.net again — the IP shown should be the VPN exit, not your real IP.

What you do not want to see: traffic flows immediately when the network comes back, your real IP is visible at ipleak.net, the VPN reconnects in the background but only after some traffic has already exited.

A kernel-level kill switch passes this test. An application-level kill switch with a fast detection loop usually passes. An application-level kill switch with a slow detection loop fails.

Why this matters for specific use cases

For most users — casual privacy, occasional public-Wi-Fi work, geo-bypass for streaming — application-level kill switches are usually fine. The leak windows are seconds, not minutes; the traffic that leaks is unlikely to be sensitive enough to matter.

For specific use cases, kernel-level matters more:

Torrenting. A torrent client running for hours can experience VPN drops without the user noticing. A real IP appearing in swarm logs for even a few seconds is enough for rights-holder agents to log it. Kernel-level kill switches prevent the leak.

Journalism, activism, dissident work. Communications that need confidentiality for safety reasons cannot tolerate even short leaks. Kernel-level + boot-time persistence is the right configuration.

Compliance-driven use (HIPAA, ABA 477R). A VPN dropping mid-session and exposing client data over an unencrypted connection is the compliance posture you are trying to prevent. Kernel-level kill switch is the technical control that makes the compliance claim defensible.

Corporate environments. Kill switches that survive sleep/wake cycles matter for laptops that go in and out of bags during travel.

Which providers use which

The picture in 2026:

Fexyn: WFP-based kernel-level on Windows (production) and Android (shipped); macOS, Linux, and iOS clients are coming soon
Mullvad: kernel-level on Windows, macOS, Linux. Among the most robust kill switch implementations available.
NordVPN: application-level on most platforms with various improvements; kernel-level features in their newer Windows client. Variable depending on version.
ExpressVPN's Network Lock: application-level with proprietary implementation; functionally robust on Windows and macOS but not strictly kernel-level filter-based
Surfshark: application-level kill switch
ProtonVPN: kernel-level on most platforms
IVPN: kernel-level on most platforms
AirVPN: kernel-level

The pattern: providers focused on technical privacy (Mullvad, ProtonVPN, IVPN, AirVPN, Fexyn) tend toward kernel-level. Providers focused on broad consumer market (NordVPN, ExpressVPN, Surfshark) historically used application-level with improvements over time.

Frequently asked

Does my VPN have a kill switch?

Almost every reputable VPN claims to have one. Whether it actually works the way you need it to is a question to verify, not assume. The test described above (disable network mid-session, watch what happens when the network comes back) is the practical answer.

Why doesn't every VPN use kernel-level kill switches?

Implementation cost. Kernel-level requires platform-specific code: WFP filters on Windows, pf rules on macOS, kernel networking integration on Linux. Each platform requires separate engineering. Application-level implementations work on every platform with the same code. For VPN providers serving broad consumer markets, the engineering investment in kernel-level has not historically been the priority.

Will boot-time persistence break my computer?

It will prevent your computer from reaching the internet during boot until the VPN starts. For most users this is annoying but not broken — the VPN starts, the system reaches the internet. For users on corporate networks where boot processes need internet access (joining corporate domains, syncing with corporate time servers, downloading updates from internal mirrors), boot-time persistence may interfere. Test before enabling.

What about kill switch for specific apps only?

Some VPN clients let you configure the kill switch to apply to specific apps rather than all traffic. Useful when you want some traffic to go through the VPN with kill-switch protection (work apps) and other traffic to go around the VPN (streaming). Fexyn does not currently support per-app kill switch; we ship the all-or-nothing approach. Mullvad and ProtonVPN have more granular per-app options.

Can I trust a "kill switch" that I cannot test?

Test it. The cost of testing is minutes; the cost of a kill switch that does not actually work is whatever the leaking traffic exposed. Any kill switch that cannot be tested by the user is a marketing claim, not a verified feature.

Try Fexyn free for 7 days — WFP-based kernel-level kill switch on Windows, with optional boot-time persistence. VPN for torrenting and VPN for lawyers cover the use cases where this matters most.

Last reviewed 2026-05-09.