Fail-Open vs Fail-Closed: What a VPN Kill Switch Decides
Both terms describe what happens when the tunnel is gone, not how strong the encryption is. The scope you choose decides whether traffic really leaks.
The myth is that fail-closed is the secure setting and fail-open is the careless one. Both describe what happens to traffic once the tunnel is gone, and neither changes how well that tunnel encrypts. A fail-closed policy with a wide exception list can leak more than a fail-open policy on a device that never leaves the office network. Choose the outcome you can explain to the person who owns the traffic.
The label describes an outcome, not a strength
The vocabulary comes from control systems: fail-open permits operation when a component fails, fail-closed denies it. Applied to a VPN, the failing component is the tunnel, and the question is whether the traffic is allowed to continue by some other path. Cipher choice, key length and protocol are separate decisions.
The confusion survives because a kill switch sounds like a security feature, and vendors market it as one. Mechanically it is a routing and firewall rule that blocks traffic the tunnel was supposed to carry, implemented in the client, in the operating system, or on the gateway. Whichever layer enforces it also defines its coverage, and a rule in one layer does not cover another. A gateway rule cannot protect a laptop that has already moved to a different network.
What each outcome looks like
The same policy can behave very differently depending on which failure you hit, so compare the events rather than the labels.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
The last row is the one that catches people who assume a kill switch is a single switch. A rule written for the IPv4 route table leaves the IPv6 default route untouched, and the application may happily use it.
Scope decides whether it leaks
Ask what the policy covers before asking which mode it is. A per-application rule protects one app and nothing else, a device-wide rule protects everything except the exceptions, and a gateway rule protects only traffic that reaches that gateway. DNS needs its own decision, because a query sent to a local resolver can reveal names even when the payload is blocked.
Local-network exceptions exist for printers, casting and captive portals, and each one is a hole in the block. Document them next to the policy, because the person who inherits the configuration will otherwise read fail-closed as absolute.
Reconnecting and blocking are also separate controls. A client can reconnect automatically without ever blocking, or block without reconnecting, and the combination determines what a user experiences during an outage.
Prove it during a transition
Testing the steady state proves nothing. Drop the tunnel deliberately and try the application that is supposed to be protected, then check whether it reached the network. Compare the client's indicator with the result, because an indicator that still says connected is exactly the case the policy exists for. If the protected application succeeds, the mode's name does not matter; you have a leak.
Repeat from a cold boot before sign-in, across a Wi-Fi to cellular switch, and with the protected app in the background. If the block is enforced by the client process, also test what happens when that process is killed rather than closed cleanly.
Finally, check the cleanup path. If a client is uninstalled while its rules are active, use the vendor's documented removal procedure instead of disabling the operating-system firewall, which removes unrelated protection without answering who owns the leftover rule.