En corto

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

Qué buscasConsulta
Cloud VPN no llega al peerresource.type="vpn_gateway" "establishing IKE_SA failed, peer not responding"
Fase 1 arrancaresource.type="vpn_gateway" ("initiating IKE_SA" OR "generating IKE_SA_INIT request")
Autenticación IKEresource.type="vpn_gateway" ("generating IKE_AUTH request" OR "parsed IKE_AUTH response")
PSK aceptadaresource.type="vpn_gateway" ("authentication of" AND "with pre-shared key successful")
Fase 1 establecidaresource.type="vpn_gateway" ("IKE_SA" AND "established between")
Todo lo de fase 2 (incluye rekeys)resource.type="vpn_gateway" "CHILD_SA"
Las subredes no coincidenresource.type="vpn_gateway" ("Remote traffic selectors narrowed" OR "Local traffic selectors narrowed")
Alguien cierra la fase 2resource.type="vpn_gateway" ("received DELETE for ESP CHILD_SA" OR "sending DELETE for ESP CHILD_SA")

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