IPv6-Firewall-Fehlersuche: ip6tables/nftables testen und Traffic-Trace durchführen

Ein funktionierendes IPv6-Netzwerk kann an der Firewall scheitern. Die IPv6-Firewall-Fehlersuche bezieht sich auf die systematische Analyse, warum IPv6-Pakete nicht ankommen oder nicht korrekt verarbeitet werden. In diesem Beitrag lernen Sie, wie Sie ip6tables- und nftables-Regeln prüfen, gezielt Traffic spüren (trace) und mittels Paketmitschnitt (tcpdump/tshark) typische Ursachen identifizieren. Zielgruppe sind Administratoren, System Engineers und Operatoren, die im Betrieb klare Prüfsequenzen, sichere Tests und pragmatische Rückfallstrategien benötigen.

Warum IPv6-Firewall-Fehlersuche anders ist

IPv6 unterscheidet sich in mehreren Punkten entscheidend von IPv4. ICMPv6 ist kein bloßes Diagnoseprotokoll, sondern unverzichtbar für Neighbor Discovery (ND) und Path MTU Discovery (PMTUD). Wird ICMPv6 zu restriktiv blockiert, fallen Adressauflösung und Fragmentierung zusammen und Verbindungen brechen scheinbar ohne Grund. Außerdem existiert bei IPv6 kaum NAT als Standardlösung; Firewalling ist daher stärker auf Routing, Adress-Policies und Stateful-Inspection ausgerichtet.

Wesentliche Begriffe kurz erklärt

• Neighbor Discovery (ND): Mechanismus analog ARP bei IPv4, für Link-Layer-Adressauflösung und Router-Advertisments.
• ICMPv6: Protokollfamilie, notwendig für Fehler- und Steuerungsnachrichten (z. B. „Packet Too Big“ für PMTUD).
• conntrack: Kernel-Komponente zur Verbindungsnachverfolgung (Stateful Firewalling). Ein voller Conntrack-Table kann neue Zustände verhindern oder Pakete verwerfen.
• ip6tables / nftables: Zwei Verwaltungswerkzeuge für Netfilter-Regeln. nftables ist moderner; viele Distributionen bieten Kompatibilitäts-Wrapper.

Vorbereitungen: Basischecks bevor Sie Regeln ändern

Bevor Sie in die Firewall-Regeln eingreifen, prüfen Sie Adresse, Routing und Kernel-Unterstützung. Diese Basischecks helfen, falsche Ursachen auszuschließen.

1. IPv6-Adresse und Routing prüfen

Kontrollieren Sie lokale Adressen und Routen.

ip -6 addr show dev eth0

ip -6 route show

Wenn die Adresse fehlt oder die Route nicht gesetzt ist, trifft das keine Firewall. Erst Behebung von Adress-/Routingfehlern, dann Regeln prüfen.

2. Wichtige Sysctl- und Kernel-Module

Prüfen Sie, ob IPv6-Forwarding und passende Kernel-Module aktiviert sind.

sysctl net.ipv6.conf.all.forwarding
# oder prüfen und temporär setzen
sysctl -w net.ipv6.conf.all.forwarding=1

# Kernel-Module
lsmod | egrep 'nf_tables|ip6_tables|nf_conntrack'

Fehlt nf_tables oder ip6_tables, kann die Firewall die Pakete nicht verarbeiten. In vielen Distributionen liefert das Paketmanagement die passenden Module; notfalls mit modprobe nachladen.

Regelinspektion: ip6tables und nftables systematisch prüfen

Viele Probleme entstehen durch falsche Priorität von Tabellen/Chains oder durch Mixen beider Werkzeuge. Entscheidend ist die Erkenntnis, ob auf dem System eine Kompatibilitätsschicht läuft (z. B. ip6tables-nft) oder beide Tools parallel unterschiedliche Regel-Sets verwalten.

3. ip6tables-Regeln anzeigen

ip6tables -t raw -L -v -n
ip6tables -t filter -L -v -n
ip6tables -S

Die Option -v zeigt Packet- und Byte-Counter; wenn Werte 0 bleiben, passiert kein Traffic durch die Regeln. Die raw-Tabelle kann NOTRACK/NOTABLE-Effekte haben, also dort prüfen.

4. nftables-Regeln anzeigen

nft --version
nft list ruleset
# oder gezielt
nft list table inet filter

nftables nutzt eine einheitliche Regeln-Abstraktion. Achten Sie auf Counters, Log-Statements und auf die Familie (inet, ip, ip6). Ein häufiger Fehler: Regeln sind nur für ipv4 (ip) geschrieben, nicht für inet oder ip6.

5. Erkennen von Wrapper/Compatibility-Schichten

Distributionen bieten häufig Wrapper, die ip6tables-Kommandos auf nftables-Backends abbilden. Prüfen Sie das:

update-alternatives --display ip6tables  # Debian/Ubuntu-Varianten
# oder prüfen, wohin das Binary linkt
readlink -f $(which ip6tables)

Wenn ip6tables auf ein nft-Backend zeigt, dann schreiben Änderungen mit ip6tables in die nft-Repräsentation — aber paralleles Editieren mit nft kann Inkonsistenzen erzeugen.

Messbare Tests: Counters, Logging und gezielte Paketerzeugung

Statt blind zu loggen, sollten Sie kontrollierte Tests ausführen. Sinnvoll sind Counters an kritischen Punkten, gezielte Paketgenerierung und anschließende Captures.

6. Counters in nftables setzen (schnell prüfen, ob Rule matched)

Fügen Sie temporär eine Counter-Regel hinzu, um zu sehen, ob Pakete eine Chain passieren. Counters sind robust und erzeugen keine Log-Flut.

# Beispiel: Zähle eingehende TCP-Pakete auf Port 80 (IPv6)
nft add rule inet filter INPUT tcp dport 80 counter comment "temp-count-http6"

# Zähler ansehen
nft list ruleset | sed -n '/temp-count-http6/,$p'

# Zurücksetzen / entfernen nach Test
# Handle-ID aus nft list ruleset verwenden
nft delete rule inet filter INPUT handle 42

Warum es funktioniert: Counters werden im Kernel aktualisiert, wenn ein Paket die Regel passiert. Wann es scheitert: Wenn Pakete vor der Chain verworfen werden (z. B. in raw oder mangle) oder der falsche Interface-/Family-Kontext genutzt wird.

7. Logging sinnvoll einsetzen

Log-Regeln sind nützlich, aber in Produktion riskant wegen Log-Flut. Stattdessen Log-Filter mit Rate-Limit verwenden oder per nflog an ulogd/tcpdump leiten.

# nftables: rate-limitiertes Loggen
nft add rule inet filter INPUT tcp dport 22 limit rate 5/second counter log prefix "FW-SSH6: "

# ip6tables Beispiel
ip6tables -A INPUT -p tcp --dport 22 -m limit --limit 5/sec -j LOG --log-prefix "FW-SSH6: "

Log-Prefix hilft beim Filtern in syslog/journal. Achten Sie auf Rate-Limits, sonst wird das System belastet.

Traffic captures: tcpdump, tshark und file-basierte Aufnahme

Paketmitschnitt ist der Goldstandard, um zu sehen, ob Pakete das System erreichen, korrekt adressiert sind und ob Antworten gesendet werden.

8. Live-Mitschnitt mit tcpdump

Ein typisches Capture für IPv6-Fehler:

# Capture nur IPv6-ICMP und TCP/UDP für ein bestimmtes Host-Paar
tcpdump -n -i eth0 ip6 and host 2001:db8::10 and '(icmp6 or tcp or udp)'

# Schreiben in eine Datei zur Analyse mit tshark
tcpdump -n -i eth0 ip6 and host 2001:db8::10 -w /tmp/trace-ipv6.pcap

Hinweis: Verwenden Sie -n, um Namensauflösung zu vermeiden; das verlangsamt Captures.

9. Analyse mit tshark oder Wireshark

# Schnelle Statistik per tshark
tshark -r /tmp/trace-ipv6.pcap -q -z conv,ip

# Filter in tshark (nur ICMPv6 "Packet Too Big" analysieren)
tshark -r /tmp/trace-ipv6.pcap -Y "icmpv6.type == 2"

Wichtig ist, speziell nach ICMPv6-Typen zu filtern — Packets Too Big (ICMPv6 Type 2) signalisieren PMTUD-Probleme.

Praktische Tests: Traffic erzeugen und Verhalten beobachten

Simulieren Sie die problematischen Verbindungen von beiden Enden. Verwenden Sie ping6, curl -6, nping (Nmap) oder ein simples socat/nc.

10. Beispiel-Tests

# Echo testen: ICMPv6
ping6 -c 4 2001:db8::10

# TCP-Connect Test mit curl (IPv6)
curl -6 -v http://[2001:db8::10]:80/

# Nping für gezielte Paketerzeugung (Teil von nmap)
nping --tcp -p 80 -c 3 -S 2001:db8::1 2001:db8::10

Diese Tests erzeugen klar erkennbare Signale, die Sie im tcpdump oder in Counters sehen können.

Conntrack, Timeouts und Limits prüfen

Ein häufig übersehener Auslöser sind Conntrack-Limits. Wenn die Tabelle voll ist, verwirft der Kernel neue Verbindungen oder verhält sich inkonsistent.

11. Conntrack prüfen

# Conntrack-Tools (conntrack-utils) anzeigen
conntrack -L -f ipv6 | head

# Aktuelle Limits
sysctl net.netfilter.nf_conntrack_max

# Anzahl der Einträge
cat /proc/net/nf_conntrack | wc -l

Wenn die Tabelle nahe am Limit ist, erhöhen Sie den Parameter temporär oder analysieren, welche Clients ungewöhnlich viele Verbindungen erzeugen.

Typische Stolperfallen und Ursachen

• ICMPv6 zu restriktiv gefiltert: ND oder PMTUD wird blockiert.
• Mischbetrieb ip6tables vs nftables: Regeln überschreiben sich oder werden falsch interpretiert.
• Raw-/PREROUTING-Eingriffe: Pakete werden vor Filter-Checks gedroppt (z. B. NOTRACK).
• Conntrack-Exhaustion: neue Zustände werden nicht angelegt.
• Falscher Interface- oder Family-Kontext (ip statt ip6, filter für IPv4-only).

IPv6-Firewall-Fehlersuche: tiefere Diagnosen und erweiterte Werkzeuge

Nachdem Basischecks, Counters und Captures durchgeführt sind, helfen erweiterte Diagnosen, schwer reproduzierbare Probleme zu verstehen. Dazu zählen gezielte Analyse von ICMPv6-Typen, Fragment-Handling, Router-Advertisment-Verhalten (RA) und erweiterte Kernel-Tracing-Techniken.

12. ICMPv6-Typen und ihre Bedeutung

ICMPv6 umfasst mehrere Typen mit unterschiedlichen Rollen. Wichtige Typen sind:

• Typ 1, 2 (Destination Unreachable / Packet Too Big): zeigt Probleme mit Erreichbarkeit oder MTU.
• Typ 133–135 (Router Solicitation/Advertisement): wesentliche Bestandteile für SLAAC und Routeninformation.
• Neighbor Solicitation/Advertisement: für Link-Layer-Adressauflösung und Duplicate Address Detection.

Wenn Router Advertisements fehlen oder gefiltert werden, funktioniert SLAAC (automatische Adresskonfiguration) nicht korrekt. Prüfen Sie die ICMPv6-Filterregeln gezielt auf diese Typen.

13. Fragmentierung und PMTUD

IPv6 verbietet Fragmentierung im Router-Forwarding; nur der Endpunkt fragmentiert. Ist im Pfad ein zu kleines MTU-Segment und ICMPv6 Type 2 wird unterdrückt, werden Pakete still verworfen. Achten Sie auf MTU-Einstellungen und auf PAMTUD-Fehlermeldungen in Captures.

# Nach ICMPv6 Packet Too Big filtern
tshark -r /tmp/trace-ipv6.pcap -Y "icmpv6.type == 2" -T fields -e frame.time -e ip.src -e ip.dst -e icmpv6.code -e icmpv6.mtu

Zur Gegenprobe können Sie MTU-Tests mit hping3 oder ping6 (mit entsprechenden Paketgrößen) durchführen, um PMTUD-Verhalten zu validieren.

14. Router Advertisement (RA) und SLAAC-Fallen

Router Advertisements (RA) liefern Prefixe, Flags und Router-Lifetime. Firewalls, die RA blockieren, verhindern dynamische Adressvergabe. Prüfen Sie die RA-Rate und Validität mit tcpdump:

tcpdump -n -i eth0 'icmp6 and ip6[40] == 134'  # ICMPv6 type 134 = Router Advertisement
tcpdump -n -i eth0 'icmp6 and ip6[40] == 135'  # Neighbor Solicitation

Wenn RA-Informationen manipuliert oder entfernt werden, kann das zu inkonsistenten Prefix-Informationen und unerwartetem Routing führen.

15. Erweiterte Kernel-Tracing-Ansätze

Für hartnäckige Fälle können Sie Kernel-Tracing verwenden (z. B. perf, ftrace, bpftrace), um zu sehen, welche Hooks Pakete durchlaufen. eBPF/bpftrace erlaubt, Pfade und Hook-Ausführungen effizient zu verfolgen — das ist jedoch fortgeschrittener Skill und benötigt Kernel-Unterstützung.

Beispielhaft, ein kurzer bpftrace-Check (nur in Testumgebungen, auf Produktionskernen mit Vorsicht):

# Einfaches Beispiel: Zähle Aufrufe bestimmter Netfilter-Hooks
# Benötigt bpftrace und entsprechende Kernel-Funktion-Symbole
sudo bpftrace -e 'kprobe:netfilter_hook_entry { @[comm] = count(); }'

Warum es hilft: Sie sehen, ob Pakete überhaupt Netfilter-Hooks erreichen. Wann es scheitert: fehlende Debug-Symbole, inkompatible Kernel-Versionen oder fehlende Berechtigungen.

Umsetzungsschritte für sicheres Troubleshooting in Produktion

1. Arbeiten Sie mit zeitlich begrenzten Counters statt sofort umfassendem Logging.
2. Führen Sie Tests von beiden Seiten (Client und Server) durch und erfassen Sie Pakete beidseitig, falls möglich.
3. Dokumentieren Sie ursprüngliche Regeln vor Änderungen: exportieren Sie ip6tables- und nftables-Outputs.
4. Planen Sie ein Backout: Konfigurationsdateien sichern und Notfall-Skript bereithalten, das innerhalb von Minuten den Vorzustand wiederherstellt.

16. Beispiel: Verbesserte Konfigurationssicherung und Rollback-Skript

# Sichern
ip6tables-save > /root/ip6tables-before-$(date +%F).save
nft list ruleset > /root/nftables-before-$(date +%F).rules

# Einfaches Rollback-Skript (prüft Vorhandensein)
#!/bin/bash
BACKUP_DIR=/root
IP6BK=$(ls -1 $BACKUP_DIR/ip6tables-before-*.save | tail -n1)
NFTBK=$(ls -1 $BACKUP_DIR/nftables-before-*.rules | tail -n1)
if [ -f "$IP6BK" ]; then ip6tables-restore < "$IP6BK"; fi
if [ -f "$NFTBK" ]; then nft -f "$NFTBK"; fi

Testen Sie das Rollback in einer isolierten Umgebung, bevor Sie es produktiv nutzen.

Monitoring, Reporting und Prävention

Nachdem ein Problem behoben ist, sollten Sie präventive Maßnahmen einführen: regelmäßige Counters, Alerts für ICMPv6-Anomalien, Conntrack-Auslastung und rule-hit-Metriken. Exportieren Sie Counters periodisch (z. B. mit einem kleinen Skript und Prometheus Textfile Collector) und alarmieren Sie frühzeitig.

17. Beispiel: Zähler-Export (Prometheus textfile)

#!/bin/bash
# Simple scraper, in crontab alle 30s/1m ausführen
OUT=/var/lib/node_exporter/textfile_collector/nft_counters.prom
echo "# HELP nft_rule_hits rule hit counters" > $OUT
nft list ruleset | grep counter -A1 | awk '/counter/ {print $0} /handle/ {print $0}' | sed 's/.*counter //g' | nl -v0 | while read i line; do
  echo "nft_rule_hits{rule="$i"} $(echo $line | awk '{print $1}')" >> $OUT
done

Das Beispiel ist konzeptionell und muss für Ihre Regelstruktur angepasst werden.

Checkliste für die Nachbearbeitung

Nach erfolgreicher Diagnose sollten Sie

• Gefundene Regelprobleme in die zentrale Konfigurationsverwaltung übernehmen (z. B. Ansible, Salt).
• Sorgfältig dokumentieren, warum eine Regel angepasst wurde (Ticket-Referenz, Datum, Test-Log).
• Monitoring ergänzen: Counters regelmäßig überwachen und Alerts für Conntrack-Auslastung und ICMPv6-Fehlerraten einrichten.

Fazit

Die IPv6-Firewall-Fehlersuche ist eine Kombination aus Basisprüfung (Adressen, Routing, Sysctls), regelbasierter Inspektion (ip6tables / nftables), gezielten Tests (Counters, nping, curl) und Paketmitschnitt (tcpdump/tshark). Besondere Aufmerksamkeit verlangt ICMPv6 und conntrack-Verfügbarkeit. Planen Sie Änderungen mit Sicherungen und einer klaren Rückfallstrategie. In produktiven Umgebungen sind temporäre Counters und eingeschränkte Logging-Regeln oft der effektivste Weg, ohne den Betrieb zu gefährden. Ergänzen Sie langfristig Monitoring und automatisierte Tests, um Regressionen früh zu erkennen.

Weiterführende Empfehlungen

Für größere Umgebungen empfiehlt sich eine saubere Migration zu nftables (wenn noch nicht vorhanden), konsistente Regeln in der Familie inet zur Vereinheitlichung und automatisiertes Testing in einer Staging-Umgebung. Ergänzen Sie Monitoring um Metriken wie IPv6 ICMP-Fehler pro Sekunde, conntrack-Rate und rule-hit-Counters, um regressionssicher zu arbeiten.

Für dieses Thema sind auch Tcpdump Ip6 wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.