A Windows 11 workstation at a customer site cannot reliably connect to two office servers over Remote Desktop on the same network. One server usually takes two or three connection attempts, while the other disconnects with a generic network or firewall error. Strangely, if I connect remotely to the Windows 11 workstation first and then launch Remote Desktop from that session, both servers work normally. Reinstalling Windows and testing another computer did not change anything, and I use the same account both on-site and remotely. What could cause Remote Desktop to fail locally but work when launched inside another Remote Desktop session?
4 Answers
Check whether other local resources work from the affected workstation, such as file shares, printers, or Remote Desktop to other computers. If only these two servers are affected, compare their firewall rules, endpoint security policies, organizational-unit policies, recent patches, and network profiles. If many local resources fail, investigate the workstation's network authentication and domain connectivity instead.
Check whether endpoint protection or firewall policies treat local Remote Desktop traffic differently from traffic arriving through a remote session. The servers may be blocking or inspecting connections from the workstation's local network profile, domain classification, or IP address.
Try disabling the UDP transport for Remote Desktop on both the clients and the servers as a test. Some network paths, especially wireless ones, handle the initial TCP connection but cause disconnects when RDP switches to UDP. This can be tested through Group Policy or the appropriate registry policy, then reverted if it does not help.
Compare the connection method when you are on-site versus when you are inside the remote session. Try connecting by IP address instead of hostname, and then try the hostname again. Differences in DNS, name resolution, Kerberos, or NTLM authentication can make one path work while the other fails. Also check whether endpoint security is blocking local NTLM traffic.
It is worth testing this on just one client first. If the behavior changes immediately, the problem is probably with UDP handling rather than the user account or Windows installation.