An attendee at our IT Camp in Saint Louis a few weeks ago had an problem that is understandable:
“Thanks for training session, I have a question. Tried to RDP one of my VM’s at work and I can’t connect. Possible firewall port issue? I am going to try and connect from home tonight.”
You’re already onto the issue. It’s important to remember that the port that you’re using for RDP is not the traditional 3389.
“It’s not? How does that work?”
Let’s step back for a second and consider what you see when you first create a virtual machine in Windows Azure and you get to the screen where “endpoints” are defined. By default, it looks something like this…
…Notice that, even though the operating system is going to have Remote Desktop enabled and will be listening on the traditional port 3389, the external “public port” value that will be redirected to the “private port” 3389 is going to be something different.
Security. We take the extra precaution of randomizing this port so that tools that are scanning for open 3389 ports out there won’t find those machines and then start attempting to log in.
So the answer to your question: Yes, it’s a firewall issue. And I bet it worked from home later that night.
Let’s go one step further here and propose a couple of solutions to this, in case you also run into this problem.
Solution #1: Open up the proper outbound firewall ports
In the properties of your virtual machine, you can find what “public port” was assigned to the VM under the endpoints tab…
So this web server of mine is answering to my RDP requests via my ability to connect to it’s service URL and port 56537. Since I am not restricting outbound ports, this isn’t a problem for me. But knowing what this port is can help you understand what needs to be opened for a particular machine.
“Is there a range of ports that I need to have open outbound?”
The port that will be assigned automatically is going to come from the “ephemeral port range” for dynamic or private ports (as defined by the Internet Assigned Numbers Authority) of 49152 to 65535. So if you simply enable outbound connections through that range, the defaults should work well for you.
Solution #2: Modify the VM End Points
You’ll note on the above picture that there is an “edit” option. You have the ability to edit and assign whatever port you want for the public port value. For example, I could do this…
…and just use port 3389 directly. Of course, this would defeat the purpose for using a random, non-standard port for remote desktop connections. But it could be done.
Solution #3: Use some other remote desktop-esque tool over some other port.
The server you’re running as a VM in Windows Azure is your machine, so there’s no reason you couldn’t install some other tool of choice for doing management or connecting to a remote desktop type of connection. Understand the application, what port needs to be enabled on the firewall of the server, and then add that port as an endpoint; either directly mapped with the same public/private port or using some other public port. It is entirely configurable and flexible. And as long as you’ve enabled the public port value as a port you’re allowing outbound from your workplace, you’re golden.
Solution #4: Use a Remote Desktop Gateway
How about instead of connecting to machines directly, you do something more secured, manageable, and along the same lines of what you would consider for allowing secured access into your own datacenter remote desktop session hosts: Configure one server as the gateway for access to the others. In this way you have the added benefits of just one open port; and that port is SSL (443). You’re very likely already allowing out port 443 for anyone doing secured browsing (HTTPS://…), so the firewall won’t get in the way.
I hope you found this useful! Don’t hesitate to ask questions in the comments if you’d like me to clarify anything, or share your ideas if you have other solutions I haven’t yet considered.