This is one of those silly little things that comes along every so often just to mess with your head, and to cause some issues. Of course it has to happen at a time when you really want to connect to the remote machine and do some work.
This week I was at a training event for internal Microsoft engineers, and when back at the hotel I tried to connect to one of my Azure based lab VMs. As you may imagine this did not work, hence the post, and Remote Desktop Connection Manager (RDCMan) did not connect. It reported unable to establish a connection. The standard RDP client (MSTSC.exe) was also unable to connect.
Weirdly enough one or two of my VMs could be accessed. Only the two AD FS servers. Nothing else….
Time to find out what is going on.
Devil In The Networking Details
Opening up Network Monitor revealed that the Azure VMs which could be contacted were running on the standard RDP port of TCP 3389. We can easily filter for this my using a filter in Network Monitor. For addition example Network Monitor (NetMon) filters please see this post.
// Filter frames by TCP port number.
tcp.port == 3389
Zooming into the Frame Summary pane makes this slightly easier to read. It is the same information as the screen above.
Note that we can see the TCP handshake completing, and then the SSL handshake successfully completing.
Contrast this with one of the Azure VMs which were not working. This VM was published on TCP port 52659. This was a random high port chosen previously.
// Filter frames by TCP port number.
tcp.port == 52659
Note that the TCP three way handshake does not complete. All we see are three SYN frames sent by the client. Nothing comes back. Typically this is caused by a network device blocking the traffic.
Azure VM Port – Switching It UP
Since some of the RDP traffic was allowed, the standard TCP 3389 port, what about other ports? Were they doing something to the high port ranges only? Was it worth a try to see if it would help? Well, yes as it could not make it work worse…..
The VMs in question were made accessible using a NAT rule on the Azure load balancer. To modify the port the RDP client connects to, we need to edit the NAT rule. Below we see the starting NAT rule where externally TCP 52659 is mapped to TCP 3389 on the actual Windows server.
Let’s edit the NAT rule, and change it so that the NAT rule will be on TCP 49999 externally? There might be a rule blocking traffic over the 50, 000 port range….
