Windows Kill Switch Without Extra Software: Profiles or Routes?

Firewall profiles follow a network's category, routes follow the adapter. Compare both, then test the crash case with the tunnel gone and the icon lying.

The client dies mid-download and the tray icon vanishes. The transfer keeps going over the home connection. That sequence is the reason a kill switch exists, and Windows can approximate one without a second product.

Two methods are worth knowing. They fail in different places, and neither is a complete answer.

Method One: Permit the Program on One Profile Only

Windows Firewall scopes rules to the Domain, Private and Public profiles. The trick is to give the tunnel adapter one category and the physical adapter another. You then write an outbound rule that permits the protected program on the tunnel profile and blocks it everywhere else. The firewall reads the category, not the adapter name.

Set the VPN connection to Private and the physical network to Public first. Then add a block rule for the program that applies to the profiles you do not want. Confirm the assignment afterwards with Get-NetConnectionProfile, because that assignment is what the rule follows.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

The weakness is structural. A profile rule tracks the category, so when Windows reclassifies a hotel network the block can stop applying. Nothing in the rule list changes when that happens.

Method Two: Remove the Physical Default Route

The routing approach is blunter and far easier to audit. Note the physical gateway, let the VPN install its own default with a lower metric, then delete the physical default. Nothing else can then carry traffic.

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

When the client dies, the VPN route leaves with its adapter. The machine goes offline instead of leaking, which is what a kill switch is supposed to produce.

Two details decide whether it survives a week. DHCP puts the gateway back whenever the link flaps. A statically addressed physical adapter avoids that surprise. The VPN server's own address has to stay reachable too. Without that host path the client can never reconnect after the drop that triggered the block.

Method Three: No Gateway, One Persistent Host Route

The third option starts by clearing the gateway from the adapter settings. A single persistent route to the VPN endpoint then replaces it. The machine can then talk to the server and to nothing else until the tunnel comes up.

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

Restoring the gateway restores ordinary internet, which makes this a clean on and off switch. It does not depend on a script watching interface events. It also does not care how the network gets categorized.

The cost is total isolation while the tunnel is down. Updates stop, and so does the very download that prompted the exercise. For a work laptop that is often correct, while on a personal machine it is a decision to make deliberately.

Why the Globe Icon Proves Nothing

Windows reports reachability through a probe against a Microsoft endpoint. That probe says nothing about your tunnel. A connected tunnel can sit behind a globe that reports no internet, and a dead one can show a healthy connection.

Test by killing the client process and then trying to reach a public address by number. A name lookup can be answered from cache, so neither the icon nor a DNS answer is evidence.

What to Record After a Real Drop

Run the test as a sequence rather than a single check. Kill the process instead of disconnecting, then try a numeric address on both families. Restore the client afterwards and confirm it can still reach its own server through the route you kept.

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

Repeat the sequence after sleep, after a Wi-Fi change and after a wired-to-wireless switch. Those transitions are where the profile method and the DHCP behaviour both fail. A rule that holds on a desk does not necessarily hold in a hotel.

Write the undo step next to every rule and route. Microsoft documents outbound rule creation in its Windows Firewall rules reference, and that is a better source than a screenshot-only walkthrough.

Mikanda mikatakata