Comprobar servicios y puertos salientes de Sophos Firewall
Sophos Firewall establece conexiones propias con Sophos y algunos servicios externos de plataforma. Las utiliza para descargar firmware y patterns, sincronizar licencias, conectar dispositivos RED, enviar informes a Sophos Central o abrir Support Access. Si delante del firewall hay otro router, proxy o filtro de egreso, pueden fallar funciones concretas aunque el tráfico normal de los clientes siga funcionando.
La distinción principal es que se trata de tráfico de sistema generado por el propio firewall. Una regla amplia LAN-to-WAN adicional en Sophos Firewall no corrige un filtro previo. Se necesita una regla saliente específica en el sistema upstream que realmente bloquea la conexión.
⚠️ Los nombres de destino son una lista cambiante del fabricante. El siguiente resumen corresponde a la documentación pública de SFOS 22 del 21 de agosto de 2026. Antes de crear una allowlist productiva debe revisarse de nuevo la página actual Default services de Sophos. Las direcciones IP fijas obtenidas mediante una única consulta DNS no sustituyen permanentemente a los FQDN y wildcards documentados.
Comprobación rápida cuando falla un servicio de Sophos
- Registrar la función afectada, la hora del error y la build actual de SFOS.
- Comprobar si el firewall resuelve por DNS el destino documentado y si la hora del sistema y la sincronización NTP son correctas.
- Buscar en el router o filtro de egreso upstream un bloqueo de la dirección WAN del firewall, el FQDN de destino y el puerto requerido.
- Permitir solo el grupo funcional que falta, no
*.sophos.com,Anyy todos los puertos de forma general. - Iniciar exactamente una nueva prueba y comparar por hora Packet Capture, el log upstream y el log de servicio SFOS correspondiente.
Una resolución DNS correcta solo demuestra que el nombre puede resolverse. Un handshake TCP correcto todavía no demuestra que la licencia, la actualización, el upload o el aprovisionamiento RED funcionen completamente. Después de cambiar la regla de red hay que probar de nuevo la función real.
Destinos y puertos necesarios para SFOS 22
La tabla resume los grupos más importantes. Para servicios regionales de Sophos Central se permite únicamente la región utilizada. Una empresa en Frankfurt, por ejemplo, no necesita automáticamente todos los destinos S3 de Oregon, Mumbai, Sydney y Tokio.
| Función | Destinos documentados | Puertos | Síntoma típico |
|---|---|---|---|
| Categorización web y reputación IP | 4.sophosxl.net | TCP 443 | Las categorías o la reputación no se evalúan con datos actuales. |
| Actualizaciones de firmware, patterns y clientes | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware o patterns se quedan bloqueados durante la comprobación o descarga. |
| Escáner antivirus adicional para appliances pequeños | oem.avdl.ctmail.com | TCP 80 | Fallan las actualizaciones antivirus adicionales. |
| Licencias | *.soa.sophos.com | TCP 443 | Falla la activación o sincronización de licencia. |
| Aprovisionamiento RED | *.astaro.com | TCP 3400, UDP 3410 | El dispositivo RED no se registra o no establece el túnel. |
| Security Heartbeat y Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, los hosts regionales *.upe.p.hmr.sophos.com documentados por Sophos y *.sophos.com para Central Firewall Management | TCP 80, 443; Central Firewall Management usa además TCP 22 | Registro, Heartbeat, Synchronized Application Control o gestión Central permanece offline. |
| Central Firewall Reporting | host regional tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com | TCP 443 | Los logs e informes no aparecen en Central. |
| Central Firewall Backup | host regional <region>-firewall-backup.s3.<region>.amazonaws.com; para UAE Sophos documenta *.s3.me-central-1.amazonaws.com | TCP 443 | Backup o restore de Central no alcanza el almacenamiento. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | Los archivos no se envían al sandbox o faltan resultados. |
| Support Access | *.apu.sophos.com | TCP 22 | No se puede establecer el túnel saliente de soporte. |
| NTP | pool.ntp.org | UDP 123 | La hora deriva; certificados, MFA, Kerberos o logs parecen incoherentes. |
| SAR, telemetría y comprobación DDNS | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443; la comprobación DDNS usa TCP 80 | No funciona Security Audit Report, telemetría o detección de la IP pública. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | Falla la ruta de datos ZTNA o la conexión con Sophos Central. |
Sophos también enumera hosts concretos de Heartbeat y Central. Estos valores pueden cambiar según región, operación de plataforma o cambios del fabricante. Por eso la tabla no se transforma en una lista IP estática.
Crear la allowlist de egreso de forma segura
La regla se crea en el dispositivo que realmente filtra el tráfico de sistema saliente. Puede ser un firewall previo, un router del proveedor o un firewall de red cloud. En ese sistema solo debe usarse como origen la dirección pública o traducida de Sophos Firewall. Como destinos se usan los FQDN necesarios y como servicios solo los puertos TCP o UDP documentados.
Tratar correctamente wildcards y direcciones IP dinámicas
Muchos servicios Sophos utilizan CDN, plataformas cloud o hosts distribuidos regionalmente. Las IP detrás de un FQDN pueden cambiar. Por tanto, un único nslookup, seguido de IP fijas y una allowlist sin cambios durante años no es fiable.
Si el filtro upstream admite reglas por FQDN o URL, se mantienen allí los nombres documentados por Sophos. Si el dispositivo solo filtra IP, hace falta un proceso documentado de resolución y actualización periódica. Permitir ampliamente todas las redes de AWS o Sophos no es un sustituto equivalente y aumenta innecesariamente la superficie autorizada.
Con *.sophos.com hay que ser especialmente cuidadoso: Sophos indica expresamente este wildcard amplio para Central Firewall Management. No debe extenderse automáticamente a otras funciones o puertos adicionales. RED, updates, sandbox, licencias y Support Access disponen de patrones de destino más estrechos.
No crear una regla WAN entrante
Estas conexiones se inician en el firewall y salen hacia internet. No se crea para ellas una regla DNAT o WAN-to-Local entrante. Tampoco debe añadirse por sospecha una excepción amplia de TLS Inspection, IPS o Web Filtering. Primero se comprueban DNS, ruta, bloqueo upstream y servicio concreto.
Support Access es especialmente fácil de interpretar mal: el firewall se conecta de forma saliente por TCP 22 a *.apu.sophos.com. El procedimiento seguro para activarlo y limitarlo en el tiempo se explica en Configurar Sophos Firewall Support Access.
Delimitar errores de forma sistemática
Comprobar DNS, ruta y puerto por separado
En Device Console se puede comprobar primero de forma no modificadora un destino documentado:
dnslookup host xg-up2date-firmwares.sophosupd.com
Después, un Packet Capture limitado muestra si el firewall inicia una conexión hacia la IP resuelta, qué interfaz WAN utiliza y si regresan respuestas. El capture se limita a la IP de destino y al puerto concretos. En paralelo se busca en el sistema upstream el mismo intervalo de tiempo, origen y destino.
El resultado se interpreta por capas:
- Sin respuesta DNS: comprobar servidor DNS, ruta al resolver y hora del sistema.
- El SYN sale del firewall, pero no vuelve respuesta: comprobar regla upstream, ruta del proveedor, NAT y retorno.
- TCP o UDP funciona, pero la función sigue fallando: comprobar el log de servicio correspondiente y el estado del producto; la conectividad por sí sola no es una prueba funcional completa.
- Solo un nodo HA muestra el error: revisar logs y capture en el nodo que procesó la conexión en el momento del error.
Utilizar el log de servicio SFOS adecuado
Para updates, u2d.log y up2date_av.log son buenos puntos de partida; para licencias, licensing.log; para RED, red.log; para sandbox, sandboxd.log; y para Sophos Central, entre otros, centralmanagement.log, sophos-central.log y los archivos fwcm-*.log. Para NTP corresponde ntpclient.log. La asignación completa y la exportación segura se describen en Encontrar e interpretar logs de servicio de Sophos Firewall.
En HA, los logs de servicio se guardan en el nodo que procesó la conexión. Una prueba correcta en el Primary actual no demuestra retrospectivamente que el otro nodo tuviera la misma conexión en el momento del error. Por eso se registran juntos hora, nodo, nombre de destino, IP resuelta y puerto.
Validar y operar el cambio
Después de añadir una regla de egreso, no se repite solamente la prueba de puerto. La función real debe mostrar un éxito visible: un pattern cambia de estado, la licencia sincroniza, RED conecta, Central recibe la tarea, aparece un informe o Support Access muestra una sesión activa.
Se mantiene el logging de la regla upstream y se revisa después de unos días. Se eliminan regiones no utilizadas, destinos antiguos y reglas de prueba temporalmente amplias. Antes de upgrades de firmware o de activar nuevas funciones Sophos, se compara otra vez la lista actual Default services para no descubrir la dependencia durante la ventana de mantenimiento.
Criterio de éxito: resolución DNS, establecimiento de conexión saliente, allowlist upstream correspondiente y prueba funcional tienen éxito en conjunto. Si falta una capa, el problema aún no está resuelto de forma limpia.