A surviving SSH window after a firewall change does not establish that access remains available. A rule accepting established traffic can preserve that session while blocking new connections. Verification therefore needs an independent new SSH connection.
Prepare two paths before applying a change
First verify that an out-of-band recovery path, such as a remote console, is actually usable. Then preserve the current rules and identify their owners. When Docker, Tailscale or firewalld also manages rules, restoring an old whole-host snapshot can erase intervening changes. Identify the tables and scope you own.
nft --version
sudo nft list ruleset
sudo nft -c -f reviewed-change.nftreviewed-change.nft is your previously reviewed change file. The -c check does not establish that a new SSH connection will succeed. Rules may reveal internal addresses; sanitize them before sharing. The -f mechanism described in atomic rule replacement avoids partial intermediate updates, but does not validate reachability under the final policy.
A delayed rollback also needs verification
If using a delayed rollback, record its execution identity, restore file, deadline and cancellation procedure, and test it beforehand. A sleep command tied only to the current SSH shell is not a reliable guarantee after disconnection. Keep the existing session open, test a new management connection and required services from another client, then cancel the rollback.
If a new connection fails, use the prepared recovery path instead of improvising more rules. IPv4, IPv6 and cloud security rules may be separate boundaries. This article reviews the decision procedure; it does not report an actual lockout or successful rollback test.