Cloud VPN Limits You Cannot Tune: IKE Lifetime and Peer NAT

Give the remote device a 24-hour phase-1 lifetime and the Cloud VPN tunnel stays down, even though everything on the Google side is configured correctly. The peer is proposing a value the responder will not accept, so the negotiation either fails outright or restarts indefinitely. Cloud VPN caps phase 1 at 36,000 seconds, ten hours, and that cap is not a setting you can raise. The change belongs on the remote device.

The peer asks, the responder decides

IKE is a matching exercise between two proposal sets. The tunnel forms only where the sets overlap inside the bounds the responder accepts, which is why an out-of-range lifetime produces no partial tunnel at all. Treating the peer's configuration as a wish list rather than as a proposal is the usual mistake. An empty intersection leaves the tunnel down however correct the routing and selectors are.

Read the tunnel's own state before opening a case, because the detailed status usually names the stage that failed:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Compare what comes back with the supported set for your gateway type and IKE version, and record both traffic selectors while you are there. A selector mismatch gives the same down-tunnel symptom as an algorithm mismatch, and unlike the algorithm that one is yours to fix.

36,000 seconds is the ceiling

Phase 1 stops at 36,000 seconds. A device set to 86,400 is asking for something the responder will never agree to, and retrying does not change its mind. Dial the remote proposal back inside the range and the same configuration establishes; the asymmetry is the whole lesson, since you may lower your own value and cannot raise Google's.

Write the chosen value into the design notes. Otherwise the next engineer reruns the 24-hour experiment and reaches the same wall.

The supported set is published per gateway type and IKE version in the Cloud VPN overview, so read the section for your topology rather than a general IKE guide.

A tunnel that drops on a schedule

Phase 2 behaves differently: when the two ends disagree, rekeying follows the shorter interval. A peer that treats the mismatch as fatal drops the tunnel instead, so one mismatch can look like two unrelated faults. Watch the rekey rhythm, not just the first connect. A tunnel that comes up and then falls over on a regular beat is more often a lifetime mismatch than a routing defect.

Correlate those drop timestamps with the peer's own logs before editing anything, since a selector or route change can mimic the same rhythm. If the beat matches the phase 2 timer, the cause is found without touching a proposal.

Suites come from the gateway type

Cipher and integrity suites are not a per-tunnel profile you edit the way strongSwan lets you. You pick them by gateway type and IKE version, and hunting for a profile that does not exist wastes an afternoon.

A legacy device that offers nothing inside the supported set leaves two honest paths: replace the device, or terminate on a software gateway you control and route into the VPC from there. Anything else is a workaround that fails the next review.

One external address per device

The peer's external address has to map one-to-one onto its internal address. An overloaded PAT pool cannot work, because several hosts behind a single public address give the responder no way to demultiplex them. Where several hosts have to share an address, the tunnel must end somewhere that can tell them apart.

Keep that external address stable too. Move the device behind a different NAT and the association breaks even though every proposal still matches. Which values are Google's and which are yours is worth writing down: lifetimes, suites and one-to-one NAT are fixed on their side, while proposals, selectors, routing and BGP priorities are yours.