La phase2 est en baisse avec l’échange clé IKEv2 en raison DH de l’inadéquation du groupe
124245
Created On 02/13/20 03:00 AM - Last Modified 08/04/22 22:36 PM
Symptom
La phase2 est en baisse après que l’un Firewall ou l’autre /Peer a essayé de négocier la clé.
Environment
Le pair n’est pas un appareil Palo Alto qui peut ne pas prendre en charge le même chiffre défini dans le Firewall .
- Vous devrez peut-être vérifier le comportement avec le pair car certains fournisseurs ne prend pas en charge le DH groupe spécifié dans le firewall .
- Le pair peut hériter PFS de la valeur des paramètres de ses pairs IKE (pour ce cas, le paramètre IKE crypto de Palo Alto).
Exemple des journaux IKEMGR pris à partir du moment firewall où le problème se produit
1) Initiateur
> 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) Répondeur :
> 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-AExemple de capture de paquets : Initator négocie la clé
Frame #88,
The initiateur ( ) négocie la clé, en faisant savoir au PALO ALTO NETWORKS Firewall pair que DHGroup # 2048 MODP ( DH Group14) Frame #89, The responder ( ) a envoyé INVALID_KEY_PAYLOAD et faire savoir au pair que
son acceptation que
VENDOR A DH Group20/ecp384 (le pair héritent de la valeur de PaloAlto FW 's Crypto réglage). en fait ne prend pas en charge IKE
VENDOR A Group20 (cela peut varie dans l’environnement du client)
Frame #90,
L’initiateur ( PALOALTO FW ) négocie la clé, en faisant savoir au pair qu’il prend en charge DHGroup # 2048 MODP ( DH Group14)
Frame #91,
The responder ( ) envoyé NO_PROPOSAL_CHOSEN car il VENDOR A n’était pas d’accord avec le DH groupe défini.
Cause
Veuillez consulter ce qui suit pour référence : indique que la charge utile d’échange de clés est construite en RFC
RFC
A copiant sa valeur publique Diffie-Hellman
dans la partie « Données d’échange clés » de la charge utile.
La longueur de la valeur publique Diffie-Hellman est égale à la MUST
longueur du modulus principal sur lequel l’exposant a été
effectué, prépendant zéro bits à la valeur si nécessaire.
Le DH Groupe # identifie le groupe Diffie-Hellman dans lequel les données d’échange de clés ont été
calculées (voir la section 3.3.2). Si la proposition
sélectionnée utilise un groupe Diffie-Hellman différent, le message doit être rejeté avec une charge utile notifier de type INVALID_KE_PAYLOAD NO_PROPOSAL_CHOSEN MUST
14
Aucune des suites crypto proposées n’était acceptable.
INVALID_KE_PAYLOAD 17
Le D-H champ Groupe # dans la charge KE utile n’est pas le groupe #
sélectionné par le répondeur pour cet échange. Il y a
deux octets de données associés à cette notification : le
Groupe accepté # dans le grand ordre D-H endian.
S’il vous plaît voir ci-dessous l’article pour activer le IKE
débogage VPN- pour http://live.paloaltonetworks.com:80/t5/Management-Articles/How-to-Troubleshoot-IPSec- connectivité-questions/ta-p/59187
Commandes qui peuvent être utiles pour afficher le débogage et effectuer la capture de paquets
> 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
Prendre note:
1) Dans le scénario normal, le pair ( VENDOR A ) devrait avoir le paramètre respectif pour correspondre à la configuration sur le firewall
2) En vertu de certaines exigences sur le pair, qu’il peut ne pas soutenir groupe DH spécifique (pour ce cas, le pair ne prend pas en charge DH Group20), il IPSEC PFS hérite de la peer IKE PFS (PaloAlto FW 's Crypto paramètres) qui a IKE causé le problème.
1) IKE Crypto Profile configuré avec DH group20 (non pris en charge par peer)
2) IPSEC Crypto Profile configuré avec DH group14 (pris en charge par peer)
Resolution
Assurez-vous que IKE crypto et crypto réglage a le même groupe IPSEC DH configuré sur Firewall le côté pour répondre au comportement de peer et pour la stabilité du tunnel.
Par exemple, si le pair ne prend pas en charge DH group20, vous pouvez utiliser un groupe DH différent pour les deux paramètres Crypto sur le firewall .