Solución de problemas del firewall IPv6: probar ip6tables/nftables y realizar una traza de tráfico

Una red IPv6 que funciona puede fallar en la firewall. La resolución de problemas de la firewall IPv6 se refiere al análisis sistemático de por qué los paquetes IPv6 no llegan o no se procesan correctamente. En este artículo aprenderá a comprobar reglas de ip6tables y nftables, rastrear tráfico de forma dirigida (trace) y, mediante captura de paquetes (tcpdump/tshark), identificar causas típicas. El público objetivo son administradores, ingenieros de sistemas y operadores que, en producción, necesitan secuencias de comprobación claras, pruebas seguras y estrategias de retroceso pragmáticas.

Por qué la depuración de la firewall IPv6 es diferente

IPv6 difiere en varios puntos decisivos respecto a IPv4. ICMPv6 no es un mero protocolo de diagnóstico, sino imprescindible para Neighbor Discovery (ND) y Path MTU Discovery (PMTUD). Si ICMPv6 se bloquea de forma demasiado RESTrictiva, la resolución de direcciones y la fragmentación quedan afectadas y las conexiones se rompen aparentemente sin motivo. Además, en IPv6 no existe NAT como solución estándar; por ello el filtrado se orienta más al enrutamiento, a políticas de direcciones y a la inspección stateful.

Conceptos esenciales brevemente explicados

• Neighbor Discovery (ND): mecanismo análogo a ARP en IPv4, para la resolución de direcciones a nivel de enlace y los Router Advertisements.
• ICMPv6: familia de protocolos, necesaria para mensajes de control y de error (p. ej., „Packet Too Big“ para PMTUD).
• conntrack: componente del kernel para el seguimiento de conexiones (firewall con estado). Una tabla conntrack llena puede impedir nuevos estados o provocar el descarte de paquetes.
• ip6tables / nftables: dos herramientas de gestión para reglas de Netfilter. nftables es más moderno; muchas distribuciones ofrecen wrappers de compatibilidad.

Preparativos: comprobaciones básicas antes de modificar reglas

Antes de intervenir en las reglas de la firewall, compruebe direcciones, enrutamiento y soporte del kernel. Estas comprobaciones básicas ayudan a descartar causas erróneas.

1. Comprobar la dirección IPv6 y el enrutamiento

Verifique direcciones locales y rutas.

ip -6 addr show dev eth0

ip -6 route show

Si falta la dirección o no existe la ruta, eso no es culpa de la firewall. Primero corrija errores de dirección/enrutamiento y luego compruebe las reglas.

2. Sysctl y módulos del kernel importantes

Compruebe si el reenvío IPv6 y los módulos del kernel adecuados están activados.

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'

Si faltan nf_tables o ip6_tables, la firewall no podrá procesar los paquetes. En muchas distribuciones el gestor de paquetes proporciona los módulos adecuados; si es necesario, cárguelos con modprobe.

Inspección de reglas: comprobar ip6tables y nftables de forma sistemática

Muchos problemas se generan por una prioridad incorrecta de tablas/chains o por mezclar ambas herramientas. Es fundamental saber si en el sistema existe una capa de compatibilidad (p. ej. ip6tables-nft) o si ambos tools gestionan conjuntos de reglas diferentes en paralelo.

3. Mostrar reglas de ip6tables

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

La opción -v muestra contadores de paquetes y bytes; si los valores permanecen en 0, no pasa tráfico por las reglas. La tabla raw puede tener efectos NOTRACK/NOTABLE, por lo que conviene comprobarla.

4. nftables-Regeln anzeigen

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

nftables utiliza una abstracción unificada de reglas. Preste atención a los contadores, las sentencias de registro y a la familia (inet, ip, ip6). Un error frecuente: las reglas se han escrito solo para IPv4 (ip), no para inet o ip6.

5. Detección de capas wrapper/compatibilidad

Las distribuciones suelen ofrecer wrappers que mapean comandos ip6tables a backends nftables. Compruébelo:

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

Si ip6tables apunta a un backend nft, entonces los cambios realizados con ip6tables se escriben en la representación nft — pero editar en paralelo con nft puede generar inconsistencias.

Pruebas medibles: contadores, registro y generación dirigida de paquetes

En lugar de registrar a ciegas, debe realizar pruebas controladas. Son útiles los contadores en puntos críticos, la generación dirigida de paquetes y las capturas posteriores.

6. Añadir contadores en nftables (comprobar rápidamente si una regla coincide)

Añada temporalmente una regla con contador para ver si los paquetes atraviesan una cadena. Los contadores son robustos y no generan una avalancha de registros.

# 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

Por qué funciona: los contadores se actualizan en el kernel cuando un paquete atraviesa la regla. Cuándo falla: cuando los paquetes se descartan antes de la cadena (p. ej. en raw o mangle) o se usa el contexto de interfaz/familia incorrecto.

7. Empleo adecuado del registro

Las reglas de registro son útiles, pero en producción suponen un riesgo por la avalancha de logs. En su lugar, use filtros de registro con limitación de tasa o diríjalos mediante nflog a 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: "

El prefijo de registro ayuda a filtrar en syslog/journal. Tenga en cuenta los límites de tasa; si no, el sistema se verá sometido a carga.

Capturas de tráfico: tcpdump, tshark y grabación en archivo

La captura de paquetes es el estándar de referencia para ver si los paquetes llegan al sistema, están correctamente direccionados y si se envían respuestas.

8. Captura en vivo con tcpdump

Una captura típica para errores IPv6:

# 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

Nota: Use -n para evitar la resolución de nombres; la resolución de nombres ralentiza las capturas.

9. Análisis con tshark o 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"

Es importante filtrar específicamente por tipos ICMPv6: „Packet Too Big“ (ICMPv6 Type 2) indica problemas de PMTUD.

Pruebas prácticas: generar tráfico y observar el comportamiento

Simule las conexiones problemáticas desde ambos extremos. Utilice ping6, curl -6, nping (Nmap) o un simple socat/nc.

10. Pruebas de ejemplo

# 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

Estas pruebas generan señales claramente identificables que puede ver en tcpdump o en los contadores.

Comprobar Conntrack, timeouts y límites

Un desencadenante frecuentemente pasado por alto son los límites de Conntrack. Si la tabla está llena, el kernel descarta nuevas conexiones o se comporta de forma inconsistente.

11. Comprobar 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

Si la tabla está cerca del límite, aumente el parámetro temporalmente o analice qué clientes generan un número inusualmente alto de conexiones.

Errores típicos y causas

• ICMPv6 filtrado demasiado RESTrictivamente: se bloquean ND o PMTUD.
• Operación mixta ip6tables vs nftables: las reglas se sobrescriben o se interpretan incorrectamente.
• Intervenciones Raw/PREROUTING: los paquetes se descartan antes de las verificaciones de filtrado (p. ej. NOTRACK).
• Agotamiento de Conntrack: no se crean nuevos estados.
• Contexto de interfaz o de familia incorrecto (ip en lugar de ip6, filter para IPv4-only).

Depuración de la firewall IPv6: diagnósticos más profundos y herramientas avanzadas

Después de realizar las comprobaciones básicas, contadores y capturas, los diagnósticos avanzados ayudan a entender problemas difíciles de reproducir. Esto incluye análisis específicos de tipos ICMPv6, manejo de fragmentos, comportamiento de Router Advertisement (RA) y técnicas avanzadas de tracing del kernel.

12. Tipos ICMPv6 y su significado

ICMPv6 incluye varios tipos con roles diferentes. Los tipos importantes son:

• Tipo 1, 2 (Destination Unreachable / Packet Too Big): indican problemas de alcanzabilidad o de MTU.
• Tipo 133–135 (Router Solicitation/Advertisement): componentes esenciales para SLAAC e información de rutas.
• Neighbor Solicitation/Advertisement: para resolución de direcciones de capa de enlace y detección de direcciones duplicadas.

Si faltan o se filtran Router Advertisements, SLAAC (configuración automática de direcciones) no funciona correctamente. Revise las reglas de filtrado ICMPv6 enfocándose en estos tipos.

13. Fragmentación y PMTUD

IPv6 prohíbe la fragmentación en el reenvío por routers; solo el extremo puede fragmentar. Si hay un segmento con MTU demasiado pequeño en la ruta y se suprime ICMPv6 Type 2, los paquetes se descartarán silenciosamente. PRESTe atención a las configuraciones de MTU y a los mensajes de error PAMTUD en las capturas.

# 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

Como comprobación, puede realizar pruebas de MTU con hping3 o ping6 (con tamaños de paquete adecuados) para validar el comportamiento de PMTUD.

14. Router Advertisement (RA) y trampas de SLAAC

Router Advertisements (RA) proporcionan prefijos, flags y el tiempo de vida del router. Las firewalls que bloquean RA impiden la asignación dinámica de direcciones. Compruebe la tasa y la validez de RA con 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

Si la información RA se manipula o se elimina, puede provocar información de prefijos inconsistente y enrutamiento inesperado.

15. Enfoques avanzados de trazado del kernel

Para casos persistentes puede usar trazado del kernel (p. ej. perf, ftrace, bpftrace) para ver qué hooks atraviesan los paquetes. eBPF/bpftrace permite seguir de forma eficiente rutas y ejecuciones de hooks — sin embargo, es una habilidad avanzada y requiere soporte del kernel.

A modo de ejemplo, una breve comprobación con bpftrace (solo en entornos de prueba; en kernels de producción, con precaución):

# 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(); }'

Por qué es útil: podrá ver si los paquetes alcanzan los hooks de Netfilter. Cuándo puede fallar: símbolos de depuración ausentes, versiones del kernel incompatibles o permisos insuficientes.

Pasos de implementación para una resolución de problemas segura en producción

1. Use contadores con límite temporal en lugar de un registro exhaustivo inmediato.
2. Realice pruebas desde ambos extremos (cliente y servidor) y capture paquetes en ambos lados, si es posible.
3. Documente las reglas originales antes de los cambios: exporte los outputs de ip6tables y nftables.
4. Planifique una reversión: haga copias de seguridad de los archivos de configuración y tenga preparado un script de emergencia que RESTablezca el estado anterior en minutos.

16. Ejemplo: copia de seguridad de configuración mejorada y script de rollback

# 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

Pruebe el rollback en un entorno aislado antes de usarlo en producción.

Monitorización, informes y prevención

Una vez resuelto un problema, debe implementar medidas preventivas: contadores periódicos, alertas por anomalías de ICMPv6, saturación de Conntrack y métricas de rule-hit. Exporte contadores periódicamente (p. ej. con un script pequeño y el Prometheus Textfile Collector) y configure alertas tempranas.

17. Ejemplo: exportación de contadores (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

El ejemplo es conceptual y debe ajustarse a la estructura de sus reglas.

Lista de verificación para el seguimiento posterior

Tras un diagnóstico exitoso, debería:

• Incorporar los problemas de reglas detectados en la gestión central de configuración (p. ej. Ansible, Salt).
• Documentar cuidadosamente por qué se ajustó una regla (referencia del ticket, fecha, registro de pruebas).
• Agregar monitorización: supervisar los contadores regularmente y configurar alertas para la saturación de conntrack y las tasas de error ICMPv6.

Conclusión

La resolución de problemas del firewall IPv6 combina comprobaciones básicas (direcciones, enrutamiento, sysctls), inspección basada en reglas (ip6tables / nftables), pruebas específicas (contadores, nping, curl) y captura de paquetes (tcpdump/tshark). ICMPv6 y la disponibilidad de conntrack requieren atención particular. Planifique los cambios con copias de seguridad y una estrategia de retroceso clara. En entornos de producción, los contadores temporales y las reglas de registro restringidas suelen ser la vía más eficaz sin poner en riesgo la operación. A largo plazo, complemente con monitorización y pruebas automatizadas para detectar regresiones de forma temprana.

Recomendaciones adicionales

Para entornos de mayor tamaño se recomienda una migración ordenada a nftables (si aún no está desplegado), reglas consistentes en la familia inet para unificar y pruebas automatizadas en un entorno de staging. Añada al monitoreo métricas como errores ICMP IPv6 por segundo, tasa de conntrack y contadores de aciertos de regla, para trabajar con seguridad frente a regresiones.

Para este tema, Tcpdump Ip6 también es importante. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.