iptables vs nftables : ce qui a changé et comment migrer

Réponse d’abord : vous utilisez probablement déjà nftables

La formulation « iptables vs nftables » suggère un choix entre deux options vivantes. Pour la plupart des serveurs, ce choix avait déjà été fait par votre distribution en 2026 :

• Sur Debian 10+ et Ubuntu 20.10+, la commande iptables est par défaut iptables-nft, une couche de compatibilité qui accepte la syntaxe iptables mais programme le sous-système nf_tables du noyau. Vos règles iptables tournent déjà sur le moteur nftables.
• Dans la famille RHEL (RHEL/AlmaLinux/Rocky 9 et 10), l’ensemble du framework iptables est déprécié, firewalld parle nftables nativement, et RHEL 10 ne fournit plus du tout le module noyau legacy ip_tables.
• En amont, iptables est en mode maintenance : il reçoit encore des versions (1.8.13 est sortie en mars 2026), mais tout le développement de fonctionnalités se passe dans nftables.

Le conseil pratique tient donc en peu de mots : les jeux de règles iptables existants et fonctionnels ne sont pas une urgence ; la couche de compatibilité est bonne et stable. Mais les nouvelles règles et la nouvelle automatisation devraient être écrites en nftables natif : une seule syntaxe pour IPv4 et IPv6, des sets et des maps qui passent à l’échelle, des rechargements atomiques, et aucune dépendance envers un shim dont les distros ont programmé le retrait éventuel de l’outillage sous-jacent. Le reste de cet article détaille ce conseil, ainsi que la mécanique de migration.

Comment on en est arrivé là

netfilter, le sous-système de filtrage de paquets du noyau, a connu trois générations visibles par l’utilisateur : ipchains (noyau 2.2), iptables (noyau 2.4, 2001) et nftables (intégré au noyau 3.13, 2014). nftables a été écrit par la même équipe netfilter pour corriger les problèmes structurels d’iptables plutôt que de les contourner par des rustines.

La version charnière fut iptables 1.8 (2018), qui a scindé la commande en deux variantes : iptables-legacy (l’implémentation classique) et iptables-nft (même syntaxe en ligne de commande, mais les règles sont exécutées par le moteur noyau nf_tables). Les distros ont basculé leur alias par défaut vers la variante nft presque immédiatement, et c’est ainsi que des millions de serveurs ont changé de moteur sans que leurs administrateurs s’en aperçoivent :

Vérifiez ce qu’une machine donnée utilise réellement ; la réponse s’affiche entre parenthèses :

$ iptables -V
iptables v1.8.10 (nf_tables)   # ← the shim, executing on nftables
iptables v1.8.10 (legacy)      # ← the classic engine

Ce qui a réellement changé

Les différences qui comptent au quotidien, pas la liste marketing :

Un seul outil, les deux familles d’adresses

Le péché originel d’iptables : iptables, ip6tables, arptables et ebtables étaient quatre outils séparés avec quatre jeux de règles séparés, et chaque serveur dual-stack devait voir sa politique écrite (et maintenue, et auditée) deux fois. Oublier le volet IPv6 était le trou classique. La famille inet de nftables applique une seule table à la fois à IPv4 et IPv6. Toute la classe de bugs « v4 protégé, v6 oublié » disparaît structurellement.

Les sets et les maps sont de première classe

Dans iptables, matcher 500 adresses signifiait 500 règles (évaluées linéairement), ou greffer l’outil séparé ipset. Dans nftables, les sets sont natifs :

nft add set inet filter blocklist '{ type ipv4_addr; flags interval; }'
nft add element inet filter blocklist '{ 203.0.113.0/24, 198.51.100.7 }'
nft add rule inet filter input ip saddr @blocklist drop

Une seule règle, une recherche quasi O(1), modifiable à chaud sans toucher au jeu de règles. Les maps vont plus loin en associant des critères de correspondance à des actions ou des destinations (des constructions du style dnat to tcp dport map { 80 : 10.0.0.10, 443 : 10.0.0.11 } compressent des familles entières de règles en une seule recherche). Les sets dynamiques alimentent aussi la limitation de débit par source, que nous utilisons dans notre base de règles de pare-feu par défaut.

Remplacement atomique du jeu de règles

nft -f ruleset.conf valide et applique tout le fichier de façon atomique : soit il charge intégralement, soit l’ancien jeu de règles reste intact. Les scripts iptables appliquaient les règles une commande à la fois, si bien qu’un échec à mi-chemin laissait le pare-feu dans un état à moitié configuré (parfois, mémorablement, dans l’état où le drop par défaut était déjà appliqué mais pas l’autorisation SSH). iptables-restore atténuait cela par table ; avec nftables, c’est le seul mode de fonctionnement. En prime, nft -c vous offre une vérification de syntaxe en dry-run.

Pas de chains intégrées, pas de pipeline fixe

iptables donnait à chaque table des chains fixes (INPUT, FORWARD, OUTPUT...) qui existent qu’elles soient utilisées ou non, chacune imposant un coût par paquet. Dans nftables, vous ne créez que les chains dont vous avez besoin et vous les attachez à des hooks du noyau avec des priorités explicites. Le surcoût d’un pare-feu vide est véritablement nul, et le jeu de règles que vous lisez est toute la vérité, rien d’implicite.

Meilleure introspection et automatisation

nft monitor diffuse les changements du jeu de règles en direct (excellent pour déboguer le « qu’est-ce qui vient de changer mon pare-feu ? »), les compteurs sont opt-in par règle, et nft -j parle JSON dans les deux sens, la réponse moderne à toute une génération de parseurs iptables-save fragiles. Si vous templatez la configuration du pare-feu avec Ansible ou Terraform, nftables natif est nettement moins pénible.

Syntaxe côte à côte

Les tâches que vous effectuez réellement, dans les deux langages :

La colonne nftables se lit comme un langage plutôt que comme la soupe de flags d’une commande, parce que c’en est un : les expressions se combinent librement (ip saddr @admins tcp dport 22 ct state new accept) au lieu d’exiger un module de correspondance sur mesure par fonctionnalité.

Performance : la version honnête

Les affirmations selon lesquelles nftables serait bien plus rapide (ou plus lent) sont à la fois faciles à trouver et largement infondées. Les données publiques crédibles :

• Les développeurs netfilter de Red Hat ont comparé les deux en 2017 : avec de petits jeux de règles linéaires, iptables était en fait légèrement plus rapide ; le tableau s’inverse dès que les sets entrent en jeu : en matchant sur ~120+ ports ou de grands groupes d’adresses, iptables se dégrade linéairement tandis que nftables reste stable. Leur conclusion était que les architectures sont comparables et que le gain vient des sets/maps, pas de la vitesse brute par règle. (données de 2017 : la forme de la conclusion a tenu, mais considérez les chiffres absolus comme historiques.)
• À l’échelle de l’orchestration, la différence devient visible : le kube-proxy de Kubernetes a reçu un mode nftables GA en 1.33, principalement parce que l’évaluation linéaire des règles et les rechargements complets de table d’iptables font mal à des dizaines de milliers de services. À ~30,000 services, la latence de queue du mode nftables battait la meilleure latence du mode iptables. Fait notable, le mode iptables reste le défaut de Kubernetes pour des raisons de compatibilité.

Pour un serveur unique avec des dizaines de règles, vous ne mesurerez aucune différence. Choisissez nftables pour l’expressivité, l’atomicité, et le fait que c’est là que va désormais tout l’effort de maintenance et de développement, pas pour le débit.

Migrer

Étape 1 : découvrir ce que vous utilisez

iptables -V (voir ci-dessus). Vérifiez aussi la présence de règles dans les deux moteurs, un désordre étonnamment courant après des migrations partielles :

iptables-legacy -L -n 2>/dev/null   # anything here runs on the old engine
nft list ruleset                    # the full truth, including iptables-nft rules

nft list ruleset montre tout ce qui est dans nf_tables, y compris les règles créées via le shim ; c’est la seule commande qui ne vous ment jamais sur l’état réel du pare-feu.

Étape 2 : traduction mécanique

Le paquet iptables fournit des traducteurs. Même syntaxe en entrée, syntaxe nft en sortie :

$ 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'

# whole ruleset at once:
iptables-save > current.rules
iptables-restore-translate -f current.rules > ruleset.nft
nft -c -f ruleset.nft   # syntax-check before applying

(ip6tables-restore-translate pour le volet v6.) Le résultat est correct mais littéral : il reproduit telle quelle votre duplication v4/v6 et votre structure par règle.

Étape 3 : adopter réellement le modèle

Traitez le fichier traduit comme un échafaudage, puis restructurez : fusionnez les jeux de règles v4/v6 en une seule table inet, compressez les règles de port/adresse répétées en sets, et ajoutez des commentaires. Un jeu de règles iptables de 100 lignes devient couramment 30 lignes nftables lisibles. Notre article sur la base de pare-feu constitue un squelette raisonnable vers lequel migrer. Appliquez avec un rollback programmé et une seconde session SSH ouverte (la mécanique pour éviter le verrouillage y est également couverte).

Les pièges

• Ne faites pas tourner de règles dans les deux moteurs. Les règles iptables legacy et nftables sont toutes les deux évaluées, indépendamment. Un paquet doit survivre aux deux. Ça « marche », jusqu’à ce que ça produise un comportement impossible à déboguer. Migrez, vérifiez, puis videz le côté legacy.
• Docker parle encore iptables. Docker programme par défaut son NAT/forwarding via l’interface iptables (pas de souci : sur les systèmes modernes, c’est le shim nft ; ne supprimez pas le paquet iptables sur un hôte Docker). Son backend nftables natif est sorti expérimentalement dans Engine 29, mais reste opt-in. Conséquence pratique : sur un hôte Docker, placez votre politique dans la chain DOCKER-USER ou dans vos propres tables, et ne faites pas de flush ruleset à l’aveugle. Ça balaie aussi les règles de Docker. (Même histoire pour les nodes Kubernetes : vérifiez votre CNI et votre mode kube-proxy avant de toucher au pare-feu.)
• Les frontends, ça va. Choisissez une seule couche. ufw (syntaxe iptables par-dessus le shim) et firewalld (backend nftables natif depuis 2018) fonctionnent tous les deux correctement aujourd’hui. L’anti-pattern consiste à éditer les tables nft à la main sur une machine gérée par un frontend ; le frontend gagnera au prochain rechargement.

Quand rester sur iptables est raisonnable

En toute honnêteté sur l’autre versant : un serveur stable, de type appliance, avec un jeu de règles iptables-nft fonctionnel et audité et sans développement actif de règles, a peu à gagner d’une réécriture. Un outillage qui n’émet que de l’iptables (anciennes actions fail2ban, orchestration legacy) est aussi une raison légitime de reporter ; le shim existe précisément pour ça. La ligne à tenir est directionnelle : n’écrivez pas de nouveaux systèmes, rôles ou documentations contre la syntaxe legacy, parce que la famille RHEL a déjà programmé son retrait et que le reste de l’écosystème suit l’équipe netfilter de Red Hat.

Questions fréquentes

Est-ce qu’iptables est déprécié ?

Précisément : déprécié par les distributions, maintenu en amont. Le projet netfilter continue de publier des versions d’iptables (1.8.13, mars 2026) et n’a annoncé aucune fin de vie. Mais Red Hat a déprécié l’ensemble du framework iptables dans RHEL 9, supprimé le module noyau legacy dans RHEL 10, et chez toutes les grandes distros, le moteur par défaut est nftables depuis des années. « Mort » est faux ; « interface legacy en sursis » est juste.

Est-ce que ufw et firewalld utilisent nftables ?

firewalld : oui, nativement. nftables est son backend par défaut depuis 2018. ufw : indirectement. Il génère des règles iptables et les exécute via le binaire iptables du système, qui sur tout Ubuntu moderne est le shim basé sur nft, donc les règles atterrissent dans nf_tables ; ufw lui-même n’a pas de mode nftables natif. Dans tous les cas, vos règles finissent dans le même sous-système du noyau.

Mes règles iptables vont-elles cesser de fonctionner si je change ?

La logique de vos règles se traduit proprement ; iptables-restore-translate convertit un jeu de règles sauvegardé de façon mécanique, et le moteur nftables prend en charge tout ce que fait le socle de fonctionnalités d’iptables. Ce qui ne se reporte pas automatiquement : les définitions ipset (à recréer comme des sets natifs), tout script qui parse la sortie de iptables -L, et les suppositions sur les chains intégrées. Traduisez, faites un dry-run avec nft -c, appliquez de façon atomique, gardez un rollback programmé.

nftables est-il plus rapide qu’iptables ?

À petite échelle, non. Les propres benchmarks de Red Hat ont montré que de simples jeux de règles linéaires favorisaient légèrement iptables. nftables gagne là où la structure compte : grands sets de ports/adresses (recherche plate plutôt que linéaire), très grands jeux de règles, et changements de règles fréquents (mises à jour incrémentales atomiques plutôt que rechargements complets de table, la raison pour laquelle Kubernetes a construit un kube-proxy nftables). Pour un pare-feu de serveur classique, choisissez selon la maintenabilité ; la performance, c’est un match nul.

Déployer sur Serverside

Quelle que soit la syntaxe que vous écrivez, le pare-feu sur l’hôte n’est qu’une couche sur deux dans notre réseau : chaque serveur dédié inclut un pare-feu de périphérie en self-service (le trafic non lié à un service est abandonné en amont avant d’atteindre votre port), plus une mitigation DDoS permanente sur l’ASN 55285, avec un provisioning en moins d’une minute sur n’importe quelle distribution Linux majeure.

Prolongez cet article avec le jeu de règles de pare-feu par défaut pour un serveur Linux complet, la vision plus large des menaces dans les attaques DDoS expliquées, et la criminalistique réseau pratique dans capturer et analyser une attaque DDoS avec Wireshark.