Conectar Sophos Firewall con AWS Site-to-Site VPN

Una AWS Site-to-Site VPN conecta una red local detrás de Sophos Firewall con una VPC de AWS o con un Transit Gateway. Técnicamente es una VPN IPsec, pero en operación se diferencia bastante de un túnel Sophos a Sophos: AWS crea dos túneles por conexión VPN, usa objetos Customer Gateway y gateway de destino, y el routing depende mucho de si se usan rutas estáticas o BGP.

Este artículo explica la implementación práctica con Sophos Firewall y AWS. Complementa la guía general Configurar una VPN IPsec site-to-site en Sophos Firewall con los puntos específicos de AWS: dos túneles, vecinos BGP, route tables, security groups, NACLs y comprobaciones de estado en AWS y Sophos. Si el túnel ya está activo pero el tráfico no pasa, encaja mejor Troubleshooting de VPN IPsec en Sophos Firewall.

Cuándo encaja este artículo

Este artículo encaja cuando una sede, un datacenter o una red local debe conectarse a AWS mediante Sophos Firewall. Cubre AWS Site-to-Site VPN hacia una VPC, un Virtual Private Gateway o un Transit Gateway. No cubre Sophos Firewall como appliance virtual dentro de AWS.

Escenarios típicos:

• red de servidores local hacia instancias EC2 en una VPC
• tráfico de backup, monitorización o gestión hacia AWS
• DNS híbrido, AD, jump hosts o redes administrativas
• migración de VPN estática a routing dinámico con BGP
• operación redundante con dos túneles AWS

AWS y Sophos usan términos distintos. En AWS se trabaja con Customer Gateway, Virtual Private Gateway o Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups y Network ACLs. En Sophos Firewall se trabaja con conexiones Amazon VPC, perfiles IPsec, interfaces XFRM, BGP, rutas y reglas firewall.

Planificar antes de configurar

AWS Site-to-Site VPN no debería tratarse como un simple import de una configuración de ejemplo descargada. El archivo de AWS ayuda, pero la puesta en producción depende de routing, security groups, NACLs, reglas firewall y pruebas con tráfico real.

Definir redes y gateway de destino

Primero hay que decidir qué lado de AWS se va a usar:

• Virtual Private Gateway para una VPC única clásica.
• Transit Gateway para varias VPC, varias sedes o un diseño de routing más amplio.
• Cloud WAN u otras variantes solo si la arquitectura de AWS lo exige explícitamente.

Documentar antes:

• CIDR de la VPC de AWS, por ejemplo 10.60.0.0/16
• subredes AWS y route tables relevantes
• redes locales detrás de Sophos Firewall, por ejemplo 172.16.20.0/24
• IP pública de Sophos Firewall o del router upstream
• modo de routing: static o dynamic BGP
• ASN local y de AWS si se usa BGP
• destinos de prueba esperados en ambos lados
• opciones de túnel previstas, versión IKE, preshared keys y lifetimes

Las redes solapadas deberían corregirse antes de diseñar la VPN. NAT sobre IPsec puede funcionar, pero complica route tables, security groups, logs y troubleshooting.

Tomarse en serio los dos túneles

AWS crea dos túneles por cada Site-to-Site VPN connection, cada uno con un endpoint AWS distinto. Ambos túneles deberían configurarse y verificarse en Sophos Firewall. Crear solo un túnel puede ser cómodo en laboratorio, pero en producción desperdicia la redundancia de AWS.

La expectativa debe ser correcta: el retorno desde AWS prefiere un túnel según el routing y el lado AWS, y puede conmutar si hay fallo. Eso no significa que ambos túneles se usen siempre de forma equilibrada. Lo importante es que ambos suban, que BGP o las rutas estáticas sean correctos y que el failover se haya probado.

Routing estático o BGP

AWS Site-to-Site VPN admite rutas estáticas y routing dinámico con BGP. BGP suele ser mejor cuando hay varios prefijos, ampliaciones futuras o Transit Gateway. Las rutas estáticas son más simples, pero cada cambio de red debe mantenerse manualmente.

En la práctica:

• BGP necesita valores ASN coherentes en ambos lados.
• Sophos Firewall debe anunciar los prefijos locales previstos.
• Las route tables de AWS deben usar realmente las rutas propagadas o estáticas.
• Security groups y NACLs también deben permitir el tráfico.
• Rutas estáticas y BGP idénticas pueden crear prioridades inesperadas.

Preparar AWS

Los siguientes pasos describen el flujo habitual. Los detalles cambian entre Virtual Private Gateway y Transit Gateway, pero el principio es el mismo.

Crear el Customer Gateway

El Customer Gateway describe el lado Sophos local en AWS.

Introducir:

1. En la consola de AWS, ir a VPC > Virtual private network (VPN) > Customer gateways y elegir Create customer gateway.
2. Definir Name tag, por ejemplo cgw-sophos-hq.
3. Si se va a usar BGP, configurar BGP ASN exactamente con el ASN local de Sophos. AWS también muestra este campo para conexiones con routing estático, pero el routing estático no establece peering BGP.
4. En IP address, introducir la dirección estática alcanzable desde Internet del lado Sophos. Si el firewall está detrás de un dispositivo NAT situado delante de él, introducir en el AWS Customer Gateway la IP pública de ese dispositivo NAT, no la dirección de la interfaz WAN de Sophos.
5. Opcionalmente indicar en Device un nombre claro y elegir Create customer gateway.

Si Sophos Firewall está detrás de un router o equipo del proveedor, debe estar claro qué IP pública ve AWS y si NAT-T funciona correctamente. Para el Customer Gateway, se debe permitir UDP 500 y, cuando se usa NAT-T, UDP 4500 entre la red local y los endpoints de AWS Site-to-Site VPN. Configurar el dispositivo NAT/firewall situado delante de Sophos para permitir y reenviar esos puertos entre la interfaz WAN de Sophos y las direcciones de ambos endpoints de túnel AWS incluidas en el archivo de configuración.

Crear o seleccionar el gateway de destino

Para una sola VPC normalmente se crea un Virtual Private Gateway en VPC > Virtual private network (VPN) > Virtual private gateways y se adjunta mediante Actions > Attach to VPC. En entornos AWS mayores se usa a menudo un Transit Gateway.

Comprobar:

• El gateway está adjunto a la VPC o Transit Gateway correcto.
• El ASN del lado AWS no colisiona con el ASN de Sophos.
• Las route tables de la VPC o del Transit Gateway están planificadas.
• Las subredes usadas para pruebas utilizan la route table correcta.

Crear la Site-to-Site VPN connection

Después, ir a VPC > Virtual private network (VPN) > Site-to-Site VPN connections y elegir Create VPN connection.

Puntos importantes:

• En Target gateway type, seleccionar el Virtual Private Gateway o Transit Gateway previsto.
• En Customer gateway, elegir Existing y el Customer Gateway creado anteriormente.
• Configurar Routing options como Dynamic (requires BGP) o Static; en Static IP prefixes, introducir solo los prefijos locales que AWS debe alcanzar por la VPN.
• Revisar deliberadamente Tunnel Options, especialmente IKE version, encryption, integrity, DH/PFS y DPD.
• Documentar las preshared keys por túnel o dejar que AWS las genere de forma consciente.

Para el enrutamiento dinámico, Sophos exige que Local IPv4 Network Cidr y Remote IPv4 Network Cidr tengan el valor 0.0.0.0/0 en la conexión AWS para que pueda establecerse el peering BGP. Si ya existe un Local AS configurado en el firewall, se introduce exactamente ese ASN en el AWS Customer Gateway.

Después de crearla, elegir Download configuration. Para la importación automática de Sophos, elegir Vendor Sophos, Platform Sophos Firewall, Software v19+ y la IKE version realmente prevista. El archivo es solo una configuración de ejemplo: los algoritmos, grupos DH, certificados y la familia IP deben ajustarse al diseño de producción. Si Sophos está detrás de NAT, antes de importar introducir la dirección local de la interfaz WAN de Sophos en los dos bloques tunnel_outside_address del lado del customer gateway. Dejar sin cambios los endpoints outside del lado AWS; no sustituir indiscriminadamente todos los bloques XML con el mismo nombre. En cambio, el AWS Customer Gateway conserva la dirección pública del dispositivo NAT situado delante de Sophos. Para rutas estáticas, elegir Generic y configurar manualmente. También se puede configurar manualmente BGP dinámico con la descarga Generic descrita a continuación; la importación Sophos no es la única opción para BGP.

Comprobar route tables, security groups y NACLs

Un túnel VPN en verde en AWS todavía no significa que una instancia EC2 sea alcanzable.

Para la validación, comprobar:

• La route table de la VPC tiene una ruta hacia la red local vía Virtual Private Gateway o Transit Gateway.
• Con Virtual Private Gateway, route propagation está activada o la ruta está configurada de forma estática.
• Las route tables del Transit Gateway contienen attachments y propagations correctos.
• El security group de la instancia destino permite el tráfico requerido desde la red local.
• Las Network ACLs permiten ida y vuelta.
• El firewall del sistema operativo de la instancia no bloquea la prueba.

Esta parte se olvida a menudo porque Sophos y AWS pueden mostrar un túnel conectado aunque la instancia no responda por security group o ruta de retorno.

Configurar Sophos Firewall

Sophos ofrece dos caminos prácticos para AWS: import mediante Site-to-site VPN > Amazon VPC o configuración manual como conexión IPsec route-based. En muchos despliegues AWS, el import es el punto de partida más limpio, pero los objetos creados automáticamente deben revisarse.

Importar la configuración AWS

En Site-to-site VPN > Amazon VPC, Sophos Firewall puede importar la conexión mediante Use AWS security credentials o Use VPC configuration file. Para el método con credenciales se utiliza un usuario IAM de AWS dedicado con los permisos necesarios para los ajustes de Site-to-Site VPN; su access key y secret key se protegen y rotan como cualquier otro secreto administrativo.

La importación es una instantánea. Si se cambian las opciones de túnel u otros valores de conexión en AWS, hay que importar de nuevo los ajustes y repetir después toda la validación. Una importación anterior no se adapta automáticamente a la configuración de AWS.

El procedimiento siguiente utiliza el archivo de configuración AWS descargado:

Pasos:

1. Abrir Sophos Firewall.
2. Ir a Site-to-site VPN > Amazon VPC.
3. Seleccionar Use VPC configuration file.
4. Subir el archivo de configuración AWS.
5. Iniciar el import.
6. Comprobar conexiones, perfiles IPsec, interfaces XFRM y ajustes BGP creados.

La importación crea perfiles IPsec, ajustes BGP e interfaces XFRM. A continuación se añaden los prefijos locales en Routing > BGP > Networks. En Administration > Device access, IPsec debe estar activado para WAN y Dynamic Routing para VPN. Estas opciones permiten el tráfico de control del túnel y del enrutamiento; no sustituyen una regla de firewall para el tráfico útil.

Si Sophos está detrás de NAT, comprobar en cada una de las dos secciones de túnel que el tunnel_outside_address del lado del customer gateway contiene la dirección WAN local de Sophos. No cambiar las direcciones outside del lado AWS; la dirección pública de NAT sigue siendo la dirección del AWS Customer Gateway. Si la asignación no está clara, no activar el archivo ni los objetos importados; identificar primero de forma inequívoca el lado del cliente y el lado AWS.

Configurar manualmente dos túneles IPv4 hacia un VGW con BGP

Esta alternativa describe una conexión IPv4 a un Virtual Private Gateway adjunto a la VPC con Dynamic (requires BGP). No es un runbook de IPv6/Transit Gateway/Cloud WAN ni una afirmación general de que AWS no admita IPv6. Los requisitos previos son permisos AWS, derechos de administración locales, endpoints outside alcanzables, redes sin solapamiento y un procedimiento de reversión aprobado. No activar a la vez la importación y una configuración manual paralela para las mismas rutas.

1. En AWS, abrir Download configuration en la conexión VPN prevista: Vendor Generic, Platform Generic, Software Vendor agnostic, IKE version ikev2. Esto se aplica expresamente también a BGP dinámico manual. El archivo contiene PSK: guardarlo cifrado y con acceso restringido.
2. Registrar por separado para cada túnel el endpoint outside, la PSK, el CIDR inside, la dirección inside del cliente, la dirección inside de AWS y los ASN a partir de la configuración realmente generada. Usar dos redes /30 distintas, aceptadas por AWS, de 169.254.0.0/16; no utilizar rangos reservados ni ya utilizados. La siguiente asignación es un ejemplo de planificación legible, no una asignación realizada por AWS:

Tabla de asignación: la IP outside establece IPsec; la IP inside proporciona el direccionamiento de XFRM y BGP. Usar exclusivamente las direcciones realmente proporcionadas por AWS: no deducir la asignación propia a partir del orden de las direcciones de demostración. La dirección XFRM de SFOS es la dirección inside del cliente, nunca la dirección inside de AWS ni la IP pública. El vecino BGP es la dirección inside de AWS, no el endpoint outside.

3. En Profiles > IPsec profiles > Add, crear un perfil personalizado con un nombre inequívoco. Un ejemplo de alcance limitado para túneles configurados así en ambos lados es IKEv2, fase 1 AES256 / SHA2 256 / DH 14 (DH2048) y fase 2 AES256 / SHA2 256 / PFS 14 (DH2048). Activar Re-key connection; usar Key negotiation tries 0 y Use strict profile desactivado solo si lo prevé el plan operativo aprobado. Los algoritmos y grupos DH/PFS seleccionados deben formar una propuesta común permitida, no simplemente llevar el mismo nombre de perfil.
4. Documentar por separado los lifetimes y Rekey/DPD. Un ejemplo histórico indica para la fase 1 de AWS 28800 segundos, pero para SFOS Key life 28000; para la fase 2, 3600 en ambos casos, Rekey Margin 360 y Fuzz 50 por ciento. Unos temporizadores locales de rekey IKEv2 distintos no constituyen automáticamente un error de propuesta ni demuestran una interoperabilidad probada. No adoptar silenciosamente un temporizador contradictorio como estándar universal: usar los valores realmente configurados en AWS y un plan de rekey SFOS aprobado para ellos; si las condiciones no están claras, detenerse y aclararlas. Un ejemplo de DPD es AWS Restart y, en SFOS, DPD activado, intervalo de comprobación 30, tiempo de espera de respuesta 120 segundos y Re-initiate. Estos valores son un ejemplo de perfil que debe comprobarse, no una configuración universal. Antes del uso en producción, confirmar el comportamiento de Rekey/DPD en la ventana de cambio propia.
5. En Site-to-site VPN > IPsec > Add, crear una conexión independiente por túnel con Connection type Route-based (Tunnel interface), IP version IPv4 y Gateway type Initiate the connection. En Profile, seleccionar el perfil personalizado que se acaba de comprobar, no otro perfil predeterminado llamado IKEv2 sin revisarlo. Establecer Authentication type Preshared key y exactamente la PSK de ese túnel. Listening interface es la interfaz WAN local; Gateway address es el endpoint outside de AWS correspondiente. Establecer los ID IKE locales/remotos únicamente según el plan de identidades realmente esperado, nunca usar IP arbitrarias; detrás de NAT, la dirección WAN local no equivale a la dirección pública del Customer Gateway. Seleccionar Activate on save solo en la ventana aprobada, tras la revisión; guardar y activar ambas conexiones.
6. En Network > Interfaces, abrir el XFRM que pertenece a cada conexión y comprobar el enlace de conexión. En IPv4/netmask, introducir la IP inside del cliente y /30 (255.255.255.252) de ese túnel. En el segundo XFRM, usar su propia IP inside; no intercambiar las asignaciones.
7. En Routing > BGP > Global configuration, conservar el Local AS ya utilizado o establecer el ASN aprobado del Customer Gateway. Usar una Router ID única y estable del plan propio. No sobrescribir un ASN global existente para esta VPN; AWS debe usar el mismo valor de ASN local. No copiar sin verificar un rango ASN ni un ASN de demostración: comprobar primero su disponibilidad, su admisibilidad en AWS y la ausencia de conflictos. En Neighbors, crear para cada IP inside de AWS un vecino IPv4 con Remote AS igual al ASN real del VGW.
8. En Routing > BGP > Networks, anunciar solo los prefijos aprobados y alcanzables localmente. En Administration > Device access, permitir IPsec para WAN y Dynamic Routing para VPN; no añadir una autorización general para LAN si allí no se ha previsto un peer de routing local. Abrir BGP TCP 179 como tráfico de datos a todo Internet o entre todas las redes LAN/VPN no sustituye esta autorización del plano de control. Crear además las reglas de datos estrictamente limitadas que se describen en la siguiente sección.
9. Para cada vecino, comprobar en Routing > Information > BGP > Neighbors el estado Established y los prefijos aprendidos y anunciados esperados. En AWS, en Tunnel Details, comprobar que ambos túneles están UP y revisar las rutas BGP; comprobar la propagación de rutas del VGW en las Route Tables de las subredes afectadas. Solo después, probar el tráfico de aplicación permitido y un origen no permitido. En la ventana acordada, desactivar un túnel de forma controlada, comprobar que la ruta/aplicación esperada se mantiene a través del otro, volver a activarlo y comprobar de nuevo ambas vecindades; sin una prueba real de failover, no afirmar que se ha aceptado la redundancia.

Ante errores IPsec, comprobar primero por túnel el endpoint, la PSK, las propuestas, los ID y NAT-T; si BGP está en Active, comprobar primero las direcciones inside de XFRM, el ASN, la activación del peer y Device Access. Una ruta estática provisional con ping no es una reparación BGP general y puede ocultar un recorrido incorrecto. Si desaparecen rutas existentes o la asignación de lifetimes/ID no está clara, no seguir probando valores: detener la nueva configuración y compararla con el estado guardado.

Comprobar perfil IPsec y túneles

Después del import, o en configuración manual, no hay que confiar solo en el estado.

Comprobar:

• Existen los dos túneles AWS.
• La versión IKE coincide con la configuración AWS.
• Encryption, Authentication, DH Group y PFS forman, para cada túnel, una propuesta permitida en ambos extremos; los lifetimes y los temporizadores locales de rekey se comprueban por separado respecto al plan aprobado, sin reducir la comprobación a una mera igualdad numérica.
• La preshared key es correcta por túnel.
• Gateway type y remote gateway apuntan a los endpoints AWS correspondientes.
• Las interfaces XFRM existen y tienen nombres claros.

Si se modifican las opciones de túnel de AWS, las propuestas de Sophos deben seguir siendo compatibles y los temporizadores de rekey y DPD, documentados por separado, deben ajustarse al plan operativo aprobado. Los cambios unilaterales de algoritmo, DH/PFS, PSK o identidad pueden impedir que se establezca la fase 1 o la fase 2; las diferencias entre los lifetimes locales de IKEv2, por sí solas, no demuestran un error de compatibilidad de las propuestas.

Configurar BGP o rutas estáticas

Con BGP, en Routing > BGP se comprueba que ASN local, neighbor, ASN remoto y redes anunciadas sean correctos. Configurar BGP en Sophos Firewall explica la configuración y validación completas. En Routing > Information > BGP, Neighbors, Summary y Routes deberían mostrar los valores esperados.

Con routing estático, las rutas hacia redes AWS deben apuntar a la interfaz XFRM correcta. AWS también debe conocer los prefijos locales, ya sea mediante rutas VPN estáticas o mediante la route table correspondiente.

En ambas variantes, el routing debe ser correcto en ambos sentidos. Un túnel puede estar conectado mientras el retorno sale por Internet, por un NAT Gateway o por una route table equivocada.

Crear reglas firewall

Route-based IPsec no crea automáticamente reglas firewall de producción suficientemente limpias. Conviene crearlas y registrarlas de forma consciente.

Recomendado:

1. En Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, crear la regla local-a-AWS: Source zones LAN, Source networks and devices el objeto de red local, Destination zones VPN y Destination networks el objeto de red AWS.
2. En Services, seleccionar solo los servicios necesarios; usar Any únicamente de forma temporal para aislar un problema y sustituirlo después.
3. Permitir conexiones en el sentido contrario con Source zones VPN y Destination zones LAN solo si AWS debe alcanzar activamente sistemas locales.
4. Activar Log firewall traffic para la validación.
5. Comprobar la posición de la regla antes de reglas drop o catch-all amplias.

Si la regla esperada no coincide, usar Regla de Sophos Firewall no coincide: cómo encontrar la causa.

Validar la conexión

La validación debe incluir siempre ambas plataformas y tráfico de aplicación real. Un estado de túnel verde no basta.

Comprobar AWS

En AWS, comprobar:

• VPC > Site-to-Site VPN Connections > Tunnel Details muestra ambos túneles.
• El estado del túnel es UP.
• Con BGP, las rutas son visibles.
• La route table de la VPC o Transit Gateway contiene las rutas esperadas.
• Security groups y NACLs permiten la prueba.
• Métricas CloudWatch o VPN logs no muestran problemas IKE o DPD repetidos.

Comprobar Sophos Firewall

En Sophos Firewall, comprobar:

• Site-to-site VPN > Amazon VPC o Site-to-site VPN > IPsec muestra túneles activos.
• Routing > Information > BGP muestra vecinos y rutas aprendidas si se usa BGP.
• Network > Interfaces muestra interfaces XFRM.
• Log Viewer muestra la regla firewall esperada.
• Packet Capture confirma interfaz de entrada y salida si los logs no bastan.

Elegir bien el tráfico de prueba

Una prueba debe usar un host origen, host destino y servicio concretos, por ejemplo ICMP, RDP, SSH, HTTPS o DNS. Si ICMP está bloqueado, un ping no es significativo. Es mejor probar el servicio que se usará realmente.

Errores típicos

Los errores de AWS VPN a menudo parecen problemas IPsec aunque la causa sea routing o controles de seguridad AWS. Estos casos son especialmente frecuentes.

Solo un túnel está activo

Un túnel basta para una primera prueba, pero no para una operación correcta. Ambos túneles AWS tienen endpoints y parámetros propios. Comprobar por túnel preshared key, parámetros IKE/IPsec, interfaz XFRM, vecino BGP y estado AWS.

BGP no levanta

Si el túnel está conectado pero BGP no forma peering, se comprueban primero ASN, IP del vecino, anuncios locales y direcciones inside tunnel. Existe un caso concreto de Sophos cuando el túnel AWS VPC aparece activo y conectado en el firewall, el vecino BGP permanece en Active, AWS muestra la VPN como down mientras IPsec está up y la configuración BGP activa contiene no bgp default ipv4-unicast.

Solo cuando coinciden todas estas características se registran la configuración BGP actual, Local AS y la IP del vecino. Después se abre la consola BGP mediante 3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP y se activa exactamente el vecino AWS afectado:

enable
conf t
router bgp <as-number>
neighbor <ip-address> activate
write

<as-number> se sustituye por el ASN local de Sophos y <ip-address> por la dirección inside tunnel del vecino AWS afectado. A continuación se vuelven a comprobar el resumen BGP, los prefijos aprendidos y anunciados, el estado del túnel AWS y el tráfico real. Si no aparece no bgp default ipv4-unicast o no coinciden las direcciones y ASN de AWS, no se aplican estos comandos. El comando procede del procedimiento de troubleshooting de SFOS 22 limitado a conexiones Amazon VPC y no es una reparación BGP general.

Antes de conf t, documentar la configuración BGP actual y el método de recuperación aprobado para el entorno. Si el vecino no llega a Established o desaparecen rutas existentes, no improvisar y usar únicamente ese método probado de antemano. Si no existe, detenerse antes del cambio y escalar al soporte de Sophos.

Túnel verde, instancia no alcanzable

La causa suele estar fuera de IPsec: route table AWS incorrecta, route propagation ausente, security group, NACL, firewall del sistema operativo, red origen incorrecta o regla Sophos ausente.

El retorno va por el camino equivocado

AWS debe conocer el retorno hacia la red local por VPN. Localmente, el retorno hacia la VPC AWS debe ir por XFRM o BGP. El routing asimétrico puede parecer normal en el estado del túnel, pero romper sesiones reales.

MTU o fragmentación afectan aplicaciones

AWS Site-to-Site VPN y la sobrecarga IPsec pueden hacer visibles problemas de MTU. Si pruebas pequeñas funcionan pero transferencias grandes o ciertas aplicaciones se quedan colgadas, comprobar MSS/MTU, fragmentación y capturas de paquetes.

Operación y revisión

Después del go-live, el túnel debe pasar al proceso operativo normal. Esto incluye owner, proceso documentado para preshared keys, ventana de cambio para parámetros IPsec, monitorización de túneles, pruebas regulares de failover y un procedimiento claro para cambios de AWS o ISP.

Cada cambio en CIDR de VPC, routing de Transit Gateway, route tables, security groups, redes locales o anuncios BGP debe repetir la validación VPN. Cloud VPN no es un clic único, sino parte de la arquitectura de red.

Revertir selectivamente los nuevos túneles y rutas

Antes del cambio, guardar el backup, los perfiles IPsec y la asignación de túneles, las direcciones XFRM, los vecinos/anuncios BGP, las reglas firewall y las Route Tables de AWS con su propagación. Si aparecen anuncios inesperados, un destino incorrecto o una interrupción del tráfico existente, retirar primero los prefijos recién introducidos o desactivar la nueva conexión y devolver únicamente las reglas/rutas modificadas al estado seguro documentado. No eliminar ni restablecer los vecinos BGP existentes, el ASN global ni gateways/VPC/subredes compartidos. Volver a comprobar las rutas existentes previstas, las aplicaciones permitidas y el bloqueo de un origen no permitido. Si no hay un procedimiento de reversión aprobado, detener el cambio antes de la activación.

FAQ