0

I have a bit of a conundrum - we are no longer able to remote desktop into one of our domain controllers which we have always been able to in the past. This machine is a VM, and I can access its console via VMware. This machine is running Windows Server 2012. The only thing that changed over the weekend is that Windows Updates were applied.

I took a look at Windows Firewall, and see that the for the "Domain Profile" Windows Firewall is off. For "Private Profile", Windows Firewall is on, Inbound connections that do not match a rule are blocked, and Outbound connections that do not match a rule are allowed. It states that the Public Profile is active - Windows Firewall is on, Inbound connections that do not match a rule are blocked, and Outbound connections that do not match a rule are allowed.

Looking at Inbound Rules, I see the following four (4) rules:

  1. Remote Desktop - User Mode (TCP-In); Profile:Public; Enabled:No; Action:Allow; Override:No
  2. Remote Desktop - User Mode (TCP-In); Profile:Domain,Private; Enabled:Yes; Action:Allow; Override:No
  3. Remote Desktop - User Mode (UDP-In); Profile:Domain,Private; Enabled:Yes; Action:Allow; Override:No
  4. Remote Desktop - User Mode (UDP-In); Profile:Public; Enabled:No; Action:Allow; Override:No

If I simply enable to first rule, which is for the firewall's public profile, I can then successfully remote desktop into the server from my domain workstation. But why? The second rule should work to get us in from a domain workstation.

I appreciate any insight you can provide.

  • "The only thing that changed over the weekend is that Windows Updates were applied." - Which updates? – Ramhound Jan 20 at 18:35
  • KB890830 Windows Malicious Software Removal Tool x64; KB4534283 2020-01 Security Monthly Quality Rollup for Windows Server 0212 for x64-based Systems; KB4535103 2020-01 Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 for Windows Server 2012 for x64. – STLDev Jan 20 at 22:08
1

There are quite a few things that can go wrong here, but the steps necessary to solve the problem are not so complex that it turns this answer in an answer that is considered too broad for Super User.

First thing we need to do is download the x86 version of paping. Either open a command prompt in the folder you extracted paping to, or place paping in your C:\Windows\System32 (recommended) folder, so that you can start paping any time you open a new command prompt.

Paping allows you to test any port based on ip-address and port, to see if the port is open and a service is running behind it. This is essential to quickly test changes and speed up the troubleshooting stage significantly.

Once paping is installed, arrange your screens such that you see the VM on the left and your command prompt on the right. In command prompt, start a paping to your server. Assuming your server is located at 192.168.1.10 and you use the standard RDP port, 3389, your paping command would look like this:

paping 192.168.1.10 -p 3389

While paping is running, either you get a red line saying it timed out, or a green line saying the ping was successful. As long as the paping returns red, either the port/ip address is wrong, or the connection is blocked on the server, but in either case, the problem is on the server side. If it turns green, but you cannot connect, the problem lies somewhere else.

Given it always worked, I'm going to assume you are receiving a red time-out message.

Keep it open and trying while you test the following things:

  • Completely disable the Windows Firewall. If it turns green, the problem is firewall related.
  • Restart the Remote Desktop Services. If this was the problem, it will go from red to green and stay green.
  • Is there a different kind of firewall installed, or a service that auto-bans ip addresses upon multiple failed logins? (rdp guard, rdp defender, etc) These usually work with the Windows FireWall and should be bypassed the moment you disable the Windows Firewall.
  • Double check all settings regarding Remote Desktop. Is it still enabled? Is it still setup to the port it was once configured or did it somehow reset to default 3389? Or maybe someone changed it to a different port and forgot to mention it?

If none of the above fixes it, try paping directly from the host of the VM to its guests, and also try to reboot the server itself.

A few notes regarding Windows Firewall. - A connection can change from private to public if the network card drivers are updated. You can try to reconnect the network to get it to a private state again. - It is never a bad habit to enable RDP access to both private and public networks, such that even if somehow the connection changed from private to public, it still works.

Lets assume you can paping from your workstation with a green result, but you still can't RDP connect to it. Are you using the correct IP Address and Port? Are you trying to connect through a DNS or hostname, and is that translating to the correct ip address? If you use the domainname the client would normally use, and you are now internal, do you have hairpin natting enabled, such that your router actually understands the connection is meant inwards, not outwards?

This last paragraph is most likely not applicable, but I wrote it down to be thorough.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.