GCP HA VPN Rejects FortiGate: Local ID Type Mismatch

AUTHENTICATION_FAILED from Google Cloud HA VPN usually sends people back to the pre-shared key, and the key is normally correct. The tunnel stalls in phase 1 because Google compares something else as well: the identity the peer asserts during the IKE exchange. On a FortiGate that identity can change type without anyone editing an address. Read the log as an identity mismatch once the key has been re-entered twice.

One failure, two checks

IKE verifies a peer in two separate steps. The pre-shared key proves both ends hold the same secret, and an asserted identity tells the responder who the peer claims to be. Google checks that identity against the peer it was configured with. Left alone, a FortiGate sends an address-based identity derived from its outgoing interface, and the comparison passes without anyone noticing it happened.

Both steps land in the same bucket in the log, which explains the familiar loop of retyping the key four times before anyone reads the identity payload.

What a FortiGate puts in the identity payload

The trouble starts when someone sets a local ID to make the two sides agree. Recent FortiOS builds mark that identity as a fully qualified domain name even when the value typed in is a dotted address. Google therefore receives an FQDN identity while expecting an address, and it refuses the session. Nothing in the message says which half failed, so the report reads as an authentication failure.

Reproduce it once with IKE debugging enabled and read the identity payload the firewall actually emits.

In the same pass, confirm three cheap facts: the IKE version both ends use, the exact key including invisible trailing characters, and the peer address Google is configured to expect. They answer separate questions, and a matching key says nothing about the identity.

Options, and what each one costs

Each exit fixes a different layer, and none of them is available to every deployment.

Correcting the identity on the firewall is the cleanest answer where the firmware lets you pick the type and keep the value. The field exists in some builds and fills the type wrongly in others, so test your version instead of trusting release notes.

A routable public address on the negotiating interface is the documented workaround, because the default identity then matches what Google expects and no override is required. It is where most deployments land, if the firewall can hold such an address at all.

Terminating on a peer that validates what you produce is a topology change. Treat it as a design decision rather than a workaround with a friendlier description.

When NAT removes one option

Behind NAT the public-address exit disappears, and what remains depends on firmware behaviour you do not control. That is the point to choose deliberately between upgrading, relocating the peer, or accepting a different cloud endpoint. Those are three different budgets, and picking one by accident is how a temporary workaround turns into architecture. Write the choice and its reason beside the tunnel.

Before interpreting any of this, confirm the tunnel state on the Google side and that IKE is not simply being dropped en route. A dropped packet times out; it does not produce a rejection.

What to record while it works

Note the identity type, its value, the firmware version and the peer address that were in force when the tunnel last came up. A firmware update can change the default again, and the next failure will look exactly like a key mismatch. With identity stored beside the key and the peer address, the next person starts from the cheap checks.

That record is also the only way to know whether a workaround is still needed after the next upgrade.