How to test if a VPN kill switch works

Learning how to test if a VPN kill switch works properly takes about fifteen minutes and one packet capture. The test that every ranking page teaches, which is to disconnect the VPN and refresh a browser tab, proves almost nothing. It checks one application, in the foreground, after the interval where leaks actually happen has already closed. This page gives a method you can run on your own machine, repeat after any client update, and read without guessing. It does not rank providers and it does not tell you whether yours passed.

A browser tab is the worst available instrument for this. It reports one process, and the process most likely to have been paused by the operating system while you were switching windows.

Three specific things it cannot see. It cannot see a background process resolving a hostname, which is where most real leaks are. It cannot tell you whether the thing that escaped was an address or a name, and those have different fixes. It cannot observe the two seconds after a wake or a network change, because a page load takes longer than the window it is meant to be testing.

The result is a test that produces a green light from a kill switch with a hole in it. That is worse than no test, because you stop looking.

Be clear on the boundary before measuring anything, because half of what people call a kill switch failure is not one.

A kill switch blocks traffic when the tunnel is down. That is the entire job. It does not decide which resolver your operating system talks to while the tunnel is up, so it does not stop a DNS leak by itself. It does not control what a browser chooses to reveal about your local network. And a kill switch does not make a weak provider trustworthy, which is the point what a kill switch does and does not do exists to make.

That means a passing kill switch test and a passing DNS leak test are two separate results. You need both, and this page produces both from one capture.

Four stages. Run them in order on a machine you can reach physically, because stage three deliberately removes your network access.

Stage one: start a packet capture

Capture on the physical interface, not on the tunnel. The tunnel is where traffic is supposed to be, so it tells you nothing. The physical interface is where a leak would appear.

Identify it first. Run ip -brief link show on Linux or ifconfig on macOS, and take the wired or wireless device, usually something like enp3s0, wlan0 or en0. Then start the capture, filtering out the encrypted tunnel traffic so the file contains only things that should not be there:

sudo tcpdump -i en0 -n -w /tmp/killswitch.pcap 'not host 203.0.113.10'

Replace en0 with your interface and 203.0.113.10 with your VPN server address. Every packet that lands in this file while the tunnel is down is a candidate leak.

On Windows there is no tcpdump. Use Wireshark on the physical adapter with the display filter not ip.addr == 203.0.113.10. Windows also ships pktmon, which is built into the operating system and needs no install. Start a capture with pktmon start --capture, then convert the resulting ETL file with pktmon etl2pcap. Open the converted file in Wireshark and apply the same filter you would have used live. Run pktmon help first if you want the option set your own build offers.

Stage two: generate continuous traffic

The traffic has to exercise name resolution and raw addressing separately, or the capture cannot distinguish the two failures. Use two different targets, and give each one a timestamp.

while true; do
  date +%T
  dig +short +time=2 +tries=1 example.com @1.1.1.1
  curl -s -m 2 -o /dev/null -w 'http %{http_code}\n' https://1.1.1.1/
  sleep 1
done

The dig line sends a DNS query and nothing else. The curl line connects to a literal address, so it involves no name resolution at all. In the capture those become UDP port 53 and TCP port 443 to distinct destinations, and you can tell at a glance which one escaped.

dig is not present on every system, so run which dig before you rely on that loop. Where it is missing, install the DNS utilities package your platform provides, or substitute nslookup example.com 1.1.1.1 and accept the noisier output. On Windows, run the equivalent with Resolve-DnsName example.com -Server 1.1.1.1 and Invoke-WebRequest https://1.1.1.1/ -TimeoutSec 2 inside a loop.

Leave this running in its own terminal. The visible output is a live signal, and the timestamps are what let you line the loop up against the capture afterwards.

Stage three: kill the tunnel four different ways

This is the stage the incumbents collapse into one action, and the four are not equivalent. Each of these removes your network access. Run them locally.

sudo ip link set wg0 down          # Linux
sudo ifconfig utun4 down           # macOS

sudo wg-quick down wg0
sudo killall openvpn

sudo pfctl -d                      # macOS
sudo ufw disable                   # Linux, if UFW is the kill switch

Test one simulates a crash or a lost route. Nothing gets told to clean up, so a firewall-based kill switch stays armed. This is the case that should always block.

Test two is the one that surprises people, and the result is not a failure. A PostUp and PreDown kill switch written into a WireGuard config removes its own rules on the way down, because that is what PreDown is for. Traffic flows afterwards by design. To make the block survive a deliberate disconnect, put the rules in the operating system firewall instead of the config file. That is the difference between the WireGuard kill switch page and the Linux VPN kill switch page.

Test three checks nothing about the VPN and everything about you. It proves you can restore your own connectivity, which is the thing you will need at the least convenient moment.

Test four is the closest to reality and the one worth repeating most often.

Stage four: read the capture

Stop the capture with Ctrl-C, stop the traffic loop, then read the file back with the local noise filtered out:

tcpdump -r /tmp/killswitch.pcap -n \
  'not arp and not port 5353 and not port 67 and not port 68 and not icmp6'

Local noise is not a leak, and treating it as one is how people conclude their kill switch is broken when it is working. ARP, mDNS on port 5353, DHCP on ports 67 and 68, and IPv6 router solicitations are your machine talking to the network it is attached to. None of them carries a destination on the internet.

What remains after that filter is the actual result. A UDP packet to port 53 addressed to anything other than your tunnel resolver is a DNS leak. A TCP SYN to port 443 or 80 at an ordinary internet address is an IP leak. Compare the packet timestamps against the timestamps your loop printed, and you have the exact second the block engaged or failed to.

Steady-state testing is the easy half. The interval that matters is the one where the tunnel is coming back rather than sitting down, and it has three common forms.

Sleep and wake is the first. Close the lid with the capture and the loop running, wait a minute, open it. The network interface comes up before the VPN client does, and everything queued during sleep tries to send in that gap.

A wifi to cellular handover is the second, and it is a phone and laptop problem rather than a desktop one. The route changes underneath a tunnel that still believes it is connected, so packets go out on the new interface while the client works out what happened.

Boot is the third and the simplest to check. Start the capture at login, before the VPN client autostarts, and watch what the machine does in the gap. Update checkers and mail clients are usually first out.

A claim circulates that the reconnect window is where most real-world leaks occur. It matches the mechanism and it is repeated widely. It could not be traced to a source with measurements behind it, so treat it as a reason to test rather than as a finding. Your own capture across those three events is the only evidence that settles it for your machine.

Write the result down, because the point of a reproducible test is comparison over time. Repeat it after every client update, every operating system update and every config change.

• The date, the client version, and the operating system version you ran on
• Which of the four teardown methods blocked and which did not
• Whether DNS and raw address traffic behaved the same way, and the timestamp of any packet that escaped
• The exact capture filter you used, so the next run measures the same thing

Keep the pcap files. A capture from before an update is the only way to tell a regression from something that never worked.