Security

How the Fexyn kill switch works

Technical explanation. Where Fexyn's kill switch sits in the network stack and why that matters.

What it does

The kill switch blocks all internet traffic when the VPN connection isn't fully established. If the tunnel drops mid-session, the kill switch holds traffic until the tunnel comes back. Your browser shows a "no internet" error rather than silently leaking your real IP.

The whole point: prevent the 200ms-to-several-seconds window between a tunnel drop and a userland reconnect from leaking your traffic out the underlying interface.

Where it lives — Windows Filtering Platform

Fexyn's kill switch is implemented as Windows Filtering Platform filters, installed by the SYSTEM- level helper service. WFP is the same kernel-level firewall API that Windows Defender Firewall uses. It operates below the transport layer — packets get filtered before any application sees them.

Three properties make this matter:

It's kernel-level. The filters apply to every packet your machine tries to send, regardless of which application sent it. There's no userland race condition; no app can "sneak past" while the VPN is reconnecting.
It survives client crashes. If the Fexyn UI crashes, or even if the helper service crashes, the WFP filters stay in place until something privileged explicitly removes them. Userland kill switches die with their app.
It survives sleep, hibernate, and network changes. Going from Wi-Fi to ethernet, lid-close, hotspot switching — all events a userland kill switch has to handle as separate state transitions. WFP rules are below all of that.

The activation sequence

When you click Connect:

The helper service installs WFP filters that block all outbound traffic except (a) loopback, (b) the specific VPN endpoint and port, and (c) DHCP/ARP for handshake purposes.
The VPN handshake runs through the carved-out hole to the endpoint. If the handshake fails, no other traffic ever leaves.
Once the tunnel is up, the routing table sends everything through the tunnel interface. The WFP filters stay in place but no longer see most traffic — the tunnel is now the path of least resistance.
If the tunnel drops, the routing table loses the tunnel route. Traffic falls back to the default interface, where the WFP filters block it. Your browser shows an error; your IP stays hidden.
When the helper reconnects, the new tunnel may point at a different endpoint. The helper updates the carve-out to match.

How this differs from app-level kill switches

Most VPN clients ship an "app-level" kill switch — a feature that monitors the connection and, when it detects a drop, instructs the OS to drop traffic. The flow:

The tunnel goes down.
The VPN client's health check eventually notices — somewhere between 200ms and several seconds later.
The client tells the OS to drop traffic.
Between step 1 and step 3, the OS happily continues sending packets out the underlying interface. Your real IP is exposed.

A WFP-based kill switch eliminates the gap. The filters were already in place before the tunnel went up. When the tunnel goes down, traffic immediately fails at the firewall layer because the underlying interface isn't whitelisted to the broader internet — only to the specific VPN endpoint.

What it allows

The filters are restrictive but not paranoid:

Loopback (127.0.0.0/8 and ::1) — your local dev server, local databases, anything bound to localhost keeps working.
Link-local — Docker bridge networks, local Kubernetes setups, LAN-only services.
VPN endpoint — the specific server:port the tunnel connects to.
Handshake-essential traffic — DHCP for getting an IP on the local network, ARP for finding the gateway. These are required for any network connectivity.

IPv6 is null-routed when the VPN is active, so IPv6 traffic doesn't leak around the IPv4 tunnel.

When the kill switch isn't enough

The kill switch protects against tunnel-drop leaks at the network layer. It doesn't protect against:

A compromised endpoint. Malware on your machine sees traffic before the kernel does.
DNS leaks within the tunnel. If DNS isn't configured to go through the tunnel, queries can leak to your ISP even with the kill switch active. Fexyn addresses this with NRPT rules. See [the DNS leak guide](/support/troubleshooting/dns-leak).
WebRTC leaks. Browser-level. The browser knows your real IP regardless of what the network sees. See [the WebRTC guide](/support/troubleshooting/webrtc-leak).
User error. If you disable the kill switch in settings, the kill switch isn't active. The default is on.