Encontrarte con el mensaje “usuario o contraseña incorrectos” al intentar usar Escritorio Remoto a través de una VPN, pese a que funcione en la LAN, es frustrante. Esta guía práctica explica por qué sucede y cómo resolverlo paso a paso.

Panorama general del problema

Cuando un administrador intenta abrir una sesión RDP a un Windows Server 2012 R2 desde la red interna, las credenciales son aceptadas de inmediato. Sin embargo, al repetir la conexión sobre una VPN —utilizando el mismo usuario y la misma contraseña— el servidor responde que las credenciales no son válidas. A primera vista parece un simple error de autenticación, pero en realidad confluyen factores de red, seguridad y sincronización de servicios que provocan el síntoma.

Cómo diagnosticar de forma estructurada

Antes de aplicar cambios, reúne datos objetivos:

• ¿El RDP responde al puerto 3389? Compruébalo con telnet <IP_servidor> 3389 desde el equipo cliente conectado a la VPN.
• ¿La hora del cliente y del servidor coincide? Una desviación superior a cinco minutos afecta a Kerberos y a la Network Level Authentication (NLA).
• ¿Se genera el evento 4625 o 4771? Abre el Visor de eventos en el servidor (Registros de Windows → Seguridad) y filtra por los ID mencionados mientras reproduces el fallo.
• ¿Existen subredes superpuestas (overlapping)? Ejecuta route print y revisa que la VPN no cree rutas más específicas que desvíen el tráfico.

Comprobaciones de conectividad básicas

Una VPN de nivel 3 debe permitir el flujo completo del tráfico RDP (TCP 3389). Verifica los puntos siguientes:

1. Realiza ping y tracert hacia la dirección interna del servidor. Latencias superiores a 150 ms pueden causar expiraciones prematuras de credenciales.
2. Si la VPN opera mediante túnel split, confirma que la subred del servidor esté dentro de la política de enrutamiento.
3. En caso de VPN con NAT interno, revisa que el puerto 3389 no sea traducido a otro valor.

Formato correcto de las credenciales

Un fallo típico es que el cliente envíe las credenciales al dominio o equipo equivocado. Usa siempre la sintaxis apropiada:

• Para cuentas del dominio: DOMINIO\usuario o usuario@dominio.com
• Para cuentas locales del servidor: SERVIDOR\usuarioLocal

Evita el prefijo MicrosoftAccount\ salvo que auténticamente sea una cuenta Microsoft, algo inusual en un servidor.

Impacto de la Network Level Authentication (NLA)

NLA protege la sesión RDP exigiendo que la autenticación ocurra antes de establecer el canal gráfico. Si el certificado TLS del servidor está caducado, o si hay cipher suites deshabilitados, la negociación falla y el equipo cliente interpreta que las credenciales son incorrectas. Para descartar NLA:

1. En el servidor abre System Properties → Remote.
2. Desmarca “Permitir conexiones solo desde equipos que ejecutan Escritorio remoto con NLA”.
3. Repite la conexión a través de la VPN.

Si ahora funciona, el problema se concentra en:

• Certificados expirados o firmados con SHA‑1.
• Desfase horario entre cliente y servidor.
• Políticas que exigen TLS 1.2 pero el cliente usa TLS 1.0.

Sincronización de hora y Kerberos

Los tickets de Kerberos son válidos solo si el reloj del cliente y el del Controlador de dominio difieren menos de cinco minutos. En una VPN es frecuente que el PC se suspenda y pierda la sincronización NTP. Ejecuta:

w32tm /query /status
w32tm /resync

Si la respuesta muestra un error (Time Source unreachable), ajusta manualmente la hora y configura un servidor NTP accesible tanto por la LAN como por la VPN.

Firewall y políticas de IPSec

Un cortafuegos mal configurado puede permitir el handshake TLS inicial y, sin embargo, bloquear paquetes RDP específicos que portan las credenciales cifradas. Comprueba:

Elemento	Acción recomendada
Firewall de Windows	Añadir regla entrante TCP 3389 para el perfil ‘Privado’ o el perfil aplicado por la VPN.
Firewall de la VPN	Permitir application ms‑rdp o puerto 3389 sin inspección profunda.
IPSec	Deshabilitar, momentáneamente, reglas que requieran cifrado adicional sobre RDP.

Análisis detallado de eventos

Los eventos 4625 y 4771 muestran el código de estado que aclara la causa:

Código hex	Significado	Diagnóstico
0xC000006D	Credenciales incorrectas	Usuario, contraseña o dominio erróneos.
0xC0000064	Cuenta inexistente	Cuenta eliminada o en OU distinta no replicada aún.
0xC0000234	Cuenta bloqueada	Demasiados intentos fallidos; revisar política de bloqueo.
0xC0000071	Contraseña caducada	Obliga a cambio de contraseña desde la LAN primero.

Escenarios especiales y soluciones puntuales

Contraseñas sincronizadas en varios controladores de dominio

En entornos con varios sites de Active Directory, la replicación incompleta puede provocar que el controlador cercano a la VPN no conozca aún la contraseña reciente. Ejecuta repadmin /syncall /APeD para forzar la convergencia.

Uso de mstsc /admin

El parámetro /admin ignora restricciones de licenciamiento RDS y evita redirigir la sesión a un host RDS incorrecto. Es útil si el servidor solo permite un número limitado de sesiones estándar.

Actualización del cliente RDP

Los clientes anteriores a Windows 10 v1909 no negocian por defecto TLS 1.2 ni Elliptic Curve Diffie‑Hellman (ECDH). Instala la última versión del componente Remote Desktop Connection o aplica los parches KB previstos para Windows 7/8.

Procedimiento paso a paso

1. Valida conectividad con telnet y tracert.
2. Comprueba coincidencia de hora con w32tm /query /status.
3. Reinicia la sesión RDP sin NLA y observa si se conecta.
4. Revisa el Visor de eventos (4625/4771) y anota el código.
5. Corrige credenciales, desbloquea la cuenta o cambia la contraseña según el caso.
6. Restablece NLA, instala certificados válidos y limita los cipher suites a TLS 1.2.
7. Vuelve a probar con mstsc /admin.
8. Aplica políticas de firewall definitivas y habilita únicamente los puertos necesarios.

Checklist rápida para administradores ocupados

• ☑ ¿Puerto 3389 accesible en ambos sentidos?
• ☑ Hora del sistema sincronizada (<5 min de diferencia).
• ☑ Formato de usuario adecuado (DOMINIO\usuario).
• ☑ Cuenta no bloqueada ni caducada.
• ☑ Certificados TLS vigentes.
• ☑ NLA activo y probado.
• ☑ Firewall de la VPN no inspecciona RDP.
• ☑ AD replicado en todos los sites.

Preguntas frecuentes

¿Puedo desactivar NLA de forma permanente?

No se recomienda: NLA brinda una capa crucial de defensa. Úsala, pero con certificados actualizados y cifrados modernos.

¿Por qué el problema ocurre solo a algunas cuentas?

Porque esas cuentas pueden residir en un dominio distinto, estar sujetas a políticas de expiración o replicarse con más retraso.

¿Es mejor habilitar RDP sobre UDP?

El canal UDP (3389 UDP) mejora la experiencia multimedia, pero no resuelve problemas de autenticación. Asegúrate primero de que TCP funcione.

Conclusión

El aparente “error de contraseña” al usar RDP a través de una VPN rara vez implica realmente una contraseña mal escrita. Casi siempre obedece a parámetros de NLA, certificados vencidos, relojes desincronizados o rutas de red mal definidas. Sigue la ruta de diagnóstico sistemática descrita y en pocos minutos tendrás una conexión estable y segura.