In Linux netfilter — the kernel framework behind both iptables and nftables — what are the filter, nat and mangle tables for, and what changes about a packet's fate depending on which of them a rule lives in?

## What a table actually is Netfilter is the packet-processing framework inside the Linux kernel. It exposes a small number of *hook points* in the network path, and userspace tools (`iptables`, `nft`, and everything built on them such as firewalld) register rules at those hooks. A **table** is simply a named container of chains, and each chain is attached to one hook. The table name carries two pieces of meaning: what kind of verdict its rules are allowed to produce, and the priority at which its chains run relative to other tables at the same hook. In classic iptables the table set is fixed: `filter`, `nat`, `mangle`, `raw` and `security`. In nftables you create tables with any name you like and declare the hook and priority yourself, so the split is a convention rather than a kernel-imposed structure — but the conventional priorities are the same, which is why translated rulesets behave identically. ## filter — accept or drop This is the firewall in the everyday sense, and it is the default table when a table is not named. It has three chains: `INPUT` for packets addressed to a local process, `FORWARD` for packets the host is routing on behalf of someone else, and `OUTPUT` for packets a local process generated. Verdicts here are terminal: accept, drop (silently discard) or reject (discard and send an ICMP or TCP error). The commonest beginner mistake is to write a rule in `FORWARD` when the traffic is actually addressed to the host itself, and then wonder why nothing was blocked. ## nat — rewrite addresses and ports The `nat` table holds the address-translation verdicts: destination rewriting (`DNAT`, and `REDIRECT` as the special case that points at the local machine) and source rewriting (`SNAT` and `MASQUERADE`). Its chains sit at `PREROUTING`, `OUTPUT`, `POSTROUTING` and `INPUT`. The important semantic — and a favourite interview probe — is that **nat chains are not evaluated for every packet**. They are consulted only for packets whose connection-tracking state is NEW, that is the first packet of a flow. Once a translation is recorded in the conntrack entry, the kernel's NAT engine applies it to every subsequent packet of that flow, in both directions, without re-running any rule. Two consequences follow. First, you never write a reverse rule for the replies; the reverse mapping is implied. Second, the nat table is a bad place to put filtering logic, because most packets never traverse it. ## mangle — change the packet, not its fate `mangle` is present at all five hooks and is for modifying packet header fields and kernel-side metadata: setting TTL/hop limit, setting DSCP/TOS for quality-of-service, and above all setting the *firewall mark* (fwmark), a number attached to the packet or to its conntrack entry. The mark is the standard bridge between the firewall and the routing layer, since policy routing rules can select a routing table by mark. ## raw and security `raw` runs at the earliest priority of all — before connection tracking has created an entry. That is its whole point: it is where you exempt traffic from being tracked, which matters on very high-rate boxes where tracking every flow is expensive. `security` is used by SELinux for packet labelling (SECMARK) and is rarely touched by hand. ## Ordering at a shared hook Several tables can register at the same hook, so the priority decides who sees the packet first. The conventional order, lowest number first, is: raw (-300), mangle (-150), destination NAT (-100), filter (0), security (50), source NAT (100). nftables makes this explicit in the chain declaration: ``` table inet myfw { chain input { type filter hook input priority 0; policy drop; } } ``` That one line encodes what iptables expressed by the table name alone: which hook, what kind of chain, and where in the priority order it sits. ## Why the distinction is worth knowing Picking the wrong table produces rules that are syntactically valid and quietly ineffective. A drop placed in `nat` is skipped by every packet after the first. A destination rewrite placed after the routing decision cannot influence where the packet is routed. A mark set in `filter` on the wrong hook is too late for the routing lookup that was supposed to use it. Understanding tables as *purpose plus priority*, rather than as arbitrary namespaces, is what makes rule placement predictable.