Does a VPN kill switch survive a reboot? How to verify

Rebooting is the most common way people test a kill switch, and it is the test that lies most often. The checkbox in the client is a preference; what matters is whether something enforces a block between the moment the network stack comes up and the moment the tunnel is actually established. On Windows that something is usually a filter in the Windows Filtering Platform, on Linux a ruleset loaded by a unit, on macOS a pf anchor, on Android the system's own always-on and lockdown flags. Those arrangements behave very differently across a reboot, and only the platform-level ones are in place before anyone can sign in.

Reboot asks three separate questions

Split the question. First, does the policy exist on disk in a form that something reads at boot? Second, does that reader run before any traffic can leave? Third, does the policy cover the traffic you care about, meaning every process, both address families and DNS. A yes to the first and a no to the second produces exactly the failure people report as a kill switch that does not survive reboot: traffic escapes for a few seconds at startup, and nobody notices until someone goes looking.

Keep the layers apart. A saved firewall ruleset, a service that starts at boot and a client preference are three different objects with three different lifetimes. The preference survives reboots because it is a value in a config file. The rules are the only thing that blocks packets, and they vanish with the kernel that held them.

Find the object that restores the block

On Linux, netfilter rules live in the kernel. Nothing writes them back at boot unless you arranged it: iptables-save plus netfilter-persistent, nftables.service loading /etc/nftables.conf, or a systemd unit that runs your own script. Check what is enabled instead of what you remember configuring.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

An empty ruleset a few seconds after boot is the answer to the question in the title. On Windows, ask the client service how it starts, then dump the platform filter state while the tunnel is down.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

The second command writes wfpstate.xml to the current directory. Look for filters with a block action that already exist before the client connects. The Base Filtering Engine starts early in boot and restores filters that were added with the persistent flag, which is why some kill switches block traffic before any client window exists and others do not. On macOS, sudo pfctl -s info reports whether pf is enabled, sudo pfctl -s rules shows what is loaded, and VPN clients usually attach their rules to an anchor instead of the main ruleset. A rule that names utun3 can point at a different interface after the next boot, because that number is assigned at runtime.

Watch the gap between network-up and tunnel-up

The dangerous interval is not the whole reboot, it is the gap. The interface receives a lease and a default route at one point, the VPN service starts at another, and the tunnel authenticates later still, sometimes only after a user logs in and a credential agent runs. If the block is applied last, everything in the gap leaves in the clear.

On systemd hosts, read the ordering rather than guessing it. Run systemctl cat on the VPN and firewall units and look for After= or Before= against network-pre.target and network-online.target. A firewall unit ordered after network-online.target loses to the interface; one that is wanted by and ordered before network-pre.target wins. On Windows the equivalent questions are the service start type and its dependencies, since a service set to Manual cannot block a boot-time process. If your requirement includes traffic before sign-in, only a device-level arrangement satisfies it: an Always On VPN device tunnel authenticates with a machine certificate and connects before the user logs on, and Microsoft documents the device tunnel configuration separately from the user tunnel. Android takes the other route, enforcing always-on VPN and blocking connections without it from the system rather than from an app process.

Run the test, then compare two timelines

Reboot with a destination that costs nothing if it leaks, and capture state during the gap instead of after it. The cleanest method is a boot-time probe: a oneshot unit or a scheduled task that starts as early as the platform allows, records the default route and the firewall state, attempts one request with a short timeout and appends a line to a local file. Compare that record against the VPN service start time from journalctl -b -u or the System log.

Then run the ordinary test: tunnel up, drop the connection, watch whether direct traffic is blocked, restore. Passing the second and failing the first is the normal result, and it means enforcement is client-side, applied when the client connects rather than at boot. On the last machine I audited, the block came from a NetworkManager dispatcher script, present and correct and useless for the seconds before the interface came up. Write both results down, because surviving a reboot only means something once you say which layer survived and from what moment.

Close the gap without breaking your way back in

If the block is missing at boot, move enforcement down a layer instead of adding a second client rule. Save the ruleset and load it from a unit ordered before the network is usable, and make sure that unit does not need a DNS lookup or a network mount it is supposed to protect. Scope matters as much as timing: rules matched on a user ID or a cgroup leave every system daemon outside the block, and a ruleset that handles only IPv4 leaves IPv6 and DNS reachable.

Leave yourself a way back. A machine that blocks everything at boot and then cannot authenticate has no network at all, and the fix is not to delete the block but to repair the credential or the ordering. Keep a documented local-console procedure and a narrow, deliberate exception for what the tunnel genuinely needs, such as the server address and the resolver used before the tunnel exists.

Before you trust the setup, confirm four things in order. The policy is stored somewhere boot reads. That reader runs before the interface is usable. The block covers both address families and DNS. The VPN can still authenticate while the block is active. When all four hold, a reboot changes nothing.