iOS IKEv2 hacia strongSwan: no se eligió ninguna propuesta, corrija la lista

El iPhone levanta el túnel, la puerta de enlace responde con nada y el teléfono muestra un fallo genérico. El registro de strongSwan es más concreto: no se eligió ninguna propuesta. Ese mensaje significa que las dos listas de conjuntos de cifrado aceptables nunca se solaparon, así que el intercambio terminó antes de que empezara la autenticación. Es un problema de coincidencia, y la solución es hacer que las listas se crucen.

Dónde declara la puerta de enlace su política

strongSwan escribe su política en la configuración, y el signo de exclamación final decide cómo se lee esa política. Con el signo, la lista es exhaustiva: se aceptarán esas entradas y nada más. Sin él, la misma línea es un orden de preferencia, y el demonio puede elegir algo que no pretendía. Pregunte qué forma está desplegada antes de traducir nada, porque las dos se comportan distinto frente al mismo cliente. Anote la línea exacta, signo incluido, y pruebe contra ella.

Un cliente que ofrece una lista más amplia todavía puede conectarse a una puerta de enlace fijada, siempre que una combinación aparezca en ambos lados. Lo que no puede ocurrir es una negociación fuera del conjunto fijado.

Por eso un perfil copiado de otra aplicación VPN puede funcionar donde el suyo no: la otra aplicación traía una lista distinta.

Los nombres deben coincidir, no mejorar

Dos traducciones atrapan a quien traslada valores de strongSwan a iOS. El algoritmo de integridad escrito como SHA1 en una propuesta IKE viaja en su forma truncada, que iOS llama .SHA96. El grupo Diffie-Hellman escrito como modp1024 es group 2, que iOS llama .group2. Sustituir por SHA-256 o group 14 no negociará contra una puerta de enlace que solo acepta el par antiguo. El cliente debe describir el mismo algoritmo, no uno más fuerte.

Defina esos valores explícitamente en NEVPNProtocolIKEv2. Los valores predeterminados pueden ser más amplios o más estrechos que el perfil que sustituye, y la diferencia solo se ve cuando falla el saludo.

La propuesta hija falla más tarde y más silenciosamente

Configure la asociación de seguridad hija además de la de IKE. Cuando solo coinciden los parámetros IKE, el túnel se autentica y luego no transporta tráfico, lo que es un fallo mucho más silencioso que un rechazo. Defina el cifrado, la integridad, el grupo y la vida útil de la hija en la misma pasada. Mantenga la vida útil del cliente en el valor de la puerta de enlace o por debajo, porque insistir en una más larga produce el mismo mensaje de propuesta no elegida por otra causa. Una discrepancia ahí se ve idéntica a una discrepancia de IKE en el registro.

Compruebe si el perfil se autentica con certificados o con un secreto compartido mientras está en la configuración. Un rechazo de propuesta y un rechazo de autenticación aparecen en líneas distintas, y arreglar el equivocado cuesta un día. Pruebe con una conexión nueva después de cada cambio, una variable a la vez, porque el estado en caché oculta qué parámetro se movió.

Deje el conjunto heredado solo mientras haga falta

Fijar SHA-1 con un grupo de 1024 bits es un puente, no un destino. Ambos están obsoletos, y los clientes más nuevos pueden rechazarlos de plano, lo que significa que el perfil fallará en el siguiente dispositivo sin ningún cambio de su lado. Trate la fijación como temporal y dígalo en el registro.

Si strongSwan es suyo, añada una propuesta moderna y deje que ambos extremos negocien hacia arriba mientras la entrada antigua se queda para dispositivos antiguos. Lea la salida de estado del demonio para ver qué conjunto usó realmente cada conexión. Después retire la fijación del lado del cliente cuando el par moderno esté confirmado. Un túnel que se levanta no es prueba suficiente, porque puede levantarse con el conjunto que intentaba retirar. La documentación de IKEv2 de strongSwan describe la sintaxis de las propuestas y el marcador estricto.