iptables Rule Builder

iptables in depth: tables, chains, targets, and persistent firewall rules

iptables is the userspace interface to the netfilter framework inside the Linux kernel. It groups firewall rules into tables, each table has chains (rule lists hooked to a specific point of the packet path), and each rule sends matched traffic to a target (ACCEPT, DROP, REJECT, etc.). Although nftables is the official replacement since kernel 3.13, iptables is still by far the most widely deployed Linux firewall in production. This generator helps you produce syntactically correct commands; you remain responsible for testing in a lab and for not locking yourself out of a remote host.

Tables and chains

• filter (default) — chains INPUT (traffic addressed to the host), OUTPUT (traffic generated locally), FORWARD (traffic routed through the host).
• nat — chains PREROUTING (rewrite destination before routing), POSTROUTING (rewrite source after routing), OUTPUT. Used for NAT, port forwarding, masquerading.
• mangle — modify packet fields (TOS, TTL, MARK).
• raw — runs before conntrack; used to set NOTRACK.
• security — SELinux-aware rules.

Command syntax and common targets

The general form is iptables -t <table> -A <chain> <match> -j <target>. Important commands: -A append, -I insert at top, -D delete, -L list, -F flush, -N new user chain, -P set default policy. Common targets:

• ACCEPT — let the packet through.
• DROP — silently discard.
• REJECT — discard and send an ICMP error (more visible, less stealth).
• LOG — copy headers to dmesg/syslog (often combined with --log-prefix).
• MASQUERADE — SNAT to the egress interface IP (typical for home gateways).
• DNAT / SNAT — rewrite destination or source IP/port.
• RETURN — leave a user chain and continue in the parent.

Worked examples

# Allow established/related (keep return traffic working)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from a trusted /24
iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 22 -j ACCEPT

# Web server
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# Log and drop everything else
iptables -A INPUT -j LOG --log-prefix "INPUT_DROP: " --log-level 4
iptables -A INPUT -j DROP

# Set default policies (after allowing what you need!)
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Share a connection (NAT)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Port forward 80 -> internal 10.0.0.5:8080
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.0.0.5:8080

Persisting rules across reboots

iptables rules are kept in kernel memory and disappear on reboot. To persist them, dump and restore on boot:

# Debian/Ubuntu
apt install iptables-persistent
iptables-save  > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

# RHEL/CentOS family (legacy)
service iptables save

# Generic systemd
iptables-save > /etc/iptables.rules
# add a unit that runs `iptables-restore < /etc/iptables.rules`

Modern alternatives

nftables is the official successor: a single binary (nft), unified syntax for IPv4/IPv6, atomic ruleset updates, named sets. Prefer it on new deployments. firewalld (RHEL/Fedora) and ufw (Ubuntu) are high-level wrappers — they generate iptables/nftables rules under the hood and are easier for desktop or single-server use. For container hosts, Docker, Podman and Kubernetes inject their own iptables rules; never run a blanket iptables -F on a Docker host or you will break every container network.

Authorised and educational use

iptables is defensive in nature, but misconfigured firewalls can be just as harmful as no firewall. Always: (1) test in a VM or container before applying on a remote host; (2) keep a rescue script scheduled with at now + 5 minutes that flushes the firewall, so you cannot lock yourself out via SSH; (3) document policies and review them periodically. In pentest engagements, document any changes you make to filtering rules and revert at the end.

FAQ

Does iptables replace ufw? No — ufw is a wrapper that translates simpler commands (ufw allow 22) into iptables/nftables rules. Use one or the other, not both.

Should I migrate to nftables? On new servers, yes — it is the modern replacement. On existing fleets, iptables still works perfectly and the kernel translates it via iptables-nft internally.

Order matters? Yes — rules are evaluated top-down and the first match wins. Put high-traffic ACCEPTs near the top and broad DROPs at the bottom.

Why did I lose SSH? Likely because you set -P INPUT DROP before adding an ACCEPT rule for port 22. Always allow SSH first or schedule a flush via at.

Does it break cron or Docker? Not directly. But iptables -F on a Docker host flushes the chains Docker created (DOCKER, DOCKER-USER) and breaks container networking until the daemon recreates them.