GCP HA VPN BGP stuck at Waiting for peer: the address-pair swap
A Cloud VPN BGP session stuck at Waiting for peer usually has the tunnel and peer addresses swapped. Check the pair before you rebuild anything.
A BGP session that never reaches Established on a Cloud VPN tunnel is usually not a routing problem. It is a wiring problem: two addresses that must mirror each other were entered the wrong way round, or the first tunnel's pair was reused on the second. The tunnel itself can be perfectly healthy while the session sits at Waiting for peer, because IPsec and BGP are separate negotiations between the same two endpoints. Decide which of those two is broken before you rebuild anything.
One question settles most cases: does the peer device see the Cloud Router's address at all?
Tunnel state and session state are different checks
IKE and ESP come first. If the tunnel is not established, nothing inside it matters and the BGP address discussion is premature. Read the tunnel's status and detailed status, then read the router's BGP peer status for that same tunnel.
A tunnel that is up while its BGP peer is down narrows the fault to the session: peer address, ASN, or TCP 179 arriving on the inner address. A tunnel that is up, a session that is up, and still no routes in the VPC is a third case. Changing addresses will not help that one, because the session already works and the prefix is simply not being advertised or not being preferred. Keeping those three cases apart is most of the work.
Each tunnel needs its own /30, with both ends filled in
Every HA VPN tunnel gets a link-local /30 out of 169.254.0.0/16, with one address on the Cloud Router interface and the other on your peer. The peer field must name the far end, never the router's own address.
Two tunnels mean two interfaces on the Cloud Router, each with a different /30. Reusing tunnel 0's pair on tunnel 1 is the mistake that looks tidy in a summary table and dies in the OPEN packet.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Read the pair from the router resource rather than from the console summary. The summary lists the peer address in a column that is easy to misread, and the interface's ipRange plus the peer's peerIpAddress have to describe opposite ends of one /30.
The swap usually happens during a rebuild
Rebuilding a tunnel is where pairs get crossed. The old tunnel's peer address is copied into the new tunnel's interface field, or the new session is pointed at the previous session's peer. Either way the Cloud Router sends OPEN packets to an address that is now itself or an address with no tunnel behind it.
Write the pairs down before opening the console: tunnel name, interface, router address, peer address, peer ASN. Then create both tunnels in one pass, so the second one is not filled in from the first one's leftovers.
Three other reasons a session waits
The peer ASN is the first: each side must be configured with the other side's ASN, and a mismatch reaches the peer but never establishes. The second is the peer's own firewall, which has to allow TCP 179 on the tunnel interface; an IKE or ESP rule does not cover it. The third is a peer that replies from a different source address than the one configured as its neighbor.
The peer's own log is the discriminator. If its BGP summary lists no neighbor for that address, packets are not arriving and the pair or the path is wrong. If the neighbor sits in Active or Connect, packets arrive and the session parameters disagree.
Verify in the order the packets travel
Work outward: tunnel status, then router BGP peer status, then the peer's BGP summary, then the routes. If the first two are healthy, stop editing the Cloud VPN side and work on the peer device. If the router reports the peer as down and your device has no neighbor, the pair is wrong or the BGP port is filtered. A packet capture on the peer's tunnel interface settles it in one look, because OPEN packets either arrive there or they never do.
gcloud compute routers get-status ROUTER --region=REGION prints the peer state beside the address it is using, which is exactly the pair you need to compare.
Once the session establishes, confirm that the learned prefix appears in the VPC route table and that one host on each side answers. Then record the final pairs next to the tunnel names, so the next rebuild starts from a known-good table instead of the console summary.