Analizar paquetes descartados en Sophos Firewall

Cuando Sophos Firewall descarta paquetes, no es automáticamente un error. A menudo es la decisión de seguridad deseada: una regla no coincide, una política bloquea, un paquete no pertenece a una conexión conocida o un módulo como Webfilter, IPS o Application Control interviene.

Se vuelve complicado cuando un servicio no funciona y no está claro si el firewall bloquea, si el tráfico no llega o si el tráfico de retorno toma otro camino. Entonces se necesita un orden claro: primero Log Viewer, luego Packet Capture, y después, si es necesario, registros de servicio o CLI.

Para el emparejamiento general de reglas, consulte Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture. Este artículo se centra en los descartes y paquetes descartados.

¿Qué artículo de solución de problemas es adecuado?

No todos los problemas de conexión son problemas de descarte. Dependiendo de la observación, otro punto de partida puede ser más rápido:

• En Log Viewer o Packet Capture se ve un descarte, Invalid traffic, Violation o Firewall ID 0: Este artículo.
• Una regla de firewall esperada no se activa: Comprobar causas de reglas de Sophos Firewall que no coinciden.
• Se debe validar una regla después de un cambio: Probar reglas de Sophos Firewall con Log Viewer y Packet Capture.
• Se deben verificar paquetes en WebAdmin con un filtro estrecho: Usar Packet Capture en WebAdmin de Sophos Firewall.
• WebAdmin muestra poco y se necesitan archivos de registro: Solución de problemas de Sophos Firewall: Servicios y registros.
• Los registros deben conservarse más tiempo o correlacionarse centralmente: Enviar Syslog de Sophos Firewall a SIEM.
• WebAdmin, SSH, DNS, VPN Portal o SNMP hacia el propio firewall están afectados: Asegurar el acceso a Sophos Firewall: Configurar correctamente Device Access.
• El túnel IPsec está activo, pero el tráfico no fluye correctamente: Solución de problemas de IPsec VPN en Sophos Firewall.
• Grandes transferencias se cuelgan o aplicaciones individuales fallan: Comprobar MTU y MSS en problemas de VPN en Sophos Firewall.

Esta selección ahorra tiempo, ya que no se trata cada problema como un error de regla de firewall. Primero debe quedar claro si el firewall ve el tráfico, qué regla o módulo decide y si el camino de retorno realmente sigue la misma ruta.

Un descarte no es igual a otro descarte

Para el análisis, primero se debe distinguir qué tipo de descarte está presente. De lo contrario, se busca rápidamente en el lugar equivocado.

• Descarte intencionado: El firewall bloquea según la regla, política web, IPS o Threat Feed. Verificar si la política es correcta desde el punto de vista técnico.
• Descarte inesperado: Tráfico legítimo es descartado por una regla o módulo. Verificar Rule ID, NAT ID, módulo y razón en Log Viewer o Packet Capture.
• No es un descarte de firewall: El tráfico no llega al firewall o la respuesta toma otro camino. Verificar cliente, VLAN, switch, gateway, ruta, SD-WAN o camino de retorno.

Esta clasificación evita excepciones innecesarias. Si el descarte es intencionado, no se necesita una reparación técnica, sino una decisión de política. Si el tráfico no llega al firewall, ninguna nueva regla de firewall ayudará. Si un módulo de seguridad bloquea, no se debe crear ciegamente una regla de firewall amplia.

Primera clasificación

Antes del análisis, se debe delimitar el error lo más concretamente posible.

Preguntas importantes:

• ¿Qué IP de origen y destino están afectadas?
• ¿Qué puerto y protocolo se utilizan?
• ¿Se trata de cliente a Internet, VPN de sitio a sitio, acceso remoto, DNAT, WAF o tráfico interno?
• ¿El error es permanente o esporádico?
• ¿Afecta solo a una aplicación, a un usuario o a toda una red?
• ¿Se cambió recientemente una regla de firewall, regla NAT, ruta, regla SD-WAN, inspección TLS o política web?

Sin esta información, a menudo se busca demasiado ampliamente en Log Viewer. Es mejor una prueba reproducible con hora, direcciones IP y dirección esperada.

Uso correcto de Log Viewer

El Log viewer es el primer punto de partida. Muestra registros de eventos y se puede filtrar por módulo, tiempo, campo y texto libre.

Log Viewer se abre en la parte superior derecha de la interfaz WebAdmin. Para los descartes, según el caso, estos módulos son importantes:

• Firewall: Coincidencia de reglas, conexiones permitidas y descartadas.
• Web: Política web, categoría, grupo de URL, escaneo de malware.
• SSL/TLS inspection: Desencriptación, errores TLS, excepciones.
• Application filter: Coincidencias de Application Control.
• IPS: Prevención de intrusiones y decisiones DPI.
• Active threat response: Threat Feeds, NDR Essentials u otras coincidencias ATR.
• Web server protection: WAF, proxy inverso y servicios web publicados.
• VPN: Eventos de IPsec, SSL VPN y acceso remoto.

Las reglas de firewall generalmente registran sesiones cuando el firewall recibe un evento Destroy y cierra la conexión. Si una conexión termina sin este evento, no siempre aparece como se espera. En conexiones SSL/TLS, la conexión se registra después del handshake y al cerrarse.

También es importante la configuración de registros. Si un tipo de registro no está activado en System services > Log settings, no se verá de manera confiable localmente, en Sophos Central o en el Syslog. Para un análisis a largo plazo, es adecuado Enviar Syslog de Sophos Firewall a SIEM o Activar Central Firewall Reporting.

Clasificar eventos Invalid Traffic

Invalid traffic es un hallazgo importante, pero no un análisis de causa terminado. La firewall lo usa para tráfico que no encaja limpiamente con una conexión válida o una decisión de policy. Son típicos los paquetes fuera del estado de sesión esperado, rutas asimétricas, sesiones caducadas, flags TCP inesperados o tráfico de retorno que no pasa por el mismo camino.

En estos eventos no conviene construir primero una regla Allow. Es mejor seguir este proceso:

1. Tomar Source, Destination, port y hora del evento.
2. Comprobar en Log Viewer si se ve una Firewall Rule ID, NAT Rule ID o un módulo.
3. Probar con Packet Capture si ambos sentidos pasan por la misma firewall.
4. Comprobar routing, SD-WAN, rutas VPN, rol HA y ruta de retorno.
5. Solo después decidir si debe adaptarse una regla, lógica NAT, ruta o Security Profile.

Invalid traffic es especialmente valioso como indicio de problemas de estado o retorno. Si solo se amplía la regla Allow, la causa real suele permanecer.

Uso correcto de Packet Capture

La ruta del menú es:

Diagnostics > Packet capture

Packet Capture muestra si los paquetes llegan a una interfaz, se reenvían, son procesados por el propio firewall o se descartan. Esto es especialmente importante cuando en Log Viewer no aparece nada claro.

Procedimiento básico:

1. Delimitar el caso de prueba: anotar IP de origen, IP de destino, puerto y protocolo.
2. Abrir Diagnostics > Packet capture.
3. Establecer un filtro de captura lo más estrecho posible.
4. Activar Packet Capture.
5. Reproducir el problema.
6. Detener la captura.
7. Verificar entradas por origen, destino, Rule ID, NAT ID, estado y razón.

Packet Capture muestra, entre otros, Rule ID, NAT ID, Status, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID y Username. Estos campos ayudan cuando no solo una regla de firewall, sino también Webfilter, IPS, Application Control o NAT están involucrados.

Para el manejo de la herramienta, Usar Packet Capture en WebAdmin es la guía más detallada.

Comprender el estado de Packet Capture

Los valores de estado son cruciales para el análisis. Sophos Firewall ofrece seis valores de estado en el filtro de visualización: Allowed, Violation, Consumed, Generated, Incoming y Forwarded.

• Incoming: El paquete llega a una interfaz WAN o LAN. La fuente alcanza el firewall.
• Allowed: El paquete fue permitido por la regla de firewall o política correspondiente. Este estado a menudo se superpone con Forwarded en la práctica; si un paquete aparece como Allowed pero no como Forwarded, conviene revisar el enrutamiento, la ruta de retorno o un módulo de seguridad posterior.
• Forwarded: El paquete se reenvía. El firewall deja pasar el paquete en principio.
• Consumed: El paquete está destinado al propio firewall. Device Access, VPN Portal, DNS, DHCP u otro servicio local.
• Generated: El paquete es generado por el firewall. Respuesta o tráfico del sistema del firewall.
• Violation: El paquete se descarta debido a una violación de política. Una regla, módulo o función de seguridad bloquea.

Un solo Incoming sin un Forwarded correspondiente puede significar que el firewall descarta el paquete, lo procesa él mismo o que el filtro no muestra todo el flujo. Por eso siempre se deben considerar ambas direcciones.

Después del primer estado, no se debe crear inmediatamente una excepción. Es mejor derivar la siguiente prueba del estado:

• Solo Incoming visible: Verificar filtro, capturar dirección opuesta, buscar Rule ID y excluir Firewall ID 0.
• Incoming y Forwarded, pero sin respuesta: Verificar ruta de retorno, sistema de destino, firewall local del servidor, NAT y enrutamiento asimétrico.
• Consumed visible: Verificar Device Access, Local service ACL y servicio de firewall local afectado.
• Generated visible: Verificar si el firewall responde por sí mismo o genera tráfico del sistema.
• Violation visible: Comparar Reason, Rule ID, NAT ID y módulo afectado en Log Viewer.

Esto mantiene el análisis reproducible: el estado decide qué herramienta es más adecuada a continuación. En Violation, Log Viewer es importante; si falta respuesta, es mejor verificar el camino de retorno y Packet Capture; en Consumed, Device Access en lugar de la regla de firewall.

Triaje rápido de síntomas

En la práctica, una breve tabla de síntomas ahorra tiempo antes de profundizar en logs o shell:

• Log Viewer muestra Invalid traffic: Estado de sesión, ruta de retorno, enrutamiento asimétrico. Comprobar ambas direcciones con Packet Capture.
• Packet Capture solo muestra Incoming: Descarte, servicio local, regla predeterminada o filtro incompleto. Ampliar filtro, ejecutar Policy Test, revisar Firewall ID 0.
• Packet Capture muestra Forwarded, pero no hay respuesta: Sistema destino, ruta de retorno, NAT, firewall externo. Comprobar paquetes de respuesta y ruta de retorno.
• Packet Capture muestra Consumed: Tráfico hacia el propio firewall. Revisar Device Access y Local service ACL.
• Packet Capture muestra Violation: Regla, módulo de seguridad o infracción de policy. Comparar Reason, Rule ID, NAT ID y log del módulo.
• Log Viewer y Packet Capture no muestran nada: El tráfico no llega al firewall. Revisar cliente, VLAN, switch, gateway u objetivo de prueba incorrecto.

Firewall ID 0 y regla Drop explícita

Cuando no coincide ninguna regla explícita de firewall, Sophos Firewall descarta el tráfico mediante la regla final integrada con Firewall ID 0 o Policy ID 0. Esta regla siempre está al final de las reglas de firewall. Importante para troubleshooting y SIEM: la regla Drop-all integrada no registra el tráfico por sí misma. Quien quiera ver todas las conexiones descartadas de forma trazable necesita una regla Drop explícita propia con logging activado.

Si los drops por la regla predeterminada no son visibles, la decisión de policy no es automáticamente incorrecta. En Packet Capture puede verse solo Incoming, pero no la entrada Violation Firewall correspondiente. El problema es entonces la trazabilidad durante el troubleshooting, no necesariamente la decisión real de descarte.

Si un caso de prueba no coincide con ninguna regla y aún así no se ve un descarte, se debe verificar adicionalmente:

1. Usar Policy Test y verificar si la prueba cae en Firewall ID 0 o la regla predeterminada.
2. Verificar el orden de las reglas y asegurarse de que ninguna otra regla más arriba coincida inesperadamente.
3. Crear al final de la base de reglas una regla Drop explícita si los drops deben registrarse o enviarse a Central Reporting o Syslog.
4. Realizar nuevamente la prueba y verificar si el descarte ahora es visible con la Rule ID explícita.
5. Incluir la regla de descarte explícita en la documentación de cambios y revisión de reglas, para que no se malinterprete más tarde como una regla normal de permitir/denegar.

Al crear la regla final deben elegirse las zonas conscientemente. Sophos recomienda usar Source y Destination zones concretas y no poner Any de forma global como zona, para no afectar innecesariamente servicios internos. Para un entorno auditable, la regla final explícita es útil. Pero no sustituye una estructura de reglas limpia. Si mucho tráfico legítimo termina en la regla final, probablemente falta más arriba una regla Allow más precisa o una red está mal clasificada.

Leer campos importantes en Packet Capture

En los descartes, no solo es importante el estado. Los campos adicionales muestran qué parte del firewall procesó el tráfico.

• Rule ID: Regla de firewall coincidente. ¿Coincide con la regla esperada?
• NAT ID: Regla NAT coincidente. ¿Se espera NAT, falta NAT o se aplica una regla NAT incorrecta?
• Reason: Razón para el descarte o violación. No leer de forma aislada, sino comparar con estado y módulo.
• Web filter ID: Decisión de política web. Verificar categoría, grupo de URL y contexto del usuario.
• Application ID: Aplicación reconocida. Application Control puede decidir de manera diferente a lo que sugiere el puerto.
• IPS policy ID: Política IPS aplicada. Verificar firma, contexto de regla y riesgo de falso positivo.
• Username: Usuario reconocido. Evaluar coincidencia de usuario solo si el usuario es realmente visible.

Si Rule ID o NAT ID son inesperados, no se debe crear inmediatamente una excepción. Primero debe quedar claro si el caso de prueba estaba correctamente definido, si una regla más general más arriba coincide o si NAT cambia la vista de origen y destino.

Usar Reason como guía

El valor Reason no es un informe completo de root cause, pero sí una buena guía hacia el siguiente módulo. Firewall apunta más a base de reglas, regla predeterminada o lógica de zonas. LOCAL_ACL encaja con Device Access y Local service ACL. INVALID_TRAFFIC apunta más a estado de sesión, ruta de retorno o routing asimétrico. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION o VIRTUAL_HOST muestran que no debe comprobarse solo la regla de firewall.

Por eso ayuda un breve triple paso: leer primero el status, clasificar después el Reason y abrir luego el módulo adecuado en Log Viewer. Así un único registro Violation se convierte en un camino de comprobación trazable en lugar de una invitación a crear una excepción amplia.

Consumed y servicios de firewall locales

Consumed no es un descarte normal. El estado significa que el paquete está destinado al propio firewall. Los destinos típicos son WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN o SNMP.

En tales casos, a menudo no es la regla de firewall normal la que importa, sino Device Access y Local service ACL. Si, por ejemplo, WebAdmin, SSH, VPN Portal o SNMP no son accesibles, no se debe buscar solo en Rules and policies > Firewall rules. El punto de partida correcto suele ser Administration > Device access.

Para el endurecimiento y solución de problemas en servicios de firewall locales, consulte Asegurar el acceso a Sophos Firewall: Configurar correctamente Device Access.

Causas comunes de descartes

No hay una regla de firewall adecuada

La causa más común es una regla que no coincide. Las razones pueden ser:

• zona de origen incorrecta
• red de origen incorrecta
• zona de destino incorrecta
• IP de destino mal interpretada en DNAT
• servicio faltante o protocolo incorrecto
• usuario no autenticado
• el horario no coincide
• una regla más específica está debajo de una regla más general

Para la estructura de reglas, consulte Entender y configurar correctamente las reglas de Sophos Firewall. Si DNAT está involucrado, también debe verificarse Publicar servidores mediante DNAT en Sophos Firewall.

NAT o camino de retorno no coinciden

A veces, el firewall permite el camino de ida, pero la respuesta regresa de manera diferente o se traduce incorrectamente.

Puntos típicos:

• Falta SNAT o MASQ.
• DNAT apunta al host interno incorrecto.
• Se desactivó una regla NAT vinculada.
• Falta la ruta de retorno.
• SD-WAN o enrutamiento estático envía el tráfico de respuesta por otro camino.
• En tráfico VPN, falta una ruta IPsec adecuada o ruta de retorno.

El enrutamiento asimétrico a menudo genera errores difíciles de entender, ya que el firewall no puede asignar correctamente el estado de la conexión. Entonces, los paquetes pueden aparecer como no pertenecientes a la conexión.

El paquete no pertenece a una conexión conocida

Mensajes como Could not associate packet to any connection o indicaciones similares de Conntrack a menudo significan que el firewall no encuentra un objeto de contexto de conexión adecuado.

Posibles causas:

• El tráfico de retorno toma otro camino.
• La conexión se estableció en otro nodo HA.
• La sesión ya ha expirado.
• Las banderas TCP no coinciden con la conexión esperada.
• Un dispositivo envía respuestas sin solicitud previa.
• La inspección con estado solo ve una parte del flujo de datos.

Aquí, Packet Capture es más importante que una sola entrada de registro. Se debe ver si ambas direcciones pasan por el mismo firewall y la misma zona.

Webfilter, TLS Inspection, Application Control o IPS bloqueado

No todos los descartes provienen de la regla de firewall en sí. A menudo, el tráfico es permitido, pero luego bloqueado por un módulo de seguridad.

Ejemplos típicos:

• La política web bloquea una categoría o grupo de URL.
• La inspección TLS falla debido a un certificado, SNI, cifrado o excepción.
• Application Control reconoce una aplicación no deseada.
• IPS bloquea un patrón.
• Active Threat Response encuentra un IoC.
• Zero-Day Protection retiene o bloquea una descarga.

En caso de coincidencias de IPS, se debe verificar la firma, política y contexto de la regla antes de establecer una excepción amplia. El procedimiento adecuado está en Configurar y probar de manera segura IPS en Sophos Firewall.

En casos de Web y TLS, también se debe verificar QUIC. Si los navegadores evitan a través de UDP 443, las expectativas de Webfilter y TLS no siempre coinciden. Más información: Bloquear correctamente QUIC y HTTP/3 en Sophos Firewall.

MTU, MSS o fragmentación

En VPN, PPPoE, SD-WAN, redes móviles o túneles anidados, un paquete puede ser demasiado grande para el camino. Entonces, no siempre se ve un descarte claro del firewall, sino más bien interrupciones de conexión, aplicaciones lentas o servicios individuales que se cuelgan.

Para tales casos, consulte Comprobar MTU y MSS en problemas de VPN en Sophos Firewall.

Procedimiento estructurado

Para la práctica, esta secuencia funciona bien:

1. Anotar el caso de prueba: Origen, destino, puerto, protocolo, hora.
2. Verificar Log Viewer: Filtrar por módulo de firewall y módulos de seguridad adecuados.
3. Buscar Rule ID y NAT ID: Verificar qué regla se activó realmente.
4. Iniciar Packet Capture: Establecer un filtro estrecho y reproducir la prueba.
5. Verificar estado: Evaluar Incoming, Forwarded, Consumed, Generated o Violation.
6. Verificar dirección de retorno: ¿La respuesta regresa y por el mismo camino?
7. Verificar módulos de seguridad: Web, TLS, Application Control, IPS, ATR, WAF.
8. Verificar registros de servicio: En problemas de servicio, verificar el archivo de registro adecuado en /log.
9. Verificar registros centrales: Incluir Central Reporting o SIEM si los registros locales no son suficientes.

Los archivos de servicio y registros adecuados están resumidos en Solución de problemas de Sophos Firewall: Servicios y registros.

Cuando no aparece nada en Log Viewer

La falta de una entrada de registro no significa automáticamente que el firewall no esté involucrado.

Posibles causas:

• El registro no está activado en la regla de firewall.
• El tipo de registro relevante no está activo en System services > Log settings.
• La conexión no se cerró correctamente y, por lo tanto, no se registró.
• El tráfico no llega al firewall.
• El tráfico es procesado por un servicio local.
• El filtro en Log Viewer es demasiado estrecho.
• El almacenamiento de registros es limitado o las entradas antiguas ya fueron sobrescritas.

En tales casos, primero use Packet Capture. Si Packet Capture tampoco muestra entrada, el enfoque se centra más en el cliente, switch, VLAN, enrutamiento antes del firewall o un objetivo de prueba incorrecto.

Cuándo son necesarios tcpdump o archivos de registro

El Packet Capture de WebAdmin es bueno para análisis rápidos. Para capturas más largas, archivos PCAP, filtros muy precisos o casos de soporte, tcpdump a través de SSH a menudo es más adecuado. Esto es especialmente cierto si un problema solo ocurre esporádicamente o si la captura debe ser analizada más tarde en Wireshark o por el soporte de Sophos.

Para tales casos, se debe aclarar antes de la captura:

• ¿Qué IP de origen, IP de destino y puertos deben estar en el filtro?
• ¿Cuánto tiempo puede durar la captura?
• ¿Dónde se guardará el archivo PCAP?
• ¿Quién puede ver el archivo?
• ¿Cuándo se eliminará el archivo después del análisis?

El procedimiento práctico está en Capturar paquetes con tcpdump en Sophos Firewall a través de CLI. Si además de paquetes se necesitan registros de servicio, consulte Guardar registros de Sophos Firewall para soporte y análisis.

Establecer excepciones solo de manera específica

Con los descartes, la tentación es grande de crear rápidamente una excepción. Esto puede ayudar a corto plazo, pero a menudo empeora la seguridad o oculta la causa.

Las excepciones solo deben establecerse cuando esté claro:

• qué módulo bloquea
• qué host, dominio o aplicación está afectado
• por qué el tráfico es legítimo
• cuán estrecha puede ser la excepción
• cuándo se revisará o eliminará la excepción

Se deben evitar excepciones amplias para redes enteras, reglas Any o excepciones TLS globales. Es mejor una excepción pequeña, documentada y con fecha de revisión.

Documentar el hallazgo

Un buen hallazgo de descarte debe estar documentado de tal manera que otra persona pueda reproducir la prueba. Esto es importante para revisiones internas, documentación de cambios y casos de soporte.

Al menos registrar:

• Fecha, hora y zona horaria de la prueba.
• IP de origen, IP de destino, puerto, protocolo y usuario.
• Regla de firewall esperada y Rule ID visible realmente.
• Regla NAT esperada y NAT ID visible realmente.
• Estado de Packet Capture: Allowed, Incoming, Forwarded, Consumed, Generated o Violation.
• Mensaje relevante de Reason o módulo.
• Cambio realizado o conscientemente no realizado.
• Si se estableció una excepción: propietario, propósito, validez y fecha de revisión.

Esta documentación evita que un paso de solución de problemas a corto plazo se convierta en una brecha de seguridad permanente y poco clara.

Lista de verificación

• IP de origen, IP de destino, puerto y protocolo conocidos.
• Hora de la prueba documentada.
• Log Viewer verificado con el módulo y filtro de tiempo correctos.
• Rule ID y NAT ID evaluados.
• En caso de falta de entrada de descarte, verificar si Firewall ID 0 o la regla predeterminada están afectados.
• Regla de firewall y orden de reglas verificados.
• Regla NAT y ruta de retorno verificadas.
• Packet Capture realizado con filtro estrecho.
• Estado y razón evaluados en Packet Capture.
• Dirección de ida y vuelta verificadas.
• Webfilter, TLS Inspection, Application Control, IPS y Active Threat Response verificados.
• En VPN, MTU, MSS y ruta verificados.
• En DNAT o WAF, host de destino, dirección alojada y backend verificados.
• Registros centrales o Syslog verificados si los registros locales no son suficientes.
• En caso de necesidad de soporte, tcpdump o archivo de registro preparado específicamente.
• Excepciones establecidas solo de manera estrecha y documentada.
• Hallazgo documentado con Rule ID, NAT ID, estado, razón y cambio.

Preguntas frecuentes