Concepts and Tables

Two commands, one kernel subsystem

Modern Linux filters packets with nftables in the kernel. The iptables command you type is usually a compatibility front end that writes nftables rules.

iptables --version              # iptables v1.8.10 (nf_tables)
sudo iptables-legacy -S         # rules in the legacy tables, often empty
sudo nft list ruleset           # the real ruleset, including iptables-nft rules

Do not mix the two backends. Rules added with iptables-legacy are invisible to nft list ruleset and to iptables-nft, and both sets are evaluated by the kernel, so a "missing" rule that still blocks traffic is almost always the other backend.

What ships where

# which backend does /sbin/iptables actually point at, Debian and Ubuntu
sudo update-alternatives --display iptables
sudo update-alternatives --config iptables      # switch legacy <-> nft

# RHEL family, the service that owns the ruleset
systemctl is-active firewalld nftables iptables

On any RHEL-family box, assume firewalld owns the ruleset. Writing raw iptables rules there works until firewalld reloads and flushes them.

Tables

A table groups rules by the kind of work they do. Five exist, and most systems only use two.

sudo iptables -t filter -L -n        # -t filter is the default, so -t is optional
sudo iptables -t nat -L -n -v
sudo iptables -t mangle -S
sudo iptables -t raw -S

Chains and hooks

A chain is a list of rules attached to a point in the kernel's packet path.

                       ┌─────────────┐
   in ──> PREROUTING ──> routing?    ├──> FORWARD ──> POSTROUTING ──> out
          (nat, mangle)└──┬──────────┘   (filter)     (nat, mangle)
                          │ local                        ▲
                          v                              │
                        INPUT                          OUTPUT
                        (filter)                       (filter, nat)
                          │                              ▲
                          v                              │
                     local process ─────────────────────-┘

Two rules follow from the diagram and explain most confusion:

- Traffic to this host hits INPUT, traffic through it hits FORWARD. Blocking a port in INPUT does nothing to traffic being routed or bridged. - DNAT happens in PREROUTING, so by the time FORWARD and INPUT see the packet its destination is already the new address. Filter on the real target, not on the published one.

Rule evaluation

Rules in a chain are checked top to bottom. The first rule whose matches all succeed applies its target, and for terminating targets evaluation of that chain stops there.

If no rule matches, the chain's policy applies. Policies exist only on built-in chains, and the shipped default is ACCEPT everywhere.

sudo iptables -L INPUT -n | head -1    # Chain INPUT (policy ACCEPT)
sudo iptables -P INPUT DROP            # set the policy, see the warning below

Setting a DROP policy over SSH locks you out the instant it takes effect unless an ACCEPT rule for your own session already exists above it. Add the allow rules first, verify them, then change the policy.

Connection tracking

conntrack is what makes a stateful firewall possible. The kernel remembers flows, so replies to connections you allowed do not need their own rules.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo conntrack -L | head            # live flow table, needs conntrack-tools
cat /proc/sys/net/netfilter/nf_conntrack_count   # current entries
cat /proc/sys/net/netfilter/nf_conntrack_max     # table size

That single ESTABLISHED,RELATED rule at the top of INPUT is the foundation of every practical ruleset. Without it, a default-deny policy also blocks the answers to your own outbound connections.