iptables vs nftables: wat is er veranderd en hoe migreer je

Eerst het antwoord: je draait waarschijnlijk al nftables

De framing "iptables vs nftables" wekt de suggestie van een keuze tussen twee levende opties. Voor de meeste servers in 2026 was die keuze al gemaakt door je distributie:

• Op Debian 10+ en Ubuntu 20.10+ is het iptables-commando standaard iptables-nft, een compatibiliteitslaag die iptables-syntax accepteert maar het nf_tables-subsysteem van de kernel programmeert. Je iptables-regels draaien al op de nftables-engine.
• Bij de RHEL-familie (RHEL/AlmaLinux/Rocky 9 en 10) is het hele iptables-framework verouderd verklaard, spreekt firewalld native nftables, en levert RHEL 10 de legacy ip_tables-kernelmodule helemaal niet meer mee.
• Upstream bevindt iptables zich in maintenance mode: het krijgt nog altijd releases (1.8.13 verscheen in maart 2026), maar alle featureontwikkeling vindt plaats in nftables.

Het praktische advies is dus kort: bestaande, werkende iptables-rulesets zijn geen noodgeval; de compatibiliteitslaag is goed en stabiel. Maar nieuwe regels en nieuwe automatisering horen in native nftables te worden geschreven: één syntax voor IPv4 en IPv6, sets en maps die schalen, atomaire reloads, en geen afhankelijkheid van een shim waarvan distributies de onderliggende tooling voor uiteindelijke verwijdering hebben gemarkeerd. De rest van dit artikel is de onderbouwing van dat advies, plus de migratiemechaniek.

Hoe we hier zijn beland

netfilter, het packet-filtering-subsysteem van de kernel, heeft drie gebruikersgerichte generaties doorgemaakt: ipchains (kernel 2.2), iptables (kernel 2.4, 2001) en nftables (samengevoegd in kernel 3.13, 2014). nftables is geschreven door hetzelfde netfilter-team om de structurele problemen van iptables op te lossen in plaats van eromheen te patchen.

De sleutelrelease was iptables 1.8 (2018), die het commando opsplitste in twee varianten: iptables-legacy (de klassieke implementatie) en iptables-nft (dezelfde command-line-syntax, maar regels worden uitgevoerd door de nf_tables-kernelengine). Distributies schakelden hun standaardalias vrijwel meteen om naar de nft-variant, en zo migreerden miljoenen servers van engine zonder dat hun beheerders het merkten:

Check wat een gegeven machine daadwerkelijk gebruikt; het antwoord staat tussen haakjes:

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

Wat er daadwerkelijk is veranderd

De verschillen die operationeel ertoe doen, niet het marketingrijtje:

Eén tool, beide adresfamilies

De oerzonde van iptables: iptables, ip6tables, arptables en ebtables waren vier aparte tools met vier aparte rulesets, en elke dual-stack-server moest zijn beleid twee keer geschreven (en onderhouden, en geaudit) hebben. Het IPv6-deel vergeten was het klassieke gat. De inet-familie van nftables past één tabel toe op zowel IPv4 als IPv6. De hele klasse van "v4 afgeschermd, v6 vergeten"-bugs verdwijnt structureel.

Sets en maps zijn eersteklas

In iptables betekende het matchen van 500 adressen 500 regels (lineair geëvalueerd), of het erbij plakken van de aparte ipset-tool. In nftables zijn sets native:

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

Eén regel, O(1)-achtige lookup, tijdens runtime bijwerkbaar zonder de ruleset aan te raken. Maps gaan verder en koppelen matchcriteria aan acties of bestemmingen (constructies in de trant van dnat to tcp dport map { 80 : 10.0.0.10, 443 : 10.0.0.11 } persen hele regelfamilies samen tot één lookup). Dynamische sets voeden ook per-source rate limiting, die we gebruiken in onze firewallregels-baseline.

Atomaire ruleset-vervanging

nft -f ruleset.conf valideert en past het hele bestand atomair toe: het laadt volledig, of de oude ruleset blijft ongewijzigd. iptables-scripts pasten regels één commando tegelijk toe, dus een storing halverwege liet de firewall achter in een half geconfigureerde staat (af en toe, memorabel, in de staat waarin de default-drop al was toegepast maar de SSH-allow nog niet). iptables-restore verzachtte dit per tabel; bij nftables is dit de enige manier van werken. Daarnaast geeft nft -c je een dry-run-syntaxcheck.

Geen ingebouwde chains, geen vaste pipeline

iptables gaf elke tabel vaste chains (INPUT, FORWARD, OUTPUT...) die bestaan ongeacht of ze gebruikt worden, elk met eigen kosten per pakket. In nftables maak je alleen de chains die je nodig hebt en koppel je ze aan kernel-hooks met expliciete prioriteiten. De overhead van een lege firewall is werkelijk nul, en de ruleset die je leest is de hele waarheid, niets impliciets.

Betere introspectie en automatisering

nft monitor streamt ruleset-wijzigingen live (uitstekend voor "wat heeft er zojuist mijn firewall veranderd?"-debugging), counters zijn per regel opt-in, en nft -j spreekt JSON in beide richtingen, het moderne antwoord op een generatie broze iptables-save-parsers. Sjabloneer je firewallconfig met Ansible of Terraform, dan is native nftables aanmerkelijk minder pijnlijk.

Syntax naast elkaar

De taken die je daadwerkelijk uitvoert, in beide talen:

De nftables-kolom leest als een taal in plaats van als de flag-soep van een commando, omdat het er ook een is: expressies combineren vrij (ip saddr @admins tcp dport 22 ct state new accept) in plaats van dat elke feature een eigen matchmodule vereist.

Performance: de eerlijke versie

Claims dat nftables veel sneller (of langzamer) is, zijn allebei makkelijk te vinden en grotendeels ongefundeerd. De geloofwaardige publieke data:

• De netfilter-ontwikkelaars van Red Hat benchmarkten de twee in 2017: bij kleine, lineaire rulesets was iptables in werkelijkheid iets sneller; het beeld kantelt zodra sets in het spel komen: bij het matchen over ~120+ poorten of grote adresgroepen degradeert iptables lineair terwijl nftables vlak blijft. Hun conclusie was dat de architecturen vergelijkbaar zijn en dat de winst in sets/maps zit, niet in de ruwe snelheid per regel. (data uit 2017: de vorm van de conclusie is overeind gebleven, maar behandel de absolute cijfers als historisch.)
• Op orchestratieschaal wordt het verschil zichtbaar: de kube-proxy van Kubernetes kreeg een GA nftables-modus in 1.33, vooral omdat de lineaire regelevaluatie en volledige tabel-reloads van iptables pijn doen bij tienduizenden services. Bij ~30,000 services versloeg de tail-latency van de nftables-modus de beste latency van de iptables-modus. Opvallend genoeg blijft de iptables-modus de standaard van Kubernetes, voor compatibiliteit.

Voor een enkele server met tientallen regels meet je geen verschil. Kies voor nftables vanwege de expressiviteit, de atomiciteit en het feit dat alle onderhouds- en ontwikkelinspanning daar nu naartoe gaat, niet vanwege doorvoer.

Migreren

Stap 1: uitzoeken wat je draait

iptables -V (zie hierboven). Check ook op regels in beide engines, een verrassend veelvoorkomende puinhoop na gedeeltelijke migraties:

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 toont alles in nf_tables, inclusief regels die via de shim zijn aangemaakt; het is het enige commando dat nooit tegen je liegt over de werkelijke staat van de firewall.

Stap 2: mechanische vertaling

Het iptables-pakket levert vertalers mee. Dezelfde syntax erin, nft-syntax eruit:

$ 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 voor de v6-helft.) De output is correct maar letterlijk: hij reproduceert je v4/v6-duplicatie en per-regel-structuur zoals ze zijn.

Stap 3: het model daadwerkelijk omarmen

Behandel het vertaalde bestand als steiger, en herstructureer daarna: voeg de v4/v6-rulesets samen tot één inet-tabel, comprimeer herhaalde poort-/adresregels tot sets, en voeg commentaar toe. Een iptables-ruleset van 100 regels wordt routinematig 30 leesbare nftables-regels. Ons firewall-baseline-artikel is een redelijk skelet om naartoe te migreren. Pas toe met een geplande rollback en een tweede, open SSH-sessie (de mechaniek om lockout te vermijden komt daar ook aan bod).

De valkuilen

• Draai geen regels in beide engines. Legacy iptables- en nftables-regels worden allebei geëvalueerd, onafhankelijk van elkaar. Een pakket moet beide overleven. Dit "werkt", totdat het ondebugbaar gedrag oplevert. Migreer, verifieer, en flush daarna de legacy-kant.
• Docker spreekt nog steeds iptables. Docker programmeert zijn NAT/forwarding standaard via de iptables-interface (prima: op moderne systemen is dat de nft-shim; verwijder het iptables-pakket niet op een Docker-host). De native nftables-backend verscheen experimenteel in Engine 29, maar is opt-in. Praktisch gevolg: zet op een Docker-host je beleid in de DOCKER-USER-chain of in je eigen tabellen, en doe niet blindelings flush ruleset. Dat mept ook de regels van Docker weg. (Zelfde verhaal voor Kubernetes-nodes: check je CNI en kube-proxy-modus voordat je de firewall aanraakt.)
• Frontends zijn prima. Kies één laag. ufw (iptables-syntax over de shim) en firewalld (native nftables-backend sinds 2018) werken vandaag beide correct. Het antipatroon is het handmatig bewerken van nft-tabellen op een machine die door een frontend wordt beheerd; de frontend wint bij de volgende reload.

Wanneer bij iptables blijven redelijk is

Eerlijkheid over de andere kant: een stabiele, appliance-achtige server met een werkende, geauditeerde iptables-nft-ruleset en geen actieve regelontwikkeling heeft weinig te winnen bij een herschrijving. Tooling die alleen iptables uitstoot (oudere fail2ban-acties, legacy orchestratie) is ook een legitieme reden om uit te stellen; de shim bestaat precies hiervoor. De lijn die je moet vasthouden is richtinggevend: schrijf geen nieuwe systemen, rollen of documentatie tegen de legacy-syntax, want de RHEL-familie heeft de verwijdering ervan al ingepland en de rest van het ecosysteem volgt het netfilter-team van Red Hat.

Veelgestelde vragen

Is iptables verouderd?

Precies: verouderd verklaard door distributies, onderhouden upstream. Het netfilter-project blijft iptables uitbrengen (1.8.13, maart 2026) en heeft geen end-of-life aangekondigd. Maar Red Hat heeft het hele iptables-framework in RHEL 9 verouderd verklaard, de legacy kernelmodule in RHEL 10 verwijderd, en bij elke grote distro is de standaard al jaren de nftables-engine. "Dood" is onjuist; "legacy interface op geleende tijd" is juist.

Gebruiken ufw en firewalld nftables?

firewalld: ja, native. nftables is sinds 2018 de standaardbackend. ufw: indirect. Het genereert iptables-regels en voert ze uit via de iptables-binary van het systeem, wat op elke moderne Ubuntu de nft-gebaseerde shim is, dus de regels komen terecht in nf_tables; ufw zelf heeft geen native nftables-modus. Hoe dan ook, je regels belanden in hetzelfde kernel-subsysteem.

Stoppen mijn iptables-regels met werken als ik overstap?

De logica van je regels vertaalt zich naadloos; iptables-restore-translate zet een opgeslagen ruleset mechanisch om, en de nftables-engine ondersteunt alles wat de basis-featureset van iptables ook doet. Wat niet automatisch meekomt: ipset-definities (opnieuw aanmaken als native sets), elk script dat de output van iptables -L parseert, en aannames over ingebouwde chains. Vertaal, doe een dry-run met nft -c, pas atomisch toe, houd een rollback gepland.

Is nftables sneller dan iptables?

Op kleine schaal: nee. De eigen benchmarks van Red Hat toonden dat platte lineaire rulesets iptables licht bevoordeelden. nftables wint waar structuur ertoe doet: grote poort-/adressets (plat in plaats van lineair opzoeken), zeer grote rulesets, en frequente regelwijzigingen (atomaire incrementele updates in plaats van volledige tabel-reloads, de reden waarom Kubernetes een nftables-kube-proxy bouwde). Voor een typische serverfirewall kies je op onderhoudbaarheid; performance is gelijkspel.

Uitrollen op Serverside

Welke syntax je ook schrijft, de firewall op de host is één laag van twee op ons netwerk: elke dedicated server heeft een self-service edgefirewall (niet-servicegebonden verkeer wordt upstream gedropt voordat het je poort bereikt), plus altijd-actieve DDoS-mitigatie op ASN 55285, met provisioning binnen een minuut op elke grote Linux-distributie.

Bouw voort op dit artikel met de complete standaard firewallregels voor een Linux-server, het bredere dreigingsbeeld in DDoS-aanvallen uitgelegd, en hands-on trafficforensics in een DDoS-aanval vastleggen en analyseren met Wireshark.