On current Debian and RHEL, the iptables command is a compatibility front-end that writes nftables rules into the kernel. What does that change about how rules are stored, and what goes wrong on a host where some software still uses the legacy iptables backend?
answer
- two engines, one set of hooks
- the familiar command is now a front-end
- each tool lists only its own store
- the kernel enforces the union of both
- one backend per host, decided deliberately
basics
~20 sThe iptables command translates classic syntax into nf_tables rules, so one ruleset holds everything. The legacy binaries write to the older x_tables subsystem instead; if both are in use, each tool shows only half the rules while the kernel enforces both.
solid answer
~50 sThere are two rule engines in the kernel: the older `x_tables`, which classic iptables drives, and `nf_tables`, which `nft` drives. On current distributions the `iptables` binary is really `iptables-nft`, a translation layer that accepts the familiar syntax and stores the result as nftables rules — `iptables -V` prints which variant you have. The trap is coexistence. If one piece of software installs rules through the legacy backend while an administrator or firewall tool uses the nft backend, each side lists only its own rules, so both look correct and incomplete. The kernel registers both at the same hooks and evaluates both, so a drop in either one stops the packet — which is how you get traffic blocked by a rule that nothing in your tooling shows. The rule is to standardise on one backend per host and to check what any software that manages its own firewall rules is using.
go deeper
Know that the familiar iptables command on current distributions no longer drives the old engine — it writes nftables rules underneath — and that a newer tool exists for managing them directly.
Explain the two kernel engines, what the compatibility front-end translates, and name what nftables adds: unified address families, native sets, and loading a whole ruleset atomically.
Show you have been bitten: rules can live in both stores, each tool lists only its own, and the kernel enforces the union — so a drop you cannot see in your tool of choice is a real and common outage cause.
Own the migration and the standard: which backend the fleet uses, how hosts are audited for rules in the other store, and what is required of any software permitted to install its own firewall rules.
## Two engines, one hook set Netfilter's hook points are stable, but the machinery that evaluates rules at them has been replaced. The original engine is `x_tables`, driven by the classic `iptables`, `ip6tables`, `arptables` and `ebtables` tools, with its fixed tables and per-protocol separation. The newer engine is `nf_tables`, driven by `nft`, which replaces the fixed structure with user-defined tables, a virtual machine for rule evaluation, and first-class sets and maps. Both register at the same hooks. That is the crux of the coexistence problem below. ## What the compatibility front-end does Rather than force every script, tool and muscle memory to be rewritten, distributions ship `iptables-nft`: a binary that speaks the classic command-line syntax and the classic listing format, but stores what you asked for as nf_tables rules. It creates tables with the familiar names — filter, nat, mangle — at the conventional priorities, so behaviour matches. Current Debian and RHEL select this variant by default through the alternatives system, and both variants remain installed; `iptables -V` reports whether you are running the `nf_tables` or `legacy` build. There is also a translation helper that converts classic command lines into their nft equivalents, which is the practical migration path for an existing ruleset. The compatibility is good but not total: because rules are stored natively, `nft` shows the translated form, and constructs written directly in nftables — sets, maps, multiple hooks in one chain — have no classic representation, so `iptables` cannot display them. ## The coexistence failure The damaging scenario is a host where rules exist in *both* engines. - Software that manages its own firewall rules may invoke the legacy binaries explicitly, or ship with them statically linked. - An administrator using `nft` sees a clean ruleset and concludes nothing else is filtering. - The kernel, meanwhile, evaluates both engines at each hook. The result is that neither tool shows the whole picture, and because a drop verdict is terminal, a rule you cannot see in your preferred tool can silently discard traffic. Debugging this consists of listing both — the nft ruleset and the legacy ruleset explicitly — and reconciling. It is a genuinely nasty class of incident precisely because the primary diagnostic tool lies by omission. The remedy is policy, not cleverness: pick one backend per host, verify which variant the packaged tools resolve to, and check what any component that installs its own rules is doing before it is deployed. ## Why nftables was worth the disruption Three improvements justify the migration. **Unified families.** A chain in the `inet` family handles IPv4 and IPv6 in one place, instead of maintaining parallel `iptables` and `ip6tables` rulesets that drift apart. **Sets and maps.** Classic chains are evaluated linearly, so matching one address out of ten thousand meant ten thousand comparisons. nftables offers native sets with efficient lookup, and maps that select a verdict or a translation from a key. Large rulesets stop scaling linearly with the number of entries. **Atomic replacement.** A whole ruleset can be loaded from a file in one transaction — it either applies completely or not at all. There is no window in which the firewall is half-configured, which was a real hazard when reloading a large iptables ruleset rule by rule. ## What to say in an interview Name the two engines, say that the familiar command is now a front-end onto the newer one, and go straight to the operational consequence: rules can exist in both stores, each tool shows only its own, and the kernel enforces the union. That is the part that costs people an outage; the feature list is secondary.
- How do you tell which backend the iptables command on a host is using?`iptables -V` prints the variant in its version string — either the nf_tables build or the legacy one. Distributions keep both installed and select between them through the alternatives system, so the answer can differ between hosts of the same family. On a host you did not build, check it before trusting any rule listing you take from it.
- Why do sets and maps matter for large nftables rulesets?Classic chains are walked linearly, so blocking ten thousand addresses meant up to ten thousand comparisons per packet. nftables stores such collections as native sets with efficient lookup, and maps go further by selecting a verdict or translation from a key. Rule count stops being proportional to entry count, which changes what is feasible on a busy box.
- What does atomic ruleset replacement buy you over reloading iptables rules?The whole ruleset is applied in one transaction: it takes effect completely or not at all. Reloading a classic ruleset incrementally leaves a window in which the firewall is partially configured — often flushed then rebuilt — during which traffic is evaluated against an incomplete policy. Atomic replacement removes that window, which matters most on the exact hosts where a mistake is expensive.
- If rules exist in both engines on one host, which set wins?Neither — both are evaluated at the same hooks, so the effect is the union. Since a drop is terminal, any engine's drop stops the packet regardless of what the other permits. That makes the situation hard to reason about and worse to debug, because each tool's listing looks complete. The fix is to converge on a single backend, not to reason about ordering.
saying these in an interview costs you the question
- Thinks nftables rules replace legacy ones automatically
- Assumes one tool's listing shows every rule
- Believes only one backend can be active at a time
- Treats iptables and iptables-nft as different syntaxes
- Says nftables is just a renamed iptables