Locked Out by iptables? SSH Recovery [Solved]

What causes an iptables SSH lockout?

The most common cause is adding a DROP or REJECT rule that matches your SSH traffic before any ACCEPT rule can process it. iptables processes rules in order from top to bottom. If rule 3 drops all traffic on port 22 and rule 7 allows your IP address, rule 7 never gets evaluated.

Another frequent culprit: flushing all rules without a default ACCEPT policy. Running iptables -F clears every rule, but if your INPUT chain policy is DROP, you've just blocked everything including SSH. I handled a ticket last month where someone ran iptables -F during maintenance and couldn't understand why the server went dark.

Less obvious is blocking the ESTABLISHED,RELATED state. Many guides tell you to allow new SSH connections but forget existing ones. If your current SSH session depends on ESTABLISHED traffic and you remove that rule, you'll disconnect and won't be able to reconnect.

How do I regain access through console or VNC?

Every major hosting provider offers emergency access that bypasses network security. Look for terms like 'console,' 'VNC,' 'KVM access,' or 'remote console' in your control panel. DigitalOcean calls it the Droplet console. AWS uses EC2 Instance Connect or Session Manager. Linode has the LISH console.

Once you're in the console, log in with your root or sudo user credentials. The console connects directly to the virtual machine, so network firewall rules don't apply. From there you can run iptables -L -n -v to see current rules and iptables -F to flush them if needed.

If you're on a dedicated server with IPMI or iDRAC, those provide the same direct access. Boot the remote console interface and you'll have full keyboard and screen control as if you were physically at the machine.

What's the emergency command to restore SSH access?

The fastest fix is to flush all rules and set a permissive policy:

Run these commands in sequence through your console connection. This clears every rule and sets all chains to ACCEPT, effectively disabling the firewall. Your SSH access returns immediately.

Don't leave the server in this state. Once you reconnect via SSH, rebuild your ruleset properly or restore from a known-good backup. If you were working from a script or configuration management tool, reapply that instead of manually recreating rules.

• iptables -F (flush all rules)
• iptables -X (delete custom chains)
• iptables -P INPUT ACCEPT (set default policy)
• iptables -P FORWARD ACCEPT
• iptables -P OUTPUT ACCEPT

How do I test iptables changes safely?

Use a timed rollback pattern. This command applies your new rules, waits 60 seconds, then restores the old rules unless you cancel it:

Replace [new_rules] and [old_rules] with your actual iptables commands. If the new rules work and you can still connect, press Ctrl+C before the timer expires. If they lock you out, just wait — after 60 seconds your old rules come back and SSH access restores itself.

For more complex changes, save your current rules to a file first with iptables-save > /tmp/working-rules.txt. Then you can restore them with iptables-restore < /tmp/working-rules.txt inside your timed rollback command.

• iptables [new_rules] && sleep 60 && iptables [old_rules]

Why aren't my iptables rules persisting after reboot?

iptables stores active rules in kernel memory, not on disk. A reboot wipes them unless you've configured persistence. On Debian and Ubuntu, install the iptables-persistent package:

During installation, it asks whether to save current IPv4 and IPv6 rules. Say yes if your current rules are correct. The package writes them to /etc/iptables/rules.v4 and /etc/iptables/rules.v6, then loads them automatically at boot through the netfilter-persistent service.

On RHEL, CentOS, and Fedora, use iptables-services instead. After installing, run systemctl enable iptables to load rules from /etc/sysconfig/iptables at startup. Save your current rules with service iptables save.

• apt install iptables-persistent
• systemctl enable netfilter-persistent

What if SSH works on IPv4 but not IPv6?

IPv4 and IPv6 use separate iptables implementations. The iptables command only affects IPv4; ip6tables controls IPv6. If you locked yourself out over IPv6, your iptables rules look fine because they're not even being consulted.

Check your IPv6 rules with ip6tables -L -n -v. Many admins configure IPv4 carefully and forget IPv6 exists. I've seen production servers with wide-open IPv4 rules and a default-drop IPv6 policy that blocks everything.

Apply the same recovery steps to ip6tables: flush with ip6tables -F, set permissive policies, and save to /etc/iptables/rules.v6 once you've rebuilt the ruleset. If you don't use IPv6, disable it entirely at the network level or set all chains to ACCEPT and leave them empty.

Should I use iptables or switch to nftables?

nftables is the modern replacement for iptables and has been the default on Debian 10+, RHEL 8+, and Ubuntu 20.04+. It uses a different syntax but offers better performance and a unified interface for IPv4 and IPv6.

If you're already running iptables and it works, there's no urgent need to migrate. But new deployments should start with nftables. The iptables command still functions on modern systems through a compatibility layer that translates to nftables internally.

Recovery steps are similar: nft flush ruleset clears all rules, nft list ruleset shows current config, and /etc/nftables.conf holds persistent rules. The timed rollback pattern works exactly the same way.

How do I prevent lockouts in the future?

First, always include a rule that allows established connections at the top of your INPUT chain. This keeps your current SSH session alive even if you break the rule that allowed the initial connection.

Second, maintain a baseline ruleset in version control or a documented text file. When something goes wrong, you can quickly restore known-good rules instead of troubleshooting under pressure. I keep a firewall-baseline.sh script in every server's /root directory for exactly this reason.

Third, use configuration management tools like Ansible, Puppet, or Chef for firewall changes. They let you test in a staging environment first and provide automatic rollback if deployment fails. Manual iptables edits on production servers are always higher risk.

• iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT (always first rule)
• iptables -A INPUT -p tcp --dport 22 -j ACCEPT (allow SSH)
• iptables -A INPUT -i lo -j ACCEPT (allow loopback)
• Save working ruleset to /root/firewall-baseline.sh
• Test all changes with the timed rollback pattern before saving