¿Puedes conectar por RDP al PC C usando el puerto 3389, pero al cambiar el PC B a 3390 la conexión falla? Aquí tienes una guía práctica y muy detallada para detectar en qué punto se rompe la cadena y dejar funcionando el acceso a tu segundo equipo.

Resumen del caso

Desde el equipo A se accede por Escritorio Remoto al equipo C con el puerto predeterminado 3389, redirigido en el router. Para llegar también al equipo B se cambió el puerto de RDP de B a 3390, se abrió en el firewall y se creó la regla de NAT en el router… pero la conexión no se establece.

Qué suele estar mal

Cuando RDP a un puerto distinto no funciona, normalmente el fallo está en uno o varios de estos puntos:

• Puerto configurado en Windows: no es realmente 3390, o quedó mal guardado en el Registro.
• Servicio de RDP sin reiniciar tras el cambio de puerto.
• Firewall de Windows: la regla por defecto solo cubre 3389; falta una regla explícita para el nuevo puerto.
• Cómo se marca el destino en el cliente: hay que usar IP:puerto (y tener cuidado con IPv6 y nombres).
• Redirección en el router (NAT): regla mal apuntada, IP LAN equivocada, protocolo incorrecto o puerto cruzado.
• Limitaciones de la red: NAT loopback inexistente, doble NAT/CGNAT del ISP, u otro firewall intermedio.

Ruta de diagnóstico recomendada

Recorre los pasos en este orden (ejecútalos en el equipo B salvo que se indique lo contrario). La idea es validar, de dentro hacia fuera, cada eslabón: servicio local → firewall local → llegada desde A → NAT del router → forma de conexión.

Verifica el puerto configurado

Comprueba el valor exacto del puerto en el Registro:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

• En el Editor del Registro, el valor PortNumber es DWORD. Si lo editas a mano, marca la casilla Decimal y escribe 3390.
• Ojo con el clásico error: si pones “3390” en Hexadecimal, en realidad estarás configurando 13200 en decimal, y Windows escuchará en 13200 (no en 3390).

Opcional: en versiones modernas, RDP puede usar también un canal UDP emparejado. Si quieres comprobarlo:

# Presencia del canal UDP (si existe la clave)
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-UDP' -Name PortNumber -ErrorAction SilentlyContinue

No es obligatorio abrir UDP para que RDP funcione; si UDP no está disponible, la sesión usará solo TCP.

Reinicia el servicio de Escritorio Remoto

El cambio de puerto no toma efecto hasta reiniciar el servicio (o el equipo):

Restart-Service TermService -Force

Comprueba que el equipo está realmente escuchando

Valida que hay un proceso a la escucha en 3390:

netstat -ano | findstr :3390
O bien:
Get-NetTCPConnection -LocalPort 3390

Si no hay nada escuchando en 3390, vuelve al paso anterior y revisa el puerto del Registro.

Crea una regla explícita en el Firewall de Windows

Las reglas “Remote Desktop – User Mode (TCP-In)” suelen cubrir solo 3389. Añade tu puerto:

New-NetFirewallRule -DisplayName "RDP 3390" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow

Opcional: si deseas habilitar también el canal UDP equivalente:

New-NetFirewallRule -DisplayName "RDP 3390 UDP" -Direction Inbound -Protocol UDP -LocalPort 3390 -Action Allow

Confirma la existencia de las reglas:

Get-NetFirewallRule | Where-Object DisplayName -match 'RDP 3390' | Get-NetFirewallPortFilter

Prueba de puerto desde el equipo A

La prueba de conectividad te dice si el problema está en red/NAT o en Windows:

Test-NetConnection <IPpublicaoprivadade_B> -Port 3390 -InformationLevel Detailed

• Éxito en TCP: la ruta de red está bien; si RDP no entra, el problema es credenciales/NLA o cómo marcas el destino.
• Fallo en TCP: piensa en NAT, IP equivocada, puerto mal mapeado, firewall perimetral o bloqueo del ISP.

Valida la redirección en el router

Si B escucha en 3390, la redirección debe ser:

WAN 3390/TCP  →  LAN <IPdeB>:3390

Buenas prácticas:

• Usa IP fija en B o una reserva DHCP, para que la regla de NAT no apunte a otro equipo.
• Si prefieres no tocar Windows, deja B en 3389 y mapea WAN 3390 → LAN 3389. Es perfectamente válido.
• Revisa que el protocolo sea TCP. Si también vas a usar UDP, crea la regla en UDP para el mismo puerto.

Marca correctamente el destino en el cliente RDP

En mstsc.exe, el campo Equipo debe incluir IP o nombre y puerto con dos puntos:

<IPpublicao_host>:3390

Recomendaciones y casos especiales:

• Si conectas dentro de la misma LAN, usa la IP privada de B (p. ej., 192.168.1.50:3390). Si intentas entrar por la IP pública desde dentro y tu router no soporta NAT loopback, fallará.
• Con direcciones IPv6, usa corchetes: [2001:db8::50]:3390.
• El campo Usuario no debe contener el puerto. Usa formatos como .\miusuario, EQUIPO\miusuario o miusuario@equipo.

Ten en cuenta el entorno de red

• Sin loopback NAT: desde dentro de la LAN, la IP pública no funcionará. Prueba con la IP privada de B.
• Doble NAT o CGNAT: si tu router cuelga de otro router o tu ISP usa NAT carrier-grade, la redirección puede no ser alcanzable desde Internet. Soluciones: modo bridge, port forwarding en ambos equipos, IP pública fija, o montar una VPN.
• Antivirus/EDR: algunos bloquean puertos o inyectan reglas. Desactiva temporalmente para descartar.
• Bloqueos del ISP: ciertos proveedores bloquean puertos entrantes por seguridad. Si Test-NetConnection falla desde fuera, consulta o usa un puerto alternativo alto.

Comprueba la configuración funcional de RDP

• Asegúrate de que RDP está habilitado y que la cuenta que usas tiene permiso.
• Si está habilitada NLA (Autenticación a nivel de red), usa credenciales válidas. Para pruebas, puedes desactivarla temporalmente y volver a activarla tras validar.
• Revisa el Visor de eventos en Aplicaciones y servicios → Microsoft → Windows → TerminalServices-RemoteConnectionManager y …→ LocalSessionManager para ver intentos de conexión y errores.

Tabla rápida de síntomas y causas probables

Síntoma	Pista	Acción inmediata
El puerto 3390 no aparece en netstat	Servicio sin reiniciar o puerto mal en el Registro	Reinicia TermService; revalida PortNumber
Test-NetConnection a 3390 falla desde A	NAT/ISP/firewall perimetral	Confirma regla de router, protocolo TCP, IP LAN correcta
Conecta en LAN pero no desde Internet	Redirección o CGNAT	Revisa NAT y la IP pública; valora VPN o puerto alternativo
Desde la LAN no conecta a la IP pública	Router sin loopback	Usa IP privada, o prueba desde fuera de la LAN
Pide credenciales y vuelve a pedirlas	NLA/credenciales o dominio equivocado	Usa EQUIPO\usuario o desactiva NLA temporalmente

Pasos detallados con explicación

Confirma y corrige el puerto en el Registro

Si editas con el Editor del Registro, navega a HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp y cambia PortNumber a Decimal = 3390. La confusión Hex vs Decimal es el motivo más común cuando “todo parece bien” pero el puerto no abre.

Reinicia y vuelve a comprobar el listener

Un servicio RDP sin reiniciar seguirá atado al puerto anterior. Tras el Restart-Service, netstat debe mostrar LISTENING en 0.0.0.0:3390 (o en la IP específica). Si aparece “Escuchando” en otra IP/puerto, revisa vínculos de red y directivas.

Crea reglas de firewall específicas

La regla por defecto “Escritorio remoto” se centra en 3389. No la borres: solo añade una paralela para tu puerto nuevo. Si administras varios puertos (3390, 3391…), crea una regla por cada uno; usa nombres descriptivos.

Valida desde la máquina origen

Test-NetConnection te da una respuesta binaria pero también información adicional (traza, latencia). Si falla, intenta la misma prueba desde un tercero en Internet para descartar problemas de ruta intermedia.

Asegura que el NAT apunta al equipo correcto

El error típico es confundir la IP LAN. Verifica la IP actual del PC B:

Get-NetIPAddress -AddressFamily IPv4 | Where-Object InterfaceAlias -notmatch 'Loopback'

Configura una reserva DHCP o IP estática para que el mapeo no “huérfane” al cambiar B de IP.

Conecta con el formato adecuado

El puerto se indica tras la IP o nombre con :. Algunos ejemplos útiles:

Escenario	Formato
Internet con IP pública	203.0.113.10:3390
Nombre DNS	mi-dominio.ddns.net:3390
LAN IPv4	192.168.1.50:3390
IPv6	[2001:db8::50]:3390

Comprobaciones extra y trucos

• RDP habilitado: confirma que “Permitir las conexiones de Escritorio remoto” está activado y que el usuario pertenece a “Usuarios de escritorio remoto”.
• NLA: si hay dudas con credenciales o políticas, desactívala temporalmente; una vez probado, vuelve a activarla por seguridad.
• Visor de eventos: errores como “No listener at port” o rechazos por credenciales aparecen en los registros de TerminalServices.
• Antivirus: algunos EDR añaden reglas silenciosas; revisa sus consolas.
• Servicio correcto: el servicio es TermService. Comprueba su estado con Get-Service TermService.

Alternativas de mapeo y estrategia con varios equipos

Para publicar varios PCs detrás del mismo router, lo más simple es no tocar Windows y dejar todos los equipos en 3389, mapeando puertos distintos en la WAN:

• WAN 3390 → B:3389
• WAN 3391 → C:3389
• … y así sucesivamente.

Ventajas: reglas de firewall estándar, menos cambios en los PCs y administración más clara. Si ya cambiaste el puerto en B, no pasa nada; solo sé consistente con el NAT.

Modelo de pruebas de extremo a extremo

1. Local en B: netstat / Get-NetTCPConnection en 3390 → Debe escuchar.
2. Firewall: regla TCP 3390 permitida → Debe existir.
3. LAN: desde otro PC en la misma red, Test-NetConnection a IP de B:3390 → Debe abrir.
4. Internet: desde A, Test-NetConnection a IP pública:3390 → Debe abrir.
5. Cliente RDP: en mstsc, conectar a IP:3390 con usuario correcto → Debe iniciar sesión.

Archivo RDP de ejemplo

Si prefieres guardar un acceso directo con el puerto embebido, crea un archivo B.rdp con contenido similar a:

full address:s:203.0.113.10:3390
username:s:EQUIPO\miusuario
prompt for credentials:i:1
administrative session:i:0
authentication level:i:2

Problemas típicos resueltos

• Conecto a C pero no a B: la regla de NAT de 3390 apunta a otra IP LAN o a un puerto LAN distinto. Corrige a <WAN 3390/TCP → B:3390.
• Marca ocupado o agota tiempo: el servicio no escucha en 3390 o el firewall lo bloquea. Revisa Registro, reinicia TermService y añade la regla.
• Conecta en LAN pero no desde fuera: NAT, CGNAT o bloqueo del ISP. Prueba con otro puerto alto o usa VPN.

Seguridad y buenas prácticas

• Evita exponer RDP directamente a Internet. Alternativas más seguras: VPN (WireGuard, OpenVPN), un RD Gateway o, como mínimo, restringir origen por IP en el router.
• Usa contraseñas robustas y, si es posible, MFA con RD Gateway.
• Reglas “por IP origen”: limita la redirección 3390 únicamente a las IPs desde donde te vas a conectar.
• Actualiza Windows y aplica directivas de bloqueo tras varios intentos fallidos.

Plantilla de comandos lista para copiar

En el equipo B:

# 1) Comprobar puerto configurado
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

2) Reiniciar el servicio

Restart-Service TermService -Force

3) Verificar escucha

Get-NetTCPConnection -LocalPort 3390

4) Firewall explícito

New-NetFirewallRule -DisplayName "RDP 3390" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow

5) Prueba desde A (sustituye \<IP\de\B\o\IP\_publica>)

Ejecutar en el equipo A:

Test-NetConnection \<IP\de\B\o\IP\_publica> -Port 3390 -InformationLevel Detailed

Checklist final

• El valor PortNumber es 3390 en Decimal.
• El servicio TermService está reiniciado y netstat muestra escucha en 3390.
• Existen reglas de firewall para TCP 3390 (y opcionalmente UDP 3390).
• La regla de NAT en el router es WAN 3390/TCP → IPLANde_B:3390.
• El cliente RDP marca a IPonombre:3390 y las credenciales son válidas.
• Si conectas desde la misma LAN, usas la IP privada y no la pública.
• Descartado CGNAT/doble NAT o, si existe, mitigado con VPN u otra solución.

Conclusión

El segundo equipo falla al conectar por RDP en un puerto distinto casi siempre por un detalle concreto: puerto mal configurado o no aplicado, regla de firewall incompleta, NAT apuntando a la IP/puerto equivocados o un intento de conexión con el formato incorrecto. Siguiendo la secuencia de verificación —puerto en Registro, reinicio del servicio, escucha local, firewall, prueba con Test-NetConnection, redirección WAN→LAN y formato IP:puerto— identificarás exactamente dónde se rompe la cadena y podrás resolverlo con rapidez. Para entornos con varios equipos, considera mantener 3389 internamente y diferenciar solo los puertos en la WAN; y, por seguridad, prioriza una VPN o un RD Gateway frente a exponer RDP directamente.

---

Resumen operativo

1. Confirma el puerto real en el Registro y en decimal.
2. Reinicia TermService o el equipo.
3. Valida la escucha en 3390.
4. Añade una regla de firewall para 3390.
5. Prueba con Test-NetConnection <IP> -Port 3390.
6. Asegura el NAT: WAN 3390/TCP → B:3390 (o WAN 3390 → B:3389 si no cambiaste Windows).
7. Conecta en mstsc con IPoDNS:3390 y el usuario correcto.