Estás en Ajustes añadiendo una configuración IKEv2, y dos campos piden un texto que nadie te ha dado: Remote ID y Local ID. Ninguno es tu nombre de usuario, y ninguno es una segunda copia del campo Servidor. Remote ID es la identidad que la puerta de enlace debe demostrar a tu iPhone; Local ID es la identidad que tu iPhone reclama a la puerta de enlace. Si fallas en cualquiera, el túnel muere después de que el servidor ya haya respondido, y por eso el fallo parece un problema de contraseña sin serlo.

Dónde están los campos en iOS

Abre Ajustes > General > VPN y gestión de dispositivos > VPN y añade una configuración IKEv2. En Autenticación eliges Nombre de usuario o Certificado, y solo entonces aparecen Remote ID y Local ID como casillas de texto libre. Son identificadores, no direcciones: iOS los lleva en el intercambio IKE_AUTH, donde IKEv2 llama IDi a la identidad del iniciador e IDr a la del respondedor.

Después de guardar, iOS pliega la configuración en una sola fila y deja de mostrar los valores. Toca el botón de información o vuelve a abrir el perfil antes de concluir que los campos están vacíos. Una configuración enviada por MDM puede dejarlos completamente en gris, lo que cambia quién puede arreglar el problema.

Remote ID es el nombre de la puerta de enlace

Este es el valor que tu iPhone espera que el servidor demuestre. Con autenticación por certificado se compara con el nombre del certificado del servidor, normalmente el subject o una entrada subjectAltName. Si el certificado se emitió para vpn.example.com, ese nombre de host es el Remote ID, incluso cuando llegas al equipo por una dirección IP desnuda.

Ese desajuste es el fallo clásico: llegan paquetes, el servidor responde y la conexión se cae igualmente porque la identidad del certificado no coincide con lo que exigía el perfil. Apuntar el campo Servidor a la IP cruda no ayuda, y en muchas puertas de enlace el servidor simplemente deja de responder a una identidad que no puede emparejar.

La puerta de enlace tiene un ajuste equivalente. Un servidor strongSwan envía su propia identidad con leftid y puede restringir la identidad del cliente con rightid; si las dos partes no coinciden en la cadena, IKE_AUTH falla en ambos sentidos. Pregunta al operador para qué identidad se emitió el certificado en lugar de copiar la URL de la barra del navegador.

Apple documenta las claves de la carga como RemoteIdentifier y LocalIdentifier en su referencia de ajustes de IKEv2. Ambas son cadenas simples, así que las mayúsculas y un espacio final pueden importar.

Local ID es lo que reclama tu iPhone

Con autenticación por nombre de usuario, EAP comprueba el nombre y la contraseña, y Local ID es una identidad IKE aparte que algunas puertas de enlace también exigen. Una puerta puede requerir que Local ID sea igual al nombre de usuario, sea una dirección de correo o coincida con una entrada de su política de conexiones; otras lo ignoran. Dejarlo vacío solo es seguro cuando el operador lo dice.

Con autenticación por certificado, Local ID debe coincidir con una identidad que la puerta de enlace acepte para ese certificado de cliente, a menudo el nombre común del certificado o un valor asociado a un registro de dispositivo. Copiar el perfil de un compañero copia también su identidad. En el mejor caso la puerta registra el dispositivo equivocado; en el peor, una política por dispositivo te rechaza.

La trampa es suponer que vacío significa ninguna identidad. No rellenes un campo vacío con tu dirección de correo solo porque parezca inacabado. Confirma el valor previsto e introdúcelo exactamente como te lo dieron.

Una comprobación de cinco minutos antes de guardar

Recórrelos en orden; el primer paso que falle es el que hay que arreglar.

  1. Consigue tres cadenas del operador: el nombre del certificado del servidor, el Local ID esperado y el método de autenticación.
  2. Ajusta el método de autenticación. Remote ID y Local ID no sustituyen a un nombre de usuario y una contraseña, y un perfil de certificado no aceptará una contraseña.
  3. Escribe los valores exactamente, con mayúsculas y minúsculas, sin espacio final.
  4. Mantén activada la validación de certificados. Instalar un certificado raíz ajeno para silenciar un aviso oculta un desajuste de nombre en lugar de arreglarlo.
  5. Prueba con datos móviles, no con el Wi-Fi de la oficina, para que un portal cautivo o un DNS dividido no se hagan pasar por un problema de identidad.
FieldWhat belongs thereWhat a wrong value looks like
Remote IDThe DNS name in the gateway certificateServer answers, then the tunnel drops with a certificate or identity error
Local IDThe identity the gateway policy expects for youIKE_AUTH or user authentication fails after the server responds
ServerA reachable hostname or IPTimeout with no identity exchange at all

Lee la tabla de arriba abajo. Un tiempo de espera en la fila Servidor significa que los campos de identidad nunca se probaron, así que detente ahí. Un error que solo aparece después de que el servidor haya respondido es casi siempre un desajuste de Remote ID o Local ID.

Errores que señalan el campo equivocado

Un mensaje como "User authentication failed" trata de credenciales o EAP, no de Remote ID. Un aviso de certificado trata del nombre del certificado, y ahí es donde se encuentran Remote ID y el campo Servidor. "The VPN server did not respond" suele significar que UDP 500 y 4500 nunca se completaron, o que falló el traversal de NAT, y que no se comparó ninguna identidad.

Del lado de la puerta de enlace, los fallos de identidad se ven distintos: el peer se rechaza durante IKE_AUTH, o el registro nombra el ID que envió el cliente y dice que no coincide con ninguna conexión. Esa línea del registro es la forma más rápida de zanjar la discusión, porque muestra la cadena exacta que envió el teléfono.

Restablecer una contraseña no reparará una identidad de servidor esperada, y cambiar Remote ID no reparará una contraseña incorrecta. Separa primero la etapa y luego edita el campo que pertenece a esa etapa.

Cuando el perfil está gestionado

Si los campos están en gris, la configuración vino de MDM y el teléfono no es el lugar para arreglarlo. La carga de VPN lleva los identificadores, así que el cambio correcto está en el perfil del servidor de gestión, seguido de reinstalarlo en el dispositivo.

Comprueba en Ajustes > General > VPN y gestión de dispositivos si el perfil está gestionado y quién lo firmó. Si no puedes eliminarlo, no puedes editar los identificadores localmente, y crear un segundo perfil local solo genera una configuración en conflicto.

Antes de cerrar Ajustes, apunta las tres cadenas que introdujiste y de dónde salieron. La próxima vez que falle el túnel, compara el ID recibido en el registro de la puerta de enlace con esa nota: si difiere, estás mirando el campo, no la contraseña.

Artículos relacionados