Kassinipedia

Troubleshooting Toolkit

Se lee en 9 min

Troubleshooting Toolkit

Contenido complementario

Ping y traceroute (incluido Device > Troubleshooting) vienen de tu laboratorio; el resto de herramientas (packet capture, contadores globales, debug dataplane packet-diag, test ...-match) está completado con conocimiento general de PAN-OS. Compáralo con lo que viste en la lección y corrígelo si difiere.

Resumen

Cuando “algo no funciona” lo más importante es tener un método, no memorizar comandos. Este es el método: primero entender dónde se rompe el camino (¿llega el paquete al firewall? ¿qué regla coincide? ¿se traduce con NAT? ¿qué ruta usa? ¿sale por la interfaz correcta? ¿vuelve la respuesta?) y después usar la herramienta que responde esa pregunta. El firewall te da herramientas para cada paso: los logs (qué pasó con la sesión), los comandos test (qué regla, qué NAT y qué ruta usaría un paquete), show session (el estado real de una sesión), los packet captures (ver los paquetes en cada etapa) y los contadores globales (por qué se descartó un paquete).
Esta nota reúne el kit de herramientas y un orden de trabajo que se repite en todos los problemas, y que las notas siguientes de troubleshooting (Troubleshooting Routing, Troubleshooting NAT, Troubleshooting IPsec y Troubleshooting Decryption) aplican a casos concretos. Conoce primero el flujo de un paquete (ver Packet Flow y Sessions), porque cada herramienta tiene sentido en una etapa de ese flujo.

Requisitos previos

  • Saber la IP de origen, la de destino, el puerto y la aplicación del tráfico que falla, y por qué zonas debería pasar
  • Acceso al firewall por GUI y CLI (SSH o consola) (ver CLI y Config Management)
  • Logging activado en las reglas relevantes (Log at Session End) (ver Logging, Monitoring y SIEM)
  • Haber leído Packet Flow y Sessions
  • Un equipo de prueba en cada lado para generar tráfico controlado
  • Permisos suficientes para capturas de paquetes y comandos debug (que consumen recursos: úsalos con filtros)

Método en 6 preguntas

graph TD
    A["¿Llega el paquete al firewall?<br/>(contadores de interfaz, captura)"] --> B["¿Existe sesión?<br/>(show session)"]
    B --> C["¿Qué ruta se usa?<br/>(test routing fib-lookup)"]
    C --> D["¿Qué NAT coincide?<br/>(test nat-policy-match)"]
    D --> E["¿Qué regla de seguridad coincide?<br/>(test security-policy-match)"]
    E --> F["¿Se descarta o se modifica?<br/>(contadores globales, logs, captura)"]
    F --> G["¿Vuelve la respuesta?<br/>(sesión: c2s y s2c, captura en el otro lado)"]
PreguntaHerramienta
¿Qué pasó con esta conexión?Monitor > Logs > Traffic / Threat / System
¿Hay una sesión activa y por dónde pasa?show session all filter ... y show session id <n>
¿Qué ruta usa para llegar a un destino?show routing route, test routing fib-lookup
¿Qué regla de NAT coincidiría?test nat-policy-match
¿Qué regla de seguridad coincidiría?test security-policy-match
¿Se descartó un paquete? ¿Por qué?show counter global filter delta yes, packet-diag
¿Cómo se ve el paquete en cada etapa?Packet Capture (Monitor > Packet Capture)
¿El firewall alcanza este destino?Ping y traceroute (CLI o Device > Troubleshooting)

Configuración y uso (Ejemplo, Lab PCNSA)

1. Ping y traceroute desde el firewall

Por CLI:

ping host 8.8.8.8
ping source 10.10.0.15 host 10.10.0.20
ping source 23.1.2.15 count 5 host 23.1.2.1
traceroute host 8.8.8.8
traceroute source 23.1.2.15 host 8.8.8.8

source <IP> hace que el ping salga con esa IP (y, por tanto, por la interfaz correspondiente); sin source el ping sale por la interfaz de gestión (MGT) con la tabla de rutas del plano de gestión (ver Initial Setup y Management Plane); para probar el plano de datos usa source <IP de la interfaz de datos>. Esto es una causa clásica de confusión: un ping desde el firewall puede fallar o funcionar por una ruta distinta a la del tráfico de usuarios.

Por GUI: Device > Troubleshooting > Ping o Traceroute: elige el Test, Virtual Router (o Interface), Source, Destination y ejecuta. Muestra el resultado en la misma ventana.

2. Ver la ruta que usaría

show routing route destination 8.8.8.8
test routing fib-lookup virtual-router default ip 8.8.8.8

3. Ver qué NAT y qué regla coincidirían

test nat-policy-match from inside to outside source 10.10.0.20 destination 8.8.8.8 destination-port 443 protocol 6
test security-policy-match from inside to outside source 10.10.0.20 destination 8.8.8.8 destination-port 443 protocol 6 application ssl

protocol 6 es TCP y 17 es UDP. Estos comandos no generan tráfico: solo simulan qué reglas aplicarían. Para NAT, recuerda que el to es la zona de destino de la ruta (la del paquete antes del NAT, ver Packet Flow y Sessions). Si un comando no coincide con tu versión, usa Tab o ?.

4. Ver sesiones

show session all filter source 10.10.0.20 destination 8.8.8.8
show session id 12345
show session info
clear session all filter source 10.10.0.20

show session id muestra: zonas, interfaces de entrada y salida, regla de seguridad y NAT aplicados, estado, aplicación, y los flujos c2s (cliente a servidor) y s2c (servidor a cliente), con la IP y el puerto tras NAT. Es la mejor foto de lo que el firewall hizo.

clear session sirve para forzar que un cambio de ruta, NAT o política se aplique, porque una sesión existente no se reevalúa por cambios de configuración (con ciertas excepciones).

5. Contadores globales (por qué se descartó un paquete)

clear counter global
(provoca el tráfico)
show counter global filter delta yes severity drop
show counter global filter delta yes category flow

delta yes muestra solo lo que cambió desde la última vez. Los contadores con severity drop te dicen el motivo del descarte (por ejemplo flow_policy_deny, flow_fwd_l3_noroute, flow_fwd_l3_noarp, flow_no_interface).

6. Packet Capture (en GUI)

  1. Monitor > Packet Capture.
  2. Configure Filtering: Manage Filters > Add: Id 1, Ingress Interface, Source, Destination, Protocol, Port. Filtering: On.
  3. Pre-Parse Match: déjalo apagado salvo para diagnosticar problemas de decryption o de firmas.
  4. Configure Capturing: Packet Capture On para las etapas que necesites. Hay cuatro etapas (stage):
    • receive: el paquete tal como llegó al firewall (antes de procesarlo)
    • firewall: tras el procesamiento (por ejemplo con NAT aplicado)
    • transmit: el paquete tal como sale del firewall
    • drop: los paquetes que el firewall descartó
  5. Genera el tráfico, pulsa Off al terminar y descarga el archivo .pcap para abrirlo en Wireshark.
  6. Al terminar, apaga Filtering y borra los filtros para no seguir capturando.

Comparar receive y transmit te permite ver si el paquete salió y con qué NAT; drop muestra qué se descartó.

7. Debug dataplane packet-diag (nivel avanzado)

debug dataplane packet-diag set filter match source 10.10.0.20 destination 8.8.8.8
debug dataplane packet-diag set filter on
debug dataplane packet-diag set log feature flow basic
debug dataplane packet-diag set log on
(provoca el tráfico)
debug dataplane packet-diag set log off
debug dataplane packet-diag set filter off
show log pktlog (verificar el nombre del log con Tab o `?`)

Cuidado con los debug

Los comandos debug consumen recursos y pueden afectar el rendimiento. Úsalos con filtros estrechos, durante poco tiempo, y apágalos siempre al terminar (set log off, set filter off).

8. Logs

  1. Monitor > Logs > Traffic: filtro por IP, por ejemplo ( addr.src in 10.10.0.20 ) and ( addr.dst in 8.8.8.8 ). Mira la regla, la acción, la aplicación y el motivo de cierre (Session End Reason).
  2. Monitor > Logs > Threat, URL Filtering, WildFire Submissions, Decryption, System, Config.
  3. Policies > Security: columna Hit Count y clic en la flecha de una regla > Log Viewer.

Session End Reason: aged-out (expiró por inactividad), tcp-fin, tcp-rst-from-client, tcp-rst-from-server, policy-deny (la regla lo negó), decrypt-error, threat, entre otros. Dice por qué terminó la sesión.

9. Estado del sistema (cuando todo va lento)

show system resources
show running resource-monitor
show system info
show system disk-space
show jobs all

Verificación

Comando o lugarQué debes verSi no lo ves
ping source <IP-interfaz> host <vecino>Respuestas del vecino directoSi falla, revisa cable, VLAN y el Interface Management Profile del lado remoto
test security-policy-match ...El nombre de la regla esperada y su acciónSi coincide otra, revisa el orden (ver Security Policy Fundamentals)
test nat-policy-match ...La regla de NAT y la traducciónSi no hay coincidencia, no hay NAT para esa combinación de zonas/IP
show session id <n>Reglas, NAT y flujos c2s/s2c coherentesSi falta el flujo s2c, la respuesta no vuelve
Captura en receiveEl paquete llegóSi no aparece, el problema está antes del firewall (cable, switch, ruta del origen)
Captura en transmitEl paquete salió con la IP esperadaSi no sale, mira drop y los contadores
show counter global filter delta yes severity dropContador con el motivo del descarteSi no hay contadores, el paquete no llegó al flujo
Monitor > Logs > TrafficUna entrada de la sesión con regla y Session End ReasonSi no hay log, la regla no tiene logging o el tráfico no llegó

Errores comunes

El ping desde el firewall funciona pero los usuarios no tienen salida

  • Causa: el ping sin source sale por otra interfaz o por la MGT; el tráfico de usuarios usa otra ruta, NAT o regla.
  • Solución: haz ping con source <IP de la interfaz de datos> y usa test security-policy-match y test nat-policy-match con las IP de los usuarios.

test security-policy-match dice Allow pero el tráfico se bloquea

  • Causa: el test no incluía la aplicación correcta, o la sesión ya existía con una regla anterior, o el bloqueo es por Threat/URL/Decryption, no por la regla.
  • Solución: incluye application, limpia la sesión (clear session) y revisa los logs de Threat y URL.

Cambié una regla o ruta y no se nota

  • Causa: la sesión existente conserva el comportamiento anterior.
  • Solución: clear session all filter source <IP> y vuelve a probar.

La captura sale vacía

  • Causa: el filtro no coincide (IP, interfaz, puerto) o el Filtering está apagado, o la captura está en la etapa equivocada.
  • Solución: simplifica el filtro (solo la IP origen) y activa las cuatro etapas.

Las capturas muestran paquetes cifrados y no puedo ver el contenido

  • Causa: el tráfico va por TLS.
  • Solución: la captura en receive o transmit ve el cifrado; para ver descifrado hay que usar la opción de captura de decryption (ver Troubleshooting Decryption).

El firewall se vuelve lento al hacer debug

  • Causa: un debug sin filtro o dejado activo.
  • Solución: apaga el filtro y el log (set log off, set filter off) y siempre filtra por IP.

No encuentro el log de la sesión

  • Causa: la regla no tiene Log at Session End, o el filtro de la GUI es demasiado estrecho, o la sesión sigue abierta (el log se escribe al terminar).
  • Solución: activa el logging, amplía el rango de tiempo y usa show session all filter ... para sesiones activas.

Vista Gráfica

Retroenlaces