Fexyn
Fexyn
All posts

What a VPN kill switch actually does (and why most are useless)

Fexyn Team··6 min read
kill switchvpnprivacywindows

A VPN kill switch is a feature that blocks all internet traffic when the VPN connection drops, so your real IP doesn't leak while the client is reconnecting. Every VPN claims to have one. Most are useless.

The problem is where the kill switch lives. If it lives in the VPN app itself, it can only react after the app notices the drop. That's userland code, racing against an OS that already routed your packets.

The 200ms gap nobody talks about

Here's what happens when a VPN tunnel goes down without a kernel-level kill switch:

  1. The remote endpoint stops responding. Maybe a server reboots, maybe the network changed, maybe a routing flap.
  2. Your client doesn't notice for somewhere between 200ms and several seconds. Most clients use a heartbeat-style health check. WireGuard pings every 25 seconds by default. OpenVPN's keepalive is configurable but commonly 10–60 seconds.
  3. During that gap, your operating system still thinks the tunnel is up. It keeps routing traffic to the tunnel interface.
  4. The tunnel interface drops the packets — but in some configurations, fallback routing kicks in and the packets exit your real interface. Your browser keeps sending requests, your email client keeps polling, your IM clients keep their TCP sessions alive.
  5. The destination servers log your real IP. The streaming service updates its session record. Your ISP sees the cleartext DNS query that the in-tunnel resolver was supposed to handle — see what is a DNS leak for the broader category of failures here.

By the time the VPN client wakes up and triggers its userland kill switch, the leak has already happened.

This is most VPN kill switches. They activate after the fact.

Where a real kill switch lives

A kernel-level kill switch sits in the operating system's network stack, not in the VPN client process. On Windows, that's Windows Filtering Platform — the same firewall API Windows Defender uses. On macOS, it's the Network Extension framework. On Linux, it's nftables / iptables rules with PF_INET hooks.

Three properties make it work:

It engages before the VPN handshake completes. When you click Connect, the kill switch installs its filters first. The handshake happens through a hole the kill switch carves out for the specific VPN endpoint. If the handshake fails, no traffic ever leaves.

It survives client crashes. If the VPN app process dies, the kill switch keeps blocking. Userland kill switches die with their app — and Windows happily restores normal routing the moment the app exits.

It survives network changes, sleep, and resume. Going from Wi-Fi to ethernet, lid-close, hibernate, hotspot switching — all of these are events that an in-app kill switch sees as separate state changes to handle. WFP rules are below all of that. They just stay in place until a privileged process explicitly removes them.

How Fexyn implements it

Fexyn's Windows client splits into two pieces: a user-rights UI and a SYSTEM-level helper service. The helper service is the only thing that owns the WFP filters. When you click Connect:

  1. The helper service installs WFP filters that block all outbound traffic except (a) loopback, (b) the specific VPN endpoint:port, and (c) DHCP/DNS to your local gateway for handshake purposes.
  2. The VPN handshake runs through that carved-out hole.
  3. Once the tunnel is up, the routing table sends everything through the tunnel interface. The WFP filters stay in place; they just don't see most traffic anymore because the tunnel is now the path of least resistance.
  4. If the tunnel drops, the routing table loses the tunnel route. Traffic falls back to the default interface. The WFP filters block it. Your browser shows a "no internet" error. Your real IP stays hidden.
  5. When the helper successfully reconnects, the new tunnel endpoint may differ. The helper updates the carve-out and traffic flows again.

The user never disables anything. The UI never asks for admin. The kill switch never depends on the UI being alive.

What this looks like in practice

Open Wireshark and put your laptop into a forced VPN drop (pull the network, switch Wi-Fi networks, suspend and resume). With a userland kill switch you'll see packets continue to flow on the underlying interface for some window after the drop — usually 200ms to a few seconds. With a WFP-based kill switch you'll see nothing until either the tunnel reconnects or you explicitly disable the kill switch.

The latter is what you want.

Things "kill switch" is not

Kill switches solve one specific problem: traffic leaks during a tunnel transition. They don't:

  • Protect a compromised endpoint. If your laptop is infected, the malware sees your traffic before the kernel does.
  • Stop DNS leaks on their own. DNS leak prevention is a separate layer (NRPT rules on Windows, force-DNS-through-tunnel config in the protocol). A kill switch alone won't fix a misconfigured DNS path.
  • Prevent WebRTC leaks. Browser WebRTC operates above the network layer; the browser knows your real IP regardless of what the network sees. Different fix entirely.

What to look for

If you're evaluating a VPN's kill switch, the questions are:

  1. Does it engage before the handshake completes, or only after?
  2. Does it survive the VPN client crashing?
  3. Is it a kernel-level firewall rule, or a userland reconnect loop?
  4. Does it allow loopback so your local dev servers keep working?

Honest answers usually appear in product documentation rather than marketing copy. The marketing copy will always say "kill switch" without specifying what kind.

For Fexyn:

  • WFP-based, kernel level
  • Engages before handshake
  • Survives helper-service crash, sleep, resume, network change
  • Allows loopback (127.0.0.0/8 and ::1) and link-local

Try Fexyn free for 7 days. The kill switch is on by default; you don't have to enable it.

What a VPN kill switch actually does (and why most are useless) | Fexyn VPN