Phase2 ist mit IKEv2-Schlüsselaustausch aufgrund DH von Gruppenkonflikt aus
124223
Created On 02/13/20 03:00 AM - Last Modified 08/04/22 22:36 PM
Symptom
Phase2 ist nach Firewall dem Versuch von /Peer, den Schlüssel auszuhandeln, nach unten.
Environment
Der Peer ist kein Palo Alto-Gerät, das möglicherweise nicht dieselbe Chiffre unterstützt, die in der definiert Firewall ist.
- Möglicherweise müssen Sie das Verhalten mit dem Peer überprüfen, da ein Anbieter die im angegebene Gruppe nicht DH firewall unterstützt.
- Der Peer kann den Wert von den Einstellungen seines Peers erben PFS IKE (für diesen Fall Palo Altos IKE Krypto-Einstellung).
Beispiel für die IKEMGR Protokolle, die dem Zeitpunkt entnommen firewall wurden, an dem das Problem eintritt
1) Initiator
> less ikemgr.log
2020-02-11 13:44:04.216 +1100 [PNTF]: { 4: }: ====> IKEv2 CHILD SA NEGOTIATION FAILED AS INITIATOR, non-rekey; gateway SCPriv-Prod-A <====
====> Failed SA: 10.112.128.132[500]-10.113.48.36[500] message id:0x00000113 parent SN:13230 <==== Error code 19
2020-02-11 13:44:04.217 +1100 [PWRN]: { 5: }: 14 is not a child notify type
2020-02-11 13:44:04.217 +1100 [PERR]: { 5: }: received Notify payload protocol 0 type NO_PROPOSAL_CHOSEN2) Responder :
> less ikemgr.log
2020-02-11 13:44:08.102 +1100 [PNTF]: { 5: }: ====> IKEv2 CHILD SA NEGOTIATION STARTED AS RESPONDER, non-rekey; gateway SCPriv-Prod-A <====
====> Initiated SA: 10.112.128.132[500]-10.113.56.36[500] message id:0x0000001A parent SN:13282 <====
2020-02-11 13:44:08.102 +1100 [WARN]: { 5: 6}: selector SCPriv-Prod src is ambiguous, using the first one of the expanded addresses
2020-02-11 13:44:08.102 +1100 [WARN]: { 5: 6}: selector SCPriv-Prod dst is ambiguous, using the first one of the expanded addresses
2020-02-11 13:44:08.102 +1100 [PERR]: { 5: 6}: no proposal chosen
2020-02-11 13:44:10.217 +1100 [PWRN]: { 4: }: 17 is not a child notify type
2020-02-11 13:44:10.218 +1100 [PWRN]: { 5: }: 17 is not a child notify type
2020-02-11 13:44:10.219 +1100 [PWRN]: { 4: }: 14 is not a child notify type
2020-02-11 13:44:10.219 +1100 [PERR]: { 4: }: received Notify payload protocol 0 type NO_PROPOSAL_CHOSEN
2020-02-11 13:44:10.219 +1100 [PNTF]: { 4: }: ====> IKEv2 CHILD SA NEGOTIATION FAILED AS INITIATOR, non-rekey; gateway SCPriv-Prod-ABeispiel aus der Paketerfassung: Initator verhandelt den Schlüssel
Frame-Nr. 88,
Der Initiator ( ) verhandelt den Schlüssel und lässt den Peer PALO ALTO NETWORKS Firewall wissen, dass DHGroup 2048 MODP ( DH Group14)
Frame Nr. 89, Der Responder ( ) INVALID_KEY_PAYLOAD gesendet hat und den Peer darüber
VENDOR A informiert, dass er nur DH Group20/ecp384 akzeptiert (der Peer erbt den Wert von PaloAltos FW IKE Crypto-Einstellung).
VENDOR A Der Initiator ( ) verhandelt den Schlüssel und lässt den Peer
PALOALTO FW wissen, dass er DHGroup unterstützt MODP DH
VENDOR A NO_PROPOSAL_CHOSEN. DH
Cause
Bitte lesen Sie die unten RFC stehenden als Referenz:
RFC Besagt, dass
A die Nutzlast des Schlüsselaustauschs durch Kopieren des
öffentlichen Diffie-Hellman-Werts in den Teil "Schlüsselaustauschdaten" der Nutzlast erstellt wird.
Die Länge des öffentlichen Diffie-Hellman-Werts MUST entspricht der Länge des
Primmoduls, über den die Exponentiation
durchgeführt wurde, und setzt bei Bedarf null Bits auf den Wert vor.
Die DH Gruppe - identifiziert die Diffie-Hellman-Gruppe, in der die
Schlüsselaustauschdaten berechnet wurden (siehe Abschnitt 3.3.2). Wenn der ausgewählte
Vorschlag eine andere Diffie-Hellman-Gruppe verwendet, wird die Nachricht MUST mit einer
Notify-Nutzlast vom Typ INVALID_KE_PAYLOAD
NO_PROPOSAL_CHOSEN 14 keine der vorgeschlagenen
Krypto-Suiten abgelehnt.
INVALID_KE_PAYLOAD 17
Das Feld Gruppe in der D-H KE Nutzlast ist nicht die Gruppe,
die vom Responder für diesen Austausch ausgewählt wurde. Dieser Benachrichtigung sind zwei
Oktette von Daten zugeordnet: die
akzeptierte D-H Gruppe in großer Endreihenfolge.
Siehe unten Artikel, um das Debuggen für IKE
http://live.paloaltonetworks.com:80/t5/Management-Articles/How-to-Troubleshoot-IPSec- VPN- Connectivity-Issues/ta-p/59187 Befehle zu aktivieren, die
nützlich sein können, um das Debuggen und Durchführen der Paketerfassung anzuzeigen.
> debug ike global on debug > less mp-log ikemgr.log > debug ike pcap on > view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap > debug ike pcap off
Beachten Sie:
1) Im normalen Szenario sollte der Peer ( VENDOR A ) die entsprechende Einstellung haben, um die Konfiguration auf dem 2) Unter bestimmten Anforderungen für den Peer zu firewall
entsprechen, die möglicherweise nicht eine bestimmte Gruppe unterstützen DH (in diesem Fall unterstützt der Peer DH Group20 nicht), erbt er die IPSEC PFS von Peer IKE PFS (PaloAltos FW IKE Crypto-Einstellungen), die das Problem verursacht haben.
1) IKE Crypto-Profil konfiguriert mit DH Group20 (nicht von Peer unterstützt)
2) IPSEC Crypto Profile konfiguriert mit DH group14 (unterstützt von Peer)
Resolution
Stellen Sie sicher, dass sowohl die Crypto- als auch die Krypto-Einstellung über dieselbe Gruppe verfügt, die auf der Seite konfiguriert ist, um das IKE Verhalten von Peers und die IPSEC DH Firewall Tunnelstabilität zu gewährleisten.
Wenn der Peer beispielsweise DH Gruppe20 nicht unterstützt, können Sie eine andere DH Gruppe für beide Crypto-Einstellungen auf der firewall verwenden.