Identificar e Solucionar Problemas de IPsec para Túneis de Serviço em Bordas com IKEv2

Na CLI, também é possível exibir os logs/informações de depuração atuais do caminho especificado.

monitor start /var/log/messages

Dicas para iniciar o processo de solução de problemas de IPsec

É possível separar três cenários IPsec diferentes. É um bom ponto de referência para identificar o sintoma para ter uma melhor abordagem para saber como começar.

1. O túnel IPsec não é estabelecido.
2. O túnel IPsec caiu e foi restabelecido sozinho. (Flapped)
3. O túnel IPsec caiu e permanece em estado inativo.

Para que o túnel IPsec não estabeleça sintomas, é necessário depurar em tempo real para verificar qual é o comportamento atual na negociação de IKE.

Para o túnel IPsec caiu e foi restabelecido em seus próprios sintomas, mais comumente conhecido como túnel Flapped e a análise da causa raiz (RCA) é necessária. É indispensável saber o timestamp quando o túnel caiu ou ter um tempo estimado para examinar as depurações.

Para o túnel IPsec desligado e permanece em sintomas de estado de inatividade, significa que o túnel funcionou antes, mas por qualquer motivo, ele desceu e precisamos saber o motivo do desligamento e o comportamento atual que impede que o túnel seja estabelecido com sucesso novamente.

Identifique os pontos antes do início da solução de problemas:

1. Túnel IPsec (Número) com problemas e configuração.
2. O carimbo de data e hora quando o túnel caiu (se aplicável).
3. IPsec peer IP address (destino do túnel).

Todas as depurações e registros são salvos em arquivos /var/log/messages, para os registros atuais, eles são salvos no arquivo de mensagens, mas para esse sintoma específico, o flap pode ser identificado horas/dias após o problema, provavelmente as depurações relacionadas estariam em mensagens1, 2, 3, etc. É importante saber o timestamp para examinar o arquivo de mensagem correto e analisar as depurações (charon) para a negociação IKE do túnel IPsec relacionado.

A maioria das depurações não imprime o número do túnel IPsec. A maneira mais frequente de identificar a negociação e os pacotes é com o endereço IP do peer remoto e o endereço IP onde o túnel é originado na borda. Alguns exemplos de depurações de IKE impressas:

Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_IPsec2_1'
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1

Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_ipsec2_1'
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jun 18 00:31:22 vedge01 charon: 16[NET] sending packet: from 10.132.3.92[500] to 10.10.10.1[500] (464 bytes)
Jun 18 00:31:22 vedge01 charon: 12[NET] received packet: from 10.10.10.1[500] to 10.132.3.92[500] (468 bytes)
Jun 18 00:31:22 vedge01 charon: 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HTTP_CERT_LOOK) N(FRAG_SUP) V ]
Jun 18 00:31:22 vedge01 charon: 12[ENC] received unknown vendor ID: 4f:85:58:17:1d:21:a0:8d:69:cb:5f:60:9b:3c:06:00
Jun 18 00:31:22 vedge01 charon: 12[IKE] local host is behind NAT, sending keep alives

interface ipsec2
  ip address 192.168.1.9/30
  tunnel-source      10.132.3.92
  tunnel-destination 10.10.10.1
  dead-peer-detection interval 30
  ike
   version      2
   rekey        86400
   cipher-suite aes256-cbc-sha1
   group        14
   authentication-type
    pre-shared-key
     pre-shared-secret $8$wgrs/Cw6tX0na34yF4Fga0B62mGBpHFdOzFaRmoYfnBioWVO3s3efFPBbkaZqvoN
    !
   !
  !
  ipsec
   rekey                   3600
   replay-window           512
   cipher-suite            aes256-gcm
   perfect-forward-secrecy group-14
  !

Sintoma 1.  O túnel IPsec não é estabelecido

Como o problema pode ser a primeira implementação para o túnel, ele não foi ativado e as depurações de IKE são a melhor opção.

Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down 

Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits

Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
Jun 18 00:28:22 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)  

Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 

Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request 
Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ] 
Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

A última troca de pacotes DPD bem-sucedida é descrita como solicitação nº 542.

Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ] 
Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 13.51.17.190[4500] to 10.10.10.1[4500] (76 bytes) 
Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ] 

 Etapa 2. Junte todas as informações na ordem correta:

Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ] 
Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 10.132.3.92[4500] (76 bytes) 
Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ] 

Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request 
Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ] 
Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 

Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
Jun 18 00:28:22 Lvedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 

Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"LONDSR01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down 

Para o exemplo descrito, o túnel cai devido ao vEdge01 não receber os pacotes DPD de 10.10.10.1. Ele é esperado após 3 retransmissões DPD, o peer IPsec é definido como "perdido" e o túnel é desativado. Há várias razões para esse comportamento, geralmente, ele está relacionado ao ISP onde os pacotes são perdidos ou descartados no caminho. Se o problema ocorrer uma vez, não há como rastrear o tráfego perdido, no entanto, se o problema persistir, o pacote poderá ser rastreado com o uso de capturas no vEdge, no peer remoto de IPSec e no ISP.

Sintoma 3. O túnel IPsec caiu e permanece em estado de inatividade

Como mencionado anteriormente neste sintoma, o túnel funcionava normalmente, mas por qualquer razão, desceu e o túnel não pôde ser estabelecido novamente com sucesso. Nesse cenário, há um efeito na rede.

identifique os pontos antes do início da solução de problemas:

1. Túnel IPsec (Número) com problemas e configuração.
2. O carimbo de data e hora quando o túnel caiu.
3. Endereço IP do peer IPsec (destino do túnel)

Incompatibilidade de PFS

Neste exemplo, a solução de problemas não começa com o carimbo de data e hora quando o túnel cai. À medida que o problema persiste, as depurações de IKE são a melhor opção. 

interface ipsec1
  description             VWAN_VPN
  ip address 192.168.0.101/30
  tunnel-source-interface ge0/0
  tunnel-destination      10.10.10.1
  ike
   version      2
   rekey        28800
   cipher-suite aes256-cbc-sha1
   group        2
   authentication-type
    pre-shared-key
     pre-shared-secret "$8$njK2pLLjgKWNQu0KecNtY3+fo3hbTs0/7iJy6unNtersmCGjGB38kIPjsoqqXZdVmtizLu79\naQdjt2POM242Yw=="
    !
   !
  !
  ipsec
   rekey                   3600
   replay-window           512
   cipher-suite            aes256-cbc-sha1
   perfect-forward-secrecy group-16 
  !
  mtu                     1400
  no shutdown

O campo debug iked está ativado e a negociação é exibida.

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (508 bytes) 
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] parsed CREATE_CHILD_SA request 557 [ SA No TSi TSr ] 
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ 
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ 
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] no acceptable proposal found 
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] failed to establish CHILD_SA, keeping IKE_SA 
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] generating CREATE_CHILD_SA response 557 [ N(NO_PROP) ] 
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes) 

daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (76 bytes) 
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] parsed INFORMATIONAL request 558 [ ] 
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] generating INFORMATIONAL response 558 [ ] 
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes) 
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (396 bytes) 
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[ENC] parsed CREATE_CHILD_SA request 559 [ SA No TSi TSr ] 
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ 
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ 
daemon.info: Apr 27 05:12:58 Avedge01 charon: 07[IKE] no acceptable proposal found 
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA 

Observação: os pacotes CREATE_CHILD_SA são trocados por cada chave nova ou SA nova. Para obter mais referências, navegue até Understanding IKEv2 Packet Exchange (Compreendendo o Intercâmbio de Pacotes IKEv2)

As depurações de IKE mostram o mesmo comportamento e são repetidas constantemente, de modo que é possível pegar uma parte das informações e analisá-las: 

CREATE_CHILD_SA significa um rechaveamento, com a finalidade de que o novo SPIS seja gerado e trocado entre os endpoints IPsec.

• A borda recebe o pacote de solicitação CREATE_CHILD_SA de 10.10.10.1.
• O vedge processa a solicitação e verifica as propostas (SA) enviadas pelo peer 10.10.10.1
• A diferença compara a proposta recebida enviada pelo peer com suas propostas configuradas.
• A troca CREATE_CHILD_SA falhou com " nenhuma proposta aceitável encontrada".

Neste ponto, a questão é: Por que há uma incompatibilidade de configuração se o túnel funcionou anteriormente e nenhuma alteração foi feita?

Analisar profundamente, há um campo extra nas propostas configuradas que o peer não está enviando.

propostas configuradas: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ

Propostas recebidas:
ESP:AES_GCM_16_256/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ

MODP_4096 é o grupo DH 16, que as bordas configuraram para PFS (perfeito para encaminhamento de sigilo) na fase 2 (seção IPsec).

O PFS é a única configuração de incompatibilidade na qual o túnel pode ser estabelecido com êxito ou não de acordo com quem é o iniciador ou respondente na negociação IKE. No entanto, quando a chave rekey inicia, o túnel não pode continuar e esse sintoma pode ser apresentado ou relacionado a ele.

O túnel vEdge IPSec/Ikev2 não é reiniciado após ser desligado devido a um evento de EXCLUSÃO

Consulte o bug da Cisco ID CSCvx86427 para obter mais informações sobre esse comportamento.

Conforme o problema persiste, as depurações de IKE são as melhores opções. No entanto, para esse bug específico se as depurações estiverem habilitadas, nenhuma informação será exibida nem no terminal nem no arquivo de mensagem.

Para reduzir esse problema e verificar se o vEdge atinge o bug da Cisco ID CSCvx86427, é necessário encontrar o momento em que o túnel cai.

identifique os pontos antes do início da solução de problemas:

1. Túnel IPsec (Número) com problemas e configuração.
2. O carimbo de data e hora quando o túnel caiu.
3. Endereço IP do peer IPsec (destino do túnel)

Depois que o carimbo de data/hora for identificado e o tempo e os registros estiverem correlacionados, revise os registros logo antes de quando o túnel cair.

Apr 13 22:05:21 vedge01 charon: 12[IKE] received DELETE for IKE_SA ipsec1_1[217] 
Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1] 
Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1] 
Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted 
Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted 
Apr 13 22:05:21 vedge01 charon: 12[ENC] generating INFORMATIONAL response 4586 [ ] 
Apr 13 22:05:21 vedge01 charon: 12[NET] sending packet: from 10.16.0.5[4500] to 10.10.10.1[4500] (80 bytes) 
Apr 13 22:05:21 vedge01 charon: 12[KNL] Deleting SAD entry with SPI 00000e77 
Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec1 DOWN
Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.1.0.1 vpn-id:1 if-name:"ipsec1" new-state:down 

Observação: há vários pacotes DELETES em uma negociação IPsec e DELETE para CHILD_SA é uma DELETE esperada para um processo REKEY, esse problema é visto quando um pacote IKE_SA DELETE puro é recebido sem nenhuma negociação IPsec específica. Essa EXCLUSÃO remove todo o túnel IPsec/IKE.

Informações Relacionadas

• Intercâmbio de pacote KEv2 e depuração de nível de protocolo
• O Internet Key Exchange (IKE) - RFC 2409
• IKEv2 - RFC 7296
• IPSec de LAN para LAN entre vEdge e Cisco IOS
• Suporte Técnico e Documentação - Cisco Systems