Unable to configure behind-NAT Fortigate IPsec VPN with GCP

[Timor]

Hello,

We have a cloud services in Google Cloud (GCP) and we try to configure a vpn from our new offices and GCP.   The difference between our old offices and new ones, that now we are behind the NAT where in the old offices we were facing the Internet directly.   Our new offices is doing 1-to-1 NAT with our Fortigate. Our Fortigate is 90E v5.4.1. GCP supports 1-to-1 NAT with VPN peers but it restricts the peer to be able to identify itself with a public IP. https://cloud.google.com/vpn/docs/support/troubleshooting#gateways_behind_nat   Our Fortigate because it is behind a NAT identifies itself with it's private IP which GCP rejects upon ikev2 authentication. I have tried to play with: local-gw, localid and nat-traversal but nothing helped when it comes to authentication with GCP Cloud VPN.   Please Help.  

[NetFire]

did you open open 500-4500 UDP ports on NAT router?

[Timor]

Yes, as the we are 1-to-1 NAT, meaning that we have a dedicated public IP for the office provider, and all traffic that is getting to this address is redirected to our Fortigate private IP address.

[NetFire]

Ok, same my scenario. 

In our offices we had two type of routing:

- NATted Modem/router with virtualIP/Virtual Server: Fortigates are behind them, with WAN private IP

- Transparent LAN port on modem/router: Fortigates is connected to a physical LAN port on router and has public WAN IP.

If you can, you must set up a Transparent IP mode on one LAN port on modem/router where the public IP pass as-is.

In this case you must have one IP for the modem/router and one IP for the Fortigate, and each modem/router port must be set as interface instead of switch

Which modem/router do you have?

[Timor]

Our office provider have a Cisco Meraki MX Router.

Thanks

[johnnyringo]

Tying this right now with a Fortigate F60-E.  Firewall is behind a NAT with ports udp/500 and udp/4500 forwarded.   I'm also having a lot of trouble getting a tunnel to GCP up and running.   

A couple things I've discovered:

[ol]

The FortiGate's "Local ID" field in the Phase 1 proposal seems to only work for FQDN authentication.  To override IP address with IP address based authentication, I'm assuming that can only be done in the CLI.  

GCP tends to really prefer IKEv2.  IKEv1 is technically supported but I've never been able to get it working w/ NAT-T on either a Palo Alto or Cisco router.  Based on errors from the Palo Alto, it seems like the GCP cloud VPN gateway mis-identifies itself in IKEv1: received ID_I (type ipaddr [35.242.62.249]) does not match peers id[/ol]

I am successfully running other tunnels to CheckPoint, Palo Alto, Cisco ISRs, and AWS.  The Palo Altos are using FQDN authentication both with IKEv1 and IKEv2.  It's only GCP that I've had problems with.