RDP no conecta: diagnóstico paso a paso

Cuando Escritorio remoto (RDP) no conecta, cambiar opciones al azar suele alargar la incidencia. El diagnóstico correcto avanza por capas, de fuera hacia dentro: primero la red y el nombre del equipo, después el puerto, el servicio, el firewall, los permisos y, por último, la autenticación y las licencias. En esta guía tienes un método paso a paso, con los mensajes de error más frecuentes, los comandos para comprobar cada capa y las medidas de seguridad que conviene respetar al abrir el acceso remoto.

Una advertencia previa: si administras un servidor solo por RDP, asegúrate de tener otra vía de acceso (consola del hipervisor, KVM, otra herramienta de administración) antes de tocar el firewall o los servicios, para no perder el acceso al equipo.

Paso 1: identifica el mensaje exacto

El texto del error te dice casi siempre en qué capa está el problema. Estos son los más habituales:

Mensaje	Causa probable	Dónde mirar
«Escritorio remoto no puede conectarse al equipo remoto»	Red, puerto 3389 cerrado, servicio parado o equipo apagado	Pasos 2 a 5
«Ha ocurrido un error interno»	Problema de sesión, certificado o servicio en el destino	Guía de error interno de Escritorio remoto
«El equipo remoto requiere autenticación a nivel de red (NLA)»	Tu cliente no puede cumplir NLA	Guía de autenticación a nivel de red (NLA)
«Para iniciar sesión de forma remota, necesita el derecho de inicio de sesión a través de Servicios de Escritorio remoto»	El usuario no está autorizado	Guía del derecho de inicio de sesión remoto
«Error de autenticación. La función solicitada no es compatible»	Diferencia de parches de CredSSP entre cliente y servidor	Paso 7
«No hay servidores de licencias de Escritorio remoto disponibles»	Licencias de acceso (CAL) de RDS	Paso 8
Advertencia de certificado	El certificado de RDP no coincide con el nombre	Paso 9

Paso 2: comprueba el alcance de red y el nombre

Empieza por lo básico: ¿llegas al equipo? Desde el cliente, comprueba que el nombre se resuelve y que la ruta funciona. Si el nombre resuelve a una dirección inesperada, el problema es de DNS y no de RDP; en nuestra guía de ping, IPv6 e IPv4 tienes un caso típico en el que el nombre resuelve a una dirección que no es la que esperas.

ping servidor01
nslookup servidor01
Test-NetConnection servidor01 -Port 3389

El último comando, de PowerShell, intenta abrir una conexión TCP al puerto de RDP. Si TcpTestSucceeded es False, el puerto no es alcanzable desde donde estás; si es True, el problema está más adentro (permisos, autenticación o sesión). Un fallo rápido suele significar que llegas al equipo pero no hay nada escuchando; un tiempo de espera largo suele significar que un firewall descarta los paquetes.

Paso 3: comprueba que RDP está habilitado

En el equipo de destino, abre Configuración, Sistema, Escritorio remoto y verifica que esté activado. En Windows Server, la opción está en el Administrador del servidor, en Servidor local. Desde PowerShell puedes leer el valor del registro que controla el acceso:

(Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server").fDenyTSConnections

El valor 0 indica que las conexiones remotas están permitidas; el 1, que están denegadas. Una directiva de grupo puede estar forzando este valor, así que si lo cambias a mano y vuelve al cabo de un rato, revisa las GPO.

Paso 4: servicio y puerto

El servicio de Servicios de Escritorio remoto (TermService) debe estar en ejecución y el equipo debe escuchar en el puerto 3389, salvo que lo hayas cambiado:

Get-Service TermService
Get-NetTCPConnection -State Listen -LocalPort 3389
netstat -ano | findstr :3389

Si el servicio está parado, arráncalo con Start-Service TermService y comprueba en el Visor de eventos por qué se detuvo. Si el equipo escucha en un puerto distinto, habrá que indicarlo en el cliente con servidor01:puerto. Conviene distinguir siempre «el servicio escucha» de «el puerto es alcanzable desde la red»: son dos comprobaciones distintas.

Paso 5: el firewall de Windows

La regla de entrada de Escritorio remoto debe estar habilitada para el perfil de red correcto (Dominio, Privado o Público). Compruébalo y actívala si hace falta:

Get-NetFirewallRule -DisplayGroup "Escritorio remoto" | Select-Object DisplayName, Enabled, Profile
Enable-NetFirewallRule -DisplayGroup "Escritorio remoto"

El nombre del grupo depende del idioma del sistema (en inglés, «Remote Desktop»). Si la regla está habilitada y sigues sin llegar, revisa los firewalls intermedios: el de la red, el de la nube (grupos de seguridad) o el del antivirus.

Paso 6: permisos del usuario

El usuario debe pertenecer al grupo local Usuarios de Escritorio remoto o ser administrador. Puedes ver y modificar la pertenencia con:

net localgroup "Usuarios de Escritorio remoto"
net localgroup "Usuarios de Escritorio remoto" DOMINIO\usuario /add

En un servidor de sesiones, además, una directiva puede restringir quién tiene el derecho «Permitir el inicio de sesión a través de Servicios de Escritorio remoto». Esa causa es la del mensaje que aparece en la tabla.

Paso 7: autenticación, NLA y CredSSP

La autenticación a nivel de red (NLA) exige que el usuario se autentique antes de crear la sesión, y es la configuración recomendada por seguridad. Si el cliente no puede cumplirla (equipo fuera del dominio, hora desajustada, sistema muy antiguo), aparece el error de NLA. No la desactives por defecto: es mejor corregir la causa. Si ves el mensaje «Error de autenticación: la función solicitada no es compatible», suele deberse a una diferencia de actualizaciones de CredSSP entre el cliente y el servidor; la solución es actualizar ambos con los parches de seguridad, no relajar la política de forma permanente.

Paso 8: sesiones y licencias

Windows 10 y 11: admiten una sola sesión remota simultánea; si alguien está conectado en local, tu conexión lo desconecta (o te pide confirmación).
Windows Server sin el rol de Servicios de Escritorio remoto: permite dos sesiones administrativas simultáneas.
Con el rol RDS: se necesitan licencias de acceso de cliente (CAL) y un servidor de licencias; sin ellas, tras el periodo de gracia aparece el error de licencias.

Si te encuentras con sesiones desconectadas que ocupan recursos, puedes verlas con quser y cerrarlas con logoff ID. Para entornos con muchos usuarios, merece la pena plantearse una solución de escritorios virtuales: tienes una introducción en la guía de qué es VDI.

Paso 9: certificado y TLS

RDP usa un certificado para cifrar la conexión. Por defecto, es autofirmado y el cliente muestra una advertencia. Si el cliente rechaza la conexión por certificado, comprueba que el nombre que usas coincide con el del certificado, que la fecha de validez es correcta y que las versiones de TLS compatibles coinciden con las del cliente. En entornos corporativos, lo habitual es usar un certificado emitido por la entidad certificadora interna y asignarlo mediante directiva de grupo. Un caso parecido, con otro cliente, es el de los errores de certificado en la guía de Horizon Client.

Paso 10: eventos y registros

Si has descartado las capas anteriores, consulta los registros. En el Visor de eventos, revisa:

Aplicaciones y servicios, Microsoft, Windows, TerminalServices-RemoteConnectionManager, Operational: intentos de conexión y rechazos.
TerminalServices-LocalSessionManager: inicios y cierres de sesión.
Seguridad: eventos 4625 (inicio de sesión fallido) y 4624 (correcto), que indican el motivo del rechazo y el tipo de inicio de sesión (el tipo 10 corresponde a RemoteInteractive).

Seguridad: no expongas el puerto 3389 a internet

Abrir RDP directamente a internet es una de las causas más habituales de intrusiones: los atacantes lo escanean de forma constante e intentan contraseñas. Conviene:

Acceder por VPN o por una puerta de enlace de Escritorio remoto (RD Gateway), en lugar de publicar el puerto.
Mantener NLA activo y exigir contraseñas robustas y autenticación multifactor.
Limitar los usuarios y las IP de origen con reglas de firewall.
Aplicar las actualizaciones de Windows y de los clientes.
Configurar el bloqueo de cuentas y vigilar los eventos 4625 en busca de intentos masivos.

Lista de comprobación rápida

¿Qué mensaje exacto aparece?
¿Resuelve el nombre y llega el puerto 3389?
¿Está RDP habilitado y el servicio en marcha?
¿Permite el firewall la entrada, en el perfil correcto?
¿Pertenece el usuario al grupo y tiene el derecho de inicio de sesión?
¿Coinciden NLA y CredSSP entre cliente y servidor?
¿Hay límite de sesiones o licencias?
¿Qué dicen los eventos?

Preguntas frecuentes

¿Cómo sé si el puerto 3389 está abierto?

Desde el cliente, con Test-NetConnection servidor -Port 3389; en el servidor, con Get-NetTCPConnection -State Listen -LocalPort 3389.

¿Puedo cambiar el puerto de RDP?

Sí, pero no es una medida de seguridad por sí sola. Si lo cambias, abre el nuevo puerto en el firewall e indícalo en el cliente.

¿Por qué funciona por IP y no por nombre?

Probablemente falle la resolución DNS o el nombre apunte a otra dirección. Revisa DNS y el archivo hosts.

¿Es seguro desactivar NLA?

No es recomendable. Desactivarlo reduce la protección; corrige la causa del error en lugar de renunciar a NLA.

Resumen

Diagnostica por capas: red, nombre, puerto, servicio, firewall, permisos, autenticación y licencias.
Lee el mensaje de error: indica en qué capa está el fallo.
Test-NetConnection -Port 3389 separa los problemas de red de los de sesión.
No expongas RDP a internet: usa VPN o RD Gateway, NLA y autenticación multifactor.
Consulta los eventos del Visor cuando el resto de comprobaciones no aclare nada.