Ir al contenido
Avanet

La regla de Sophos Firewall no se aplica: Verificar causas

Sophos Firewall

Cuando una regla de firewall no se aplica, rara vez es porque el firewall esté “roto”. Generalmente, una condición no coincide, una regla más general está por encima, NAT cambia la perspectiva del tráfico, la coincidencia de usuario no se cumple o el registro no está activado correctamente.

Esta lista de verificación ayuda a proceder de manera sistemática, en lugar de modificar reglas al azar.

Orientación

Empieza con un caso de prueba claro antes de cambiar reglas o funciones de seguridad.

¿Qué artículo es adecuado?

Los problemas de reglas se superponen rápidamente con NAT, enrutamiento, VPN, Device Access o características de seguridad. Para el análisis, primero debe estar claro qué nivel está afectado:

Esta separación es importante porque una regla de firewall no controla todo tipo de acceso. Los servicios locales del firewall, las decisiones de NAT, el enrutamiento y las características de seguridad tienen sus propios puntos de verificación.

Delimitación rápida

Al principio, no se deben mover reglas ni cambiar objetos inmediatamente. Primero, se delimita dónde se pierde el tráfico.

  • El contador de reglas permanece en 0: La posición de la regla, la zona, el origen, el destino, el servicio o el horario no coinciden
  • Log Viewer muestra otra regla: Una regla más general o generada automáticamente está más arriba
  • Log Viewer no muestra nada: Falta el registro o el tráfico no llega al firewall
  • Packet Capture no ve ningún paquete: El problema está antes del firewall: cliente, VLAN, switch, gateway, proveedor o grupo de seguridad en la nube
  • Packet Capture ve paquetes, pero no hay reenvío: La regla de firewall, NAT, enrutamiento o característica de seguridad bloquea
  • Packet Capture ve el reenvío, pero no hay respuesta: Verificar ruta de retorno, sistema de destino, NAT o firewall externo

Esta separación ahorra tiempo. Si el firewall no ve un paquete, ningún cambio en una regla de firewall ayudará. Si Log Viewer muestra otra Rule ID, el orden es más importante que la regla de destino afectada. Si el flujo de paquetes y la Rule ID son correctos, el análisis se desplaza a NAT, ruta de retorno o características de seguridad.

Definir claramente el caso de prueba

Una regla solo puede ser probada de manera significativa si el caso de prueba es claro. Declaraciones como “Internet no funciona” o “VPN no funciona” son demasiado amplias. Para la resolución de problemas, se necesita un flujo concreto.

Antes de la prueba, debe estar claro:

  • IP de origen: Cliente 10.10.20.35
  • Zona de origen: LAN, VPN, DMZ o zona personalizada
  • Usuario: usuario autenticado o sin coincidencia de usuario
  • Destino: IP del servidor, FQDN, IP pública u objeto WAN
  • Servicio: TCP 443, UDP 53, ICMP, servicio personalizado
  • Regla esperada: Nombre de la regla o Rule ID, si se conoce
  • Regla NAT esperada: NAT Rule ID o nombre de la regla, si NAT está involucrado
  • Hora de la prueba: hora exacta para Log Viewer y archivos de registro posteriores

Luego, se repite siempre la misma prueba. Si durante el análisis cambian la IP de origen, el destino, la resolución DNS o el puerto, ya no se está comparando el mismo caso.

Combinar correctamente las herramientas de análisis

Sophos Firewall ofrece varias herramientas que responden a diferentes preguntas. Ninguna de ellas es por sí sola una prueba completa.

  • Contador de reglas: ¿El nuevo tráfico de prueba alcanza la regla en principio? No muestra por qué una aplicación aún falla
  • Log Viewer: ¿Qué Rule ID, NAT Rule ID, acción, usuario o función de seguridad se registró? Depende del registro y del final de la sesión
  • Policy Tester: ¿Qué lógica de políticas se aplicaría a un flujo definido? No reemplaza un flujo de paquetes real y no representa completamente SD-WAN
  • Packet Capture: ¿Llegan los paquetes, se reenvían o se descartan? No explica cada capa de aplicación y necesita filtros estrechos
  • Registros de servicio: ¿Tiene un módulo como Web, IPS, autenticación o VPN un problema propio? Solo es útil cuando el servicio afectado está delimitado

Para un diagnóstico sólido, se combinan al menos Log Viewer y una prueba real. En caso de resultados contradictorios, Packet Capture suele ser el siguiente paso, ya que muestra si los paquetes realmente llegan y continúan.

Árbol de decisiones para la primera prueba

Para el primer análisis, a menudo basta con un breve árbol de decisiones. Evita trabajar inmediatamente en reglas, NAT y enrutamiento al mismo tiempo.

  • Packet Capture no ve ningún paquete: Verificar cliente, VLAN, switch, gateway, proveedor, grupo de seguridad en la nube o firewall previo
  • Packet Capture ve el paquete, Log Viewer permanece vacío: Verificar registro, tipo de registro, final de sesión y filtro BPF adecuado
  • Log Viewer muestra otra Rule ID: Comparar orden de reglas, zonas, origen, destino, servicio y horario
  • La Rule ID de firewall es correcta, la NAT Rule ID no lo es: Verificar orden de NAT y campos Original
  • Rule ID y NAT ID son correctas, pero no hay respuesta: Verificar ruta de retorno, sistema de destino, firewall local en el servidor o bloqueo externo
  • La regla solo no coincide con ciertos usuarios: Verificar coincidencia de usuario, grupo, autenticación y usuarios sin cliente

Esto mantiene el análisis controlado: primero se prueba si el tráfico llega al firewall. Luego se verifica qué regla y qué regla NAT realmente se aplican. Solo cuando estos dos puntos son correctos, vale la pena buscar en la ruta de retorno, características de seguridad o capa de aplicación.

Entender el matching de reglas

Sophos Firewall procesa las reglas en orden. Gana la primera regla adecuada.

Primer principio: La primera regla que coincide gana

Sophos Firewall procesa las reglas de firewall de arriba hacia abajo. Tan pronto como una regla coincide, las reglas posteriores ya no se verifican. El mismo principio básico se aplica también a las reglas NAT.

Importante:

  • La posición en la lista decide la evaluación.
  • La Rule ID es solo una referencia y no dice nada sobre el orden actual.
  • Los grupos de reglas ayudan con la visión general, pero no son una lógica de coincidencia propia.
  • Una regla general por encima puede “absorber” completamente una regla específica debajo.

Si una regla no se aplica, primero se verifica la posición.

Reglas de firewall de Sophos Firewall con orden de reglas marcado
La posición en la lista de reglas de firewall decide la evaluación. La primera regla que coincide gana, no la Rule ID más baja.

Restablecer contador de reglas

En caso de coincidencias poco claras, ayuda restablecer el contador de reglas.

  1. Abrir Rules and policies > Firewall rules.
  2. Buscar la regla afectada.
  3. Abrir el menú de tres puntos.
  4. Seleccionar Reset data transfer count.
  5. Reproducir el tráfico nuevamente.
  6. Controlar el contador después de la prueba.
Menú de tres puntos de Sophos Firewall con Reset data transfer count
Con Reset data transfer count se restablece el contador de reglas. Luego se puede ver claramente si el nuevo tráfico de prueba realmente cae en esta regla.

Si el contador no aumenta, la regla no coincide. Si aumenta, pero la aplicación aún no funciona, el problema probablemente esté en los perfiles de seguridad, NAT, enrutamiento, ruta de retorno o sistema de destino.

Verificar campos de coincidencia

Una regla de firewall solo coincide si todos los criterios relevantes coinciden.

  • Zonas de origen: Zona incorrecta, VLAN está en otra zona, tráfico VPN proviene de VPN
  • Redes y dispositivos de origen: Objeto incorrecto, IP incorrecta, grupo de hosts incompleto
  • Zonas de destino: Zona de destino incorrecta, especialmente en DNAT o VPN
  • Redes de destino: Confusión entre vista pre-NAT y post-NAT
  • Servicios: Falta de puerto, confusión TCP/UDP, aplicación utiliza puertos adicionales
  • Usuarios o grupos: Usuario no autenticado o grupo incorrecto
  • Horario: El horario no coincide actualmente
  • Exclusiones: El tráfico se excluye de la regla y se procesa más abajo
Regla de firewall de Sophos Firewall con Source, Destination y services
Una regla de firewall solo coincide si Source zone, Source networks and devices, Destination zones, Destination networks, Services y Schedule coinciden simultáneamente.

En el tráfico web, también se debe verificar si QUIC está activo. Si los navegadores envían tráfico a través de UDP 443, algunas expectativas de filtrado web y escaneo funcionan de manera diferente que con HTTPS clásico a través de TCP.

Más información: Sophos Firewall y el protocolo QUIC.

No pasar por alto DNS, FQDN e IPv6

Una regla puede parecer correcta y aún así no coincidir si el cliente alcanza un destino diferente al esperado. Esto ocurre frecuentemente con objetos FQDN, DNS dividido, servicios CDN, IPv6 o aplicaciones que utilizan múltiples destinos en paralelo.

Antes de cambiar reglas, se debe verificar:

  • ¿Qué IP realmente resuelve el cliente?: La caché DNS, DNS dividido u otro resolvedor pueden proporcionar una dirección diferente a la esperada.
  • ¿Es IPv4 o IPv6?: Las reglas IPv4 no coinciden con el tráfico IPv6. Si los clientes prefieren IPv6, se debe verificar la parte IPv6 por separado.
  • ¿Se utiliza un host FQDN en el firewall?: El firewall debe resolver el FQDN y conocer la IP de destino actual. Los servicios CDN o en la nube pueden proporcionar múltiples IPs cambiantes.
  • ¿La aplicación utiliza destinos adicionales?: Inicio de sesión, API, actualizaciones, telemetría o rutas de medios pueden utilizar dominios y puertos diferentes a la aplicación principal.
  • ¿Un cliente interno utiliza el nombre público de un servicio interno?: Entonces, DNS dividido, NAT de loopback o una resolución pública incorrecta son posibles causas.

Para la resolución de problemas, es crucial no solo anotar el nombre del host, sino comparar la IP de destino realmente utilizada en Log Viewer o Packet Capture. Si una regla apunta a un objeto FQDN o de host específico, pero el cliente utiliza una IP diferente, la regla no coincidirá.

En resoluciones de nombres internas, ayudan las rutas de solicitud DNS limpias. El procedimiento está en Configurar rutas de solicitud DNS en Sophos Firewall. Si IPv6 está activo en el entorno, también se debe verificar si IPv6 está planificado conscientemente y si la política adecuada está presente. Los fundamentos están en Configurar delegación de prefijos IPv6 en Sophos Firewall.

Un caso especial frecuente son los objetos FQDN. Si los clientes prefieren IPv6, pero una regla solo usa objetos IPv4 o un host FQDN con resolución IPv4, el flujo IPv6 real no coincidirá. La regla parece correcta, pero no procesa el tráfico que realmente circula. En estos casos se deben comprobar por separado la respuesta DNS, la versión IP y la policy.

El tráfico hacia el propio firewall es un caso especial

No todo acceso a un Sophos Firewall se controla mediante reglas de firewall normales. Si el cliente debe alcanzar el propio firewall, por ejemplo, WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS o SNMP, Device Access y Local service ACL son decisivos.

Ejemplos típicos:

  • WebAdmin desde LAN o WAN: Device Access, Local service ACL, MFA, permiso de administrador
  • VPN Portal o User Portal: Device Access, configuración del portal, permiso de usuario
  • SSH al firewall: Device Access, Local service ACL, derechos de administrador, red de origen
  • Conexión SSL VPN o IPsec: Device Access para la zona adecuada, configuración VPN, autenticación
  • DNS al firewall: Device Access, configuración DNS, ruta de solicitud
  • SNMP al firewall: Device Access, configuración SNMP, fuente de monitoreo

Si una regla de firewall no se aplica para dicho tráfico, a menudo no es un error de la regla. El tráfico termina en el firewall y se trata como un servicio local. Para el endurecimiento de estos servicios, Asegurar el acceso a Sophos Firewall: Configurar correctamente Device Access es el artículo central. Para los portales, también es adecuado Visión general de los portales de Sophos.

Comprobar NAT, DNAT e ID

En tráfico DNAT, las reglas de firewall y NAT deben leerse juntas.

Leer correctamente DNAT

En DNAT, la perspectiva en las reglas de firewall es especialmente importante. Como regla general, se puede recordar:

Las reglas de firewall para tráfico DNAT utilizan la zona de destino después de NAT, pero la IP de destino antes de NAT.

Ejemplo:

  • Un cliente externo se conecta a la IP WAN del firewall.
  • NAT traduce a un servidor interno en la DMZ.
  • La regla de firewall utiliza como zona de destino la zona del servidor interno, por ejemplo, DMZ.
  • La red de destino sigue siendo la IP pública o el objeto WAN al que el cliente se dirigió.

Si esta combinación es incorrecta, la regla NAT puede parecer correcta, pero la regla de firewall no coincidirá.

Más información: Publicar servidor mediante DNAT en Sophos Firewall.

Verificar reglas NAT

NAT no permite tráfico. NAT solo traduce. Siempre se necesita una regla de firewall adecuada adicional.

En Rules and policies > NAT rules se debe verificar:

  • ¿Está la regla NAT adecuada por encima de reglas NAT más generales?
  • ¿Está la regla activa?
  • ¿Coinciden la fuente original, el destino y el servicio?
  • ¿Coinciden la fuente traducida, el destino y el servicio?
  • ¿Se utiliza MASQ o una IP SNAT fija?
  • ¿Hay una Linked NAT Rule que se aplica inesperadamente?
  • ¿Hay una regla SNAT genérica que coincide antes que una regla más específica?

Sophos recomienda para entornos simples generalmente reglas NAT independientes, en lugar de crear una Linked NAT Rule por cada regla de firewall.

Más información: Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Leer juntas la Firewall Rule ID y la NAT Rule ID

Cuando NAT está involucrado, la pregunta “¿Qué regla de firewall se aplica?” no es suficiente. Una conexión puede alcanzar la Rule ID de firewall esperada, pero aún así pasar por una NAT Rule ID incorrecta. Por el contrario, una regla NAT puede parecer correcta, mientras que una regla de firewall más general por encima ya procesa el tráfico.

Para la prueba, se debe anotar de antemano:

  • Rule ID de firewall esperada: Muestra si la regla de firewall correcta permite o bloquea el tráfico
  • NAT Rule ID esperada: Muestra si la regla SNAT, DNAT, MASQ o PAT correcta traduce
  • IDs reales en Log Viewer: Demuestra si el firewall procesa el flujo como se planeó
  • IDs en Packet Capture: Ayuda si Log Viewer parece incompleto o la ruta de retorno no está clara

La interpretación es relativamente simple, pero ahorra mucho tiempo de búsqueda:

  • La Rule ID de firewall es correcta, la NAT Rule ID es incorrecta: Verificar orden de NAT, campos Original y reglas NAT más generales
  • La NAT Rule ID es correcta, la Rule ID de firewall es incorrecta: Verificar orden de reglas de firewall, zonas, origen, destino y servicio
  • Ambas IDs son correctas, pero la conexión falla: Verificar ruta de retorno, servidor de destino, característica de seguridad o aplicación
  • No se ve ninguna NAT Rule ID, aunque se espera NAT: Verificar flujo de prueba, criterios NAT, dirección y registro nuevamente

Es importante no reconstruir inmediatamente ambos conjuntos de reglas al mismo tiempo. Primero se decide si el problema está en la coincidencia de firewall o en la coincidencia de NAT. Solo después se debe cambiar una posición de regla concreta, un objeto o un campo. La evaluación más detallada de NAT está en la sección Leer correctamente la Firewall Rule ID y la NAT Rule ID.

Comprobar usuarios, routing y funciones de seguridad

User Matching, routing, NAT, logging y perfiles de seguridad pueden afectar a si una regla aplica.

Verificar coincidencia de usuario y autenticación

Las reglas con coincidencia de usuario o grupo a menudo parecen correctas, pero solo se aplican si el firewall puede realmente asignar el usuario al tráfico en ese momento.

A verificar:

  • ¿Es visible el usuario en Log Viewer?
  • ¿El tráfico proviene del dispositivo esperado o de otro cliente?
  • ¿Está el usuario en el grupo de firewall correcto?
  • ¿Funciona AD SSO, STAS, Captive Portal, RADIUS o Entra ID SSO?
  • ¿Hay una regla sin coincidencia de usuario por encima de la regla de usuario planificada?
  • ¿Hay usuarios sin cliente que se tratan de manera diferente?
  • ¿MFA o acceso al portal son exitosos, pero la regla de firewall para el tráfico de usuario real es incorrecta?

En el acceso remoto, se debe separar el problema del usuario del problema de VPN. Un usuario puede iniciar sesión con éxito, pero aún así no alcanzar una aplicación interna si el pool de VPN, la regla de firewall, NAT o el enrutamiento no coinciden. Para fundamentos de AD, es adecuado Agregar Active Directory en Sophos Firewall, para escenarios de acceso remoto basados en Entra Microsoft Entra ID SSO para Sophos Connect y VPN Portal. Si el usuario se registra a través de Captive Portal con Entra ID SSO, es adecuado Configurar Microsoft Entra ID SSO para Sophos Firewall Captive Portal.

Separar inicio de sesión de usuario y coincidencia de regla

Un inicio de sesión exitoso en el VPN Portal, User Portal, Captive Portal o a través de Microsoft Entra ID SSO no prueba que la regla de usuario planificada coincida con el tráfico real. El inicio de sesión solo confirma la autenticación. Luego, el firewall debe unir correctamente al usuario, la IP de origen, el grupo y el flujo de tráfico.

Para el análisis, se debe verificar por separado:

  • El usuario inicia sesión, el contador de reglas permanece en 0: Verificar pool de VPN, zona de origen, red de origen, condición de grupo o posición de regla
  • El campo de usuario en Log Viewer está vacío: Verificar STAS, Captive Portal, AD SSO, Entra ID SSO o usuarios sin cliente
  • El usuario es visible, pero se aplica la regla incorrecta: Verificar orden de reglas, filtro de grupos o regla más general por encima
  • Solo los usuarios de VPN están afectados: Verificar zona VPN, pool de VPN, configuración SSL/IPsec y perfil de Sophos Connect
  • Solo algunos usuarios están afectados: Comparar UPN, dirección de correo electrónico, grupo importado y grupo de firewall

En entornos locales de AD, ayudan STAS y Agregar Active Directory en Sophos Firewall. En configuraciones basadas en Entra, se debe verificar según la ruta de inicio de sesión Microsoft Entra ID SSO para Sophos Connect y VPN Portal o Entra ID SSO para Captive Portal. Si hay muchos usuarios o usuarios sin cliente involucrados, también puede ser relevante el Límite de ID de usuario de Sophos Firewall.

Verificar enrutamiento y SD-WAN

Si la regla coincide, pero la conexión no funciona, el enrutamiento puede ser el problema.

Se debe verificar:

  • ¿Existe una ruta predeterminada adecuada?
  • ¿Existe una ruta estática?
  • ¿Se aplica una ruta SD-WAN?
  • ¿Está activo el gateway?
  • ¿Existen rutas de retorno en el sistema de destino o en la red remota?
  • ¿Es simétrica la ruta de retorno?
  • ¿El tráfico pasa por VPN, MPLS u otra interfaz diferente a la esperada?

Importante: El Policy Tester no representa completamente el enrutamiento SD-WAN. Es muy útil para decisiones de políticas de firewall, SSL/TLS y web, pero no reemplaza una prueba de flujo de paquetes real.

Más información: Ajustar prioridad de enrutamiento en Sophos Firewall.

Activar registro

Sin registros, la resolución de problemas se vuelve tediosa. Se deben verificar dos lugares:

  1. En la regla de firewall, debe estar activado Log firewall traffic.
  2. En System services > Log settings, el tipo de registro adecuado debe estar activado localmente, para Sophos Central o para Syslog.

El Log Viewer generalmente muestra sesiones de firewall cuando el firewall termina una conexión y recibe un evento Destroy. Si una conexión a Internet simplemente se interrumpe, puede que no todas las sesiones aparezcan como se espera.

El Log Viewer se abre en la parte superior derecha de la consola WebAdmin. Los filtros útiles son:

  • IP de origen
  • IP de destino
  • Puerto o servicio
  • Rule ID
  • Nombre de la regla
  • Acción
  • Usuario
  • NAT rule ID
Log Viewer de Sophos Firewall con Rule ID y NAT rule ID
En Log Viewer se puede ver qué Rule ID y NAT rule ID procesaron el tráfico. Esto es a menudo más rápido que buscar solo por nombre de regla o dirección IP.

Más información: Resolución de problemas en Sophos Firewall: Servicios y registros.

Usar Packet Capture

Si Log Viewer y el contador de reglas no son suficientes, se utiliza Diagnostics > Packet capture.

La pregunta más importante es si el paquete llega, se reenvía o ya se queda en el firewall.

Packet Capture de Sophos Firewall con filtro BPF, NAT ID y Rule ID
Packet Capture muestra si los paquetes llegan, por qué interfaz pasan y qué NAT ID o Rule ID es visible. El filtro BPF mantiene la salida pequeña y legible.
  • No llega ningún paquete: El problema está antes del firewall: cliente, switch, VLAN, gateway, proveedor, grupo de seguridad en la nube
  • El paquete entra, pero no sale: Verificar regla de firewall, NAT, enrutamiento o característica de seguridad
  • El paquete sale, pero no hay respuesta: Verificar ruta de retorno, sistema de destino, NAT o bloqueo externo
  • El paquete se muestra con Violation: Política o característica de seguridad bloquea
  • El paquete muestra NAT ID y Rule ID: Comparar coincidencias de regla y NAT específicamente

Más información: Usar la herramienta Packet Capture en WebAdmin.

No cambiar varias cosas a la vez

En problemas de reglas, es tentador ajustar simultáneamente posición, servicio, NAT, política web y enrutamiento. A veces esto resuelve el acceso a corto plazo, pero hace que la causa sea difícil de rastrear más tarde.

Es mejor un enfoque paso a paso:

  1. Anotar el estado inicial: Rule ID, NAT ID, origen, destino, servicio, hora.
  2. Realizar exactamente un cambio.
  3. Repetir la prueba con la misma IP de origen y el mismo destino.
  4. Comparar nuevamente Log Viewer y Packet Capture.
  5. Documentar el resultado.
  6. Solo después considerar el siguiente cambio.

Para reglas productivas, también debe estar claro si un cambio es permanente o solo una regla de prueba. Las reglas temporales deben tener un propietario y una fecha de vencimiento, de lo contrario, a menudo permanecen en el conjunto de reglas durante años.

Verificar características de seguridad individualmente

Si la regla coincide, pero la aplicación no funciona, un perfil de protección puede estar interviniendo:

  • Política web
  • Regla de inspección SSL/TLS
  • Perfil de descifrado
  • Política IPS
  • Control de aplicaciones
  • Escaneo de malware
  • Protección contra amenazas de día cero
  • Security Heartbeat
  • Modelado de tráfico

Para las pruebas, no se puede desactivar todo de manera permanente. Es mejor: verificar brevemente de manera específica, observar Log Viewer y luego solucionar la causa de manera adecuada. En la inspección TLS, ayuda el artículo Implementar gradualmente la inspección TLS en Sophos Firewall.

Para reglas productivas, no se deben considerar las características de seguridad como un bloque general. Es mejor delimitar un módulo tras otro:

  • Se bloquea una categoría web o URL: Verificar política web, categoría, excepción y Log Viewer
  • La aplicación se reconoce incorrectamente: Verificar control de aplicaciones y registro IPS
  • La página HTTPS solo carga sin inspección: Verificar regla de inspección SSL/TLS, distribución de CA, perfil de descifrado y excepciones
  • La conexión se interrumpe con grandes datos: Verificar MTU/MSS, ruta VPN, fragmentación y Packet Capture
  • Coincidencia en IPS o protección contra amenazas de día cero: Evaluar firma, política, sistema de destino y riesgo de falso positivo
  • Solo algunos usuarios están afectados: Verificar coincidencia de usuario, Security Heartbeat, grupo y autenticación

Si se elimina un perfil de protección para una prueba, el cambio debe estar estrechamente limitado: solo la fuente afectada, solo el destino concreto, solo durante el período de prueba. Luego, se debe restaurar la protección original o documentar una excepción específica.

Comprobar el historial de cambios

Si una regla funcionaba ayer y hoy ya no funciona, no se debe revisar solo el contenido actual de la regla. A menudo se ha cambiado poco antes un objeto, la posición de una regla, una regla NAT, un grupo, un servicio o una policy de Central.

Comprobaciones prácticas:

  • ¿Se modificó la propia regla de firewall?: Audit Trail, Config Studio, descripción de la regla
  • ¿Se cambió un objeto utilizado?: Hosts and services, Audit Trail, Config Studio
  • ¿Se movió la posición de la regla?: Lista de reglas de firewall, Audit Trail
  • ¿Se aplicó una policy desde Central?: Sophos Central Task Queue y vista local del firewall
  • ¿Se cambió una regla NAT o una ruta SD-WAN?: Reglas NAT, routing, Audit Trail, Packet Capture

Para la trazabilidad son útiles Comprobar Audit Trail Logs de Sophos Firewall y Usar Sophos Firewall Config Studio. Si el cambio viene de Sophos Central, compruebe también la Sophos Central Firewall Management Task Queue.

Proceso práctico y causas típicas

La mayoría de problemas de matching se acotan rápido con una secuencia fija de troubleshooting.

Causas comunes

  • El contador de reglas permanece en 0: Posición de la regla, zona de origen, zona de destino o servicio incorrecto
  • El registro muestra otra regla: Una regla más general está por encima
  • No se ve ningún registro: El registro no está activo o el tráfico no llega al firewall
  • DNS funciona, web no: Verificar servicio, política web, inspección TLS o QUIC
  • El nombre de host coincide, pero la IP de destino es diferente: Verificar DNS, objeto FQDN, DNS dividido, CDN o IPv6
  • HTTPS no se escanea: No hay una regla de inspección SSL/TLS adecuada o la CA no está distribuida
  • DNAT no funciona: La regla de firewall utiliza zona de destino o red de destino incorrecta
  • El tráfico VPN no coincide: Verificar zona VPN, ruta, interfaz de túnel o contexto XFRM
  • Solo algunos usuarios están afectados: Verificar coincidencia de usuario, grupo, SSO, Captive Portal o Heartbeat

Procedimiento práctico

  1. Anotar el problema con IP de origen, destino, puerto, usuario y hora.
  2. Verificar posición de la regla.
  3. Restablecer contador de reglas.
  4. Reproducir la prueba.
  5. Filtrar Log Viewer con IP de origen y IP de destino.
  6. Verificar regla NAT y enrutamiento.
  7. Iniciar Packet Capture con filtro estrecho.
  8. Verificar características de seguridad solo de manera específica.
  9. Documentar el cambio.

Para un flujo de prueba combinado, ver Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.

Lista de verificación para resolución de problemas de reglas

  • Caso de prueba concreto definido con origen, destino, servicio, usuario y hora.
  • Posición de la regla verificada y contador de reglas restablecido para la prueba.
  • Log Viewer muestra la Rule ID esperada o una regla diferente comprensible.
  • Resolución DNS, IP de destino real y versión IP se compararon con el caso de prueba.
  • En DNAT, la zona de destino después de NAT y la red de destino antes de NAT están configuradas correctamente.
  • NAT Rule ID verificada si NAT está involucrado.
  • El tráfico hacia el propio firewall se separó del tráfico a través del firewall.
  • La coincidencia de usuario solo se evaluó si el usuario es visible en Log Viewer.
  • En reglas de usuario, se evaluaron por separado el inicio de sesión, la asignación de usuario y la decisión de regla real.
  • Se verificaron enrutamiento, SD-WAN, gateway y ruta de retorno.
  • Packet Capture muestra Incoming, Forwarded, Violation o falta de respuesta de manera comprensible.
  • Las características de seguridad se verificaron individualmente y no se desactivaron permanentemente de manera general.
  • Los cambios de prueba están documentados y las reglas temporales tienen propietario y fecha de vencimiento.

FAQ

¿Por qué no se aplica una regla de Sophos Firewall?

Generalmente, al menos un criterio de coincidencia no coincide: posición de la regla, zona de origen, zona de destino, objeto de origen, objeto de destino, servicio, horario, coincidencia de usuario o contexto NAT. Primero se debe verificar Log Viewer, Rule ID y Packet Capture.

¿Por qué Log Viewer muestra una regla diferente a la esperada?

Probablemente, una regla más general está más arriba o el tráfico se ve diferente desde la perspectiva del firewall de lo esperado. La posición de la regla, las zonas, NAT y los campos de origen/destino son entonces más importantes que el nombre de la regla.

¿Por qué no se ve ningún registro?

O bien Log firewall traffic no está activo en la regla, el tipo de registro adecuado está desactivado o el tráfico no llega al firewall. Packet Capture ayuda a distinguir si el paquete llega en absoluto.

¿Las reglas de firewall también se aplican a WebAdmin, SSH o VPN Portal?

No como en el tráfico de paso normal. Los accesos a servicios locales del firewall se controlan mediante Device Access y Local Service ACL. Las reglas de firewall normales son responsables del tráfico a través del firewall.

¿Por qué no funciona DNAT aunque la regla NAT es correcta?

A menudo, la regla de firewall adecuada está mal construida. En DNAT, la regla de firewall utiliza la zona de destino después de NAT, pero la red de destino antes de NAT. Además, deben coincidir el orden de NAT, el registro y la ruta de retorno.

¿Es el Policy Tester una prueba para el tráfico real?

No. El Policy Tester es útil para la lógica de políticas, pero no es una prueba de flujo de paquetes real. El enrutamiento, SD-WAN, la ruta de retorno, el comportamiento del proveedor y los sistemas de destino deben verificarse con Log Viewer y Packet Capture.

¿Por qué no se aplica una regla de usuario aunque el inicio de sesión VPN funciona?

El inicio de sesión VPN solo prueba que la autenticación funciona. Para la regla de firewall, también deben coincidir la zona de origen, el pool de VPN, la asignación de usuario, el grupo, el servicio, el destino y la posición de la regla. En Log Viewer se debe verificar si el usuario es realmente visible en el tráfico afectado y qué Rule ID procesa el flujo.

¿Por qué no coincide una regla con destino FQDN?

Frecuentemente, el cliente utiliza una IP de destino diferente a la esperada. Las causas son caché DNS, DNS dividido, direcciones CDN, otro resolvedor o IPv6. En Log Viewer o Packet Capture se debe comparar la IP de destino realmente utilizada con el objeto FQDN o de host de la regla.