Every iptables guide assumes you already know what a table is. I did not, and it cost me an afternoon of confusion. So: three concepts, in plain words, before any rule.

A packet walks into a chain

When a packet arrives, the kernel does not check one big list of rules. It walks a chain — an ordered list — and stops at the first rule that matches. Three chains matter for most setups: INPUT (packets to this box), OUTPUT (packets leaving), FORWARD (packets passing through).

A rule says match, then jump

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Read it left to right: append (-A) to INPUT, match TCP port 22, jump (-j) to ACCEPT. The -j is always a target: ACCEPT, DROP, REJECT, LOG, or another chain.

Why tables exist at all

Rules live in tables by job. filter is the default and where you will spend 99% of your time. nat rewrites addresses (port forwarding, masquerade). mangle tweaks packet fields. You can write years of firewall rules without leaving filter.

The order trap

Rules are checked top to bottom, and the first match wins. This rule blocks everything, because it is first:

iptables -A INPUT -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT   # never reached

The accept has to come before the drop. When a rule does not behave, check the order before you check the syntax — it is the beginner mistake I made every single time.

Look before you lock yourself out

iptables -L -n -v          # list rules with packet counts
iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT  # insert at the TOP, so it wins

On a remote box, always insert your SSH accept at position 1 before you append anything scary. And remember the golden rule of firewall work: the rules are gone on reboot unless you save them.

apt install iptables-persistent   # Debian/Ubuntu
netfilter-persistent save

With tables, chains, targets and order under your belt, you can read any firewall script on the internet. Part 2 turns that reading skill into writing one from scratch.