FortiGate Azure rekey: la propuesta de SA del peer no coincide con la política local
Un túnel IKEv2 que funciona puede rechazar igualmente la CHILD SA de reemplazo. Compare la propuesta que negocia de verdad la renovación, no la que usó el primer ping.
El túnel subió, el tráfico fluyó y más tarde el registro dice peer SA proposal not match local policy. La mayoría de la gente lee esa línea como prueba de que las dos configuraciones nunca coincidieron. Normalmente significa algo más concreto: coincidieron para la primera CHILD SA y dejaron de coincidir en la primera renovación, porque la primera asociación nunca necesitó el intercambio que hacen las posteriores. Esa distinción decide dónde mirar.
La primera CHILD SA hereda, las posteriores negocian
En IKEv2, la CHILD SA inicial se crea durante IKE_AUTH y sus claves se derivan del material de claves de la IKE SA. En ese momento no hay un intercambio Diffie-Hellman aparte, así que un grupo PFS que uno de los peers no puede aceptar simplemente aún no se prueba. El túnel parece sano porque el requisito que más adelante incumplirá nunca se probó.
Una renovación de claves de CHILD_SA es una secuencia de mensajes distinta. Cuando PFS está configurado, los peers ejecutan un intercambio de claves nuevo y deben acordar un grupo que ambos lados acepten, además de la propuesta ESP para la nueva asociación. Ese es el momento en que la discrepancia se hace visible, y por eso el error nombra una propuesta y no una ruta.
Así que “ayer funcionaba” no le dice nada sobre la propuesta. Le dice que el intercambio inicial tuvo éxito, algo que ya sabía.
Lea el intercambio fallido, no el primer ping
Reúna la autenticación IKE correcta, la CHILD SA inicial y el reemplazo fallido de ambos extremos antes de cambiar nada. Después nombre la operación con precisión: la renovación de claves de la IKE SA, la reautenticación IKE y la renovación de claves de la CHILD SA son tres eventos distintos, y “fase 2” los cubre todos en una conversación informal.
Compare los campos siguientes para la conexión que falló, no para el túnel en general.
| Capa | Valores que comparar |
|---|---|
| IKE | Versión, cifrado e integridad o disposición de PRF, grupo DH |
| IPsec / CHILD | Cifrado e integridad de ESP, grupo PFS o de intercambio de claves previsto |
| Tráfico protegido | Selectores locales y remotos, más cualquier ajuste de selector basado en políticas |
En FortiGate, abra la propuesta de fase-2, el ajuste de PFS y los grupos DH aceptados para ese túnel. Lea los valores cargados en lugar de inferirlos de una conexión que se estableció antes. Una captura de la página de la GUI es una prueba más débil que la configuración en ejecución, porque ambas pueden discrepar tras una actualización. Exporte la sección que cambió y guárdela con el ticket.
La política predeterminada de Azure sigue siendo una política
Que no haya una política personalizada adjunta a la conexión no significa que Azure no aplique ninguna. La conexión recurre al conjunto de propuestas predeterminado de la puerta de enlace, que puede ser más amplio o más estrecho que lo que ofrece su FortiGate. Si los dos conjuntos se solapan para IKE pero no para ESP con PFS, obtiene exactamente este patrón de fallo.
Esta vista de solo lectura muestra la política realmente adjunta, sin volcar secretos:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesUse los nombres reales de sus recursos. Cuando se necesita una política explícita, defínala en el recurso de la conexión. No es un interruptor de toda la puerta de enlace y no se aplica en silencio a otros túneles de la misma puerta de enlace.
En el portal, la página Configuration de esa conexión es donde va una política IPsec/IKE personalizada. La guía de Microsoft sobre políticas personalizadas enumera los parámetros admitidos y los requisitos de SKU. Azure toma una combinación completa por conexión, así que especifica los campos de IKE y los de IPsec juntos, no uno a la vez.
PFS es un requisito, no un interruptor que girar
Si su línea base de seguridad exige PFS, la solución es un grupo que ambos peers acepten en los dos lados, expresado mediante una política coincidente. Desactivar PFS para que el error desaparezca cambia la propiedad de seguridad que intentaba conservar, y normalmente reaparece más tarde como otra discrepancia.
Una trampa específica de Azure: cuando elige GCM para ESP, las selecciones de cifrado e integridad deben nombrar el mismo algoritmo GCM y la misma longitud de clave. Mezclar un cifrador GCM con un algoritmo de integridad separado produce una combinación que el servicio rechaza, y parece una discrepancia entre peers hasta que lee la política con atención.
Elija la combinación más fuerte que ambos extremos admitan y que su requisito permita, y luego anótela en el registro de cambios. La siguiente persona comparará con ese registro, no con el recuerdo de un túnel que funcionaba. Incluya el grupo PFS y la propuesta ESP, no solo el nombre de la política. Cuando alguien pregunte más tarde por qué falló una auditoría o por qué una renovación es lenta, esa línea responde a ambas preguntas.
Verifique el intercambio que falló
Planifique el cambio con una vía de recuperación, porque editar la política puede interrumpir el túnel que intenta arreglar. Cuando vuelva el tráfico, espere o provoque una renovación de CHILD_SA y confirme que la nueva asociación se establece con el grupo PFS previsto. Después confirme que el tráfico de aplicaciones sigue pasando por ella.
Merece la pena nombrar dos pistas falsas. Las duraciones de las SA son especificaciones locales, así que los valores desiguales son normales y cambiarlos solo mueve cuándo aparece el problema. DPD detecta si un peer está vivo; subir su tiempo de espera no alinea las elecciones de ESP ni de PFS.
Registre el resultado negociado y el siguiente evento después del cambio. Si ahora la conexión falla antes de que se complete la autenticación IKE, está mirando los ajustes de IKE que acaba de editar, no el fallo original de renovación de la CHILD.