Linux VPN Kill Switch: 7 Essential Safety Checks

A Linux VPN kill switch is a fail-closed network rule that stops ordinary traffic from leaving through your normal interface when the VPN tunnel disappears. On Linux, I do not consider that protection proven because a toggle says “enabled.” I want to disconnect WireGuard deliberately, watch the routes, test DNS and IPv6, and confirm that the machine has no quiet escape path back to the open internet.

I use this approach mainly inside Parrot OS on VMware. My daily machine is a second-hand HP EliteBook that I upgraded to 32 GB RAM, so I can keep Parrot, Kali and vulnerable lab systems available together. A Linux VPN kill switch suits that setup because I can see exactly what the firewall permits instead of treating the VPN client as a black box.

This guide walks through seven safety checks for a VPN kill switch Linux setup: mapping interfaces, building a dedicated nftables policy, protecting DNS and IPv6, adding simple controls, forcing failures, switching profiles safely and only then making the rules persistent.

For the VPN side of this lab, I use Proton regularly. If you already use Proton VPN and also want encrypted mail, cloud storage and a password manager, Proton Unlimited is the package I would look at first rather than stacking separate subscriptions.

Proton Unlimited bundles Proton VPN, Proton Mail, Proton Drive and Proton Pass under one subscription. If you already use Proton services in your lab, the bundle is usually the more practical option.

HackersGhost Note: My rule is simple: a Linux VPN kill switch is not working until I have made the VPN fail on purpose and watched ordinary traffic fail with it. Successful connections are easy. Safe failures are the interesting part.

Key Takeaways for a Linux VPN Kill Switch

• A Linux VPN kill switch should fail closed: if the tunnel disappears, ordinary traffic should not fall back to Ethernet, Wi-Fi or a VMware uplink.
• Your VPN endpoint needs a narrow exception on the normal uplink or the encrypted tunnel cannot establish itself.
• A dedicated nftables table is safer to test than flushing the machine’s entire firewall ruleset.
• DNS and IPv6 belong in the same test plan. A changed public IPv4 address alone does not prove that every path is protected.
• A VPN kill switch Ubuntu setup, Parrot setup or Kali setup may use the same principles, but interface names and DNS management can differ.
• Do not enable persistence until disconnects, reconnects, server changes, suspend/resume and recovery all behave as expected.

What This Linux VPN Kill Switch Actually Builds

The finished setup stays small: one dedicated nftables table, one narrow VPN-endpoint exception, simple control scripts and a repeatable failure test. That keeps this Linux VPN howto practical without hiding the routing logic.

There is an important distinction between a provider-native kill switch and this manual policy. Proton’s Linux apps provide standard and advanced modes; advanced mode is designed to block internet access unless Proton VPN is connected. I still like the manual Linux VPN kill switch in a lab because I can inspect every rule and deliberately test failure.

My Parrot OS and VMware Linux VPN Config

I mainly use Parrot OS in VMware, with Kali Linux available when I want to compare behavior. Both are Debian-based, so the nftables and WireGuard concepts translate well. The exact Linux VPN config still depends on your own network stack, especially the uplink name, DNS manager and VPN profile.

My wider lab also includes a Cudy WR3000 routing through Proton VPN WireGuard with Secure Core. I treat that router layer and the VM-level Linux VPN kill switch separately: router protection does not prove that a WireGuard profile inside the VM fails closed when its own interface changes state.

I use WireGuard because Linux routing and firewall tools can inspect its tunnel interface directly. For the firewall layer, I keep the nftables documentation nearby to verify chain hooks, policies and matching behavior.

Install the basic tools on a Debian-based lab VM:

sudo apt update
sudo apt install -y nftables wireguard-tools dnsutils curl tcpdump

I do not force-install a DNS manager. Before changing anything, I want to know whether NetworkManager, systemd-resolved, resolvconf or another component already owns DNS on that machine.

VPN Kill Switch Linux Check 1: Map the Network Path

The first safety check is boring and therefore important. Before I load a Linux VPN kill switch, I identify the normal uplink, the WireGuard interface and the VPN endpoint. If any of those three values are wrong, the firewall can be perfectly valid syntax and still enforce the wrong policy.

sudo nft list ruleset
ip route
ip -br link
sudo wg

In my VMware VM the uplink may appear as ens33, but yours could be eth0, enp0s3, wlan0 or something else. A VPN kill switch Ubuntu guide that tells everyone to paste one interface name is already making an assumption it cannot guarantee.

ip route show default

grep -E '^(Address|DNS|Endpoint|AllowedIPs)' /etc/wireguard/protonnl.conf

The WireGuard Endpoint line contains the server address and UDP port. Do not assume the port is always 51820. If the endpoint is a hostname, resolve it before a strict output policy blocks normal DNS:

getent ahostsv4 YOUR-ENDPOINT-HOSTNAME | head -n 1

HackersGhost Note: The mistakes I distrust most are hard-coded values copied from somebody else’s laptop. A Linux VPN kill switch should be strict about your real network, not strict about somebody else’s screenshot.

VPN Kill Switch Linux Check 2: Build a Fail-Closed nftables Policy

The earlier version of this guide used sudo nft flush ruleset. I no longer use that as a starting point. It clears the entire nftables ruleset, including rules created for other services. My Linux VPN kill switch should be removable without bulldozing unrelated firewall configuration.

Create a working directory:

mkdir -p "$HOME/vpn/scripts"

Then create $HOME/vpn/killswitch.nft. Replace the uplink, endpoint IP and port with values from your own profile:

define vpn_if = "wg0"
define uplink_if = "ens33"
define vpn_endpoint = 185.159.0.10
define vpn_port = 51820

table inet hg_vpnks {
  chain input {
    type filter hook input priority 0;
    policy drop;

    iifname "lo" accept
    ct state established,related accept
    iifname $vpn_if accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy drop;

    oifname "lo" accept
    oifname $vpn_if accept
    oifname $uplink_if ip daddr $vpn_endpoint udp dport $vpn_port accept
  }
}

This Linux VPN kill switch allows ordinary outbound traffic through wg0. The encrypted WireGuard packets themselves receive one narrow exception to reach the server over the normal uplink. Everything else reaches the end of the output chain and is dropped.

I deliberately do not add a broad outbound ct state established,related accept rule. If I activate the policy while an old non-VPN connection already exists, I do not want “established” to become a permanent VIP pass around the Linux VPN kill switch.

For a persistent desktop setup, the uplink may also need tightly scoped local traffic such as DHCP renewal. My lab test starts narrow. If you add exceptions, document why each exists instead of opening the local network “just in case.”

Linux VPN Kill Switch iptables vs nftables

A Linux VPN kill switch iptables policy can work, and the wg-quick manual even shows an iptables-based kill-switch pattern. I prefer nftables here because one inet table can handle both IPv4 and IPv6 traffic, and I can delete my own table without clearing everything else.

VPN Kill Switch UFW: Is It a Valid Alternative

Yes. A VPN kill switch UFW setup can be perfectly reasonable on a desktop where UFW is already your normal firewall interface. I use nftables in this guide because I want to see the exact base chains, default-drop policy and endpoint exception. The goal is not to declare one frontend magically secure; the goal is to understand the path your packets are allowed to take.

VPN Kill Switch Linux Check 3: Protect DNS and IPv6

A public IPv4 address from the VPN is reassuring, but it is not the whole test. My Linux VPN kill switch also has to stop resolver traffic and IPv6 from quietly using an unprotected path when WireGuard goes down.

Find the DNS Manager Before You Change It

resolvectl status 2>/dev/null || true
cat /etc/resolv.conf
ls -l /etc/resolv.conf

If NetworkManager controls DNS, inspect the active connection with nmcli. If /etc/resolv.conf is a symlink, check its target. I do not overwrite resolver files until I know which service owns them; otherwise Linux may quietly rewrite my “fix.”

Use the DNS and IPv6 Values From Your VPN Profile

Current Proton WireGuard profiles can include IPv4 and IPv6 settings. That matters for a Proton VPN kill switch Linux test because an old profile or copied tutorial may not represent what the current generated configuration actually contains. I trust the active profile first.

grep -E '^(Address|DNS|Endpoint|AllowedIPs)' /etc/wireguard/protonnl.conf
ip -6 route
ip -6 addr

With the output policy from Check 2, ordinary DNS that tries to leave through the uplink is already blocked. DNS-over-HTTPS is different because it travels over HTTPS, but the Linux VPN kill switch still forces that HTTPS traffic through wg0 while the tunnel is active and blocks it when the tunnel is gone.

If your VPN profile carries IPv6, test it through the tunnel. If it does not, confirm that the default-drop policy prevents native IPv6 from escaping through the uplink. I prefer testing that behavior over disabling IPv6 reflexively and hoping the problem has become somebody else’s problem.

HackersGhost Note: I no longer treat DNS as a separate decorative checkbox. In my Linux VPN kill switch tests, DNS is simply another packet path that must obey the same fail-closed rule.

How to Test DNS & WebRTC Leaks: 7 Sneaky Checks

VPN Kill Switch Linux Check 4: Add Simple Control Scripts

I want the controls for a Linux VPN kill switch to be boring: on, off and status. When networking breaks, boring is excellent. I do not want a clever Bash script hiding five assumptions behind a cheerful green message.

$HOME/vpn/scripts/kill-on

#!/usr/bin/env bash
set -euo pipefail

sudo nft delete table inet hg_vpnks 2>/dev/null || true
sudo nft -f "$HOME/vpn/killswitch.nft"

echo "[kill-on] VPN fail-closed policy active."

$HOME/vpn/scripts/kill-off

#!/usr/bin/env bash
set -euo pipefail

sudo nft delete table inet hg_vpnks 2>/dev/null || true

echo "[kill-off] HackersGhost VPN table removed."

$HOME/vpn/scripts/kill-status

#!/usr/bin/env bash
set -euo pipefail

echo "=== HackersGhost nftables table ==="
sudo nft list table inet hg_vpnks 2>/dev/null || echo "Kill-switch table not loaded."

echo
echo "=== WireGuard ==="
sudo wg || true

echo
echo "=== Default route ==="
ip route show default

chmod +x "$HOME/vpn/scripts/kill-on"
chmod +x "$HOME/vpn/scripts/kill-off"
chmod +x "$HOME/vpn/scripts/kill-status"

The useful part is what kill-off does not do. It removes only hg_vpnks. That keeps the Linux VPN kill switch isolated from unrelated nftables rules that may belong to another service.

Optional Panic Mode

I also keep an optional panic table for moments when I want all networking stopped. It is separate from the normal Linux VPN kill switch: the normal policy allows the VPN path; panic mode allows nothing.

table inet hg_panic {
  chain input {
    type filter hook input priority -100;
    policy drop;
  }
  chain forward {
    type filter hook forward priority -100;
    policy drop;
  }
  chain output {
    type filter hook output priority -100;
    policy drop;
  }
}

Test panic mode only from a local console. If a remote shell disappears after you block every packet, the firewall is simply following instructions with uncomfortable enthusiasm.

VPN Kill Switch Linux Check 5: Force the VPN to Fail

This is the check that turns a Linux VPN kill switch from configuration into evidence. I first verify a healthy tunnel, then I tear it down while the firewall remains active.

"$HOME/vpn/scripts/kill-on"
sudo wg-quick up protonnl

sudo wg
ip route
curl -4 https://ifconfig.co ; echo
dig example.com

I check for a recent WireGuard handshake and transferred bytes. I confirm the public IP belongs to the VPN path, then check DNS and IPv6. After that, I create the failure:

sudo wg-quick down protonnl

curl --max-time 5 https://example.com
dig example.com

Those requests should fail while the Linux VPN kill switch remains active. Your ordinary default route can still exist; the firewall is what refuses to use it for normal internet traffic. If curl succeeds, I stop there and troubleshoot instead of declaring victory because the VPN icon looked reassuring five minutes earlier.

Watch the Uplink With tcpdump

sudo tcpdump -ni ens33

Replace ens33 with your actual uplink. In another terminal, generate a web request while WireGuard is down. I expect not to see that ordinary destination traffic escape over the uplink. Local-link noise can still exist, so I focus on whether the test request itself gets out.

VPN Kill Switch OpenVPN: Does the Same Test Apply

Yes, the failure principle is the same for a VPN kill switch OpenVPN setup: identify the tunnel interface, identify the remote VPN endpoint, restrict the normal uplink and then deliberately stop the tunnel. The exact interface and process behavior differ from WireGuard, so do not paste WireGuard-specific rules into an OpenVPN setup without adjusting them.

If you prefer Proton’s own Linux app rather than a manual WireGuard profile, its built-in kill switch is the easier route. I use the manual Linux VPN kill switch mainly when I want the lab value of seeing and testing the policy myself.

Proton Unlimited combines Proton VPN with Proton Mail, Proton Drive and Proton Pass, which is why I find it more useful than evaluating the VPN subscription in isolation.

VPN Kill Switch Linux Check 6: Test Server and Profile Switching

A Linux VPN kill switch that works with one server can still fail operationally when you change profiles. The firewall exception is pinned to an endpoint IP and port. If profile B uses a different endpoint from profile A, profile B may be blocked before it can create the tunnel.

I prefer a small nftables file per profile rather than one enormous rule collection. The relationship stays obvious:

sudo wg-quick down protonnl 2>/dev/null || true
sudo nft delete table inet hg_vpnks 2>/dev/null || true
sudo nft -f "$HOME/vpn/killswitch-be.nft"
sudo wg-quick up protonbe

Then I repeat the public IP, DNS, IPv6 and forced-disconnect checks. The phrase Proton VPN kill switch Linux often leads people to the app setting, but a manually pinned endpoint has a different maintenance requirement: when the profile changes, the firewall assumption may need to change too.

I also test suspend/resume and a VMware adapter bounce. Those are realistic transitions in my own lab. If the VM wakes up with a changed route or interface state, the Linux VPN kill switch should still refuse a normal fallback path.

VPN Kill Switch Linux Check 7: Make It Persistent Only After Testing

I delay persistence because a temporary networking mistake is easy to undo from the console. The same mistake automatically loaded after every boot is how a five-minute Linux VPN kill switch experiment becomes an evening appointment with recovery mode.

sudo cp /etc/nftables.conf /etc/nftables.conf.backup 2>/dev/null || true
sudo nft list ruleset
sudo systemctl status nftables

I do not blindly export the entire live ruleset into /etc/nftables.conf. Other software can create dynamic rules that were never meant to become permanent. I prefer a reviewed static include or a dedicated service that loads only my Linux VPN kill switch file.

Before enabling that service, I test recovery: can I remove the table locally, boot without the service after a typo and identify which file owns the rules? Persistence comes last.

Linux VPN Ubuntu, Parrot and Kali: What Changes

The core Linux VPN kill switch logic is portable: allow the tunnel, allow only what is required to establish that tunnel, then drop other outbound traffic. What changes between distributions is usually the surrounding plumbing.

• Linux VPN Ubuntu: NetworkManager and systemd-resolved are common, so inspect DNS ownership before editing resolver files.
• Parrot OS: this is where I do most of my own testing, usually inside VMware with a virtual Ethernet uplink.
• Kali Linux: the nftables and WireGuard concepts remain the same, but I still verify interface names and networking state rather than copying them from Parrot.

That is also why I prefer this guide to read like a Linux VPN howto rather than a distro-specific recipe. The commands give you a working model, but the safety comes from validating your own interfaces, routes and endpoints.

How Routers Break OPSEC Without You Noticing

Why I Prefer nftables for a Linux VPN Kill Switch

I do not claim nftables is the only correct answer. An iptables VPN kill switch, a VPN kill switch UFW policy or a provider-native kill switch can all be valid. nftables fits my workflow because I can read the default-drop policy, keep IPv4 and IPv6 in one inet table and delete only the rules I created.

That visibility matters in my ethical-hacking VM. With VMware routing, a local VPN and a router VPN all present, the Linux VPN kill switch answers one specific question: if this VM’s tunnel fails, can ordinary traffic leave through its uplink? I prefer proving that answer.

Linux VPN Kill Switch Not Working: What I Check First

When a Linux VPN kill switch does not behave as expected, I check assumptions before rewriting everything. Most failures are ordinary configuration mismatches wearing a mysterious hat.

• Wrong uplink: the rules allow ens33, but the real default route uses another interface.
• Wrong VPN endpoint: the server IP or UDP port in the nftables file does not match the active WireGuard profile.
• Hostname rotation: a provider hostname resolves to a new IP while your manual rule still pins the old address.
• Overly broad exception: a rule intended to help the tunnel connect also allows ordinary traffic outside it.
• DHCP or local infrastructure: an extremely narrow persistent policy can interrupt lease renewal or other required local traffic if you never accounted for it.
• IPv6 forgotten: IPv4 is tested while IPv6 is left to improvise.
• DNS misunderstood: operating-system DNS, browser DNS-over-HTTPS and provider DNS are related but not identical.
• Profile switching: the firewall still allows profile A’s endpoint while you are trying to start profile B.
• Persistence enabled too early: an untested rule loads automatically and makes recovery harder.

HackersGhost Note: The strongest improvement I made to this guide was not another firewall rule. It was removing assumptions. A Linux VPN kill switch becomes easier to trust when every interface, endpoint and failure test comes from the machine in front of me.

My Final Linux VPN Kill Switch Checklist

1. Confirm the current uplink, WireGuard interface, endpoint IP and UDP port.
2. Load only the dedicated hg_vpnks table and leave unrelated firewall rules alone.
3. Connect the VPN and verify handshake, public IP, DNS and IPv6 behavior.
4. Disconnect WireGuard while the Linux VPN kill switch stays active and confirm web and DNS traffic fail.
5. Watch the uplink with tcpdump during the failure test.
6. Repeat after a reconnect, server switch, adapter change and VM suspend/resume.
7. Only then decide whether the policy should load automatically.

That is the difference between installing a firewall rule and verifying a Linux VPN kill switch. I want the machine to have an obvious protected path when the VPN is up and no ordinary internet path when it is down. The commands are not the interesting part by themselves; the repeated failure test is what turns the configuration into something I can actually trust in my lab.

If you want the provider side to stay simple while keeping the manual firewall work as a learning layer, Proton Unlimited is still the package I use as the natural fit around Proton VPN.

Proton Unlimited brings Proton VPN, Proton Mail, Proton Drive and Proton Pass together in one subscription, which makes sense if you already use several Proton services rather than only the VPN.

Frequently Asked Questions