Resolución de problemas de IPsec para túneles de servicio en vEdge con IKEv2

En CLI también es posible mostrar los registros actuales/información de depuración para la ruta especificada.

monitor start /var/log/messages

Sugerencias para iniciar el proceso de resolución de problemas de IPsec

Es posible separar tres escenarios IPsec diferentes. Es un buen punto de referencia para identificar el síntoma para tener un mejor abordaje para saber comenzar.

1. El túnel IPsec no se establece.
2. El túnel IPsec se desactivó y se restableció por sí solo. (Inestable)
3. El túnel IPsec se desactivó y permanece en un estado descendente.

Para que el túnel IPsec no establezca síntomas, es necesario depurar en tiempo real para verificar cuál es el comportamiento actual en la negociación IKE.

Para el túnel IPSec cayó y se restableció en sus propios síntomas, más comúnmente conocido como túnel inestable y el análisis de la causa raíz (RCA) es necesario. Es indispensable conocer la marca de tiempo cuando el túnel cayó o tener un tiempo estimado para ver las depuraciones.

Para el túnel IPSec se desactivó y permanece en los síntomas de estado descendente, significa que el túnel funcionó antes, pero por cualquier razón, se desactivó y necesitamos saber la razón de desconexión y el comportamiento actual que impide que el túnel se establezca nuevamente con éxito.

Identifique los puntos antes de que comience la resolución del problema:

1. Túnel IPsec (número) con problemas y configuración.
2. La marca de tiempo cuando el túnel cayó (si corresponde).
3. Dirección IP del par IPsec (destino del túnel).

Todos los debugs y logs se guardan en archivos /var/log/messages, para los logs actuales, se guardan en el archivo de mensajes pero para este síntoma específico la inestabilidad podría identificarse horas/días después del problema, lo más probable es que los debugs relacionados estén en los mensajes1,2,3..etc. Es importante conocer la marca de tiempo para ver el archivo de mensaje correcto y analizar los debugs (charon) para la negociación IKE del túnel IPsec relacionado.

La mayoría de las depuraciones no imprimen el número del túnel IPsec. La manera más frecuente de identificar la negociación y los paquetes es con la dirección IP del par remoto y la dirección IP donde se origina el túnel en el borde. Algunos ejemplos de depuraciones IKE impresas:

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
  !

Síntoma 1.  El túnel IPsec no se establece

Como el problema puede ser la primera implementación para el túnel, no ha estado activo y las depuraciones IKE son la mejor opción.

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)

El último intercambio de paquetes DPD correcto se describe como la solicitud 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 [ ] 

 Paso 2. Reúna toda la información en el orden correcto:

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 

En el ejemplo descrito, el túnel deja de funcionar debido a que vEdge01 no recibe los paquetes DPD de 10.10.10.1. Se espera que después de 3 retransmisiones DPD, el par IPsec se establezca como "perdido" y el túnel deje de funcionar. Hay múltiples razones para este comportamiento, generalmente, está relacionado con el ISP donde los paquetes se pierden o se descartan en el trayecto. Si el problema ocurre una vez, no hay forma de rastrear el tráfico perdido; sin embargo, si el problema persiste, se puede rastrear el paquete con el uso de capturas en vEdge, el peer IPSec remoto y el ISP.

Síntoma 3. El túnel IPsec se desactivó y permanece en un estado descendente

Como se ha mencionado anteriormente en este síntoma, el túnel funcionaba correctamente pero, por cualquier motivo, se ha caído y no se ha podido volver a establecer correctamente. En esta situación, la red se ve afectada.

identifique los puntos antes de que comience la localización de averías:

1. Túnel IPsec (número) con problemas y configuración.
2. La marca de tiempo cuando el túnel cayó.
3. Dirección IP del par IPsec (destino del túnel)

Discordancia de PFS

En este ejemplo, la solución de problemas no comienza con la marca de tiempo cuando el túnel deja de funcionar. A medida que el problema persiste, las depuraciones IKE son la mejor opción. 

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

El comando debug está habilitado y se muestra negotiation.

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 

Nota:  Los paquetes CREATE_CHILD_SA se intercambian por cada nueva clave o nueva SA. Para obtener más referencias, vaya a Introducción al intercambio de paquetes IKEv2

Las depuraciones IKE muestran el mismo comportamiento y se repiten constantemente, por lo que es posible tomar parte de la información y analizarla: 

CREATE_CHILD_SA significa una nueva clave, con el propósito de que los nuevos SPIS se generen e intercambien entre los puntos finales IPsec.

• El vedge recibe el paquete de solicitud CREATE_CHILD_SA de 10.10.10.1.
• El vedge procesa la solicitud y verifica las propuestas (SA) enviadas por el peer 10.10.10.1
• El vedge compara la propuesta recibida enviada por el peer con sus propuestas configuradas.
• El CREATE_CHILD_SA intercambiado falla con " no se han encontrado propuestas aceptables".

En este punto, la pregunta es: ¿Por qué hay una discordancia de configuración si el túnel funcionó anteriormente y no se realizaron cambios?

Si se analiza en profundidad, hay un campo adicional en las propuestas configuradas que el par no está enviando.

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

Propuestas recibidas:
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 es el grupo DH 16, que vedges ha configurado para PFS (confidencialidad directa perfecta) en la fase 2 (sección IPsec).

PFS es la única configuración no coincidente en la que el túnel se puede establecer correctamente o no según quién sea el iniciador o el respondedor en la negociación IKE. Sin embargo, cuando se inicia la regeneración de la clave, el túnel no puede continuar y este síntoma puede presentarse o estar relacionado con él.

El túnel vEdge IPSec/Ikev2 no se reinicia después de ser desmontado debido a un evento DELETE

Consulte Cisco bug ID CSCvx86427 para obtener más información sobre este comportamiento.

A medida que el problema persiste, las depuraciones IKE son las mejores opciones. Sin embargo, para este bug particular si los debugs están habilitados no se muestra ninguna información ni el terminal ni el archivo de mensaje.

Para reducir este problema y verificar si vEdge llega al ID de bug de Cisco CSCvx86427, es necesario encontrar el momento en que el túnel deja de funcionar.

identifique los puntos antes de que comience la localización de averías:

1. Túnel IPsec (número) con problemas y configuración.
2. La marca de tiempo cuando el túnel cayó.
3. Dirección IP del par IPsec (destino del túnel)

Una vez que se identifique la marca de tiempo y se correlacionen la hora y los registros, revise los registros justo antes de que el túnel deje de funcionar.

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 

Nota:  Hay varios paquetes DELETES en una negociación IPsec, y DELETE para CHILD_SA es una DELETE esperada para un proceso REKEY, este problema se observa cuando se recibe un paquete DELETE IKE_SA puro sin ninguna negociación IPsec particular. Esa opción DELETE elimina todos los túneles IPsec/IKE.

Información Relacionada

• Depuración a nivel de protocolo y de intercambio de paquetes KEv2
• Intercambio de claves de Internet (IKE): RFC 2409
• IKEv2: RFC 7296
• IPSec de LAN a LAN de sitio a sitio entre vEdge y Cisco IOS
• Soporte Técnico y Documentación - Cisco Systems