Temos um cliente com 6 sites usando IPsec. De vez em quando, possivelmente uma vez por semana, às vezes uma vez por mês, os dados simplesmente param de fluir do servidor VPN Fortigate remoto para o cliente VPN MikroTik IPsec local.
Para demonstrar os sintomas do problema, anexei um diagrama. Na guia SAs instaladas do diagrama você notará um endereço IP de origem xx186.50 tentando se comunicar com xx7.3, mas 0 bytes atuais. xx186.50 é o servidor Fortigate IPsec remoto do cliente e xx7.73 é um endpoint IPsec baseado em MikroTik. Parece que os dados do lado remoto para nós nem sempre fluem.
As fases 1 e 2 são sempre estabelecidas, mas o tráfego sempre se recusa a fluir do lado remoto para nós.
Tentamos várias coisas ao longo do tempo, como reiniciar, acertar relógios, mexer na configuração, verificar novamente e verificar novamente a configuração, mas parece que o problema é totalmente aleatório. E às vezes coisas aleatórias resolvem isso. A certa altura, eu tinha uma teoria de que se o túnel fosse iniciado pelo lado deles, ele funcionaria, mas mexer em "Enviar contato inicial" não fez nenhuma diferença.
Tivemos muitas conversas com o cliente sobre isso, mas eles têm muito mais VPNs IPsec internacionais e apenas nossa configuração MikroTik está falhando.
Registro de fortalecimento:
http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654
Olhando para a base de conhecimento da Fortigate, parece que os SPIs não concordam e o DPD faria a diferença. Mas tentei todas as combinações de DPD deste lado sem sucesso. Gostaria de habilitar o DPD do outro lado, mas não consigo devido ao controle de alterações e também porque o cliente está dizendo que está funcionando em todos os outros sites exatamente com a mesma configuração.EDITAR DPD foi ativado
Diagrama do cliente VPN local mostrando nenhum fluxo de tráfego:
Incluí um arquivo de log mostrando loops contínuos de arquivo de log MikroTik "recebido um RU-THERE válido, ACK enviado":
echo: ipsec,debug,packet 84 bytes de xx7.183[500] a xx186.50[500]
echo: ipsec,debug,nome do pacote xx7.183[500]
echo: ipsec,debug,pacote de envio de pacote de xx7.183[500]
echo: ipsec,debug,pacote envia pacote para xx186.50[500]
eco: ipsec, depuração, pacote src4 xx7.183 [500]
eco: ipsec, depuração, pacote dst4 xx186.50[500]
echo: ipsec,debug,packet 1 vezes a mensagem de 84 bytes será enviada para xx186.50[500]
eco: ipsec, depuração, pacote 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf
eco: ipsec, depuração, pacote cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979
eco: ipsec, depuração, pacote 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8
echo: ipsec,debug,packet sendto Notificação de informações.
echo: ipsec,debug,packet recebeu um RU-THERE válido, ACK enviado
Recebi várias sugestões de especialistas em IPsec e do próprio MikroTik, sugerindo que o problema está no lado remoto. No entanto, a situação é bastante agravada porque outros 5 sites estão funcionando e o firewall do cliente está sob controle de alterações. A configuração também sempre funcionou por muitos anos, então eles afirmam que não pode ser um erro de configuração da parte deles. Esta sugestão parece plausível, mas não posso implementar devido ao controle de alterações. Só posso mudar o lado do cliente:
Certifique-se de que o respondedor IPSec tenha passivo=yes e send-initial-contact=no definidos.
Isso não funcionou.
EDITAR 9 de dezembro de 2013
Estou colando capturas de tela adicionais com a configuração do Fortigate e o que acreditamos serem os seletores do Modo Rápido no lado do Mikrotik.
Deixe-me reiterar que não acho que seja um problema de configuração. Eu especulo que seja um problema de tempo em que o lado A ou o lado B tentam enviar informações de forma muito agressiva, tornando a negociação das informações (por exemplo, o SPI) fora de sincronia.
EDITAR 11 de dezembro de 2013
Infelizmente tenho que desistir desse assunto. Felizmente tudo está funcionando. Por que está funcionando ainda é um mistério, mas para ilustrar melhor o que fizemos, postei outra imagem in-line.
Nós corrigimos isso por:
- Desativando PPPoE no cliente.
- Instalando roteador completamente novo (Roteador B) e testado na Border. Funcionou na Border.
- Desligando o novo roteador B na fronteira. E ENTÃO, SEM FAZER UMA ÚNICA ALTERAÇÃO, o roteador A do endpoint do cliente começou a funcionar. Portanto, apenas adicionar um roteador duplicado na fronteira e colocá-lo off-line novamente fez com que o roteador original funcionasse.
Então adicione esta correção à lista de coisas que fizemos:
- Reinício. Isso funcionou uma vez.
- Crie um novo túnel com novo IP. Isso funcionou uma vez, mas apenas uma vez. Depois de alterar o IP, o endpoint do cliente voltou a funcionar.
- Altere os servidores de horário.
- Mexa em todas as configurações possíveis.
- Espere. Uma vez, depois de um dia, simplesmente deu certo. Desta vez, mesmo depois de dias, nada deu certo.
Portanto, postulo que existe uma incompatibilidade no lado do Fortigate ou do MikroTik, que só acontece em situações muito aleatórias. A única coisa que não conseguimos tentar foi atualizar o firmware no Fortigate. Talvez haja um valor de configuração corrompido oculto ou um problema de tempo invisível para o configurador.
Especulo ainda que o problema é causado por problemas de tempo que causam incompatibilidade de SPI. E meu palpite é que o Fortigate não quer “esquecer” o antigo SPI, como se o DPD não estivesse funcionando. Acontece aleatoriamente e pelo que posso dizer apenas quando o endpoint A é Fortigate e o endpoint B é MikroTik. As constantes tentativas agressivas de tentar restabelecer a conexão "mantêm-se" nos antigos valores do SPI.
Acrescentarei a este post quando isso acontecer novamente.
EDITAR 12 de dezembro de 2013
Como esperado, aconteceu novamente. Como você deve se lembrar, temos 6 roteadores de ponto final IPsec do cliente MikroTik configuradosexatamente o mesmoconectando-se a um servidor Fortigate. O último incidente ocorreu novamente em um roteador aleatório, não aquele sobre o qual postei originalmente. Considerando a última correção onde instalamos esse roteador duplicado, usei este atalho:
- Desative o roteador A, o roteador que não deseja mais receber pacotes do Fortigate.
- Copie a configuração IPsec do roteador A para um roteador temporário mais próximo da borda da nossa rede.
- Desative imediatamente a configuração recém-criada.
- Reative o roteador A.
- Automaticamente ele simplesmente começa a funcionar.
Olhando para o comentário de @mbrownnyc, acredito que estamos tendo um problema com o Fortigate, não esquecendo os SPIs obsoletos, embora o DPD esteja ativado. Vou investigar o firmware do nosso cliente e publicá-lo.
Aqui está um novo diagrama, muito parecido com o anterior, mas apenas mostrando minha "correção":
Responder1
Pode não ser a causa do seu problema, mas pode ser uma informação útil para outros usuários. Tivemos um problema um pouco semelhante com uma VPN entre um Mikrotik e um Sonicwall. O tráfego pararia aleatoriamente, exigindo que as SA fossem liberadas.
No final, percebemos que o Sonicwall estava criando uma SA separada para cada política de rede (pela aparência da sua captura de tela, parece que você tem 2 políticas/sub-redes passando pela VPN). Não sei se essa configuração de 'SA por política' é codificada ou configurável, pois não tive acesso ao Sonicwall.
Nosso Mikrotik estava usando o nível 'require' para as políticas (o padrão, e visto na sua captura de tela). Isto faz com que o roteador crie um único SA com o ponto remoto. Ao enviar tráfego para qualquer uma das políticas desse peer, ele usará esse mesmo SA, independentemente da sub-rede src/dest.
Basicamente, isso significava que funcionava desde que usássemos apenas uma sub-rede. Assim que nosso Mikrotik tentasse enviar tráfego para a segunda sub-rede, ele enviaria pelo SA existente (que no que diz respeito ao Sonicwall é para um par de sub-rede específico), o Sonicwall reclamaria, os números de sequência do SA sairiam de whack e tudo parou. (No nosso caso, o cliente recebeu erros de 'repetição')
No final, foi tão simples quanto alterar o nível de política para 'único', de modo que ambas as extremidades usaram uma SA exclusiva para cada par de sub-rede exclusivo. Os túneis ficaram perfeitamente felizes depois disso.
Responder2
Eu sei que você verificou isso (assim como fiz quando tive um problema intermitente semelhante, mas completamente diferente), mas certifique-se de não ter um endereço IP duplicado que o roteador A esteja compartilhando. Isso causaria um problema intermitente quando o roteador do lado alto faz uma pesquisa arp para o roteador A e fica confuso. Você poderia pensar que dup Ips em roteadores daria um erro consistente, mas isso não acontece.