iptables legacy and migration to nftables · Linux

iptables is the legacy Linux firewall tool. It is deprecated in favour of nftables but still appears in older documentation and existing rulesets. This lesson covers iptables, the migration path, and the iptables-nft compatibility layer.

Why iptables is deprecated

The Linux kernel team has merged nftables as the unified firewall API. iptables now runs as a compatibility shim over nftables. Issues with iptables:

Separate binaries for IPv4 (iptables), IPv6 (ip6tables), ARP (arptables), bridge (ebtables).
Verbose syntax with separate commands for every option.
No native transactional updates - rules apply one at a time.
Limited counters and no native sets.

nftables fixes all of these with a unified syntax, atomic updates, and better performance.

The iptables tables and chains

sudo iptables -L -n -v              # list filter table
sudo iptables -t nat -L -n -v       # list NAT table
sudo iptables -t mangle -L -n -v    # list mangle table
sudo iptables -t raw -L -n -v       # list raw table

Tables: filter (default), nat, mangle, raw, security. Chains: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING. Each chain has a default policy (ACCEPT or DROP).

A minimal iptables ruleset

# Default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow established
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from management
iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 22 -j ACCEPT

# Allow ICMP from monitoring
iptables -A INPUT -p icmp -s 10.0.0.0/24 -j ACCEPT

# Drop invalid
iptables -A INPUT -m state --state INVALID -j DROP

The -m flag loads a module (state, conntrack, multiport, etc.). The -j flag is the jump target (ACCEPT, DROP, REJECT, LOG, or a user-defined chain).

Migration to nftables

Step 1: install nftables and iptables-nft (often already installed).

Step 2: dump the iptables ruleset in a format nft can understand:

iptables-save > /tmp/iptables.rules

Step 3: translate the saved ruleset with iptables-restore-translate:

# Note the tool name: iptables-RESTORE-translate takes a file.
iptables-restore-translate -f /tmp/iptables.rules > /tmp/translated.nft

# Make the file idempotent, then check and load it.
sed -i '1i flush ruleset' /tmp/translated.nft
nft -c -f /tmp/translated.nft     # check syntax, change nothing
nft -f /tmp/translated.nft        # apply atomically

iptables-translate takes a rule, not a file

There are two translation tools and they are not interchangeable:

iptables-translate converts one rule given as command-line arguments. It has no -f option, so pointing it at an iptables-save dump fails outright:

$ iptables-translate -f /tmp/iptables.rules
Bad argument `/tmp/iptables.rules'
Try `iptables-translate -h' or 'iptables-translate --help' for more information.

Its real use is a quick one-off lookup:

iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# nft add rule ip filter INPUT tcp dport 22 counter accept

iptables-restore-translate -f FILE converts a whole iptables-save dump. This is the migration tool:

# Translated by iptables-restore-translate v1.8.11
add table ip filter
add chain ip filter INPUT { type filter hook input priority 0; policy drop; }
add rule ip filter INPUT iifname "lo" counter accept

Reaching for the wrong one mid-change-window leaves you hand-translating rules under time pressure, which is exactly how an allow rule gets dropped and a service is blackholed.

Step 4: validate the new ruleset behaves the same way. Translation is mechanical; equivalence is not. Compare the rulesets you actually intend to compare, and then test behaviour from outside the host:

# Before the change, on the still-legacy host:
nft list ruleset > /tmp/ruleset.before
sudo nmap -Pn -p- firewall-host > /tmp/scan.before   # from a peer host

# After loading /tmp/translated.nft:
nft list ruleset > /tmp/ruleset.after
diff -u /tmp/ruleset.before /tmp/ruleset.after

sudo nmap -Pn -p- firewall-host > /tmp/scan.after
diff -u /tmp/scan.before /tmp/scan.after             # must be empty

The external scan is the part that matters. It is the only check that tests the reachability your users depend on rather than the text of a config file.

iptables-nft compatibility layer

Most modern distributions ship iptables-nft, which routes iptables commands through the nftables backend:

ls -l /usr/sbin/iptables
update-alternatives --display iptables

On RHEL, the alternatives are iptables-legacy and iptables-nft. On Debian, similar.

If you have a service that hard-codes iptables commands and you want to use nftables underneath:

sudo update-alternatives --set iptables /usr/sbin/iptables-nft

iptables commands now create nftables rules transparently.

Read iptables output

iptables -L -n -v --line-numbers

Output:

num   pkts bytes target   prot opt in  out  source         destination
1    1234  100K ACCEPT   all  --  lo  any  0.0.0.0/0      0.0.0.0/0
2     987  65.2K ACCEPT   all  --  any any  0.0.0.0/0      0.0.0.0/0     state RELATED,ESTABLISHED
3       0      0 ACCEPT   tcp  --  any any  10.0.0.0/24   0.0.0.0/0      tcp dpt:22
4      42   3.5K ACCEPT   icmp --  any any  10.0.0.0/24   0.0.0.0/0

The line numbers are essential for inserting or deleting specific rules.

Persist iptables rules

# Debian/Ubuntu
sudo apt install iptables-persistent
sudo netfilter-persistent save

# RHEL family
sudo yum install iptables-services
sudo service iptables save

This saves the current rules to /etc/iptables/rules.v4 (Debian) or /etc/sysconfig/iptables (RHEL).