In Logs Explorer, every tunnel phase has its query:

Cloud VPN runs strongSwan underneath, so the messages are strongSwan’s: if you know charon, you already know how to read them.

What each message means

establishing IKE_SA failed, peer not responding. Cloud VPN sends IKE_SA_INIT and nobody answers. In order of likelihood: the peer is on IKEv1 and the tunnel on IKEv2 (or the reverse), the configured peer IP is not the real public one (NAT in front of the firewall), UDP 500 and 4500 do not reach the peer, or the peer does not even have the tunnel enabled. The PSK does not produce this message: with a wrong PSK, phase 1 starts and fails at IKE_AUTH.

IKE_SA … established between and then nothing. Phase 1 fine, phase 2 not. Look for CHILD_SA and traffic selectors.

Remote traffic selectors narrowed / Local traffic selectors narrowed. The phase 2 networks do not match on both sides. On HA VPN (and route-based Classic VPN) Cloud VPN proposes 0.0.0.0/0 on both sides and expects the same; a policy-based peer with specific subnets makes strongSwan narrow the selectors and pass traffic only between what matched, or nothing. On the peer: phase 2 with 0.0.0.0/0 local and remote (on pfSense, Routed mode, which creates an ipsecN tunnel interface), and routing handled by BGP or static routes.

received DELETE for ESP CHILD_SA in a loop. The peer tears phase 2 down every few minutes: mismatched phase 2 lifetimes with badly negotiated rekeys, or aggressive DPD. Match lifetimes (Cloud VPN uses 3 hours for phase 2 and 10 for phase 1) and let only one side initiate rekeys.

Comes up, passes traffic for a while, dies with NAT-T. A peer behind NAT on UDP 4500 and a middlebox that “helps” (IPsec ALG on the router) drops encapsulated ESP packets. Disable the ALG or move the firewall onto a direct public IP.

HA VPN with BGP against pfSense (FRR)

The tunnel comes up, bgp establishes, and no route comes in or goes out. FRR on pfSense starts with a policy that rejects everything not explicitly permitted:

1. Services → FRR → BGP → Route Maps: create ALLOW-ALL, Action Permit, Sequence 100, no criteria.
2. BGP → Neighbors → the Cloud Router peer: Remote AS the Cloud Router’s ASN, and under Peer Filtering assign ALLOW-ALL as route map in and out.
3. BGP → Network Distribution: list the local networks you want to advertise (or Default Originate if everything goes through the tunnel).
4. On GCP, the Cloud Router with --advertisement-mode custom if you want to control which prefixes go out; by default it advertises the VPC subnets.

Without step 2, vtysh -c "show ip bgp summary" shows the session Established with 0 prefixes in both directions, which is exactly the symptom.

Traps

• IKEv2 unless the peer cannot: IKEv1 is still supported, but without IPv6 and with fewer ciphers. Classic VPN still exists (99.9%), but part of its functionality is retired; new work goes on HA VPN (99.99%).
• Two tunnels per gateway on HA VPN for the 99.99%: if you only bring one up, the gateway status stays in warning even though it works.
• MTU: 1460 by default on the GCP VPC; with IPsec on top, let TCP do MSS clamping on the peer (pfSense does it on the tunnel’s ipsecN interface) or you will see transfers hanging after the handshake.
• Logs lag: a minute or two between the event and Logs Explorer. Refresh before changing the configuration again.
• A PSK with special characters copied from a password manager: check on the peer that nothing got eaten; the symptom is IKE_AUTH failing, not peer not responding.

See also

• pfSense: NAT reflection and split DNS — the other classic of “the tunnel is fine and I still cannot get there”.
• Cloud VPN troubleshooting in the Google Cloud documentation.