A Safe Migration Runbook from iptables to nftables

In enterprise Linux environments, the firewall layer usually falls into the “touch it and it explodes” category. iptables served us well for many years; nftables, however, brings a more consistent model on modern Linux kernels: sets, counters, more readable rule structure, and improved performance and observability.

Here is the catch: the iptables → nftables move is not just a “command swap” — it is a shift in operational risk. This runbook helps you carry out the migration not as one big bang, but with the discipline of waves + evidence + rollback.

0) Define the goal: what does “using nftables” actually mean?

In the Linux world there are two distinct realities:

1. iptables-nft (compat): the iptables command still works, but the backend is nftables.
2. native nft: rules are managed via nft, and nft list ruleset becomes the source of truth.

For many organizations the most realistic path is to first standardize the backend on iptables-nft, and only then move on to native nft.

1) Inventory: produce evidence for the question “what is actually running?”

A migration’s success is measured not against documentation of existing rules, but against real traffic evidence.

A) Export the current rule set

sudo iptables-save > /var/tmp/iptables-save.txt
sudo ip6tables-save > /var/tmp/ip6tables-save.txt

B) Classify critical chains

• north-south (internet/edge)
• east-west (intra-DC)
• management plane (SSH, API, monitoring)
• NAT/masquerade (conntrack cost)

This classification answers the question of “which flows are risky?” during the wave-based rollout.

2) Pre-migration prerequisites (prod checklist)

• Is the rollback path clear: can you revert to iptables with a single command?
• Out-of-band access exists: is the console/iDRAC/iLO/bmc path working?
• Have dependencies like DNS/NTP been validated?
• Is monitoring ready: drop, conntrack, CPU softirq, packet loss

3) Phase 1 — switch to the iptables-nft backend (low friction)

Package names differ across distributions, but the principle stays the same:

• The alternatives ship as iptables-legacy and iptables-nft.
• Goal: “have iptables commands write to the nft backend”.

Verification:

sudo iptables -V
sudo update-alternatives --display iptables 2>/dev/null || true
sudo alternatives --display iptables 2>/dev/null || true

The win at this stage: ending the mess of different backends (legacy vs nft) running across your fleet.

4) Phase 2 — switch to native nft (the real operational gain)

A) Build the nft “skeleton” (table/chain model)

A minimal skeleton looks like this:

• inet filter table
• input, forward, output chains
• policy drop + an allow list

B) Shadow counter approach

In production the highest-value signal is counters. nft gives you precise byte/packet counters at the rule level.

sudo nft list ruleset
sudo nft list ruleset -a

Do not delete or relocate critical rules until you have observed them actually receive hits.

5) Wave-based rollout: manage blast radius

My practical ordering looks like this:

1. test/lab boxes
2. low-criticality batch/worker nodes
3. internal services farthest from the edge
4. critical APIs
5. edge/NAT/gateway tier (the very last)

Define a “success criterion” for each wave:

• no drop/latency over the next 30–60 minutes
• conntrack trend stays normal
• CPU/softirq stay normal
• application error rate stays normal

6) Fast rollback (the heart of the runbook)

Do not keep rollback “in your head” — write it down.

A sample rollback approach:

1. flush the nft ruleset
2. restore from the iptables-save dump
3. re-validate the service/host

sudo nft flush ruleset
sudo iptables-restore < /var/tmp/iptables-save.txt
sudo ip6tables-restore < /var/tmp/ip6tables-save.txt

Note: these commands are illustrative. In your distribution, document how persistent rules (systemd unit, netfilter-persistent, etc.) are loaded inside the runbook itself.

7) Common pitfalls

• NAT/conntrack timeouts: when behavior shifts, the failure stays “silent”
• IPv6 gets forgotten: in production, this is not an outage but a security gap
• Service-specific exceptions stay scattered: rules managed “by some script somewhere” produce drift over time

Conclusion

Moving from iptables to nftables is not a modernization project — it is an operational confidence project. Success does not appear in translation tools; it shows up in inventory built on evidence, in wave-based rollout discipline, and in rollback that actually works. What you gain on the day you switch to nftables is not new commands; it is a more readable, more measurable, and more manageable firewall plane.