Problembehandlung bei IPsec-Problemen für Service-Tunnel an vEdges mit IKEv2

In CLI können auch die aktuellen Protokolle/Debugging-Informationen für den angegebenen Pfad angezeigt werden.

monitor start /var/log/messages

Tipps zum Starten des Fehlerbehebungsprozesses bei IPsec-Problemen

Es ist möglich, drei verschiedene IPsec-Szenarien zu trennen. Es ist ein guter Bezugspunkt, um das Symptom zu identifizieren, um einen besseren Ansatz zu wissen, wie man beginnt.

1. Der IPsec-Tunnel lässt sich nicht herstellen.
2. Der IPsec-Tunnel stürzte ab und wurde von selbst wiederhergestellt. (Geflattert)
3. Der IPsec-Tunnel ist ausgefallen und befindet sich weiterhin im Downstate.

Da der IPsec-Tunnel keine Symptome feststellt, muss er in Echtzeit gedebuggt werden, um das aktuelle Verhalten der IKE-Aushandlung zu überprüfen.

Der IPsec-Tunnel ging nämlich aufgrund eigener Symptome auseinander und wurde wiederhergestellt. Dieser Vorgang wird gemeinhin als "tunnel flapped" (Tunnel-Flapping) bezeichnet und die Ursachenanalyse (RCA) ist erforderlich. Es ist unerlässlich, den Zeitstempel zu kennen, wenn der Tunnel ausgefallen ist, oder eine geschätzte Zeit zu haben, um die Debugs zu betrachten.

Für den Fall, dass der IPsec-Tunnel ausgefallen ist und an Downstate-Symptomen hängen bleibt, bedeutet dies, dass der Tunnel vorher funktioniert hat, aber aus irgendeinem Grund ist er ausgefallen, und wir müssen den Grund für den Abriss und das aktuelle Verhalten kennen, das verhindert, dass der Tunnel wieder erfolgreich hergestellt werden kann.

Identifizieren Sie die Punkte, bevor die Fehlerbehebung beginnt:

1. IPsec-Tunnel (Anzahl) mit Problemen und Konfiguration.
2. Der Zeitstempel, nach dem der Tunnel ausgefallen ist (falls zutreffend).
3. IPsec-Peer-IP-Adresse (Tunnelziel).

Alle Debug- und Protokolldateien werden in /var/log/messages-Dateien gespeichert, für die aktuellen Protokolle werden sie in der Datei "messages" gespeichert, aber für dieses spezielle Symptom könnte die Klappe Stunden/Tage nach dem Problem identifiziert werden, höchstwahrscheinlich wären die zugehörigen Debug-Dateien in den Nachrichten 1,2,3..etc. Es ist wichtig, den Zeitstempel zu kennen, um die richtige Meldungsdatei anzuzeigen und die Debug-Meldungen (Charon) für die IKE-Aushandlung des IPsec-Tunnels zu analysieren.

Bei den meisten Debugs wird die Anzahl des IPsec-Tunnels nicht ausgegeben. Die häufigste Methode zur Identifizierung der Aushandlung und der Pakete besteht in der IP-Adresse des Remote-Peers und der IP-Adresse, von der der Tunnel am vEdge stammt. Einige Beispiele für IKE-Debugging-Ausgaben:

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
  !

Symptom 1.  IPsec-Tunnel wird nicht eingerichtet

Da es sich um die erste Implementierung für den Tunnel handeln kann, wurde sie nicht durchgeführt, und die IKE-Debugging-Optionen sind die beste Option.

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)

Der letzte erfolgreiche DPD-Paketaustausch wird als Anforderung Nr. 542 beschrieben.

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 [ ] 

 Schritt 2: Zusammenstellen der Informationen in der richtigen Reihenfolge:

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 

Im beschriebenen Beispiel fällt der Tunnel aus, da vEdge01 die DPD-Pakete nicht von 10.10.10.1 empfängt. Es wird erwartet, dass nach 3 DPD-Neuübertragungen der IPsec-Peer als "verloren" festgelegt wird und der Tunnel ausfällt. Dieses Verhalten hat mehrere Gründe. Normalerweise hängt es mit dem ISP zusammen, bei dem Pakete verloren gehen oder im Pfad verworfen werden. Wenn das Problem einmal auftritt, gibt es keine Möglichkeit, den verlorenen Datenverkehr zu verfolgen. Wenn das Problem jedoch weiterhin besteht, kann das Paket mithilfe von Erfassungen auf vEdge, Remote-IPSec-Peer und dem ISP verfolgt werden.

Symptom 3. Der IPsec-Tunnel ist ausgefallen und befindet sich weiterhin im Downstate

Wie bereits in diesem Symptom erwähnt, funktionierte der Tunnel zuvor gut, aber aus irgendeinem Grund kam er herunter und der Tunnel konnte sich nicht wieder erfolgreich etablieren. In diesem Szenario liegt eine Beeinträchtigung des Netzwerks vor.

Identifizieren Sie die Punkte, bevor die Fehlerbehebung beginnt:

1. IPsec-Tunnel (Anzahl) mit Problemen und Konfiguration.
2. Der Zeitstempel, als der Tunnel ausfiel.
3. IPsec-Peer-IP-Adresse (Tunnelziel)

PFS-Nichtübereinstimmung

In diesem Beispiel beginnt die Fehlerbehebung nicht mit dem Zeitstempel, wenn der Tunnel ausfällt. Da das Problem weiterhin besteht, sind die IKE-Debugging-Optionen die beste Option. 

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

Der Debug-Kiked ist aktiviert, und die Verhandlung wird angezeigt.

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 

Anmerkung:  CREATE_CHILD_SA-Pakete werden für jeden neuen Schlüssel oder jede neue SA ausgetauscht. Weitere Referenzen finden Sie unter Grundlagen von IKEv2 Packet Exchange.

IKE-Debugs verhalten sich genauso, und es wird ständig wiederholt, sodass es möglich ist, einen Teil der Informationen zu analysieren: 

CREATE_CHILD_SA ist ein Schlüssel, mit dem der neue SPIS generiert und zwischen den IPsec-Endpunkten ausgetauscht werden soll.

• Der vedge empfängt das CREATE_CHILD_SA-Anforderungspaket von 10.10.10.1.
• Der vedge verarbeitet die Anforderung und verifiziert die vom Peer 10.10.10.1 gesendeten Vorschläge.
• Der vedge vergleicht den vom Peer gesendeten empfangenen Vorschlag mit den konfigurierten Vorschlägen.
• Der Austausch von CREATE_CHILD_SA schlägt fehl mit "Es wurden keine akzeptablen Vorschläge gefunden".

An dieser Stelle stellt sich die Frage: Warum stimmt die Konfiguration nicht überein, wenn der Tunnel zuvor funktioniert hat und keine Änderungen vorgenommen wurden?

Detaillierte Analyse: Es gibt ein zusätzliches Feld für die konfigurierten Vorschläge, die nicht vom Peer gesendet werden.

konfigurierte Vorschläge: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ

Empfangene Vorschläge:
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 ist die DH-Gruppe 16, die von Vedges für PFS (perfect-forward-secrecy) in Phase 2 (IPsec-Abschnitt) konfiguriert wurde.

PFS ist die einzige Mismatch-Konfiguration, bei der der Tunnel erfolgreich eingerichtet werden kann, je nachdem, wer der Initiator oder Responder in der IKE-Aushandlung ist. Wenn der Rekey jedoch startet, kann der Tunnel nicht fortgesetzt werden, und dieses Symptom kann dargestellt oder in Beziehung gesetzt werden.

vEdge IPSec/IKEv2-Tunnel wird nach einem DELETE-Ereignis nicht neu initiiert

Weitere Informationen zu diesem Verhalten finden Sie unter Cisco Bug-ID CSCvx86427.

Da das Problem weiterhin besteht, sind die IKE-Debugging-Optionen die beste Option. Für diesen speziellen Bug, wenn Debug-Meldungen aktiviert sind, werden jedoch weder das Terminal noch die Meldungsdatei angezeigt.

Um dieses Problem einzugrenzen und zu überprüfen, ob vEdge die Cisco Bug-ID CSCvx86427 erreicht, muss der Zeitpunkt ermittelt werden, an dem der Tunnel ausfällt.

Identifizieren Sie die Punkte, bevor die Fehlerbehebung beginnt:

1. IPsec-Tunnel (Anzahl) mit Problemen und Konfiguration.
2. Der Zeitstempel, als der Tunnel ausfiel.
3. IPsec-Peer-IP-Adresse (Tunnelziel)

Wenn der Zeitstempel identifiziert wurde und Zeit und Protokolle korreliert sind, überprüfen Sie die Protokolle kurz vor dem Ausfall des Tunnels.

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 

Anmerkung:  Es gibt mehrere DELETES-Pakete in einer IPsec-Aushandlung, und DELETE für CHILD_SA ist ein erwartetes DELETE für einen REKEY-Prozess. Dieses Problem tritt auf, wenn ein reines IKE_SA-DELETE-Paket ohne eine bestimmte IPsec-Aushandlung empfangen wird. Durch diese DELETE-Anweisung werden alle IPsec/IKE-Tunnel entfernt.

Zugehörige Informationen

• KEv2-Paketaustausch und Debugging auf Protokollebene
• Internet Key Exchange (IKE) – RFC 2409
• IKEv2 - RFC 7296
• Site-to-Site-LAN zu LAN IPSec zwischen vEdge und Cisco IOS
• Technischer Support und Dokumentation für Cisco Systeme