Don’t let your nftables sets blow up when your VPN client restarts

Networking & Firewalls (Nftables/Iptables/WireGuard)

Don’t let your nftables sets blow up when your VPN client restarts

Technical Briefing | 9/19/2026

WireGuard is great because it is quiet, but that silence is exactly why it is a pain to manage with static firewall rules. If you bind your nftables rules to an interface that only exists when the tunnel is up, you are going to have a bad time the moment your connection drops and the interface disappears. I have seen more than one production box drop traffic into a void because the ruleset failed to load after a transient network blip.

Why static interface names are a trap

The kernel is perfectly happy to let you define rules for an interface that isn’t currently active, but it won’t always handle the state transition gracefully during a configuration reload. If you hardcode the wg0 interface into your primary ruleset, your configuration file becomes a ticking time bomb. The moment that interface vanishes, your load command starts returning non-zero, and you are left with either a partial firewall or, worse, a locked-out state.

nft add element inet filter vpn_peers { 10.0.0.5 }

  • Move peer IPs into an anonymous or named set instead of individual rule lines
  • Use interface index lookups if you absolutely must reference the device name
  • Wrap your nftables reload logic in a script that checks for the interface existence first
  • Stop assuming the interface will be present when your automation triggers

Instead of hardcoding interfaces, use sets. By decoupling your policy from the physical or virtual device presence, you shift the complexity to the data plane. You can update the set dynamically while the firewall is running without needing to trigger a full re-parse of your main config file. It keeps your rules clean and prevents the firewall from crashing just because a remote peer decided to change its IP or the tunnel went down for a few seconds.

If you really want to be safe, stick to using marks for your WireGuard traffic. Once you mark the packets based on the port they arrive on, you can forget about the interface name entirely. That way, when the tunnel flaps, the rest of your firewall logic stays exactly where it belongs: working.

Linux Admin Automation  |  © www.ngelinux.com  |  9/19/2026

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Newest
Oldest Most Voted