☰

QUESTÕES

tag-icon • tag-icon vpn google-cloud-platform fortigate ikev2 ikev1
QUESTÕES

Aqui está a necessidade:

Conecte um dispositivo Fortigate atrás de um NAT 1:1 estático à Internet a um gateway VPN do Google Cloud Platform (GCP).

Diagrama ASCII simplificado:

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

O modem Fiber está fazendo NAT 1:1 para o Fortigate, o modo DMZ é chamado neste modem.

Eu segui várias instruções:

Como criar uma VPN para um gateway externo no GCP - sou o caso de uso nº 3, pois só tenho um único IP público no Fortigate https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4

Interoperabilidade com Fortinet - não tenho 2 IPs estáticos, um por interface no Fortigate https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate

Resultados com IKE v1:

A Fase 1 é negociada, o problema é que a Fase 2 nunca é tocada. O guia de solução de problemas do Google:

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

Diz: você deve definir o peer ID como o IP público para que o túnel seja ativado.

O estranho é que defini no parâmetro localid do FortiGate Phase 1 o IP público, e ele é enviado corretamente para o gateway VPN do GCP.

É um evento reconhecido nos logs do GCP conforme mostrado abaixo!

{
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"
}

Mas o problema é que a Fase 2 nunca é negociada pelo lado do GCP e o túnel é excluído. Para fins de documentação, aqui está a saída no log de depuração ike do 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

A desconexão ISAKMP é então correspondida nos registros do 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"
}

A negociação permanece neste estado num loop infinito.

Testes com IKE v2.

Também experimentei no IKE v2, os resultados são bastante semelhantes. O túnel nunca é acionado, a única diferença é que do lado do FGT não consigo enviar o IP público para o gateway VPN do GCP. Tentei modificar os parâmetros localid, local-gw e eap no IKEv2 sem sucesso. O log da perspectiva GPC é AUTHENTICATION_FAILED. A autenticação PSK é concluída, mas como os pares nunca são devidamente identificados, ela nunca é acionada. Se eu definir o parâmetro local-gw no FGT como o IP público do modem na frente do Fortigate, a negociação em si não poderá ser concluída. O motivo: ao estabelecer este parâmetro no gw da interface fase 1 do FGT, o Fortigate enviará os pacotes com o IP FONTE do IP definido pelo gw local. Como este IP não é válido para o Modem, o pacote nunca é enviado.

É importante ressaltar que fiz 2 túneis, um no ike v1 e outro no ike v2 para testar. Devido a isso, os IPs no túnel a seguir são diferentes: Aqui estão os registros de evidências do console do 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"
}

QUESTÕES

Alguém sabe por que no ike v1, mesmo com os IPs corretos, o gateway VPN do GCP se recusa a configurar o túnel (fase 2)?

Alguém sabe uma maneira de definir o IKE v2 IDi ou IDr na definição da fase 1 em um Fortigate?

Alguém já viu esse problema antes? Alguma sugestão?

Responder1

Bem, respondendo à minha própria pergunta. Aqui vai:

No FortiOS 7.0.1, quando o ForiGate está atrás de um dispositivo NAT fazendo um NAT 1:1, não há nenhuma maneira documentada ou explícita de definir o IDi ou IDr da definição da fase um no FortiGate de uma forma que o GCP aceite para configuração o tunel.

A única maneira de configurar um túnel VPN entre um FGT e um gateway VPN GCP é o FortiGate ter o IP público atribuído diretamente à interface que está se conectando ao GCP VPN.

Dessa forma, você pode definir o IP “local gw” para a Interface, IP público na definição do FGT Fase 1. Com isso, a negociação do túnel é concluída e a VPN funciona.

Em resumo, NÃO TENTE configurar um túnel FGT para VPN GCP quando o FGT estiver atrás de um dispositivo NAT. Não vai funcionar de jeito nenhum!

Isso foi testado com FortiOS 7.0.1 conectando-se a gateways redundantes VPN GCP com um único IP público no FortiGate e DOIS IPs no lado VPN GCP usando IKE v2. IKE v1 não foi testado.

informação relacionada