Moving from ipset to nftables - Revision history

Pablo at 11:01, 28 June 2021

2021-06-28T11:01:54Z

← Older revision		Revision as of 11:01, 28 June 2021
Line 27:		Line 27:
	add element inet global myset { 172.16.0.1 . tcp . 80 . 10.0.0.1 }		add element inet global myset { 172.16.0.1 . tcp . 80 . 10.0.0.1 }
	</source>		</source>

			The translation utility defines a dummy ''inet'' table whose name is ''global'', you can mangle this output to make it fit into your existing ruleset.

	Now, you have to manually translate the rules that contain ''-m set'' in your ruleset:		Now, you have to manually translate the rules that contain ''-m set'' in your ruleset:

Pablo: incorrect ipset-translate syntax in example

2021-06-28T11:00:00Z

incorrect ipset-translate syntax in example

← Older revision		Revision as of 11:00, 28 June 2021
Line 10:		Line 10:

	<source lang="bash">		<source lang="bash">
	ipset-translate restore sets.ipset ~~> sets.nft~~		ipset-translate restore < sets.ipset
	</source>		</source>

Pablo: update article to document the new ipset-translate utility

2021-06-28T10:58:39Z

update article to document the new ipset-translate utility

← Older revision		Revision as of 10:58, 28 June 2021
Line 1:		Line 1:
	If you use [[ipset]] with iptables, you need to consider the following when [[Moving from iptables to nftables \| moving 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~~.		* Since ipset 7.12, there is the ''ipset-translate'' utility that automatically transform ipsets into nftables [[Sets\|sets]]. This utility translates ipset set types into nftables set data types, which will often result in [[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''.

	* ~~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~~''.		* 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''.

			* After the initial translation, it is recommended to have a look at nftables [[Maps\|maps]] and [[Verdict_Maps_(vmaps)\|verdict maps]] to make your ruleset more efficient.

	* 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''.		The translation from ipset to nftables is straightforward with the ''ipset-translate'' utility:

	* You can often use nftables [[Maps\|maps]] and [[Verdict_Maps_(vmaps)\|verdict maps]] to make your ruleset more efficient.		<source lang="bash">
			ipset-translate restore sets.ipset > sets.nft
			</source>

	Following is an example of translating a basic iptables/ipset configuration into nftables.		Following is an example of translating a basic iptables/ipset configuration into nftables.
Line 13:		Line 17:
	Here is the iptables/ipset setup:		Here is the iptables/ipset setup:
	<source>		<source>
	user@debian:~ $ sudo ipset save		user@debian:~ $ sudo ipset save > sets.ipset
			user@debian:~ $ sudo cat sets.ipset
	create myset hash:ip,port,ip family inet hashsize 1024 maxelem 65536		create myset hash:ip,port,ip family inet hashsize 1024 maxelem 65536
	add myset 172.16.0.1,tcp:80,10.0.0.1		add myset 172.16.0.1,tcp:80,10.0.0.1

			user@debian:~ $ sudo ipset-translate restore < sets.ipset
			add table inet global
			add set inet global myset { type ipv4_addr . inet_proto . inet_service . ipv4_addr; size 65536; }
			add element inet global myset { 172.16.0.1 . tcp . 80 . 10.0.0.1 }
			</source>

			Now, you have to manually translate the rules that contain ''-m set'' in your ruleset:

			<source lang="bash">
	user@debian:~ $ sudo iptables-save		user@debian:~ $ sudo iptables-save
	# Generated by iptables-save v1.8.3 on Wed Oct 30 11:26:41 2019		# Generated by iptables-save v1.8.3 on Wed Oct 30 11:26:41 2019
Line 28:		Line 42:

	The above translates into nftables as:		The above translates into nftables as:

	<source>		<source>
	user@debian:~ $ sudo nft list ruleset		user@debian:~ $ sudo nft list ruleset

Fmyhr: 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.

2021-02-18T10:45:08Z

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.

← Older revision		Revision as of 10:45, 18 February 2021
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 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 examples]].

	== See also ==		== See also ==

Fmyhr: dictionaries -> verdict maps

2021-02-12T10:56:29Z

dictionaries -> verdict maps

← Older revision		Revision as of 10:56, 12 February 2021
Line 3:		Line 3:
	* There are no translation/compat tools right now to help in the task. This may change in the future.		* 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''')		* 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.		* 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.		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.
Line 69:		Line 69:
	* [[Concatenations]]		* [[Concatenations]]
	* [[Sets]]		* [[Sets]]
	* [[Dictionaries]]
	* [[Maps]]		* [[Maps]]
			* [[Verdict_Maps_(vmaps) \| Verdict maps]]
	* [[Legacy xtables tools]]		* [[Legacy xtables tools]]

Arturo: add more examples, migrated from Concatenations page

2019-10-30T10:45:33Z

add more examples, migrated from Concatenations page

← Older revision		Revision as of 10:45, 30 October 2019
Line 42:		Line 42:

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

			We recommend reading information about [[Concatenations \| concatenations]]. Some additional ipset datatype equivalents:

			'''hash:net,net'''

			<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 }
			</source>

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

			<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 }
			</source>

			'''hash:net,iface'''

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

			This syntax may be compacted in the future to support CIDR notation.

	== See also ==		== See also ==

Arturo: add example

2019-10-30T10:40:58Z

add example

← Older revision		Revision as of 10:40, 30 October 2019
Line 6:		Line 6:

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

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

			That would translate into nftables as follows:

			<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 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 ==		== See also ==

Arturo: add link to legacy xtables tools

2018-06-20T14:11:29Z

add link to legacy xtables tools

← Older revision		Revision as of 14:11, 20 June 2018
Line 13:		Line 13:
	* [[Dictionaries]]		* [[Dictionaries]]
	* [[Maps]]		* [[Maps]]
			* [[Legacy xtables tools]]

Arturo: create page with basic content

2018-02-01T10:16:24Z

create page with basic content

New page

If you are [[Moving from iptables to nftables | 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.

== See also ==

* [[Concatenations]]
* [[Sets]]
* [[Dictionaries]]
* [[Maps]]