La fase 2 ha caído con el intercambio de claves IKEv2 debido al DH desajuste del grupo
124217
Created On 02/13/20 03:00 AM - Last Modified 08/04/22 22:36 PM
Symptom
La Fase2 está abajo después de que Firewall /Peer intente negociar la clave.
Environment
El par no es un dispositivo Palo Alto que puede no ser compatible con el mismo cifrado definido en el Firewall .
- Es posible que deba comprobar el comportamiento con el mismo nivel, ya que algún proveedor no admite DH el grupo especificado en el archivo firewall .
- El par puede heredar el valor de la configuración de su par (para este caso la PFS configuración IKE criptográfica de Palo IKE Alto).
Ejemplo de los IKEMGR registros tomados de firewall cuando el problema está sucediendo
1) Iniciador
> 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) Respondedor :
> 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-AEjemplo de la captura de paquetes: Initator negociando la clave
Fotograma#88,
El iniciador ( PALO ALTO NETWORKS Firewall ) está negociando la clave, haciendo saber al par que DHGroup # 2048 MODP ( DH Grupo14)
Marco #89,
El respondedor ( ) envió INVALID_KEY_PAYLOAD y VENDOR A hacer saber al par que su aceptación sólo DH Grupo20/ecp384 (el par hereda el valor de PaloAlto FW 's IKE Crypto setting).
VENDOR A El
iniciador ( ) está PALOALTO FW negociando la clave, haciendo saber al par que soporta DHGroup # 2048 MODP ( DH Grupo14)
Marco #91, El
respondedor ( ) enviado NO_PROPOSAL_CHOSEN ya que VENDOR A no estaba de acuerdo con el grupo DH definido.
Cause
Consulte lo siguiente RFC como referencia: indica que, la carga útil de intercambio de claves se construye
RFC
A copiando el valor público diffie-hellman
en la parte "Datos clave de Intercambio" de la carga útil.
La longitud del valor público Diffie-Hellman MUST es igual a la longitud del módulo principal sobre el que se realizó la
exponenciación,
anteponiendo cero bits al valor si es necesario.
El DH grupo # identifica el grupo Diffie-Hellman en el que se calcularon los datos de Key Exchange (consulte la sección
3.3.2). Si la propuesta seleccionada
utiliza un grupo diferente de Diffie-Hellman, el mensaje se MUST
rechazará con una carga útil notificar de tipo INVALID_KE_PAYLOAD
NO_PROPOSAL_CHOSEN 14
Ninguno de los conjuntos de criptografías propuestos era aceptable.
INVALID_KE_PAYLOAD 17
El D-H campo Grupo # de la carga útil KE no es el grupo # seleccionado por el
respondedor para este intercambio. Hay dos
octetos de datos asociados con esta notificación: el
grupo aceptado # en orden D-H endian grande.
Consulte el siguiente artículo para habilitar la depuración de IKE
comandos http://live.paloaltonetworks.com:80/t5/Management-Articles/How-to-Troubleshoot-IPSec- VPN- connectivity-issues/ta-p/59187
que pueden ser útiles para ver la depuración y la realización de la captura de paquetes
> 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
Tome nota:
1) En el escenario normal, el par ( VENDOR A ) debe tener la configuración respectiva para hacer juego la configuración en el firewall
2) Bajo cierto requisito en el par, que puede no ser soportando el grupo específico DH (para este caso, el par no soporta DH el Grupo20), hereda el IPSEC PFS del par IKE PFS (las configuraciones crypto de PaloAlto) que causó el FW IKE problema.
1) IKE Perfil criptográfico configurado con DH el group20 (no soportado por el par)
2) IPSEC perfil crypto configurado con el DH grupo14 (soportado por el par)
Resolution
Asegúrese de que la IKE configuración crypto y crypto tenga el mismo grupo configurado en el lado para atender el comportamiento IPSEC del par y para la estabilidad del DH Firewall túnel.
Por ejemplo, si el par no admite DH group20, usted puede utilizar un grupo diferente DH para ambas configuraciones crypto en el firewall .