Moving from ipset to nftables

If you are moving from iptables to nftables and you used ipset, some considerations should be taken into account.

• There are no translation/compat tools right now to help in the task. This may change in the future.
• ipset uses explicit set types, like hash:net,port,net which you need to translate to nftables native data types (like ipv4_addr . inet_service . ipv4_addr)
• nftables support mappings and dictionaries, so you could take actions directly from matching elements in the set.

In most cases, direct equivalencies can be found of ipset features. In most cases, it worth evaluating nftables native features to benefit from them when migrating from ipset to nftables.

Here is an example. This is a basic ipset/iptables setup:

user@debian:~ $ sudo ipset save
create myset hash:ip,port,ip family inet hashsize 1024 maxelem 65536
add myset 172.16.0.1,tcp:80,10.0.0.1

user@debian:~ $ sudo iptables-save
# Generated by iptables-save v1.8.3 on Wed Oct 30 11:26:41 2019
*filter
:INPUT ACCEPT [3:212]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:250]
-A INPUT -m set --match-set myset src,dst,dst -j ACCEPT
COMMIT

That would translate into nftables as follows:

user@debian:~ $ sudo nft list ruleset
table inet filter {
	map myset {
		type ipv4_addr . inet_service . ipv4_addr : verdict
		elements = { 172.16.0.1 . 80 . 10.0.0.1 : accept }
	}

	chain input {
		type filter hook input priority filter; policy accept;
		meta nfproto ipv4 ip saddr . tcp dport . ip daddr vmap @myset
	}
}

Note that nftables is capable of storing verdict information per set element, which can drastically reduce the amount of rules required in the ruleset compared to iptables/ipset.

See also

• Concatenations
• Sets
• Dictionaries
• Maps
• Legacy xtables tools