Usar Packet Capture de Sophos Firewall en WebAdmin
Packet Capture es una de las herramientas de troubleshooting más importantes en Sophos Firewall WebAdmin. Muestra si los paquetes llegan a una interfaz, si se reenvían, qué regla o NAT ID interviene y si un paquete se descarta.
Log Viewer muestra la decisión de la firewall. Packet Capture muestra el flujo de paquetes. Juntos suelen ser la forma más rápida de encontrar la causa.
Es importante situarlo correctamente: este artículo describe la versión WebAdmin de Packet Capture. Es ideal para una primera comprobación, porque permite ver directamente en el navegador si los paquetes llegan, se reenvían o se descartan. Para capturas más largas, filtros muy precisos, exportación PCAP o casos de soporte, tcpdump por SSH suele ser mejor.
Cuándo tiene sentido Packet Capture
Packet Capture ayuda especialmente con preguntas como:
- ¿El tráfico llega realmente a la firewall?
- ¿El tráfico sale por la interfaz esperada?
- ¿Coincide una Firewall Rule?
- ¿Coincide una NAT Rule?
- ¿Un paquete se descarta por policy, IPS o routing?
- ¿Vuelve una respuesta del sistema de destino?
- ¿Se usa otro puerto o protocolo distinto al esperado?
Si no se ve nada en Log Viewer, Packet Capture suele ser el siguiente paso. Así se ve si el problema está antes de la firewall o si la firewall procesa el tráfico.
Ruta de menú
La herramienta se encuentra en:
Diagnostics > Packet capture
Packet Capture se abre directamente en WebAdmin. Según la versión de SFOS y la vista del navegador, parece una ventana de diagnóstico propia dentro de WebAdmin.
Log Viewer o Packet Capture?
Log Viewer y Packet Capture responden a preguntas distintas.
| Herramienta | Muestra principalmente |
|---|---|
| Log Viewer | Qué Firewall Rule, Web Policy, Application Control, IPS o SSL/TLS inspection tomó la decisión |
| Packet Capture | Si los paquetes individuales llegan, se reenvían, se consumen, se generan o se descartan |
Un buen ejemplo es un ping. En Log Viewer a menudo se ve solo una entrada o una decisión resumida de la conexión. En Packet Capture se ven los paquetes ICMP individuales: Echo Request hacia el destino y Echo Reply de vuelta. Windows envía por defecto cuatro ICMP Echo Requests con ping. En Packet Capture se esperan por tanto varios paquetes de ida y vuelta. Si solo se ven los requests pero no vuelven replies, es un problema distinto a que ningún request llegue a la firewall.
En la práctica:
- Log Viewer responde: ¿Qué regla o módulo tomó la decisión?
- Packet Capture responde: ¿Los paquetes llegaron realmente y qué camino toman?
- Para problemas de routing, NAT, VLAN, gateway o ruta de retorno, Packet Capture suele ser más claro.
- Para decisiones de Web filter, Application Control, IPS o SSL/TLS inspection también se necesita Log Viewer.
Acotar antes de empezar
Packet Capture no debería iniciarse sin filtro. En redes productivas se generan muchos datos rápidamente y la salida se vuelve difícil de leer.
Antes conviene anotar:
- Source IP
- Destination IP o FQDN
- Protocolo
- Source port, si es relevante
- Destination port
- Interfaz o zona
- Hora de la prueba
- Aplicación afectada
Para una prueba web, el alcance podría ser:
| Campo | Ejemplo |
|---|---|
| Source IP | 172.16.10.25 |
| Destination | 93.184.216.34 |
| Protocol | TCP |
| Destination Port | 443 |
| Dirección esperada | LAN a WAN |
Configurar capture filter
Con Configure se establece un filtro lo más preciso posible.
Filtros típicos:
- Source IP del cliente
- Destination IP del servidor
- Destination port
- Protocolo TCP, UDP o ICMP
- Interfaz
Si no se conoce el servidor de destino, se puede empezar filtrando solo por Source IP. Si aparecen demasiados paquetes, se restringe más.
Sophos Firewall usa la sintaxis Berkeley Packet Filter, abreviada como BPF. El capture filter decide qué paquetes se escriben en el capture buffer. Por eso debería configurarse correctamente antes de la prueba.
Ejemplos BPF típicos:
| Objetivo | Ejemplo BPF |
|---|---|
| host concreto | host 10.10.10.1 |
| Source IP concreta | src host 10.10.10.1 |
| Destination IP concreta | dst host 10.10.10.1 |
| red concreta | net 10.10.10.0 |
| puerto concreto | port 443 |
| puerto de destino concreto | dst port 443 |
| host y puerto concretos | host 10.10.10.1 and port 443 |
| ICMP/ping | proto ICMP |
| TCP | proto TCP |
| UDP | proto UDP |
Para una prueba web muy concreta, un filtro puede ser:
host 172.16.10.25 and host 93.184.216.34 and port 443
Para una prueba de ping suele bastar:
host 172.16.10.25 and proto ICMP
En WebAdmin, tras guardar, el BPF string activo se muestra encima de la lista de paquetes. La primera captura muestra la configuración del filtro, la segunda la lista de resultados con el filtro activo.
⚠️ Los datos PCAP pueden contener direcciones IP, nombres de host, detalles de protocolo y, según el protocolo, también datos útiles. Las capturas solo deberían compartirse con personas o partners autorizados a ver esos datos.
Iniciar la captura y reproducir el problema
- Configurar el filtro.
- Activar Packet Capture con el interruptor.
- Reproducir el problema de forma controlada.
- Detener la captura.
- Analizar los resultados.
- Limpiar la captura antes de iniciar una nueva prueba.
Sophos Firewall muestra el estado y el buffer:
| Indicador | Significado |
|---|---|
Trace On | Packet Capture está en ejecución |
Trace Off | Packet Capture está desactivado |
Buffer size | Tamaño del capture buffer, 2048 KB en la documentación de Sophos |
Buffer used | buffer usado actualmente |
Cuando el buffer se llena, la captura se detiene automáticamente. Después hay que usar Clear antes de poder registrar una nueva captura útil. Por eso es importante un filtro estrecho.
En la configuración del filtro también se puede definir cuántos bytes por paquete se capturan. Para muchos análisis iniciales bastan los headers. Si se necesitan más datos de payload, hay que capturar más bytes, pero teniendo en cuenta privacidad y tamaño del buffer.
Entender las columnas importantes
Packet Capture muestra muchos campos. En la práctica, estos son especialmente importantes:
| Campo | Significado |
|---|---|
| Time | Momento del paquete |
| In interface | Interfaz por la que entró el paquete |
| Out interface | Interfaz por la que sale el paquete |
| Source IP | Dirección origen |
| Destination IP | Dirección destino |
| Packet type | Protocolo o tipo de paquete |
| Ports [src, dst] | Puerto origen y destino |
| NAT ID | Regla NAT correspondiente |
| Rule ID | Firewall Rule correspondiente |
| Status | Estado del paquete |
| Reason | Motivo del drop o violation |
| Connection status | Estado de la conexión |
| Gateway ID | Gateway utilizado |
| Username | Usuario detectado |
| IPS policy ID | IPS Policy aplicada |
| Application filter ID | Application Control Policy aplicada |
Estos campos son valiosos porque cierran la brecha entre “la regla parece correcta” y “el tráfico realmente fluye así”.
Con Show additional properties o la vista de detalle se ven, según la versión, más datos como Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username u otros policy IDs. Estos detalles ayudan cuando un paquete no solo lo procesa una Firewall Rule, sino también Web, Application Control, IPS u otros módulos.
Interpretar correctamente Status
| Status | Significado |
|---|---|
| Incoming | El paquete se recibió en una interfaz |
| Forwarded | El paquete se reenvió |
| Consumed | El paquete está destinado a la firewall |
| Generated | El paquete fue generado por la firewall |
| Violation | El paquete fue descartado por una infracción de policy |
Si solo se ve Incoming y no Forwarded, probablemente el paquete se queda en la firewall. Entonces hay que revisar Firewall Rule, NAT, routing y security features.
Si se ve Forwarded pero no vuelve respuesta, el problema suele estar en el sistema de destino, la ruta de retorno, NAT o un peer remoto.
Con un ping correcto se suelen ver paquetes en ambas direcciones. Si Windows envía cuatro pings, se ven varios ICMP Echo Requests del cliente al destino y varios Echo Replies de vuelta. Si faltan los Replies, hay que revisar ruta de retorno, sistema de destino, firewall local del destino, NAT o un peer remoto. Si faltan incluso los Requests, hay que revisar cliente, gateway, VLAN, puerto de switch o si el tráfico llega a Sophos Firewall.
Usar Display filter
El capture filter limita qué paquetes se registran. El Display filter, en cambio, filtra la vista ya capturada. Es útil cuando la captura se inició intencionadamente con un alcance algo más amplio y después solo se quieren ver ciertos paquetes.
En Display filter se puede filtrar, entre otros, por:
- Interface name
- Ethernet type, por ejemplo IPv4, IPv6 o ARP
- Packet type
- Source IP y Source port
- Destination IP y Destination port
- Reason
- Status
- Rule ID
- User
- Connection ID
Para troubleshooting, Status, Reason, Rule ID, Source IP, Destination IP y Destination port son especialmente útiles. Si hay muchos paquetes en la captura, ayudan a reducir rápidamente la vista a la parte relevante sin reiniciar la prueba.
Leer NAT en Packet Capture
Con NAT hay que tener en cuenta que un paquete se ve distinto antes y después de NAT. Packet Capture puede mostrar NAT ID, Rule ID y las direcciones modificadas.
Para problemas NAT, revisar:
- ¿Se ve el paquete con la dirección original?
- ¿Se ve el paquete después de la traducción?
- ¿Se muestra el NAT ID esperado?
- ¿El paquete sale por el Out interface esperado?
- ¿Vuelve una respuesta?
Para DNAT hay otro punto: la Firewall Rule usa la zona de destino después de NAT, pero la Destination IP antes de NAT. Al principio resulta poco intuitivo.
Más información: Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.
Combinar Packet Capture y Log Viewer
El mejor flujo es:
- Abrir Log Viewer.
- Iniciar Packet Capture con un filtro estrecho.
- Reproducir la prueba.
- Comprobar en Packet Capture si los paquetes llegan y salen.
- Comprobar en Log Viewer qué regla o módulo tomó la decisión.
- Si hace falta, cambiar al archivo de log correspondiente.
Log Viewer muestra por ejemplo eventos Firewall, Web, SSL/TLS inspection, IPS o Application Control. Packet Capture muestra el flujo de paquetes a nivel de interfaz.
Esta combinación es importante especialmente con ping o conexiones TCP simples. Log Viewer solo puede mostrar que una conexión fue permitida o bloqueada. Packet Capture muestra además si los paquetes de respuesta vuelven, si NAT se aplica, si se usa el Out interface correcto y si la ruta de retorno funciona.
Ejemplos habituales
El cliente no llega a Internet: configurar una captura sobre Source IP y TCP 443. Si no llega ningún paquete, revisar cliente, VLAN, gateway o switch. Si el paquete llega pero no sale, revisar Firewall Rule, NAT o routing.
DNAT no funciona: configurar una captura sobre la IP pública de destino y el puerto externo. Si no llega ningún paquete, revisar router del proveedor, port forwarding, cloud Security Group o WAN. Si el paquete llega pero no va al servidor interno, revisar la regla DNAT y la Firewall Rule.
El tráfico VPN no funciona: configurar una captura sobre la interfaz de túnel, XFRM interface o las redes origen/destino relevantes. Revisar además strongswan.log, charon.log o xfrmi.log.
Web filter bloquea inesperadamente: en Packet Capture normalmente solo se ve el flujo de paquetes. La decisión real se revisa mejor en Log Viewer bajo Web, Application Control o SSL/TLS inspection.
Cuándo tcpdump es mejor
WebAdmin Packet Capture es ideal para análisis rápidos. Para capturas más largas, filtros muy precisos o casos de soporte, tcpdump por CLI suele ser mejor.
Más información: Recopilar logs de Sophos Firewall con TCPDump para análisis.