O que pode impedir o sucesso do aperto de mão IKE na construção de um túnel IPSEC?

Question

Nós usamos o Cisco ASA para nossas VPNs IPSEC, usando o método EZVPN. Ocasionalmente, nos deparamos com problemas em que um ISP fez uma alteração em sua rede e nossa VPN parou de funcionar. Nove em dez vezes o ISP nega que a mudança possa ter impedido que isso funcione - suspeito, porque eles não entendem exatamente o que poderia ter causado o problema. Em vez de apenas bater cabeças com eles, quero tentar apontá-los em uma direção que possa ter uma resolução mais rápida.

No meu incidente atual, posso ssh na interface externa do ASA e fazer uma pequena pesquisa:

 sh crypto isakmp sa

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: {Public IP address of London ASA}
    Type    : user            Role    : initiator
    Rekey   : no              State   : AM_TM_INIT_XAUTH_V6C

Na outra extremidade do link, vejo o seguinte:

Active SA: 26
<snip>
25  IKE Peer: {public IP address of Port-Au-Prince-ASA}
    Type    : user            Role    : responder
    Rekey   : no              State   : AM_TM_INIT_MODECFG_V6H

Não consigo encontrar nenhuma documentação para o que é AM_TM_INIT_XAUTH_V6C ou AM_TM_INIT_MODECFG_V6H , mas tenho certeza que significa que o handshake do IKE falhou por algum motivo.

Alguém pode sugerir alguma coisa que possa estar impedindo o IKE de ter sucesso ou detalhes específicos sobre o que AM_TM_INIT_XAUTH_V6C significa?

Atualização : Conectamos o ASA no site de um cliente de outro ISP. A conexão VPN surgiu imediatamente. Isso confirma que o problema não está relacionado à configuração. O ISP agora está aceitando a responsabilidade e investigando mais.

Atualização : a conexão voltou a ficar on-line na semana passada. Eu avisei o ISP para ver se eles mudaram alguma coisa, mas não ouvi de volta ainda. Frustrantemente, estou vendo agora um problema semelhante em outro site. Eu encontrei um documento da Cisco sobre os efeitos da fragmentação na VPN . Estou começando a pensar que isso pode ser a causa dos problemas que estou vendo.

    

Answer 1

Com um pouco de ajuda da Cisco, fiz uma análise mais profunda do que estava acontecendo e descobri as coisas que precisava verificar. As coisas úteis que a Cisco me disse:

• debug crypto isakmp 5 fornece detalhes suficientes para ver se estão ocorrendo problemas com o tráfego ISAKMP
• clear crypto isakmp sa apaga associações de segurança obsoletas.
• clear crypto isakmp {client_ip_address} pode ser usado no HQ para limpar uma associação de segurança específica (você não necessariamente deseja limpar todas as suas associações de segurança se for apenas um dispositivo com problemas!
• as capturas de pacotes em ambas as extremidades são realmente úteis para descobrir o que está acontecendo

Lendo um pouco sobre o pacote IPSEC, e o ISAKMP mostrou mais especificamente que o seguinte precisa ser permitido através de qualquer firewall no caminho:

• Tráfego ISAKMP na porta UDP 500
• Tráfego ISAKMP (usado para o NAT-Tunneling) na porta UDP 4500
• Tráfego ESP (Protocolo IP 50)
• Tráfego AH (Protocolo IP 51)

Parece que muitas pessoas por aí não percebem a diferença importante entre os protocolos IP e as portas TCP / UDP.

As seguintes capturas de pacotes focam nos tipos de tráfego acima. Estes foram configurados tanto no remoto quanto no ASA do HQ:

object service isakmp-nat-t 
    service udp destination eq 4500 
    description 4500
object-group service ISAKMP-Services
    description Traffic required for ISAKMP
    service-object esp 
    service-object ah 
    service-object object isakmp-nat-t 
    service-object udp destination eq isakmp
access-list ISAKMP extended permit object-group ISAKMP-Services host {hq_ip_address} host {remote_ip_address}
access-list ISAKMP extended permit object-group ISAKMP-Services host {remote_ip_address} host {hq_ip_address}
capture ISAKMP access-list ISAKMP interface outside

Você pode baixar as capturas de cada dispositivo em https://{device_ip_address}/capture/ISAKMP/pcap e analisá-las em Wireshark .

Minhas capturas de pacotes mostraram que o tráfego do ISAKMP descrito acima estava ficando fragmentado - já que esses pacotes são criptografados, uma vez que eles são fragmentados, é difícil reconectá-los e as coisas quebram.

Dar esta informação para o ISP significava que eles poderiam fazer sua própria verificação focada, e resultaram na realização de algumas alterações em um firewall. Acontece que o ISP estava bloqueando todo o tráfego ICMP em seu roteador de borda, o que significava que a descoberta do MTU do caminho estava quebrada, resultando em pacotes ISAKMP fragmentados. Depois que eles pararam de bloquear o ICMP, a VPN apareceu (e espero que todos os clientes tenham começado a obter um serviço melhor em geral).

    

Answer 2

É bem possível que o seu ISP esteja interpretando mal o seu tráfego como compartilhamento de arquivos P2P ou algo nefasto. Dê uma olhada no M-Lab para descobrir se é isso que poderia estar acontecendo.

    

Answer 3

Um erro AM_TM_INIT_XAUTH provavelmente significa que suas chaves pré-compartilhadas não correspondem. (fonte: www.cisco.com/warp/public/471/easyvpn-nem.pdf)

Tudo o que precisa para trabalhar para estabelecer uma sessão IPSec é para o tráfego udp destinado à porta 500 (para IKE) e tráfego ESP (ou udp 4500 para NAT-T) para ser permitido. Isso parece um problema de configuração em vez de um problema causado pelo ISP. Sinta-se à vontade para postar sua configuração relevante, caso queira alguma ajuda para verificar.