Windows Firewall Alone as a VPN Kill Switch: Does It Hold?
Interface-type rules can block the physical adapters, but a third-party tunnel often looks wired. Check classification, the endpoint route, then DNS.
Ask whether Windows Firewall can act as a kill switch on its own and you get two confident, incompatible answers. One says the interface-type rule does the whole job; the other says it cannot work without scripting. Both are describing half of the same mechanism. The firewall can express the block, and whether the result actually fails closed depends on three things: how Windows classifies the tunnel adapter, whether the endpoint exception survives, and whether name resolution and IPv6 are covered. Get any one of them wrong and the machine either leaks or loses all connectivity.
Three conditions, in this order
The first condition is classification, and it decides whether the rule you want is even expressible. Windows Firewall rules can be scoped by interface type: wired, wireless, or remote access. A policy that blocks outbound traffic on the physical types while permitting the tunnel only works if Windows recognises the tunnel as remote access.
The second condition is the endpoint exception. Before any tunnel exists, the client has to reach the VPN server over the physical adapter, so a blanket block on that adapter prevents the very connection that would make the block unnecessary. The exception must name the server and its port, and the packet must be routed out of the physical gateway rather than into a tunnel that is not up yet.
The third is coverage. A rule set that blocks IPv4 and forgets IPv6, or that permits the local resolver for the endpoint lookup and therefore permits every other lookup, fails open in exactly the window the kill switch exists to cover. That is a design gap rather than a bug in the firewall. It is also the gap that survives every test run on a desk.
Classification is the first gate
Check what Windows thinks the adapters are before writing a single rule. A native Windows VPN connection normally appears as remote access. A third-party client that creates its own virtual adapter often appears as wired, which means a block scoped to wired adapters also blocks the tunnel.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionThe third command tells you whether a default outbound block is already in force, which changes the whole shape of the design. If the default is already block, you are writing allow rules rather than exceptions to a permissive baseline, and that is a much easier posture to reason about.
If your tunnel adapter reports as wired, firewall-only is not the right tool for a fail-closed design, and no amount of rule tuning changes that. This is the case where the second opinion in every forum thread is correct.
The endpoint exception needs a route as well as a rule
Assume the classification works. The exception is two pieces, and they live in different subsystems. The firewall rule permits the traffic; the host route makes it leave by the right interface while the tunnel is down.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32Without the route, the endpoint exception only helps while a default route still points at the physical gateway. Once the client installs its own default route and then dies, the permitted packets have nowhere sensible to go and the connection cannot be re-established. That failure looks like a broken client and is really a missing route.
Keep the exception as narrow as the client allows. One address and one port is reviewable; a range that covers the provider's whole network is not. That wider rule also permits anything else hosted at the same provider, which is usually more than you intended.
DNS and IPv6 are where it fails open
Name resolution is the classic leak. If the endpoint is a hostname, the client must resolve it before the tunnel exists, which means the physical adapter must be allowed to reach a resolver. That same permission lets every other lookup out while the tunnel is down, and a lookup is enough to reveal what you were about to visit.
IPv6 is the second. Rules written for IPv4 do not cover the other family, and many clients install only IPv4 routes. A machine with native IPv6 connectivity can therefore keep talking to the internet while the IPv4 side is firmly blocked, and the kill switch reports success throughout.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
The third row is worth understanding rather than working around. A firewall decides about packets, not about which interface an application asked to use, and a program that binds explicitly can be awkward to contain. That is an argument for a client-side kill switch that operates below the application, not for more rules.
Test by stopping the client, not by pulling the cable
The only meaningful test is the one that imitates the failure you are protecting against. Stop the service, kill the process, or disable the adapter the client created, then try to reach the internet and a name:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443All three should fail. If the first succeeds, the block is not in force; if the second succeeds where the first failed, you have a DNS leak; if the third succeeds, IPv6 is uncovered. Each outcome points at exactly one of the gaps above.
Repeat the test after a sleep and resume, because the firewall profile can change when Windows decides a network is public or private, and rules scoped to a profile follow it. A design that holds on a desk and fails on a train is a design that was tested once.
If the classification gate or the DNS requirement makes the firewall-only approach unworkable, a client-side kill switch is the honest answer. If the tunnel terminates on a router instead, the router should own the policy, because one rule there covers every device behind it and does not depend on how Windows labels an adapter.