How to Test What a Kill Switch Covers on a Compromised Host

Flip the kill switch on, pull the tunnel server offline, and watch what the machine still does. That test is worth running, because it separates what the firewall enforces from what you assumed it enforces, and the results are narrower than most product pages suggest. A kill switch governs network paths; it does not govern software already running on the device. I run this sequence on any machine where the client claims to be fail-closed, and it takes about ten minutes.

Start from the client, not the server

The enforcement point is the host you are sitting at: the operating system firewall, a helper service, or the VPN client's own driver. That matters because everything the switch can do is bounded by what that layer can see. If the client implements the block with a routing rule plus a mark, anything with enough privilege can add a rule of its own; if it uses a kernel firewall table, the same privilege can edit the table. The strength of the cipher never enters this question.

So the first thing to establish is who owns the policy on this device and what it is allowed to override. On a managed work machine the answer is usually the organization's endpoint agent, and a personal VPN does not remove those capabilities, however the tunnel is configured.

Step one: confirm the block on the paths you believe it covers

Take the tunnel down at the far end rather than at the client, so the client still believes it should be connected. Then try what a person would actually try:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

You want a client that fails fast and cleanly, not one that hangs until a browser timeout. A hang usually means packets are dropped silently by a rule with no reject, which is acceptable, but it can also mean the client left a stale default route aimed at a dead interface. Read the routing table while the tunnel is down: a default route still pointing at the tunnel device and a firewall rule that only blocks new outbound connections are two different states, and only one of them is fail-closed.

Repeat the same commands with the client's allow-LAN option on and off. That toggle is where most surprises live, because it reopens a path the rest of the policy was written to close.

Step two: check DNS and IPv6 as separate paths

Name resolution is the gap that survives most implementations, because the query can leave through something other than the system resolver. Ask with a tool that ignores your resolver configuration, and check the v6 side while you are there:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Empty answers for both name queries with the tunnel down are the result you want. If the second query answers, a hardcoded resolver address is reachable and the tunnel is not the only path off the machine. If only the v6 request succeeds, the policy covers IPv4 and ignores IPv6, which is the same leak in a different address family.

Browsers make this harder to read from the outside, because one configured for DNS over HTTPS resolves through an HTTPS request: the query is only as blocked as port 443 to that endpoint. On a host where the policy allows the local subnet, that request can still reach a resolver on the LAN.

Step three: separate network exposure from endpoint exposure

Now the part no firewall rule reaches. A kill switch blocks paths off the machine; it does not stop software on the machine from reading data before it is encrypted, and it does not stop that software from using the tunnel legitimately. A keylogger, a malicious extension, a screen left unlocked, a sync client with broad permissions: all of these move information over a connection the switch is happy to allow.

The same holds for monitoring software an employer installed on purpose. Blocking routes does not remove it, and buying a new VPN server is not the repair, because the exposure sits upstream of the tunnel.

A clipboard manager that uploads to a cloud account makes the point sharply. The traffic is encrypted, the destination is allowed, and the kill switch reports a healthy state the entire time.

Step four: write the claim your test supports

After the outage test you can state specific facts: which applications failed, which paths stopped, whether DNS and IPv6 behaved, and whether the block held when the tunnel dropped. You cannot state that the operating system is clean, and you cannot state that a service on the far end will keep your login private.

Keep the two problems separate and give each its own control:

• Kill switch: the defined failure requirement, verified by an outage test you repeat after every client upgrade.
• Device trust: supported updates, endpoint protection from a trustworthy source, review of unexplained permissions and authentication prompts.
• Incident: follow the platform or organizational process when compromise is suspected; a fresh server is not a cleanup step.
• Disclosure: when asking for help, do not paste private keys or whole diagnostic archives, because logs and screenshots carry the same secrets as the connection.

Run the sequence again after the next update, because a kill switch is configuration that moves with versions. The test is the only evidence you have that the behavior you rely on is still the behavior you get.