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

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:

1
2
3
4
5


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:

1
2
3
4


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