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.
"The only thing that changed over the weekend is that Windows Updates were applied." - Which updates? – Ramhound – 2020-01-20T18:35:51.240
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 – 2020-01-20T22:08:00.567