VPN Kill Switch: Which Traffic It Blocks and When

Two features get described with the same word and do different jobs. Automatic reconnection tries to bring the tunnel back, and it can succeed within a second while requests fail in the gap. A kill switch decides what happens to traffic during that gap. Reading a client as though the two were one setting is how people end up trusting an icon instead of a policy.

Blocking and reconnecting are separate decisions

One client blocks only while a loss is unexpected, then reconnects and releases the block. Another holds a system-level block until someone changes a setting by hand, and a third treats a deliberate disconnect as permission to restore ordinary access. Those are three different behaviours, and the vendor documentation says which one your build implements.

Nothing about importing a profile decides that question. The same server profile loads into two clients with opposite blocking behaviour, because the profile carries settings rather than a promise. That is also why a desktop checkbox and a mobile switch with similar labels can implement different rules. Read the description attached to the control on your platform, then test what it does.

The same profile behaves differently in two clients

The OpenVPN Connect application settings describe a tunnel mode that holds ordinary traffic only while the client reports a paused or reconnecting state, which is narrower than a general promise about every event on every platform. Read the listed states rather than the product name. A description written for one client build does not transfer to another vendor client.

Android shows the same word covering two controls, since always-on VPN and blocking connections without a VPN are documented separately. A desktop client with a similarly named checkbox may implement something narrower or broader than either of them. Treat a shared label in two menus as a coincidence until both descriptions have been read. Managed devices add a third layer, because a device profile can enforce a setting the user cannot see or override.

Platform settings that look alike are not equivalent

Compare the control you can see with the policy that actually applies. On a managed device the visible switch may be greyed out, or it may be enabled while a higher-level profile forces the opposite. Ask for the effective policy rather than the local one, and get the answer in writing.

Record what each layer claims before you test anything, because the two commonly disagree and the disagreement is easy to lose once the tests begin. A device that blocks correctly during a test may be blocking for a reason nobody documented.

Run one event at a time and record the code

Test one event per run, with a harmless request, and make every attempt a new request rather than a page that may already be cached. The commands below take the tunnel down, ask for a page, and show whether the interface came back.

ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0

The table maps each action to the observation that matters and to the evidence worth keeping. A request that fails inside the timeout tells you the block engaged; a request that succeeds tells you the traffic found another path, which may be an excluded route rather than a disabled block. Repeat the whole set after a meaningful software update or a route-policy change, because either can alter the branch without any visible setting moving. What you want at the end is predictable failure behaviour, not a reassuring icon.

Exceptions, captive portals and what a block cannot do

Local-network access is the common exception, and it changes the scope of the promise. A client may reach a printer on the same subnet while blocking everything else, which is reasonable at home and questionable on a guest network. Decide whether that exception is wanted before an incident discovers it for you.

A strict block also makes captive-portal sign-in awkward, since the portal is exactly the direct traffic the block exists to stop. Learn the supported way to authorise the network, then restore the policy deliberately instead of switching off controls until a page loads. Keep the resolver answer and the route table in the same note, as below. What a kill switch cannot do is make the service anonymous, because blocking traffic outside the tunnel says nothing about what happens inside it.

resolvectl query example.com
ss -tunp | grep -v tun0