iptables Commands

Listing Rules

Everything needs root. -n skips DNS lookups, -v adds packet counters, --line-numbers gives you the numbers used for deleting.

SSH Lockout

This is the one that costs you the server. iptables -P INPUT DROP with no rule allowing port 22 kills the session you are typing in, not just the next login, because the policy applies to the packets carrying your keystrokes. The same thing happens when you flush a ruleset while the policy is already DROP, since -F removes the SSH allow rule and leaves the DROP in place. Add the allow rules first, set the policy last.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -L INPUT -n -v --line-numbers   # confirm the SSH rule is live
# only now, once port 22 is open:
sudo iptables -P INPUT DROP

Set up the deadman switch before the first DROP, not after, and cancel it once a new login works. If sshd listens on a non-standard port, open that port instead and check it from outside with the SSH port checker. A DROP policy shows up as a timeout (Network error: Connection timed out), a REJECT rule as connection refused. The nftables and UFW sheets have the same trap in their own syntax, and the firewall rule generator writes a ruleset that already has the SSH rule in it.

Allowing Traffic

Order matters: rules match top down, first match wins. Allow SSH before anything drops.

A minimal safe INPUT policy, in the right order:

sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
sudo iptables -P INPUT DROP

The firewall rule generator builds rule sets like this from a checklist.

Blocking Traffic

DROP discards the packet silently, so the client hangs until it times out; REJECT answers with an error, so the client fails fast with connection refused. DROP gives port scanners nothing, REJECT is kinder for services your own users hit. If SSH suddenly gets connection refused, look for a REJECT rule. For blocklists of more than a handful of addresses, or a whole country, see IP Sets below.

Adding and Deleting Rules

-A appends to the bottom, -I inserts at the top (or a position). Since first match wins, a rule appended after a DROP does nothing.

Rule numbers shift after every delete. Deleting several by number goes highest first, or re-list between deletes.

Rule Order

Inside a chain the first matching rule wins and evaluation stops, so a rule you append below an existing ACCEPT or DROP never runs. Chains run in a fixed order too, which is why NAT happens before your filter rules ever see the packet.

Two consequences worth remembering: a DNAT rewrite in PREROUTING happens first, so a FORWARD rule has to match the internal address, not the public one; and a packet accepted in INPUT never reaches FORWARD, which is why Docker's published ports are invisible to your INPUT rules.

Tables and Chains

A rule lives in a chain, a chain lives in a table. -t filter is the default, which is why NAT rules seem to disappear until you ask for their table.

Flushing Rules

-F deletes all rules but does not touch chain policies. If the policy is DROP, flushing locks you out of SSH instantly. Safe order:

# 1. Open the policies first, so an empty ruleset allows everything:
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
# 2. Now flush:
sudo iptables -F
sudo iptables -X          # delete custom chains
sudo iptables -t nat -F   # nat and mangle have their own rules
sudo iptables -t mangle -F

Keep the current SSH session open and test a fresh login before closing it. When rebuilding, the first rule you add back is the SSH allow, and the deadman switch in SSH Lockout above costs nothing.

NAT and Port Forwarding

NAT rules live in the nat table and need forwarding enabled in the kernel first:

sudo sysctl -w net.ipv4.ip_forward=1
# permanent: echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-forward.conf

Forward port 80 arriving on this box to an internal server:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.5:80
sudo iptables -A FORWARD -p tcp -d 10.0.0.5 --dport 80 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

A forward that does nothing is almost always ip_forward left at 0, a FORWARD chain with no matching ACCEPT, or a test run from the box itself: locally generated traffic never passes through PREROUTING, so test from another host or with the SSH port checker.

Saving Rules

Rules live in kernel memory and are gone after a reboot unless something restores them.

IP Sets

ipset keeps thousands of addresses in one kernel hash, so a blocklist costs you one rule instead of one rule per address, and matching stays fast as it grows.

sudo apt install ipset
sudo ipset create blocklist hash:net
sudo ipset add blocklist 198.51.100.0/24
sudo iptables -I INPUT -m set --match-set blocklist src -j DROP

Country blocking works the same way: build a hash:net set from an aggregated zone file and point one DROP rule at it. The xt_geoip module from xtables-addons does it without a set, but the database needs updating by hand and it is a per-packet lookup. nftables has sets built into the ruleset, with no second tool to install or save; see the nftables cheat sheet.

Logging and Rate Limiting

Logged packets land in the kernel log: journalctl -k | grep IPT-DROP or dmesg. fail2ban inserts its bans into its own chain at the top of INPUT, so its rules are why a chain sometimes has entries you did not add.

IPv6

ip6tables is a second, independent firewall with the same syntax. Locking down IPv4 on a service that also listens on IPv6 closes half the door.

nftables' inet family covers both stacks in one rule, which is the main day-to-day reason to move.

Docker

Docker writes its own chains and publishes container ports through FORWARD and the DOCKER chain, bypassing INPUT entirely. A container run with -p 8080:80 is reachable from the internet even when your INPUT rules say only 22 is open.

Setting {"iptables": false} in /etc/docker/daemon.json stops the bypass but breaks container networking in other ways, so almost nobody keeps it. Full container commands are on the Docker cheat sheet.

Common Errors

nftables and Front Ends

nftables is the successor; new setups should use it or a front end rather than raw iptables.

Convert whole rule sets with the iptables to nftables converter, or write one rule for iptables, nft, UFW, and firewalld at once with the firewall rule generator. The nftables cheat sheet has the native syntax side by side with these commands. If all you want is ports opened and closed on one server, UFW is the simpler front end and manages this layer for you.

Gotchas

• Mixing tools bites: ufw, firewalld, and Docker all write their own iptables or nftables rules, so a rule you add by hand can be shadowed by theirs or wiped on their reload. nft list ruleset shows the whole truth; pick one manager per box.
• Rules are gone after a reboot unless you set up persistence. The classic failure: firewall works for months, a reboot silently drops it.
• iptables -L without -t nat hides all NAT rules, and without -n it stalls on DNS lookups.
• iptables-legacy and iptables-nft keep separate rule sets. If rules seem to be missing, the other binary may own them: check iptables -V and iptables-legacy -L -n.
• Docker publishes container ports by writing its own FORWARD and DOCKER chain rules, bypassing your INPUT rules entirely. A "closed" port can still be reachable through Docker.
• IPv6 is a separate firewall (ip6tables or the nft inet family). Locking down IPv4 while the service also listens on IPv6 locks down half the door.
• ipset contents are saved by ipset save, not by iptables-save. Restoring rules without restoring the sets leaves you with rules that match nothing, or that refuse to load at all.