Aquí está la necesidad:
Conecte un dispositivo Fortigate detrás de una NAT estática 1:1 a Internet a una puerta de enlace VPN de Google Cloud Platform (GCP).
Diagrama ASCII simplificado:
LOCAL_LAN ---- Fortigate ----- Fiber modem ---- Internet ---- GCP VPN Gateway ----- GCP_VPC
El módem de fibra está realizando NAT 1:1 con Fortigate, se llama al modo DMZ en este módem.
He seguido varias instrucciones:
Cómo crear una VPN para una puerta de enlace externa en GCP: soy el caso de uso n.° 3, ya que solo tengo una IP pública en Fortigate https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4
Interoperabilidad con Fortinet: no tengo 2 IP estáticas, una por interfaz en Fortigate https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate
Resultados con IKE v1:
La Fase 1 está negociada, el problema es que la Fase 2 nunca se plantea. La guía de solución de problemas de Google:
https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting
Dice: debe definir el ID del par como la IP pública para que se active el túnel.
Lo extraño es que he definido en el parámetro localid de FortiGate Fase 1 la IP pública y se envía correctamente a GCP VPN Gateway.
¡Es un evento reconocido en los registros de GCP como se muestra a continuación!
{
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"
}
Pero el problema es que la Fase 2 nunca se negocia por parte del GCP y el túnel se elimina. Para fines de documentación, aquí está el resultado del registro de depuración de ike de 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
Luego, la desconexión de ISAKMP coincide con los registros de GCP:
{
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"
}
La negociación permanece en este estado en un bucle infinito.
Pruebas con IKE v2.
También probé IKE v2 y los resultados son bastante similares. El túnel nunca aparece, la única diferencia es que en el lado FGT no puedo enviar la IP pública a la puerta de enlace VPN de GCP. Intenté modificar los parámetros localid, local-gw y eap en IKEv2 sin éxito. El registro desde la perspectiva de GPC es AUTHENTICATION_FAILED. La autenticación PSK se completa, pero como los pares nunca se identifican adecuadamente, nunca se muestra. Si defino el parámetro local-gw en el FGT como la IP pública del módem frente al Fortigate, la negociación en sí no se puede completar en absoluto. La razón: al establecer este parámetro en la interfaz gw de fase 1 del FGT, Fortigate enviará los paquetes con la IP FUENTE de la IP definida en gw local. Como esta IP no es válida para el módem, el paquete nunca se envía.
Es importante señalar que hice 2 túneles, uno en ike v1 y otro en ike v2 para probar. Debido a esto, las IP en el siguiente túnel son diferentes: Aquí están los registros de evidencia de la consola de GCP:
{
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"
}
PREGUNTAS
¿Alguien sabe por qué en ike v1, incluso cuando las IP son correctas, GCP VPN Gateway se niega a configurar el túnel (fase 2)?
¿Alguien sabe una manera de configurar el IDi o IDr de IKE v2 en la definición de la fase 1 en un Fortigate?
¿Alguien ha visto este problema antes? ¿Alguna sugerencia?
Respuesta1
Bueno, respondiendo a mi propia pregunta. Aquí va:
En FortiOS 7.0.1, cuando ForiGate está detrás de un dispositivo NAT que realiza una NAT 1:1, no existe una forma documentada o explícita de definir el IDi o IDr de la definición de fase uno en FortiGate de manera que GCP acepte su configuración. el tunel.
La única forma de configurar un túnel VPN entre FGT y GCP VPN Gateway es que FortiGate tenga la IP pública asignada directamente a la interfaz que se conecta a GCP VPN.
De esa manera, puede definir la IP "gw local" para la interfaz, IP pública en la definición de FGT Fase 1. Con eso, se completa la negociación del túnel y la VPN funciona.
En resumen, NO INTENTE configurar un túnel VPN de FGT a GCP cuando el FGT esté detrás de un dispositivo NAT. ¡No funcionará en absoluto!
Esto se probó con FortiOS 7.0.1 conectándose a puertas de enlace redundantes de GCP VPN con una única IP pública en FortiGate y DOS IP en el lado de GCP VPN usando IKE v2. IKE v1 no fue probado.