Gcloud vpn tunnel log complains that “MAC mismatched”. How to fix

google-cloud-platformgoogle-cloud-vpnvpn

I am trying to connect my application deployed on Google cloud VPC to my client's on-premise LAN (thru an VPN on client's request) such that my client and I can transfer files between my server on Gcloud and their server.

However, we are running issues with setting up the VPN tunnel. Below are the specifications:

  1. I have set up a High-availablity (HA) VPN and I'm using Dynamic routing.
  2. The IP of my gcloud VPN gateway is 78.211.79.182; The IP of peer gateway (aka the client's gateway) is 41.233.612.86. (These are not the real IPs, of course. Just for the ease of reading log below.)
  3. I have created the IKEv2 pre-shared key and have shared the key to my clients so they are using it to configure their gateway.

From my Gcloud gateway's log, I can see that an error occurs:

D 2020-07-26T13:46:23.854055402Z remote host is behind NAT 
D 2020-07-26T13:46:23.854099553Z authentication of '78.211.79.182' (myself) with pre-shared key 
I 2020-07-26T13:46:23.854167373Z establishing CHILD_SA vpn_41.233.612.86{1} 
D 2020-07-26T13:46:23.854285679Z generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ] 
D 2020-07-26T13:46:23.854821679Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (320 bytes) 
D 2020-07-26T13:46:23.865825884Z received packet: from 41.233.612.86[4500] to 78.211.79.182[4500] (240 bytes) 
D 2020-07-26T13:46:23.866158710Z parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ] 
D 2020-07-26T13:46:23.866219472Z tried 1 shared key for '78.211.79.182' - '41.233.612.86', but MAC mismatched 
D 2020-07-26T13:46:23.866341774Z generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ] 
D 2020-07-26T13:46:23.866434696Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (80 bytes) 
D 2020-07-26T13:46:26.830704780Z creating acquire job for policy with reqid {1} 
I 2020-07-26T13:46:26.830879885Z initiating IKE_SA vpn_41.233.612.86[38] to 41.233.612.86 
D 2020-07-26T13:46:26.835746125Z generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ] 
D 2020-07-26T13:46:26.836731673Z sending packet: from 78.211.79.182[500] to 41.233.612.86[500] (892 bytes) 
D 2020-07-26T13:46:26.847907232Z received packet: from 41.233.612.86[500] to 78.211.79.182[500] (464 bytes) 
D 2020-07-26T13:46:26.848248731Z parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] 
D 2020-07-26T13:46:26.853647299Z local host is behind NAT, sending keep alives 
D 2020-07-26T13:46:26.853693084Z remote host is behind NAT 
D 2020-07-26T13:46:26.853740121Z authentication of '78.211.79.182' (myself) with pre-shared key 
I 2020-07-26T13:46:26.853804324Z establishing CHILD_SA vpn_41.233.612.86{1} 
D 2020-07-26T13:46:26.853950401Z generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ] 
D 2020-07-26T13:46:26.854595024Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (320 bytes) 
D 2020-07-26T13:46:26.865979158Z received packet: from 41.233.612.86[4500] to 78.211.79.182[4500] (240 bytes) 
D 2020-07-26T13:46:26.866316701Z parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ] 
D 2020-07-26T13:46:26.866381716Z tried 1 shared key for '78.211.79.182' - '41.233.612.86', but MAC mismatched 
D 2020-07-26T13:46:26.866505332Z generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ] 
D 2020-07-26T13:46:26.866615565Z sending packet: from 78.211.79.182[4500] to 41.233.612.86[4500] (80 bytes) 
D 2020-07-26T13:46:29.830755043Z creating acquire job for policy with reqid {1} 
I 2020-07-26T13:46:29.830930845Z initiating IKE_SA vpn_41.233.612.86[39] to 41.233.612.86 
D 2020-07-26T13:46:29.835922517Z generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ] 
D 2020-07-26T13:46:29.836919895Z sending packet: from 78.211.79.182[500] to 41.233.612.86[500] (892 bytes) 
D 2020-07-26T13:46:29.848359165Z received packet: from 41.233.612.86[500] to 78.211.79.182[500] (464 bytes) 
D 2020-07-26T13:46:29.848683121Z parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] 
D 2020-07-26T13:46:29.853828481Z local host is behind NAT, sending keep alives 
D 2020-07-26T13:46:29.853841851Z remote host is behind NAT

The vpn tunnel has failed to set up. I have 2 questions:

  1. The log says:
D 2020-07-26T13:46:26.853647299Z local host is behind NAT, sending keep alives
D 2020-07-26T13:46:26.853693084Z remote host is behind NAT

Is this an issue at all? or is this normal behavior that I don't need to worry?

  1. The log says:
    D 2020-07-26T13:46:23.866219472Z tried 1 shared key for '78.211.79.182' - '41.233.612.86', but MAC mismatched

What does this mean? How can I configure to fix this issue? Is this something I should change on my gcloud vpn configuration or something I should advice my client to do with their settings?

Best Answer

Cloud VPN only supports one-to-one NAT via UDP encapsulation for NAT-Traversal (NAT-T). One-to-many NAT and port-based address translation are not supported. In other words, Cloud VPN cannot connect to multiple peer VPN gateways that share a single external IP address.Details can be found UDP encapsulation

When using one-to-one NAT, your on-premises VPN gateway must identify itself using the same external IP address of the NAT device:

The identity type must be ID_IPV4_ADDR (RFC 7815).

Not all Cisco devices support setting a device identity to an IP address different from the one the device is using (its internal address). For example, Cisco ASA devices do not support assignment of different (external) IP addresses for their identities. Thus, Cisco ASA devices cannot be configured to use one-to-one NAT with Cloud VPN.

For Juniper devices, you can set the identity of the device using set security ike gateway [NAME] local-identity inet [PUBLIC_IP] where [NAME] is your VPN gateway name and [PUBLIC_IP] is your external IP address. Refer to this Juniper TechLibrary article for more detail.

Additionally, I have noticed following in the log you have shared

D 2020-07-26T13:46:23.854285679Z generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ]
D 2020-07-26T13:46:23.866158710Z parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]

As per the information discussed above the solution for this issue is to configure the on-prem VPN gateway to identify itself using its public IP address, not with the internal or any other address. As GCP end will only expecting reply from peer IP configured in GCP Cloud VPN configuration.

Related Topic