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 Route-based Any-to-Any, 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. En este diseño se pueden priorizar varios XFRM Gateways directamente mediante un SD-WAN Profile y comprobaciones SLA. No se necesita un VPN Failover Group adicional.

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.

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 o un FQDN cuyo DNS basado en estado o actualización DDNS apunte solo a la dirección disponible en ese momento. Si no se puede controlar ni la contraparte ni la actualización DNS, se detiene el diseño en este punto. Dos direcciones publicadas simultáneamente no deben considerarse 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.

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. Con direcciones Peer fijas, una Local Service ACL Exception limitada es mejor que una autorización innecesariamente amplia. Device Access y Local Service ACL explica la configuración segura.
• 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 activas.
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 si se debe notificar por correo electrónico un cambio de túnel. 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.

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 establece de forma efectiva Key negotiation tries en 3. La Failover Condition asume la supervisión. Por tanto, los valores mostrados únicamente en la vista del Profile no representan todo el comportamiento efectivo.

Después de retirar la conexión del grupo, vuelve a utilizar los valores DPD y Key-negotiation de su IPsec Profile asignado. Esto es importante durante el Rollback: un túnel puede comportarse de forma distinta después de eliminar el grupo, aunque no se haya editado el propio Profile.

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.

Se puede desactivar y volver a activar el grupo manualmente para iniciar otro intento de establecer la conexión principal. Sin embargo, esto provoca una interrupción del servicio y no es un simple conmutador de actualización. Antes se deben comprobar los Logs, la contraparte, el Profile, los IDs 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. Los comandos siguientes se ejecutan en la Advanced Shell 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, ipsec_monitor.log y el Action Log específico de la conexión. En la última línea se sustituye HQ-Branch-ISP1 por el nombre real de la conexión:

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
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 y ambas deben estar activas. Comprobar si una conexión 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.

El orden es incorrecto después de Drag-and-drop

Sophos confirma el error NC-178121 en SFOS 22.0 GA: después de un cambio mediante Drag-and-drop, las conexiones IPsec Site-to-Site podían quedar en una posición incorrecta dentro del Failover Group. Este error concreto está corregido en SFOS 22.0 MR2 Build 546.

En SFOS 22.0 GA se debe documentar el orden antes y después de cada cambio y no confiar únicamente en el desplazamiento visual. La Release Note pública no indica un límite independiente e inequívoco de versiones afectadas o corregidas para MR1. Si se produce un error similar en MR2 Build 546 o posterior, no se debe seguir atribuyendo automáticamente a NC-178121.

Desmontar el grupo

Al desactivar un Failover Group se desactivan los túneles activos de sus miembros. Las conexiones independientes necesarias deben reactivarse después por separado. Para un Rollback controlado:

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