O estabelecimento de VPN Site-to-Site comumente é uma loteria, em algumas situações o processo é rápido e indolor, cada ponta configura sua parte e na janela de manutenção o túnel sobe rapidamente, já em outras situações horas se passam e fica um vai e vem de validações e confirmações de configuração de fase 1 e fase 2.

Compartilho nesse artigo algumas dicas de troubleshooting de túneis VPN utilizando Fortigate.

Antes de pegarmos alguns exemplos precisamos revisar alguns conceitos (de forma bem superficial). O processo de estabelecimento de uma VPN passa por dois estágios, Fase 1 e Fase 2. Negociação da Fase 2 só pode ser iniciada quando a Fase 1 estiver estabelecida.

Na Fase 1 os gateways VPN negociam a versão de IKE (Internet Key Exchange), validam credenciais (normalmente uma senha referenciada como PSK – Pre Shared Key), negociam se será necessário uso de NAT Traversal (NAT-T), Dead-Peer Detection (DPD) e diversos outros atributos como método de criptografia, hashing, lifetime, grupo Diffie-Hellman, autenticação...

Após Fase 1 estiver estabelecida, negociação de Fase 2 pode iniciar. O objetivo da Fase 2 é negociar o que será trafegado no túnel VPN, alguns outros atributos como criptografia, hashing, lifetime, grupo Diffie-Hellman e outras particularidades também são negociadas aqui, independente da negociação de Fase 1, sendo assim, alguns atributos negociados na Fase 1 podem ser diferentes na Fase 2.

Conforme mencionado anteriormente, um dos atributos que são negociados e precisam ser definidos no túnel é a versão de IKE a ser utilizada (v1 ou v2), de forma geral é recomendado utilizar IKEv2 quando possível, pois é uma evolução em comparação a v1 e permite a utilização de métodos mais seguros de estabelecimento de túnel.

O intuito desse artigo não é mostrar a configuração de túneis, mas sim demonstrar formas resolução de problemas e apresentar eventos comuns e como resolvê-los, prefiro por apresentar métodos de troubleshooting na linha de comando por conseguirmos colher mais informações, com isso em mente, vamos ao primeiro exemplo:

• Temos um túnel VPN estabelecido entre o IP 203.0.113.10 e 203.0.113.30
• A rede 10.10.0.0/24 precisa realizar comunicação com a rede 10.20.0.0/24
• Usuários da rede 10.10.0.0/24 reclamam de que essa comunicação não está funcionando

O primeiro passo é verificarmos o estado do túnel, como falamos anteriormente o túnel possui dois passos para o estabelecimento (Fase 1 e 2), sendo assim, faz sentido verificarmos primeiro o estado da negociação inicial (Fase 1) do túnel.

O comando ‘diagnose vpn ike gateway list’ apresenta o estado da fase 1 do túnel, rodando esse comando no firewall (nossa visão será sempre no firewall ‘LOCAL’) podemos confirmar as seguintes informações:

• O nome do túnel é ‘SITE_REMOTO’
• Estamos utilizando IKEv2 (version: 2)
• O IP local utilizado para esse túnel é 203.0.113.10 e o remoto é 203.0.113.30
• O status é ‘connecting’, isso demonstra que o túnel não está estabelecido

O próximo passo é entendermos o que está acontecendo com mais detalhes, para isso iremos habilitar debug no firewall e colher as informações,

diagnose vpn ike log-filter dst-addr4 203.0.113.30  ---- Define que apenas tráfego de 203.0.113.30 seja apresentado, isso é extremamente útil em ambientes com diversos túneis

diagnose debug application ike -1 ---- Define que todo possível output seja apresentado

diagnose debug enable ---- Habilita o debug em si

Ao habilitar debug, o terminal apresentará mensagens como a apresentada abaixo.

Navegando através do output gerado pela sessão de debug, o firewall apresenta a mensagem ‘No SA proposal chosen’, essa mensagem informa que os atributos do túnel sugerido pelo firewall remoto não batem com nenhuma proposta configurada localmente, normalmente nesse caso é recomendado que confirme se o que o firewall remoto está oferecendo é o correto e há necessidade de alteração local, ou não.

Mas olhando com mais atenção nos logs podemos ver a mensagem abaixo que mostra o firewall remoto está tentando estabelecer o túnel utilizando IKEv1, mas conforme validado anteriormente o que temos configurado é IKEv2, isso precisa ser corrigido. Infelizmente (ou felizmente) IKEv2 não é retrocompatível com IKEv1, sendo assim a mesma versão precisa estar configurada nos dois lados.

Nesse momento é necessário entender quais dos lados deve corrigir a configuração, no exemplo consideramos que a ponta remota corrige a configuração e altera para IKEv2, assim que a alteração é feita podemos ver que o túnel é estabelecido com sucesso.

A frase ‘mágica’ que sempre queremos ver é ‘set oper up’ que informa que o túnel foi estabelecido com sucesso.

Rodando o mesmo comando inicial, podemos ver que o estado do túnel agora é ‘established’ (conforme esperado).

Vamos para um outro exemplo, conforme falamos, a PSK (Pre-Shared Key) é a senha compartilhada entre as duas pontas, essa senha precisa ser exatamente igual entre as duas pontas. O exemplo abaixo mostra no log (o mesmo output do debug apresentado anteriormente) a senha errada.

Como podemos ver acima, o output é bem claro para qual é o erro nesse caso, infelizmente nem sempre a saída é tão clara, ou não é clara o suficiente com apenas uma linha de debug, sendo necessário gastar alguns minutos vinculado o debug geral.

Novamente, ao corrigir o erro o túnel é estabelecido com sucesso.

Para um terceiro exemplo, em algumas situações podemos ver a seguinte mensagem durante uma sessão de debug, ‘no policy configured’, conforme apresentado abaixo.

O erro informa que não há nenhuma regra de firewall (policy) que permita tráfego vinculado a interface VPN para esse túnel, logo o firewall não estabelece o túnel, faz sentido, pois se não há nenhuma regra de firewall que permita essa comunicação, não faz sentido o túnel ser estabelecido.

Nesse caso a solução é simples, é só criar uma regra de firewall que permita o tráfego necessário de/para o túnel.

Numa outra situação, podemos nos deparar com o erro ‘no proposal chosen’, conforme abaixo:

Esse erro demonstra que a proposta para o estabelecimento do túnel recebido pelo peer remoto não bate com o que temos configurado localmente, felizmente os firewalls Fortigate facilitam essa validação, como podemos ver abaixo, estamos recebendo (incoming proposal) o seguinte:

• Criptografia: AES128
• Autenticação: SHA256
• Diffie-Hellman: Grupo 14 (2048 bit)

Enquanto o que temos localmente é:

• Criptografia: AES256
• Autenticação: SHA256
• Diffie-Hellman: Grupo 14 (2048 bit)

Comparando a proposta oferecida e o que temos local podemos identificar que o método de criptografia local (AES256) não bate com o oferecido (AES128), nesse caso a alteração local (ou remota) fazendo as duas pontas idênticas faz o túnel ser estabelecido com sucesso.

Num outro exemplo temos o mesmo erro (‘no proposal chosen’), mas podemos validar que nesse caso o método de criptografia está correto, mas o que não está dando match é o grupo Diffie-Hellman. Enquanto o site remoto está oferecendo grupo 5 (1536), o local está oferecendo grupo 14 (2048), ao corrigir isso o túnel deve estabelecer com sucesso.

Nem sempre os erros de negociação vão ser vinculados a proposta de criptografia e hashing, quando esses itens estiverem Ok, mas mesmo assim o túnel não funciona, podemos nos deparar com o erro ‘failed to match peer selectors’, conforme abaixo:

Esse erro informa que a proposta de rede/fase 2 não bate com o que temos configurado, note que o erro informa um erro nas redes sendo negociadas, normalmente todo o resto (PSK, criptografia, Diffie-Hellman, etc) deve estar correto para chegarmos nesse ponto.

Como podemos ver abaixo a rede recebida é 10.30.0.0/24.

Podemos comparar o que é recebido com o que temos configurado localmente, o comando ‘diagnose vpn tunnel list’ apresenta esses dados. Conforme abaixo, o que temos configurado como rede local é 10.10.0.0/24 enquanto a rede remota é 10.20.0.0/24.

Como a rede remota recebida pelo peer é 10.30.0.0/24 a configuração não dá ‘match’ e o túnel falha, corrigindo a rede oferecida em um dos lados resolve o problema.

Esse erro (fase 2) pode também ser apresentado como ‘TS_UNACCEPTABLE’, a solução é a mesma (corrigir as redes sendo oferecidas).

Uma outra situação que pode acontecer é a mensagem abaixo ser apresentada durante a leitura dos logs/debug.

O erro ‘SA is not ready yet, drop’, informa que existe uma rota apontando para o túnel, porém a fase 2 desse tráfego/rede ainda não foi estabelecida com sucesso, a solução é a mesma da apresentada anteriormente (validar que as redes configuradas na fase 2 batem com o que está configurado localmente).

É possível validar o estado da(s) fase 2 no túnel rodando o comando ‘diagnose vpn tunnel list’, conforme abaixo:

O campo/valor de SA informa o estado da fase 2 (de cada uma, se houver mais redes, mais output será gerado, cada SA é negociado independentemente)

• sa=0 indica que ou há um erro na fase 2 impedindo a negociação ou simplesmente não há tráfego forçando a fase 2 a ser negociada
• sa=1 indica que a fase 2 está estabelecida com sucesso
• sa=2 visível apenas no momento de rekey (renegociação) do SA

Além dos exemplos apresentados, compartilho alguns comandos chave que são extremamente úteis durante uma sessão de troubleshooting.

Validar negociação do túnel (fase 1 e fase 2):

diagnose vpn ike log-filter dst-addr4 x.x.x.x

diagnose debug application ike -1

diagnose debug enable

Validar que tráfego de/para de acordo está sendo enviado para o túnel adequadamente (de acordo com o filtro):

diagnose debug flow filter addr x.x.x.x

diagnose debug enable

diagnose debug flow trace start 10

Após uma sessão de troubleshooting é sempre recomendável desativar debugging com os comandos abaixo:

diagnose debug flow filter clear

diagnose debug disable

Coletar informação sobre um túnel específico (use o nome do túnel para coletar informações de um peer especifico):

diagnose vpn tunnel list name ‘VPN-NAME’

Validar estado de fase 1 do túnel:

diagnose vpn ike gateway list name ‘VPN-NAME’

Listar todos os túneis e o estado deles:

get vpn ipsec tunnel summary