Why a kill switch drops traffic when you switch servers

You pick a server that looks closer, hit connect, and the browser stops loading before the new tunnel is up. The icon flips to a connecting state and sits there while every tab times out. That pause is usually the kill switch working as designed: traffic is blocked while the client has no tunnel to send it through. Whether the pause is acceptable depends on what the client does in those seconds, and whether the block is lifted when it says it is.

What the client does between two servers

An endpoint switch is several steps, not one toggle. The client tears down the current tunnel, updates its blocking rules, resolves and reaches the new endpoint outside the tunnel, then installs the new routes and lifts the block. The gap you feel lives between the first step and the last.

Order matters more than speed here. If the block rules go in before the exception for the new endpoint, the client cannot complete the handshake and the client stays on connecting until a timeout. If the exception is a copy of the old server's address, the new handshake looks like any other outbound packet and gets dropped. Both cases look identical from the browser, which is why a switch that recovers after six seconds and one that never recovers can share a cause.

The new endpoint needs a hole in the block

To build the tunnel, the client must send packets to the new server's address and port on the physical interface, for example UDP 51820 for a typical WireGuard profile or 1194 and 443 for OpenVPN, whatever your own profile specifies. That traffic is not inside the tunnel it is about to create, so a whole-device block swallows it unless a matching permit rule exists.

Hostname-based profiles add a second requirement: the lookup itself. If the client resolves the endpoint before the block goes up, it can use a cached address, but once the profile rotates addresses or the cached entry goes stale, the handshake heads for an address the permit rule does not cover. IPv6 makes this visible, because a dual-stack endpoint can publish both an A and an AAAA record, and an allow rule that covers only the v4 address leaves the client retrying against a v6 address that is blocked.

Option names and defaults differ by client and version, so read the documented list for yours instead of guessing from screenshots. The OpenVPN Connect settings reference at openvpn.net/connect-docs/app-settings-windows is one example of how a client describes its block and split-tunnel options.

Fail-closed is a state machine, not a switch

Most clients express the block as firewall policy in three states: tunnel up, with traffic going through the tunnel and no block; tunnel down, with the block active; and transitioning, with the block active plus temporary exceptions for the endpoint. The third state is where bugs live, because it has to change twice within a couple of seconds, and failing to leave it looks exactly like a permanent block.

The mechanism differs by platform, and so does the failure. Windows Filtering Platform filters carry weights, so a block filter that outranks your permit keeps dropping packets even though the permit exists, and filters left behind by a killed client process can keep the machine offline after the app is gone. macOS clients usually write pf rules into an anchor, where rule order and quick decisions decide which rule applies. Linux clients commonly manage an nftables or iptables chain with a drop policy and explicit accepts for the endpoint, the tunnel interface and loopback. Android's always-on VPN with block connections without VPN is the strictest of the group, because the OS applies the block device-wide rather than per app.

WireGuard needs its own note, because AllowedIPs is a routing selector, not a blocker. It decides which destinations go into the tunnel; it does nothing to stop a packet that has no tunnel yet from leaving over Wi-Fi. In a WireGuard-only setup with no firewall rule, the kill switch is really the absence of a route, and a dropped handshake can be followed by a real packet leaving over the physical interface.

Measure the gap instead of watching the icon

Watch packets, not the status light. On Linux, start a slow ping against a public address in one terminal and capture the tunnel's transport port on the physical interface in another:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Switch servers in the client while both run. Three things matter: how long the pings stop, whether the capture shows the handshake reaching the new endpoint, and whether traffic resumes before or after the client's state changes to connected. If the ping gap ends first, either the block is lifted early or the tunnel is up before the indicator admits it. If the gap ends later, the indicator is optimistic.

On Windows, netsh wfp show state writes a snapshot you can search for block filters that are still present while the client claims to be disconnected. On macOS, sudo pfctl -sr lists the loaded rules and their order. Pair either snapshot with the client's own log; the timeline from your ping tells you whether the block ended late or never ended.

Normal blackout versus a stuck block

Some interruption is the point of the feature, so triage before you change any setting:

If you land in the second or fifth row, do not disable the kill switch to test, because that converts a routing bug into a leak. Restart the client's service, or reboot where filters survive a process kill, then see whether the block clears. If it does, the fault is cleanup during the switch rather than the block itself.

Before your next switch, confirm four things: the endpoint permit covers every address family your profile resolves to, the client log shows the transition completing, your ping test measures the gap rather than the icon, and quitting the client restores normal connectivity. A kill switch that holds during the switch and releases afterwards is doing its job. One that releases early, or never, is worth debugging.