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. Los túneles basados en políticas y los túneles basados en rutas con Traffic Selectors concretos utilizan en su lugar un IPsec Failover Group.

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 gateway supervisado 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.

Any-to-Any no utiliza un VPN Failover Group adicional. Las interfaces XFRM con dirección, los gateways y las rutas seleccionan el recorrido. Configurar una VPN IPsec Site-to-Site explica la configuración básica completa de este tipo de túnel.

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 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.

Como Interface se selecciona la XFRM correspondiente. Si debe evaluarse todo el recorrido posterior, el Monitoring Target debería ser un endpoint estable y permitido detrás del peer. Un ping únicamente a la dirección XFRM del peer solo demuestra el tramo inmediato del túnel.

La selección del destino es una decisión operativa: debe responder de forma estable, no debe desaparecer durante un mantenimiento normal y necesita la autorización adecuada. Crear y comprobar un Custom Gateway explica en detalle 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.

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.

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.

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. Un túnel activo no garantiza que las sesiones TCP existentes o los estados de routing continúen sin interrupción.

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. strongswan.log y xfrmi.log ayudan con las capas IKE y XFRM; Troubleshooting de VPN IPsec explica el diagnóstico seguro.

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