Iată nevoia:
Conectați un dispozitiv Fortigate în spatele unui NAT static 1:1 la internet la un gateway VPN Google Cloud Platform (GCP).
Diagrama ASCII simplificată:
LOCAL_LAN ---- Fortigate ----- Modem fibră ---- Internet ---- GCP VPN Gateway ----- GCP_VPC
Modemul Fiber face NAT 1:1 la Fortigate, modul DMZ este apelat pe acest modem.
Am urmat mai multe instructiuni:
Cum să creez un VPN la un gateway extern pe GCP - Sunt cazul de utilizare #3, deoarece am doar un singur IP public pe Fortigate
https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4
Interoperabilitate cu Fortinet - Nu am 2 IP-uri statice, unul pentru fiecare interfață pe Fortigate
https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate
Rezultate cu IKE v1:
Faza 1 este negociată, problema este că faza 2 nu este niciodată adusă în discuție. Ghidul de depanare de la Google:
https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting
Spune: trebuie să definiți ID-ul de peer ca IP public pentru ca tunelul să fie afișat.
Ceea ce este ciudat este că am definit pe parametrul local FortiGate Phase 1 IP-ul public și este trimis corect către GCP VPN Gateway.
Este un eveniment recunoscut în jurnalele GCP, așa cum se arată mai jos!
{
insertId: „5abgbbg2313tdw”
etichete: {1}
logName: „projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events”
primire ștampilă: „2021-09-01T21:14:46.610751733Z”
resursă: {2}
severitate: „DEBUG”
**textPayload: „IDir „201.110.XXX.240” nu se potrivește cu „201.110.XXX.240””**
marca temporală: „2021-09-01T21:14:46.592461252Z”
}
Dar problema este că Faza 2 nu este niciodată negociată pe partea GCP și tunelul este șters.
În scopuri de documentare, iată rezultatul din jurnalul de depanare ike al Fortigate:
ca 0:gcp00-0:10752: procesat INITIAL-CONTACT
ike 0:gcp00-0: planificați negocierea automată
ike 0:gcp00-0:10752: nu există negocieri în modul rapid în așteptare
[...]
ike 0:gcp00-0:10751: recv ISAKMP SA șterge 14cb5d60541aaaaa/d405bbbbf6d06acb
Deconectarea ISAKMP este apoi potrivită în jurnalele GCP:
{
insertId: „5abgbbg2313tdx”
etichete: {1}
logName: „projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events”
primire ștampilă: „2021-09-01T21:14:46.610751733Z”
resursă: {2}
severitate: „NOTICĂ”
textPayload: „se șterge IKE_SA vpn_201.110.XXX.240[2662] între 35.242.XXX.165[35.242.XXX.165]...201.110.XXX.240[%any]”
marca temporală: „2021-09-01T21:14:46.592502955Z”
}
Negocierea rămâne în această stare într-o buclă infinită.
Teste cu IKE v2.
Am incercat si pe IKE v2, rezultatele sunt destul de asemanatoare. Tunelul nu este niciodată prezentat, singura diferență este că, pe partea FGT, nu pot trimite IP-ul public către gateway-ul GCP VPN. Am încercat să modific parametrii localid, local-gw și eap pe IKEv2 fără succes. Jurnalul din perspectiva GPC este AUTHENTICATION_FAILED. Autentificarea PSK este finalizată, dar, deoarece colegii nu sunt niciodată identificați corespunzător, nu este niciodată adusă în discuție.
Dacă definesc parametrul local-gw pe FGT ca IP-ul public al modemului în fața Fortigate, negocierea în sine nu poate fi finalizată deloc. Motivul: la stabilirea acestui parametru pe interfața FGT phase1-gw, Fortigate va trimite pachetele cu IP-ul SURSA a IP-ului definit local-gw. Deoarece acest IP nu este valid pentru modem, pachetul nu este trimis niciodată.
Este important de menționat că am făcut 2 tuneluri, unul pe ike v1 și altul pe ike v2 pentru a testa. Din acest motiv, IP-urile din următorul tunel sunt diferite:
Iată jurnalele de dovezi din consola GCP:
{
insertId: „134hqnjg23gnfib”
etichete: {1}
logName: „projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events”
primire Timp: „2021-09-01T21:52:39.566968571Z”
resursă: {2}
severitate: „DEBUG”
textPayload: „Se caută configurații peer care se potrivesc cu 35.220.XXX.31[%any]...201.110.XXX.240[201.110.XXX.240]”
marca temporală: „2021-09-01T21:52:39.552310603Z”
}
{
insertId: "134hqnjg23gnfia"
etichete: {1}
logName: „projects/my-project-xxxxxx/logs/cloud.googleapis.com%2Fipsec_events”
primire Timp: „2021-09-01T21:52:39.566968571Z”
resursă: {2}
severitate: „DEBUG”
textPayload: „Solicitare IKE_AUTH analizată 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]”
marca temporală: „2021-09-01T21:52:39.552287263Z”
}
ÎNTREBĂRI
Știe cineva de ce pe ike v1, chiar dacă IP-urile sunt corecte, GCP VPN Gateway refuză să configureze tunelul (faza 2)?
Știe cineva o modalitate de a seta IKE v2 IDi sau IDr pe definiția fazei 1 pe un Fortigate?
A mai văzut cineva această problemă? Orice sugestii?
