Google HA VPN to a Cisco Router: Plan the Peer Resource First
Name both Google interfaces, the peer resource, the IKEv2 contract and each BGP session before configuring the Cisco router, then pick one peer or two.
The first decision in a Cisco-to-Google HA VPN is not which crypto profile to use, it is whether one on-premises device or two will terminate the tunnels. Google's HA VPN gateway has two interfaces, and each one expects a corresponding peer tunnel. That gives you two tunnels whether or not you have two routers, and the difference is whether a single power supply or software upgrade can take the whole design down.
The decision is one peer device or two
Pick the layout from three conditions: whether you can accept a local failure point, whether both cloud interfaces must be used, and how much reconvergence your workloads tolerate. If any of the three is a hard requirement, two peer devices is the honest answer.
Decide that before you open a console, because the answer changes how many tunnels and BGP sessions the worksheet has to describe.
Write the worksheet before any command
The worksheet has five rows, and each one needs an owner:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
The external peer resource describes your interfaces inside Google Cloud, and creating it does not configure the Cisco router. That asymmetry surprises people who expect the cloud console to be the source of truth for both ends. It is a declaration of what Google should expect, and the router still has to match it. Google's peer gateway guide maps that declaration onto the tunnel, BGP, firewall and IKE work you still owe.
If a row has no owner, it will be filled in by whoever is on shift during the cutover.
Keep the three address roles apart
The public peer addresses carry the outer IPsec exchange. The inside BGP pair belongs to the protected logical connection that runs over it. The advertised LAN and VPC prefixes describe the workloads behind that connection. Copying a VM's internal address into the external peer field mixes the first two roles, and the failure looks like a negotiation problem rather than a data-entry one.
Plan two corresponding peer tunnels, one for each HA VPN interface. Using both cloud interfaces does not by itself remove the local failure point, because both tunnels can still land on the same chassis.
Write the address role next to every value in the worksheet. That single habit prevents most of the mixing.
Translate the worksheet into the Cisco release
Start from the supported peer documentation or a matching Google configuration template for your platform, then reconcile every placeholder against the worksheet. Check IKEv2 authentication, ESP proposals, PFS and the tunnel and routing model together, because a mismatch in one of them usually presents as a mismatch in another. Use the actual platform and software release to select what is supported, since a Classic VPN recipe is a different starting point.
Keep the shared secret out of screenshots, ticket attachments and support notes. A pre-shared key pasted into a case comment is a credential disclosure, not a troubleshooting artefact.
If the template and the worksheet disagree, stop and resolve it on paper. The device will not arbitrate for you.
Accept each tunnel on its own evidence
HA VPN needs BGP sessions, and successful IKE negotiation establishes only the first stage. The inside session has to come up, the intended prefixes have to be advertised and accepted, and useful routes plus firewall permissions have to exist before workload traffic moves. Recording those as one green light hides which stage actually failed.
Record acceptance evidence per tunnel: negotiated security associations, BGP neighbor state, expected learned prefixes, and the intended workload path. Then run a controlled failure and recovery check, because a tunnel that has never failed is a tunnel whose recovery path is untested.
That record is reusable the next time the design changes, and it is the difference between an interoperation and a command fragment whose assumptions were lost.