La política se ve bien. El ruteo, correcto. Y el tráfico sigue sin funcionar. Antes de seguir peleando con la configuración, hazte la pregunta que casi nadie hace a tiempo: ¿el paquete siquiera está llegando a la interfaz? Porque el debug flow te dice qué decide el FortiGate con un paquete —pero no si ese paquete existe. A veces el tráfico nunca toca el firewall, o llega deformado, y para verlo necesitas los bytes crudos en el cable.
La buena noticia: no hace falta instalar nada ni poner un switch en modo espejo. El FortiGate trae un capturador de paquetes integrado —básicamente un tcpdump escondido en el CLI— y, mejor aún, puedes exportar lo capturado a Wireshark para analizarlo con calma.
La anatomía del comando
Todo vive en un solo comando con cinco parámetros. Se ve intimidante, pero cada uno tiene un propósito claro:
diagnose sniffer packet port2 'host 203.0.113.45 and port 443' 4 10 lport2: la interfaz a escuchar. Usaanypara escuchar todas —útil para ver por dónde entra algo, caro en CPU si hay mucho tráfico.'host ... and port ...': el filtro, en la misma sintaxis detcpdump/BPF. Aquí es donde acotas para no ahogarte:host,port,proto,and/or. Un filtro vacío ('') captura todo —casi nunca lo que quieres en producción.4(verbosidad): cuánto detalle. 1 = solo encabezados; 3 = encabezados + datos + nombre de interfaz; 4 y 5 agregan más contexto. El 4 es el punto dulce para troubleshooting normal; el 3 es el que se exporta a Wireshark.10(conteo): cuántos paquetes capturar antes de parar solo. Tu red de seguridad —nunca dejes una captura sin filtro corriendo indefinidamente.0captura hasta que le das Ctrl+C.l(timestamp):l= hora local,a= absoluta. Un detalle que agradeces al correlacionar con logs.
interfaces=[port2]
filters=[host 203.0.113.45 and port 443]
10.412 192.168.10.20.52344 -> 203.0.113.45.443: syn 1846135720
10.448 203.0.113.45.443 -> 192.168.10.20.52344: syn 91827364 ack 1846135721
10.449 192.168.10.20.52344 -> 203.0.113.45.443: ack 91827365
...
10 packets received by filterEn ese ejemplo el handshake TCP completa (SYN, SYN-ACK, ACK): el tráfico llega y regresa. Si solo ves los SYN saliendo y nunca la respuesta, el paquete no está volviendo —y ya sabes que el problema está más allá del firewall, no en él.
Llevarlo a Wireshark
Para casos peludos, la consola se queda corta y quieres el análisis visual. Capturas con verbosidad 3, copias la salida completa de la consola a un archivo de texto, y la conviertes a formato .pcap con el script fgt2eth.pl que Fortinet publica. El resultado se abre en Wireshark como cualquier captura. Es el puente entre "lo vi pasar en el CLI" y "lo analicé paquete por paquete".
Sniffer o debug flow: cuál, cuándo
No compiten, se complementan. Úsalos así:
- El paquete llega pero no pasa →
debug flow: la decisión (política, ruteo, NAT) es lo que falla. - No sabes si el paquete siquiera llega →
sniffer packet: confirmas presencia y forma del tráfico en la interfaz.
El reflejo de un buen troubleshooting es empezar por el sniffer cuando dudas de la existencia del tráfico, y pasar al debug flow cuando confirmaste que llega pero algo lo detiene.
Preguntas frecuentes
help ¿Qué hace diagnose sniffer packet en un FortiGate?
Es el capturador de paquetes integrado del FortiGate: escucha una interfaz y muestra el tráfico real que pasa por ella, con la misma sintaxis de filtros de tcpdump. Sirve para confirmar si un paquete realmente llega al firewall y cómo, algo que el debug flow —que solo muestra la decisión del firewall— no responde.
help ¿Puedo exportar una captura del FortiGate a Wireshark?
Sí. Captura con verbosidad 3, guarda la salida de la consola en un archivo de texto y conviértela a formato .pcap con el script fgt2eth.pl de Fortinet. El archivo resultante se abre en Wireshark como cualquier otra captura, para análisis visual paquete por paquete.
help ¿Es seguro correr el sniffer en producción?
Sí, si filtras y limitas el conteo. El riesgo no es el comando, sino escuchar la interfaz any con filtro vacío en un equipo con mucho tráfico: satura la consola y suma carga de CPU. Filtra por host y puerto, captura un número acotado de paquetes y evita capturas indefinidas en horas pico.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →