View source for Moving from ipset to nftables

If you use [[ipset]] with iptables, you need to consider the following when [[Moving from iptables to nftables | moving to nftables]]:

* There are no tools or compatibility layers that automatically transform ipsets into nftables [[Sets|sets]]. The translation is typically straightforward, but you must do it manually.

* You will need to translate ipset set types into nftables set data types, which will often be [[Concatenations | concatenated]] types. For example, an ipset of type ''hash:net,port,net'' becomes an nftables set of type ''ipv4_addr&nbsp;.&nbsp;inet_service&nbsp;.&nbsp;ipv4_addr''.

* nftables sets do not support negated elements, as with ipset ''nomatch''. To translate an ipset that has ''nomatch'' elements you can use a pair of nftables sets, one for the usual positive elements and one for negated elements, along with compound rule expressions like ''ip&nbsp;saddr&nbsp;@pos_set&nbsp;&nbsp;ip&nbsp;saddr&nbsp;!=&nbsp;@neg_set''.

* You can often use nftables [[Maps|maps]] and [[Verdict_Maps_(vmaps)|verdict&nbsp;maps]] to make your ruleset more efficient.

Following is an example of translating a basic iptables/ipset configuration into nftables.

Here is the iptables/ipset setup:
<source>
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
</source>

The above translates into nftables as:
<source>
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
	}
}
</source>

Note that we have used an nftables [[Verdict_Maps_(vmaps)|verdict&nbsp;map]], which takes action directly from each map element. Using such powerful new structures can greatly reduce the number of rules required by your filtering policy, compared with iptables/ipset.

We recommend reading about [[Concatenations | concatenations]].

Here are some additional examples of nftables equivalents for some ipset data types:

'''hash:net,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . ip daddr vmap { 10.10.10.0/24 . 10.10.20.0/24 : accept }
</source>

'''hash:net,port,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . tcp dport . ip daddr vmap { 10.10.10.0/24 . 80 . 10.10.20.0/24 : accept }
</source>

'''hash:net,iface'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . iif vmap { 10.10.10.0/24 . eth0 : accept }
</source>

NOTE that before Linux kernel 5.6 and nftables 0.9.4 the CIDR notation used above was not yet available. If you are unable to upgrade, you can work around this limitation as noted in the [[Concatenations#Network_addresses|concatenation&nbsp;examples]].

== See also ==

* [[Concatenations]]
* [[Sets]]
* [[Maps]]
* [[Verdict_Maps_(vmaps) | Verdict maps]]
* [[Legacy xtables tools]]