Configurar IPsec basado en rutas con dos conexiones a Internet

Una segunda conexión a Internet no convierte automáticamente un túnel IPsec en redundante. Un failover fiable requiere una conexión basada en rutas independiente para cada enlace, una interfaz XFRM con dirección propia y una ruta supervisada. Solo entonces Sophos Firewall puede cambiar de forma controlada el tráfico de ISP1 a ISP2 y volver a la ruta preferida cuando se restablezca.

Este procedimiento trata IPsec basado en rutas Any-to-Any entre dos firewalls Sophos con SFOS 22.0 y sigue el diseño con dos conexiones a Internet descrito por Sophos. Los túneles basados en políticas y los basados en rutas con Traffic Selectors concretos utilizan en su lugar un IPsec Failover Group.

⚠️ La ayuda actual de Sophos se contradice sobre dos conexiones Any-to-Any. La guía específica para dos ISP crea ambos túneles sin Failover Group. En cambio, las indicaciones generales de troubleshooting de IPsec afirman que varias conexiones con Local y Remote Subnets iguales, incluidas Any-Any, solo funcionan en el mismo Failover Group. Como el grupo cambia DPD y Failback, aquí no se inventa ese paso: validar el diseño en la Maintenance Release de SFOS 22 instalada y consultar cualquier comportamiento distinto con Sophos Support antes de producción.

Procedimiento breve

1. Validar por separado en ambos firewalls un túnel Any-to-Any mediante ISP1 y otro mediante ISP2.
2. Asignar una dirección de transferencia única a cada una de las cuatro interfaces XFRM.
3. Crear en cada firewall un Custom Gateway con un Health Check elegido conscientemente para ambas direcciones XFRM del peer.
4. Añadir dos rutas estáticas a la misma LAN remota: Primary con una Administrative Distance menor y Backup con una mayor.
5. Registrar la Route Precedence global y establecerla en static vpn sdwan_policyroute solo si encaja con el diseño completo.
6. Comprobar las reglas de firewall y las rutas de retorno para ambos recorridos XFRM.
7. Interrumpir ISP1 de forma controlada, probar tráfico real de aplicaciones mediante ISP2 y después validar el Failback a ISP1.

⚠️ Route Precedence se aplica a todo el firewall. Un cambio también puede afectar a rutas Static, VPN y SD-WAN existentes. Primero se registran el valor actual y todas las rutas solapadas, se crea un backup de configuración y se verifica un acceso de administración independiente.

Diseño y requisitos

Entender el modelo de failover

Las dos conexiones IPsec siguen siendo túneles independientes. La ruta con la Administrative Distance menor es el recorrido de datos preferido. Si su gateway XFRM supervisado se considera inaccesible, puede asumir el tráfico la ruta por el segundo túnel.

Son dos estados distintos:

• El túnel está activo: se han establecido IKE y Child SA.
• La ruta es utilizable: gateway, ruta, regla de firewall, expectativa de NAT, peer y ruta de retorno funcionan para el tráfico real.

Por eso, un túnel verde por sí solo no demuestra el failover. Tampoco basta un failover WAN normal: WAN link manager no crea una segunda conexión IPsec ni una ruta adecuada en el peer.

Para Any-to-Any no se añade un VPN Failover Group. La selección se realiza mediante las interfaces XFRM con dirección, los gateways y las rutas. Configurar una VPN IPsec Site-to-Site explica la configuración básica completa de este tipo de túnel.

SFOS 22 permite rutas estáticas, SD-WAN o dinámicas para interfaces XFRM Any-to-Any. El procedimiento específico para dos ISP utiliza expresamente dos rutas estáticas. Este procedimiento sigue ese diseño; no se añade una ruta SD-WAN al mismo destino sin diseñar y probar por separado su interacción y prioridad.

Planificar la topología de ejemplo

El ejemplo conecta una sede central con una sucursal:

• Sede central: 172.16.16.0/24
• Sucursal: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• Red XFRM de ISP1: 10.255.1.0/30
• Red XFRM de ISP2: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

Las direcciones son valores de documentación y se sustituyen por redes de transferencia propias que no se solapen. Cada par XFRM necesita una red separada. Las direcciones públicas de los ISP, Local y Remote IDs, Profiles y Listening Interfaces deben coincidir con el peer en cada túnel.

Configurar túneles, gateways y rutas

Preparar dos túneles

En cada firewall se crean dos conexiones en Site-to-site VPN > IPsec. Ambas utilizan Route-based (Tunnel interface) y Any en Local subnet y Remote subnet. En un diseño típico de sede central y sucursal, la central utiliza Respond only y la sucursal Initiate the connection.

El primer túnel utiliza la interfaz WAN de ISP1 y el segundo la de ISP2. Ambas conexiones se prueban por separado antes de configurar el failover. En cada prueba se activa únicamente el túnel previsto y se comprueba un flujo de datos definido en ambas direcciones.

En ambos firewalls, en Network > Interfaces, se despliega la interfaz WAN utilizada para la conexión IPsec correspondiente. Debajo aparecen las interfaces XFRM creadas automáticamente como interfaces subordinadas. Así se puede asociar cada XFRM al túnel de ISP1 o ISP2 antes de asignarle su dirección de transferencia.

En Network > Interfaces se asignan estas direcciones de ejemplo a las interfaces XFRM creadas automáticamente:

• Sede central: 10.255.1.1/30 para ISP1 y 10.255.2.1/30 para ISP2
• Sucursal: 10.255.1.2/30 para ISP1 y 10.255.2.2/30 para ISP2

No se cambia la dirección de una interfaz XFRM mientras otras rutas o servicios dependan de ella. Antes de cada cambio se revisan Object usage, el estado del túnel y los objetos de routing existentes.

Supervisar los gateways XFRM

En Routing > Gateways se crea en cada lado un gateway por túnel hacia la dirección XFRM del peer. En la sede central son 10.255.1.2 y 10.255.2.2; en la sucursal, 10.255.1.1 y 10.255.2.1.

En cada gateway se configuran al menos Name, Gateway IP e Interface. Gateway IP es la dirección XFRM del peer e Interface la XFRM correspondiente. Health check está desactivado de forma predeterminada y debe activarse para supervisar el recorrido. SFOS 22 muestra entonces Interval (60 segundos de forma predeterminada), Time-out (2 segundos), Retries (3) y al menos una Monitoring condition con Protocol, Port para TCP e IP address.

La IP de prueba debe pertenecer a un host detrás del gateway. Para evaluar todo el recorrido posterior, se elige un endpoint estable y permitido detrás del peer. Un ping solo a la dirección XFRM demuestra únicamente el tramo inmediato. Varias condiciones pueden combinarse con AND u OR: AND exige todas las respuestas y OR prueba de arriba abajo hasta la primera respuesta.

La elección de protocolo, destino e intervalos es una decisión operativa: el destino debe responder de forma estable, seguir disponible durante el mantenimiento normal y contar con la autorización adecuada. Los valores predeterminados son un punto de partida, no un tiempo de conmutación garantizado. El cambio solo se acepta después de medir detección, Failover y Failback. Crear y comprobar un Custom Gateway explica el Health Check, el estado y las condiciones de parada.

Añadir rutas estáticas Primary y Backup

En la sede central se añaden en Routing > Static routes dos rutas IPv4 Unicast hacia la red de la sucursal 192.168.10.0/24:

• mediante 10.255.1.2 y la XFRM de ISP1 con Administrative distance 1
• mediante 10.255.2.2 y la XFRM de ISP2 con Administrative distance 2

En la sucursal se crean de forma simétrica dos rutas hacia la red central 172.16.16.0/24:

• mediante 10.255.1.1 y la XFRM de ISP1 con Administrative distance 1
• mediante 10.255.2.1 y la XFRM de ISP2 con Administrative distance 2

La Administrative Distance menor gana mientras su gateway esté disponible. Por tanto, redes de destino idénticas y distancias distintas forman las rutas Primary y Backup. Es diferente de ECMP con la misma prioridad. Configurar y probar una ruta estática explica la lógica general de ruta y retorno.

La guía específica de Sophos atribuye Failover y Failback automáticos a este diseño. La referencia general de rutas estáticas confirma la prioridad por Administrative Distance, pero no describe por separado cómo un Health Check fallido elimina la ruta de la selección. Por ello, la validación debe observar la ruta activa y no solo el estado del gateway.

Establecer Route Precedence de forma controlada

Sophos documenta este diseño con Static antes que VPN y SD-WAN. Primero se registra el estado existente en Device Console:

system route_precedence show

Solo si este orden encaja con todo el diseño de routing, se establece en ambos firewalls:

system route_precedence set static vpn sdwan_policyroute

Después se comprueba de nuevo el valor con system route_precedence show. Este cambio no es una solución general para IPsec. También afecta a otras rutas Static, VPN y SD-WAN solapadas. Cambiar Route Precedence de forma segura explica el efecto global y el rollback.

La ayuda de SFOS 22 indica como valor general predeterminado static, sdwan_policyroute, vpn, mientras que la guía específica exige static vpn sdwan_policyroute. El rollback debe restaurar el orden exacto registrado previamente con show, no aplicar el predeterminado sin comprobarlo.

Alinear reglas, NAT y ruta de retorno

Ambos firewalls necesitan reglas adecuadas entre LAN y VPN. Orígenes, destinos y servicios se limitan a las redes y aplicaciones reales de los sitios; Log firewall traffic permanece activado durante la implantación.

El tráfico normal enrutado entre sedes no suele necesitar SNAT. Si ya existen excepciones NAT o traducciones específicas, deben comportarse igual en ambos recorridos. No se añade una regla MASQ amplia como atajo para el failover.

Esto es distinto de NAT Traversal. Sophos Firewall activa NAT-T automáticamente y usa UDP 4500 al detectar NAT; sin NAT, IKE usa UDP 500 y ESP el protocolo IP 50. Si un firewall está detrás de un router anterior, el DNAT y los permisos de ese router deben alcanzar la Listening Interface adecuada por ambos ISP. Las redes de sedes solapadas requieren, en cambio, reglas SNAT y DNAT para el tráfico útil.

La ruta del peer es tan importante como el camino de ida. Un túnel puede estar activo aunque la respuesta vuelva por el ISP equivocado o por una ruta más general. Por eso se evalúan conjuntamente Route Lookup, la ruta activa, Firewall Rule ID, NAT Rule ID y Packet Capture.

Validar y operar el failover

Validar Failover y Failback

Antes de la prueba de fallo se validan ambos túneles por separado con el mismo flujo de aplicación. Se mantiene visible una conexión de prueba continua y, además, se crean sesiones nuevas durante la prueba.

En la ventana de mantenimiento se interrumpe de forma controlada únicamente el recorrido de ISP1. No se desactivan al mismo tiempo ambos puertos WAN ni ambos túneles. La validación responde a cuatro preguntas:

1. ¿Se detecta el gateway de ISP1 como no disponible?
2. ¿Se activa la ruta con Administrative Distance 2 mediante la XFRM de ISP2?
3. ¿Las conexiones nuevas alcanzan el peer y las respuestas regresan mediante ISP2?
4. Cuando ISP1 se recupera, ¿vuelve a utilizarse la ruta con Administrative Distance 1?

En Log Viewer y en un Packet Capture restrictivo deben coincidir la Firewall Rule ID esperada, la interfaz XFRM activa y el flujo bidireccional. Un ping por sí solo no basta. HTTPS, RDP, VoIP u otra aplicación real también muestran si funcionan el establecimiento de sesión, MTU y la ruta de retorno. Probar una regla de firewall con Log Viewer y Packet Capture explica el procedimiento combinado.

En un clúster HA, después de un Failover planificado se prueba una conexión nueva por ambos recorridos ISP. SFOS 22 restaura de forma transparente los túneles IPsec route-based, pero limita el Failover de sesiones para tráfico dentro del túnel a protocolos sin estado como UDP e ICMP; TCP no es compatible. Se evalúan por separado una conexión TCP existente y otra nueva. Además, los logs e informes HA solo permanecen en el nodo que procesó el tráfico: hay que revisar ambos dispositivos.

Delimitar errores sistemáticamente

Ambos túneles están verdes, pero ISP2 no asume el tráfico

Comprobar el estado de los gateways, el Monitoring Target y ambas rutas estáticas. La red de destino y el prefix deben ser idénticos; los Next Hops y las interfaces XFRM deben ser distintos. Después se comparan Administrative Distance y Route Precedence actual.

ISP2 asume el tráfico, pero las aplicaciones no responden

Comprobar las reglas de firewall, las excepciones NAT y la ruta de retorno en ambos lados. Packet Capture debe mostrar la solicitud y la respuesta en la XFRM de ISP2. Si solo falta la respuesta, el error suele encontrarse detrás del peer o en una ruta de retorno asimétrica.

Failback cambia demasiado pronto o no cambia

Observar Health Check y Monitoring Target. El destino no debe indicar de forma intermitente que el túnel está sano mientras el recorrido de la aplicación sigue afectado. Comprobar conjuntamente Administrative Distance, la ruta activa y una sesión realmente nueva; las conexiones existentes pueden seguir ligadas a su estado anterior.

Solo funciona una dirección

Comparar la configuración simétrica: dirección XFRM, gateway, ruta estática, regla y ruta de retorno deben existir en ambos firewalls. El troubleshooting actual de Sophos cita /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log y /log/dgd.log; el último contiene eventos de Dead Gateway Detection y VPN Failover. En Advanced Shell, el comando de solo lectura ip xfrm state muestra si existen Transform States. Troubleshooting de VPN IPsec explica el diagnóstico seguro.

El estado del túnel y el del gateway no coinciden

DPD y Gateway Health Check miden aspectos distintos. Dead Peer Detection se configura en Profiles > IPsec profiles y detecta un peer IKE que no responde tras permanecer inactivo el túnel Phase 2; Sophos recomienda activarlo. El Health Check del Custom Gateway comprueba el host elegido detrás del recorrido XFRM. No se desactiva DPD para ocultar un destino de prueba defectuoso. Si Sophos Support exige un Failover Group por el conflicto documental anterior, hay que tener en cuenta que añadirlo desactiva DPD en el perfil asociado, establece Key negotiation tries en 3 e introduce un Automatic failback propio con un máximo de cinco intentos. Es otro modelo operativo y no debe mezclarse con este procedimiento sin una validación separada.

Volver atrás de forma segura

Antes del cambio se documentan el backup, la Route Precedence original, el estado de los túneles, las direcciones XFRM, los gateways, las reglas y las rutas. Si el recorrido redundante no es fiable:

1. Desactivar las nuevas rutas Backup.
2. Desactivar los gateways de ISP2 y el segundo túnel en lugar de eliminarlos inmediatamente.
3. Restaurar la Route Precedence original en ambos firewalls.
4. Restaurar las reglas y NAT al estado anterior documentado.
5. Volver a probar la ruta original de ISP1 con una nueva sesión de aplicación.

Las direcciones XFRM, los gateways o los túneles solo se eliminan cuando Object usage ya no muestra dependencias. Backup y restauración de Sophos Firewall explica el proceso de backup y recuperación.

FAQ