You are deep into a firewall refactor, moving from iptables to nftables, and you decide to flush the ruleset to start clean. Within seconds, your SSH session dies. It’s a classic panic move. You lose access because the default policy dropped your established connection, and now you have to hope the KVM console or out-of-band management is actually working.

The trap of the immediate flush

Most documentation tells you to just call nft flush ruleset, but that is a blunt instrument. When you run that command, the kernel immediately applies the empty ruleset, which usually defaults to dropping everything if your base chains aren’t explicitly configured to accept. Even if you aren’t resetting the policy, you’re leaving a window of vulnerability wide open or cutting your own throat by killing active state tracking.

nft add chain inet filter input { type filter hook input priority 0 \; policy accept \; } && nft flush ruleset

• Create a safety net chain with an accept policy before wiping the rest
• Use atomic transactions to prevent partial rule application during updates
• Keep a secondary management port open with a static allow rule that ignores table flushes

Why state tracking matters more than you think

The real pain starts when you forget that your SSH connection is an established packet. If your new ruleset doesn’t explicitly permit related and established traffic early in the chain, your existing session is toast the moment the rule changes commit. It’s a trivial detail, but I’ve seen more than one production outage caused by an engineer who thought the rules only applied to new incoming traffic.

Next time you are modifying production tables, write your rules to a file and load them using -f instead of piping them directly into the shell. If you syntax error your way into a locked port, you’ll be glad you weren’t running those commands interactively.