Cannot connect a Fortigate VPN behind a static NAT to a GCP VPN gateway

Question

Here's the need:

Connect a Fortigate device behind a static 1:1 NAT to the Internet to a Google Cloud Platform (GCP) VPN gateway.

Simplified ASCII Diagram:

LOCAL_LAN ---- Fortigate ----- Fiber modem ---- Internet ---- GCP VPN Gateway ----- GCP_VPC

The Fiber modem is doing NAT 1:1 to the Fortigate, DMZ Mode is called on this modem.

I've followed several instructions:

How to create a VPN to an external Gateway on GCP - I am use case #3 as I only have a single public IP on the Fortigate https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4

Interoperability with Fortinet - I do not have 2 static IPs, one per interface on the Fortigate https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate

Results with IKE v1:

The Phase 1 is negotiated, the problem is that the Phase 2 is never brought up. The Troubleshooting guide at Google:

https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting

Says: you must define the peer ID as the public IP in order for the tunnel to be brought up.

What's odd is that I've defined on the FortiGate Phase 1 localid parameter the public IP, and it is properly sent to the GCP VPN Gateway.

It is event acknowledged on the GCP logs as shown below!

{
insertId: "5abgbbg2313tdw"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "DEBUG"
**textPayload: "IDir '201.110.XXX.240' does not match to '201.110.XXX.240'"**
timestamp: "2021-09-01T21:14:46.592461252Z"
}

But the problem is that the Phase 2 is never negotiated on the GCP side and the tunnel is deleted. For documentation purposes, here's the output on the Fortigate's ike debug log:

ike 0:gcp00-0:10752: processed INITIAL-CONTACT
ike 0:gcp00-0: schedule auto-negotiate
ike 0:gcp00-0:10752: no pending Quick-Mode negotiations
[...]
ike 0:gcp00-0:10751: recv ISAKMP SA delete 14cb5d60541aaaaa/d405bbbbf6d06acb

The ISAKMP disconnect is then matched on the GCP Logs:

{
insertId: "5abgbbg2313tdx"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "NOTICE"
textPayload: "deleting IKE_SA vpn_201.110.XXX.240[2662] between 35.242.XXX.165[35.242.XXX.165]...201.110.XXX.240[%any]"
timestamp: "2021-09-01T21:14:46.592502955Z"
}

The negotiation stays in this state in an infinite loop.

Tests with IKE v2.

I also tried on IKE v2, the results are quite similar. The tunnel is never brought up, the only difference is that on the FGT side I am unable to send the public IP to the GCP VPN gateway. I've tried modifying the localid, local-gw and eap parameters on the IKEv2 with no success. The log from the GPC perspective is AUTHENTICATION_FAILED. The PSK auth is completed but as the peers are never properly identified, it is never brought up. If I define the local-gw parameter on the FGT as the public IP of the modem in front of the Fortigate, the negotiation itself cannot be completed at all. The reason: when establishing this parameter on the FGT phase1-interface gw, the Fortigate will send the packets with the SOURCE IP of the local-gw defined IP. As this IP is not a valid to the Modem, the packet is never sent out.

It is important to note that I made 2 tunnels, one on ike v1 and another on ike v2 to test. Due to this the IPs on the following tunnel are different: Here are the evidence logs from the GCP console:

{
insertId: "134hqnjg23gnfib"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "looking for peer configs matching 35.220.XXX.31[%any]...201.110.XXX.240[201.110.XXX.240]"
timestamp: "2021-09-01T21:52:39.552310603Z"
}

{
insertId: "134hqnjg23gnfia"
labels: {1}
logName: "projects/my-project-xxxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]"
timestamp: "2021-09-01T21:52:39.552287263Z"
}

QUESTIONS

Does anyone know why on ike v1 even as the IPs are correct, the GCP VPN Gateway refuses to setup the tunnel (phase2)?

Does anyone know a way to set the IKE v2 IDi or IDr on the phase 1 definition on a Fortigate?

Have anyone seen this problem before? Any suggestions?

Answer 1

Well, answering my own question. Here it goes:

On FortiOS 7.0.1 when the ForiGate is behing a NAT device doing a 1:1 NAT, there is no documented or explicit way to define the IDi or IDr of the phase one definition on the FortiGate in a way that GCP accepts it to setup the tunnel.

The only way to setup a VPN tunnel between a FGT and GCP VPN Gateway is for the FortiGate to have the Public IP directly assigned to the interface that is connecting to GCP VPN.

That way, you can define the "local gw" IP to the Interface, public IP on the FGT Phase 1 definition. With that, the tunnel negotiation is completed and the VPN works.

In summary, DO NOT TRY to setup a FGT to GCP VPN tunnel when the FGT is behind a NAT device. It won't work at all!

This was tested with FortiOS 7.0.1 connecting to GCP VPN Redundant Gateways with a single public IP on the FortiGate and TWO IPs on the GCP VPN side using IKE v2. IKE v1 wasn't tested.