You create an nftables table, add a chain to it and add a drop rule to that chain, but the traffic is never filtered. What must an nftables chain declare before the kernel evaluates its rules, and how does a base chain differ from a regular chain?

## There are no built-in chains The first thing to internalise is that nftables ships an empty slate. There is no default table, no default chain, and no chain that exists merely because the firewall subsystem is loaded. A fresh host with `nft list ruleset` printing nothing has no rules and no chains — every table, chain and rule you want, you create. That design is deliberate: it means you pay only for what you register, and it means a chain's attachment to the packet path is an explicit, visible property rather than an implicit one. ## What makes a chain a base chain A **base chain** is a chain registered with the kernel at a packet-processing attachment point. It is created with a header clause: ```bash nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }' ``` Four things appear there, three of them mandatory: - **`type`** — `filter`, `nat` or `route`. It declares what the chain is allowed to do; a `nat` chain, for example, is the only place NAT statements belong, and the kernel only registers connection-tracking-dependent machinery where it is needed. - **`hook`** — the attachment point, named with keywords such as `prerouting`, `input`, `forward`, `output`, `postrouting` (and `ingress`/`egress` for device-level chains). Which hooks are available depends on the family. - **`priority`** — a signed integer deciding the order in which chains on the same hook run, lowest first. Keywords exist for the classic values: `raw` (-300), `mangle` (-150), `dstnat` (-100), `filter` (0), `security` (50), `srcnat` (100). Using the keyword documents intent better than a bare number. - **`policy`** — optional, `accept` (the default) or `drop`. It is the verdict applied to a packet that reaches the end of the chain without any rule deciding its fate. ## Regular chains A chain declared with no header: ```bash nft add chain inet filter ssh_checks ``` is a **regular chain**. It is not attached to anything. Its rules are evaluated only when some rule elsewhere transfers control to it: ```bash nft add rule inet filter input tcp dport 22 jump ssh_checks ``` `jump` returns to the calling chain when the target chain ends without a terminal verdict; `goto` does not return — evaluation continues at the calling chain's *hook* level, not after the calling rule. Regular chains are how you keep a large ruleset readable, and they cost nothing when the guarding match is false. They also cannot carry a policy, because a policy is meaningless for a chain that is not the last word on a packet. ## Priority and multiple base chains on one hook Several base chains — from different tables, even different families — may register on the same hook. They all run, in ascending priority order. This is where a genuine misconception bites: an `accept` verdict in one base chain terminates evaluation *of that chain*, but the packet still goes on to the next base chain on the same hook, which is free to drop it. There is no "accept wins" rule. `drop`, by contrast, is immediate and final: the packet is discarded and no further chain sees it. The practical consequence is that a packet must survive *every* base chain on its path. That is what makes a hand-written table and a firewall frontend's table interact the way they do. ## Policy runs last, not first `policy drop` is not evaluated before the rules. Rules are walked in order; the policy applies only if none of them issued a verdict. It also applies only to base chains. A frequent operational injury is loading a `policy drop` input chain over a remote session before adding the rule that permits the session — the ruleset is valid, the rules just do not cover you. ## Diagnosing the reported symptom `nft list ruleset` prints the chain header verbatim, so the check is direct: ``` table inet filter { chain input { } } ``` No `type`/`hook`/`priority` line means a regular chain that nothing jumps to — rules inside it are dead code. Add `-a` to get rule handles when you need to delete a specific rule, and remember that a chain cannot be converted in place in older nft versions: you delete and recreate it with the header, which is another reason to keep the ruleset in a file and load it atomically.