Why VPN Tunnels Drop
VPN disconnections happen more often than most users realize:
- Network changes: Switching from Wi-Fi to Ethernet, moving between access points, or joining a new network causes the tunnel to drop and re-establish.
- Sleep/wake cycles: When a laptop sleeps, the VPN connection is terminated. On wake, the OS reconnects to the network before the VPN client has re-established the tunnel — a window of exposed traffic.
- Server-side restarts: VPN providers perform rolling restarts during maintenance. Connections to that server drop momentarily.
- Protocol timeouts: Packet loss or unstable connections cause OpenVPN or WireGuard to time out, dropping the tunnel and triggering a reconnect sequence.
The gap between tunnel drop and reconnect is typically 2–15 seconds. During that window, without a kill switch, any active application — a torrent client, a browser making background requests, an email client — sends traffic directly from the real IP.
How a Kill Switch Works
A kill switch is implemented as a firewall rule set that is activated when the VPN tunnel interface goes down. The implementation varies by approach:
Application-level kill switch: The VPN client monitors the tunnel state and adds firewall rules blocking all outbound traffic when the tunnel drops. Simpler to implement but depends on the VPN client remaining responsive. If the VPN client crashes, the firewall rules may not be applied in time.
System firewall-level kill switch (persistent rules): Firewall rules are configured to allow outbound traffic only through the VPN tunnel interface, not through physical interfaces. These rules persist regardless of VPN client state. If the tunnel interface doesn't exist, traffic is blocked by default. This is the most robust approach — used by implementations like NordVPN's "Always-on VPN" and mullvad-vpn on Linux.
Routing-table kill switch: The VPN client removes default routes and installs a more-specific route via the tunnel. When the tunnel drops, there are no routes for traffic to follow and connections fail. Less reliable than explicit firewall rules because route changes can be overridden by DHCP or network manager events.
System Kill Switch vs App-Level Kill Switch
| Type | What It Blocks | Reliability | Flexibility |
|---|---|---|---|
| System-level | All traffic from all apps | High — OS firewall rules | Low — everything blocked |
| App-level (per-app) | Only selected apps | Medium — app must catch the event | High — other apps continue |
| Router-level | All devices on network | High — hardware-enforced | Low — entire network affected |
Kill Switch and IPv6
A kill switch that only blocks IPv4 non-tunnel traffic leaves IPv6 connections open to the physical interface. For a kill switch to be complete, it must also block IPv6 traffic through any interface other than the VPN tunnel. Check your VPN provider's documentation explicitly — many providers document whether their kill switch covers IPv6. If yours does not, disable IPv6 at the OS level as a complementary measure.
When You Need a Kill Switch
A kill switch is important when privacy continuity matters — not just when a VPN is active. It's essential for: journalists and activists protecting their identity, torrenting (IP exposure during a drop triggers DMCA notices), always-on privacy users who need uninterrupted masking, and any situation where a momentary real-IP exposure has significant consequences.
For casual geo-unblocking or public Wi-Fi encryption, a kill switch is less critical — a few-second gap is generally not meaningful in those use cases.
Frequently Asked Questions
Will the kill switch disconnect me from the internet completely?
Yes — that is the intended behavior. When the VPN tunnel drops, the kill switch blocks all traffic until the tunnel is restored, typically 2–10 seconds for most providers. During that window, no real IP is exposed and no traffic reaches the internet. If the VPN cannot reconnect, traffic stays blocked until you manually intervene.
Does a kill switch protect against WebRTC and IPv6 leaks?
Not necessarily. A kill switch addresses the disconnection scenario — leaks while the tunnel is down. WebRTC leaks happen while the VPN is connected, via browser-level IP enumeration. IPv6 leaks happen when only IPv4 is tunneled and IPv6 exits via the real interface — also while connected. A thorough kill switch blocking all non-tunnel traffic including IPv6 helps with IPv6 leaks, but WebRTC always requires a separate browser-level fix.