La regla de Sophos Firewall no se aplica: verificar causas

Cuando una regla de Sophos Firewall no se aplica, no se deben mover reglas ni ampliar objetos como primera medida. Primero hay que reproducir y observar un único flujo de datos: ¿llega el paquete, qué Firewall Rule ID y NAT Rule ID lo procesan, se reenvía y regresa una respuesta?

Por lo general, esto muestra que una condición es distinta de lo esperado, que se aplica una regla más general situada más arriba o que el problema surge después de decidir la regla. El propio firewall es la causa con mucha menos frecuencia que una prueba definida de manera imprecisa.

Decisión rápida: Si un Packet Capture iniciado y filtrado correctamente no muestra ningún paquete, primero hay que comprobar el cliente, la VLAN, el gateway o la ruta anterior al firewall. Una Rule ID diferente apunta al orden y al matching. Si la Rule ID y la NAT ID son correctas, el análisis continúa con el routing, la ruta de retorno, el sistema de destino o un módulo de seguridad.

Vía rápida: seguir un flujo concreto

Para la primera delimitación bastan seis pasos:

1. Definir el flujo de prueba: Anotar Source IP, Source zone, usuario, destino, protocolo, puerto y hora.
2. Demostrar la entrada: Iniciar Packet Capture con un filtro de captura limitado y provocar el mismo flujo.
3. Comprobar la Firewall Rule ID: Compararla con la regla esperada en Log Viewer o Packet Capture.
4. Comprobar la NAT Rule ID: Si interviene NAT, verificar la regla NAT real y su traducción.
5. Comprobar reenvío y respuesta: Buscar Forwarded, la interfaz de salida y los paquetes de retorno.
6. Solo entonces profundizar: Investigar routing, SD-WAN, User Matching, TLS Inspection, IPS, Web Policy o el sistema de destino.

Este procedimiento mantiene separadas las capas. Una regla de firewall decide el acceso y las funciones de protección, NAT traduce direcciones o puertos, el routing selecciona la ruta posterior y el sistema de destino debe conocer la ruta de retorno. Si se modifican todas las capas a la vez, puede desaparecer el síntoma, pero la causa sigue sin estar clara.

Si la prueba se dirige a WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP u otro servicio del propio firewall, no se aplican las mismas reglas que al tráfico de tránsito. En ese caso, la ruta de diagnóstico conduce directamente a Administration > Device access y a Local Service ACL.

Definir un caso de prueba reproducible

Una afirmación como «Internet no funciona» o «la regla VPN no se aplica» es demasiado amplia. Un caso de prueba útil puede ser, por ejemplo:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com o deliberadamente sin User Matching
• Destination: app.example.net, resuelto actualmente como 203.0.113.20
• Service: TCP 443
• Regla de firewall esperada: LAN-App-HTTPS, Rule ID 37
• Regla NAT esperada: NAT Rule ID 12 o expresamente ninguna regla NAT
• Hora de la prueba: 2026-08-08 10:15:00

Las direcciones IP, las ID, los nombres y la hora son valores de ejemplo y deben sustituirse por los del entorno correspondiente. Lo importante es el formato: durante el diagnóstico se mantienen iguales el origen, la IP de destino, el puerto y el usuario. Si entretanto cambian la resolución DNS, el cliente o la aplicación, ya no se está comparando el mismo flujo.

Interpretar las primeras observaciones

• Un Packet Capture activo no muestra ningún paquete pese a tener un filtro adecuado: Primero hay que comprobar el estado de la captura, el filtro y el búfer. Si son correctos, la causa probablemente se encuentra antes del firewall, por ejemplo en el cliente, la VLAN, el switch, el gateway, el proveedor o el Security Group de la nube.
• Log Viewer muestra otra Rule ID: Se evalúa antes una regla más general, generada automáticamente o que coincide de otra manera.
• La Firewall Rule ID es correcta, pero la NAT Rule ID no: Comprobar el orden de NAT y el origen, el destino y el servicio originales.
• La Rule ID y la NAT ID son correctas, pero no aparece Forwarded: Comprobar la acción de la regla, Reason, el routing o un módulo de seguridad.
• Aparece Forwarded, pero no llega respuesta: Comprobar la ruta de retorno, el sistema de destino, el firewall local del servidor o un bloqueo externo.
• Solo se ven afectados determinados usuarios: Comprobar por separado la autenticación y el User Matching del flujo de datos real.

El procedimiento combinado y detallado se encuentra en Probar una regla de firewall con Log Viewer, Policy Tester y Packet Capture. Este artículo se centra en explicar un match de regla inesperado.

Comprobar el orden y el matching de las reglas

Una regla de firewall solo se aplica si coinciden todos los criterios relevantes y ninguna regla anterior ha procesado ya el mismo tráfico.

Gana la primera regla que coincide

Sophos Firewall evalúa las reglas de arriba abajo y termina la búsqueda en la primera regla que coincide. Por ello, la posición en la lista es decisiva; la Rule ID solo es un identificador fijo y no corresponde a la posición.

También hay que tener en cuenta lo siguiente:

• Una regla general situada más arriba puede ocultar por completo una regla específica situada debajo.
• Los Rule Groups mejoran la visión general, pero no generan una lógica de matching propia. Se evalúan las reglas que contienen.
• Las reglas generadas automáticamente, por ejemplo para MTA, IPsec o hotspots, pueden insertarse en la parte superior y comprobarse primero.
• Un filtro activo en la tabla de reglas puede ocultar reglas relevantes. Antes del análisis se debe utilizar Reset filter.
• La regla Default Drop inmutable tiene Rule ID 0, se encuentra al final y no dispone de un Usage Counter normal. Los filtros de la tabla no se aplican a ella.

Para repasar por completo la lógica básica de una regla, consulte Entender y configurar correctamente las reglas de Sophos Firewall.

Leer conjuntamente todos los criterios de matching

Una regla que parece correcta puede fallar por un solo campo:

• Source zones: El cliente procede de otra zona, por ejemplo VPN en lugar de LAN, o la VLAN está asignada de otra forma.
• Source networks and devices: El objeto IP, el grupo de hosts o la subred no contiene la Source IP real.
• Destination zones: La zona de destino es incorrecta, especialmente con DNAT, VPN o redes enrutadas.
• Destination networks: La IP a la que se accede realmente no coincide con el objeto o se han confundido las perspectivas antes y después de NAT.
• Services: Falta el puerto, se han intercambiado TCP y UDP o la aplicación abre conexiones adicionales.
• Users or groups: El firewall no puede asignar el usuario a la Source IP o el grupo importado no coincide.
• Schedule: La planificación no está activa en el momento de la prueba.
• Exclusions: El flujo se excluye de la regla y después se comprueba con las reglas siguientes.

En el tráfico web, el protocolo también forma parte de la prueba. Los navegadores pueden utilizar QUIC mediante UDP 443, mientras que la regla o la inspección web esperada solo cubre HTTPS clásico mediante TCP 443. Controlar QUIC en Sophos Firewall explica las consecuencias.

Restablecer de forma controlada el volumen de datos transferido

La opción de menú Reset data transfer count puede ayudar durante la prueba, pero se interpreta mal con frecuencia. Restablece el volumen de datos transferido a través de la regla; no es un contador de sesiones ni de coincidencias.

1. Abrir Rules and policies > Firewall rules.
2. Buscar la regla afectada y abrir el menú de tres puntos.
3. Seleccionar Reset data transfer count.
4. Provocar de nuevo el flujo de prueba definido.
5. Evaluar conjuntamente el volumen de datos, la Rule ID y Packet Capture.

Si el valor aumenta después de la prueba controlada, indica que se ha transferido tráfico mediante esta regla. Si no cambia, esto por sí solo no demuestra que la regla nunca haya coincidido. Para obtener una conclusión fiable, hay que comprobar la Rule ID real en Log Viewer y la ruta de los paquetes en Packet Capture. Este contador de datos no está disponible para la regla Default Drop con ID 0.

Leer correctamente Log Viewer, Policy Tester y Packet Capture

Las herramientas responden a preguntas diferentes:

• Log Viewer: ¿Qué sesión registrada, regla, regla NAT, acción y usuario se han detectado?
• Policy Tester: ¿Qué lógica de políticas se aplicaría a los valores introducidos?
• Packet Capture: ¿Qué paquetes llegan realmente, cómo los procesa el firewall y vuelven a salir?

Ninguna de las herramientas sustituye por completo a las demás. Si la simulación y el flujo real de paquetes se contradicen, los datos de log y de paquetes de la prueba reproducible tienen más peso.

Log Viewer: Rule ID y NAT Rule ID reales

En la regla de firewall debe estar activado Log firewall traffic. Además, en System services > Log settings debe estar habilitado el tipo de log adecuado para la visualización local, Sophos Central o syslog.

Para la prueba resultan útiles los filtros de los siguientes campos:

• Source IP y Destination IP
• Puerto o servicio
• Rule ID y Rule name
• NAT rule ID
• Action y User
• la hora de prueba anotada

La ausencia de una entrada todavía no demuestra que el firewall no haya visto nada. Las sesiones del firewall se registran, entre otros momentos, cuando la conexión termina con un evento Destroy. Si una conexión se interrumpe de forma abrupta, la entrada esperada puede faltar o aparecer más tarde. En ese caso, Packet Capture proporciona el resultado más directo. Los servicios y archivos de log correspondientes se describen en Solución de problemas de Sophos Firewall: servicios y logs.

Policy Tester: lógica de políticas sin un flujo real de paquetes

En Diagnostics > Tools > Policy tester se establecen deliberadamente la URL, el usuario, la hora, la Source IP y la Source zone. El protocolo y el puerto deben deducirse de la URL completa, por ejemplo https://app.example.net:8443/. Sin protocolo, la herramienta prueba HTTP; para HTTPS se utiliza de forma predeterminada el puerto 443, y un puerto diferente debe indicarse en la URL.

Policy Tester es útil, pero tiene límites claros:

• No genera un flujo real de paquetes y no comprueba ni el sistema de destino ni la ruta de retorno.
• Los resultados no reflejan las rutas SD-WAN.
• Las reglas con direcciones MAC en Source networks and devices no pueden coincidir.
• Los problemas del proveedor, el switch, el gateway y la pérdida de paquetes permanecen invisibles.

⚠️ En SFOS 22.0 GA Build 411, NC-177587 y NC-176083 podían causar resultados incorrectos de Policy Tester. El tráfico aparecía bloqueado o asignado a la regla equivocada aunque en realidad circulara correctamente. MR1 Build 490 contiene las correcciones documentadas. Si los resultados se contradicen, hay que comprobar primero la versión de firmware, Log Viewer y Packet Capture antes de modificar las reglas de producción.

Packet Capture: comprobar la ruta real de los paquetes

En Diagnostics > Packet capture, primero se establece un filtro de captura BPF limitado, por ejemplo a la Source IP, Destination IP y el puerto del flujo de prueba. Después se activa Trace On, se borra la lista y se provoca exactamente el flujo definido.

Un Packet Capture vacío solo es significativo cuando se cumplen estos requisitos:

1. Trace On está activo.
2. El filtro de captura BPF coincide con el destino real y no oculta el flujo.
3. El búfer no ha sobrescrito ya el tráfico de prueba relevante. Sin Wrap capture buffer once full, la grabación se detiene cuando se llena el búfer de 2048 KB y continúa con Clear. Con la opción Wrap activada, la grabación continúa y sobrescribe los paquetes más antiguos.

Un Display Filter adicional no cambia lo que se ha grabado, pero puede ocultar entradas existentes. Por ello, el filtro de captura y el Display Filter deben comprobarse por separado.

Los valores de estado significan lo siguiente:

• Incoming: El paquete se ha recibido en una interfaz.
• Forwarded: El firewall reenvía el paquete mediante una interfaz de salida.
• Consumed: El paquete está destinado al propio firewall o es utilizado por él.
• Generated: El propio firewall ha generado el paquete.
• Violation: Una infracción de política provoca el descarte; el campo Reason explica el motivo con más detalle.

La Rule ID, la NAT ID, Reason y las interfaces de entrada y salida siempre se leen conjuntamente. Consumed y Generated son resultados normales y no indican automáticamente un error.

⚠️ En SFOS 22.0 MR1 Build 490, NC-178387 puede mostrar los descartes de la regla predeterminada con ID 0 solo como Incoming. Faltan la entrada esperada Violation Firewall y la entrada en drppkt, aunque el firewall siga descartando el flujo. Para esta versión afectada resultan útiles Policy Tester o una regla de descarte con log colocada deliberadamente al final de la lista de reglas propia. La información actual de Known Issues no indica una versión corregida.

El procedimiento detallado de captura se encuentra en Utilizar Packet Capture en Sophos Firewall WebAdmin. Analizar paquetes descartados en Sophos Firewall trata los descartes y una regla final controlada.

Comprobar NAT, DNAT, el routing y la ruta de retorno

NAT no permite tráfico. Traduce direcciones o puertos para el tráfico que permite una regla de firewall. Por tanto, la Firewall Rule ID y la NAT Rule ID deben coincidir por separado.

Evaluar conjuntamente Firewall Rule ID y NAT Rule ID

• La Firewall Rule ID es correcta, la NAT Rule ID es incorrecta: Comprobar el orden de NAT, los campos Original y las reglas NAT más generales.
• La NAT Rule ID es correcta, la Firewall Rule ID es incorrecta: Comparar el orden del firewall, las zonas, el origen, el destino, el servicio y la planificación.
• Ambas ID son correctas, pero la conexión falla: Comprobar el routing, la ruta de retorno, el servidor de destino, el módulo de seguridad o la aplicación.
• No aparece ninguna NAT Rule ID aunque se espera NAT: Comprobar la dirección, Inbound/Outbound Interface y los criterios originales de la regla NAT.

En Rules and policies > NAT rules también gana la primera regla que coincide. Por ello, una regla SNAT o MASQ general puede ocultar una regla específica situada debajo. Además, las Linked NAT Rules solo se tienen en cuenta para el tráfico que coincide con su regla de firewall asociada; aun así, una regla NAT independiente anterior puede aplicarse primero.

Entender NAT en Sophos Firewall explica la lógica completa de las ID.

Entender DNAT desde la perspectiva anterior y posterior a NAT

Para el tráfico DNAT entrante se aplica una regla importante:

La regla de firewall utiliza la zona de destino después de NAT, pero como Destination Network utiliza la dirección a la que se accedió originalmente antes de NAT.

Ejemplo de redirección de puertos:

• El cliente externo se conecta a 198.51.100.10 mediante TCP 8888.
• La regla NAT traduce al servidor 10.10.50.20 de la zona DMZ y a TCP 4444.
• En la regla NAT, TCP 8888 es el Original service y TCP 4444 el Translated service (PAT).
• La regla de firewall utiliza WAN como Source zone, DMZ como Destination zone y 198.51.100.10 como Destination network.
• En el ejemplo PAT oficial de Sophos, la regla de firewall asociada contiene tanto el servicio original como el traducido.

La prueba externa sigue realizándose contra el puerto 8888; el servidor interno recibe la conexión en el puerto 4444. Si solo se considera uno de los dos puertos, la regla puede parecer correcta rápidamente aunque el matching de servicios y la traducción no encajen. La publicación completa se describe en Publicar un servidor mediante DNAT en Sophos Firewall.

Establecer una conexión nueva después de cambios de NAT

Sophos Firewall solo evalúa una regla NAT para el primer paquete de una conexión. Las sesiones existentes siguen utilizando la traducción anterior aunque la regla NAT se haya modificado entretanto.

Después de corregir NAT, hay que establecer una conexión nueva: finalizar la prueba en curso, cerrar la sesión existente del navegador o la aplicación y volver a iniciar el flujo. Una recarga dentro de la misma sesión TCP no demuestra de forma fiable la nueva configuración de NAT.

Investigar el routing solo después de confirmar el match

Si la Rule ID y la NAT Rule ID son correctas y Packet Capture muestra Forwarded, el matching de la regla está demostrado en principio. A continuación se comprueba:

• ruta estática o Default Route adecuada
• SD-WAN route y gateway activo
• interfaz de salida real
• ruta en el sistema de destino y en las redes remotas
• ruta de retorno simétrica mediante VPN, MPLS o WAN
• firewall local del servidor de destino

Policy Tester no refleja SD-WAN. Para la decisión real son determinantes la Gateway ID, la interfaz y la ruta de los paquetes. Ajustar la prioridad de routing en Sophos Firewall explica el orden de las rutas estáticas, SD-WAN y VPN.

Casos especiales después del primer resultado

Solo cuando se ha clasificado el flujo básico merece la pena profundizar en servicios locales, usuarios, resolución de nombres o módulos de seguridad.

Tráfico hacia el propio firewall: Device Access en lugar de una regla de firewall

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS y SNMP terminan en el firewall. Por ello, Packet Capture puede mostrar el estado Consumed. El acceso se controla en Administration > Device access y mediante Local Service ACL Exception Rules, no mediante una regla normal de tránsito.

Se deben comprobar la zona, la red de origen de confianza, el servicio permitido, la autorización del usuario y MFA. Proteger Sophos Firewall Device Access y Local Service ACL explica la interacción relevante para la seguridad; Resumen de los portales de Sophos Firewall clasifica las diferentes interfaces web.

Separar el inicio de sesión del usuario y User Matching

Un inicio de sesión correcto en VPN Portal, User Portal, Captive Portal o mediante Entra ID SSO solo confirma inicialmente la autenticación. Para que se aplique la regla de usuario prevista, el firewall también debe asignar el usuario al flujo de datos real y a su Source IP.

Resultados típicos:

• El campo User de Log Viewer está vacío: Comprobar STAS, AD SSO, Captive Portal, Entra ID SSO o Clientless User. Para una IP fija de dispositivo, configurar y probar Clientless Users muestra la asignación con la comprobación en Live Users y la prueba negativa.
• El usuario aparece, pero se aplica otra regla: Comparar la posición de la regla, la condición del grupo o una regla más general situada más arriba.
• Solo se ven afectados los usuarios VPN: Comprobar la zona VPN, el pool VPN, Source network y el matching de grupos.
• Solo se ven afectados usuarios concretos: Comparar UPN, dirección de correo electrónico, grupo de directorio importado y grupo de Sophos Firewall.

Para entornos AD locales son útiles Configurar STAS en Sophos Firewall y Añadir Active Directory a Sophos Firewall. Según la ruta de inicio de sesión de Entra, consulte Entra ID SSO para Sophos Connect y VPN Portal o Entra ID SSO para Captive Portal. Con un número muy elevado de usuarios detectados o Clientless Users, también puede ser relevante el límite de User ID de Sophos Firewall.

Comprobar DNS, FQDN, CDN e IPv6

Para el matching de reglas cuenta la IP de destino utilizada realmente, no solo el nombre de host introducido. La caché DNS, Split DNS, los servicios CDN, otro resolver, destinos API adicionales o IPv6 pueden dirigir el flujo a otra dirección.

El firewall resuelve por sí mismo los FQDN Hosts normales y actualiza la asignación según el TTL de DNS. Los FQDN comodín funcionan de otra forma: el firewall aprende las direcciones IP de los subdominios coincidentes a partir de las respuestas DNS observadas. Si el cliente utiliza un resolver externo, su tráfico DNS UDP en el puerto 53 debe atravesar el firewall. Si el firewall no puede ver la respuesta correspondiente, la IP del subdominio puede faltar en el objeto comodín y la regla puede no coincidir aunque el nombre parezca correcto.

Además, los FQDN Hosts no admiten resolución IPv6. Antes de ampliar un objeto, hay que comparar la respuesta DNS, la IP de destino y la versión IP con Log Viewer o Packet Capture. Los detalles sobre TTL, comodines y comportamiento de aprendizaje se encuentran en FQDN Hosts y FQDN comodín en Sophos Firewall. Para la resolución interna son útiles las DNS Request Routes; un entorno IPv6 activo necesita sus propias reglas adecuadas y un concepto de IPv6 definido.

Distinguir los módulos de seguridad y Traffic Shaping

Si la Firewall Rule ID, la NAT Rule ID y el routing son correctos, un módulo asignado a la regla puede afectar a la aplicación:

• Web Policy y Application Control
• SSL/TLS inspection rule y Decryption Profile
• IPS Policy y Malware Scan
• Zero-Day Protection
• Security Heartbeat

En cada prueba solo se aísla un módulo para el flujo concreto y durante un periodo breve. Una excepción permanece limitada al origen, el destino y el servicio; después se restablece la protección original o se documenta la excepción necesaria. Para problemas de HTTPS resulta útil un despliegue controlado de TLS Inspection.

En cambio, Traffic Shaping es una función QoS. Garantiza, prioriza o limita el ancho de banda y, por ello, puede provocar un throughput bajo, pérdida de paquetes cuando hay congestión o timeouts. No es lo mismo que la decisión de acceso Drop o Reject. Para un bloqueo real hay que comprobar el estado de Packet Capture, Reason y el módulo de seguridad responsable. En transferencias grandes o conexiones VPN también deben incluirse MTU y MSS en el análisis.

Probar y documentar los cambios de forma controlada

En problemas de reglas solo se debe modificar una variable por prueba:

1. Anotar el estado inicial con origen, destino, servicio, usuario, hora, Rule ID y NAT ID.
2. Modificar exactamente una posición de regla, un objeto, un servicio o un módulo.
3. En el caso de NAT, establecer una conexión nueva; de lo contrario, provocar de nuevo el mismo flujo de prueba.
4. Comparar Log Viewer y Packet Capture con los mismos filtros.
5. Documentar el éxito o el fracaso y solo entonces comprobar el siguiente cambio.

Las reglas temporales de Allow, Drop o excepción reciben un nombre comprensible, un Owner y una fecha de caducidad. De lo contrario, una ayuda de diagnóstico temporal puede permanecer rápidamente de forma permanente en el conjunto de reglas.

Si la conexión aún funcionaba ayer, también se deben comprobar los últimos cambios de configuración. Audit Trail Logs muestra quién ha modificado reglas u objetos. Config Studio ayuda a comparar configuraciones de mayor tamaño. Si el cambio procede de Sophos Central, también se comprueba la Central Firewall Task Queue.

Lista de comprobación para solucionar problemas de reglas

• Se ha definido un flujo de prueba concreto con origen, destino, servicio, usuario y hora.
• Se ha comprobado si se trata de tráfico de tránsito o de un servicio local del firewall.
• Se han controlado la posición de las reglas, las reglas automáticas y los filtros ocultos de la tabla.
• Se han comparado todos los campos de matching con el flujo real.
• El volumen de datos solo se ha utilizado como indicación y no como contador de coincidencias.
• Log Viewer muestra la Firewall Rule ID real y, si procede, la NAT Rule ID.
• El resultado de Policy Tester se ha contrastado con la versión de firmware y los datos reales de paquetes.
• Packet Capture se ejecuta con un filtro de captura adecuado y espacio libre en el búfer.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason e interfaces se han interpretado correctamente.
• En DNAT, se han comprobado la zona de destino después de NAT, Destination Network antes de NAT y ambos servicios PAT.
• Después de cambios de NAT se ha establecido una conexión nueva.
• Se han comprobado la respuesta DNS, la IP de destino, el comportamiento de aprendizaje de FQDN y la versión IP.
• El inicio de sesión del usuario y el User Matching del flujo de datos se han comprobado por separado.
• El routing, SD-WAN, el gateway y la ruta de retorno solo se han investigado después de confirmar el match de la regla.
• Los módulos de seguridad se han comprobado individualmente y Traffic Shaping como QoS.
• Cada cambio se ha documentado; las reglas de prueba tienen un Owner y una fecha de caducidad.

Preguntas frecuentes