Moving from iptables to nftables: Difference between revisions

From nftables wiki
Jump to navigation Jump to search
(dictionaries -> verdict maps)
 
Line 8: Line 8:
* [[List of available translations via iptables-translate tool]]
* [[List of available translations via iptables-translate tool]]


After the migration process, you are encouraged to implement new nftables mechanisms such as sets, maps, dictionaries, concatenations and more.  
After the migration process, you are encouraged to implement new nftables mechanisms such as sets, maps, [[Verdict_Maps_(vmaps) | verdict maps]], concatenations and more.  


== command translation ==
== command translation ==

Latest revision as of 11:53, 12 February 2021

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, verdict maps, 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.

See also