You spend all afternoon crafting the perfect nftables ruleset, migrate away from that crusty old iptables script, and feel great about it. Then, you restart your WireGuard interface. For a split second, before your new rules actually kick in, your server is wide open. I learned this the hard way when a scan hit a fresh VPN node I had just hardened. It is not enough to just apply a ruleset; you have to handle the state transition.

Why the interface bounce is a security hole

When you use systemd-networkd or wg-quick to bring up an interface, the kernel creates the tunnel before your firewall rules load. If you define your ruleset in a separate file, there is a race condition where traffic flows unfiltered until the nftables service catches up. Most tutorials just suggest putting a PostUp script in your wireguard config, but that is messy and easily broken by dependency loops.

nft add rule inet filter input iifname wg0 accept

• Pre-load your firewall ruleset before the network stack initializes
• Use interface-specific jump targets to avoid global scope contamination
• Set the default policy to drop before any interface is brought up

Anchoring the rules to the namespace

The right approach is to bind your rules to the existence of the interface rather than the service order. You should define a base set of drop rules that exist from boot, then use dynamic sets in nftables to manage access. This ensures that even if you tear the interface down, the traffic that was meant for it doesn’t leak into the global forward chain or get misrouted back to the primary interface.

Check your netfilter hooks next time you migrate a stack. If you are not explicitly clearing the connection tracking table when changing firewall backends, your old rules might still be dictating the state of packets you think you just blocked. It is a subtle detail, but it is exactly the kind of thing that makes a network engineer’s life miserable at 3 AM.