Hier ist der Bedarf:
Verbinden Sie ein Fortigate-Gerät hinter einem statischen 1:1-NAT mit dem Internet mit einem VPN-Gateway der Google Cloud Platform (GCP).
Vereinfachtes ASCII-Diagramm:
LOCAL_LAN ---- Fortigate ----- Fiber modem ---- Internet ---- GCP VPN Gateway ----- GCP_VPC
Das Glasfasermodem führt NAT 1:1 zum Fortigate durch, auf diesem Modem wird der DMZ-Modus aufgerufen.
Ich habe mehrere Anweisungen befolgt:
So erstellen Sie ein VPN zu einem externen Gateway auf GCP - Ich bin Anwendungsfall Nr. 3, da ich nur eine einzige öffentliche IP auf dem Fortigate habe https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4
Interoperabilität mit Fortinet - Ich habe keine 2 statischen IPs, eine pro Schnittstelle auf dem Fortigate https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate
Ergebnisse mit IKE v1:
Phase 1 wird ausgehandelt, das Problem ist, dass Phase 2 nie angesprochen wird. Der Troubleshooting-Leitfaden bei Google:
https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting
Sagt: Sie müssen die Peer-ID als öffentliche IP definieren, damit der Tunnel aufgebaut werden kann.
Das Seltsame ist, dass ich im FortiGate Phase 1-LocalID-Parameter die öffentliche IP definiert habe und diese ordnungsgemäß an das GCP VPN Gateway gesendet wird.
Das Ereignis wird in den GCP-Protokollen bestätigt, wie unten gezeigt!
{
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"
}
Das Problem besteht jedoch darin, dass Phase 2 auf der GCP-Seite nie ausgehandelt wird und der Tunnel gelöscht wird. Zu Dokumentationszwecken finden Sie hier die Ausgabe des IKE-Debugprotokolls von Fortigate:
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
Die ISAKMP-Trennung wird dann mit den GCP-Protokollen abgeglichen:
{
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"
}
Die Verhandlung bleibt in diesem Zustand in einer Endlosschleife.
Tests mit IKE v2.
Ich habe es auch mit IKE v2 versucht, die Ergebnisse sind ziemlich ähnlich. Der Tunnel wird nie aufgebaut, der einzige Unterschied besteht darin, dass ich auf der FGT-Seite die öffentliche IP nicht an das GCP-VPN-Gateway senden kann. Ich habe versucht, die Parameter localid, local-gw und eap auf IKEv2 zu ändern, aber ohne Erfolg. Das Protokoll aus der GPC-Perspektive lautet AUTHENTICATION_FAILED. Die PSK-Authentifizierung ist abgeschlossen, aber da die Peers nie richtig identifiziert werden, wird sie nie aufgebaut. Wenn ich den Parameter local-gw auf dem FGT als öffentliche IP des Modems vor dem Fortigate definiere, kann die Verhandlung selbst überhaupt nicht abgeschlossen werden. Der Grund: Wenn dieser Parameter auf dem FGT-Phase1-Schnittstellen-GW festgelegt wird, sendet das Fortigate die Pakete mit der QUELL-IP der als local-gw definierten IP. Da diese IP für das Modem ungültig ist, wird das Paket nie gesendet.
Es ist wichtig zu beachten, dass ich zum Testen zwei Tunnel erstellt habe, einen auf IKE v1 und einen auf IKE v2. Aus diesem Grund sind die IPs im folgenden Tunnel unterschiedlich: Hier sind die Beweisprotokolle von der GCP-Konsole:
{
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"
}
FRAGEN
Weiß jemand, warum sich das GCP VPN Gateway bei IKE v1 weigert, den Tunnel einzurichten (Phase 2), obwohl die IPs korrekt sind?
Kennt jemand eine Möglichkeit, die IKE v2 IDi oder IDr in der Phase 1-Definition eines Fortigate festzulegen?
Hat jemand dieses Problem schon einmal gesehen? Irgendwelche Vorschläge?
Antwort1
Nun, ich beantworte meine Frage selbst. Hier ist sie:
Unter FortiOS 7.0.1 gibt es, wenn sich das ForiGate hinter einem NAT-Gerät befindet, das ein 1:1-NAT durchführt, keine dokumentierte oder explizite Möglichkeit, die IDi oder IDr der Phase-1-Definition auf dem FortiGate so zu definieren, dass GCP sie zum Einrichten des Tunnels akzeptiert.
Die einzige Möglichkeit, einen VPN-Tunnel zwischen einem FGT- und einem GCP-VPN-Gateway einzurichten, besteht darin, dass FortiGate die öffentliche IP direkt der Schnittstelle zuweist, die eine Verbindung zum GCP-VPN herstellt.
Auf diese Weise können Sie die „lokale GW“-IP für die Schnittstelle definieren, die öffentliche IP für die FGT-Phase-1-Definition. Damit ist die Tunnelverhandlung abgeschlossen und das VPN funktioniert.
Zusammenfassend: VERSUCHEN SIE NICHT, einen FGT-zu-GCP-VPN-Tunnel einzurichten, wenn sich das FGT hinter einem NAT-Gerät befindet. Das wird überhaupt nicht funktionieren!
Dies wurde mit FortiOS 7.0.1 getestet, das eine Verbindung zu redundanten GCP VPN-Gateways mit einer einzelnen öffentlichen IP auf dem FortiGate und ZWEI IPs auf der GCP VPN-Seite unter Verwendung von IKE v2 herstellte. IKE v1 wurde nicht getestet.