OpenVPN kill switch Windows setup

An OpenVPN kill switch on Windows is a set of Windows Defender Firewall rules, not a feature of the client. The OpenVPN GUI has no such setting on Windows, so the block has to live in the operating system. Build it correctly and every process on the machine loses network access the moment the tunnel drops. Build it carelessly and you either leak on IPv6 or lock yourself out of your own printer. This page covers the rules, the two exceptions almost every guide omits, and the teardown you will want at two in the morning.

The model is four rules and nothing else. Set the outbound default action to block on every profile. Allow all outbound traffic on the OpenVPN virtual adapter. Allow openvpn.exe itself so the tunnel can reach the server. Allow nothing else outbound on the physical adapter.

That ordering matters. Windows Defender Firewall evaluates allow rules against a default action, so the default has to change first. Everything after it is an exception you are choosing deliberately. If you can name why each allow rule exists, the kill switch is correct.

• Default outbound action set to block on the domain, private and public profiles
• One allow rule scoped to the OpenVPN adapter by interface alias
• One allow rule for the OpenVPN process, or for the server address and port
• Explicit exceptions for the LAN and for captive portal login, added knowingly

Find the adapter name before writing any rule. Open PowerShell as administrator and run Get-NetAdapter. The OpenVPN adapter is the one whose InterfaceDescription names either TAP-Windows or Wintun. Note the Name column value, because that is the interface alias the firewall rule needs, and it is usually something like OpenVPN TAP-Windows6 or OpenVPN Wintun.

Which driver you see depends on the client build you installed rather than on your Windows version. Do not predict it from a version number in a forum post. Read the InterfaceDescription column and use whichever name is actually there. The rule syntax is identical either way, and only the alias string changes.

Rename the adapter if the default name is awkward. Use Rename-NetAdapter -Name "OpenVPN Wintun" -NewName "VPN" and then use VPN everywhere below. A stable, short alias makes the rules readable, and readable rules are rules you can safely delete later.

Everything below assumes an elevated PowerShell session. Run it on a machine you are sitting at. These commands cut outbound network access. Do not run them over Remote Desktop or SSH, because the session will drop before you finish.

Set the outbound default to block

Set-NetFirewallProfile -Profile Domain,Private,Public -DefaultOutboundAction Block -Enabled True

Confirm the change with Get-NetFirewallProfile | Select-Object Name, DefaultOutboundAction. All three profiles should read Block. At this point the machine has no outbound connectivity at all, which is the correct intermediate state.

This step is the one that does the work. Microsoft documents the outbound default action as Allow when you are managing a computer, so nothing outbound is blocked until you change it. That is why a guide starting with an allow rule builds nothing at all.

Prove the IPv6 half rather than assuming it. With the tunnel down, run curl -6 https://ipv6.icanhazip.com and confirm it fails alongside the IPv4 test. A route-deletion approach, which is what the incumbent guides teach, leaves IPv6 untouched, and that test is how you catch it.

Allow the VPN adapter

New-NetFirewallRule -DisplayName "VPN tunnel out" -Direction Outbound -Action Allow -InterfaceAlias "VPN" -Profile Any -Enabled True

This is the rule the command-line guides cannot write, and it is worth knowing why. netsh advfirewall scopes rules by interface type rather than by interface name. Run netsh advfirewall firewall add rule ? and read the interfacetype values your own build accepts. None of them names a single adapter, and the Windows Defender Firewall with Advanced Security console has the same limit on its Advanced tab.

The PowerShell module draws the line clearly. Microsoft documents -InterfaceAlias as specifying the alias of the interface that applies to the traffic, and -InterfaceType as accepting only Any, Wired, Wireless or RemoteAccess. So the type filter names a class of adapter and the alias filter names one adapter.

Read the rule back afterwards with Get-NetFirewallRule piped into Get-NetFirewallInterfaceFilter, which is the documented way to query an alias filter. Every guide that tells you to use netsh for this step is telling you to build a looser rule than you think you are building.

Allow the server endpoint

The tunnel itself has to reach the server across the physical adapter, so it needs one exception. Two shapes work, and they fail differently.

New-NetFirewallRule -DisplayName "OpenVPN client" -Direction Outbound -Action Allow `
  -Program "C:\Program Files\OpenVPN\bin\openvpn.exe" -Profile Any -Enabled True

The program rule survives a server address change, which matters if your provider rotates endpoints. The endpoint rule below is tighter but pins you to one address.

New-NetFirewallRule -DisplayName "OpenVPN endpoint" -Direction Outbound -Action Allow `
  -RemoteAddress 203.0.113.10 -RemotePort 1194 -Protocol UDP -Profile Any -Enabled True

Read the remote and proto lines of your .ovpn file for the address, port and protocol. If your profile uses remote-random across several servers, the program rule is the only practical option, because you cannot enumerate the endpoint in advance.

The same rules from the command line

netsh advfirewall still handles the default action and the program rule correctly. Use it if you are scripting against an older image.

netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound
netsh advfirewall firewall add rule name="OpenVPN client" dir=out action=allow program="C:\Program Files\OpenVPN\bin\openvpn.exe" enable=yes
netsh advfirewall firewall add rule name="OpenVPN endpoint" dir=out action=allow remoteip=203.0.113.10 remoteport=1194 protocol=UDP enable=yes

There is no netsh equivalent for the adapter rule. Mix the two tools rather than dropping the adapter scope, or accept a rule that allows more than one interface. Run netsh advfirewall firewall add rule ? to see the parameters your build accepts, then read every rule back with Get-NetFirewallRule once you have created it.

There are four, and the incumbent pages cover none of them. Each one is a specific leak with a specific test.

The LAN exception is one rule and it should name your subnet, not the whole private range.

New-NetFirewallRule -DisplayName "LAN out" -Direction Outbound -Action Allow `
  -RemoteAddress 192.168.1.0/24 -Profile Private -Enabled True

Scope it to the private profile so it does not follow you onto a coffee shop network. Replace 192.168.1.0/24 with the subnet your router actually hands out. Adding 10.0.0.0/8 and 172.16.0.0/12 alongside it is common and it is also how you accidentally allow traffic on a network you do not control.

The DHCP row needs its own rule, and it is the one that catches people on a new network. An outbound block stops the DHCP client from asking for a lease, so the machine can join the wifi and never receive an address. Allow the request explicitly.

New-NetFirewallRule -DisplayName "DHCP out" -Direction Outbound -Action Allow `
  -Protocol UDP -LocalPort 68 -RemotePort 67 -Profile Any -Enabled True

Captive portals cannot be solved with a standing rule, and any rule broad enough to let a portal through is broad enough to leak. Portals answer on arbitrary addresses over HTTP and HTTPS, so an allow rule for them is an allow rule for the web. Flip the default instead, complete the login, and flip it back:

Set-NetFirewallProfile -Profile Public -DefaultOutboundAction Allow
Set-NetFirewallProfile -Profile Public -DefaultOutboundAction Block

Treat the gap between those two commands as unprotected time and do nothing else in it. Connect the tunnel before you open anything you care about.

The DNS row is not a firewall rule. block-outside-dns is an OpenVPN directive that tells the Windows client to stop the operating system from querying resolvers outside the tunnel. Add it to your profile and read the rest of the flag detail in block-outside-dns and other OpenVPN flags. It solves a different problem from the firewall, and the firewall does not solve it for you.

Connect the tunnel and confirm normal browsing works. Then force a disconnect and confirm traffic stops. That is the minimum, and it is also roughly where every competing page ends.

It is not enough, for one specific reason: a browser tab tests one application in the foreground, after the leak window has already closed. Background processes resolve hostnames on their own schedule. The real test runs a packet capture, exercises DNS separately from IP, and covers the reconnect window after a sleep or a network change. The full method is in how to test if a VPN kill switch works.

This is the failure the incumbent pages never mention, and it is the one that generates support tickets. The rules are firewall state. They survive a disconnect, a reboot and an uninstall of OpenVPN, because none of those things touches Windows Defender Firewall. Remove the client and the machine stays offline, with no obvious cause.

Restore outbound connectivity first, then clean up:

Set-NetFirewallProfile -Profile Domain,Private,Public -DefaultOutboundAction Allow
Remove-NetFirewallRule -DisplayName "VPN tunnel out"
Remove-NetFirewallRule -DisplayName "OpenVPN client"
Remove-NetFirewallRule -DisplayName "OpenVPN endpoint"
Remove-NetFirewallRule -DisplayName "LAN out"
Remove-NetFirewallRule -DisplayName "DHCP out"

The first line is what gets you back online. The rest is tidying. Naming every rule with a recognisable -DisplayName when you create it is what makes this teardown possible, so do not skip the naming step to save typing. Test the teardown once before you need it. Set the default outbound action back to allow, load a page, then set it to block again.

If you inherited a machine in this state and do not know the rule names, run Get-NetFirewallRule -Direction Outbound -Action Allow | Select-Object DisplayName, Enabled and read the list. There is also a blunt instrument, netsh advfirewall reset, which returns the firewall to its shipped defaults. It also discards every other rule on the machine, so treat it as a last resort.

There are none that change any rule on this page. Every command here comes from the NetSecurity PowerShell module, and Microsoft documents those cmdlets without splitting the reference by client version. Do not take that as a promise about your own build. Read each rule back with Get-NetFirewallRule after you create it, because the machine in front of you is the authority on what it accepted.

One consequence of the outbound block is worth stating plainly, and it is not version-specific. While the tunnel is down, Windows Update, the Microsoft Store, licence activation and time synchronisation are all blocked along with everything else. That is the kill switch doing its job. It is also why people quietly disable it after a week. Decide up front whether you want it on permanently, or only while you are on an untrusted network.