Cenário:
Palo hospedando GlobalProtect está atrás de outro dispositivo que faz NAT do IP público para o IP externo do Palo, que possui um IP privado. Conseguimos acessar o IP público normalmente e obter o portal, baixar o cliente, etc. Importante notar que usamos um IP privado na interface externa do Palo que é o IP do portal e do gateway para a configuração do GlobalProtect.
Ao conectar ao IP público com o cliente, vemos autenticação no portal, mas o gateway expira.
Não há políticas de NAT no Palo interno.
Certificado autoassinado privado no Palo interno.
Tentei um loopback na interface do gateway, remover o tunnel split. Nada funciona e os logs não mostram nada relevante.
Alguém mais já precisou solucionar um cenário assim?
Obrigado
Quais portas você está permitindo pelo dispositivo que faz NAT? Você precisa de TCP-443 e UDP-4501
Ele precisa de IPSEC? Pensei que ele faria fallback para 443 se o IPSEC não estivesse disponível.
Adicionamos o UDP/4501 ao dispositivo upstream e ainda assim nada. Tenho quase certeza de que o problema está nos certificados, mas com os dois dispositivos envolvidos, isso complica as coisas.
Não pode ser um problema de certificado se você estiver encaminhando a porta 443 e não descodificando o tráfego no dispositivo NAT. Isso é fácil de provar acessando o endereço do portal pelo navegador.
Não há muito o que verificar além das coisas óbvias:
- Você está permitindo TCP 443 e UDP 4501? Mesmo que o segundo não, a menos que você o tenha desativado, o GlobalProtect voltará ao SSL ao se conectar ao gateway.
- Você tem uma regra de ‘de confiança’ para qualquer coisa de ‘não confia’ para o IP usado pelo portal e pelo gateway nessas portas (é melhor usar os aplicativos embutidos para isso ao invés de portas). Com tudo isso, veja o que acontece, verifique os logs de tráfego para ver se algo está sendo negado ou não mostra algo esperado. Além disso, cheque os logs do GlobalProtect.
A situação que você descreveu é como todos os Palo em AWS/Azure/GCP funcionam.