La tabla de sesiones del FortiGate: leerla desde el CLI

Una conexión que debería funcionar se cuelga a medias. Otra sigue "viva" media hora después de que el usuario cerró la app. Y la duda de siempre: ¿esta conexión salió de verdad por la política que crees, o por otra? La interfaz web del FortiGate no te lo dice; la tabla de sesiones, sí. Cada conexión viva deja ahí un registro con la verdad de lo que pasa ahora mismo: por cuál regla salió, si se le aplica NAT, cuánto lleva viva. Es la otra mitad de lo que ya sabes preguntarle al firewall cuando un paquete no pasa —solo que aquí miramos el tráfico que sí pasa.

El problema es que un FortiGate en producción tiene miles de sesiones. Leerlas sin filtrar es ahogarse. Así que, igual que con el debug flow, la regla es: filtra primero, mira después.

Filtrar la tabla

El filtro de sesiones acota por dirección, puerto, protocolo y hasta por política. Para seguir una sola conversación —digamos el tráfico hacia 203.0.113.45 en el puerto 443— montas esto:

diagnose sys session filter clear
diagnose sys session filter dst 203.0.113.45
diagnose sys session filter dport 443
diagnose sys session filter proto 6
diagnose sys session list

El filtro acepta más llaves de las que crees: src/dst, sport/dport, proto (6=TCP, 17=UDP, 1=ICMP) y policy —esta última, para ver todas las sesiones que casaron con una regla concreta, oro cuando sospechas que una política está capturando tráfico que no debería.

Leer una sesión

Una entrada de la tabla asusta la primera vez. Pero solo necesitas cuatro renglones:

session info: proto=6 proto_state=01 duration=42 expire=3597 timeout=3600
state=log may_dirty
statistic(bytes/packets/err): org=842/9/0 reply=6210/8/0
hook=post dir=org act=snat 192.168.10.20:52344 ->203.0.113.45:443(198.51.100.1:52344)
hook=pre  dir=reply act=dnat 203.0.113.45:443 ->198.51.100.1:52344(192.168.10.20:52344)
policy_id=7 auth_info=0 serial=000a1b2c npu_state=0x000c00

• proto_state y expire: el estado del protocolo y cuántos segundos le quedan de vida a la sesión. Una sesión TCP que "no muere" con un expire altísimo suele ser una conexión que quedó a medio cerrar; ahí es donde se acumulan sesiones fantasma.
• act=snat / act=dnat: te dice si hay traducción y cuál. En el ejemplo, el origen 192.168.10.20 sale traducido a 198.51.100.1 (SNAT). Si esperabas NAT y ves act=noop, ahí está tu problema.
• dir=org / dir=reply: las dos mitades del flujo. Si solo ves org y nunca reply, el tráfico de vuelta no está regresando —típico del ruteo asimétrico que también delata el reverse path check fail del debug flow.
• policy_id=7: la joya. Por cuál política salió de verdad esta conexión. No la que crees que debería; la que fue. Ese número lo buscas en tu tabla de reglas.

El pulso general y cómo limpiar

Para el panorama sin listar todo, diagnose sys session stat te da el conteo y —clave— el memory_tension_drop, que si es distinto de cero significa que el equipo está tirando sesiones por presión de memoria (lo cubrimos en los 5 comandos de triage). Y si necesitas forzar el cierre de sesiones colgadas —con cuidado, porque corta conexiones en vivo— el mismo filtro que armaste aplica a diagnose sys session clear: limpia solo lo que filtraste, no toda la tabla.

Entre preguntarle al firewall por qué algo no pasa y mirar en la tabla de sesiones qué sí está pasando, tienes las dos mitades de la verdad del tráfico —y casi ningún problema sobrevive a mirar las dos.