Redundancia de túneles IPsec en AWS con FortiGate‑VM

Problema

En entornos híbridos es frecuente que una o más instancias de firewall virtual (por ejemplo FortiGate‑VM) se encarguen de los túneles IPsec que conectan la VPC de AWS con la red de la oficina corporativa. Cuando se despliegan dos firewalls idénticos, cada uno abre su propio túnel. El objetivo es que, si una instancia deja de responder —por falla del EC2, por problemas de software o por pérdida de la conexión a Internet— el tráfico de la VPC se redirija automáticamente al segundo túnel sin intervención manual. La dificultad radica en que AWS no ofrece un “IP SLA” integrado; la conmutación debe basarse en mecanismos de enrutamiento o de salud que el propio cliente configure.

Causa

1. Rutas estáticas únicas – Si la tabla de rutas de la VPC contiene solo una ruta hacia la red corporativa (por ejemplo 10.0.0.0/16 via igw‑tunnel‑a), la caída del túnel elimina la única vía disponible y el tráfico se pierde.
2. Ausencia de detección de fallos – Sin un proceso que verifique la disponibilidad del túnel, la tabla de rutas no se actualiza.
3. Diseño de arquitectura sin BGP – Cuando los túneles se crean como rutas estáticas, no hay intercambio dinámico de rutas que permita a AWS elegir automáticamente la mejor vía.
4. Uso de una sola AZ – Un EC2 que falla por problemas de zona de disponibilidad deja sin ruta a toda la VPC si la arquitectura no está distribuida.

Solución

1. Enrutamiento con rutas de igual coste (ECMP)

AWS permite varias rutas con la misma prioridad siempre que tengan la misma métrica (longitud de prefijo). Si se añaden dos rutas estáticas a la tabla de la VPC, cada una apuntando a la ENI del FortiGate‑VM correspondiente, el motor de enrutamiento enviará tráfico por ambas interfaces de forma balanceada (ECMP). Cuando una de las ENI desaparece, el motor elimina automáticamente esa ruta y el tráfico fluye por la única ruta restante.

Pasos clave

1. Crear dos ENI en la subred donde reside cada FortiGate‑VM. Cada ENI recibe una IP privada que será el “next‑hop” de la ruta.
2. Añadir rutas idénticas a la tabla de rutas de la VPC:
   • 10.0.0.0/16 via <ENI‑A>
   • 10.0.0.0/16 via <ENI‑B>
3. Habilitar “source/destination check” en ambas instancias para que actúen como routers.
4. Configurar los túneles IPsec en cada FortiGate‑VM apuntando a la IP pública de la oficina.

Con este esquema, la pérdida de una ENI (por ejemplo, por terminación del EC2) hace que la tabla elimine la ruta correspondiente y el tráfico sigue fluyendo por la otra.

2. BGP dinámico mediante AWS Transit Gateway

Si la arquitectura ya incluye un Transit Gateway (TGW), se puede aprovechar BGP para anunciar rutas a través de cada túnel. Cada FortiGate‑VM establece una sesión BGP con el TGW (usando el “Transit Gateway VPN attachment”). El TGW selecciona la mejor ruta basada en la métrica BGP (local‑pref, MED). Cuando una sesión BGP desaparece, el TGW retira automáticamente las rutas aprendidas por esa sesión.

Ventajas

• Escalabilidad: se pueden añadir más túneles sin tocar la tabla de rutas.
• Conmutación rápida: BGP detecta la caída en segundos.
• Compatibilidad con rutas de prefijo más específicas (por ejemplo, subredes de DMZ).

Implementación resumida

1. Crear dos VPN attachments en el TGW, cada una apuntando a la IP pública del FortiGate‑VM correspondiente.
2. Configurar BGP en cada FortiGate‑VM con el ASN del TGW (por defecto 64512).
3. Definir las rutas que el TGW debe propagar a la VPC (usualmente 0.0.0.0/0 o rangos corporativos).
4. Opcional: usar BGP “route‑map” para ajustar la preferencia (local‑pref) y garantizar que la ruta primaria tenga prioridad.

3. FortiGate HA activo‑pasivo con IPsec en modo “HA over AWS”

FortiGate‑VM soporta High‑Availability (HA) en modo activo‑pasivo usando una interfaz de sincronización (sync‑interface) dentro de la misma VPC. En este modelo:

• El nodo primario mantiene el túnel activo.
• El nodo secundario mantiene una sesión IPsec en “standby”.
• Cuando el primario falla, el secundario asume la dirección IP virtual (VIP) y el tráfico se redirige sin cambiar la tabla de rutas.

Para que AWS reconozca la conmutación, se debe asociar la VIP a una Elastic Network Interface y habilitar “Network Load Balancer (NLB) TCP health checks” que marquen la ENI como “in‑service” o “out‑of‑service”. El NLB no balancea el tráfico IPsec, solo sirve como detector de salud; al marcar la ENI del nodo primario como “unhealthy”, AWS deja de usarla como next‑hop.

4. Uso de AWS Site‑to‑Site VPN como respaldo

AWS permite crear dos túneles independientes por cada conexión VPN. Si los FortiGate‑VM ya gestionan los túneles, se puede crear una VPN Site‑to‑Site adicional (con la opción “static routing”) que apunte a la IP pública del segundo FortiGate‑VM. La tabla de rutas del TGW o de la VPC contendrá ambas rutas; la VPN de AWS actúa como fallback automático cuando la ruta estática del primer túnel deja de ser válida.

Cuándo aplicar esta solución

No se recomienda mezclar ECMP estático y BGP en la misma tabla sin una clara política de prioridad, ya que puede generar bucles de enrutamiento.

Código

# 1. Crear ENI para cada FortiGate‑VM (ejemplo en us-east-1)
aws ec2 create-network-interface --subnet-id subnet-0abc1234 --description "ENI FortiGate A"
aws ec2 create-network-interface --subnet-id subnet-0abc1234 --description "ENI FortiGate B"

# 2. Obtener los IDs de las ENI
ENI_A=$(aws ec2 describe-network-interfaces --filters Name=description,Values="ENI FortiGate A" --query "NetworkInterfaces[0].NetworkInterfaceId" --output text)
ENI_B=$(aws ec2 describe-network-interfaces --filters Name=description,Values="ENI FortiGate B" --query "NetworkInterfaces[0].NetworkInterfaceId" --output text)

# 3. Añadir rutas ECMP a la tabla de rutas de la VPC
aws ec2 create-route --route-table-id rtb-0123abcd \
    --destination-cidr-block 10.0.0.0/16 --network-interface-id $ENI_A
aws ec2 create-route --route-table-id rtb-0123abcd \
    --destination-cidr-block 10.0.0.0/16 --network-interface-id $ENI_B

Verificación

1. Comprobar rutas activas

   aws ec2 describe-route-tables --route-table-id rtb-0123abcd --query "RouteTables[0].Routes[?DestinationCidrBlock=='10.0.0.0/16']"
   

   Deberían aparecer dos entradas con NetworkInterfaceId diferentes.

2. Simular caída – Detener una de las instancias FortiGate‑VM. La ruta asociada a su ENI desaparece del output anterior.

3. Traceroute desde una instancia dentro de la VPC hacia una IP de la oficina corporativa. El primer salto debe ser la ENI que sigue activa.

4. En caso de BGP, usar show ip bgp summary en el FortiGate‑VM para confirmar que la sesión BGP está establecida y que la ruta aprendida tiene el atributo local-preference esperado.

5. Para HA con NLB, observar en la consola de EC2 que el estado de la ENI del nodo primario pasa a “unhealthy” y que el VIP se reasigna al nodo secundario.

Notas adicionales

• Health checks: Cuando se usa ECMP, la única forma de detectar una caída es mediante el estado de la ENI (terminación del EC2). Si la instancia sigue “running” pero el túnel está down, la ruta no se elimina automáticamente. En ese caso, combina ECMP con un script que ejecute aws ec2 replace-route al detectar pérdida de ping a la oficina.
• Preferencias BGP: Ajustar local-preference permite definir cuál túnel es “primario”. Un valor más alto gana sobre el más bajo.
• Costos: Cada ENI adicional y cada attachment de TGW generan cargos mensuales. Evalúa el número de túneles frente al presupuesto.
• Seguridad: Mantén las claves de IPsec sincronizadas entre los dos FortiGate‑VM. Un desbalance puede provocar que el túnel secundario no establezca la fase 2.
• Zonas de disponibilidad: Distribuye los FortiGate‑VM en al menos dos AZ diferentes para evitar un único punto de falla a nivel de infraestructura.

Con estas prácticas, la conectividad site‑to‑site entre AWS y la oficina corporativa permanece operativa pese a fallos de instancia, de