Fortigate: VPN secundária com CheckPoint | VINICIUS BUENO
Neste post vou demonstrar a configuração de uma VPN secundária entre os firewalls Fortigate e CheckPoint R75.40.
Pelo CheckPoint possui dois links Internet, ativo/backup, o Fortigate deve configurar a VPN Ipsec através de Interface Mode / Route-based.
Começaremos demonstrando a configuração dos tuneis VPN no Fortigate.
SITE_A_1
SITE_A_2
Após a configuração da VPN, iremos adicionar as rotas para as interfaces VPN.
Reparem que foi configurado os tuneis com Distance distintas, fazendo o SITE_A_1 ser o preferencial.
Assim como o IP SLA da Cisco, será necessário monitorar a Interface da VPN para que o chaveamento das rotas ocorra no momento de indisponibilidade do túnel principal.
No Fortigate iremos configurar a opção Dead Gateway Detection.
Navegue até o menu abaixo, e pressione em Create New
Para verificarmos se o túnel SITE_A_1 está disponível iremos monitorar o Host_B (10.32.0.20) através do ICMP por dentro do túnel VPN. Ou seja, é necessário que este host esteja sempre disponível, pois após 5 tentativas sem sucesso ocorrerá o chaveamento das rotas para o túnel SITE_A_2.
Ainda temos um problema, por padrão o firewall tentará pingar o host através de sua interface publica, porém a rede 10.100.0.0 não é trocada no túnel VPN, desta forma teremos que trocar o source ip para a rede 10.33.0.0 que é trocada no túnel. Está configuração é possível apenas por CLI.
set source-ip 10.33.0.2
O source-ip 10.33.0.2 é o endereço na Interface da rede privada do firewall.
Após esta configuração iremos apenas criar as regras de firewall para que acha comunicação entre as redes.
Por hora, as configurações no firewall Fortigate estão concluídas.
Agora iremos prosseguir com as configurações no firewall CheckPoint, onde não nos aprofundaremos nas configurações da VPN, pois já existe um post no link abaixo.
VPN CheckPoint: https://vsoc.com.br/vpn-ipsec-checkpoint/
Como demonstrado na topologia, o ambiente onde está o firewall CheckPoint possui dois links Internet, sendo um ativo e outro de backup.
Isso é configurável através da opção abaixo.
Como foi definido a rede 10.30.0.20 como a principal, a rota default estará apontando para a eth0
Logo mais iremos demonstrar a comutação dos links para testarmos os tuneis VPN, onde ao assumir o link de backup, a rota default passa a ser a eth1.
Foi configurado apenas um único túnel VPN com o endereço da WAN publica do Fortigate.
Regras de firewall permitindo a comunicação.
Para que fosse possível simular este ambiente, foi utilizado um Roteador no GNS3, que é o gateway default dos ambientes, pois quando ocorrer a comutação dos links, a rede de backup deve ser alcançável ao Fortigate.
Endereçamento do Router
Após estas configurações iremos realizar o troubleshooting realizando a comutação entre os links, iremos nos deparar com um problema, isso devido a forma que o CheckPoint trabalha com o túnel VPN na comutação.
Iremos através do Host_A(10.33.0.10) gerar trafego interessante para que o túnel VPN fique disponível.
Reparem que o Host_A está pigando o Host_B através do túnel VPN.
O túnel SITE_A_1 se entra UP
Reparem que a Interface do firewall 10.33.0.2 está realizando o monitoramento configurado no Dead Gateway Detection.
Fazendo com que a rota da rede 10.32.0.0/24 seja encaminhada para o SITE_A_1.
Agora iremos realizar a comutação do link no CheckPoint, passa isso irei através do VMware desativar fisicamente a interface eth0.
Reparem no log do Tracker, informando que o link primary deve problemas.
Na tabela de roteamento, o CheckPoint chaveou o tráfego para o link de backup eth1.
Vamos analisar o comportamento do Fortigate após este processo.
Reparem que o Fortigate não está mais conseguindo pingar o Host_B (10.33.0.20), configurado no monitoramento através do túnel VPN SITE_A_1.
Devido a isso, o firewall chaveou o roteamento para o túnel VPN SITE_A_2.
Perfeito, isso comprova o funcionamento correto do chaveamento de roteamento entre as interfaces VPN.
Porém o túnel SITE_A_2 não foi estabelecido.
Para identificamos o problema, iremos realizar um debug no processo de VPN do Fortigate.
Eis que nos deparamos com o problema de INVALID-SPI.
Este erro ocorre quando o Host_B está gerando um trafego interessante ao Host_A, pois no processo de comutação do link, não houve uma nova troca entre as sessões da VPN. Fazendo com que a comunicação fosse através do ID/SPI antigo, onde o firewall está barrando.
Através da CLI é possível listarmos as sessões.
diagnose vpn ike gateway list
Caso eu limpe a sessão, forçando a gerar uma nova troca de SPI entre os peers, o túnel VPN será estabelecido.
Reparem que após este comando, a sessão foi deletada e estabelecida uma nova, fazendo com que o túnel VPN fosse estabelecido.
Sessão estabelecida, porém através de um processo manual.
A solução de contorno encontrada para que este processo ocorre de forma automática foi, diminuir o tempo de Keyfile da PHASE1 para 120 segundos, desta forma após 2 minutos novas SPI serão negociadas.
Desta forma, uma vez realizando o chaveamento do link, existirá um tempo máximo de 2 minutos para que a comunicação com o novo túnel volte a ser estabelecida.
Uma vez o link principal voltar a ser operacional, o tráfego volta a ser feito realizado através do túnel SITE_A_1.
Log Tracker CheckPoint
Túnel VPN SITE_A_1 estabelecido.
Outro ponto, é a questão do monitoramento do Host_B feito pelo firewall.
Uma vez este host indisponível o firewall irá chavear sua tabela de roteamento, porém o túnel VPN ainda se mantém ativo com o link principal, onde o trafego gerado pelo CheckPoint será encaminhado pelo SITE_A_1 e o trafego gerado pelo Fortigate será encaminhado pelo SITE_A_2.