How to Set Up a VPN Kill Switch on Linux (Step by Step)

A VPN kill switch blocks all network traffic the moment your VPN connection drops, so your real IP address never briefly leaks out while the app reconnects. On Windows and macOS this is usually a single toggle in the app’s settings. On Linux, it depends heavily on which app or client you’re using, and if you’re running OpenVPN or WireGuard through the command line rather than a GUI app, you may need to set one up manually with iptables or nftables. Here’s how to handle both cases.

Step 1: Check if your VPN app already has one

NordVPN, ProtonVPN, Surfshark and Mullvad all ship Linux apps or command-line tools with a built-in kill switch option, though the exact wording and location varies. Check your app’s settings menu for terms like “kill switch,” “always-on VPN,” or “network lock.” If you’re using an official app rather than a manually configured OpenVPN or WireGuard connection, this is almost always the simpler and more reliable option, since it’s built and tested by the provider specifically for their own client.

Step 2: Enable the built-in kill switch

If your app has the option, toggle it on and restart the app to make sure the setting takes effect immediately rather than only applying to future connections. Some apps offer a distinction between a standard kill switch, which blocks all traffic when the VPN drops, and a stricter “always-on” mode that blocks all internet access unless the VPN is actively connected in the first place, even before you’ve manually started a session. For most users, the standard option is the better default, since the stricter mode can be inconvenient if you frequently use the machine without the VPN running.

Want to compare all VPNs side by side? Check our full VPN comparison table with scores across 18 criteria.

Step 3: Set up a manual iptables kill switch

If you’re running a bare WireGuard or OpenVPN connection without a GUI app, or your provider’s Linux client doesn’t include a kill switch, you can build one with iptables rules that block all outbound traffic except through your VPN’s network interface. The core idea is to set your default policy to drop all traffic, then explicitly allow traffic only through your VPN tunnel interface (commonly named tun0 for OpenVPN or wg0 for WireGuard) and to your VPN server’s IP address for the initial handshake.

A basic version looks like this, run before connecting:

sudo iptables -P OUTPUT DROP
sudo iptables -A OUTPUT -o tun0 -j ACCEPT
sudo iptables -A OUTPUT -d YOUR_VPN_SERVER_IP -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT

Replace YOUR_VPN_SERVER_IP with the actual IP address of the server you’re connecting to, and adjust the interface name to match your setup. This ruleset blocks all outbound traffic by default, then carves out exceptions for your VPN tunnel, your VPN server itself (needed for the connection to establish in the first place), and loopback traffic, which your system needs for internal processes to function correctly.

Step 4: Use nftables for a more modern approach

nftables is the newer framework replacing iptables on most current Linux distributions, and it handles the same logic with cleaner syntax. A comparable ruleset in nftables looks like this:

sudo nft add table inet killswitch
sudo nft add chain inet killswitch output { type filter hook output priority 0 \; policy drop \; }
sudo nft add rule inet killswitch output oifname "wg0" accept
sudo nft add rule inet killswitch output ip daddr YOUR_VPN_SERVER_IP accept
sudo nft add rule inet killswitch output oifname "lo" accept

Whichever framework you use, remember these rules apply until you remove them or reboot, so if you disconnect the VPN intentionally and want normal internet access back, you’ll need to reset the ruleset (sudo iptables -F for iptables, or delete the table with sudo nft delete table inet killswitch for nftables) rather than just closing the VPN application.

Step 5: Test that it actually works

This step matters more than the setup itself, since an untested kill switch is just a guess. With your VPN connected and the rules active, find the VPN process and kill it forcibly to simulate an unexpected drop:

sudo pkill -9 openvpn

or for WireGuard:

sudo wg-quick down wg0

Then immediately try to load any website. If your kill switch rules are working, the connection should fail outright rather than silently falling back to your normal, unprotected connection. If a page does load, check your rule order and confirm the default OUTPUT or nftables chain policy is actually set to drop, since a misconfigured rule order is the most common reason a manual kill switch doesn’t actually block anything.

Making the rules persistent across reboots

Manual iptables or nftables rules don’t survive a reboot by default. On most distributions, you can save iptables rules with iptables-save > /etc/iptables/rules.v4 and restore them at boot using your distribution’s iptables-persistent package, or write your nftables ruleset directly into /etc/nftables.conf and enable the nftables systemd service so it loads automatically. If you only need the kill switch active during specific sessions rather than permanently, a simple shell script that applies the rules before connecting and removes them after disconnecting is often more practical than making them persistent system-wide.

Common problems and fixes

DNS requests still leak through: your kill switch rules may only be covering outbound traffic on the standard ports without explicitly handling DNS. Make sure your VPN app or manual WireGuard/OpenVPN config is pointing DNS through the tunnel interface, and consider adding an explicit rule blocking DNS traffic (port 53) outside the tunnel.

Kill switch blocks the initial VPN handshake: this usually means your rule allowing traffic to the VPN server’s IP was written after the default-drop policy took effect, or the server IP is wrong. Double check the IP address matches the actual server you’re connecting to, not a hostname, since iptables and nftables rules generally need a resolved IP address rather than a domain name.

Rules don’t survive a reboot: as covered above, this is expected behavior unless you’ve explicitly configured persistence through your distribution’s tools.

Which distributions this works on

The iptables and nftables commands above work the same way across Debian, Ubuntu, Fedora, Arch and most other major distributions, since both frameworks are part of the Linux kernel’s standard networking stack rather than being distribution-specific. The main difference between distributions is which persistence tooling is available by default and what the package is called, so check your distribution’s documentation for the exact persistence package name if you want the rules to survive a reboot automatically.

Keep reading: VPN Kill Switch Explained and Best VPN for Linux 2026.