When learning nftables, it is easy to start with command details: how to add a rule, how to delete a handle, or how to write a port match. Commands matter, but if you understand the framework first, reading rules, troubleshooting, and designing rule sets become much easier.

You can think of nftables as a layered structure:

• table isolates rule namespaces.
• family decides which network protocols the rules apply to.
• chain decides at which stage rules are executed.
• rule defines the actual match and action.
• set, map, and verdict map reduce repeated rules and make rule sets easier to maintain.

The following sections explain these concepts layer by layer.

table: Rule Namespace

table is the outermost rule container in nftables. Different tables are isolated from each other, so a common practice is to put related rules into the same table.

For example, you can separate filtering rules, NAT rules, or custom testing rules. This keeps boundaries clear: when debugging, you know which group of rules you are changing; when cleaning up, you are less likely to delete unrelated content by mistake.

A table itself does not directly process packets. The chain and rule objects inside the table are what actually participate in packet processing.

family: Which Protocols the Rules Apply To

When creating a table, you need to choose a family. It determines what kind of packets the rules in the table apply to.

Common families can be understood this way:

• ip: handles IPv4 only.
• ip6: handles IPv6 only.
• inet: handles both IPv4 and IPv6.
• arp: handles ARP.
• bridge: handles bridge-layer traffic.
• netdev: closer to the network device ingress path, suitable for handling traffic at an earlier stage.

For ordinary firewall rules, inet is commonly used. It lets you keep IPv4 and IPv6 rules in the same table and avoids maintaining two similar rule structures.

chain: Where Rules Are Executed

chain is a list of rules. After a packet enters a hook, it passes through the rules in the chain in order.

Chains can roughly be divided into two types:

1. Base chain: attached to a hook in the kernel network path and actively called by the packet flow.
2. Regular chain: not directly attached to a hook; it must be called by jumps from other rules.

A base chain usually specifies several key properties:

• type: the purpose of the chain, such as filter, nat, or route.
• hook: the processing stage, such as prerouting, input, forward, output, or postrouting.
• priority: when multiple chains exist on the same hook, this decides which runs first.
• policy: the default action when no rule matches, commonly accept or drop.

The key point is that rules do not take effect just anywhere. The same rule has completely different meaning when placed in input, forward, or output.

rule: Match Conditions Plus Actions

rule is where nftables actually makes decisions. It usually consists of two parts:

• Match conditions: source IP, destination IP, protocol, port, interface, connection state, and so on.
• Actions: accept, drop, reject, counter, jump, return, and so on.

Rules are evaluated in order. After a packet matches an action that terminates processing, subsequent rules are no longer evaluated. If nothing matches, evaluation continues until the chain ends or the default policy is triggered.

This is why rule order matters: more specific rules usually need to appear before broader rules, otherwise they may never get a chance to run.

set: Group Values Together

If you need to match many IP addresses, ports, or interfaces, writing many separate rules becomes hard to maintain. set lets you manage a group of values of the same type in one place.

For example, a group of trusted IPs, a group of blocked ports, or a group of addresses that need rate limiting can all be stored in a set. The rule only needs to check whether a value belongs to that set.

The benefits of set are:

• Fewer rules.
• Better readability.
• Easier element additions and removals later.

When a rule set contains many repeated conditions, it is usually time to consider set.

map: Map a Matched Value to a Result

map can be understood as a lookup table. It returns a result based on an input value.

For example, different ports can map to different marks, or different addresses can map to different processing parameters. Compared with writing many if/else-style rules, map is more centralized and easier to maintain.

set answers “is this value in the collection”; map answers “what result corresponds to this value”.

verdict map: Map a Matched Value to an Action

verdict map is an important use of map: it maps a matched value to a verdict, which means a rule action.

For example, different IP ranges can correspond to accept, drop, or jumps to different chains. This can compress many branches into one structure.

When a rule set grows more complex, verdict map is very useful. It reduces repeated rules and expresses policy more like a table rather than a long list of conditional statements.

Designing Rules from the Concepts

When designing nftables rules, you can think in this order:

1. First decide which family the rules belong to.
2. Then decide which table they should go into.
3. Choose the proper hook and chain.
4. Write the concrete rule.
5. If there are many repeated conditions, introduce set, map, or verdict map.

Rules written this way are easier to maintain and easier to troubleshoot.

Summary

nftables concepts are not complicated, but the hierarchy matters:

• table defines rule boundaries.
• family defines protocol scope.
• chain defines execution position.
• rule defines matching and action.
• set, map, and verdict map manage complexity.

Understand these concepts first, then look at concrete commands. That is more reliable than memorizing commands directly. Especially after a rule set grows, clear concepts help you determine whether a problem is in protocol scope, execution stage, rule order, or the match condition itself.

References

• https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework