Fehlerbehebung bei einem IKEv2 IPsec VPN-Tunnel, der von DPD heruntergefahren wurde

Fehlerbehebung bei einem IKEv2 IPsec VPN-Tunnel, der von DPD heruntergefahren wurde

12875
Created On 07/15/24 21:31 PM - Last Modified 08/14/24 01:42 AM


Objective


  • Überprüfen Sie die Konfiguration der Live-Überprüfung auf beiden Endpunkten des IPsec-VPN-Tunnels.
  • Verwenden Sie den Zeitstempel des DPD-Ausfallereignisses, um mit anderen Ereignissen zu korrelieren, die sich auf die Konnektivität zwischen den VPN-Peers auswirken könnten.
  • Beheben Sie Probleme mit der IPsec-VPN-Konnektivität.
  • Erfassen Sie Debug-Paketerfassungen, um zu überprüfen, ob die Firewall Liveness-Check-Pakete sendet und empfängt.


Environment


  • IPsec-VPN-Tunnel
  • IKEv2
  • DPD/ Liveness Check


Procedure


  1. Überprüfen Sie die Konfiguration der Live-Überprüfung auf beiden Endpunkten des IPsec-VPN-Tunnels. Navigieren Sie für NGFW zu Netzwerk- > Netzwerkprofile > IKE-Gateways > Erweiterte Optionen. Stellen Sie sicher, dass die Verfügbarkeitsprüfung aktiviert ist und das Intervall mit den Einstellungen am anderen Ende des Tunnels übereinstimmt:Liveness-Check
    1. IKEv2 verwendet eine Live-Prüfung (ähnlich wie Dead Peer Detection (DPD) in IKEv1), um zu bestimmen, ob ein Peer noch verfügbar ist. Die Option zur Lebendigkeitsprüfung ist standardmäßig aktiviert.
  2. Wenn der IPsec-Tunnel aufgrund von DPD ausfällt, werden die folgenden Protokollmeldungen im Systemprotokoll angezeigt:
    > show log system direction equal backward
    2019/03/06 18:24:04 low      vpn     seapa- ikev2-n 0  IKEv2 IKE SA is down determined by DPD.
    2019/03/06 17:26:27 low      vpn     seapa- ikev2-n 0  IKEv2 IKE SA is down determined by DPD.

    Und die folgenden Meldungen werden in den IKEMGR-Protokollen angezeigt:
    > less mp-log ikemgr.log
    2019-03-06 17:26:28.000 -0800  [INFO]: \{    1:    1}: DPD down, rekey vpn tunnel <awsseapa-to-azeapa>, SA state ESTABLISHED
    2019-03-06 18:24:05.000 -0800  [INFO]: \{    1:    1}: DPD down, rekey vpn tunnel <awsseapa-to-azeapa>, SA state ESTABLISHED
    Das Standardintervall der livität-Überprüfung beträgt alle 5 Sekunden, wenn SA untätig ist. Wenn die Verbindung unterbrochen wird, führt die Firewall 10 Live-Wiederholungen durch. Nachdem die maximale Anzahl von Wiederholungsversuchen erreicht wurde, beendet die Firewall die Zertifizierungsstellen der Phasen 1 und 2. Suchen Sie nach den obigen Meldungen, und notieren Sie sich den Zeitstempel, damit Sie ihn verwenden können, um andere verwandte Ereignisse zu korrelieren, was dazu beiträgt, die Ursache für den Fehler bei der Live-Überprüfung zu finden.
  3. Wenn der IPsec-Tunnel aufgrund von DPD ausfällt, ist dies ein Hinweis darauf, dass es Verbindungsprobleme zwischen den IPsec-VPN-Peers gibt. Weitere Informationen zur Behebung finden Sie unter Beheben von Problemen mit der IPSec-VPN-Konnektivität.
  4. Für ein anhaltendes Problem mit einem Tunnelausfall aufgrund von DPD und im Zweifelsfall, dass die Firewall das Live-Check-Paket empfängt oder sendet, bei dem es sich um das leere Informationspaket handelt. Legen Sie ein Wartungsfenster fest, um eine Debug-ikemgr-Paketerfassung zu erfassen:
    debug ike pcap on
    view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap
    scp export debug-pcap from ikemgr.pcap to username@host:path
    debug ike pcap off 
    
    Hinweis: Seien Sie sehr vorsichtig mit den oben genannten Befehlen, insbesondere mit dem orange hervorgehobenen, da er ressourcenintensiv werden kann, weshalb es empfohlen wird, ihn während eines Wartungsfensters auszugeben.
    1. Wenn die Firewall das leere Paket zur Überprüfung der Informationsintegrität sendet und empfängt, sieht die Paketerfassung wie folgt aus:Paket-Erfassung
    2. Auf ähnliche Weise können Sie eine Paketerfassung auf Datenebene zwischen den beiden Endpunkten des Tunnels durchführen, indem Sie die Quelle und das Ziel des Paketfilters auf die IP-Adressen der Endpunkte festlegen, wie in der folgenden Abbildung gezeigt:Paket-Erfassung 3
    3. Aktivieren Sie die Debugger für das betroffene Gateway mit dem folgenden Befehl:
      debug ike gateway <name of the gateway> on debug
      Die ikemg-Protokolle zeigen in diesem Fall die folgenden Meldungen an:
      2024-07-15 10:55:41.005 -0700  [DEBG]: 10.46.36.241[500] - 10.46.36.240[500]:(nil) 1 times of 76 bytes message will be sent over socket 1024
      2024-07-15 10:55:41.007 -0700  [DEBG]: processing isakmp packet
      2024-07-15 10:55:41.007 -0700  [DEBG]: ===
      2024-07-15 10:55:41.007 -0700  [DEBG]: 76 bytes message received from 10.46.36.240
      2024-07-15 10:55:41.007 -0700  [DEBG]: {    2:     }: [IKE Initiator] response message_id 704 expected 704
      2024-07-15 10:55:41.013 -0700  [DEBG]: {    2:     }: response exch type 37
      2024-07-15 10:55:41.013 -0700  [DEBG]: {    2:     }: update response message_id 0x2c0
      2024-07-15 10:55:46.005 -0700  [DEBG]: 10.46.36.241[500] - 10.46.36.240[500]:(nil) 1 times of 76 bytes message will be sent over socket 1024
      2024-07-15 10:55:46.006 -0700  [DEBG]: processing isakmp packet
      2024-07-15 10:55:46.006 -0700  [DEBG]: ===
      2024-07-15 10:55:46.006 -0700  [DEBG]: 76 bytes message received from 10.46.36.240
      2024-07-15 10:55:46.006 -0700  [DEBG]: {    2:     }: [IKE Initiator] response message_id 705 expected 705
      2024-07-15 10:55:46.014 -0700  [DEBG]: {    2:     }: response exch type 37
      2024-07-15 10:55:46.014 -0700  [DEBG]: {    2:     }: update response message_id 0x2c1
    4. Deaktivieren Sie die Debugger mit dem folgenden Befehl:
      debug ike gateway <name of the gateway> off
  5. WICHTIGER Hinweis zum Verhalten der IKEv2-Live-Überprüfung:
    1. DPD (das ist die Lebendigkeitsprüfung im Fall von IKEv2) ist immer aktiviert. Alle IKEv2-Pakete außer dem leeren Informationspaket dienen der Verfügbarkeitsprüfung.
    2. Das Live-Check-Paket (informativ) wird nur gesendet, wenn nach dem dpd_interval über die IKE SA und die untergeordnete SA keine Aktivität vorhanden ist.
    3. Aktivieren: Wenn diese Option auf Ja gesetzt ist, wird nach einiger Zeit der Inaktivität (IKE) eine leere Informationsnachricht gesendet. Diese Wartezeit wird durch dpd_interval definiert.
    4. Wenn die Live-Prüfung fehlgeschlagen ist, werden die IKE-SA und alle untergeordneten SAs, die über diese IKE-SA eingerichtet wurden, gelöscht. Das IKE-Gateway startet eine neue IKE_SA_INIT Exchange.
  6. Basierend auf der Paketerfassung, die zwischen den beiden Peers des Tunnels erfasst wurde, kann die Lösung des Problems darin bestehen, den Wert für das Intervall für die Live-Überprüfung anzupassen, indem er auf beiden Endpunkten erhöht wird, um die Überprüfung weniger streng zu machen. Andere Lösungen können das Korrigieren falsch konfigurierter Richtlinien, das Konfigurieren korrekter Routeneinträge oder das Beheben potenzieller Netzwerkprobleme umfassen, die sich auf die Erreichbarkeit des Remote-Peers auswirken.


Additional Information


Liveness-Check: Wenn nur ausgehender Datenverkehr auf allen SAs stattgefunden hat, die einer IKE-SA zugeordnet sind, ist es wichtig, die Live-Aktivität des anderen Endpunkts zu bestätigen, um schwarze Löcher zu vermeiden. IKEv2-Gateways können Live-Prüfungen durchführen, um zu verhindern, dass Nachrichten an einen toten Peer gesendet werden. Der Empfang einer neuen kryptografisch geschützten Nachricht auf einer IKE SA oder einer ihrer untergeordneten SAs stellt die Gültigkeit der IKE SA und aller ihrer untergeordneten SAs sicher.

Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HDbVCAW&lang=de&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language