iptables to nftables Migration: Tools, Compatibility & Best Practices

Introduction

The Linux kernel’s packet filtering framework has undergone a fundamental transformation over the past decade. While iptables has served as the backbone of Linux firewall configuration since 2001, its successor nftables — introduced in kernel 3.13 and made the default in major distributions since 2019 — offers a unified, more efficient replacement. However, migrating thousands of iptables rules accumulated over years of production use is not a trivial exercise. This guide compares the three primary migration approaches: the iptables-nft compatibility layer, the iptables-translate tool, and native nftables rule authoring.

The Case for Migration

iptables has well-known architectural limitations that nftables addresses directly:

• Unified framework: iptables requires separate utilities for IPv4 (iptables), IPv6 (ip6tables), ARP (arptables), and bridging (ebtables). nftables replaces all four with a single nft command.
• Performance: iptables evaluates rules linearly across multiple tables and chains. nftables uses a more efficient expression-based evaluation engine with just-in-time compilation that can significantly reduce packet processing overhead.
• Atomic rule updates: iptables applies rules one at a time, creating windows of inconsistent firewall state. nftables supports atomic rule-set replacement — the entire ruleset is loaded in a single transaction.
• Reduced kernel/userspace overhead: iptables communicates each rule to the kernel individually via the legacy setsockopt interface. nftables uses netlink-based communication with batched operations.

For production environments running hundreds of rules, the performance improvement alone justifies the migration effort. Benchmarks show nftables consuming 30-50% less CPU for equivalent rule sets under high packet rates.

Migration Path Comparison

There are three main strategies for moving from iptables to nftables. Each has different trade-offs in terms of effort, compatibility, and long-term benefits.

Comparison Table

Approach 1: iptables-nft Compatibility Layer

The iptables-nft package (also known as iptables-over-nftables) provides a drop-in replacement for the legacy iptables binaries. Under the hood, it translates iptables commands into nftables bytecode before sending them to the kernel. From the user’s perspective, existing scripts and tools continue to work unchanged.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Install iptables-nft on Debian/Ubuntu
sudo apt install iptables-nft arptables-nft ebtables-nft

# Verify the nft backend
sudo update-alternatives --set iptables /usr/sbin/iptables-nft
sudo iptables -V
# Output: iptables v1.8.9 (nf_tables)

# Check that rules are stored as nftables
sudo iptables -L -n
sudo nft list ruleset

Advantages:

• Zero script changes required
• All existing iptables rules continue to work
• Gradual transition path — you can switch the backend first, then migrate rules later

Limitations:

• Performance remains similar to legacy iptables (translating rules adds overhead)
• No access to nftables-specific features (sets, maps, verdict maps)
• Some rarely-used iptables extensions have incomplete nft translation

Approach 2: iptables-translate Tool

The iptables-translate utility converts individual iptables rules into native nftables syntax. It is included with iptables >= 1.6.2 and is ideal for understanding what your rules look like in the new format.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Translate individual rules
sudo iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Output: nft add rule ip filter INPUT tcp dport 22 counter accept

sudo iptables-translate -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Output: nft add rule ip filter FORWARD ct state established,related counter accept

# Translate NAT rules
sudo iptables-translate -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
# Output: nft add rule ip nat POSTROUTING ip saddr 192.168.1.0/24 oifname "eth0" counter masquerade

# Batch translation of a saved ruleset
sudo iptables-save > /tmp/iptables-rules.v4
# Then use the nft equivalent
sudo iptables-nft-save > /tmp/rules-translated.nft

Advantages:

• Learn nftables syntax incrementally
• Identify rules that don’t have direct translations
• Useful for validating translations before applying them

Limitations:

• Does not handle complex rule sets with custom chains automatically
• Requires manual verification of translations
• Some iptables features (like recent module) need manual rewriting

Approach 3: Native nftables Rule Authoring

For maximum performance and flexibility, writing native nftables rules is the recommended long-term approach. The syntax is more expressive and often more readable than iptables once you become familiar with it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Basic firewall with nftables
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0; policy drop; }
sudo nft add chain inet filter forward { type filter hook forward priority 0; policy drop; }
sudo nft add chain inet filter output { type filter hook output priority 0; policy accept; }

# Allow loopback
sudo nft add rule inet filter input iif lo accept

# Allow established connections
sudo nft add rule inet filter input ct state established,related accept

# Allow SSH, HTTP, HTTPS
sudo nft add rule inet filter input tcp dport { 22, 80, 443 } accept

# Rate limit ICMP
sudo nft add rule inet filter input ip protocol icmp limit rate 10/second accept

# NAT/masquerading
sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority 100; }
sudo nft add rule ip nat postrouting oifname "eth0" masquerade

# Save and restore
sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables

Named sets — a powerful nftables feature with no iptables equivalent:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Define a set of allowed IPs
sudo nft add set inet filter allowed_ips { type ipv4_addr; }

# Add elements
sudo nft add element inet filter allowed_ips { 10.0.0.0/8, 172.16.0.0/12, 192.168.1.100 }

# Use in rules
sudo nft add rule inet filter input ip saddr @allowed_ips accept

# Dynamic updates without reloading the whole ruleset
sudo nft add element inet filter allowed_ips { 192.168.1.200 }

Verdict maps — another nftables innovation:

1
2
3

sudo nft add map inet filter port_actions { type inet_service: verdict; }
sudo nft add element inet filter port_actions { 22: accept, 80: accept, 443: accept, 8080: drop }
sudo nft add rule inet filter input tcp dport vmap @port_actions

Migrating Docker and Kubernetes Firewall Rules

Container orchestration platforms add their own iptables rules for networking, load balancing, and port mapping. Understanding how these interact with nftables is critical for production migrations.

Docker with nftables: Docker 20.10+ uses iptables-nft by default on systems where nftables is the primary backend. No configuration changes are needed — Docker automatically detects the backend and uses the compatibility layer.

1
2
3
4
5
6

# Verify Docker is using nft backend
sudo iptables -V
# iptables v1.8.9 (nf_tables)

# Check Docker rules appear in nftables
sudo nft list ruleset | grep -i docker

Kubernetes with nftables: kube-proxy in iptables mode works transparently with iptables-nft. However, for new clusters, consider Calico or Cilium which can interact with nftables natively through BPF — bypassing iptables entirely.

1
2
3
4
5

# Check kube-proxy mode
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode

# If using iptables mode, verify nft backend
kubectl exec -n kube-system $(kubectl get pod -n kube-system -l k8s-app=kube-proxy -o name | head -1) -- iptables -V

Why Self-Host Your Firewall with nftables?

Managing your own firewall rules with nftables rather than relying on cloud provider security groups or managed firewalls gives you full control over your network security posture. Cloud provider firewalls typically offer a limited subset of filtering capabilities — basic IP/port rules with static configurations. With nftables, you can implement sophisticated filtering logic including connection tracking, dynamic rate limiting, geo-IP filtering, and application-layer inspection that cloud firewalls simply cannot match.

For self-hosted environments, nftables integrates seamlessly with other infrastructure components. The atomic rule update capability means you can push complex rule changes across dozens of servers simultaneously without risking intermediate inconsistent states. This is particularly valuable when managing firewall management frameworks that programmatically generate rule sets.

The performance benefits are especially noticeable on edge devices and low-power hardware — common in self-hosted setups. nftables’ just-in-time compilation can process equivalent rule sets using 30-50% less CPU than legacy iptables, freeing resources for your actual services. Combined with connection tracking tools, nftables provides enterprise-grade firewall capabilities that were previously only available with dedicated hardware appliances.

For environments that require persistent firewall configuration across reboots, integrating nftables with iptables rule persistence frameworks ensures your carefully crafted rules survive system restarts. The trend across all major Linux distributions is clear: nftables is the future. Ubuntu, Debian, RHEL 8+, Fedora, and Arch Linux have all made nftables the default backend. If you’re building new infrastructure today, starting with nftables avoids a future migration.

FAQ

Is iptables being removed from Linux?

No. iptables (the user-space tool) and the legacy kernel API are maintained for backward compatibility. However, the kernel-side nf_tables framework supersedes the older x_tables framework for new development. Major distributions have switched to iptables-nft as the default backend, but legacy iptables remain available via the iptables-legacy package.

Can I run iptables and nftables simultaneously?

Technically yes — the kernel allows both frameworks to coexist. However, this creates a confusing split-brain situation where rules from one framework are invisible to the other. The iptables-nft compatibility layer is the recommended way to run legacy iptables scripts alongside nftables, as both are backed by the same nf_tables engine and share the same rule state.

What happens to my fail2ban or Docker iptables rules?

fail2ban version 0.11+ supports nftables natively with the banaction = nftables setting. Docker 20.10+ detects the nftables backend automatically and uses iptables-nft. Most tools that generate iptables rules work transparently through the compatibility layer — no changes required to your fail2ban jails or Docker Compose configurations.

How do I revert to legacy iptables if something breaks?

Switch back with the alternatives system:

1
2

sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

Your existing nftables rules will remain in the kernel but won’t interfere with legacy iptables processing. This provides a safe rollback path while you debug any issues.

Do I need to restart services after migrating?

No. The firewall backend change is transparent to applications — they see the same filtering behavior regardless of whether iptables-legacy or nftables processes the packets. However, test your rule set thoroughly in a staging environment before migrating production systems. Key things to verify: NAT/masquerading, port forwarding, Docker published ports, VPN passthrough, and custom chain-based rules.

How do nftables sets improve performance?

Sets replace the pattern of multiple individual iptables rules with a single lookup operation. For example, instead of 100 individual iptables -A INPUT -s 10.0.1.1 -j ACCEPT rules, you define one set containing all 100 IPs and a single nftables rule that checks membership. The kernel implements sets using efficient hash tables, making lookups O(1) regardless of set size — a massive improvement over linear iptables rule evaluation.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到加密货币监管，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测科技事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com