nftables vs UFW vs firewalld : lequel pour un serveur Debian en 2026 ?

Lorsqu'on parle de nftables vs UFW firewalld, on compare trois approches différentes de la gestion du filtrage réseau sous Linux : nftables (le framework kernel moderne), UFW (interface simplifiée Debian/Ubuntu) et firewalld (gestionnaire dynamique RedHat/CentOS). En 2026, le choix entre ces outils dépend de votre niveau d'expertise, de vos besoins en performance et de votre volonté de contrôler finement le filtrage au niveau kernel. Cet article décode les différences techniques, les cas d'usage et les critères de décision pour sysadmins et architectes réseau.

nftables, UFW et firewalld : périmètre et architecture de chaque solution

Avant de trancher entre nftables vs UFW firewalld, il faut comprendre que ces trois composants jouent sur des couches d'abstraction différentes :

nftables : le framework kernel natif

Depuis le noyau 3.13 (mainline 2014), nftables remplace progressivement iptables/ip6tables/arptables/ebtables. Il expose une API unique au travers de Netlink et repose sur une machine virtuelle noyau (nf_tables) qui exécute des bytecode compilés depuis des règles. Contrairement à iptables, nftables supporte :

• Des tables et chaînes multiples au sein d'une même famille (inet, ip, ip6, bridge, arp, netdev).
• Des ensembles (sets) et des dictionnaires (maps) pour stocker IP, ports, interfaces sans multiplier les règles linéaires.
• Une syntaxe déclarative cohérente (nft add rule inet filter input tcp dport 22 ct state new accept).
• Une transaction atomique : tous les changements sont appliqués en une passe ou annulés en cas d'erreur.

nftables est stateful via ct state (conntrack) et peut travailler en amont avec PAKKT.io qui place un programme XDP/eBPF avant la stack réseau pour filtrer à la carte réseau (L2), laissant nftables gérer le stateful L3/L4.

UFW : wrapper Canonical pour Debian/Ubuntu

UFW (Uncomplicated Firewall) est un frontend développé par Canonical pour simplifier iptables (et depuis Ubuntu 20.10, nftables en backend). Il traduit des commandes humaines (ufw allow 22/tcp) en règles iptables/nftables. UFW propose :

• Une CLI minimaliste orientée débutant.
• Des profils d'application dans /etc/ufw/applications.d/ (Apache, SSH, Nginx).
• Un mécanisme de reset et de log intégré.
• Aucune gestion native de sets, rate-limit avancé ou chaînes personnalisées complexes.

UFW traduit systématiquement vos commandes en règles iptables-save ou nftables, ce qui peut créer des conflits avec Docker (qui injecte ses propres chaînes dans FORWARD) ou fail2ban (qui manipule directement iptables). PAKKT contourne ce problème en isolant ses règles nftables dans une table inet pakkt dédiée, garantissant zéro conflit avec UFW, Docker ou iptables-persistent.

firewalld : orchestrateur dynamique RedHat/Fedora

firewalld est le gestionnaire par défaut sur RHEL, CentOS, Fedora et dérivés. Il s'appuie sur nftables (depuis RHEL 8/CentOS 8, avant il utilisait iptables) et expose une API D-Bus pour modifier les règles sans redémarrage. Fonctionnalités clés :

• Zones réseau (public, trusted, dmz) attachées à des interfaces ou des sources IP.
• Services prédéfinis dans /usr/lib/firewalld/services/ (SSH, HTTP, MySQL).
• Rich rules pour des conditions avancées (firewall-cmd --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port port=25565 protocol=tcp reject').
• Direct rules (accès bas niveau nftables/iptables) pour compléter les zones.

firewalld est daemon : il tourne en permanence, consomme ~10 MB RAM et réagit aux événements réseau (NetworkManager, hotplug). Contrairement à UFW qui est statique (on active/désactive), firewalld peut recharger la config sans perte de connexion.

Le tableau ci-dessous résume les différences d'architecture :

Critère	nftables	UFW	firewalld
Couche	Framework kernel	Wrapper CLI (backend iptables/nft)	Daemon + D-Bus (backend nft)
Stateful (conntrack)	Oui (ct state)	Oui (via backend)	Oui (via nft)
Rechargement à chaud	Oui (transactions atomiques)	Non (reload complet)	Oui (D-Bus runtime)
Zones / Profils	Non (tables/chaînes libres)	Profils applicatifs	Zones réseau
Sets / Maps	Oui (natifs)	Non	Via direct rules
Compatibilité iptables	Via iptables-nft	Natif (legacy backend)	Via nft (RHEL ≥8)

Performance et impact kernel : où se situe la différence ?

Dans le débat nftables vs UFW firewalld, un critère décisif est la latence par paquet et le throughput maximum. Tous reposent in fine sur le même hook Netfilter dans le noyau, mais la complexité des règles et l'overhead du daemon changent la donne.

nftables : machine virtuelle optimisée, coût sub-microseconde

Le moteur nftables compile les règles en bytecode exécuté dans le kernel space. Grâce aux sets (tables de hachage ou arbres radiaux), une recherche IP parmi 10 000 entrées se fait en O(log n) ou O(1), contre O(n) pour iptables qui évalue chaque règle linéairement. Sur un serveur moderne (Xeon Scalable, 10GbE), nftables ajoute typiquement 0,2 à 0,5 µs par paquet pour une politique INPUT basique (connexions établies + DROP default).

Exemple de set IP efficace :

nft add table inet pakkt
nft add chain inet pakkt input { type filter hook input priority 0 \; policy drop \; }
nft add set inet pakkt blacklist_v4 { type ipv4_addr \; flags interval \; }
nft add rule inet pakkt input ip saddr @blacklist_v4 drop
nft add element inet pakkt blacklist_v4 { 203.0.113.0/24, 198.51.100.42 }

Cette structure permet de bloquer des milliers d'IP avec une seule règle. PAKKT pousse ce principe plus loin : il maintient une BPF map XDP (évaluée à la carte réseau, avant le stack IP) et un set nftables synchronisé, offrant une double couche de filtrage avec latence cumulée négligeable.

UFW : overhead du wrapper, pas de différence kernel

UFW génère des règles iptables ou nftables selon le backend. Une fois les règles chargées, le coût runtime est identique à celui de nftables/iptables natif. L'overhead se situe au moment du ufw reload : UFW régénère toute la politique, flush les chaînes, puis réinjecte. Sur un serveur en production avec 200+ connexions actives, ce flush peut provoquer une perte transitoire de paquets (quelques millisecondes).

UFW ne tire pas parti des sets ou maps nftables : chaque IP de blocage = une règle distincte, ce qui dégrade les performances linéairement au-delà de quelques centaines d'entrées. Pour des scénarios DDoS (50 000+ IP source malveillantes), UFW devient impraticable sans script externe.

firewalld : daemon overhead, mais rechargement partiel

Le daemon firewalld (~10 MB RAM, 0,1 % CPU idle) écoute D-Bus et traduit les commandes en appels nftables via libnftables. L'avantage : seules les règles modifiées sont touchées, pas de flush global. En revanche, chaque appel firewall-cmd traverse le daemon (latence ~5 ms pour une rich rule simple), ce qui interdit l'usage en chemin rapide (exemple : ajout d'IP à la volée depuis un IDS).

Pour du rate-limit par connexion (protection SYN flood), firewalld expose :

firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" service name="ssh" accept limit value="10/m"'
firewall-cmd --reload

Ce qui se traduit en nftables par une règle ct state new limit rate 10/minute. Là encore, PAKKT combine XDP (filtrage stateless, plusieurs millions de pps) et nftables (conntrack, TCP flags, meter/burst) dans une architecture hybride sans daemon supplémentaire : l'agent Go pousse les règles directement via Netlink, zéro overhead D-Bus.

Ordre de grandeur crédible : sur un lien 10 Gbps saturé (14,8 Mpps de paquets 64 octets), une politique nftables optimisée (sets, ct state) traite le flux avec ~2–3 % CPU par cœur. UFW/firewalld ajoutent chacun <1 % CPU supplémentaire en régime permanent, mais UFW perd l'avantage dès qu'on dépasse 500 règles individuelles.

Cas d'usage et critères de choix : quand privilégier nftables, UFW ou firewalld ?

Le comparatif nftables vs UFW firewalld n'a de sens que rapporté à un contexte métier. Voici les scénarios types :

nftables pur : contrôle total, performance maximale

Choisissez nftables si :

• Vous gérez des serveurs edge à fort trafic (CDN origin, serveurs de jeu avec 100k+ pps, proxies reverse).
• Vous devez manipuler des listes IP/port dynamiques (feeds de threat intelligence, rate-limit par ASN).
• Vous souhaitez une intégration CI/CD : les règles nftables peuvent être versionnées en fichiers .nft, diffées, testées en staging.
• Vous combinez nftables avec XDP/eBPF pour filtrer en amont (cas PAKKT : XDP drop les SYN floods à 20 Mpps, nftables gère le conntrack des flux légitimes).

Contre-indications : courbe d'apprentissage raide pour les juniors, risque de lockout si erreur de syntaxe (toujours tester avec nft -c -f test.nft avant nft -f).

UFW : simplicité pour serveurs standalone Debian/Ubuntu

Privilégiez UFW si :

• Vous administrez quelques VPS personnels ou de développement (WordPress, GitLab, CI runners).
• Votre politique est statique : SSH + HTTP/HTTPS + deny all, modifiée une fois par trimestre.
• Votre équipe est junior et préfère ufw allow 443/tcp à la syntaxe nftables.

Limites : dès qu'on ajoute Docker (qui crée des chaînes FORWARD), fail2ban (qui injecte des bans dynamiques) ou des règles rate-limit complexes, UFW entre en conflit ou devient opaque. Dans ce cas, soit basculer sur nftables pur, soit isoler la pile avec PAKKT qui maintient sa propre table inet pakkt sans toucher aux chaînes UFW.

firewalld : orchestration multi-interface et zones réseau

Adoptez firewalld si :

• Vous êtes sur RHEL/CentOS/Fedora et souhaitez l'expérience intégrée RedHat.
• Votre serveur a plusieurs interfaces (LAN interne, WAN publique, DMZ) et vous voulez des politiques par zone (trusted sur eth1, public sur eth0).
• Vous utilisez NetworkManager et souhaitez que le firewall suive les changements de réseau (VPN, hotplug Wi-Fi sur edge devices).
• Vous gérez la config via Ansible/Puppet et préférez l'API D-Bus à l'édition de fichiers nft.

Limites : le daemon ajoute un point de défaillance (si firewalld crashe, pas de rechargement automatique des règles ; systemd le redémarre mais avec un délai). Pour des environnements critiques (passerelles 40GbE, routeurs BGP), nftables direct (éventuellement piloté par un agent léger comme celui de PAKKT) est préférable.

Hybridation PAKKT + nftables/UFW/firewalld

L'approche PAKKT.io est complémentaire : quelle que soit votre couche firewall (UFW, firewalld, nftables manuel), l'agent PAKKT charge un programme XDP unique par interface et crée une table inet pakkt isolée. Vous conservez vos règles existantes (SSH, HTTP) dans UFW/firewalld, et PAKKT prend en charge :

• Le filtrage ultra-rapide des attaques volumétriques (UDP floods, SYN floods) via XDP avant que le kernel ne voie les paquets.
• Le rate-limit par port (max_port_pps) et global (max_pps) pilotable depuis le panel web, sans éditer de config locale.
• La blacklist/whitelist IP synchronisée en temps réel (API push depuis votre SIEM ou threat feed).

Exemple d'architecture type : VPS Ubuntu 24.04, UFW gérant SSH (port 22) et Nginx (80/443), PAKKT protégeant un serveur Minecraft (25565 TCP/UDP) avec rate-limit 5000 pps et blacklist GeoIP (pays hors UE). Zéro conflit car les chaînes ufw-user-input et pakkt input sont évaluées à des priorités différentes.

Migration et coexistence : passer de iptables/UFW/firewalld à nftables sans coupure

En 2026, Debian 12, Ubuntu 24.04 LTS, RHEL 9 et dérivés embarquent nftables par défaut, mais beaucoup de serveurs legacy tournent encore avec iptables ou UFW/firewalld en mode iptables. Voici comment migrer sans risque.

Inventaire de l'existant

Avant toute migration, listez les règles actives :

# Si iptables est actif
iptables-save > /root/iptables-backup.rules
ip6tables-save > /root/ip6tables-backup.rules

# Si UFW
ufw status verbose > /root/ufw-backup.txt

# Si firewalld
firewall-cmd --list-all-zones > /root/firewalld-backup.txt

# Si nftables déjà présent
nft list ruleset > /root/nftables-backup.nft

Traduction iptables → nftables

Le paquet iptables-nft fournit iptables-translate et ip6tables-translate :

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

iptables-restore-translate -f /root/iptables-backup.rules > /root/nftables-migration.nft

Relisez nftables-migration.nft, factorisez les règles redondantes avec des sets, puis testez :

nft -c -f /root/nftables-migration.nft  # vérification syntaxe
nft -f /root/nftables-migration.nft     # chargement
nft list ruleset                         # validation

Bascule UFW → nftables

UFW depuis Ubuntu 20.10 peut utiliser nftables en backend (/etc/default/ufw, IPT_MODULES="nf_tables"), mais pour un contrôle total :

ufw disable
systemctl stop ufw
systemctl disable ufw

# Créez votre fichier /etc/nftables.conf avec équivalent des règles UFW
nft -f /etc/nftables.conf
systemctl enable nftables.service
systemctl start nftables.service

Testez SSH depuis une session screen ou tmux pour éviter le lockout. Si erreur, nft flush ruleset vide tout (attention, policy DROP = coupure réseau).

Bascule firewalld → nftables

firewalld pilote déjà nftables en backend sur RHEL ≥8. Pour le désactiver et gérer nftables manuellement :

firewall-cmd --list-all-zones > /root/firewalld-export.txt
systemctl stop firewalld
systemctl disable firewalld

# Traduire manuellement les zones en tables nftables (famille inet)
nft add table inet main
nft add chain inet main input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet main input ct state established,related accept
nft add rule inet main input iif lo accept
nft add rule inet main input tcp dport 22 ct state new accept
# ...
nft list ruleset > /etc/nftables.conf
systemctl enable nftables.service

Coexistence temporaire avec PAKKT

Si vous ne voulez pas toucher votre firewall actuel (UFW/firewalld), déployez PAKKT qui crée sa propre table inet pakkt avec priorité raw (-300) pour XDP et filter (0) pour nftables stateful. Vos règles UFW/firewalld restent intactes (priorités différentes), et PAKKT filtre en amont les attaques volumétriques. Vous pouvez ainsi tester nftables sur un sous-ensemble de ports (ex. 25565 pour Minecraft) tout en conservant UFW pour SSH/HTTP, puis migrer progressivement.

Commande d'installation agent PAKKT (Ubuntu/Debian, kernel ≥5.4) :

curl -fsSL https://pakkt.io/install.sh | sudo bash
# L'agent charge automatiquement pakkt_engine.bpf.o sur l'interface principale
# et crée la table inet pakkt isolée

Depuis le panel PAKKT, vous configurez règles XDP (port range, rate-limit pps, min/max packet size) et règles nftables (conntrack, TCP flags, meter) sans éditer de fichier local. Le tout est synchronisé en temps réel via mTLS.

Conclusion

Le choix entre nftables vs UFW firewalld dépend de votre stack (Debian/Ubuntu vs RHEL), de votre niveau d'expertise et de vos contraintes de performance. nftables offre le contrôle total et la meilleure scalabilité (sets, maps, transactions atomiques), UFW simplifie pour des cas d'usage basiques au prix de la flexibilité, firewalld apporte l'orchestration dynamique par zones sur RedHat. Pour des environnements exigeants (serveurs de jeu, edge computing, API publiques), combiner nftables avec XDP/eBPF via PAKKT garantit filtrage sub-microseconde et zéro conflit avec votre firewall existant. Testez toujours vos règles en staging, versionnez vos configs et privilégiez l'isolation des tables pour éviter les régressions.

FAQ

Peut-on utiliser nftables et firewalld simultanément sur le même serveur ?

Oui, firewalld pilote nftables en backend depuis RHEL 8 / CentOS 8. Vous pouvez ajouter des règles nftables manuelles dans une table distincte (ex. inet custom) sans interférer avec les zones firewalld, à condition de gérer les priorités de chaînes. En revanche, désactiver firewalld pour piloter nftables directement élimine l'overhead du daemon (~10 MB RAM) et simplifie le débogage.

UFW peut-il gérer des listes noires IP dynamiques de plusieurs milliers d'entrées ?

Non, UFW génère une règle iptables/nftables par IP, ce qui dégrade les performances linéairement (O(n)). Au-delà de 500 IP, privilégiez nftables avec un set (nft add set inet filter blacklist { type ipv4_addr ; flags interval ; }) ou une solution XDP/eBPF comme PAKKT qui maintient une BPF map de millions d'entrées évaluée en O(1) à la carte réseau.

Comment migrer de iptables vers nftables sans perdre les règles fail2ban ou Docker ?

Utilisez iptables-restore-translate pour convertir vos règles iptables en syntaxe nftables. Pour fail2ban, passez au backend nftables (/etc/fail2ban/jail.local, banaction = nftables-multiport). Docker injecte des règles dans la table nat et filter : créez votre propre table nftables (ex. inet custom) avec priorité différente pour éviter les conflits. PAKKT isole automatiquement sa table inet pakkt, garantissant zéro interférence avec Docker ou fail2ban.