A problem that’s been bothering me recently: randomly and out of the blue, my workstation at home was having an issue opening a Remote Desktop Protocol (RDP) session out to another network, which has a Remote Desktop Gateway (RDG) server sitting in front.
After ruling out DNS resolution for the RDG server, my WAN connection’s ability to reach it (laptop works fine), and no other users reporting the issue I had to assume that Windows somehow broke itself throughout normal use.
I attempted to clean out the temporary files from my client computer, as well as any cache that RDP may have to no avail. I didn’t really want to consider reformatting just to fix this one RDP problem, and after some toying it seems the following has worked for me.
Within the “Local Security Policy” of your workstation exists settings to dictate what types of minimum encryption encryption are allowed for certain protocols, among a ton of other unrelated items. The option we’re interested exists in Security Settings > Local Policies > Security Options. The policy itself is labeled Network security: LAN Manager authentication level.
By default, the authentication level is configured for “Send LM & NTLM – use NTLMv2 session security if negotiated” or in other words, allow for lower security to provide a broader range of compatibility, but use the good stuff if the server you’re connecting to wishes to.
By changing the above dropdown to “Send NTLMv2 response only“, I was able to connect with no qualms whatsoever. Presumably, this means perhaps the RDG server is misconfigured, or this is just some obscure bug no one ever would want to look at. NTLMv2 should already be negotiated, but in this instance perhaps our client is not or is unable to recognize the NTLMv2 negotiation, therefore halting due to a failure in the handshake.
Hope this helps!