A Chain Name Is Not a Hook: iptables vs nftables

Both firewalls can filter forwarded VPN traffic, and they attach rules to the packet path in different ways. iptables has built-in chains inside a table, so FORWARD exists as a named hook point. nftables separates a chain's name from its type, hook and priority, which means a regular chain called FORWARD filters nothing at all. Comparing the two models explains why an entry that looks right in one tool has no effect in the other.

A chain is a container. Whether the kernel consults it depends on the implementation and on how the ruleset attaches it.

Two Models, Two Different Attachments

In iptables, the filter table ships three built-in chains, INPUT, FORWARD and OUTPUT, and -N makes a user-defined chain that only takes effect when jumped to from one of them. The nftables manual instead defines base chains, which declare their type, hook and priority, and regular chains, which do not. A base chain can carry any name you like, and a regular chain named FORWARD gains no properties from its label. That is the whole difference, and it is invisible in a tutorial that shows only rule text.

Compatibility backends add a second reason not to infer behaviour from a command name. The iptables documentation notes operations that differ under iptables-nft, so treat native nftables, iptables-nft and a legacy ruleset as three systems rather than three spellings of one.

Read the Error in Its Real Context

A missing table, a permission failure, an unavailable kernel facility and a missing named chain are four different findings, and only one is about the chain. Record the tool version, the address family and table requested, the network namespace and the first exact error. Then check which component owns the ruleset: a firewall service or a product-managed gateway may generate its own chains and ordering. Adding a native chain beside them leaves the managed policy untouched and the inventory more confusing.

A container's namespace can hold a different ruleset from the host, so a command run in the wrong context cannot show which chain saw a forwarded packet. Raising privileges because an expected chain was not visible is not a diagnosis.

Counters Prove Reach, Not Verdict

Rule counters tell you that a rule was reached. They do not tell you that a later rule permitted the operation, and they do not prove every alternative path was denied. Read them during one harmless authorised flow, alongside rule ordering and chain attachment, and treat them as one observation rather than a verdict. A non-zero counter on a drop rule means traffic hit it; it says nothing about traffic that did not.

Kernel IP forwarding is a separate setting entirely. A chain existing does not enable forwarding, and a familiar label being absent does not mean forwarding stopped.

Describe the Flow You Expect to Protect

Write down one client request after decapsulation: its source, its destination, the address family, and whether it terminates at the gateway or passes through it. Local service input and forwarded traffic are observed at different points, so they need different rules and different tests. For a bridged VPN, verify the bridge path as well, because an IP-level chain does not automatically police Ethernet frames.

Preserve independent recovery access before changing a remote gateway. Then confirm the intended flow and the required denials under the same ruleset. A new empty chain with a familiar name is not a repair.

The comparison ends in one question: which hook does the kernel actually call for this packet? Answer that, and the chain name stops mattering.