Passer d'iptables à nftables en 2026 : guide de migration pour ops Linux

Migrer iptables nftables est devenu un enjeu stratégique pour toute infrastructure Linux moderne. Iptables, héritage des années 90, cède progressivement sa place à nftables, son successeur officiellement intégré au noyau depuis 2014. Ce guide complet 2026 vous accompagne pas à pas dans cette transition technique, en détaillant syntaxe, outils de conversion, pièges à éviter et bonnes pratiques éprouvées sur le terrain, afin de garantir zéro interruption de service et des performances optimales.

Pourquoi migrer d'iptables vers nftables en 2026 ?

Iptables repose sur quatre sous-systèmes distincts (iptables, ip6tables, arptables, ebtables), chacun avec sa propre syntaxe et ses propres tables. Cette fragmentation complexifie la maintenance, multiplie les points de défaillance et ralentit le traitement des paquets dans les configurations multi-protocoles. Nftables unifie tout cela dans un framework unique, avec une syntaxe moderne inspirée des langages déclaratifs.

Avantages techniques concrets de nftables

• Syntaxe unifiée : une seule commande nft pour IPv4, IPv6, ARP et bridge. Fini la jonglerie entre outils.
• Performance accrue : structure de données optimisée (hash tables, sets), moins de parcours linéaire de règles, traitement jusqu'à 30 % plus rapide sur gros jeux de règles.
• Atomicité des modifications : nftables applique les changements en une transaction atomique, là où iptables charge règle par règle, risquant des états incohérents transitoires.
• Expressions flexibles : opérations logiques (AND/OR/NOT), ranges de ports natifs, concaténation de critères multi-champs sans hacks.
• Débogage simplifié : traces kernel intégrées (nft monitor trace), journaux détaillés, syntaxe lisible.

Sur un serveur de production typique avec plusieurs centaines de règles firewall, la migration réduit la latence de traitement par paquet de plusieurs microsecondes et simplifie drastiquement les audits de sécurité. Les distributions récentes (Debian 12+, Ubuntu 22.04+, RHEL 9+) embarquent nftables par défaut, iptables devenant un wrapper de compatibilité (iptables-nft) qui traduit en coulisses vers nftables.

Compatibilité et coexistence temporaire

Les deux systèmes utilisent Netfilter au niveau kernel, mais leurs couches userspace sont mutuellement exclusives. Vous ne pouvez pas charger simultanément des règles iptables natives et nftables : le premier chargé verrouille les hooks Netfilter. En revanche, iptables-nft (backend nftables pour iptables) permet de continuer à utiliser la syntaxe iptables tout en bénéficiant des structures nftables en coulisses. C'est une solution transitoire acceptable, mais l'objectif final reste une migration complète pour exploiter pleinement les fonctionnalités avancées.

Chez PAKKT.io, nous déployons nftables dans une table isolée inet pakkt avec des priorités Netfilter soigneusement réglées, garantissant zéro conflit avec Docker (qui utilise iptables/iptables-nft), fail2ban, ou tout autre outil legacy. Cette isolation permet une transition progressive sans casser l'existant.

Audit et préparation : inventaire de vos règles iptables

Avant toute manipulation, documentez précisément votre configuration actuelle. Une migration bâclée peut couper des flux critiques (SSH, monitoring, réplication de bases de données) ou ouvrir des failles de sécurité. Commencez par sauvegarder et exporter l'intégralité de vos règles.

Sauvegarde complète

# Sauvegarder iptables IPv4
iptables-save > /root/iptables-backup-$(date +%F).rules

# Sauvegarder ip6tables IPv6
ip6tables-save > /root/ip6tables-backup-$(date +%F).rules

# Vérifier la présence de règles ARP/bridge si pertinent
arptables-save > /root/arptables-backup-$(date +%F).rules
ebtables-save > /root/ebtables-backup-$(date +%F).rules

Ces fichiers texte contiennent toutes vos tables (filter, nat, mangle, raw, security), chaînes et règles dans un format structuré, lisible et versionnable (idéal pour Git).

Analyse des dépendances

Identifiez tous les outils et scripts qui manipulent iptables :

• Docker : crée automatiquement des chaînes dans nat/filter. Vérifiez la version (>= 20.10 supporte iptables-nft).
• fail2ban : bannit des IPs via iptables. Configuration dans /etc/fail2ban/action.d/. Basculer vers l'action nftables après migration.
• Scripts maison : grep -r "iptables" /etc /root /usr/local pour repérer tous les appels.
• Puppet / Ansible / Salt : modules de gestion de firewall à mettre à jour.
• iptables-persistent / netfilter-persistent : service qui restaure iptables au boot. À remplacer par nftables.service.

Documentez chaque règle critique avec son objectif métier : "autoriser SSH uniquement depuis IP admin X.X.X.X", "NAT vers conteneur web sur port 8080", "rate-limit ICMP à 10/s", etc. Cette cartographie vous aidera à valider la migration.

Vérification du support kernel

# Vérifier que nftables est disponible
nft --version

# Lister les modules kernel chargés
lsmod | grep nf_tables

# Si absent, charger manuellement (normalement automatique)
modprobe nf_tables
modprobe nf_tables_ipv4
modprobe nf_tables_ipv6

Noyau Linux >= 4.17 recommandé pour un support complet. Les versions 5.x et 6.x apportent des optimisations XDP et eBPF directement intégrables avec nftables, ouvrant la voie à des architectures hybrides haute performance, comme celles que PAKKT déploie sur ses agents (XDP stateless + nftables stateful).

Conversion automatique avec iptables-translate

L'outil iptables-translate (fourni par le paquet iptables >= 1.8) convertit la syntaxe iptables vers nftables. Il ne gère pas 100 % des cas complexes, mais couvre la majorité des règles classiques et accélère considérablement le processus.

Installation et utilisation de base

# Debian / Ubuntu
apt install iptables

# RHEL / Rocky / Alma
dnf install iptables-nft

# Convertir une règle iptables unique
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Sortie : nft add rule ip filter INPUT tcp dport 22 accept

# Convertir un fichier de règles complet
iptables-restore-translate -f /root/iptables-backup-2026-01-15.rules > /root/nftables-converted.nft

# Idem pour IPv6
ip6tables-restore-translate -f /root/ip6tables-backup-2026-01-15.rules >> /root/nftables-converted.nft

Revue manuelle et corrections

Le fichier généré nécessite toujours une relecture humaine. Points de vigilance :

• Syntaxe des sets : iptables utilise ipset, nftables a ses propres sets natifs. Migrez vos ipsets vers des sets nftables pour bénéficier de l'atomicité.
• Modules iptables non supportés : certains modules exotiques (u32, osf) n'ont pas d'équivalent direct nftables. Cherchez des alternatives ou combinez avec eBPF.
• Priorités des hooks : nftables expose explicitement les priorités Netfilter (filter = 0, mangle = -150, nat prerouting = -100, etc.). Ajustez si vous avez des chaînes personnalisées.
• Syntaxe des ranges : --dport 1024:65535 devient dport 1024-65535 (tiret au lieu de deux-points).

Exemple de conversion manuelle complexe

Règle iptables originale avec rate-limit et logging :

iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -m limit --limit 100/sec --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j LOG --log-prefix "HTTP flood: "
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j DROP

Conversion nftables optimisée (une seule règle, verdict conditionnel) :

nft add rule inet filter INPUT tcp dport 80 ct state new limit rate 100/second burst 200 packets accept
nft add rule inet filter INPUT tcp dport 80 ct state new log prefix \"HTTP flood: \" drop

Notez l'utilisation de la table inet (famille mixte IPv4/IPv6) au lieu de ip ou ip6 séparées. C'est l'une des forces de nftables : une règle unique couvre les deux protocoles si les critères sont compatibles.

Déploiement et tests en environnement de production

La migration en production exige un plan de rollback rapide et des tests de non-régression exhaustifs. Privilégiez toujours une bascule progressive : un serveur pilote, puis validation, puis déploiement généralisé.

Procédure de bascule sécurisée

1. Serveur de test : clonez une VM ou un conteneur représentatif, appliquez le nouveau ruleset nftables, simulez tous les flux (SSH, HTTP/S, bases de données, monitoring, backups).
2. Validation des connexions existantes : conntrack -L pour voir les sessions actives. Assurez-vous que nftables gère correctement ct state established,related.
3. Désactivation d'iptables :

   systemctl stop iptables
   systemctl disable iptables
   systemctl stop ip6tables
   systemctl disable ip6tables
   systemctl stop netfilter-persistent
   systemctl disable netfilter-persistent
   

4. Chargement nftables :

   # Vider toute règle nftables existante
   nft flush ruleset
   
   # Charger votre nouveau ruleset
   nft -f /root/nftables-converted.nft
   
   # Activer le service pour persistance au reboot
   systemctl enable nftables.service
   systemctl start nftables.service
   

5. Vérification immédiate :

   nft list ruleset
   # Tester SSH depuis IP admin
   # Tester accès web, API, base de données
   # Vérifier logs : journalctl -u nftables -f
   

6. Rollback si problème :

   nft flush ruleset
   systemctl start iptables
   iptables-restore < /root/iptables-backup-2026-01-15.rules
   

   Prévoyez un accès console IPMI/iLO/KVM au cas où SSH serait bloqué.

Intégration avec Docker et fail2ban

Docker : si vous utilisez Docker, vérifiez que le daemon utilise iptables-nft (backend nftables transparent). Ajoutez dans /etc/docker/daemon.json :

{
  "iptables": true,
  "ip6tables": true
}

Docker continuera à fonctionner, créant ses chaînes dans une table nftables ip nat et ip filter via le wrapper iptables-nft. Aucune modification nécessaire côté conteneurs.

fail2ban : basculez l'action de bannissement. Éditez /etc/fail2ban/jail.local :

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

Redémarrez fail2ban : systemctl restart fail2ban. Vérifiez qu'un ban fonctionne : fail2ban-client set sshd banip 203.0.113.42 puis nft list set inet f2b-table addr-set-sshd (le set doit contenir l'IP).

Monitoring et métriques post-migration

Activez les compteurs nftables pour suivre le trafic par règle :

nft add rule inet filter INPUT tcp dport 22 counter accept
nft list ruleset
# Sortie : ... counter packets 1234 bytes 567890 accept

Exportez ces métriques vers Prometheus via nftables_exporter ou intégrez avec votre stack de monitoring existante. Sur les infrastructures gérées par PAKKT, les métriques XDP et nftables sont automatiquement centralisées dans TimescaleDB et visualisées en temps réel (dashboard GeoIP, top ports, top règles actives, audit logs). Cela permet de détecter instantanément toute anomalie post-migration (drop rate anormal, latence accrue).

Optimisations avancées et architecture hybride XDP + nftables

Une fois la migration réussie, exploitez les fonctionnalités avancées de nftables et envisagez une architecture hybride pour des performances ultimes.

Sets et maps pour réduire le nombre de règles

Plutôt que 50 règles drop pour 50 IPs malveillantes, utilisez un set :

nft add set inet filter blacklist { type ipv4_addr \; flags interval \; }
nft add element inet filter blacklist { 203.0.113.0/24, 198.51.100.5 }
nft add rule inet filter INPUT ip saddr @blacklist drop

Avantages : ajout/suppression d'IPs en O(1), règle unique dans le pipeline Netfilter, lookup instantané via hash table.

Verdicts multiples et expressions logiques

# Accepter SSH uniquement depuis réseau admin OU IP support, et rate-limiter
nft add rule inet filter INPUT ip saddr { 10.0.0.0/8, 203.0.113.50 } tcp dport 22 ct state new limit rate 5/minute accept
nft add rule inet filter INPUT tcp dport 22 drop

Couplage XDP + nftables pour la protection DDoS

XDP (eXpress Data Path) s'exécute avant le stack réseau kernel, au niveau driver, avec une latence sub-microseconde. C'est idéal pour filtrer les attaques volumétriques (SYN flood, UDP flood) avant même qu'elles ne consomment des cycles CPU dans Netfilter. Nftables, stateful, gère ensuite les connexions légitimes avec conntrack, rate-limit par connexion, etc.

Architecture recommandée sur un serveur de jeu ou API exposée :

• Couche XDP : drop des paquets malformés, rate-limit global (max_pps), blacklist IP, filtrage par port/proto simple. Programme eBPF attaché à l'interface (ip link set dev eth0 xdp obj filter.bpf.o).
• Couche nftables : firewall stateful, règles métier complexes, NAT, logging sélectif, intégration fail2ban.

C'est exactement le modèle déployé par l'agent PAKKT : un programme XDP unique par interface (PAKKT Engine), pilotable via BPF maps (256 règles simultanées, update en temps réel sans recompilation), couplé à une table nftables inet pakkt isolée. Le tout orchestré depuis le panel centralisé, avec synchronisation automatique des blacklists/whitelists entre XDP et nftables. Cette double couche permet d'absorber plusieurs millions de pps malveillants en XDP, tout en conservant la finesse stateful de nftables pour les flux légitimes. Plus de détails techniques sur le blog PAKKT.

Mise à jour dynamique sans interruption

Contrairement à iptables qui nécessite un flush/reload complet (perte temporaire de l'état conntrack), nftables permet des mises à jour atomiques :

# Ajouter une règle en position 5 de la chaîne INPUT
nft insert rule inet filter INPUT position 5 ip saddr 203.0.113.99 drop

# Supprimer une règle par handle
nft --handle list ruleset
# Repérer le handle (ex: 42)
nft delete rule inet filter INPUT handle 42

Les connexions existantes ne sont jamais rompues, le conntrack reste intact. C'est crucial pour les serveurs de production à haute disponibilité.

Conclusion

Migrer iptables vers nftables en 2026 n'est plus une option, c'est une nécessité technique pour bénéficier de performances accrues, d'une syntaxe moderne et d'une meilleure maintenabilité. En suivant une méthodologie rigoureuse — audit complet, conversion assistée par iptables-translate, tests exhaustifs, rollback plan — vous minimisez les risques et maximisez les gains. Envisagez ensuite une architecture hybride XDP + nftables pour atteindre des niveaux de protection et de performance inégalés, surtout sur des infrastructures critiques exposées à des attaques DDoS volumétriques.

FAQ

Puis-je faire cohabiter iptables et nftables sur le même serveur pendant la migration ?

Techniquement oui via le wrapper iptables-nft, qui traduit les commandes iptables en règles nftables en coulisses. Cela permet une transition progressive sans casser l'existant (Docker, fail2ban, scripts legacy). En revanche, vous ne pouvez pas charger simultanément des règles iptables natives (iptables-legacy) et nftables : le premier système chargé verrouille les hooks Netfilter. Privilégiez update-alternatives --config iptables pour basculer vers iptables-nft, puis migrez progressivement vers des règles nftables pures pour exploiter pleinement les fonctionnalités avancées (sets, maps, atomicité).

Que faire si iptables-translate ne convertit pas correctement une règle complexe ?

Iptables-translate couvre environ 90 % des règles classiques, mais échoue sur certains modules exotiques (u32, string, osf) ou des chaînes personnalisées imbriquées. Dans ce cas : 1) Documentez précisément l'objectif métier de la règle. 2) Consultez la wiki officielle nftables pour trouver l'équivalent (souvent une expression nftables native ou un set). 3) Combinez nftables avec eBPF si la logique est trop spécifique (filtrage payload custom, stateful complexe). 4) Testez sur un serveur pilote avant production. En dernier recours, gardez cette règle en iptables-nft temporairement, le temps de trouver une alternative propre.

Comment valider que ma migration nftables n'a pas créé de faille de sécurité ?

Trois axes de validation : 1) Tests fonctionnels : rejouez tous les scénarios de trafic légitime (SSH admin, HTTP/S, base de données, monitoring, backups) et vérifiez qu'ils passent. 2) Scan de ports externe : lancez nmap -sS -p- votre-serveur.com depuis une IP publique non autorisée, comparez avec le scan pré-migration. Aucun port supplémentaire ne doit apparaître ouvert. 3) Audit de règles : nft list ruleset et revoyez ligne par ligne, cherchez les règles trop permissives (accept sans critère restrictif). Activez le logging pour les drops suspects (log prefix "DENIED: " drop) et surveillez journalctl -k pendant 48h. Idéalement, automatisez cette revue avec des outils de compliance (Lynis, OpenSCAP) intégrant des checks nftables.