Cloud VPN status: read the resource state before the IKE log

A Cloud VPN tunnel runs two lifecycles at once, and they are not on the same clock. The resource has to be allocated and configured before it can negotiate, and the protocol has its own sequence of IKE messages after that. A status field can report the first while saying nothing useful about the second. Reading them as one thing is how a key mismatch gets blamed for a provisioning delay.

Start with one tunnel object and one time window.

Two lifecycles, one tunnel object

The resource lifecycle is the provider preparing the tunnel: addresses, configuration, capacity. The protocol lifecycle starts once both peers hold enough configuration to exchange IKE_SA_INIT, then IKE_AUTH, then child security associations. A tunnel still in the first phase has not failed authentication, because authentication has not been attempted yet.

That distinction is the whole problem. Everything else is how to observe it without merging unrelated messages.

Read the object, not the console summary

Ask the API for the two fields that matter and nothing else, so the answer stays small enough to read at three in the morning: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". The status field names the lifecycle stage, and detailedStatus carries the readable reason attached to it. A full configuration dump answers different questions and is harder to paste into a ticket. Read-only calls like this cannot change the tunnel, which matters while the incident is still live.

Record the timestamp of the call beside the values, because both fields move.

ALLOCATING_RESOURCES is not a key mismatch

When the tunnel reports ALLOCATING_RESOURCES, the provider is still assembling the object. A pre-shared key mismatch cannot be observed at that stage, and a blocked peer port is equally unproven. What you can check is the detailed message, whether the project and service look healthy, and whether the tunnel configuration is complete enough for the peer to be contacted at all. Replacing the secret now changes a value that was never tested.

Wait for the state to move before drawing a conclusion about configuration.

ESTABLISHED is the start of the access checks

An established tunnel means IKE completed, not that traffic flows. Confirm the routes the tunnel carries and, where a Cloud Router is involved, confirm the BGP session and the prefixes it learned. Then test a permitted application exchange, because a firewall rule or a missing route can block traffic through a tunnel that is perfectly healthy. Each of those is a separate observation with a separate fix.

Status tells you which question to ask next. It never answers the access question for you.

Correlate one object and one time window

An old authentication failure in the log belongs to an earlier attempt unless its timestamp falls inside the window you are investigating. Pull the logs for the tunnel resource for the same minutes as the status you recorded, and keep the identifiers together. A later IKE event can show that negotiation has begun while the console message you are staring at is already stale.

If the tunnel recovers before you collect anything, say so. An undetermined cause is a better record than a confident story assembled from unrelated lines.

The next step is always the same shape: one object, one window, one stage. Anything wider is a summary, not a diagnosis.