I set up three Lenovo ThinkCentre Tiny PCs with fresh Windows 11 Pro installations. All three have the same network configuration: private network profile, network discovery and file sharing enabled, fixed IPv4 addresses, and router reservations tied to their MAC addresses.
I changed the RDP listening port in HKEY_LOCAL_MACHINESystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp and created a Windows Defender Firewall inbound rule allowing TCP traffic on that custom port. I also disabled the default Remote Desktop TCP inbound rule for port 3389. The other two PCs accept Remote Desktop Connection sessions over the custom port, but the third one does not.
The affected PC shows the custom port as listening in netstat, and Remote Desktop is configured to require NLA. I restarted the computers after making the changes. If I restore the registry setting to 3389, re-enable the default firewall rule, and disable my custom rule, the affected computer works normally.
What else should I check to determine why this one machine will not accept RDP on the custom port?
4 Answers
First determine whether the problem follows the port number or the computer. Give the working PC the same custom port, and give the troublesome PC the working PC’s port. If the failure follows the number, look for a port conflict or filtering issue. If it stays with the same machine, focus on its firewall, services, or security configuration.
Test the port locally and from another machine instead of relying only on netstat. From the affected PC, try a local TCP connection to the custom port, and from a second PC use PowerShell’s Test-NetConnection against that address and port. If the service answers locally but not remotely, the firewall rule or network profile is likely wrong. Also make sure the Remote Desktop Services service was restarted after changing the registry, or reboot again to rule that out.
The port appears in netstat, but I’ll test it directly and compare local versus remote results.
As a diagnostic only, temporarily disable the firewall on both the affected PC and the connecting PC, then test the custom port. If it works, re-enable the firewalls and fix the rule rather than leaving them disabled. Confirm that the rule allows TCP on the Private profile and that there is no higher-priority block rule. RDP over the internet should not be exposed directly just by changing the port; use a VPN or another secure remote-access method instead.
The machines are currently LAN-only, but I was considering WAN access later. I’ll avoid exposing RDP directly and use a safer approach if that ever becomes necessary.
Check the Windows event logs on the affected computer, especially the TerminalServices and Windows Defender Firewall logs. A timeout usually points to filtering on the client, server, or network path. An authentication error suggests an NLA, account, workgroup, domain, or identity issue instead. Also compare the complete firewall rule properties with the working systems, including profile, local address, remote address, interface type, and program or service scope.
I’d also check whether any manufacturer security utility or third-party endpoint protection was installed on only that PC. Those can filter ports even when the Windows firewall rule looks correct.
That’s a good way to narrow it down. I’ll swap the port assignments and compare the results.