VPN kill switch and always-on: stopping leaks on reconnect

A kill switch blocks all network traffic whenever the VPN tunnel is not up, so nothing leaks out of your normal connection while the VPN is starting, reconnecting or has crashed. Always-on is the other half: it starts the VPN at boot and brings it back after every network change without you touching anything. Android has both built in, under the VPN settings: Always-on VPN and Block connections without VPN. On Windows and macOS there is no system-wide switch, so it depends entirely on the client - WireGuard's Windows app has one, many others do not - or on firewall rules you write yourself. iOS sits in between. Whatever you use, test it by pulling the connection out from under the VPN and watching what gets through.

The reason this matters is timing. A leak test run while everything is calm shows a perfect result; the leaks happen in the seconds after you wake a laptop, walk from wifi onto mobile data, or the server restarts.

When traffic slips out#

A VPN client is a program, and there are moments when it is not running or not connected while your device is very much online.

In each case the exposure is short - seconds, sometimes a minute - but it is exactly when mail clients, messengers, cloud sync and update checkers fire their first requests, and those requests reveal your real address and your DNS to the local network. If the reason you use a VPN is a network you do not trust, these are the seconds that matter. VPN on public wifi explains what the local network sees in that window.

Android: Always-on VPN and block connections without VPN#

Android has handled this properly since Android 8. Any VPN app built on the system's VPN service can be made always-on, and the system itself enforces the block.

On a Pixel and stock Android: Settings, Network and internet, VPN, then the gear icon next to the VPN app. On Samsung phones the VPN list is under Settings, Connections, More connection settings, VPN. Other manufacturers move it; searching settings for "VPN" finds it.

Two switches:

• Always-on VPN - Android starts the VPN at boot and restarts it if it stops. Only one app can be always-on.
• Block connections without VPN - the lockdown mode. While the VPN is not connected, apps get no network at all.

With both on, an app cannot send anything outside the tunnel at boot, during a network change or after a crash; it simply waits. That is what a kill switch should be.

VLESS clients such as v2rayNG and Hiddify work with this when they run in VPN mode, because in that mode they are ordinary Android VPN apps. In proxy-only mode they are not, and the always-on settings do not apply to them.

Three caveats:

1. Captive portals stop working. With lockdown on, the hotel login page cannot load, so the VPN can never connect. Turn off the block, get through the portal, connect, and turn it back on.
2. One VPN at a time. An always-on VPN can be replaced by turning on another VPN app, and a firewall or ad-blocking app that works as a local VPN will conflict with it.
3. Android itself sends a little outside the tunnel. Researchers have shown that, even in lockdown mode, Android sends some of its own traffic - such as connectivity checks - outside the VPN. Google treats this as intended. For most people this is a few requests to Google's servers; if your threat model cannot accept any traffic outside the tunnel, know that it exists.

Windows: it depends on the client#

Windows has no built-in VPN kill switch for third-party clients. The protection has to come from the client, usually by adding Windows Filtering Platform rules that block traffic outside the tunnel.

Two things to know whichever client you use:

• Proxy mode is not a VPN. A client running as a system proxy cannot block anything; applications that ignore the proxy go direct whether the client is running or not. For a kill switch you need the client's VPN or TUN mode.
• A kill switch can outlive the client. Firewall rules that block traffic outside the tunnel are sometimes left in place after a crash, leaving you with no internet. That is the switch doing its job; restarting the client, or its documented reset, clears it.

The more robust do-it-yourself option is Windows Defender Firewall: default-deny outbound, then allow the VPN client's connection to the server's address and port and allow everything on the VPN adapter. It works, it survives a client crash, and it is easy to lock yourself out with, so try it on a machine you can reach physically.

macOS and iOS#

macOS has no system kill switch either. Some clients implement one with the macOS packet filter (pf); many simply do not. The same proxy-versus-VPN distinction applies: a client running as a system proxy protects only applications that honour the proxy.

iOS gives VPN apps on-demand rules that reconnect the VPN automatically when the device joins a network, and a newer setting that, when an app uses it, is meant to route all traffic through the tunnel and block it when the tunnel is down. Whether a given VPN app uses these is up to its developer, so look in the app's own settings for on-demand or connect-automatically options. A long-standing issue on iOS is that connections already open when the VPN starts can stay outside the tunnel until they close; after connecting, briefly switching airplane mode on and off is a crude way to reset them.

Linux: write the rule yourself#

On Linux the cleanest kill switch is a firewall rule that only allows traffic out through the tunnel interface, to the VPN server itself, and to the local network. With nftables:

table inet killswitch {  chain output {    type filter hook output priority 0; policy drop;    oifname "lo" accept    oifname "tun0" accept    ip daddr 203.0.113.10 tcp dport 443 accept    ip daddr 192.168.0.0/16 accept    udp dport 67 accept  }}

Replace tun0 with your tunnel's interface name (wg0 for WireGuard, whatever your Xray client calls its TUN device), 203.0.113.10 and 443 with your server's address and port, and the local range with your own. The DHCP line keeps your lease renewing. Because the policy is drop, everything not listed is blocked whether the VPN client is running or not - which is the point, and also why you should load it from a console you can reach if it goes wrong. The firewall rules that matter post covers default-deny rules more generally.

Routers: one kill switch for the whole network#

Some devices cannot run a VPN client at all: smart TVs without an app store, games consoles, older streaming boxes. For those, the only way through a VPN is a router that runs the client and sends their traffic into the tunnel. Router firmware such as OpenWrt can do this, and community packages bring Xray and sing-box to it alongside WireGuard and OpenVPN.

On a router, the kill switch is a firewall decision rather than an app setting. The usual pattern is to put the tunnel interface in its own firewall zone and allow forwarding from the local network only to that zone, not to the normal internet-facing one. If the tunnel goes down, the local devices have nowhere to forward to and their traffic stops, which is the kill switch. The router's own traffic, such as the VPN connection itself and time sync, still goes out the normal way.

Two cautions. A router kill switch applies to every device behind it, so when the VPN is down the whole house is offline, not one phone. And a router CPU is often the slowest processor on the network; encryption that a phone does without noticing can cap a cheap router at a fraction of the line speed. Why is my VPN slow has the signs to look for.

A middle course many households use: the router tunnels only the devices that cannot run a client, and phones and laptops run their own client with their own always-on settings.

Testing a kill switch#

Do not take a checkbox on trust. Test the moments when leaks happen. On a laptop, a loop that prints your public address every second makes the gaps visible:

$ while true; do curl -s --max-time 3 https://ifconfig.me; echo; sleep 1; done

1. Connect the VPN and start the loop, or keep a page that shows your public address open and refresh it.
2. Make the tunnel fail. Any of: kill the VPN client process, block the server's address on your router, switch from wifi to mobile data, or put the device to sleep and wake it.
3. Watch the output. With a working kill switch you see the server's address, then timeouts while the tunnel is down, then the server's address again. Without one, your real address appears in the gap.
4. Repeat at boot: restart the device and check what the first requests do, ideally with a firewall log or a DNS log on your router.

On Android, the test is simpler: with lockdown on, stop the VPN from the notification and try to load any page. It should fail.

The DNS leak testing guide covers the steady-state leaks; this test covers the transient ones. You want both clean.

The trade-offs#

A kill switch makes the VPN a single point of failure, on purpose. When the server is unreachable, you have no internet. Whether that is acceptable depends on why you use the VPN.

• On untrusted networks, or where a network blocks or watches traffic, failing closed is what you want. A few minutes without connection is better than a few minutes of everything in the open.
• At home, for ordinary privacy from your ISP, always-on without the block is a reasonable middle: the VPN comes back by itself, and a brief gap does not cut you off.
• For local devices, check that the rule allows your local network, or the printer, NAS and casting stop working whenever the VPN is down.

Whatever you choose, it is not anonymity. A kill switch only guarantees that traffic does not leave outside the tunnel; it does not change who can see it at the far end. VPN use is also restricted in some countries; know the rules where you are.

With a private VPN server#

On RE:NODE's private VPN line, the server runs Xray with VLESS and Reality, with its own address and key and nobody else on it. Leak protection is a client-side matter, so it comes from the device: on Android, put v2rayNG or Hiddify in VPN mode and turn on Always-on VPN with the block; on iPhone, use the client's automatic connection options; on Windows, the Renode VPN app connects with the link the server prints, and the firewall approach above adds a fail-closed layer if you want one. It is one server in one location, Germany, so when it is unreachable - your network blocks its address, the server restarts, the path is down - a kill switch will do exactly what it says and hold your traffic until it is back. The client setup guide covers importing the link in each app.

FAQ#

What is the difference between a kill switch and always-on?

Always-on makes sure the VPN is running - it starts at boot and reconnects after drops. A kill switch makes sure nothing gets out when it is not - traffic is blocked during the gaps. You want both: always-on to minimise the gaps, the kill switch to close them.

Why do I have no internet after my VPN app crashed?

The kill switch is still blocking traffic outside the tunnel, which is what it is for. Restart the VPN client and it will reconnect or remove its rules. On Android, turning off Block connections without VPN restores access if the VPN cannot connect.

Does Android's block connections without VPN stop all leaks?

It stops apps from sending traffic outside the tunnel, which covers boot, reconnects and crashes. Android still sends some of its own system traffic, such as connectivity checks, outside the VPN. For almost everyone this is acceptable; for a strict threat model it is worth knowing.

Can I use a kill switch on hotel wifi?

Yes, but you have to get through the login page first, and the kill switch blocks it. Turn the block off, accept the portal, connect the VPN, then turn the block back on.

Does a kill switch slow the connection?

No. The firewall rules it adds are trivial for the operating system to evaluate. The only cost is availability: when the VPN is down, so is your connection.