RDP connection failures is a pretty common problem that people come across when trying to access their computers remotely. The problems behind this may be as follows.
Remote computer:
Local computer:
We’ll be discussing firewall settings in a separate post.
Firewalls on the local machine
Modern firewalls typically work on multiple levels of the OSI model, including the application level. For the end user that usually means some newly installed applications are asking for permissions to access the intranet and/or the Internet.
If you are using the RDP application that comes with Windows (accessible via cmd.exe by typing mstsc), then you need port 3389 to be open.
In case of 3rd party remote desktop solutions, other ports may be needed (sometimes, UDP).
Network-based firewalls
Those hardware solutions are typically your ISP’s or IT department’s equipment. So, you have checked your RDP settings and local firewall, and remote desktop still cannot connect.
Port forwarding
Port forwarding is a standard technique for making intranet resources available to the outside world (the Internet). We will be discussing it in a separate article.
There’s a big advantage in the simplicity – you don’t have to authenticate. On the flip side, that’s the big drawback – serious lack of security.
VPN
Virtual Private Network is more secure than port forwarding. As it’s the preferred option, many VPN solutions are available from different vendors. You have to authenticate, but that’s no big deal when it comes to security.
Third-party remote desktop tools
If your IT department cannot do any of the above, then you can resort to third-party remote desktop tools.
Such tools mostly rely on an intermediate server, so no additional network configuration is necessary. If remote desktop is the only function that needs to be available from remote locations, then it’s the simplest option. Security considerations are still there but they all mostly boil down to choosing a trusted vendor. Also, you may set up your own self-hosted solution if remote desktop is largely used within the organization.
Also, speed may degrade severely if the remote machine is sitting behind NAT. All data will be sent through an intermediary server. That’s yet another reason to consider VPN.
Some vendors (such as LogMeIn) are offering both remote desktop/remote access and VPN.
Some offer browser-based solutions (ScreenConnect, DeskRoll).
Conclusion
We’ve considered several ways of making remote desktop work through firewalls. VPN by far seems to be the most versatile and flexible solution, and there is an abundance of third-party tools fit for any scenario if VPN is not possible.