Difference between revisions of "Moving from ipset to nftables"

From nftables wiki
Jump to navigation Jump to search
(dictionaries -> verdict maps)
(Edited for clarity. Added note about missing ipset nomatch equivalent. Used CIDR notation in ending examples, with link to work-around for earlier nft/kernels.)
Line 1: Line 1:
If you are [[Moving from iptables to nftables | moving from iptables to nftables]] and you used [[ipset]], some considerations should be taken into account.
If you use [[ipset]] with iptables, you need to consider the following when [[Moving from iptables to nftables | moving to nftables]]:


* There are no translation/compat tools right now to help in the task. This may change in the future.
* 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.
* 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 [[Maps | maps]] and [[Verdict_Maps_(vmaps) | verdict maps]], 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.
* 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 . inet_service . ipv4_addr''.


Here is an example. This is a basic ipset/iptables setup:
* 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 saddr @pos_set  ip saddr != @neg_set''.


* You can often use nftables [[Maps|maps]] and [[Verdict_Maps_(vmaps)|verdict 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>
<source>
user@debian:~ $ sudo ipset save
user@debian:~ $ sudo ipset save
Line 24: Line 27:
</source>
</source>


That would translate into nftables as follows:
The above translates into nftables as:
 
<source>
<source>
user@debian:~ $ sudo nft list ruleset
user@debian:~ $ sudo nft list ruleset
Line 41: Line 43:
</source>
</source>


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.
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]].


We recommend reading information about [[Concatenations | concatenations]]. Some additional ipset datatype equivalents:
Here are some additional examples of nftables equivalents for some ipset data types:


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


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


Line 54: Line 58:


<source lang="bash">
<source lang="bash">
% nft add rule tablename chainname ip saddr and 255.255.255.0 . tcp dport . ip daddr and 255.255.255.0 vmap { 10.10.10.0 . 80 . 10.10.20.0 : accept }
% 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>
</source>


Line 60: Line 64:


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


This syntax may be compacted in the future to support CIDR notation.
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 ==
== See also ==

Revision as of 11:45, 18 February 2021

If you use ipset with iptables, you need to consider the following when moving to nftables:

  • There are no tools or compatibility layers that automatically transform ipsets into nftables 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 concatenated types. For example, an ipset of type hash:net,port,net becomes an nftables set of type ipv4_addr . inet_service . 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 saddr @pos_set  ip saddr != @neg_set.
  • You can often use nftables maps and verdict 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:

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

The above translates into nftables as:

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 we have used an nftables verdict 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.

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

hash:net,net

% nft add rule tablename chainname ip saddr . ip daddr vmap { 10.10.10.0/24 . 10.10.20.0/24 : accept }

hash:net,port,net

% nft add rule tablename chainname ip saddr . tcp dport . ip daddr vmap { 10.10.10.0/24 . 80 . 10.10.20.0/24 : accept }

hash:net,iface

% nft add rule tablename chainname ip saddr . iif vmap { 10.10.10.0/24 . eth0 : accept }

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 concatenation examples.

See also