nftables Firewall Setup Guide (2026)

Einleitung: Warum nftables 2026 unverzichtbar ist

Hand aufs Herz — wer heute noch iptables-Regeln von Hand pflegt, lebt ein bisschen in der Vergangenheit. Seit Debian 10, Ubuntu 20.04 und RHEL 8 ist nftables das Standard-Firewall-Backend auf allen großen Enterprise-Distributionen. Und mit dem Release von nftables 1.1.6 im Dezember 2025 hat das Framework einen Reifegrad erreicht, bei dem es wirklich keinen guten Grund mehr gibt, an iptables festzuhalten.

Die Zahlen sprechen eine deutliche Sprache: 2025 wurden über 5.500 Kernel-CVEs veröffentlicht. Ransomware-Gruppen setzen gezielt auf Netzwerk-Exploits. Und die Angriffsfläche eines ungeschützten Linux-Servers wächst mit jedem offenen Port. Eine sauber konfigurierte Firewall ist keine Option — sie ist schlicht die erste Verteidigungslinie.

In diesem Leitfaden gehen wir die gesamte nftables-Konfiguration durch: von den Grundlagen über die Migration bestehender iptables-Regeln bis hin zu fortgeschrittenen Techniken wie Rate Limiting, Geo-Blocking und dem oft unterschätzten Zusammenspiel mit Docker und Podman. Alles mit praxiserprobten Befehlen, die Sie direkt auf Ihrem Server einsetzen können.

Also, legen wir los.

nftables vs. iptables: Was hat sich geändert?

Die Schwächen von iptables

iptables hat uns zwei Jahrzehnte lang treue Dienste geleistet — keine Frage. Aber die Architektur zeigt mittlerweile deutlich ihr Alter. Jede Regeländerung erfordert das vollständige Ersetzen des gesamten Regelwerks im Kernel. Es gibt keine native Unterstützung für Sets oder Maps — dafür brauchte man das externe Tool ipset. IPv4 und IPv6 erfordern zwei separate Werkzeuge (iptables und ip6tables). Und bei tausenden Regeln wird die lineare Verarbeitung (O(n)) zum echten Performance-Problem.

Wer schon mal einen Server mit 2.000+ iptables-Regeln debuggen musste, weiß genau, wovon ich rede.

Was nftables besser macht

nftables räumt mit diesen Einschränkungen grundlegend auf:

Ein Tool für alles: nft ersetzt iptables, ip6tables, arptables und ebtables. Ein einziges Framework, eine einheitliche Syntax.
Atomare Updates: Regeländerungen werden transaktionsbasiert angewendet — entweder komplett oder gar nicht. Keine teilweise angewendeten Regelwerke mehr.
Native Sets und Maps: Hash-basierte Datenstrukturen mit O(1)-Lookup sind direkt eingebaut. Ein Set mit 10.000 IP-Adressen ist genauso schnell wie eines mit 10.
Dual-Stack in einer Tabelle: Die inet-Familie verarbeitet IPv4 und IPv6 in denselben Regeln.
Mehrere Aktionen pro Regel: Statt einer Regel pro Aktion (wie bei iptables mit -j) können Sie in nftables loggen, zählen und verwerfen — alles in einer einzigen Regel.
Keine vordefinierten Tabellen: Sie erstellen genau die Struktur, die Sie brauchen. Keine ungenutzten Standard-Chains, die unnötig Performance kosten.

Versionsüberblick: nftables 1.1.6 (Dezember 2025)

Die aktuelle Version bringt einige spannende Neuerungen mit:

Vollständige Unterstützung für Lightweight-Tunnel-Templates (VXLAN, Geneve, ERSPAN)
Wildcard-Support in Netdev-Hooks — ziemlich praktisch für Multi-Interface-Server
Verbesserte Big-Endian-Kompatibilität (relevant für s390x und PowerPC)
Neue AFL++-Fuzzer-Infrastruktur für bessere Sicherheitstests
Benötigt mindestens libnftnl 1.3.1 und libmnl 1.0.4

Installation und erste Schritte

nftables installieren

Auf den meisten aktuellen Distributionen ist nftables bereits vorinstalliert. Falls nicht, ist die Installation schnell erledigt:

# Debian/Ubuntu
sudo apt install nftables

# RHEL/CentOS/Fedora
sudo dnf install nftables

# Arch Linux
sudo pacman -S nftables

# openSUSE
sudo zypper install nftables

Dienst aktivieren und starten

# nftables-Dienst aktivieren (startet automatisch beim Booten)
sudo systemctl enable nftables.service

# Dienst starten
sudo systemctl start nftables.service

# Status prüfen
sudo systemctl status nftables.service

# Installierte Version prüfen
nft --version

Kleines Detail am Rande: Seit einem Update Anfang 2025 enthält die systemd-Unit die Bedingung ConditionFileNotEmpty=/etc/nftables.conf. Der Dienst startet also nur, wenn die Konfigurationsdatei tatsächlich existiert und nicht leer ist. Das ist ein sinnvoller Schutz vor Fehlstarts bei frischen Installationen — hat mich aber anfangs kurz verwirrt, als auf einem neuen Server einfach nichts passierte.

Aktuellen Zustand prüfen

# Alle aktiven Regeln anzeigen
sudo nft list ruleset

# Nur bestimmte Tabelle anzeigen
sudo nft list table inet filter

# Prüfen, ob iptables-nft oder iptables-legacy aktiv ist
sudo update-alternatives --display iptables    # Debian/Ubuntu
sudo alternatives --display iptables           # RHEL/Fedora

Die Grundstruktur verstehen: Tables, Chains, Rules

Bevor wir ans Konfigurieren gehen, sollten Sie die drei Bausteine von nftables verstehen. Anders als bei iptables gibt es hier keine vordefinierten Tabellen oder Chains — Sie bauen alles selbst auf. Das klingt erstmal nach mehr Arbeit, gibt Ihnen aber deutlich mehr Kontrolle.

Tables (Tabellen)

Eine Tabelle ist ein Container für Chains und andere Objekte. Jede Tabelle gehört zu einer Address Family:

ip — nur IPv4
ip6 — nur IPv6
inet — IPv4 und IPv6 gemeinsam (empfohlen für die meisten Anwendungsfälle)
arp — ARP-Pakete
bridge — Bridge-Frames
netdev — Pakete direkt am Netzwerkinterface (für XDP und frühe Filterung)

Für die allermeisten Server-Setups ist inet die richtige Wahl.

Chains (Ketten)

Chains enthalten die eigentlichen Regeln. Es gibt zwei Typen:

Base Chains: Direkt mit einem Netfilter-Hook verbunden (input, output, forward, prerouting, postrouting). Sie haben einen type, eine priority und eine policy.
Regular Chains: Werden nur über jump oder goto aus anderen Chains aufgerufen — nützlich, wenn Sie Ihr Regelwerk modular aufbauen wollen.

Rules (Regeln)

Regeln bestehen aus Matching-Ausdrücken und Aktionen (Verdicts). Die wichtigsten Verdicts im Überblick:

accept — Paket durchlassen
drop — Paket stillschweigend verwerfen
reject — Paket ablehnen und ICMP-Fehlermeldung senden
log — Paket protokollieren (kann mit anderen Aktionen kombiniert werden)
counter — Paket zählen
jump / goto — In eine andere Chain wechseln

Praxis: Server-Firewall von Grund auf konfigurieren

Minimale sichere Basiskonfiguration

So, jetzt wird es konkret. Hier ist ein vollständiges, praxiserprobtes Regelwerk für einen typischen Linux-Server. Es folgt dem Default-Deny-Prinzip: Alles wird blockiert, was nicht explizit erlaubt ist.

#!/usr/sbin/nft -f

# Alle bestehenden Regeln löschen
flush ruleset

table inet filter {
    # Set für vertrauenswürdige Admin-Netzwerke
    set trusted_nets {
        type ipv4_addr
        flags interval
        elements = { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
    }

    # Set für erlaubte Dienste
    set allowed_tcp_ports {
        type inet_service
        elements = { 22, 80, 443 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        # Bestehende und zugehörige Verbindungen erlauben
        ct state established,related accept

        # Loopback-Interface immer erlauben
        iif "lo" accept

        # Ungültige Pakete sofort verwerfen
        ct state invalid counter drop

        # ICMP für IPv4 erlauben (Ping, Path MTU Discovery)
        ip protocol icmp icmp type {
            echo-request,
            echo-reply,
            destination-unreachable,
            time-exceeded,
            parameter-problem
        } accept

        # ICMPv6 erlauben (für IPv6-Funktionalität essentiell)
        ip6 nexthdr icmpv6 icmpv6 type {
            echo-request,
            echo-reply,
            destination-unreachable,
            packet-too-big,
            time-exceeded,
            parameter-problem,
            nd-neighbor-solicit,
            nd-neighbor-advert,
            nd-router-solicit,
            nd-router-advert
        } accept

        # Erlaubte TCP-Dienste
        tcp dport @allowed_tcp_ports accept

        # SSH nur aus vertrauenswürdigen Netzwerken
        # (Entfernen Sie Port 22 aus allowed_tcp_ports wenn Sie dies nutzen)
        # ip saddr @trusted_nets tcp dport 22 accept

        # Alles andere loggen und verwerfen
        log prefix "nftables-drop: " flags all counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Das sieht auf den ersten Blick nach viel aus, ist aber im Kern übersichtlich: Bestehende Verbindungen durchlassen, Loopback erlauben, ICMP zulassen, definierte Ports öffnen, den Rest droppen. Fertig.

Konfiguration anwenden und validieren

# Syntax prüfen OHNE anzuwenden (Dry-Run)
sudo nft -c -f /etc/nftables.conf

# Konfiguration laden
sudo nft -f /etc/nftables.conf

# Aktives Regelwerk anzeigen
sudo nft list ruleset

# Einzelne Chain anzeigen
sudo nft list chain inet filter input

# Counter zurücksetzen
sudo nft reset counters

Wichtig: Testen Sie Firewall-Änderungen immer mit einer Out-of-Band-Konsolenverbindung (IPMI, iDRAC, ILO oder KVM-over-IP) als Fallback. Falls Sie sich per SSH aussperren, brauchen Sie einen alternativen Zugang. Ich spreche aus Erfahrung.

Webserver mit Rate Limiting absichern

Für einen Webserver, der HTTP/HTTPS bedient und vor Brute-Force-Angriffen auf SSH geschützt werden soll, eignet sich folgende Konfiguration:

table inet filter {
    # Dynamisches Set für SSH-Rate-Limiting
    set ssh_ratelimit {
        type ipv4_addr
        flags dynamic,timeout
        timeout 60s
    }

    # Dynamisches Set für temporäre Sperren
    set temp_blocked {
        type ipv4_addr
        flags dynamic,timeout
        timeout 5m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        ct state established,related accept
        iif "lo" accept
        ct state invalid drop

        # Temporär gesperrte IPs sofort verwerfen
        ip saddr @temp_blocked counter drop

        # ICMP (begrenzt auf 5 pro Sekunde)
        ip protocol icmp limit rate 5/second accept
        ip6 nexthdr icmpv6 limit rate 5/second accept

        # HTTP/HTTPS ohne Einschränkung
        tcp dport { 80, 443 } accept

        # SSH mit Rate Limiting: max. 3 neue Verbindungen pro Minute
        tcp dport 22 ct state new             add @ssh_ratelimit { ip saddr limit rate 3/minute } accept

        # Zu viele SSH-Versuche -> temporäre Sperre
        tcp dport 22 ct state new             add @temp_blocked { ip saddr }             log prefix "nft-ssh-blocked: " drop

        log prefix "nftables-drop: " counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Das Schöne an diesem Setup: Wer mehr als 3 SSH-Verbindungsversuche pro Minute startet, landet automatisch für 5 Minuten auf der Sperrliste. Ganz ohne fail2ban.

Migration von iptables zu nftables

Schritt 1: Bestandsaufnahme

Bevor Sie irgendetwas ändern — und das kann ich nicht oft genug betonen — sichern Sie Ihren aktuellen Zustand:

# Backup-Verzeichnis erstellen
sudo mkdir -p /etc/firewall-backup

# Bestehende iptables-Regeln sichern
sudo iptables-save > /etc/firewall-backup/iptables-$(date +%Y%m%d).rules
sudo ip6tables-save > /etc/firewall-backup/ip6tables-$(date +%Y%m%d).rules

# Prüfen, welches Backend aktiv ist
# Wenn die Ausgabe "iptables-nft" zeigt, nutzt Ihr System bereits
# nftables als Backend mit iptables-Kompatibilitätsschicht
iptables -V

Schritt 2: Übersetzungswerkzeuge nutzen

Das Paket iptables-nft bringt praktische Übersetzungstools mit, die den Großteil der Arbeit abnehmen:

# Einzelne Regel übersetzen
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Ausgabe: nft add rule ip filter INPUT tcp dport 22 counter accept

# Gesamtes Regelwerk auf einmal übersetzen
iptables-restore-translate -f /etc/firewall-backup/iptables-$(date +%Y%m%d).rules     > /etc/firewall-backup/nftables-translated.nft

# IPv6-Regeln ebenfalls übersetzen
ip6tables-restore-translate -f /etc/firewall-backup/ip6tables-$(date +%Y%m%d).rules     >> /etc/firewall-backup/nftables-translated.nft

Schritt 3: Übersetzte Regeln prüfen und bereinigen

Die automatische Übersetzung ist ein brauchbarer Startpunkt — aber verlassen Sie sich nicht blind darauf. Bekannte Stolperfallen:

Subnetz-Definitionen: Der Übersetzer wandelt manchmal Subnetze in einzelne IP-Adressen um, die dann nie matchen.
NAT-Tabellen: Chains werden gelegentlich mit Typ filter statt nat generiert — der Kernel lehnt dann masquerade-Verdicts ab.
Komplexe Erweiterungen: Nicht alle iptables-Module haben ein direktes nftables-Äquivalent.

Prüfen Sie jede übersetzte Regel manuell. Und nutzen Sie die Gelegenheit, Ihr Regelwerk zu vereinfachen — Sets und Maps machen viele einzelne Regeln überflüssig.

Schritt 4: Umschalten und testen

# Syntax der neuen Regeln prüfen
sudo nft -c -f /etc/nftables.conf

# Alte iptables-Regeln leeren
sudo iptables -F
sudo ip6tables -F

# Neue nftables-Regeln laden
sudo nft -f /etc/nftables.conf

# Verbindungstest (in einer separaten Konsole!)
# SSH, HTTP, DNS — alles prüfen, was funktionieren muss

# nftables-Dienst aktivieren
sudo systemctl enable nftables.service

# iptables-Dienst deaktivieren (falls vorhanden)
sudo systemctl disable iptables.service 2>/dev/null
sudo systemctl disable ip6tables.service 2>/dev/null

Goldene Regel der Migration: Mischen Sie nach der Umstellung niemals iptables- und nft-Befehle. Die Kompatibilitätsschicht iptables-nft übersetzt stillschweigend — und das führt zu schwer debugbaren Konflikten, die einen zur Verzweiflung treiben können.

Fortgeschrittene Techniken: Sets, Maps und Named Counters

Jetzt wird es richtig interessant. Sets und Maps sind ehrlich gesagt der Hauptgrund, warum sich der Umstieg auf nftables lohnt.

Named Sets für IP-Blocklisten

# Blockliste als Named Set definieren
table inet filter {
    set blocklist {
        type ipv4_addr
        flags interval
        # Elemente können auch aus einer Datei geladen werden
        elements = {
            203.0.113.0/24,
            198.51.100.50
        }
    }

    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif "lo" accept

        # Blockliste prüfen — O(1) Lookup!
        ip saddr @blocklist counter drop

        tcp dport { 22, 80, 443 } accept
        counter drop
    }
}

# Dynamisch IPs zur Blockliste hinzufügen (ohne Neustart)
sudo nft add element inet filter blocklist { 192.0.2.100 }

# Element wieder entfernen
sudo nft delete element inet filter blocklist { 192.0.2.100 }

# Alle Elemente im Set anzeigen
sudo nft list set inet filter blocklist

Der entscheidende Vorteil: Sie können IPs zur Laufzeit hinzufügen und entfernen, ohne das gesamte Regelwerk neu laden zu müssen. Bei iptables war das mit ipset möglich, aber deutlich umständlicher.

Maps für Port-basiertes Routing

Maps verknüpfen Werte miteinander — zum Beispiel Ports mit spezifischen Aktionen oder Ziel-Adressen. Ziemlich mächtig, wenn man sich erstmal daran gewöhnt hat:

table inet filter {
    # Verdict-Map: Port -> Aktion
    map port_policy {
        type inet_service : verdict
        elements = {
            22 : accept,
            80 : accept,
            443 : accept,
            8080 : drop
        }
    }

    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif "lo" accept

        # Entscheidung per Map-Lookup
        tcp dport vmap @port_policy

        counter drop
    }
}

Named Counters für Monitoring

# Named Counter in der Konfiguration definieren
table inet filter {
    counter cnt_ssh_accepted {
        comment "Akzeptierte SSH-Verbindungen"
    }
    counter cnt_dropped_total {
        comment "Insgesamt verworfene Pakete"
    }

    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif "lo" accept

        tcp dport 22 counter name cnt_ssh_accepted accept
        counter name cnt_dropped_total drop
    }
}

# Counter abfragen (ideal für Monitoring-Skripte)
sudo nft list counter inet filter cnt_ssh_accepted
sudo nft list counter inet filter cnt_dropped_total

Named Counters lassen sich wunderbar in Prometheus oder Grafana einbinden — aber das ist Stoff für einen eigenen Artikel.

Geo-Blocking mit nftables umsetzen

Geo-Blocking ist kein Allheilmittel — das sei gleich vorweg gesagt. Aber es ist eine sinnvolle zusätzliche Schutzschicht, besonders für Dienste, die nur aus bestimmten Ländern erreichbar sein müssen.

Strategie: Eigene Tabelle für Geo-Filterung

Erstellen Sie eine separate Tabelle für Geo-Blocking. So bleibt Ihre Hauptkonfiguration übersichtlich, und Änderungen am Geo-Filter beeinflussen nicht Ihre anderen Regeln.

# Separate Geo-Blocking-Tabelle mit hoher Priorität
table inet geo_filter {
    set blocked_countries {
        type ipv4_addr
        flags interval
        # Hier werden die IP-Bereiche eingefügt
    }

    set blocked_countries_v6 {
        type ipv6_addr
        flags interval
    }

    chain prerouting {
        # raw-Priorität (-300): Pakete werden VOR Connection Tracking verworfen
        type filter hook prerouting priority raw; policy accept;

        ip saddr @blocked_countries counter drop
        ip6 saddr @blocked_countries_v6 counter drop
    }
}

IP-Listen automatisch aktualisieren

# nft-geo-filter installieren (Go-basiertes Tool)
# https://github.com/rpthms/nft-geo-filter
go install github.com/rpthms/nft-geo-filter@latest

# IP-Bereiche für bestimmte Länder herunterladen und als nftables-Set generieren
nft-geo-filter -table inet -table-name geo_filter     -set-name blocked_countries     -action drop CN RU KP

# Alternativ: Cronjob für tägliche Aktualisierung
cat > /etc/cron.daily/update-geo-blocklist << 'SCRIPT'
#!/bin/bash
nft-geo-filter -table inet -table-name geo_filter     -set-name blocked_countries     -action drop CN RU KP     -output /tmp/geo-rules.nft
nft -f /tmp/geo-rules.nft
rm /tmp/geo-rules.nft
logger "Geo-Blockliste aktualisiert"
SCRIPT
chmod +x /etc/cron.daily/update-geo-blocklist

Wichtig: Platzieren Sie die Geo-Blocking-Chain mit priority raw im Prerouting-Hook. Pakete werden dann verworfen, bevor Connection Tracking überhaupt greift — das spart erhebliche Ressourcen bei großen Blocklisten.

nftables und Container: Docker, Podman und die Fallstricke

Hier wird es ehrlich gesagt richtig frustrierend. Die Container-Welt und nftables sprechen 2026 immer noch nicht durchgehend dieselbe Sprache.

Das Docker-Problem

Docker wurde um iptables herum gebaut. Es fügt eigene Chains ein, manipuliert NAT-Regeln und geht davon aus, die vollständige Kontrolle über die Paketfilterung zu haben. Das kollidiert mit nftables auf mehreren Ebenen:

Docker injiziert iptables-Regeln, die über die iptables-nft-Kompatibilitätsschicht stillschweigend übersetzt werden
firewalld-Reloads können Dockers NAT-Chains zerstören ("Failed to program NAT chain")
Docker geht davon aus, die FORWARD-Chain zu besitzen — Ihre manuellen nftables-Regeln werden möglicherweise einfach ignoriert

Docker 29+ mit nativem nftables-Support

Seit Docker 29.0.0 gibt es endlich experimentellen nftables-Support. Noch nicht perfekt, aber ein großer Schritt in die richtige Richtung:

# Docker-Daemon-Konfiguration anpassen
cat > /etc/docker/daemon.json << 'EOF'
{
    "firewall-backend": "nftables"
}
EOF

# Docker-Dienst neu starten
sudo systemctl restart docker

# Prüfen, ob nftables-Regeln von Docker erstellt wurden
sudo nft list ruleset | grep -i docker

Wichtige Einschränkungen (Stand Anfang 2026):

Der Support ist experimentell — Verhalten kann sich jederzeit ändern
Overlay-Netzwerke (Swarm Mode) sind nicht unterstützt
Es gibt keine DOCKER-USER-Chain mehr — eigene Regeln gehören in separate Tabellen
Wechsel zwischen iptables- und nftables-Backend erfordert einen Neustart aller Container

Podman mit Netavark: Der sauberere Ansatz

Podman hat mit Netavark ab Version 1.10 nativen nftables-Support. Meiner Erfahrung nach funktioniert das deutlich reibungsloser als bei Docker. Alle Regeln landen in einer eigenen netavark-Tabelle, was Konflikte mit anderen Firewall-Tools erheblich reduziert:

# Podman-Container-Netzwerk-Backend auf nftables umstellen
# In /etc/containers/containers.conf oder ~/.config/containers/containers.conf:
[network]
firewall_driver = "nftables"

# Alternativ in /etc/containers/networks/podman.json
# "firewall_driver": "nftables"

# Prüfen, welches Backend aktiv ist
podman info | grep -i firewall

Der Vorteil von Podman: Rootless Podman arbeitet hervorragend mit firewalld und nftables zusammen, da es keine Firewall-Regeln umgeht. Bei Docker müssen Sie dagegen immer damit rechnen, dass iptables-Regeln direkt manipuliert werden.

Eigene Regeln neben Container-Regeln

# RICHTIG: Eigene Tabelle verwenden — keine Konflikte mit Docker/Podman
table inet my_custom_rules {
    chain input {
        type filter hook input priority 10; policy accept;
        # Ihre eigenen Regeln hier
        # Höhere Priorität (10) = wird NACH Docker/Podman-Regeln ausgewertet
    }
}

# FALSCH: Dockers Tabellen direkt modifizieren
# -> Änderungen werden beim nächsten Docker-Restart überschrieben!

Best Practices für die Server-Härtung mit nftables

1. Default-Deny als Grundprinzip

Setzen Sie die Policy jeder Input- und Forward-Chain auf drop. Erlauben Sie explizit nur den Traffic, den Ihr Server tatsächlich braucht.

Jeder offene Port ist ein potenzieller Angriffsvektor. So einfach ist das.

2. Connection Tracking als erste Regel

Die Regel ct state established,related accept muss immer ganz oben in Ihrer Input-Chain stehen. Ohne diese Regel werden Antwortpakete blockiert — auch für Verbindungen, die Sie eigentlich erlaubt haben. Ein klassischer Anfängerfehler, der überraschend oft vorkommt.

3. Ungültige Pakete frühzeitig verwerfen

ct state invalid drop gehört direkt nach der Connection-Tracking-Regel. Ungültige Pakete sind oft Anzeichen für Port Scans oder manipulierte Pakete.

4. ICMPv6 nicht blindlings blockieren

Wenn Sie IPv6 nutzen (und das sollten Sie), dürfen Sie essenzielle ICMPv6-Nachrichten nicht blockieren. Neighbor Discovery, Router Solicitation und Path MTU Discovery sind für das Funktionieren von IPv6 schlicht unverzichtbar.

5. Logging mit Bedacht einsetzen

Loggen Sie verworfene Pakete — aber setzen Sie unbedingt Rate Limits auf die Log-Regeln. Sonst wird Ihnen bei einem Angriff die Festplatte mit Log-Einträgen geflutet:

# Logging mit Rate Limit: max. 10 Einträge pro Minute
log prefix "nft-drop: " flags all limit rate 10/minute counter drop

6. Konfiguration validieren vor dem Anwenden

Nutzen Sie immer nft -c -f (Check-Modus), bevor Sie Regeln laden. Und halten Sie eine Konsolenverbindung als Fallback bereit. Immer.

7. Regelmäßige Audits

# Aktuelles Regelwerk exportieren und in Versionskontrolle einchecken
sudo nft list ruleset > /etc/nftables.conf
cd /etc && sudo git add nftables.conf && sudo git commit -m "Firewall-Audit $(date +%Y-%m-%d)"

# Counter regelmäßig prüfen — ungewöhnlich hohe Drop-Counts deuten auf Angriffe hin
sudo nft list counters

8. Nicht mischen: Ein Tool, ein Backend

Entscheiden Sie sich für einen Verwaltungsansatz: Entweder direkte nft-Befehle, oder firewalld, oder ufw. Aber nicht mehrere gleichzeitig. Die Interaktion zwischen verschiedenen Firewall-Management-Tools führt unweigerlich zu unvorhersehbaren Konfigurationen — und unvorhersehbar ist bei Firewalls ein anderes Wort für unsicher.

Troubleshooting: Die häufigsten Probleme

SSH-Aussperrung nach Regeländerung

Die häufigste Panik-Situation (und ja, fast jeder hat das schon mal erlebt): Sie laden neue Regeln und plötzlich ist die SSH-Verbindung weg. Vorbeugung:

# Sicherheitsnetz: at-Job der alte Regeln nach 5 Minuten wiederherstellt
echo "nft -f /etc/firewall-backup/last-working.nft" | at now + 5 minutes

# Dann neue Regeln testen
sudo nft -f /etc/nftables.conf

# Wenn alles funktioniert: at-Job abbrechen
atrm $(atq | tail -1 | cut -f1)

Dieser at-Job-Trick hat mir schon mehr als einmal den Tag gerettet. Wenn innerhalb von 5 Minuten alles passt, brechen Sie den Job ab. Falls nicht, stellt er automatisch die funktionierende Konfiguration wieder her.

Docker-Container haben kein Netzwerk nach Firewall-Änderung

# Docker-Netzwerk-Regeln prüfen
sudo nft list ruleset | grep -A5 -i docker

# Docker-Dienst neu starten (generiert Firewall-Regeln neu)
sudo systemctl restart docker

# Falls firewalld aktiv ist: Docker-Zone prüfen
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=docker --list-all

Regeln werden nach Neustart nicht geladen

# Prüfen, ob die Konfigurationsdatei existiert und nicht leer ist
ls -la /etc/nftables.conf
wc -l /etc/nftables.conf

# Prüfen, ob der systemd-Service aktiviert ist
systemctl is-enabled nftables.service

# Journal auf Fehler prüfen
journalctl -u nftables.service --no-pager -n 20

Häufig gestellte Fragen (FAQ)

Muss ich sofort von iptables zu nftables wechseln?

Nicht sofort — aber Sie sollten es auf die Agenda setzen. iptables wird aktiv nicht mehr weiterentwickelt, und die iptables-nft-Kompatibilitätsschicht ist nur eine Übergangslösung. Auf aktuellen Distributionen (Debian 12, Ubuntu 24.04, RHEL 9) nutzt Ihr System über iptables-nft bereits nftables im Hintergrund. Der vollständige Umstieg auf native nft-Syntax gibt Ihnen Zugang zu allen fortgeschrittenen Funktionen wie Sets, Maps und atomaren Updates.

Kann ich nftables und firewalld gleichzeitig verwenden?

Ja — denn firewalld nutzt nftables als Backend. Wenn Sie firewalld einsetzen, schreiben Sie effektiv nftables-Regeln über eine Abstraktionsschicht. Wichtig ist nur: Modifizieren Sie niemals die von firewalld generierten Tabellen direkt mit nft-Befehlen. Erstellen Sie stattdessen eigene Tabellen für zusätzliche Regeln.

Wie wirkt sich nftables auf die Performance meines Servers aus?

Positiv. nftables nutzt Hash-basierte Sets mit O(1)-Lookup statt linearer Regelverarbeitung (O(n) bei iptables). Bei Servern mit großen Blocklisten oder vielen Regeln ist der Unterschied durchaus spürbar. Die atomaren Updates vermeiden außerdem kurze Zeitfenster ohne Firewall-Schutz, die bei iptables während des Regel-Reloads auftreten konnten.

Was passiert mit meinen iptables-Regeln nach einem Distribution-Upgrade?

Das hängt von der Distribution ab. Bei einem Upgrade auf Debian 12 oder RHEL 9 wird das iptables-Kommando automatisch auf iptables-nft umgestellt. Ihre bestehenden Regeln funktionieren zunächst weiter, werden aber intern in nftables übersetzt. Für einen sauberen Betrieb sollten Sie nach dem Upgrade auf native nftables-Syntax migrieren.

Wie sichere ich meine nftables-Konfiguration richtig?

Exportieren Sie Ihr aktuelles Regelwerk regelmäßig mit nft list ruleset > /etc/nftables.conf und versionieren Sie die Datei mit Git. Für Disaster Recovery empfiehlt sich zusätzlich ein separates Backup der funktionierenden Konfiguration unter /etc/firewall-backup/, das Sie bei Problemen schnell wiederherstellen können.