Cloud VPN to Cisco ASA: Rebuild After a Proposal Mismatch

NEGOTIATION_FAILURE on a Cloud VPN tunnel with a Cisco ASA at the far end is almost always a proposal or selector disagreement, and the first useful fact is that no edit will fix it. Cloud VPN fixes the IKE proposal when the tunnel object is created. There is no field for changing an algorithm in place, so the repair is a delete and a recreate with a recorded starting point. Treat it as a rebuild and the work becomes a checklist rather than an afternoon of guessing.

Read the failure before you delete anything

A negotiation failure is a phase problem, and the peer log usually names the phase. Phase 1 failing means the ends could not agree on a proposal or could not authenticate each other. Phase 2 failing means the tunnel came up and the protected selectors did not match. Those are different repairs, and the log line is worth extracting before anyone touches a configuration.

The failure also rules things out. It is not a VPC route, not a firewall rule on the tunnel interface, and not a name-resolution fault inside the network. Chasing those produces confident changes that cannot alter the outcome, and they make the eventual fix harder to attribute.

Capture both configurations while they still exist

Deleting a tunnel takes half a minute and destroys the only evidence you had. Before that, write down the local and remote selectors, the peer address, who owns the shared secret, and the ASA's crypto map or IKEv2 profile. The ASA answers two separate questions, what is configured and what is currently up:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

On the Google side, read the tunnel object rather than the console summary, because the peer address and the selector fields are the values you must reproduce exactly:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Put those values in the ticket before the first delete. The rebuild below only works because you can recreate the same object with one deliberate difference.

The algorithms one side refuses to negotiate

Cloud VPN does not pick from a range of IKEv1 algorithms the way a traditional peer does. The peer settings it expects are fixed: aes-cbc-128 for encryption, sha1-96 for both integrity and PRF, Diffie-Hellman group 2, 36,600 seconds for phase 1 and 10,800 seconds for phase 2. The ASA policy has to offer that exact set. A second proposal on the ASA does no harm as long as the matching one is in the list too.

IKEv2 gives both sides more room, but the rules keep the same shape: enable PFS, choose a DH group the tunnel supports, and keep the proposal list short enough that a mismatch is obvious. An ASA peer on Cloud VPN also means static routing, so the protected prefixes have to be planned and listed rather than left to BGP.

A lifetime copied from another vendor template is the usual wrong turn here. Google publishes these values as required peer settings, so set them; a shorter value is not negotiated up to what the ASA wants.

Delete, recreate, and clear the old state

Delete the tunnel, not the gateway, and note the name Cloud VPN gives the replacement, since names are assigned rather than reused. Recreate it with the recorded values and the same peer address, then add the matching proposal to the ASA policy list.

Clear the security associations after the ASA change and before you read the result. An ASA can keep offering a stale policy until the current SA expires, so a correct configuration looks broken for the length of the old lifetime and the watcher concludes the rebuild failed when it had not started:

clear crypto ikev2 sa
clear crypto ipsec sa

Confirm that phase 1 comes up before looking at phase 2. While phase 1 is down, the proposal or the pre-shared key is wrong, and selector work will not change that.

Selectors mirror, then counters decide

Phase 2 works only when both ends agree on the addresses being protected, and the agreement is mirrored rather than shared. The Google local selector has to match the selector the ASA calls remote, and the Google remote selector has to match what the ASA calls local. A tunnel with 0.0.0.0/0 on one side and a single subnet on the other clears phase 1 and then fails phase 2 with the same headline error. Neither side can widen the other's list.

For policy-based selectors, list every prefix pair and keep the list in the ticket. A subnet added on-premises later needs an edit at both ends, because a new route on the ASA does not widen a selector, and the result is a tunnel that is up and passes traffic only for the prefixes that existed on day one.

Finish with one host-to-host flow and read byte counters on both sides. Counters climbing on the ASA while staying flat on Google usually mean the reply leaves through a different interface, or the selector does not cover the return prefix. Record the algorithms, lifetimes, selectors and the new tunnel name, because the next proposal change repeats this rebuild and those values turn it into a short job.