Configurar y probar un IPsec Failover Group en Sophos Firewall

Un IPsec Failover Group ordena varias conexiones IPsec Site-to-Site según su prioridad. Si falla el túnel principal, Sophos Firewall activa la siguiente conexión disponible. Sin embargo, para que la conmutación sea realmente útil, ambos túneles deben funcionar previamente por separado y cubrir las mismas redes de producción, reglas, expectativas de NAT y rutas de retorno.

Procedimiento breve: probar dos conexiones IPsec por separado, comprobar los Remote IDs y el orden, agruparlas en Site-to-site VPN > IPsec > Failover group, elegir una Failover Condition adecuada y validar después el Failover y el Failback con un flujo de prueba definido.

Esta guía presupone una configuración IPsec Site-to-Site existente. Explica el control de la redundancia, no vuelve a describir la configuración completa del túnel.

Cuándo conviene un IPsec Failover Group

El grupo resulta adecuado principalmente para IPsec Policy-based e IPsec Route-based con Traffic Selectors concretos. Varias conexiones con Local y Remote subnets idénticas deben pertenecer al mismo Failover Group o utilizar Selectors claramente distintos. De lo contrario, los túneles pueden interferir entre sí.

Con un diseño Route-based Any-to-Any controlado íntegramente por el enrutamiento, la decisión es distinta: las interfaces XFRM reciben direcciones de transferencia y las rutas estáticas, dinámicas o las SD-WAN Routes determinan la ruta de los datos. Para este diseño, Sophos documenta varios gateways XFRM con un SD-WAN Profile y comprobaciones SLA sin un grupo de failover VPN adicional. Fuera de este diseño, Sophos advierte que varias conexiones Any-to-Any con selectores idénticos deben pertenecer al mismo grupo de failover.

La documentación general de troubleshooting exige un grupo también para Any-to-Any, mientras que la guía específica de SD-WAN funciona sin él. La documentación no delimita explícitamente esta excepción. Por tanto, se debe seguir el diseño XFRM/SD-WAN completo y validarlo en la build instalada, no prescindir del grupo simplemente porque los selectores sean Any. Configurar IPsec basado en rutas con dos conexiones a Internet explica el diseño completo con dos proveedores, gateways XFRM separados, rutas estáticas Primary y Backup y una prueba controlada de failover.

Tampoco un WAN Failover normal sustituye al grupo. WAN link manager puede cambiar la conexión a Internet, pero no crea una segunda conexión IPsec con su propia Gateway Address, Listening Interface y configuración de la contraparte.

system link_failover es un mecanismo CLI independiente

SFOS 22 también publica un comando de Device Console que añade un túnel VPN o GRE como backup de un Primary Link. La gramática publicada es:

system link_failover add [primarylink] [portname] [backuplink] [vpn] [gre] [tunnel] [tunnelname] [monitor PING host] [monitor TCP host] [ipaddress] [portnumber]

Con monitor TCP host debe indicarse el puerto TCP que se comprobará; monitor PING host no utiliza puerto. El objetivo no solo debe responder, sino representar de forma útil la ruta relevante. Un monitor correcto no demuestra que funcionen la aplicación, la regla, la ruta o la dirección de retorno.

Este comando no equivale al grupo de failover IPsec configurado en WebAdmin ni al diseño XFRM y SD-WAN. La página pública de SFOS 22 solo documenta add: no ofrece comandos de estado, eliminación o reversión ni explica la interacción con rutas o políticas SD-WAN existentes. Sin un método de reversión confirmado para la build instalada, no es un procedimiento para copiar y pegar. Para configuraciones nuevas, los métodos WebAdmin o XFRM documentados ofrecen un punto de partida más claro.

Un FQDN con varias direcciones WAN no es un failover

Si el mismo registro DNS A apunta simultáneamente a la dirección WAN primaria y a otra que solo está activa durante una caída, la contraparte remota también puede seleccionar la dirección inactiva. DNS round robin no conoce ni el estado de la WAN ni el del túnel. Un IPsec Failover Group local no corrige automáticamente esta selección DNS remota.

Para túneles iniciados desde la contraparte, esta necesita dos conexiones configuradas explícitamente. Otra opción es un FQDN cuyo DNS tenga en cuenta el estado de salud o que una actualización DDNS haga apuntar solo a la dirección disponible en ese momento. Si no se puede controlar ni la contraparte ni la actualización DNS, este diseño no ofrece un failover entrante fiable. Dos direcciones publicadas simultáneamente no constituyen un failover probado.

Además, un VPN Failover Group no es lo mismo que un clúster HA. El grupo cambia entre túneles; HA cambia entre dos nodos del firewall. En un entorno crítico, los fallos de WAN, VPN y posibles fallos de HA deben planificarse y probarse por separado.

Qué supervisa el grupo

Sophos Firewall comprueba la contraparte mediante la Failover condition del grupo. El intervalo procede del valor global Gateway failover time-out situado en:

Network > WAN link manager

El mismo valor también afecta a la supervisión general de los WAN Gateways. Por tanto, no se debe modificar solo para un túnel VPN. Un valor corto reacciona con mayor rapidez, pero puede provocar una conmutación innecesaria ante una pérdida breve de paquetes. Un valor largo tolera las interrupciones durante más tiempo, pero prolonga la caída antes del cambio.

El Health Check solo confirma que la contraparte remota responde a la condición Ping o TCP seleccionada. No demuestra que funcionen DNS, una aplicación empresarial, NAT, Routing y la ruta de retorno completa. Estos puntos se comprueban por separado después de la conmutación.

Preparar dos túneles para el grupo

El siguiente ejemplo conecta una sede central con una sucursal mediante dos túneles:

• Sede central: 10.10.0.0/16
• Sucursal: 10.20.0.0/16
• Conexión principal: HQ-Branch-ISP1
• Conexión secundaria: HQ-Branch-ISP2
• Dirección del Peer principal: 198.51.100.20
• Dirección del Peer secundario: 203.0.113.20
• Remote ID común de la sucursal: 10.255.255.2
• Failover Group: HQ-Branch-Zurich

Las direcciones 198.51.100.0/24 y 203.0.113.0/24 son redes de documentación y deben sustituirse por las direcciones públicas reales de los Peers. Las redes, los nombres y el Remote ID también son valores de ejemplo. Lo importante es el principio: las Gateway addresses pueden ser distintas, pero la dirección IP del Remote ID debe ser la misma para todos los miembros del grupo. En la contraparte, este Remote ID debe coincidir con el Local ID correspondiente.

En Site-to-site VPN > IPsec, Active y Connection no significan lo mismo: Active indica si la conexión está activada; Connection indica si el túnel está establecido. Una entrada activa puede seguir sin tener un túnel establecido. Con varias Local y Remote subnets se crea un túnel por cada par de redes; por tanto, un estado parcialmente establecido no constituye una validación completa. Activate on save o el conmutador de la columna Active activa la entrada. Para varias entradas seleccionadas están disponibles Activate y Deactivate, además de un filtro junto a Active. Estas acciones cambian el estado y, como la agrupación, deben realizarse durante la ventana de pruebas prevista.

Para comparar ambos miembros, seleccionar Local subnet y Remote subnet en IPsec connections > Show additional properties y confirmar con OK. Se pueden mostrar otras propiedades y reordenar las columnas mediante arrastrar y soltar. Logs abre los registros; Profiles > IPsec profiles > Show additional properties permite comparar también los valores de los perfiles. Antes de agrupar, se deben aclarar con el administrador de la contraparte los pares de redes ausentes o diferentes.

Si el firewall acepta solicitudes IPsec entrantes, también debe permitirse IPsec para la zona WAN en Administration > Device access. Esta autorización es distinta de Ping o SSH para el Health Check y no sustituye las reglas de firewall para el tráfico de las aplicaciones.

Antes de agruparlas, se comprueban ambas conexiones por separado:

1. Ambas conexiones están activas en Site-to-site VPN > IPsec.
2. Cada conexión puede establecerse de forma independiente y transporta el mismo flujo de prueba definido.
3. Local y Remote subnets o Traffic Selectors son simétricos con respecto a la configuración de la contraparte.
4. Las reglas de firewall permiten el tráfico necesario a través de la zona VPN en ambos sentidos.
5. NAT es idéntico en ambas rutas y se ha configurado de forma deliberada.
6. La contraparte dispone de una ruta de retorno por ambos túneles.
7. Los Profiles coinciden con la contraparte correspondiente. IPsec Profiles en Sophos Firewall explica DPD, Rekeying y Lifetimes.
8. Se dispone de un acceso administrativo alternativo y de una ventana de mantenimiento.

⚠️ Al añadir conexiones a un Failover Group se interrumpen las conexiones establecidas. El cambio no debe realizarse durante una sesión remota sin supervisión ni sin una vía de recuperación probada.

Una conexión solo puede pertenecer a un Failover Group. No puede eliminarse mientras esté asignada a un grupo. Las conexiones IPsec Remote Access no pueden utilizarse como miembros.

Elegir una Failover Condition adecuada

Sophos admite Ping o TCP con un puerto definido. La condición debe permitirse de forma deliberada en ambos firewalls:

• Ping: es fácil de comprobar, pero requiere Ping/Ping6 para la zona WAN en Administration > Device access. Sophos documenta esta autorización de zona como requisito. Con direcciones fijas de la contraparte, se puede evaluar una Local Service ACL Exception limitada como medida de refuerzo; debe coincidir con la dirección de origen que utiliza realmente la contraparte. Device Access y Local Service ACL explica la configuración.
• TCP 22: requiere SSH a través de la zona VPN. No se debe abrir SSH en WAN para este fin. Un servicio de gestión no es un buen Health Check general si debe exponerse exclusivamente para la supervisión.
• Otro puerto TCP: requiere las reglas de firewall entrantes y salientes correspondientes. El servicio debe estar disponible de forma permanente y no depender únicamente del estado de una aplicación cualquiera.

La condición debe representar un servicio de respuesta o una ruta estable de la contraparte remota. Si el servicio utilizado para TCP deja de responder por mantenimiento, un fallo local o un Host Firewall, el grupo puede conmutar aunque la ruta IPsec siga disponible.

Configurar el IPsec Failover Group

La ruta del menú es:

Site-to-site VPN > IPsec > Failover group > Add

1. Introducir un Name único, HQ-Branch-Zurich en el ejemplo.
2. En Member connections, seleccionar al menos dos conexiones IPsec Site-to-Site. Solo las conexiones activas participan en el failover; por tanto, se debe activar y probar por separado cada miembro previsto antes de poner en servicio el grupo.
3. Colocar las conexiones en el orden deseado: primero HQ-Branch-ISP1 y después HQ-Branch-ISP2. La primera conexión es el túnel principal.
4. Activar Mail notification para recibir notificaciones de error de conexión. Para ello ya deben funcionar los Notification settings y las notificaciones VPN.
5. Activar Automatic failback si el grupo debe volver al túnel preferido después de su recuperación.
6. Definir una Failover condition adecuada con Ping o TCP y un puerto.
7. Guardar con Save.
8. Activar el conmutador de estado del grupo. Solo entonces queda activo el grupo e intenta establecer la conexión principal.

Cuando intervienen dos Sophos Firewalls, se deben comprobar en ambos lados las propiedades de las conexiones, el orden de los miembros, los Remote IDs y las autorizaciones del Health Check. Un grupo correcto en un solo lado no sustituye una configuración compatible en la contraparte.

Referencia API: separar grupo, conexión y monitor

La operación API combinada de SFOS 22/23 Add Failover Group IPSEC Connection / Edit IPSEC Connection no proporciona un payload completo del grupo: su ejemplo muestra VPNIPSecConnection/Configuration y acciones de conexión, no la serialización del grupo independiente de WebAdmin.

• La tabla indica Failover Group Name como obligatorio y Failover Mail Notification como opcional con y/n. El ejemplo no muestra su correspondencia XML ni cómo representar la pertenencia al grupo, la prioridad o Automatic failback. No deducir etiquetas XML de nombres de campos con espacios ni la prioridad de los miembros del orden de los ARRAY.
• Protocol aparece dos veces con ámbitos distintos: para la supervisión como ARRAY con ping, tcp o una cadena vacía (''), junto a Port como ARRAY de 1 a 65535; para la conexión como SCALAR con ALL, ICMP, UDP, TCP, junto a LocalPort y RemotePort. Estos campos no son intercambiables. La referencia no explica cómo emparejar los arrays ni el significado del valor vacío; no deducir de ellos autorizaciones para tráfico de aplicaciones o IKE. Las reglas de firewall y Device Access siguen siendo requisitos independientes.

Las listas de valores tampoco coinciden: el ejemplo de ConnectionType muestra RemoteAccess/SiteToSite/HostToHost, mientras que la tabla añade TunnelInterface; SubnetFamily muestra IPv4/IPv6, mientras que la tabla añade Dual. Su ausencia en el ejemplo no demuestra que no se admitan. No convertir nombres de modos GUI en tokens API supuestos; la guía de IPsec Site-to-Site explica los parámetros de conexión.

Mientras el esquema del grupo para la build instalada siga sin estar claro, gestionarlo mediante el procedimiento WebAdmin anterior en lugar de adivinar un request. Antes de los cambios, registrar la pertenencia real al grupo, el orden, la condición de supervisión y el ajuste de failback; después, comprobar el grupo guardado y el flujo de prueba real. Si el resultado no coincide con lo previsto, utilizar la reversión descrita más abajo para restablecer el estado inicial documentado.

Qué ocurre con DPD y Key negotiation tries

En cuanto una conexión pasa a ser miembro del grupo, SFOS desactiva Dead Peer Detection para ella y utiliza 3 para Key negotiation tries. La Failover condition asume la supervisión.

Después de retirar la conexión del grupo, vuelve a utilizar los valores DPD y Key negotiation de su IPsec Profile asignado. Este comportamiento debe formar parte de la prueba de reversión, aunque no se haya modificado el perfil.

Probar Failover y Failback de forma controlada

Antes de la prueba de caída se define un flujo de datos concreto, por ejemplo:

• Source: 10.10.10.25
• Destination: 10.20.20.15
• Service: TCP 443
• Regla de firewall esperada: HQ-to-Branch-HTTPS

A continuación, la prueba se realiza en un orden claro:

1. Documentar el estado del grupo, el orden de los miembros, el Firmware Build y Gateway failover time-out.
2. Comprobar el túnel principal en WebAdmin en ambos lados. Confirmar con tráfico HTTPS real que funcionan la ida y la vuelta.
3. Registrar el estado en la Advanced Shell con ipsec statusall.
4. Durante la ventana de mantenimiento, interrumpir de forma controlada la ruta WAN o Upstream principal. No desactivar todo el Failover Group, porque esto desactiva todos los túneles activos del grupo.
5. Observar durante más tiempo que el Gateway failover time-out configurado y anotar el momento de la conmutación.
6. Comprobar si se establece HQ-Branch-ISP2 y si la misma prueba HTTPS funciona en ambos sentidos.
7. Comprobar la regla de firewall, NAT, la ruta de retorno y el funcionamiento de la aplicación. Un túnel verde no es por sí solo un criterio de éxito.
8. Restablecer la ruta principal y observar Automatic failback.
9. Tras el retorno, repetir la misma prueba y documentar la interrupción medida realmente.

Las sesiones TCP existentes pueden interrumpirse durante el cambio. El nuevo túnel tiene Security Associations distintas y puede utilizar otra dirección pública. Por ello, la aplicación suele tener que establecer una nueva sesión. El Failover IPsec mejora la disponibilidad, pero no garantiza una sesión sin interrupciones.

Automatic failback termina tras cinco intentos fallidos

Cuando la contraparte principal vuelve a estar accesible, SFOS intenta restablecer la conexión preferida hasta cinco veces si Automatic failback está activado. Si estos intentos fallan, el túnel secundario permanece activo. El firewall no continúa comprobando indefinidamente el túnel principal; solo vuelve a él si falla la ruta secundaria. Si el grupo contiene más de dos conexiones, SFOS vuelve a la primera conexión disponible en el orden de Member connections.

Se puede desactivar y volver a activar el grupo manualmente para iniciar otro intento de establecer la conexión principal. Esto provoca una interrupción del servicio. Antes se deben comprobar los registros, la contraparte, el perfil, los identificadores y la ruta.

Consultar los Logs sin modificar la configuración

dgd.log es importante para la decisión del grupo, mientras que strongswan.log muestra el establecimiento IPsec propiamente dicho. En la CLI, abrir 5. Device Management > 3. Advanced Shell; estos comandos no están destinados a Device Console. Los registros pueden contener redes internas, direcciones de los peers y nombres, por lo que deben revisarse antes de compartirlos. Los comandos siguientes solo consultan el estado o los registros y no modifican la configuración:

tail -n 200 /log/dgd.log
tail -n 200 /log/strongswan.log
ipsec statusall

Si es necesario, se añaden charon.log y el registro de acciones específico de la conexión. Las páginas oficiales de SFOS 22 no coinciden en el nombre del registro de supervisión: la referencia general indica ipsec_monitor.log, mientras que la página de troubleshooting IPsec indica strongswan-monitor.log. Se debe consultar solo el archivo presente en la build instalada. En la última línea se sustituye HQ-Branch-ISP1 por el nombre real de la conexión:

tail -n 200 /log/charon.log
for log in /log/ipsec_monitor.log /log/strongswan-monitor.log; do [ -f "$log" ] && tail -n 200 "$log"; done
tail -n 200 /log/ipsec_conn/ipsec_HQ-Branch-ISP1.log

Se comparan los timestamps de dgd.log, el estado IPsec, el evento WAN y la prueba de la aplicación. Un Health Check fallido sin el correspondiente error de túnel o aplicación todavía no demuestra una caída del proveedor. La ruta de diagnóstico completa se encuentra en Troubleshooting de IPsec VPN en Sophos Firewall.

Errores frecuentes y retorno seguro

El grupo no se activa correctamente

Se deben seleccionar al menos dos conexiones. Solo las conexiones activas participan en el failover. Comprobar si un miembro previsto está desactivado, ya pertenece a otro grupo, se creó como Remote Access o utiliza un Remote ID distinto. Después se vuelven a probar ambos túneles por separado antes de reactivar el grupo.

El túnel secundario aparece verde, pero falla el tráfico

Es probable que la lógica del grupo haya funcionado, pero no la ruta de datos. Comprobar las reglas de firewall, NAT, Local y Remote subnets, las rutas automáticas o manuales y la ruta de retorno en la contraparte. El túnel secundario debe poder transportar el mismo flujo de prueba de producción que el principal.

El grupo conmuta demasiado pronto o demasiado tarde

Comprobar conjuntamente la Failover Condition y Gateway failover time-out. Un destino Ping o TCP inestable puede provocar cambios innecesarios. Un Timeout global largo también retrasa otras comprobaciones de Gateway dependientes. No se debe cambiar solo la cifra, sino documentar la causa, la pérdida de paquetes y el tiempo real de conmutación.

Comprobar el orden después de arrastrar y soltar

La ayuda pública actual de SFOS 22 no ofrece un límite fiable de versiones afectadas o corregidas para un orden incorrecto después de arrastrar y soltar. Se debe volver a abrir el grupo guardado después de cada cambio y comparar el orden con la prioridad prevista.

Desmontar el grupo

Al desactivar un grupo de failover se desactivan los túneles activos de sus miembros. Las conexiones independientes necesarias deben reactivarse después por separado. Sophos no documenta los efectos de eliminar el propio grupo. Por tanto, primero se debe desactivar el grupo durante una ventana de mantenimiento, retirar las asignaciones de forma controlada y no dar por supuesta una reactivación automática. Para una reversión controlada:

1. Registrar el estado inicial, el orden de los miembros y los Profiles utilizados.
2. Confirmar la ventana de mantenimiento y un acceso administrativo alternativo.
3. Desactivar el grupo y documentar la interrupción.
4. Retirar las conexiones del grupo o restablecer la asignación original.
5. Activar la conexión independiente necesaria.
6. Volver a tener en cuenta el comportamiento de DPD y Key negotiation del Profile.
7. Comprobar el mismo flujo de prueba, los Logs y la ruta de retorno.

Operación

• Volver a probar Failover y Failback después de cambios de Firmware, proveedor, Peer, Routing, NAT o Profile.
• Documentar el orden de los miembros, los Remote IDs, los Profiles, la condición del Health Check y el Timeout global.
• Utilizar Mail notification solo como aviso; la validación técnica sigue requiriendo estado, Logs y tráfico real.
• Incluir ambos túneles en el Monitoring, el plan de mantenimiento y la documentación de la contraparte.
• Comprobar si el proveedor secundario cumple las mismas Allowlists, dependencias de NAT y accesibilidades públicas.
• Desactivar y volver a activar manualmente el grupo solo con una interrupción planificada.

FAQ