IKEv2 NO_PROPOSAL_CHOSEN: ¿qué etapa rechazó el conjunto?
Encuentre el intercambio que falló y luego compare el conjunto completo ofrecido y el permitido. Cambiar una clave precompartida no repara una discrepancia criptográfica.
NO_PROPOSAL_CHOSEN en un registro envía a la gente a la clave precompartida, y el error sobrevive al cambio. Nunca fue un problema de credenciales: el par rechazó cada propuesta ofrecida para ese intercambio, lo que es una afirmación sobre algoritmos y no sobre identidad. La primera pregunta útil no es qué algoritmo editar, sino qué intercambio se rechazó. Responda eso antes de comparar nada. Luego compare el conjunto completo ofrecido con el conjunto completo que el par permite.
Primero: qué intercambio se rechazó
IKEv2 negocia dos tipos de asociación. La IKE SA protege la propia negociación y la CHILD SA protege el tráfico. Cada una tiene su propio conjunto de propuestas, y cada una puede fallar con la misma notificación. Un rechazo durante la negociación IKE inicial y un rechazo durante la negociación CHILD necesitan correcciones distintas, y el registro suele nombrar el intercambio una o dos líneas por encima del aviso. Lea esas dos líneas juntas, o editará la lista de propuestas equivocada.
La notificación por sí sola no identifica el intercambio. La línea superior nombra la SA que se está negociando, y ese nombre apunta a la lista de propuestas que hay que inspeccionar.
Compare conjuntos completos, no palabras clave sueltas
Una propuesta es una combinación: algoritmo de cifrado, integridad o AEAD, grupo de intercambio de claves y cualquier función pseudoaleatoria. Comparar solo el nombre del cifrado es el error habitual, porque dos pares pueden coincidir en AES-256 y seguir discrepando en SHA-1 frente a SHA-256. Escriba los conjuntos ofrecido y permitido uno al lado del otro en la etapa fallida y luego busque la intersección vacía.
offered: aes256-sha256-modp2048
permitted: aes256-sha1-modp2048
Compruebe también que ambas implementaciones admitan lo que ha configurado. Un nombre copiado de otra plataforma puede parecer sintácticamente familiar mientras que el complemento o la implementación falta por completo.
El conjunto IKE y el conjunto ESP son objetos distintos
Editar la propuesta IKE no reparará una propuesta CHILD rechazada, y lo contrario también es cierto. En strongSwan son ajustes separados, aproximadamente proposals = aes256-sha256-modp2048 para la IKE SA y una lista ESP aparte para la CHILD SA. Cambie la lista que corresponde al intercambio fallido y luego vuelva a leer el registro en lugar de suponer que la corrección funcionó.
Para la CHILD SA, el ajuste relevante es la lista de propuestas ESP, no la de IKE. Copiar la línea IKE en ella produce una configuración que se analiza y negocia el objeto equivocado.
Un túnel que funciona y falla al renovar la clave
Si el túnel funcionó durante una hora y luego falló, la negociación inicial no es el problema. Una renovación de clave puede ejercitar condiciones distintas: un grupo de intercambio de claves diferente tras el primer intercambio, una discrepancia de lifetime entre pares o una política de respondedor cambiada. Guarde la marca de tiempo de renovación y los identificadores de asociación de ambos lados. Ese patrón necesita una comparación de propuestas en la renovación, no un tiempo de espera más largo. Cambiar el tiempo de espera oculta el síntoma y deja la discrepancia en su sitio.
ipsec statusall muestra cada asociación y los algoritmos realmente negociados. Esa salida es la forma más rápida de confirmar qué lista se usó, y separa un error de configuración de un túnel obsoleto que nunca se renegoció.
ipsec statusall | grep -E "IKE:|ESP:"
Elija una intersección y luego confirme ambas fases
Haga que el administrador elija una intersección moderna documentada que ambos pares admitan, y anótela. No resuelva el error habilitando todos los algoritmos heredados ni desactivando la verificación de identidad, porque ninguna de las dos cosas se deduce de un rechazo. Tras el cambio, establezca una conexión nueva y luego fuerce una renovación de clave. La primera conexión por sí sola no demuestra que la ruta de renovación funcione.
Conserve la combinación aceptada junto con las versiones de firmware. Si el siguiente error trata de selectores de tráfico, trátelo por separado, ya que el acuerdo sobre criptografía no dice nada sobre qué subredes protege el túnel. La documentación de propuestas de strongSwan cubre la sintaxis de ambas listas.