Many VPN apps come with a “kill switch”, which turns off your Internet connectivity when the VPN connection is lost. Without a kill switch, you might be falsely thinking that you’re protected by a VPN, while the VPN connection is down and your connection is switched back to the ISP.
But how do you know that the VPN app’s kill switch is working as expected? The answer to the question is not as straightforward as you might think. In fact, many people found out that their VPN kill switch failed after their IP info leaked. “VPN kill switch not working” is one of the top searches for “VPN kill switch” on Google.
In this post I’ll show you how to test the kill switch in several common scenarios. To keep it simple, I’ll be using the WireGuard client on Windows as an example. And I’ll use the “ping” command to test connectivity.
Test this scenario if you configured the VPN to auto-start on device boot-up. You want to simulate the condition where your device has a valid Internet connection but the VPN fails to establish a connection to its server. The kill switch should block you from the Internet.
Here are the steps:
Below are the screenshots for my test. I updated my WireGuard VPN server to a non-routable IP address. After I activated the WireGuard tunnel, “ping” to Cloudflare DNS server 18.104.22.168 failed as expected. It continued to fail after I rebooted the computer.
Under this scenario, your VPN connection is working in the beginning, but at some point it stops working. Would the kill switch bring down your Internet connection?
This condition is a little bit trickier to simulate. You want to block the VPN connection while keeping your ISP connection intact. Unplugging the Ethernet cable or disconnect the WiFi wouldn’t work because it also brings down your underlying ISP connection.
In my case, I added a calendar for the VPN server domain on my pcWRT router. And indeed Internet connectivity was blocked when the allowed time on the calendar was exceeded.
You can test this scenario by stopping the VPN process in the Task Manager (on Windows). The Windows WireGuard client kill switch partially worked in this scenario.
There were three WireGuard processes when the VPN tunnel was successfully established. When the process labeled “1” in the picture below was killed, it was restarted automatically, keeping the VPN tunnel intact. However, when the process labeled “2” was killed, my Internet connectivity fell back to the ISP connection (i.e., the kill switch failed to kill).
This was evidenced by the drop in “ping” round trip time (ping through the VPN tunnel takes longer).
Sometimes you may want to switch your VPN connection to a different server. Or the VPN client software may do so automatically depending on the network conditions. After the original VPN tunnel is teared down and before the new VPN tunnel is established, does the kill switch prohibit Internet connectivity through your ISP connection?
You’ll have a temporary leak if it doesn’t.
The WireGuard VPN client on Windows did not pass this test. I configured two VPN tunnels, started one tunnel first. Then I stopped the active tunnel, waited for a few seconds and started the second tunnel. My computer was able to get out to the Internet after the first one was stopped and before the second one was activated. This can be seen in the “ping” test that was going on during the process. The “ping” response time dropped to single digit milliseconds for a few seconds, meaning the computer was sending the packets outside of a VPN tunnel.
However, there’s an easy mitigation for the WireGuard VPN client on Windows. You can simply activate the second VPN tunnel without stopping the first tunnel beforehand. The client will bring down the first tunnel then start the second tunnel immediately, thus minimizing the gap between de-activation of the first and activation of the second.
We are often asked about the kill switch for VPN on the pcWRT router. It doesn’t have one because it doesn’t need one.
When you configure the pcWRT router to route certain VLANs through a VPN, the router will send traffic from the designated VLANs only through a VPN connection. If a VPN connection is not available (e.g., not configured, inactive or connectivity lost), the packets will be dropped.