SonicWall Packet Monitor: cómo identificar por qué el firewall bloquea tráfico

¿Un firewall SonicWall permite navegar, pero bloquea una aplicación, un servidor o una página web? Aprende a capturar paquetes con Packet Monitor, interpretar Drop Codes como Policy Drop y Enforced Firewall Rule, revisar reglas de acceso, NAT y rutas, y encontrar la causa sin desactivar los servicios de seguridad.

Una aplicación deja de funcionar. Los usuarios tienen Internet, el firewall SonicWall está encendido y aparentemente no existe ninguna falla de conectividad. Sin embargo, no pueden abrir el ERP, conectarse a un servidor, utilizar una plataforma en la nube o acceder a una página web específica.

¿El problema está en una Access Rule? ¿Falta una política NAT? ¿El firewall está bloqueando la aplicación mediante IPS, App Control o Content Filtering? ¿O el tráfico realmente está saliendo del firewall y la falla se encuentra en otro punto de la red?

Para resolver estas preguntas, SonicWall dispone de una herramienta de diagnóstico especialmente útil: Packet Monitor.

En esta guía de la Biblioteca Virtual SISTRO 2.0 explicamos cómo capturar tráfico, interpretar paquetes descartados, comprender los Drop Codes y construir una metodología para identificar la causa de un bloqueo sin desactivar indiscriminadamente los servicios de seguridad.

Alcance: firewalls SonicWall TZ y NSa que utilizan SonicOS 7 u 8. La ubicación de algunos menús y las opciones disponibles pueden variar según la versión de firmware, el modelo y la configuración.

1. ¿Qué es SonicWall Packet Monitor?

Packet Monitor es una herramienta integrada en SonicOS que permite observar paquetes de red que atraviesan el firewall, llegan al propio dispositivo o son descartados durante su procesamiento.

En lugar de asumir que una regla está bloqueando una conexión, podemos recopilar evidencia acerca del tráfico real.

Dependiendo de la configuración, permite analizar información como:

Dirección IP de origen.
Dirección IP de destino.
Puertos TCP o UDP.
Protocolo utilizado.
Interfaz de entrada y salida.
Estado del paquete.
Información relacionada con NAT.
Drop Code y motivo de descarte.

También permite exportar capturas para analizarlas posteriormente con herramientas como Wireshark.

Packet Monitor no sustituye el análisis completo de la red, pero permite determinar si SonicWall está recibiendo, reenviando o descartando el tráfico investigado.

2. ¿Qué problemas podemos diagnosticar?

La herramienta resulta útil cuando una conexión falla de manera aparentemente inexplicable.

Por ejemplo:

Un usuario no puede abrir una página HTTPS específica.
Una aplicación empresarial no consigue conectarse a su servidor.
Un sistema ERP falla únicamente desde determinada VLAN.
Una aplicación SaaS funciona desde otra red, pero no desde la oficina.
Un servidor publicado mediante NAT no recibe conexiones externas.
Un túnel VPN está establecido, pero determinados servicios son inaccesibles.
El firewall muestra eventos de bloqueo asociados con IPS o App Control.
Una nueva política de seguridad provoca problemas de comunicación.

Antes de capturar paquetes conviene definir exactamente qué conexión se quiere investigar.

Es importante conocer el origen, el destino, el servicio utilizado y el momento en que aparece el error.

3. Cómo abrir Packet Monitor en SonicOS 7 y SonicOS 8

Para SonicOS 7, la documentación de SonicWall indica la siguiente ruta:

Monitor → Tools & Monitors → Packet Monitor

En SonicOS 8, el Monitor Administration Guide también ubica la función bajo:

MONITOR → Tools & Monitor → Packet Monitor

Los nombres pueden presentarse ligeramente diferentes según la interfaz y versión instalada.

Una vez dentro, el procedimiento general es:

Comprobar que no exista una captura anterior en ejecución.
Guardar o exportar evidencia anterior, si es necesaria.
Restablecer los parámetros de monitoreo cuando corresponda.
Configurar los filtros de captura.
Iniciar la captura.
Reproducir el problema desde el equipo afectado.
Detener la captura.
Examinar los paquetes y sus detalles.

El fabricante recomienda utilizar la opción de configuración predeterminada del monitor cuando sea apropiado para evitar que filtros antiguos interfieran con un nuevo diagnóstico.

4. Monitor Filter vs Display Filter: una diferencia fundamental

SonicWall distingue dos tipos de filtros que no deben confundirse.

Monitor Filter

Determina qué tráfico se recopila durante la captura.

Permite seleccionar parámetros como:

IP origen.
IP destino.
Puerto origen o destino.
Protocolo.
Interfaz.
Estado de procesamiento del paquete.

Si este filtro es demasiado restrictivo, los paquetes que necesitamos investigar podrían no capturarse.

Display Filter

Controla qué paquetes se muestran de entre los que ya fueron capturados.

Esto permite reducir visualmente la información sin cambiar los datos que el monitor recopiló.

Recomendación: al comenzar, utiliza un Monitor Filter suficientemente preciso para identificar la conexión, pero evita filtrar tantas condiciones que desaparezcan los paquetes de retorno, las traducciones NAT o las respuestas relevantes.

Deja inicialmente el Display Filter sin restricciones adicionales.

5. Forwarded, Consumed y Dropped: cómo interpretar los estados

Packet Monitor permite diferenciar distintas formas de procesamiento.

Estado	Interpretación general
Forwarded	El firewall reenviará o ha procesado el paquete para enviarlo hacia otra interfaz.
Consumed	El paquete fue recibido y procesado por el propio firewall.
Dropped	El paquete fue descartado durante su procesamiento.

Estos estados son importantes porque no todos los problemas de conectividad representan un bloqueo del firewall.

Si SonicWall recibe una solicitud y la reenvía correctamente, pero la respuesta nunca regresa, es necesario investigar el camino de retorno, el servidor o los sistemas intermedios.

Si SonicWall descarta el paquete, entonces necesitamos revisar su motivo de descarte.

Para una primera captura, la documentación oficial recomienda generalmente no limitar la recopilación exclusivamente a paquetes Dropped, ya que observar también los paquetes permitidos ayuda a reconstruir el flujo.

6. Caso práctico: un usuario no puede abrir una aplicación HTTPS

Imaginemos el siguiente escenario ilustrativo:

Elemento	Valor de ejemplo
Equipo del usuario	10.10.20.15
Aplicación	Servidor HTTPS externo
Puerto	TCP 443
Firewall	SonicWall TZ o NSa
Síntoma	La aplicación no consigue establecer conexión

Las direcciones utilizadas en este ejemplo son ficticias.

Para comenzar el diagnóstico configuramos Packet Monitor con:

Source IP: 10.10.20.15.
Protocolo: TCP.
Puerto de destino: 443, cuando el filtro resulte adecuado.
Estados de paquetes: sin restringir inicialmente.

Si conocemos la dirección IP actual del destino, podemos añadirla para reducir el volumen de la captura.

Cuando el origen y destino pueden cambiar debido a NAT o cuando necesitamos analizar las respuestas, debemos comprobar que el filtro permita observar el flujo completo. La opción de coincidencia bidireccional, disponible en versiones compatibles, puede ser útil.

Después iniciamos la captura y pedimos al usuario que reproduzca el problema una sola vez.

7. Cómo interpretar los paquetes capturados

Durante una conexión TCP convencional podemos esperar una secuencia inicial similar a esta:

Cliente              Servidor
   | ---- SYN ------> |
   | <--- SYN/ACK --- |
   | ---- ACK ------> |
   |                  |
   | ---- Datos ----> |
   | <--- Datos ----- |

Este es un diagrama conceptual, no una captura literal de Packet Monitor.

Al analizar el flujo conviene identificar:

Si el paquete inicial llega a SonicWall.
Si SonicWall lo permite y reenvía.
Qué traducción NAT se aplica, cuando corresponde.
Si llega una respuesta desde el destino.
Si la conexión TCP logra establecerse.
En qué punto ocurre el primer descarte relevante.

Si vemos una solicitud SYN descartada, revisaremos inicialmente políticas de acceso, rutas, NAT y dirección de entrada.

Si el handshake TCP se completa y la sesión falla posteriormente, el problema podría estar relacionado con inspección de seguridad, filtrado de contenido, comportamiento TLS o con la aplicación misma.

No debemos concluir automáticamente que una aplicación fue bloqueada por SonicWall solamente porque el usuario recibió un error del navegador.

8. Qué son los Drop Codes de SonicWall

Cuando SonicWall descarta determinados paquetes, Packet Monitor puede mostrar un código y una descripción asociados con el motivo del descarte.

En la interfaz, los paquetes descartados suelen visualizarse en rojo.

Al seleccionar uno podemos examinar Packet Details para consultar información adicional, incluido el Drop Code o Drop Reason.

El texto del código es especialmente útil para identificar qué componente investigar.

Sin embargo, un Drop Code debe interpretarse junto con el paquete, el momento de la conexión y el resto del flujo.

Importante: SonicWall advierte que algunos números de Drop Code pueden cambiar entre versiones de firmware. Por eso es preferible conservar también la descripción textual del evento.

9. Error: Packet Dropped — Policy Drop

Uno de los motivos que pueden aparecer es:

Packet Dropped - Policy Drop

La documentación de SonicWall indica que este resultado requiere revisar diferentes elementos de la configuración.

Entre las posibles causas se encuentran:

Access Rules inexistentes o incorrectas.
Políticas NAT ausentes o mal configuradas.
Rutas incorrectas o conflictivas.
Tráfico recibido por una interfaz inesperada.
Configuraciones que no coinciden con la zona correspondiente.

El error no debe resolverse automáticamente mediante una regla que permita todo el tráfico.

Lo correcto es identificar el origen, destino y servicio que deberían estar autorizados.

Después hay que validar qué política se está aplicando y por qué el tráfico no coincide con ella.

10. Error: Enforced Firewall Rule

Otro mensaje documentado es:

Enforced Firewall Rule

Este resultado puede requerir un análisis más amplio de las reglas y servicios de seguridad.

Según la documentación del fabricante, conviene revisar:

Access Rules.
Políticas NAT.
Políticas de routing.
Application Control.
Content Filtering.
SSL Control.
Registros asociados con el usuario o aplicación.

Existe una pista útil: si se descarta el SYN inicial, la investigación suele concentrarse primero en acceso, NAT y rutas.

Si la comunicación TCP ya se estableció y el descarte ocurre más tarde, los controles de aplicación o contenido pueden ser relevantes.

Esta diferencia ayuda a reducir el número de hipótesis.

No recomendamos desactivar globalmente IPS, App Control, Content Filtering o DPI-SSL como primera medida. Si se necesita una excepción de diagnóstico, debe ser específica, autorizada, temporal y posteriormente revertida o ajustada conforme a la política de seguridad.

11. Error: IDP Detection

Un Drop Code relacionado con detección IDP puede indicar que un motor de protección identificó tráfico que coincide con alguna condición de prevención.

En estos casos conviene revisar los registros de seguridad para identificar:

Servicio o motor que generó el evento.
Firma o Signature ID, cuando esté disponible.
Direcciones IP involucradas.
Aplicación y protocolo.
Hora y frecuencia del bloqueo.
Contexto del dispositivo y usuario afectado.

Antes de crear una exclusión necesitamos determinar si se trata de una amenaza real, una incompatibilidad conocida o una posible detección incorrecta.

Una aplicación que no funciona no justifica desactivar de forma permanente los mecanismos de prevención de intrusiones.

12. Cache Add Cleanup: no todos los paquetes descartados representan una falla

Un detalle importante del análisis de tráfico es que no todo paquete descartado representa necesariamente una interrupción de servicio.

SonicWall documenta el motivo Cache Add Cleanup en escenarios donde llegan paquetes que ya no corresponden a una conexión TCP válida.

Por ejemplo, un ACK que aparece después del cierre de una sesión puede ser descartado porque el firewall ya no dispone del estado correspondiente.

En determinadas situaciones este descarte forma parte del comportamiento normal de un firewall stateful.

Por eso debemos distinguir:

Paquetes descartados que explican directamente la interrupción.
Paquetes descartados como consecuencia de una sesión que ya terminó.
Paquetes inesperados o fuera de secuencia.
Tráfico realmente malicioso o no autorizado.

La presencia de paquetes rojos en Packet Monitor no es suficiente para diagnosticar un problema.

13. Revisa las Access Rules y las zonas de seguridad

Las reglas de acceso son uno de los primeros elementos que debemos investigar cuando el tráfico es descartado.

En SonicOS 7 y 8, revisa las reglas desde la sección correspondiente de Policy → Rules and Policies → Access Rules, según la versión instalada.

Comprueba:

Zona de origen, como LAN, VPN, WLAN o DMZ.
Zona de destino.
Objeto de dirección de origen.
Objeto de dirección de destino.
Servicio y puerto.
Acción de la regla.
Prioridad y coincidencia de políticas.
Opciones de autenticación y logging.

Un error frecuente consiste en configurar una regla para una relación de zonas distinta de la utilizada realmente por el tráfico.

Por ejemplo, una aplicación alojada en una VLAN de servidores puede requerir una política LAN hacia DMZ en lugar de una regla LAN hacia WAN.

Las etiquetas de zona deben corresponder con la arquitectura real.

14. Por qué NAT puede explicar un bloqueo inesperado

La traducción de direcciones también influye en el procesamiento de una conexión.

Consideremos un servidor interno publicado en Internet mediante NAT.

Tenemos:

Cliente externo
      |
      v
IP pública del firewall
      |
      v
SonicWall / NAT Policy
      |
      v
Servidor interno

Para que la conexión funcione debemos verificar tanto las reglas de acceso como la política NAT correspondiente.

Una traducción incorrecta puede hacer que el tráfico alcance el firewall, pero no llegue al servidor esperado.

También pueden existir problemas de NAT loopback cuando un usuario interno intenta acceder a un servidor mediante su dirección pública.

SonicWall documenta casos de Policy Drop asociados con configuraciones incorrectas de loopback NAT y Access Rules.

Para investigar traducciones, Packet Monitor permite adaptar los filtros de origen y destino y observar diferentes momentos del procesamiento.

Evita filtrar simultáneamente una dirección original y otra traducida sin confirmar cómo coinciden con los paquetes.

15. ¿Qué pasa si el paquete sale del SonicWall pero no hay respuesta?

Este es un escenario diferente de un bloqueo explícito del firewall.

Si la captura muestra que el tráfico fue reenviado correctamente, debemos determinar qué sucede después.

Entre las hipótesis se encuentran:

El servidor remoto está fuera de servicio.
Un firewall intermedio descarta la conexión.
El proveedor presenta un problema de routing.
Existe una ruta de retorno incorrecta.
El servidor no tiene abierto el puerto solicitado.
La dirección de destino no corresponde al servicio esperado.
La aplicación falla después de completar el transporte TCP.

Packet Monitor ayuda a demostrar si SonicWall reenvió el tráfico, pero no reemplaza las pruebas desde el destino o desde otro punto de la infraestructura.

Esta distinción también es importante para evitar modificar una política cuando la falla realmente se encuentra en el proveedor o en el servidor.

16. Packet Monitor y DPI-SSL: cómo investigar aplicaciones HTTPS

En entornos con inspección HTTPS, una aplicación puede fallar después de que el firewall permitió establecer la comunicación inicial.

En estos casos debemos diferenciar:

Bloqueo de Access Rules.
Problema de conectividad IP.
Error de certificado.
Validación de Certificate Pinning.
Bloqueo de IPS o Application Control.
Incompatibilidad con DPI-SSL.
Problema propio de la aplicación.

Packet Monitor puede aportar evidencia de transporte y descarte, pero el contenido de una conexión TLS cifrada no siempre será visible en la captura exportada.

Para investigar los aspectos de inspección de certificados, exclusiones y compatibilidad, consulta nuestra guía anterior:

SonicWall DPI-SSL: cómo inspeccionar HTTPS sin romper aplicaciones ni degradar la red.

17. Cómo exportar capturas y analizarlas con Wireshark

Packet Monitor permite exportar los paquetes para un análisis más detallado.

Entre los formatos admitidos se encuentra Libpcap, que puede abrirse en Wireshark.

En una investigación con Wireshark podemos revisar:

TCP SYN, SYN/ACK y ACK.
Retransmisiones.
Resets TCP.
Secuencias de comunicación.
Paquetes ICMP.
Intercambios DNS visibles.
Puertos y direcciones.
Flujos en distintos momentos del incidente.

Ejemplos de filtros de visualización en Wireshark:

ip.addr == 10.10.20.15

tcp.port == 443

tcp.analysis.retransmission

tcp.flags.reset == 1

Estos filtros son ejemplos para Wireshark, no comandos de la CLI de SonicWall.

Una captura puede contener datos sensibles, identificadores, direcciones internas e información de aplicaciones. Debe almacenarse y compartirse conforme a las políticas de seguridad de la organización.

18. Por qué una captura vacía no demuestra que no exista tráfico

Si Packet Monitor no muestra paquetes, todavía no podemos concluir que el tráfico nunca llegó al firewall.

Antes debemos comprobar:

Que la captura esté realmente activa.
Que el usuario haya reproducido el problema.
Que los filtros correspondan al origen y destino correctos.
Que el tráfico utilice la interfaz esperada.
Que la aplicación no esté utilizando otra dirección IP o protocolo.
Que el Display Filter no oculte los resultados.
Que no se haya saturado el buffer de captura.
Que las opciones avanzadas permitan observar el tráfico requerido.

Algunas capturas requieren considerar paquetes generados internamente, tráfico IPsec u otros tipos de procesamiento incluidos en las opciones avanzadas.

Las opciones adicionales pueden aumentar significativamente el volumen de datos, por lo que conviene utilizarlas con un alcance controlado.

19. Matriz rápida de diagnóstico

Observación	Investigación recomendada
Policy Drop	Access Rules, NAT, rutas, zonas e interfaces
Enforced Firewall Rule	Reglas, App Control, CFS, SSL Control y logs
IDP Detection	IPS, firmas, registros y contexto de seguridad
Cache Add Cleanup	Estado de conexión TCP y paquetes tardíos
SYN descartado	Reglas de acceso, NAT y routing
SYN reenviado sin respuesta	Servidor, red intermedia y camino de retorno
TCP establecido, HTTPS falla	TLS, certificados, DPI-SSL y aplicación
No hay paquetes visibles	Filtros, interfaz, dirección y captura

20. Procedimiento recomendado para diagnosticar de forma segura

Definir el síntoma: identificar la aplicación y el error exacto.
Identificar el flujo: IP origen, IP destino, protocolo y puerto.
Documentar la configuración: modelo, firmware y cambios recientes.
Preparar Packet Monitor: revisar los filtros y condiciones de captura.
Capturar el tráfico: reproducir una sola vez la falla.
Examinar los paquetes: identificar reenviados y descartados.
Leer Drop Code: interpretar el motivo y correlacionarlo con los logs.
Verificar la política: revisar solamente los componentes relacionados.
Aplicar una corrección controlada: evitar reglas excesivamente permisivas.
Validar y documentar: confirmar que la aplicación funciona y que las protecciones permanecen activas.

Las capturas y registros deben almacenarse como evidencia cuando el incidente afecta aplicaciones críticas.

21. Checklist para administradores SonicWall

☐ Modelo exacto SonicWall TZ o NSa.
☐ Versión de SonicOS.
☐ IP origen y destino.
☐ Puerto TCP o UDP.
☐ Zona e interfaz de entrada.
☐ Zona e interfaz de salida.
☐ Filtros Packet Monitor verificados.
☐ Captura inicial con tráfico forwarded y dropped.
☐ Paquetes de retorno observados.
☐ Drop Code y descripción registrados.
☐ Access Rule correspondiente identificada.
☐ NAT Policy revisada.
☐ Routing Policy validada.
☐ Servicios IPS, App Control y CFS revisados.
☐ DPI-SSL comprobado cuando corresponde.
☐ Eventos de seguridad correlacionados.
☐ Captura exportada cuando es necesaria.
☐ Corrección aplicada con mínimo privilegio.
☐ Funcionamiento del servicio verificado.
☐ Evidencia y causa raíz documentadas.

22. Soluciones SonicWall y servicios empresariales en SISTRO.NET

Un firewall correctamente dimensionado y actualizado proporciona las herramientas necesarias para aplicar políticas de seguridad, monitorear tráfico y proteger aplicaciones empresariales.

Pero una implementación segura también necesita diagnóstico, administración y procedimientos de operación.

En SISTRO.NET puedes consultar:

Antes de reemplazar un firewall por un problema de conectividad, es recomendable comprobar si la causa se encuentra en la configuración, la red, el software o en los servicios de seguridad.

23. Preguntas frecuentes

¿Qué es SonicWall Packet Monitor?

Es una herramienta integrada en SonicOS que permite capturar y analizar paquetes reenviados, consumidos o descartados para investigar problemas de comunicación.

¿Cómo sé si SonicWall está bloqueando una aplicación?

Captura el tráfico correspondiente y revisa si los paquetes son descartados por el firewall. Analiza el Drop Code, las políticas y los registros antes de establecer la causa.

¿Qué significa Policy Drop?

Es un motivo de descarte que puede relacionarse con reglas de acceso, NAT, routing, interfaces o configuraciones que no permiten procesar correctamente el tráfico.

¿Qué significa Enforced Firewall Rule?

Indica un descarte relacionado con la aplicación de reglas y controles del firewall. Debe investigarse junto con Access Rules, políticas de seguridad y registros de eventos.

¿Todos los paquetes descartados son problemas?

No. Algunos descartes pueden corresponder a paquetes inválidos, tardíos o no autorizados y formar parte del funcionamiento normal de un firewall stateful.

¿Puedo utilizar Wireshark con SonicWall?

Sí. Packet Monitor permite exportar capturas en formatos compatibles, como Libpcap, para analizarlas con Wireshark.

¿Packet Monitor funciona en SonicOS 8?

Sí. SonicWall dispone de documentación específica de Packet Monitor para SonicOS 8. La ubicación exacta de ciertas opciones puede variar entre versiones.

¿Qué hago si no aparecen paquetes?

Comprueba el estado de la captura, los filtros, las interfaces, el protocolo, la dirección real utilizada por la aplicación y las condiciones de captura avanzada.

¿Debo desactivar IPS para probar una aplicación?

No como primera medida. Primero identifica el motor, la firma y el motivo del bloqueo. Las excepciones deben ser específicas, justificadas y documentadas.

¿Packet Monitor puede mostrar el contenido HTTPS?

No necesariamente. Las conexiones TLS mantienen su cifrado y la visibilidad de su contenido depende de la arquitectura de inspección. Una captura normal no proporciona automáticamente el texto de una sesión HTTPS.

24. Documentación técnica oficial SonicWall

Conclusión: antes de modificar una regla, identifica qué sucede con los paquetes

Cuando una aplicación deja de funcionar detrás de SonicWall, la respuesta no debería ser crear una regla que permita todo el tráfico ni desactivar los servicios de seguridad.

El procedimiento correcto comienza con evidencia.

Identificar el flujo → capturar paquetes → revisar Drop Codes → correlacionar políticas y logs → aplicar la corrección → validar la aplicación.

Packet Monitor permite pasar de las suposiciones a un diagnóstico técnico documentado.

Una red empresarial correctamente protegida debe permitir las aplicaciones autorizadas sin debilitar innecesariamente los controles de seguridad.

Continúa consultando la Biblioteca Virtual SISTRO 2.0 y conoce las soluciones SonicWall disponibles en SISTRO.NET.