Configurar y probar el failover WAN en Sophos Firewall

Una segunda conexión a Internet no se convierte automáticamente en una conexión de reserva en Sophos Firewall. Un gateway WAN recién creado es Active de forma predeterminada y participa, por tanto, en el load balancing. Para un diseño clásico primary/backup, hay que cambiar el segundo gateway a Backup en WAN link manager.

El procedimiento rápido para una conexión principal y otra de reserva es el siguiente:

Configurar por completo ambas interfaces WAN en Network > Interfaces y probarlas por separado.
En Network > WAN link manager, definir el gateway principal como Active y el de reserva como Backup.
En el gateway de reserva, seleccionar Activate this gateway: If active gateway fails: ANY.
Configurar Failover rules fiables para ambos gateways.
Probar el failover y el failback —es decir, el retorno a la conexión principal— con tráfico real de DNS, HTTPS y aplicaciones.

Este failover sencillo de la ruta predeterminada a Internet no requiere una ruta SD-WAN propia. SD-WAN es necesario cuando un tráfico determinado debe utilizar rutas específicas o cuando la selección de ruta debe basarse en latencia, jitter y pérdida de paquetes.

Entender correctamente Active, Backup y load balancing

El tipo de gateway determina si una conexión participa normalmente en el tráfico de Internet:

Active: Si hay varios gateways activos disponibles, el firewall distribuye las sesiones nuevas según los pesos configurados.
Backup: El gateway solo asume el tráfico cuando se cumple su condición de activación.

Al menos un gateway WAN debe permanecer Active. Si todos los gateways están marcados únicamente como Backup, falta la ruta WAN predeterminada normal y, en particular, el tráfico generado por el propio firewall no puede reenviarse.

El Weight no representa el ancho de banda. En el modo weighted round-robin, una proporción de 2 a 1 significa que el firewall asigna dos sesiones nuevas al primer gateway y la siguiente al segundo. Una sola descarga no se reparte entre ambas conexiones y el volumen de datos transferido puede diferir considerablemente de esta proporción.

De forma predeterminada, Sophos Firewall utiliza Session Persistence. Esto no solo mantiene una conexión existente en el mismo enlace WAN: según el factor de persistencia, también puede asignar al mismo enlace otras sesiones de la misma source IP. El método actual puede consultarse después de iniciar sesión en Option 4: Device Console mediante un comando de solo lectura:

show routing wan-load-balancing

El comando no modifica nada. Indica si están activos Session Persistence o weighted round-robin y ayuda a interpretar una distribución de rutas inesperada. En un diseño Active/Backup puro, el método suele ser secundario porque tanto en funcionamiento normal como durante un fallo solo está disponible la ruta prevista en cada caso.

El failover WAN no es lo mismo que un failover HA. WAN link manager cambia la ruta de Internet en el mismo firewall. Un clúster HA de Sophos Firewall, en cambio, toma el relevo cuando falla un dispositivo o un puerto supervisado.

Preparar el failover WAN

Las dos conexiones de proveedor deben funcionar primero de forma independiente. Los conceptos básicos de la zona WAN, la asignación de IP y el gateway se explican en Planificar zonas e interfaces en Sophos Firewall.

Un ejemplo sencillo podría ser el siguiente:

WAN1 Fiber: conexión principal, gateway gw-fiber, Type: Active, Weight: 1
WAN2 DSL: conexión de reserva, gateway gw-dsl, Type: Backup
Activación de la reserva: If active gateway fails: ANY
Acción durante la activación: Inherit weight of the failed active gateway
Acción durante el retorno: Serve new connections through restored gateway

Los nombres pueden elegirse libremente y deben describir claramente la conexión. El tipo de gateway y las acciones, en cambio, son ajustes funcionales. Antes de la conmutación, el gateway de reserva ya debe mostrar un estado verde y se debe haber probado correctamente tráfico real de clientes a través de esa conexión.

También se necesita una vía de retorno segura para la administración. Si el firewall se modifica de forma remota, WebAdmin no debe ser accesible exclusivamente a través de la conexión que se desconectará durante la prueba. Un backup reciente de la configuración, una ventana de mantenimiento y una persona in situ o una ruta de gestión independiente evitan que una sencilla prueba de failover se convierta en una interrupción prolongada.

También deben anotarse previamente todos los servicios vinculados a una dirección IP pública. Entre ellos se encuentran publicaciones DNAT, peers IPsec, Remote Access, listas de permitidos de proveedores, servidores de correo y sistemas de supervisión externos. El acceso saliente a Internet puede funcionar aunque estos servicios todavía no estén accesibles o autorizados mediante la nueva dirección pública.

Configurar primary/backup

Comprobar las interfaces WAN y el estado de los gateways

En Network > Interfaces, configurar ambos puertos WAN con los ajustes estáticos, DHCP o PPPoE indicados por el proveedor. Al guardar, el gateway WAN físico correspondiente se crea automáticamente en WAN link manager.

Un gateway nuevo es inicialmente Active. Después de añadir una conexión exclusivamente de reserva, conviene cambiar el tipo inmediatamente para evitar que el tráfico de producción se distribuya involuntariamente entre ambos proveedores.

Los custom gateways de Routing > Gateways, por ejemplo para XFRM, RED o MPLS, no aparecen en WAN link manager. Forman parte de otro diseño de routing y no se tratan como gateways ISP físicos en este escenario sencillo.

Configurar el gateway de reserva

En Network > WAN link manager, editar el gateway de la conexión de reserva y establecer los valores siguientes:

Type: Backup
Activate this gateway: If active gateway fails
Con una única conexión principal: ANY
Action on activation: Inherit weight of the failed active gateway
Action on failback: Serve new connections through restored gateway
Guardar y comprobar el estado del gateway.

Con exactamente un gateway activo, ANY y ALL tienen prácticamente el mismo efecto. La diferencia se vuelve importante cuando hay varias conexiones activas:

ANY: El gateway de reserva se activa en cuanto falla uno de los gateways activos. Es adecuado cuando se desea sustituir de inmediato la capacidad perdida.
ALL: El gateway de reserva solo se activa cuando han fallado todos los gateways activos. Resulta más apropiado para una conexión de emergencia lenta o costosa.

Action on activation determina el peso del gateway de reserva cuando se activa junto con otros gateways disponibles. Inherit weight of the failed active gateway es una opción comprensible para un escenario de sustitución sencillo. Use configured weight es útil cuando la reserva tiene deliberadamente una capacidad menor o mayor y funciona junto con las conexiones activas restantes.

Para el failback, Serve new connections through restored gateway es la opción menos disruptiva durante la operación. Las sesiones nuevas vuelven a utilizar la conexión principal, mientras que las existentes permanecen en la ruta de reserva hasta que caduquen o se desconecten. Serve all connections through restored gateway restablece las conexiones existentes y puede interrumpirlas. En las rutas SD-WAN, esta acción solo se aplica cuando se ha seleccionado WAN link load balance como Primary Gateway. Cuando se utiliza una única conexión WAN activa como Primary, solo las conexiones nuevas pasan por el gateway restaurado.

Seleccionar reglas de failover adecuadas

Las Failover rules determinan cuándo se considera que un gateway no está accesible. Se puede elegir entre:

Testing method: Ping o TCP
IP address
con TCP, además Port
combinación de varias condiciones de fallo mediante AND u OR

La interfaz ya detecta una desconexión física del cable. La comprobación por ping de la IP del gateway, creada de forma predeterminada, verifica además si el dispositivo del proveedor conectado directamente o el primer salto del proveedor están accesibles. Sin embargo, puede permanecer en verde aunque ya no haya acceso a Internet detrás del router del proveedor. Por ello, Sophos recomienda para gateways WAN/ISP un destino IP público conocido, por ejemplo 8.8.8.8 o 8.8.4.4.

Para IPv6, Sophos indica 2001:4860:4860::8888 como ejemplo público. Para comprobar el dispositivo upstream, se utiliza la dirección IPv6 del gateway y no su dirección link-local.

Un único destino tampoco representa una comprobación de estado completa. Para un punto de partida más robusto, se pueden utilizar dos direcciones IP públicas permanentemente accesibles y permitidas por la organización:

AND: El failover solo se activa cuando fallan todas las comprobaciones enlazadas. Esto reduce las conmutaciones erróneas causadas por un único destino inaccesible.
OR: Una sola comprobación fallida puede activar el failover. La reacción es más sensible, pero aumenta el riesgo de conmutaciones innecesarias.

8.8.8.8 y 8.8.4.4 son ejemplos concretos de Sophos, pero pertenecen al mismo operador y no representan dominios de fallo completamente independientes. En un entorno importante, es preferible utilizar dos destinos autorizados de operadores diferentes. Un destino de ping debe responder a ICMP de forma fiable; para TCP se necesita un servicio estable cuyo puerto pueda comprobarse.

ANY/ALL en el gateway de reserva y AND/OR en las reglas de comprobación responden a preguntas diferentes. ANY/ALL determina cuántos gateways activos deben fallar. AND/OR determina cómo valoran varias comprobaciones el fallo de un único gateway.

El valor global Gateway failover timeout de WAN link manager determina cuándo el firewall considera fallida una conexión que no responde. No existe un valor correcto universal. Un timeout demasiado corto reacciona más rápido, pero puede provocar una conmutación innecesaria por pérdida de paquetes o una breve interrupción del destino de comprobación. Este valor también se utiliza, entre otras cosas, como intervalo de Health Check para grupos de failover IPsec, por lo que no debe cambiarse de forma aislada para una única conexión WAN. Hay que documentar el valor inicial, realizar una prueba controlada y solo entonces ajustarlo según el tiempo de conmutación medido.

Probar el failover y el failback de forma controlada

Una prueba de cable solo comprueba un fallo local del enlace. Una interrupción del proveedor detrás de un router que sigue accesible solo se detecta cuando tampoco se puede acceder a los destinos públicos de comprobación configurados. Por eso, lo ideal es probar ambos casos por separado.

Confirmar la ventana de mantenimiento, el plan de reversión y un acceso administrativo alternativo.
En Network > WAN link manager, documentar el estado de los gateways principal y de reserva.
Desde un cliente de prueba, comprobar DNS, HTTPS y una aplicación importante. Anotar también la dirección pública de salida utilizada en ese momento.
Para probar el enlace, desconectar de forma controlada el cable WAN principal. Para la prueba real de supervisión, mantener activo el enlace con el firewall e interrumpir la conexión upstream detrás del dispositivo del proveedor, siempre que pueda hacerse de forma segura.
Esperar más tiempo que el Gateway failover timeout configurado.
Comprobar que el gateway principal aparece como fallido y que el gateway de reserva está activo.
Iniciar nuevas sesiones DNS, HTTPS, VPN y de aplicaciones. Comprobar la regla de firewall, NAT, la accesibilidad del destino y la nueva dirección pública de salida.
Revisar los eventos de activación y desactivación del gateway en Log viewer. Para un análisis más profundo, dgd.log contiene eventos sobre la gestión de gateways WAN y el failover de enlaces.
Restaurar la conexión principal y comprobar por separado las sesiones existentes y las nuevas. Así se puede confirmar si se produce realmente el comportamiento de failback configurado.
Documentar el estado final, las aplicaciones y la accesibilidad externa.

Un ping correcto solo demuestra que responde el destino de comprobación. No confirma DNS, NAT, VPN, servicios publicados ni una aplicación empresarial. Para comprobar la ruta real de los paquetes resulta útil Packet Capture en WebAdmin de Sophos Firewall; la función de dgd.log y otros archivos se explica en Registros de servicios de Sophos Firewall.

Errores habituales y limitaciones

La conexión de reserva ya distribuye tráfico de producción: El nuevo gateway todavía está configurado como Active. Para utilizarlo exclusivamente como reserva, hay que cambiarlo a Backup.
El gateway de reserva no se activa cuando se produce un fallo: Comprobar el estado y el tipo del gateway, ANY/ALL, las reglas de failover y Gateway failover timeout. Cuando hay varios gateways activos, ALL puede impedir deliberadamente la activación mientras siga disponible una ruta activa.
El gateway está en verde, pero Internet no funciona: El destino de comprobación está accesible, pero fallan DNS, routing, la regla de firewall, NAT o la aplicación. Comprobar tráfico real, Log Viewer y Packet Capture.
El firewall conmuta sin una interrupción real del proveedor: Un único destino de comprobación no responde, OR es demasiado sensible o el timeout es demasiado corto para la calidad de la conexión. Comprobar los destinos y la pérdida de paquetes medida.
Las sesiones existentes se interrumpen durante la conmutación: Cambia la dirección de origen pública o el estado de NAT. Por ello, los sistemas remotos pueden descartar la conexión. El failover WAN no ofrece automáticamente zero downtime.
El tráfico saliente funciona, pero los servicios entrantes no: El segundo proveedor necesita accesibilidad pública, DNS o Dynamic DNS, DNAT, reglas de firewall y, cuando corresponda, certificados adecuados. DNAT para servidores publicados y los fundamentos de NAT ayudan a delimitar el problema.
La VPN solo funciona mediante la conexión principal: El Remote Gateway, la Listening Address local, el FQDN, las identidades, la configuración del túnel y la ruta de retorno también deben ser compatibles con la ruta de reserva. Un failover WAN sencillo no crea una segunda conexión VPN.

Si las aplicaciones, los grupos de usuarios o las redes de destino deben utilizar conexiones diferentes, o si la latencia, el jitter y la pérdida de paquetes deben controlar la selección de ruta, la decisión debe configurarse mediante rutas y perfiles SD-WAN de Sophos Firewall. Para una conexión de reserva móvil también deben tenerse en cuenta la SIM, el APN, el volumen de datos, CGNAT y la calidad de la señal; estos aspectos se explican en Cellular WAN y failover 4G/5G.

Operación

Si es necesario, notificar por correo electrónico los cambios de estado de los gateways. Para ello, configurar primero el servidor de correo, el remitente y el destinatario en Administration > Notification settings. A continuación, activar el interruptor global Email notifications en System services > Notification list y seleccionar el evento Gateway status en System. Seleccionar únicamente la fila de un evento todavía no envía ningún correo electrónico.
Comprobar el estado de los gateways y dgd.log después de conmutaciones imprevistas.
Probar el failover y el failback al menos cada trimestre y después de cambios de proveedor, interfaz, NAT, routing o firmware.
Documentar las dependencias de IP públicas, los peers VPN, las listas de permitidos y los servicios entrantes.
Asignar responsables para las interrupciones del proveedor, la escalación y el retorno al funcionamiento normal.
Comprobar periódicamente los destinos de prueba; un destino que haya cambiado permanentemente o ya no sea accesible no debe determinar la lógica de conmutación sin que se detecte.
Cuando haya varias conexiones activas, comprobar los pesos y Session Persistence según el uso real y no solo según los anchos de banda nominales.