Moving from iptables to nftables: Difference between revisions
(Refresh page with new legacy renaming) |
(→using the nf_tables compat backend: typo hare) |
||
Line 74: | Line 74: | ||
== using the nf_tables compat backend == | == using the nf_tables compat backend == | ||
Since June 2018, the old xtables/setsockopt tools | Since June 2018, the old xtables/setsockopt tools are considered legacy. | ||
However, there is support to use the iptables/ip6tables/arptables/ebtables old syntax with the nf_tables kernel backend. | However, there is support to use the iptables/ip6tables/arptables/ebtables old syntax with the nf_tables kernel backend. |
Revision as of 15:56, 30 July 2019
This page gives information on moving/migrating from the old iptables/xtables (legacy) world to the new nftables framework.
A common situation is the need to move from an existing iptables ruleset to nftables. The Netfilter team has created some tools and mechanisms to ease in this move.
Please, make sure to check the links below:
After the migration process, you are encouraged to implement new nftables mechanisms such as sets, maps, dictionaries, concatenations and more.
command translation
You can generate a translation of an iptables/ip6tables command to know the nftables equivalent.
% iptables-translate -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
nft add rule ip filter INPUT tcp dport 22 ct state new counter accept
% ip6tables-translate -A FORWARD -i eth0 -o eth3 -p udp -m multiport --dports 111,222 -j ACCEPT
nft add rule ip6 filter FORWARD iifname eth0 oifname eth3 meta l4proto udp udp dport { 111,222} counter accept
Instead of translating command by command, you can translate your whole ruleset in a single run:
% iptables-save > save.txt
% cat save.txt
# Generated by iptables-save v1.6.0 on Sat Dec 24 14:26:40 2016
*filter
:INPUT ACCEPT [5166:1752111]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5058:628693]
-A FORWARD -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
COMMIT
# Completed on Sat Dec 24 14:26:40 2016
% iptables-restore-translate -f save.txt
# Translated by iptables-restore-translate v1.6.0 on Sat Dec 24 14:26:59 2016
add table ip filter
add chain ip filter INPUT { type filter hook input priority 0; }
add chain ip filter FORWARD { type filter hook forward priority 0; }
add chain ip filter OUTPUT { type filter hook output priority 0; }
add rule ip filter FORWARD tcp dport 22 ct state new counter accept
You should be able to directly give this to nftables:
% iptables-restore-translate -f save.txt > ruleset.nft
% nft -f ruleset.nft
% nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
tcp dport ssh ct state new counter packets 0 bytes 0 accept
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
}
}
These translate tools are included in the iptables source tarball and works for iptables and ip6tables.
using the nf_tables compat backend
Since June 2018, the old xtables/setsockopt tools are considered legacy.
However, there is support to use the iptables/ip6tables/arptables/ebtables old syntax with the nf_tables kernel backend.
This is described with further details in the Legacy xtables tools wiki page.
% iptables-nft -A FORWARD -p icmp -j ACCEPT
% iptables-nft-save
# Generated by xtables-save v1.6.0 (nf_tables) on Sat Dec 24 14:38:08 2016
*filter
:INPUT ACCEPT [62:3777]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [62:4074]
-A FORWARD -p icmp -j ACCEPT
COMMIT
# Completed on Sat Dec 24 14:38:08 2016
% nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
ip protocol icmp counter packets 0 bytes 0 accept
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
}
}
Note that translation to native nftables syntax is done if available.
In the case of some missing translation, you will see a commented rule in nftables:
% ebtables-nft -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 2, policy: ACCEPT
--802_3-type 0x0001 -j CONTINUE
--mark 0x1 -j CONTINUE
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
% nft list ruleset
table bridge filter {
chain INPUT {
type filter hook input priority -200; policy accept;
}
chain FORWARD {
type filter hook forward priority -200; policy accept;
#--802_3-type 0x0001 counter packets 0 bytes 0
#--mark 0x1 counter packets 0 bytes 0
}
chain OUTPUT {
type filter hook output priority -200; policy accept;
}
}
With these tools, the workflow could be saving the old iptables-legacy ruleset and then loading it with iptables-nft:
% iptables-save > iptables.txt
% iptables-nft-restore < iptables.txt
% iptables-nft-save
# Generated by xtables-save v1.6.0 (nf_tables) on Sat Dec 24 14:51:41 2016
*filter
:INPUT ACCEPT [19:1283]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [18:2487]
-A FORWARD -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
COMMIT
# Completed on Sat Dec 24 14:51:41 2016
% nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
ip protocol tcp tcp dport 22 ct state new counter packets 0 bytes 0 accept
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
}
}
Beware of using both the nft and the legacy tools at the same time. That means using both x_tables and nf_tables kernel subsystems at the same time, and could lead to unexpected results.