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.
The VMs which were working were published using a Public IP address assigned directly onto the network Interface as discussed in External RDP Access To Azure RM VM.
// 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....
Changing Azure VM RDP Port To 49999 TCP
The Port is changed in the below screen, and then the configuration is saved. Note that the Target Port remains at TCP 3389 as that is what the application, RDP in this case, is using on the referenced server.
Did that make a change? Nope.
Changing Azure VM RDP Port To 30000 TCP
Lets adjust the bracket down further, and change the NAT rule to use 30000 TCP. The below image shows that this has been edited and saved.
Does that work now? Yes it does!
Note that we can see the expected TCP and SSL handshake conversations in NetMon. The filter was adjust to display TCP port 30000 traffic.
And the server is accessible via RDP.
Rule #1 Blame Network
After figuring out how to work around the issue, I thought it would be fun to call the hotel's WiFi support line to see what they had to say.
After explaining that general internet browsing was fine, that took 2 minutes to get through, the standard line of "we are not blocking anything" was applied. The additional complexity that this was not a web site which I was trying to access was probably not something that they normally dealt with.
But we are not blocking anything, sir! Well then how come it all just works when I tether to my phone ? How come I can get a single machine working, by changing nothing but the port it is listening on? The helpdesk staff member was super nice and friendly, but I have better things to so since the above workaround was functioning. Like finishing off the blog post to publish AD FS 2016 for Office 365.
The VMs which initially worked were published using a Public IP address assigned directly onto the network Interface as discussed in External RDP Access To Azure RM VM. This meant they were using the standard RDP port. The other VMs used custom ports, and if the port range was 'too high" then they were blocked by the hotel's WiFi provider.
Cheers,
Rhoderick
