Host firewalls: nftables rule order, connection tracking and packet evidence
Explain nftables host filtering through hooks, base-chain priority and tracked connection state. Diagnose an allowed connection that is later dropped, and distinguish new-session rules from existing-session revocation.
TL;DR: Identify the packet's hook, tuple and tracked state before reading firewall rules. Rules run in order within a chain, and an accept in one base chain can still meet a drop in a later chain. Established-session allowances can outlive the intended policy change.
Start with the packet as the host sees it
For traffic terminating on the host, the input hook is relevant. Forwarded traffic uses the forward hook; locally generated traffic uses output. A container, bridge, proxy or address translation can change both the path and the addresses visible at a given stage. A rule matching the original client address is useless at a point where a proxy has created a different connection.
Inventory the active rules and their owners before editing. A distribution firewall manager, container runtime and Kubernetes networking component may all contribute configuration. Read the full ruleset, including base-chain hook and priority. The nftables chain guide explains ordering: lower numeric priorities run earlier at the same hook. Do not depend on an ordering between equal-priority base chains.
An accept finishes the current chain's decision, but another base chain can still reject the packet. Drop is terminal. This is why finding one matching allow rule is insufficient evidence that the host admitted traffic.
Established state changes rule interpretation
Connection tracking records flow state. A rule matching established,related can admit packets associated with tracked traffic before they reach a later port-specific rule. “Established” describes the tracking subsystem's view; it does not mean the user is still authorized by the application. See stateful matching.
This deliberately narrow example is for a disposable network namespace, not a complete host policy. It admits loopback, tracked traffic and new IPv4 connections from one subnet to TCP 8443. It omits administrative access and the ICMP/IPv6 rules a real deployment may require. Do not apply it to the machine you are using for remote access.
table inet dip_lab {
chain input {
type filter hook input priority 0; policy drop;
iifname "lo" accept
ct state invalid drop
ct state established,related accept
ip saddr 10.42.0.0/24 tcp dport 8443 accept
}
}
Removing the final allow rule blocks new matching sessions, but traffic already matching the established rule may continue. Urgent revocation needs an explicit plan for existing flows, with narrow scope and an independent administrative recovery path. A host-wide connection-state flush can interrupt unrelated services.
Diagnose the change with two kinds of probe
Use a fictional maintenance case: the team removes a subnet allowance, opens a fresh terminal, and sees a new connection fail. An existing connection continues exchanging data. Those outcomes are consistent with the example's rule order, rather than proof that the configuration failed to load.
Test both a fresh connection and a connection held open across the change. Record the source/destination tuple and whether NAT altered it. Compare rule counters around the probe, then use a scoped packet trace if needed. The nftables packet tracing mechanism follows rule evaluation; enabling tracing broadly can generate excessive output.
| Observed result | Possible boundary | Evidence to collect |
|---|---|---|
| New sessions fail; old one works | Established-state allowance | Tracked state and rule order |
| Early allow counter grows; packet still fails | Later chain or downstream path | Remaining hooks/chains and packet capture |
| No relevant rule counter changes | Wrong path, tuple or namespace | Routing, interface and namespace |
| SYN reaches service; no useful reply | Listener or return path | Socket state and reply capture |
Counters are cumulative. A busy allow rule's total does not prove it matched your particular probe; compare deltas with sufficiently narrow matching and preserve timestamps.
Describe a bounded correction
The useful interview answer identifies who owns the conflicting chain and proposes a reviewed change there. Adding an earlier accept cannot defeat a later drop, and bypassing a firewall manager's source configuration can produce a temporary fix that disappears on reload. Verify the persisted configuration after the intended management tool reapplies it.
Self-check: base chain A accepts TCP 8443 at priority 0. Base chain B, at priority 10 on the same hook, has a drop policy and no matching allowance. Will A's accept deliver the packet? No. The packet proceeds into B and is dropped. Inspect the whole hook path before adding another duplicate allow to A.