Testing firewall changes without locking yourself out
Rank your recovery paths before the rule goes in, then verify with a flow the new policy has to evaluate rather than the session that survived.
Your rule goes in, the terminal you already have keeps answering, and the next login is refused. That gap is the whole difficulty of testing a firewall change over the connection you are changing. Connection tracking decides once and then stops looking, so an established flow is the one probe that cannot see the new policy. What follows compares the three ways back in, then fixes the order in which to change and check the rules.
Why the surviving session is the weakest evidence
A stateful firewall evaluates the first packet of a flow and keeps that verdict for as long as the entry lives. Rules added afterwards apply to flows that start later, which is why the window you are typing in stays usable while everyone else is refused. Whatever you learn from it describes the policy that was in place minutes ago. Even a capture taken on that flow shows a decision the machine already made.
Treat the working session as an escape hatch rather than a measurement. Every check worth running has to open a new flow from a source the new rule will evaluate, and the first check should be the one that would hurt most to fail. When that session is your only way in, the change is not ready to be made.
Three ways back in, ordered by what each depends on
Rank the options by how much they rely on the device under test, because that ranking is what you reach for when the rule turns out wrong. A console that never passes through the firewall is independent, a rehearsed rollback is nearly so, and the session already open is not.
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
Before the change, log in through the console and prove it works, because an out-of-band path you have never used is a diagram rather than a fallback. A rollback earns its place only after a rehearsal on that platform, with that ruleset, following the approved procedure instead of improvising on a live box. Write the steps down and have somebody else read them back. If the sequence needs your memory to complete, it is not a plan.
One change, then a connection that has to be evaluated
Save the live ruleset and the file that owns it, then make a single narrow edit. One change per test keeps the outcome attributable; two at once leave you with a working machine and no idea which edit did the work. Where the platform can parse a configuration without loading it, do that first, so a typo fails while nothing is at stake.
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.confThen start a new session from a source the changed rule will match, while the console is still attached. Repeat it once if it succeeds, because the first attempt can land on an entry the table already held. If it fails, you still have a way in and a decision to reverse, which is the cheapest bad outcome available.
Counters, state and the file answer different questions
Each of the three observations can look convincing on its own and mislead you about the other two. Counters show whether the flow you just created reached the rule you edited. The state table shows which flows the machine believes are already established, which is how a broken rule can still appear healthy. The saved file shows what the device will do after the next reload, and that may not be what the running ruleset is doing now.
ss -tn state establishedRead counters as a delta rather than a total, since the only number that matters is the one your test flow moved. A rule whose counter never increments is not matching, however right it looks on paper. Confirm the reject case as well: a policy that has never refused anything has never proved it refuses what you meant to block. Work through one interface in each family the deployment actually carries, because a v4 rule says nothing about a v6 flow.
Restore from the saved ruleset, then make the file agree
When the change fails, load the saved ruleset instead of adding permissive rules until logins work again. Each extra allow quietens the symptom and leaves a hole that outlives the incident and the memory of it. Restore, reconnect, then keep the failed comparison beside the record of what you tried.
After a successful change, make the file on disk describe the ruleset that is running, and confirm a reload reproduces it. A live ruleset that has drifted from its own configuration file is a trap set for the next reboot.