IKEv2 en iPhone: qué poner en los campos «Servidor», «ID remoto» y «ID local»

Respuesta breve: en «Servidor» normalmente se introduce el nombre de dominio o la IP de tu servidor VPN; en «ID remoto» va el identificador que debe coincidir con lo que espera el servidor (a menudo es el nombre de dominio indicado en el certificado del servidor); en «ID local» se pone el identificador del cliente, que el servidor usa para aplicar reglas (a menudo se deja vacío o se introduce el nombre de usuario o ID proporcionado por el proveedor). Siempre consulta los valores exactos con tu proveedor o administrador: adivinar es una causa frecuente de errores en la verificación del certificado o fallos de conexión.

Qué significan los campos de IKEv2 en iOS y para qué sirven

En IKEv2 (IPsec) las partes intercambian parámetros y se autentican mutuamente. En iPhone ves tres campos que suelen generar dudas:

• Servidor — la dirección a la que te conectas (dirección del gateway VPN).
• ID remoto (Remote ID) — «cómo verifico el servidor»; es la cadena con la que iOS relaciona el servidor con su certificado (normalmente los datos están en el certificado del servidor).
• ID local (Local ID) — «cómo me reconoce el servidor»; el identificador del cliente que el servidor verifica o usa para aplicar políticas.

Estos valores participan en la autenticación. Si no coinciden con la configuración del servidor y su certificado, iOS puede no confiar en el servidor o éste rechazará al cliente. Para verificar la lógica de los identificadores y la autenticación, consulta la documentación oficial de Apple sobre IKEv2/IPsec: Apple: IKEv2 device management settings.

Campo «Servidor»: dominio o IP y cómo saber qué poner

Lo que se suele poner

• Nombre de dominio completo (FQDN) tipo vpn.example.com — opción común, práctica para cambios de IP y para que los certificados funcionen correctamente.
• Dirección IP — se usa a veces para pruebas rápidas o cuando no hay dominio. Pero en la verificación del certificado siempre importa el «ID remoto».

Diagnóstico antes de proceder

• Consulta con tu proveedor si la conexión debe hacerse por nombre de dominio o por IP. Si el proveedor da un dominio y certificado, es mejor usar el dominio.
• Si usas IP, comprueba que no cambie (por ejemplo, en conexiones domésticas o IP dinámica). Cambios frecuentes de IP pueden causar conexiones inestables.

Acciones seguras (reversibles)

• Si no estás seguro, comienza con el valor indicado en la guía del proveedor. En caso de error, no desactives la comprobación del certificado ni uses opciones «no verificadas»; mejor confirma la dirección correcta.
• Si el proveedor te dio dominio e IP: prueba el dominio en «Servidor» y usa la IP solo para diagnóstico temporal (y luego vuelve al dominio).

«ID remoto»: clave para verificar el certificado y ejemplos comunes

El «ID remoto» es una de las causas más frecuentes de problemas, porque iOS lo compara con el identificador que el servidor muestra durante la autenticación. En escenarios con certificado, suele coincidir con el nombre del certificado del servidor.

Valores comunes de «ID remoto»

• Dominio VPN (ejemplo: vpn.example.com) — el tipo más habitual y fácil de entender.
• Cadena identificadora (como ikev2.example.com o gateway-id) — aparece cuando el proveedor quiere separar «dirección de conexión» de «nombre dentro del certificado».
• IP — aceptada en ocasiones, pero puede causar problemas si el certificado está emitido para un dominio y no para IP.

Cómo diagnosticar qué se espera

• Revisa lo que el proveedor indica en los parámetros IKEv2: a veces el «Remote ID» se menciona aparte del «Servidor».
• Si tienes un perfil de configuración (.mobileconfig) o una configuración en texto del proveedor, normalmente ahí aparece explícito el «Remote ID». Al introducir datos manualmente, procura usar esos mismos valores.
• Si la conexión falla con error de confianza o certificado, una causa probable es que el «ID remoto» no coincida con el nombre del certificado.

Acciones seguras (reversibles)

• Si usaste IP en «ID remoto», prueba a cambiar por el dominio que dio el proveedor (y si hace falta, vuelve a la IP luego).
• Si tu «Servidor» es una IP y el proveedor dio un dominio para identificar, deja la IP en «Servidor» pero pon el dominio (exacto) en «ID remoto» para que el certificado valga con el nombre esperado.
• Si el proveedor dio un «Remote ID» específico (una cadena distinta del dominio), úsalo así, aunque parezca extraño.

«ID local»: cuándo dejarlo vacío y cuándo especificarlo

El «ID local» define con qué identificador te presentas como cliente. En algunas configuraciones no es necesario, en otras es fundamental (por ejemplo, si el servidor distingue usuarios o perfiles no solo por usuario sino también por ID).

Opciones comunes para «ID local»

• Vacío — opción habitual cuando el servidor basta con usuario/contraseña (EAP) o certificado de cliente.
• Nombre de usuario — a veces se pide que el «ID local» sea el mismo login que usas para EAP.
• Identificador separado (cadena) — si el proveedor entrega un «ID local» específico, ej. client123 o user@realm.

Diagnóstico antes de cambios

• Si el servidor rechaza la conexión (pero no es error de confianza) y el proveedor mencionó un «ID local», verifica que no hayas dejado el campo vacío.
• Si tienes varios perfiles o usuarios y uno funciona pero otro no, compara si el campo «ID local» está completado en ambos casos.

Acciones seguras (reversibles)

• Si el proveedor no dio un «ID local», empieza con el campo vacío. Es más fácil revertir y evita inconsistencias.
• Si te dieron un «ID local» concreto, introdúcelo exactamente (mayúsculas, minúsculas y símbolos importan). Si no funciona, vuelve al estado original y consulta el formato con el proveedor.

Tipo de autenticación en IKEv2 en iPhone y por qué está relacionado con los ID

En iOS para IKEv2 suelen usarse dos métodos de autenticación:

• Por usuario y contraseña (EAP) — introduces credenciales y el servidor autentica tu identidad. El servidor casi siempre usa un certificado para que el cliente (iPhone) verifique que conecta con el servidor legítimo. En este modo es clave completar correctamente el «ID remoto».
• Por certificado — el cliente también tiene certificado (usualmente entregado por el administrador o proveedor). Entonces el «ID local» puede ser importante para elegir certificado o política, aunque depende de la configuración del servidor.

Diagnóstico: cómo saber qué modo tienes

• Si el proveedor solo dio login y contraseña, probablemente use EAP.
• Ni el archivo .mobileconfig ni el certificado determinan por sí solos el método; el perfil puede incluir configuración EAP y el certificado solo se usa para confiar en el servidor. Confirma con el proveedor el método que debes usar.

Acciones seguras (reversibles)

• No intentes cambiar el tipo de autenticación al azar si el proveedor te entregó parámetros para un modo específico: suele terminar con rechazo del servidor.
• Si crees que el modo es incorrecto (por ejemplo, te dieron certificado pero intentas conectar con usuario/contraseña), pregunta al proveedor qué método se espera y vuelve a la configuración recomendada.

Verificación de coincidencia entre el nombre del certificado y el «ID remoto»: checklist

Regla práctica: cuando iPhone verifica el servidor con certificado, el «ID remoto» debe coincidir con el nombre que el servidor muestra en el certificado (normalmente un dominio). Si no coinciden, la conexión puede fallar.

Checklist para diagnóstico (sin revelar datos sensibles)

Si necesitas una guía paso a paso para añadir un perfil IKEv2 en iOS (dónde pulsar), usa esta instrucción aparte: configurar IKEv2 VPN en iOS. Aquí solo explicamos el sentido de los campos y cómo verificar coincidencias.

Mini guía para trabajar seguro con los parámetros

• No publiques los valores de «Servidor», «ID remoto/local», usuarios, contraseñas, claves ni contenido de certificados en chats o capturas. Si tienes que mostrar un problema, oculta datos sensibles.
• Cambia un parámetro a la vez para entender qué afecta y para poder revertir fácilmente.
• No desactives la verificación de certificados ni aceptes «cualquier certificado» para conectar rápido: así comprometes la seguridad frente a suplantación de servidor.

FAQ: preguntas frecuentes sobre «Servidor», «ID remoto» y «ID local»

¿Se puede usar un «Servidor» y un «ID remoto» diferentes?

Sí, es un escenario normal: «Servidor» indica dónde te conectas y «ID remoto» cómo autenticas el servidor. Por ejemplo, puedes conectarte por IP y verificarlo por un dominio del certificado, si así lo da el proveedor.

Si solo tengo IP, ¿qué pongo en «ID remoto»?

Depende de para qué esté emitido el certificado y cómo esté configurado el VPN. Normalmente el proveedor da un dominio o identificador aparte para el «ID remoto». Si no tienes esos datos, mejor solicítalos al proveedor antes que probar opciones al azar.

¿Es obligatorio rellenar «ID local» si me conecto con usuario y contraseña?

A menudo no, y se deja en blanco. Pero algunas configuraciones piden un «ID local» explícito (para asignar políticas). Si el proveedor te lo dio, úsalo; si no, empieza vacío.

¿Por qué dejó de conectar el VPN después de cambiar el dominio?

Posibles causas: cambió la dirección en «Servidor» (por DNS o enrutamiento) o el nombre en el certificado ya no coincide con el «ID remoto». Lo más seguro es revertir a los valores anteriores, luego confirmar con el proveedor el nuevo dominio o «Remote ID» y asegurarte de que el certificado está actualizado para ese nombre.

¿Puedo usar el mismo «ID remoto» para varios servidores?

Sí, si el administrador configuró varios gateways con la misma identidad de servidor verificada y certificados adecuados para ese Remote ID. En otras configuraciones los identificadores varían. Usa el valor para el servidor que indica tu proveedor.

Cuándo puede ser útil un servidor personal: si necesitas un gateway VPN estable con IP dedicada sin usuarios compartidos y parámetros IKEv2 claros (incluidos los valores correctos de «Servidor/ID»), es más cómodo cuando el proveedor da datos personales y gestionas un solo perfil específico.

Cuándo no resolverá el problema: si la dificultad viene por valores erróneos que no te dieron (como ID remoto o certificado) o por limitaciones de red o dispositivo, un servidor personal no reemplaza una configuración correcta ni la verificación del certificado — tienes que usar los datos que te dio el proveedor y no relajar las comprobaciones.

Si tu escenario es «un usuario — un servidor», vpn.how ofrece servidores VPN personales con IP dedicada; consulta en la web y en tu cuenta las ubicaciones actuales, protocolos, precios y condiciones.