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?
