IPv6 firewall troubleshooting: testing ip6tables/nftables and conducting a traffic trace

A functioning IPv6 network can fail at the firewall. The IPv6 firewall troubleshooting refers to the systematic analysis of why IPv6 packets do not arrive or are not processed correctly. In this article you will learn how to inspect ip6tables and nftables rules, selectively trace traffic (trace) and identify common causes using packet capture (tcpdump/tshark). The target audience is administrators, system engineers and operators who need clear check sequences, safe tests and pragmatic fallback strategies in operation.

Why IPv6 firewall troubleshooting is different

IPv6 differs from IPv4 in several decisive points. ICMPv6 is not merely a diagnostic protocol but essential for Neighbor Discovery (ND) and Path MTU Discovery (PMTUD). If ICMPv6 is blocked too RESTrictively, address resolution and fragmentation interact and connections can break seemingly without reason. In addition, NAT is not common as a standard solution in IPv6; firewalling therefore focuses more on routing, address policies and stateful inspection.

Essential terms briefly explained

• Neighbor Discovery (ND): Mechanism analogous to ARP in IPv4, for link-layer address resolution and router advertisements.
• ICMPv6: Protocol family required for error and control messages (e.g. „Packet Too Big“ for PMTUD).
• conntrack: Kernel component for connection tracking (stateful firewalling). A full conntrack table can prevent new states or cause packets to be dropped.
• ip6tables / nftables: Two management tools for Netfilter rules. nftables is more modern; many distributions provide compatibility wrappers.

Preparations: basic checks before you modify rules

Before you modify firewall rules, check addressing, routing and kernel support. These basic checks help rule out incorrect causes.

1. Check IPv6 address and routing

Inspect local addresses and routes.

ip -6 addr show dev eth0

ip -6 route show

If the address is missing or the route is not set, the firewall is not at fault. Fix address/routing errors first, then check rules.

2. Important sysctl settings and kernel modules

Check whether IPv6 forwarding and the appropriate kernel modules are enabled.

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'

If nf_tables or ip6_tables is missing, the firewall cannot process the packets. On many distributions the package management supplies the appropriate modules; if necessary, load them with modprobe.

Rule inspection: Systematically inspect ip6tables and nftables

Many problems are caused by incorrect priorities of tables/chains or by mixing both tools. It is crucial to determine whether a compatibility layer is running on the system (e.g. ip6tables-nft) or whether both tools concurrently manage different rule sets.

3. Display ip6tables rules

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

The -v option shows packet and byte counters; if values remain 0, no traffic passes through the rules. The raw table can have NOTRACK/NOTABLE effects, so check there.

4. Display nftables rules

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

nftables uses a unified rule abstraction. Pay attention to counters, log statements and the family (inet, ip, ip6). A common mistake: rules are written only for IPv4 (ip), not for inet or ip6.

5. Detecting wrapper/compatibility layers

Distributions often provide wrappers that map ip6tables commands to nftables backends. Check for this:

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

If ip6tables points to an nft backend, changes made with ip6tables are written into the nft representation — but editing in parallel with nft can create inconsistencies.

Measurable tests: counters, logging and targeted packet generation

Instead of logging blindly, run controlled tests. Useful measures are counters at critical points, targeted packet generation and subsequent captures.

6. Adding counters in nftables (quick check whether a rule matched)

Temporarily add a counter rule to see whether packets traverse a chain. Counters are robust and do not create a flood of logs.

# 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

Why it works: counters are updated in the kernel when a packet matches the rule. When it fails: if packets are dropped before the chain (e.g. in raw or mangle) or the wrong interface/family context is used.

7. Using logging appropriately

Log rules are useful but risky in production because of log floods. Instead, use log filters with rate limits or send via nflog to ulogd/tcpdump.

# 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 helps filtering in syslog/journal. Pay attention to rate limits, otherwise the system will be burdened.

Traffic captures: tcpdump, tshark and file-based recording

Packet capture is the gold standard to verify whether packets reach the system, are correctly addressed, and whether replies are sent.

8. Live capture with tcpdump

A typical capture for IPv6 issues:

# 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

Note: use -n to avoid name resolution; it slows captures.

9. Analysis with tshark or 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"

It is important to specifically filter by ICMPv6 types — Packets Too Big (ICMPv6 Type 2) indicate PMTUD issues.

Practical tests: generate traffic and observe behavior

Simulate the problematic connections from both ends. Use ping6, curl -6, nping (Nmap) or a simple socat/nc.

10. Example 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

These tests generate clearly identifiable signals that you can see in tcpdump or in counters.

Check Conntrack, timeouts and limits

An often overlooked trigger is Conntrack limits. If the table is full, the kernel drops new connections or behaves inconsistently.

11. Check Conntrack

# 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

If the table is close to the limit, increase the parameter temporarily or analyze which clients are generating an unusually high number of connections.

Typical pitfalls and causes

• ICMPv6 filtered too RESTrictively: ND or PMTUD is blocked.
• Mixed operation ip6tables vs nftables: rules overwrite each other or are misinterpreted.
• Raw/PREROUTING interventions: packets are dropped before filter checks (e.g. NOTRACK).
• Conntrack exhaustion: new states are not created.
• Wrong interface or family context (ip instead of ip6, filter for IPv4-only).

IPv6 firewall troubleshooting: deeper diagnostics and advanced tools

After basic checks, counters and captures have been performed, advanced diagnostics help to understand hard-to-reproduce issues. These include targeted analysis of ICMPv6 types, fragment handling, router advertisement behavior (RA) and advanced kernel tracing techniques.

12. ICMPv6 types and their significance

ICMPv6 comprises several types with different roles. Important types are:

• Type 1, 2 (Destination Unreachable / Packet Too Big): indicates reachability or MTU problems.
• Type 133–135 (Router Solicitation/Advertisement): essential components for SLAAC and route information.
• Neighbor Solicitation/Advertisement: for link-layer address resolution and Duplicate Address Detection.

If Router Advertisements are missing or filtered, SLAAC (stateless address autoconfiguration) will not work correctly. Check ICMPv6 filter rules specifically for these types.

13. Fragmentation and PMTUD

IPv6 prohibits fragmentation in router forwarding; only the endpoints fragment. If there is an MTU segment in the path that is too small and ICMPv6 Type 2 is suppressed, packets are silently discarded. Pay attention to MTU settings and to PAMTUD error messages 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

As a sanity check you can run MTU tests with hping3 or ping6 (with appropriate packet sizes) to validate PMTUD behavior.

14. Router Advertisement (RA) and SLAAC pitfalls

Router Advertisements (RA) provide prefixes, flags and router lifetime. Firewalls that block RAs prevent dynamic address assignment. Check the RA rate and validity with 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

If RA information is manipulated or removed, this can lead to inconsistent prefix information and unexpected routing.

15. Advanced kernel tracing approaches

For persistent cases you can use kernel tracing (e.g. perf, ftrace, bpftrace) to see which hooks packets traverse. eBPF/bpftrace allows efficient tracing of paths and hook executions — however this is an advanced skill and requires kernel support.

For example, a short bpftrace check (only in test environments; use caution on production kernels):

# Simple example: count invocations of specific Netfilter hooks
# Requires bpftrace and the corresponding kernel function symbols
sudo bpftrace -e 'kprobe:netfilter_hook_entry { @[comm] = count(); }'

Why it helps: you can see whether packets reach Netfilter hooks at all. When it fails: missing debug symbols, incompatible kernel versions, or insufficient permissions.

Implementation steps for safe troubleshooting in production

1. Work with time-limited counters rather than enabling comprehensive logging immediately.
2. Perform tests from both sides (client and server) and capture packets on both ends where possible.
3. Document the original rules before changes: export ip6tables and nftables outputs.
4. Plan a backout: back up configuration files and have an emergency script ready that can RESTore the previous state within minutes.

16. Example: improved configuration backup and rollback script

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

# Simple rollback script (checks for existence)
#!/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

Test the rollback in an isolated environment before using it in production.

Monitoring, reporting and prevention

After an issue is resolved, you should introduce preventive measures: regular counters, alerts for ICMPv6 anomalies, conntrack utilization and rule-hit metrics. Export counters periodically (e.g., with a small script and the Prometheus textfile collector) and trigger early alerts.

17. Example: counter export (Prometheus textfile)

#!/bin/bash
# Simple scraper, run in crontab every 30s/1m
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

The example is conceptual and must be adapted to your rule structure.

Checklist for follow-up

After a successful diagnosis you should

• Incorporate discovered rule issues into centralized configuration management (e.g., Ansible, Salt).
• Carefully document why a rule was changed (ticket reference, date, test log).
• Add monitoring: regularly monitor counters and set up alerts for conntrack utilization and ICMPv6 error rates.

Conclusion

IPv6 firewall troubleshooting is a combination of basic checks (addresses, routing, sysctls), rule-based inspection (ip6tables / nftables), targeted tests (counters, nping, curl) and packet capture (tcpdump/tshark). ICMPv6 and conntrack availability require particular attention. Plan changes with backups and a clear rollback strategy. In production environments, temporary counters and limited logging rules are often the most effective approach without jeopardizing operations. Complement these measures with long-term monitoring and automated tests to detect regressions early.

Further recommendations

For larger environments, a clean migration to nftables (if not already in place), consistent rules in the inet family for unification, and automated testing in a staging environment are recommended. Extend monitoring with metrics such as IPv6 ICMP errors per second, conntrack rate and rule-hit counters to ensure regression-safe operation.

Tcpdump Ip6 is also important for this topic. The article places these aspects into clear context and highlights what matters in day-to-day operation.