MAC mismatched in IKE means the shared key check failed

Your Cloud VPN log shows a shared-key attempt followed by MAC mismatched, and the first instinct is often to look for an address problem. In this branch MAC is a message authentication code: a value computed over the exchange with the negotiated key. The peer compared its own computation with the value it received, and they differed. No network card is involved, and no interface setting changes that comparison.

Two conditions produce it in practice: the secrets on the two ends are not the same value, or the identities used to select the secret do not correspond. Decide which by reading the pair, not the single tunnel.

What the stage proves

The check runs after both sides have exchanged initial parameters and identified themselves. It selects candidate shared keys for the local and remote identities and tries to validate the received authentication data; when none validates, the diagnostic is emitted. That is a strong statement about authentication and a weak statement about cause, because it does not say which side is wrong.

Earlier success does not carry into this check. A completed IKE_SA_INIT, or a NAT detection payload that returned the expected values, proves the peers can talk. It proves nothing about whether they share a secret.

Two configuration errors, one message

The first is a real secret mismatch, and it is usually a provisioning accident: a generated value installed on one console and retyped on the other, a trailing character that survived one side, or a quote that came along with a paste. The second is an identity mismatch, where the secret is correct but the identity the peer presents selects a different entry, so the right secret is never tried. Both produce the same line, which is why guessing costs an afternoon.

Compare the pair before touching either secret. Match the tunnel, the peer endpoint, the time window and the remote configuration, because two redundant tunnels can hold different secrets and the screen in front of you may not be the one that failed.

NAT detection is a different stage

NAT detection asks how packets are being rewritten, not who the peer is. A customer gateway behind NAT still authenticates correctly when its configured identity is the one the peer expects, and a NAT problem shows up as a proposal or port mismatch rather than a failed authentication comparison.

Do not carry an old statement about one vendor release into a current deployment. What NAT traversal requires in your release belongs in its own documentation, and the phrase MAC mismatch is not evidence for or against it.

Decide from the pair, not the screen

Read both configurations side by side with the secret redacted, then ask three questions. Is the identity on each side exactly what the other expects, character for character? Are both ends using the same IKE version and the same authentication method? Does the failing tunnel correspond to the configuration you are reading? A no to any of those decides the repair without touching the secret.

If all three are clean, replace the secret through the approved workflow rather than editing around it.

After the peer authenticates

Once authentication succeeds, the next failure surface is the child security association: proposals and traffic selectors. Rotating a secret that has already been accepted cannot fix a child failure, and it lengthens the outage. Read the child state, then the selectors and protected ranges on both sides, and match the Cloud VPN troubleshooting guidance to the stage that actually failed.

Correlate fresh logs from both ends for the same pair and the same window. One side alone gives a verdict without the other side's input, which is the ambiguity that produced the message in the first place.

What not to conclude

Do not read the message as a demand to change MAC addresses, and do not publish the shared secret while asking for help; an excerpt containing the key needs the key removed, not the log kept. Do not assume a routing fault either, because peers that cannot reach each other produce no authentication comparison at all. And do not generalise a documented limitation from one product family to every IPsec implementation.

Record the failing pair, the tunnel state before and after, and which of the two conditions you changed. That record turns the next occurrence into a five-minute check.