Firewall on KnightLi Blog

Understanding the nftables Framework: Tables, Chains, Rules, and Sets

Sat, 18 Apr 2026 10:31:12 +0800

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:

Base chain: attached to a hook in the kernel network path and actively called by the packet flow.
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:

First decide which family the rules belong to.
Then decide which table they should go into.
Choose the proper hook and chain.
Write the concrete rule.
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

nftables Quick Start: Tables, Chains, Rules, and Common Operations

Sat, 18 Apr 2026 10:22:07 +0800

nftables is a common packet filtering and firewall rule management tool on Linux. If you only need device access control, traffic counters, port matching, or basic rate limiting, you do not need to learn the entire rule system at once. Start with three concepts:

table: a container for rules.
chain: where rules are evaluated, usually attached to a hook.
rule: the actual matching condition and action.

This article outlines a minimal workflow that is suitable for testing first in a safe environment.

Basic Structure

Prepare a few variables first. The following commands reuse them:

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

Create an inet table that supports both IPv4 and IPv6:

`1`	`nft add table inet $table`

Then create a chain attached to the forward stage:

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

Here, type filter means this is a filtering rule chain, and hook forward means it processes forwarded packets.

Common Matching Methods

Match by source IP. This is usually useful for the upload direction:

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

Match by destination IP. This is usually useful for the download direction:

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

When matching by MAC address, ether saddr can be used to control upstream traffic:

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

Note that in networks involving bridging, forwarding, or address translation, downstream packets may not always be reliably filtered by destination MAC. For device access control, start by validating ether saddr or IP-based rules first.

To match ports, you can cover both TCP and UDP:

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

To match a port range, use a comparison expression:

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

Count Traffic for One Device

If you only want to count upload and download traffic for an IP address, use counter return. After a match, it records the counter and returns, which can reduce further matching overhead when more statistic rules exist later.

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

View the statistics:

`1`	`nft list chain inet $table $chain`

If you need to see the handle for each rule, add -a:

`1`	`nft -a list chain inet $table $chain`

handle is important because nftables usually relies on it to delete a single rule.

Basic Rate Limiting

Rate limiting can be done with limit rate over. For example, limit traffic over a specified rate by MAC address:

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

Here, mbytes and kbytes can be understood as the usual M and K units. You do not need to manually multiply by 8. In practice, start with a more relaxed value, confirm the matching direction and effect, then tighten it if needed.

Delete and Clean Up Rules

First list rules with handle values:

`1`	`nft -a list chain inet $table $chain`

Then delete a rule by handle:

`1`	`nft delete rule inet $table $chain handle <handle>`

Flush a chain:

`1`	`nft flush chain inet $table $chain`

Delete a chain:

`1`	`nft delete chain inet $table $chain`

Delete the entire table:

`1`	`nft delete table inet $table`

During daily debugging, only clean up the table you created yourself. Avoid directly changing tables automatically generated by the system or other services. This makes rollback easier even if a rule is written incorrectly.

Usage Notes

When using nftables, it is often safer to create your own independent table and chain first. This has two benefits:

Your rules are less likely to mix with existing system rules.
Debugging, flushing, and deletion are safer.

After writing rules, always use nft list chain to check actual matching behavior. MAC, interface, port, and rate-limit rules may behave differently across devices, bridge setups, and system versions. Small-scope testing is safer than writing complex rules all at once.

References

https://www.right.com.cn/forum/thread-8369750-1-1.html