Solucionar problemas de IPsec para túneis de serviço em bordas com IKEv2

Na CLI também é possível exibir os logs atuais/informações de depuração para o 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 diferentes de IPsec. É um bom ponto de referência para identificar o sintoma para ter uma abordagem melhor para saber como começar.

1. O túnel IPsec não é estabelecido.
2. O túnel IPsec foi desativado e restabelecido sozinho. (Não sincronizado)
3. O túnel IPsec foi desativado e permanece em um estado de inatividade.

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 IKE.

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

Para o túnel IPsec ser desativado e permanecer em sintomas de estado inativo, significa que o túnel funcionou antes, mas por qualquer motivo, ele foi desativado e precisamos saber o motivo da desativação e o comportamento atual que impede que o túnel seja estabelecido com êxito 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/hora em que o túnel foi desativado (se aplicável).
3. Endereço IP do par IPsec (destino do túnel).

Todas as depurações e logs são salvos em arquivos /var/log/messages, para os logs atuais, eles são salvos em arquivos de mensagens, mas para esse sintoma específico, a oscilação pode ser identificada 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 de onde o túnel é originado na borda. Alguns exemplos de depurações 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 fica inativo porque o vEdge01 não recebe os pacotes DPD de 10.10.10.1. É esperado que após 3 retransmissões DPD, o peer IPsec seja definido como "perdido" e o túnel fique inativo. Há várias razões para esse comportamento, normalmente, ele está relacionado ao ISP onde os pacotes são perdidos ou descartados no caminho. Se o problema ocorrer uma vez, não haverá 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 IPSec remoto 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 motivo ele foi desativado e o túnel não pôde ser estabelecido novamente com êxito. 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/hora de quando o túnel foi desativado.
3. Endereço IP do par IPsec (destino do túnel)

Incompatibilidade de PFS

Neste exemplo, a solução de problemas não começa com o carimbo de data/hora quando o túnel é desativado. À medida que o problema persistir, 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 comando debug iked é 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 

Note:  Os pacotes CREATE_CHILD_SA são trocados para cada rechaveamento ou nova SA. Para obter mais referências, navegue para Compreendendo o IKEv2 Packet Exchange

As depurações de IKE mostram o mesmo comportamento e ele é repetido constantemente, portanto, é possível tomar parte das informações e analisá-las: 

CREATE_CHILD_SA significa uma nova chave, com a finalidade de que o novo SPIS seja gerado e trocado entre os pontos finais IPsec.

• A borda recebe o pacote de solicitação CREATE_CHILD_SA de 10.10.10.1.
• A vedge processa a solicitação e verifica as propostas (SA) enviadas pelo peer 10.10.10.1
• O vedge compara a proposta recebida enviada pelo peer com suas propostas configuradas.
• A troca de CREATE_CHILD_SA falha 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?

Analise detalhadamente, 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 vedges configurou para PFS (perfect-forward-secret) na fase 2 (seção IPsec).

O PFS é a única configuração incompatível 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 o rechaveamento é iniciado, o túnel não pode continuar e esse sintoma pode ser apresentado ou relacionado.

O túnel vEdge IPSec/Ikev2 não é reiniciado após ser desativado devido a um evento DELETE

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

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

Para restringir esse problema e verificar se o vEdge atinge o bug da Cisco ID CSCvx86427, é necessário descobrir o momento em que o túnel fica inativo.

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/hora de quando o túnel foi desativado.
3. Endereço IP do par IPsec (destino do túnel)

Depois que o carimbo de data/hora for identificado e a hora e os registros estiverem correlacionados, revise os registros imediatamente antes de o túnel ser desativado.

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 

Note:  Há vários pacotes DELETES em uma negociação de IPsec e DELETE para CHILD_SA é um DELETE esperado para um processo REKEY. Esse problema é visto quando um pacote IKE_SA DELETE puro é recebido sem nenhuma negociação de IPsec específica. Esse DELETE remove todo o túnel IPsec/IKE.

Informações Relacionadas

• Troca de pacotes no IKEv2 e depuração no nível do protocolo
• Internet Key Exchange (IKE) – RFC 2409
• IKEv2 - RFC 7296
• IPSec de LAN para LAN de site a site entre vEdge e Cisco IOS
• Suporte Técnico e Documentação - Cisco Systems