Moving from ipset to nftables: Difference between revisions
(add more examples, migrated from Concatenations page) |
(dictionaries -> verdict maps) |
||
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 | * 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]] | ||
* [[Maps]] | * [[Maps]] | ||
* [[Verdict_Maps_(vmaps) | Verdict maps]] | |||
* [[Legacy xtables tools]] | * [[Legacy xtables tools]] |
Revision as of 11:56, 12 February 2021
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 maps and 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.
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.
We recommend reading information about concatenations. Some additional ipset datatype equivalents:
hash:net,net
% 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 }
hash:net,port,net
% 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 }
hash:net,iface
% nft add rule tablename chainname ip saddr and 255.255.255.0 . iif vmap { 10.10.10.0 . eth0 : accept }
This syntax may be compacted in the future to support CIDR notation.