En Logs Explorer, cada fase del túnel tiene su consulta:

Cloud VPN corre strongSwan por debajo, así que los mensajes son los de strongSwan: si conoces charon, ya sabes leerlos.

Qué significa cada mensaje

establishing IKE_SA failed, peer not responding. Cloud VPN manda IKE_SA_INIT y nadie contesta. En orden de probabilidad: el peer está en IKEv1 y el túnel en IKEv2 (o al revés), la IP del peer configurada no es la pública real (NAT delante del firewall), UDP 500 y 4500 no llegan al peer, o el peer ni siquiera tiene el túnel activo. La PSK no produce este mensaje: con PSK incorrecta la fase 1 arranca y falla en IKE_AUTH.

IKE_SA … established between y después nada. Fase 1 bien, fase 2 no. Busca CHILD_SA y traffic selectors.

Remote traffic selectors narrowed / Local traffic selectors narrowed. Las redes de fase 2 no coinciden en los dos lados. En HA VPN (y en Classic VPN basada en rutas) Cloud VPN propone 0.0.0.0/0 a ambos lados y espera lo mismo; un peer policy-based con subredes concretas hace que strongSwan estreche los selectores y solo pase tráfico entre lo que casó, o nada. En el peer: fase 2 con 0.0.0.0/0 local y remoto (en pfSense, modo Routed, que crea una interfaz de túnel ipsecN), y las rutas se resuelven por BGP o estáticas.

received DELETE for ESP CHILD_SA en bucle. El peer tumba la fase 2 cada pocos minutos: lifetimes de fase 2 distintos con rekey mal negociado, o DPD agresivo. Iguala lifetimes (Cloud VPN usa 3 horas en fase 2 y 10 en fase 1) y deja que el rekey lo inicie un solo lado.

Sube, pasa tráfico un rato y muere con NAT-T. Un peer detrás de NAT con UDP 4500 y un middlebox que “ayuda” (ALG de IPsec en el router) descarta paquetes ESP encapsulados. Desactiva el ALG o pasa el firewall a IP pública directa.

HA VPN con BGP contra pfSense (FRR)

El túnel sube, bgp se establece, y ninguna ruta entra ni sale. FRR en pfSense arranca con una política que rechaza todo lo que no esté permitido explícitamente:

1. Services → FRR → BGP → Route Maps: crea ALLOW-ALL, Action Permit, Sequence 100, sin criterios.
2. BGP → Neighbors → el peer de Cloud Router: Remote AS el ASN del Cloud Router, y en Peer Filtering asigna ALLOW-ALL como route map in y out.
3. BGP → Network Distribution: lista las redes locales que quieres anunciar (o Default Originate si todo va por el túnel).
4. En GCP, el Cloud Router con --advertisement-mode custom si quieres controlar qué prefijos salen; por defecto anuncia las subredes de la VPC.

Sin el paso 2, vtysh -c "show ip bgp summary" muestra la sesión Established con 0 prefijos en ambas direcciones, que es exactamente el síntoma.

Trampas

• IKEv2 salvo que el peer no pueda: IKEv1 sigue soportado, pero sin IPv6 y con menos cifrados. Classic VPN sigue existiendo (99,9 %), pero parte de su funcionalidad está retirada; lo nuevo va en HA VPN (99,99 %).
• Dos túneles por gateway en HA VPN para el 99.99 %: si solo levantas uno, el estado del gateway queda en aviso aunque funcione.
• MTU: 1460 por defecto en la VPC de GCP; con IPsec encima, deja que TCP haga MSS clamping en el peer (pfSense lo hace en la interfaz ipsecN del túnel) o verás transferencias que se cuelgan tras el handshake.
• Los logs tardan: un minuto o dos entre el evento y Logs Explorer. Refresca antes de cambiar la configuración otra vez.
• PSK con caracteres especiales copiada de un gestor de contraseñas: comprueba en el peer que no se comió nada; el síntoma es IKE_AUTH que falla, no peer not responding.

Ver también

• pfSense: NAT reflection y split DNS — el otro clásico de “el túnel está bien y aun así no llego”.
• Cloud VPN troubleshooting en la documentación de Google Cloud.