Packet Flow y Sessions

Resumen

Cuando un paquete llega a un firewall Palo Alto, no se evalúa todo a la vez: pasa por una cadena de decisiones en un orden fijo. Primero se busca si ya existe una session para ese flujo; si existe, el paquete sigue un camino rápido (fast path). Si no existe, es el primer paquete de una conexión nueva y recorre el camino lento (slow path): se determina la interfaz de salida con una consulta de rutas, se busca una regla de NAT, se busca una regla de Security Policy y, si la permite, se crea la session; App-ID y Content-ID inspeccionan los paquetes siguientes (el fast path también los pasa por App-ID y Content-ID). Antes de todo esto actúan Zone Protection y DoS Protection.
Entender este orden es la base para diagnosticar: si no hay ruta no hay session ni logs; si hay ruta pero no regla, el tráfico se niega; si hay regla pero no NAT, la respuesta no vuelve. Esta nota explica ese orden, cómo se leen las sessions y cómo se correlacionan con los logs.

Requisitos previos

• Conocer zonas, interfaces y Virtual Routers (ver L3 Interfaces, Subinterfaces y DHCP)
• Reglas de Security Policy y de NAT creadas (ver Security Policy Fundamentals, Source NAT, Destination NAT)
• Acceso al CLI para usar show session y test
• Logs de tráfico activados en las reglas

Orden de operaciones

graph TD
    A["Paquete entra por una interfaz<br/>(zona de origen)"] --> Z["Zone Protection y DoS Protection"]
    Z --> B{"¿Existe una session<br/>para este flujo?"}
    B -- Sí --> F["Fast path:<br/>se reenvía según la session"]
    B -- No --> C["Slow path:<br/>consulta de rutas (interfaz y zona de salida;<br/>PBF si hay una regla que coincide)"]
    C --> D["Búsqueda de regla de NAT<br/>(zonas y IP originales)"]
    D --> E["Búsqueda de regla de Security Policy<br/>(zona destino post-NAT, IP original)"]
    E --> G{"¿La regla permite?"}
    G -- No --> H["Se descarta o se niega,<br/>se registra según la regla"]
    G -- Sí --> J["Se crea la session<br/>y se aplica la traducción de NAT"]
    J --> I["App-ID y Content-ID<br/>(perfiles, decryption) sobre los paquetes siguientes"]
    I --> F

Detalles importantes de cada paso:

Paso	Qué ocurre	Qué usa
Ingreso	El paquete llega a una interfaz; determina la zona de origen	Interfaz y zona
Zone Protection y DoS	Se evalúan antes del session lookup (ver Zones, Zone Protection y DoS Protection)	Perfiles de la zona y reglas DoS
Session lookup	Busca una entrada en la session table	5-tupla (IP origen y destino, puertos, protocolo)
Route lookup	Decide la interfaz y zona de salida; una regla de PBF que coincida tiene prioridad sobre la tabla de rutas	Mejor ruta: longest prefix match, luego Admin Distance, luego metric
NAT policy lookup	Busca regla de NAT con zonas y direcciones originales (antes de traducir)	Zona origen, zona destino (por la ruta), IPs, servicio
Security policy lookup	Busca regla con la zona destino real (post-NAT) y la IP destino original (pre-NAT)	Zonas, IPs, usuario, aplicación, servicio
App-ID y Content-ID	Identifica la aplicación y aplica perfiles de seguridad y decryption	Perfiles asignados a la regla
NAT aplicado	El paquete se reescribe y sale	Regla de NAT que coincidió

Si no hay ruta, no hay logs

Si el firewall no tiene una ruta hacia el destino, el paquete se descarta antes de llegar a la Security Policy. No habrá session ni logs de tráfico. Cuando algo “no deja rastro”, empieza revisando rutas.

Fast path y slow path. El slow path ocurre solo con el primer paquete de una sesión: hace todas las búsquedas y crea la entrada en la session table. El fast path son los paquetes siguientes, que solo consultan esa tabla (el “caché” de la sesión) y se reenvían sin repetir las búsquedas. Los cambios de NAT no se reevalúan en sessions ya establecidas; los de Security Policy sí, mientras Rematch Sessions esté activo (es el valor por defecto; ver más abajo).

Conceptos de la session

Campo	Qué muestra
Session ID	Número que une el log de tráfico con show session id
c2s / s2c	Los dos sentidos del flujo (cliente a servidor, servidor a cliente)
State	INIT, ACTIVE, DISCARD, FIN, CLOSE…
Rule	Regla de Security Policy que aplicó
NAT	Si hay traducción, las direcciones original y traducida
Application	La App-ID identificada (puede cambiar durante la session)
Timeout	Tiempo hasta que expire por inactividad

Timeouts por defecto más importantes:

Protocolo	Timeout
TCP (sin actividad)	3600 segundos
TCP handshake	10 segundos
TCP half-closed	120 segundos
TCP time-wait	15 segundos
UDP	30 segundos
ICMP	6 segundos

Aplicar una regla nueva a sessions existentes. Con Rematch all sessions on config policy change activo (Device > Setup > Session > Session Settings; es el valor por defecto) los cambios de Security Policy se aplican a las sessions en curso. Si está desactivado, o el cambio fue de NAT, las sessions conservan la decisión original. Para forzar la reevaluación:

clear session all filter source 10.10.0.105

Cómo leer los logs en relación con la session

• El log de tráfico incluye el Session ID; úsalo para buscar la session: show session id <número>.
• Con Log at Session End, el log aparece cuando la session termina, con el motivo (Session End Reason: aged-out, tcp-fin, tcp-rst-from-client, policy-deny, threat…).
• Con Log at Session Start aparece desde el inicio (útil para sessions largas o para diagnosticar).
• Tráfico negado por una regla genera log si la regla tiene logging. El negado por interzone-default solo si activaste el logging en esa regla.

Configuración

Este tema es de diagnóstico: no tiene una configuración propia, pero estos comandos son la base de todo el troubleshooting (ver Troubleshooting Toolkit).

Consultas de session

show session info
show session all
show session all filter source 10.10.0.105
show session all filter destination 8.8.8.8
show session all filter application ssl
show session id 12345
clear session id 12345
clear session all filter source 10.10.0.105

Probar qué haría el firewall sin generar tráfico

test routing fib-lookup virtual-router default ip 8.8.8.8
test nat-policy-match from inside to outside source 10.10.0.105 destination 8.8.8.8 protocol 6 destination-port 443
test security-policy-match from inside to outside source 10.10.0.105 destination 8.8.8.8 protocol 6 destination-port 443 application ssl

Hit count de reglas

show rule-hit-count vsys vsys-name vsys1 rule-base security rules all
show running rule-use rule-base security type unused vsys vsys1

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
test routing fib-lookup virtual-router default ip 8.8.8.8	Interfaz de salida y next hop	Si no hay ruta, el problema está en el ruteo (ver Static Routing y Path Monitoring)
test nat-policy-match ...	La regla de NAT esperada y la traducción	Si no coincide, revisa zonas, interfaz de salida y orden
test security-policy-match ...	La regla esperada y su acción	Si coincide otra, revisa el orden
show session all filter source <ip>	Una session con la regla, el estado ACTIVE y las IPs	Si no hay, el paquete no llegó o fue descartado antes
show session id <n>	Detalle de c2s y s2c, NAT, regla, aplicación, timeout	Compara el flujo de ida y el de vuelta
show session info	Total de sessions activas y la capacidad máxima	Un número cercano al máximo indica saturación
Monitor > Logs > Traffic	Log con el Session ID y el motivo de cierre	Si no hay log, mira el logging de la regla
show counter global filter delta yes severity drop	Contadores de descartes con su motivo	El nombre del contador indica la causa (por ejemplo flow_fwd_l3_noroute)

Errores comunes

No hay session ni logs

• Causa: no hay ruta hacia el destino, la interfaz de entrada está caída, o el paquete nunca llegó.
• Revisa: test routing fib-lookup, show interface all, show counter global filter delta yes severity drop.
• Solución: corrige la ruta o la conectividad. Si el contador indica noroute, falta una ruta.

La session existe pero el tráfico no regresa

• Causa: falta NAT, el NAT está mal, o hay ruteo asimétrico (la respuesta vuelve por otra interfaz o firewall).
• Revisa: show session id <n>: el sentido s2c debe tener los datos esperados; compara con la regla de NAT.
• Solución: corrige la regla de NAT o asegura que el camino de regreso pase por el mismo firewall.

Se niega tráfico pero no hay logs

• Causa: la regla por defecto interzone-default no registra.
• Solución: activa Log at Session End en interzone-default con Override.

Cambié la política y el tráfico sigue pasando

• Causa y solución: ver “Aplicar una regla nueva a sessions existentes” (Rematch Sessions y clear session).

Tráfico UDP o ICMP desaparece rápido

• Causa: timeouts cortos por defecto (UDP 30 s, ICMP 6 s).
• Solución: si la aplicación necesita más tiempo, ajusta el timeout global en Device > Setup > Session > Session Timeouts, define una Custom Application con timeout propio, o genera tráfico periódico.

El número de sessions llega al máximo del modelo

• Causa: demasiadas conexiones (ataque, escaneo, aplicación mal diseñada) o timeouts muy largos.
• Revisa: show session info y show session all ordenado por origen.
• Solución: identifica el origen, aplica protección contra DoS (ver Zones, Zone Protection y DoS Protection) y ajusta timeouts.

La aplicación en el log cambia entre ssl y web-browsing u otra

• Causa: App-ID refina su identificación a medida que ve más datos de la session. La regla debe permitir la aplicación final y sus dependencias.
• Solución: permite las aplicaciones relacionadas, o usa el log para ver la aplicación final (ver App-ID y Policy Optimization).