Sophos Firewall como relé NTP vía NAT

Si los dispositivos internos deben usar la IP de la puerta de enlace como destino NTP, Sophos Firewall puede reenviar sus solicitudes mediante NAT a un servidor horario. El ajuste de Administration > Time, en cambio, solo sincroniza el reloj del firewall; no proporciona un servicio de servidor NTP a los clientes.

La solución documentada por Sophos es un relé NTP vía NAT. Los dispositivos envían NTP a la IP del firewall; Sophos Firewall traduce el origen y el destino y reenvía los paquetes a un servidor horario real externo o interno. El firewall no se convierte en la fuente de tiempo. Por separado, actúa como cliente NTP para sincronizar su propio reloj.

Esto es particularmente útil si los dispositivos están configurados de forma fija con la IP de la puerta de enlace, si se ha reemplazado un entorno UTM anterior o si se quieren controlar de forma centralizada los objetivos NTP. Para nuevos diseños de DHCP, suele ser más limpio distribuir el servidor horario correcto directamente a través de la opción DHCP. Los conceptos básicos se pueden encontrar en Configurar opciones DHCP en Sophos Firewall.

⚠️ Importante: Sophos Firewall no debe proporcionar un servicio NTP abierto a Internet. Las zonas de origen, las redes de origen, los servidores de destino y las reglas de firewall deben restringirse deliberadamente. WAN como Source Zone suele ser incorrecto para este patrón.

¿Qué variante es adecuada?

NTP a través de NAT es un patrón pragmático, pero no siempre es la mejor arquitectura.

Dos variantes son importantes para este artículo:

• Variante A: Los dispositivos internos utilizan la IP del firewall como servidor NTP, el firewall reenvía a un servidor NTP externo.
• Variante B: Los dispositivos internos utilizan la IP del firewall como servidor NTP, el firewall reenvía a un servidor NTP interno. Además, se debe permitir que el servidor NTP interno se sincronice externamente.

La segunda variante tiene, por tanto, dos rutas de datos independientes. Si la sincronización externa del servidor horario interno ya está permitida y traducida correctamente, se comprueba y reutiliza el par de reglas existente; no es necesario añadir reglas idénticas.

Requisitos

Antes de la configuración, estos puntos deben quedar claros:

• ¿Qué redes internas pueden utilizar NTP?
• ¿Qué dirección IP utilizan los clientes como destino NTP, por ejemplo la IP de la puerta de enlace?
• ¿Qué servidor NTP real se debe utilizar?
• ¿Se debe utilizar un servidor horario interno o un servicio externo como time.google.com o pool.ntp.org?
• ¿Puede el firewall resolver de forma fiable los destinos FQDN mediante DNS?
• ¿Está sincronizada correctamente la hora del propio sistema del cortafuegos?

Un ejemplo IPv4 coherente permite aclarar la correspondencia:

• net_Internet-LAN: 10.10.11.0/24, entrada de los clientes por Port2 en la zona de la red interna de clientes.
• host_internal-firewall-ip: host 10.10.11.1, la IP del firewall que usan estos clientes.
• host_Google-NTP: FQDN time.google.com para la variante A y, si procede, como fuente horaria externa del servidor interno.
• NTP_Server_Internal: host 192.168.20.10, accesible por Port3 en la zona DMZ, para la variante B.

Estas direcciones privadas, nombres de objetos e interfaces son ejemplos y se sustituyen por los valores reales. Solo se seleccionan las redes que necesitan el relé y sus interfaces de entrada reales; para IOT_NET, si hace falta, se añade una regla propia con restricciones igualmente precisas. Los objetos de red y host se crean en Hosts and services > IP host. Si se utilizan varias IP de puerta de enlace, las redes de origen, las entradas y las direcciones de destino correspondientes deben ser coherentes entre sí. Antes de realizar cambios, se documentan las reglas NAT y de firewall existentes, su orden y la fuente horaria de los clientes; el servidor horario real debe ser accesible y aceptar solicitudes desde la dirección del firewall utilizada por MASQ.

La hora correcta es importante para funciones críticas como MFA, autenticación WAF, certificados, registros, VPN y correlación SIEM. Si el firewall tiene una hora incorrecta, primero se debe verificar la hora del sistema antes de redirigir el NTP de los clientes.

Los pasos siguientes se basan en la documentación oficial de Sophos Firewall 22.0 (fuentes comprobadas el 17.10.2026). No se ha realizado una prueba en un dispositivo para esta guía. Los ajustes NTP del firewall no se pueden sincronizar desde Sophos Fusion (antes Sophos Central); deben configurarse en WebAdmin, mediante CLI o mediante API. Los pasos de NAT y firewall siguientes usan WebAdmin.

Los ejemplos usan intencionadamente una configuración IPv4, con IP version: IPv4 seleccionado al crear el host. En entornos IPv6 o dual-stack, este patrón no debe copiarse sin más. Primero hay que aclarar si los clientes realmente necesitan NTP sobre IPv6, qué funciones de firewall y NAT se aplican en la versión SFOS usada y si DHCPv6, Router Advertisements o un servidor horario interno directo son la solución más limpia.

Referencia rápida

Para administradores experimentados, la lógica resumida es sencilla: los clientes envían UDP 123 a la IP del firewall o de la puerta de enlace. Una regla DNAT cambia el destino al servidor NTP real, una regla de firewall permite exactamente ese tráfico y Log Viewer confirma después la Firewall Rule ID y la NAT Rule ID.

Servidor NTP externo: una regla DNAT reenvía NTP desde la IP del firewall al objeto FQDN o host del servidor externo. Una regla de firewall permite NTP desde los orígenes internos afectados hacia WAN. Sophos deja Original destination en Any en su ejemplo general. Para este relé mediante la IP de la puerta de enlace, el campo se limita a la IP exacta del firewall usada por los clientes; así no se redirigen consultas directas destinadas a otros servidores.

Servidor NTP interno: se necesitan dos movimientos. Primero, el servidor NTP interno debe poder sincronizarse hacia fuera mediante SNAT/MASQ. Segundo, una regla DNAT reenvía las solicitudes de clientes desde la IP del firewall al servidor NTP interno. Ambos pares de reglas deben comprobarse por separado en Log Viewer.

Para la primera implementación, la posición de la regla debe ponerse deliberadamente alta, normalmente Top o por encima de reglas LAN-to-WAN y NAT generales. Después se puede integrar la posición en el concepto de reglas existente, siempre que Log Viewer y Packet Capture sigan mostrando que la regla esperada coincide primero.

host_internal-firewall-ip contiene la dirección IP LAN interna de Sophos Firewall, aquí 10.10.11.1. Los clientes usan esa dirección como servidor NTP. Sustituye el valor por la IP LAN interna del firewall de tu red de clientes y adapta net_Internet-LAN (10.10.11.0/24), la interfaz de entrada y la zona de origen. Aquí la entrada es Port2 en la zona de la red interna de clientes; Port1 pertenece a la DMZ y no se usa. Ambas reglas utilizan el servicio predefinido NTP; no hace falta un servicio adicional exclusivo de UDP. Este ejemplo de configuración no demuestra una prueba real satisfactoria. Selecciona la zona asignada a la red de clientes en tu entorno; «zona LAN interna» es una descripción, no un nombre de zona obligatorio.

En Hosts and services > IP host > Add, crea los dos objetos IPv4 siguientes y guarda cada uno con Save. Reutiliza objetos existentes adecuados cuando estén disponibles.

Variante A: Usar servidor NTP externo

Esta variante es adecuada si los clientes deben utilizar la IP del firewall como servidor NTP y no hay un servidor horario interno propio. El firewall traduce la solicitud NTP a un servidor horario externo, por ejemplo time.google.com o un servidor horario de proveedor elegido deliberadamente.

Google Public NTP (time.google.com) utiliza leap smear. No lo mezcles con fuentes de tiempo sin leap smear.

Crear host FQDN para el servidor NTP externo

La ruta del menú es:

Hosts and services > FQDN host

Procedimiento:

1. Se selecciona Add.
2. Se asigna Name, por ejemplo host_Google-NTP.
3. Se introduce el servidor NTP externo en FQDN, por ejemplo time.google.com.
4. Se guarda.

Si se utiliza un servidor horario interno o externo con una IP fija en lugar de FQDN, un objeto host normal puede tener más sentido. Es importante que el objetivo pueda reconocerse claramente más adelante en la regla NAT y el firewall.

Crear regla NAT para el servidor NTP externo

La regla NAT garantiza que las solicitudes NTP a la IP del firewall se reescriban en el servidor horario externo. La ruta del menú es:

Rules and policies > NAT rules

Procedimiento:

1. Se selecciona Add NAT rule > New NAT rule.
2. Se configura Rule name, por ejemplo DNAT_Client_NTP_to_External.
3. Se establece Rule position en Top o se coloca por encima de las reglas amplias NAT.
4. Se configura Original source en la red interna afectada, en este ejemplo net_Internet-LAN (10.10.11.0/24).
5. Se configura Original destination en host_internal-firewall-ip, en este ejemplo 10.10.11.1.
6. Para Original service, se elimina Any y se selecciona NTP.
7. Para Translated source (SNAT) se selecciona MASQ.
8. Para Translated destination (DNAT), se selecciona el host FQDN o el host del servidor NTP externo.
9. En Inbound interface, se elimina Any y se selecciona la entrada real de los clientes, en este ejemplo Port2. Sophos también permite Any, pero la selección concreta evita coincidencias en entradas no previstas.
10. Se mantiene Translated service (PAT) en Original para conservar UDP 123. Outbound interface permanece en Any en esta regla DNAT; la ruta al destino traducido determina la salida.
11. Se guarda.

⚠️ No dejar Original destination abierta: si Original destination no se limita a la IP del firewall o de la puerta de enlace, la regla puede actuar de forma mucho más amplia según el resto del diseño NAT. En ese caso puede reenviar no solo tráfico hacia la IP del firewall, sino también redirigir de forma transparente tráfico NTP de la red. Para un relé controlado, la regla solo debe coincidir cuando los clientes usan realmente la IP del firewall o de la puerta de enlace como destino NTP.

En la vista detallada se debe prestar especial atención a cuatro puntos: el destino original debe ser realmente la IP del firewall o de la puerta de enlace, el servicio debe permanecer limitado a NTP o UDP 123, el destino traducido debe apuntar al servidor horario planificado y SNAT debe coincidir con la ruta de regreso.

Si los conceptos básicos de NAT o los campos DNAT no están claros, Comprender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT resulta útil. También explica por qué NAT no sustituye el permiso otorgado por una regla de firewall.

Permitir regla de firewall para NTP externo

Después de crear la regla NAT, se necesita una regla de firewall adecuada. Esto permite el tráfico NTP desde las redes internas al servidor de destino. La ruta del menú es:

Rules and policies > Firewall rules

Procedimiento:

1. Se selecciona Add firewall rule > New firewall rule.
2. Se configura Rule name, por ejemplo NTP_LAN_to_Google.
3. Se establece Rule position en Top o se coloca por encima de reglas LAN-to-WAN generales si estas coincidirían antes.
4. Se activa Log firewall traffic.
5. Se configura Source zones en las zonas internas, por ejemplo la zona LAN interna, DMZ o una zona IoT. WAN y Any son incorrectos para este patrón.
6. Se configura Source networks and devices en las redes o dispositivos afectados. No se utiliza Any de forma general si solo determinadas redes deben usar NTP.
7. Se establece Destination zones en WAN.
8. Se establece Destination networks en un objeto host IPv4 para la IP del firewall o de la puerta de enlace que los clientes usan como destino NTP, por ejemplo host_internal-firewall-ip. Si no existe, se crea en Hosts and services > IP host > Add, con Type: IP y esa dirección IP exacta. Debe coincidir con Original destination de la regla DNAT de clientes, no con el host NTP externo.
9. Se establece Services en NTP.
10. Se establece Action en Accept.
11. Se guarda.

En ejemplos oficiales o simplificados se ve a veces Any en Source networks and devices. En un laboratorio es cómodo, pero en producción rara vez es la mejor opción. Es más limpio usar un objeto de red concreto como net_Internet-LAN, IOT_NET o un pequeño grupo de hosts, para que quede claro qué dispositivos pueden usar este reenvío NTP.

En DNAT entrante, Sophos determina primero el destino traducido. Destination zones usa su zona, aquí WAN; Destination networks, en cambio, usa el destino original, aquí la IP del firewall o de la puerta de enlace. El servidor horario real se mantiene solo en Translated destination (DNAT). El ejemplo general NTP de Sophos omite Destination networks; esta distinción sigue sus ejemplos explícitos de DNAT y loopback. Después de un cambio, se inicia una nueva sesión NTP desde el cliente: las sesiones existentes no se vuelven a evaluar con las reglas NAT modificadas. Antes de dar por válida la configuración, se comprueban Firewall Rule ID, NAT Rule ID y la ruta de los paquetes entrantes y reenviados como se indica en la sección de pruebas; la configuración por sí sola no demuestra una sincronización correcta.

Registrar el tráfico de esta regla resulta útil durante la puesta en marcha. Después de la prueba, se debería poder ver en Log Viewer de qué red de cliente proviene la solicitud, qué Firewall Rule ID se utilizó y si el NAT Rule ID esperado también es visible. Si no aparece ningún ID de regla o aparece una regla incorrecta, el orden o la coincidencia de la regla es más importante que la configuración NTP en sí.

Para estructura de reglas, secuencia, Services y registro, también sirve Comprender y configurar correctamente las reglas Sophos Firewall.

Variante B: Usar servidor NTP interno

Esta variante es adecuada si un controlador de dominio interno, un servidor horario Linux u otro sistema interno va a ser la fuente horaria para los clientes, pero los clientes continúan usando la IP del firewall como servidor NTP.

Aquí se comprueban dos rutas de datos con sus respectivos pares de reglas; se pueden reutilizar las reglas existentes que sean adecuadas:

Crear host para el servidor NTP interno

La ruta del menú es:

Hosts and services > IP host

Procedimiento:

1. Se selecciona Add.
2. Se establece Name, por ejemplo NTP_Server_Internal.
3. Se establece IP version en IPv4 si se utiliza IPv4.
4. Se establece Type en IP.
5. Se introduce IP address del servidor NTP interno, en este ejemplo 192.168.20.10.
6. Se guarda.

Par de reglas 1: el servidor NTP interno se sincroniza externamente

Primero, el servidor NTP interno debe poder comunicarse con un servidor horario externo si aún no se sincroniza por otra vía. Su fuente horaria ascendente configurada debe ser el servidor horario real, no la IP de la puerta de enlace utilizada como relé. Las solicitudes solo pueden volver al propio servidor si su tráfico también coincide con una regla DNAT de relé cuyo destino traducido es ese servidor. En el ejemplo anterior, la red de origen y la interfaz de entrada impiden esa coincidencia con la regla DNAT de los clientes; la IP de la puerta de enlace elegida incorrectamente puede entonces no proporcionar una hora utilizable.

Regla NAT:

1. Se abre Rules and policies > NAT rules.
2. Se selecciona Add NAT rule > New NAT rule.
3. Se configura Rule name, por ejemplo SNAT_Internal_NTP_to_WAN.
4. Se establece Rule position en Top o se coloca de forma adecuada por encima de reglas NAT amplias.
5. En Original source, se selecciona el objeto host NTP_Server_Internal creado anteriormente.
6. Se configura Original destination en la fuente horaria externa prevista, en este ejemplo host_Google-NTP.
7. Para Original service, se elimina Any y se selecciona NTP.
8. Para Translated source (SNAT), se selecciona MASQ; Translated destination (DNAT) y Translated service (PAT) permanecen en Original.
9. Se configura Inbound interface en la entrada del servidor interno, en este ejemplo Port3; se limita Outbound interface a la interfaz WAN realmente utilizada. Si hay varias conexiones WAN, se deben incluir todas las salidas previstas.
10. Se guarda.

Regla del cortafuegos:

1. Se abre Rules and policies > Firewall rules.
2. Se selecciona Add firewall rule > New firewall rule.
3. Se configura Rule name, por ejemplo Internal_NTP_to_WAN.
4. Se activa Log firewall traffic.
5. Se configura Source zones en la zona del servidor NTP interno, en este ejemplo DMZ.
6. Se establece Source networks and devices en NTP_Server_Internal.
7. Se establece Destination zones en WAN.
8. Se configura Destination networks en la misma fuente horaria externa que en la regla SNAT, en este ejemplo host_Google-NTP. Aquí no hay DNAT; el destino original y el destino real son idénticos.
9. Se establece Services en NTP y Action en Accept.
10. Se coloca la regla por encima de las reglas generales que coincidirían antes y se guarda.

Par de reglas 2: guiar a los clientes al servidor NTP interno a través de la IP del firewall

Luego se crea el reenvío real: los clientes envían NTP a la IP del firewall, el firewall reenvía al servidor NTP interno.

Regla NAT:

1. Se abre Rules and policies > NAT rules.
2. Se selecciona Add NAT rule > New NAT rule.
3. Se configura Rule name, por ejemplo DNAT_Client_NTP_to_Internal.
4. Se establece Rule position en Top o se coloca por encima de reglas NAT generales.
5. Se configura Original source en las redes internas de los clientes afectados, en este ejemplo net_Internet-LAN.
6. Se configura Original destination en la IP del firewall o de la puerta de enlace que los clientes usan como destino NTP, en este ejemplo host_internal-firewall-ip.
7. Para Original service, se elimina Any y se selecciona NTP.
8. Para Translated source (SNAT), se selecciona MASQ.
9. Para Translated destination (DNAT) se selecciona NTP_Server_Internal.
10. En Inbound interface, se seleccionan las interfaces internas de los clientes afectados, en este ejemplo Port2.
11. Se mantiene Translated service (PAT) en Original; Outbound interface permanece en Any en esta regla DNAT.
12. Se guarda.

Aquí también Original destination es decisivo: la regla solo debe traducir solicitudes NTP dirigidas a la IP del firewall o de la puerta de enlace. Si este campo queda demasiado amplio, el firewall también puede capturar solicitudes NTP que los clientes querían enviar directamente a otro servidor horario.

Regla del cortafuegos:

1. Se abre Rules and policies > Firewall rules.
2. Se selecciona Add firewall rule > New firewall rule.
3. Se configura Rule name, por ejemplo LAN_to_Internal_NTP.
4. Se activa Log firewall traffic.
5. Se establece Source zones en las zonas de cliente interno. Se evitan WAN y Any.
6. Se configura Source networks and devices en las redes de clientes afectadas.
7. Se configura Destination zones en la zona del servidor NTP interno, por ejemplo la zona LAN interna o DMZ.
8. Se establece Destination networks en el objeto host IPv4 de la IP del firewall o de la puerta de enlace a la que se dirige originalmente el cliente, por ejemplo host_internal-firewall-ip, igual que Original destination de la regla DNAT de clientes. No se selecciona NTP_Server_Internal; ese host se mantiene en Translated destination (DNAT).
9. Se establece Services en NTP.
10. Se establece Action en Accept. Se coloca la regla por encima de las reglas generales que coincidirían antes y se guarda.

También aquí, Destination zones corresponde al destino interno traducido, mientras que Destination networks contiene la IP original del firewall o de la puerta de enlace. Se comprueba por separado una nueva sesión del cliente, los identificadores de las reglas y la ruta de los paquetes para este par de reglas. MASQ asegura el retorno por el firewall, pero oculta al servidor NTP la IP original del cliente. Si el servidor necesita esa IP para registros o acceso, se planifica un acceso directo con una ruta de retorno adecuada.

Si el servidor NTP interno es un controlador de dominio, se debe delimitar el alcance con especial cuidado. No todas las redes de clientes tienen que llegar directamente a todos los controladores de dominio. Se puede permitir NTP sin abrir accesos de controlador de dominio igualmente amplios.

Operaciones, seguridad y pruebas

Clasificar IPS y características de seguridad

NTP es técnicamente un pequeño servicio UDP, pero UDP 123 también se vuelve relevante en la práctica en caso de abuso, mala configuración u objetivos externos no deseados. Si hay disponible una licencia Network Protection, puede tener sentido una política IPS adecuada en la regla del firewall.

Para NTP, antes de añadir funciones de seguridad, es más importante definir un alcance limitado:

• Source Zone solo interno: evita que el firewall actúe como un relé público NTP.
• Redes de origen concretas: limita NTP a clientes, servidores o dispositivos que realmente necesitan este reenvío.
• Servidor de destino definido: limita el tráfico que coincide con esta regla de relé al servidor horario definido y facilita la interpretación de los registros.
• Servicio solo NTP: evita una regla UDP demasiado amplia.
• Activar registro: muestra en Log Viewer si Firewall Rule ID y NAT Rule ID funcionan como se esperaba.

Por lo tanto, IPS debe verse como un control adicional, no como un reemplazo de una regla limpia. Si la regla NTP solo permite unas pocas redes internas a un servidor horario definido, la ganancia de seguridad más importante ya se logra a través del alcance y la trazabilidad. Cuando están involucradas una gran cantidad de redes, dispositivos poco claros o áreas de IoT/OT, una política de IPS dirigida se vuelve más interesante.

Si se utiliza IPS en esta regla NTP, la política IPS asignada debe incluir expresamente firmas relacionadas con NTP (IPS patterns). Así, la protección adicional se centra en ataques contra servicios NTP; describir una política como adecuada en general no sustituye la selección de esas firmas.

⚠️ IPS requiere una licencia Network Protection adecuada. Si IPS está habilitado en una regla muy utilizada, se deben monitorear los registros y el rendimiento. Para el reenvío NTP simple, un alcance limpio es más importante que una combinación de funciones de seguridad innecesariamente amplia.

Si se utiliza una política IPS dedicada para este propósito, no se debe copiar de forma generalizada a todas las redes internas. Tiene más sentido tener una pequeña regla con un origen claro, un destino NTP definido, registro activo y control posterior en el Log Viewer.

Otras características de seguridad deben tratarse deliberadamente con cautela con NTP. Para este sencillo servicio UDP, Web Filtering, TLS Inspection, Application Control o Malware Scan normalmente no ayudan con la función NTP real. Si dichos perfiles están activos en una regla colectiva, se debe verificar si NTP estaría mejor ubicado en su propia regla pequeña.

Distribuir NTP correctamente con DHCP

Si los clientes reciben su configuración de red a través de DHCP, se debe comprobar si es necesario un reenvío NAT. Para muchos entornos, es más limpio distribuir el servidor NTP deseado directamente a través de DHCP.

Si hay un controlador de dominio o un servidor horario central, la opción DHCP 42 puede apuntar directamente a este servidor, siempre que el cliente en cuestión admita y utilice realmente esta opción. Los miembros del dominio pueden seguir la jerarquía horaria de su dominio; por ello, se comprueba en el cliente cuál es la fuente horaria efectiva. NAT es particularmente útil si los dispositivos ya usan la IP de la puerta de enlace o son difíciles de reconfigurar. Para las opciones especiales de DHCP, Configurar opciones DHCP en Sophos Firewall es un mejor comienzo.

Configurar el firewall por separado como cliente NTP

El reenvío NTP de los clientes no equivale a configurar la hora del sistema de Sophos Firewall. En Administration > Time, SFOS 22.0 ofrece tres ajustes:

Configuración actual sin cambios del reloj del firewall: Use pre-defined NTP server, Europe/Zurich. Es independiente del relay de clientes y no demuestra sincronización correcta; no se usaron Sync now ni Apply.

• Use predefined NTP server es el valor predeterminado. El firewall usa NTPv3 y 0.sophos.pool.ntp.org.
• Use custom NTP server admite direcciones IPv4, IPv6 o DNS; se comprueban hasta diez servidores en el orden mostrado.
• Do not use NTP server permite ajustar manualmente la fecha y la hora y no se recomienda para el funcionamiento habitual.

Tras elegir un servidor, se puede seleccionar Sync now y, después, Apply. Current time solo se actualiza tras Sync now al recargar WebAdmin. La zona horaria se ajusta en la misma página según la ubicación.

⚠️ Impacto en VPN: según Sophos, al cambiar los servidores NTP se restablecen todas las conexiones IPsec. El cambio se realiza en una ventana de mantenimiento.

Se comprueban por separado ambos flujos:

• Hora del sistema del firewall: relevante para Log Viewer, certificados, MFA, VPN, autenticación WAF, informes, Syslog y análisis de soporte.
• NTP de los clientes mediante NAT: los dispositivos en la red interna reciben la hora a través de la IP de la puerta de enlace o una dirección NTP redirigida.

Si el propio firewall tiene una hora o zona horaria incorrecta, las entradas de registro pueden ser difíciles de correlacionar, las comprobaciones de certificados pueden fallar o la autenticación basada en tiempo como TOTP/MFA puede causar problemas. En ese caso, primero se deben corregir la hora del sistema del firewall y su propio acceso NTP. Solo entonces tiene sentido validar el cliente NTP a través de NAT.

Para entornos SIEM o Syslog, este punto es particularmente importante: el firewall puede enrutar correctamente el tráfico NTP y aun así enviar marcas de tiempo incorrectas a un SIEM si su propia hora o zona horaria es incorrecta.

Para el reenvío de registros, Enviar Sophos Firewall Syslog a SIEM es adecuado. Para problemas de MFA, también se debe incluir Activar MFA para WebAdmin, VPN Portal y Remote Access de Sophos Firewall.

Probar NTP y aislar los errores

Después de guardar, no solo se debe comprobar si la regla existe. Lo decisivo es si un cliente puede sincronizar realmente la hora por NTP y si coinciden las reglas NAT y de firewall esperadas.

La prueba comienza igual para ambas variantes: un cliente de la red afectada utiliza la IP del firewall o de la puerta de enlace como servidor NTP. A continuación se activa una sincronización horaria o se realiza una breve espera hasta que el cliente envía NTP.

Se abre Log viewer en la parte superior derecha de WebAdmin. En el módulo Firewall, Add filter permite filtrar por regla, IP o puerto; también se puede buscar 123, la IP del cliente o el nombre de la regla en la búsqueda de texto libre. Los registros de sesión no siempre aparecen de inmediato: el firewall registra la sesión en el evento interno Destroy. Con UDP puede ser necesario esperar al final de la sesión; UDP no tiene el cierre de conexión de TCP.

Con la variante A debería ser visible:

• El cliente proviene de la red interna esperada.
• Coincide la regla de firewall NTP para NTP externo.
• Coincide la regla DNAT hacia la fuente horaria externa.
• El objetivo es el servidor NTP externo planificado.

Se deben comprobar dos cosas para la variante B:

• El servidor NTP interno puede enviar NTP externamente.
• Los clientes se enrutan a través de DNAT desde la IP del firewall al servidor NTP interno.

Si Log Viewer no muestra claramente qué regla coincide, se utiliza Diagnostics > Packet capture. En Configure, la expresión BPF port 123 limita la captura a NTP. Tras activar Packet capture, el paquete entrante debe mostrar la IP del cliente, la IP del firewall y UDP 123; el reenviado muestra el destino traducido. NAT ID y Rule ID deben corresponder a las reglas creadas. Incoming y Forwarded confirman la ruta; Consumed indica tráfico para el propio firewall, y Violation con Reason explica un descarte.

Un reenvío correcto no confirma por sí solo la sincronización horaria. Además, el estado NTP del cliente debe mostrar una respuesta válida y un estado sincronizado; en la variante B también se comprueba el estado de sincronización del servidor horario interno. En la captura de paquetes se espera una respuesta del servidor horario real y, en el retorno al cliente, la IP de la puerta de enlace consultada como dirección de origen. Si falta la respuesta, primero se comprueban la accesibilidad, la ruta de retorno y el control de acceso del servidor horario para la dirección MASQ.

Como prueba negativa, un cliente de una red interna no autorizada envía una nueva solicitud NTP a la IP de la puerta de enlace. La regla DNAT de clientes creada y el permiso asociado no deben coincidir con esta solicitud. Si aun así se reenvía, se busca una regla NAT o de firewall anterior o más amplia. Una solicitud de un cliente autorizado dirigida directamente a otra dirección NTP tampoco debe ser redirigida por esta regla DNAT de la IP de la puerta de enlace. La política de firewall restante determina si se permite o bloquea el NTP directo; este relé por sí solo no impone una fuente horaria central para todo el tráfico.

Si no hay registros visibles, puede que el cliente no esté enviando la solicitud, la regla del firewall no se registra o el tráfico toma una ruta diferente. Probar la regla de firewall con Log Viewer, Policy Test y Packet Capture es adecuada para la verificación sistemática.

Para problemas NTP específicos del firewall, el registro del cliente NTP también es relevante. La descripción general de los registros se encuentra en Solución de problemas Sophos Firewall: Services y registros.

Comprobación final breve

Antes de finalizar la puesta en producción, cinco puntos deben ser correctos:

1. Los clientes realmente usan la IP del firewall o de la puerta de enlace como servidor NTP.
2. Las reglas NTP solo permiten las redes de origen internas previstas.
3. Los Firewall Rule ID y NAT Rule ID esperados son visibles en el Log Viewer.
4. La hora del sistema de firewall es correcta por separado.
5. Después de DHCP, VLAN, NAT o cambios de reglas, NTP se probará nuevamente.

Errores típicos

• WAN permitido como Source Zone: El firewall puede actuar involuntariamente como un relé NTP abierto. Se limitan las zonas de origen a zonas internas.
• Any para origen y destino: La regla es difícil de controlar. Se definen redes de origen y servidores de destino concretos.
• Regla NAT presente, pero no hay regla de firewall: El tráfico se traduce pero no se permite. Se comprueban Rule ID y NAT ID en Log Viewer.
• Regla de firewall sin registro: El análisis de errores se vuelve innecesariamente difícil. Se activa Log firewall traffic al menos durante la prueba.
• El destino FQDN no se resuelve: No se alcanza el destino DNAT. Se comprueba la resolución DNS del firewall.
• El cliente utiliza otro servidor NTP: La regla nunca se cumple. Se comprueba la configuración del cliente o la opción DHCP.
• El servidor horario no responde: El cliente permanece sin sincronizar. Se comprueban el servidor de destino, el enrutamiento y UDP 123.

Reversión

Si el relé causa problemas, primero se desactiva la nueva regla DNAT de clientes y se inicia una nueva prueba NTP; después se desactiva la regla de firewall asociada. En la variante B, las reglas SNAT y de firewall hacia WAN del servidor interno solo se eliminan si este ya no las necesita para su propia sincronización. Se eliminan las reglas y los objetos host creados exclusivamente para este relé únicamente después de confirmar que ya no tienen coincidencias ni dependencias. Finalmente, se configura en los clientes un servidor NTP directamente accesible, por ejemplo mediante la opción DHCP 42; de lo contrario, perderán su fuente de tiempo.

Preguntas frecuentes