Crear y comprobar un custom gateway en Sophos Firewall

Un custom gateway describe en Sophos Firewall un next hop sobre una interfaz existente. El objeto resulta especialmente útil para rutas MPLS, RED, GRE y XFRM con dirección IP, porque puede tener su propio health check y su propia zona y utilizarse después en una ruta SD-WAN.

Respuesta rápida

El custom gateway se crea aquí:

Routing > Gateways > Add

Para una ruta MPLS a través de Port4, por ejemplo, se introducen estos valores:

• Name: MPLS_Zurich_GW
• Gateway IP: 192.0.2.2
• Interface: Port4-192.0.2.1
• Zone: MPLS
• Health check: On
• Monitoring condition: PING a 10.20.0.10

A continuación hay que seleccionar el gateway en una ruta SD-WAN adecuada y comprobarlo con la regla de firewall, la ruta de retorno, Log viewer y tráfico real. Un icono de estado verde solo confirma el health check, no el funcionamiento de toda la conexión.

⚠️ Un custom gateway no es un gateway WAN físico adicional. No aparece en Network > WAN link manager ni participa en el load balancing WAN, aunque se le asigne la zona WAN.

Distinguir custom gateway, ruta e interfaz

En una ruta funcional intervienen varios objetos con tareas diferentes:

• La interfaz conecta el firewall con la red de tránsito, por ejemplo Port4, RED o XFRM.
• La Gateway IP es el siguiente router accesible directamente en esa ruta.
• El custom gateway combina Gateway IP, interfaz, zona y un health check opcional en un objeto reutilizable.
• La ruta SD-WAN decide qué tráfico utiliza ese gateway.
• La regla de firewall permite las zonas, redes y servicios previstos.
• El extremo remoto necesita una ruta de retorno adecuada.

Una ruta estática normal puede contener directamente la Gateway IP y no necesita un objeto de gateway separado. Un custom gateway pasa a ser útil cuando SFOS debe supervisar la ruta, seleccionarla en una ruta SD-WAN o clasificarla mediante una zona de gateway.

En cambio, los gateways WAN físicos se crean automáticamente al configurar una interfaz WAN y se administran como Active o Backup en WAN link manager. Esta separación evita tratar por error una ruta MPLS interna o un túnel como una conexión a Internet.

Planificar la topología de ejemplo

El ejemplo continuo conecta una red de clientes con una red de servidores remota a través de un router MPLS:

• Red de clientes local: 10.10.0.0/24
• Cliente de prueba: 10.10.0.10
• Interfaz del firewall: Port4 con 192.0.2.1/30
• Router MPLS: 192.0.2.2
• Red remota: 10.20.0.0/24
• Host estable para monitorización y pruebas: 10.20.0.10
• Servicio de prueba: TCP 443
• Zona propia: MPLS de tipo LAN

192.0.2.0/24 es una red de documentación y no se utiliza en producción. En el entorno real hay que sustituir conjuntamente la IP de la interfaz y la Gateway IP por la red de tránsito real. La red remota y el host de monitorización deben estar realmente detrás de ese gateway. La zona MPLS se crea previamente en Network > Zones y se protege según el nivel de confianza de la ruta; zonas e interfaces en Sophos Firewall explica los fundamentos.

Antes del cambio se documentan la ruta existente, las reglas de firewall, la expectativa de NAT y la ruta de retorno. Un cambio remoto también requiere una copia de seguridad de la configuración, una ventana de mantenimiento y una vía de administración independiente.

Crear el custom gateway

Introducir los valores básicos del gateway

1. Abrir Routing > Gateways.
2. En IPv4, hacer clic en Add.
3. Introducir MPLS_Zurich_GW como Name. El nombre se puede elegir libremente, pero debe identificar el sitio y la ruta.
4. Introducir 192.0.2.2 como Gateway IP. Es el router MPLS accesible directamente, no la red de destino remota.
5. Seleccionar Port4-192.0.2.1 como Interface. La Gateway IP y la interfaz deben pertenecer a la misma ruta de tránsito accesible.
6. Seleccionar MPLS como Zone.

Sophos Firewall da prioridad a la zona del gateway sobre la zona de la interfaz. Sin embargo, solo la aplica al tráfico cuando el gateway está seleccionado en una SD-WAN policy route que coincida. Por tanto, con una ruta estática aislada hay que comprobar por separado el comportamiento de la zona. La zona VPN no se puede asignar a un custom gateway.

La zona del gateway no se aplica a las SD-WAN policy routes migradas desde SFOS 18.0 MR1 o versiones anteriores. En ese caso, el campo de zona visible por sí solo no demuestra que una regla existente sea correcta. Primero se comprueban la ruta, la coincidencia de zona y el tráfico real en una ventana de mantenimiento.

Elegir un health check que represente la ruta

Health check está desactivado de forma predeterminada. Para una ruta MPLS, RED o XFRM supervisada, se activa y se empieza con los valores predeterminados documentados:

• Interval: 60 segundos
• Time-out: 2 segundos
• Retries: 3
• Protocol: PING
• IP address: 10.20.0.10

El host de monitorización se encuentra deliberadamente detrás del gateway. Si solo se comprobara la Gateway IP directamente adyacente, el router podría responder aunque la ruta MPLS o el túnel posterior estuvieran interrumpidos. Para custom gateways sobre route-based VPN, RED y MPLS, Sophos indica expresamente un host detrás del gateway como destino de prueba.

Como alternativa se puede utilizar TCP con un puerto concreto. Resulta útil si la comprobación debe cubrir no solo la conectividad IP, sino también un servicio que responda de forma estable. Sin embargo, una comprobación TCP en el puerto 443 declara el gateway inactivo cuando falla el servicio web, aunque el routing siga funcionando. Por eso, el destino y el protocolo de prueba deben representar la señal de failover deseada.

Con varias Monitoring Conditions:

• AND: Deben cumplirse todas las condiciones. Es estricto, pero un solo destino caído puede provocar una conmutación innecesaria.
• OR: SFOS comprueba las condiciones de arriba abajo hasta que se cumple una. Reduce las falsas alarmas, pero puede ocultar una interrupción parcial.

No se reducen Interval, Time-out ni Retries sin datos. Primero se miden la latencia normal y las pérdidas breves de paquetes en la ruta real. Unos valores demasiado agresivos pueden hacer que el estado oscile entre activo e inactivo.

Después de guardar, Routing > Gateways muestra mediante un icono si el health check considera el gateway activo o inactivo.

Utilizar el gateway en el diseño de routing

Crear una ruta SD-WAN para el tráfico de ejemplo

Un objeto de gateway no reenvía tráfico por sí solo. Para el ejemplo se crea una ruta SD-WAN:

1. Abrir Routing > SD-WAN routes > IPv4 > Add.
2. Introducir Clients_to_Branch_MPLS como Name.
3. Seleccionar la interfaz interna como Incoming interface.
4. Establecer Source networks en 10.10.0.0/24.
5. Establecer Destination networks en 10.20.0.0/24.
6. Seleccionar inicialmente solo HTTPS, o TCP 443, en Services.
7. En Link selection settings, utilizar Primary and backup gateways.
8. Seleccionar MPLS_Zurich_GW como Primary gateway.
9. Añadir una ruta de backup real solo si está completamente configurada y probada.
10. Definir Route only through specified gateways de forma consciente: si se activa, SFOS descarta el tráfico cuando no hay ninguna de las rutas indicadas disponible; si se desactiva, puede tomar el relevo otra ruta SD-WAN o la ruta predeterminada.
11. Guardar la ruta y comprobar su posición. Gana la primera ruta SD-WAN que coincide.

Las redes y el servicio son valores propios del entorno. Una ruta amplia con Any como origen, destino y servicio puede abarcar mucho más tráfico del previsto. Para la primera prueba se mantiene una coincidencia estricta y solo se amplía de forma consciente después de una validación correcta.

Añadir la regla de firewall y la ruta de retorno

Para el flujo reenviado se crea una regla con logging desde la zona de origen de la red de clientes hacia la zona de gateway MPLS. El origen, el destino y el servicio coinciden con la ruta SD-WAN:

• Source zone: LAN
• Source network: 10.10.0.0/24
• Destination zone: MPLS
• Destination network: 10.20.0.0/24
• Services: HTTPS
• Log firewall traffic: activado

La zona del gateway no sustituye a una regla de firewall. A la inversa, una regla por sí sola tampoco impone la ruta MPLS. Ambas deben coincidir con la ruta SD-WAN. Crear y comprobar reglas de Sophos Firewall de forma segura explica el diseño general de reglas.

El router detrás de la red remota necesita una ruta de retorno hacia 10.10.0.0/24. En una interconexión normal entre sitios suele conservarse la IP original del cliente. Una regla MASQ amplia la ocultaría y puede aparentar que repara el retorno, pero empeorar el diseño de routing.

Distinguir XFRM, GRE y otras rutas de túnel

Con route-based IPsec y Any-to-Any, la interfaz XFRM recibe una IP de transferencia. Un custom gateway utiliza entonces la IP XFRM del peer como Gateway IP, el XFRM local como Interface y un host estable de la red remota como Monitoring Target. La configuración completa del túnel permanece en Configurar una VPN IPsec site-to-site.

Route-based IPsec con traffic selectors concretos funciona de otro modo: SFOS crea la ruta automáticamente y el XFRM no recibe una IP propia ni una ruta manual. No se debe trasladar sin comprobar una receta de gateway Any-to-Any a esta variante.

Una ruta GRE tampoco empieza por el objeto gateway. Primero se validan los endpoints externos, las IP del túnel y el funcionamiento de GRE siguiendo Configurar y probar un túnel GRE en Sophos Firewall. Si el diseño del proveedor requiere después una selección SD-WAN, el custom gateway utiliza la IP de túnel del peer como Gateway IP. La zona, el health check y el match de la regla deben corresponder al diseño concreto; la zona VPN sigue sin estar disponible para custom gateways.

Validar el gateway y el tráfico

Comprobar estado y uso

1. En Routing > Gateways, MPLS_Zurich_GW debe aparecer activo.
2. Actualizar Object usage y comprobar que la ruta SD-WAN prevista utiliza el gateway.
3. Volver a comprobar los criterios de coincidencia, la posición y el gateway de la ruta SD-WAN.
4. En Log viewer, revisar el módulo SD-WAN para eventos del gateway, health check y ruta.
5. Para un diagnóstico más profundo, utilizar dgd.log como log de Dead Gateway Detection; servicios y archivos de log de Sophos Firewall explica su contexto.

El estado activo del gateway solo demuestra que el host de monitorización responde bajo la condición elegida. Object Usage solo demuestra la referencia de configuración. Únicamente la siguiente prueba real confirma la ruta de datos.

Probar un flujo de tráfico real

1. Desde el cliente de prueba 10.10.0.10, iniciar una nueva conexión HTTPS a 10.20.0.10.

2. En Log viewer, comprobar origen, destino, servicio, Firewall Rule ID, una posible NAT Rule ID y el gateway utilizado.

3. Comprobar el Traffic Count de la ruta SD-WAN.

4. En Diagnostics > Packet capture, utilizar un filtro BPF estricto:

   host 10.20.0.10 and tcp port 443
   

5. Comprobar que las solicitudes salen por Port4 y que las respuestas regresan por la misma ruta prevista.

6. En el sistema de destino, comprobar la IP de origen real y la ruta de retorno.

El Policy tester no tiene en cuenta las rutas SD-WAN. Puede comprobar una coincidencia de regla de firewall, pero no el gateway utilizado realmente. Comprobar una regla de Sophos Firewall con Log Viewer y Packet Capture cubre la validación combinada.

Solo se realiza una prueba de failover con una ruta de backup validada por separado, en una ventana de mantenimiento y con una vía de administración independiente. No se elimina el gateway productivo referenciado como método de prueba. Después del fallo controlado de la ruta se vuelven a comprobar una nueva conexión, el estado del gateway, la IP de origen pública o privada, el retorno y el failback. No se presupone una transición sin interrupciones.

Delimitar los errores de forma sistemática

El gateway permanece inactivo

• La Gateway IP y la interfaz deben describir la misma ruta de tránsito accesible directamente.
• El host de monitorización debe estar realmente detrás del gateway y responder de forma fiable.
• Con PING, comprobar que ICMP está permitido en toda la ruta.
• Con TCP, comprobar el puerto correcto y un servicio que esté realmente activo.
• Utilizar Packet Capture para verificar que la prueba y la respuesta usan la interfaz prevista.
• Cambiar Interval, Time-out y Retries solo después de comprobar la ruta.

El gateway está activo, pero el tráfico de aplicación no funciona

• La ruta SD-WAN puede faltar, estar demasiado abajo o coincidir con otros valores de origen, destino o servicio.
• La Source zone y la zona del gateway en la regla de firewall deben coincidir con el flujo real.
• Comprobar por separado Route Precedence, NAT y la ruta de retorno.
• El host de monitorización puede ser accesible aunque falle otro host o servicio de destino.
• Un gateway XFRM activo no demuestra automáticamente que la SA IPsec, la regla de firewall y la ruta remota sean correctas.

La zona del gateway parece ignorarse

• Comprobar que el gateway está realmente seleccionado en la SD-WAN policy route que coincide.
• Con una ruta estática aislada, comprobar la zona de la interfaz y la regla de firewall que coincide realmente.
• La zona del gateway no se aplica a una ruta SD-WAN migrada desde SFOS 18.0 MR1 o versiones anteriores. No se debe ocultar la ruta con una regla amplia, sino modernizar de forma controlada la ruta y el modelo de zonas.
• La zona VPN no se puede seleccionar para un custom gateway. Una interfaz XFRM sigue siendo una interfaz VPN y requiere un diseño deliberado de reglas y routing.

El estado oscila innecesariamente entre activo e inactivo

• Comprobar la disponibilidad real y los límites de solicitudes del Probe Target.
• Medir la latencia normal y la pérdida de paquetes antes de cambiar valores.
• Con AND, un solo destino puede dejar inactivo todo el gateway.
• Con OR, un destino alternativo accesible puede ocultar una interrupción parcial.
• No utilizar intervalos o time-outs más cortos como solución general de estabilidad.

Revertir de forma segura y operar el gateway

Antes del rollback se documentan Object Usage, la ruta original y las reglas de firewall originales. Después:

1. Desactivar la nueva ruta SD-WAN o restaurar la ruta anterior.
2. Comprobar con una nueva conexión de cliente que la ruta original vuelve a funcionar.
3. Eliminar las reglas de firewall o NAT creadas solo para la prueba cuando ya no quede ninguna dependencia.
4. Actualizar Object Usage.
5. Eliminar el custom gateway únicamente cuando ninguna ruta ni ningún perfil lo utilice.

Para la operación se documentan el responsable, la Gateway IP, la interfaz, la zona, los Probe Targets, el protocolo, Interval, Time-out, Retries, las rutas que usan el gateway y la última prueba de failover. Después de cambios en MPLS, RED, XFRM, zonas, SD-WAN o el host de monitorización, se vuelven a probar tanto el estado como el tráfico real.

FAQ