Unable to RDP to Azure VM From Hotel WiFi


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.

RDC Manager - Denied!

Weirdly enough one or two of my VMs could be accessed.  Only the two AD FS servers.  Nothing else….

RDC Manager - Working

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

NetMon - RDP On TCP 3389 Working As Expected

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.

NetMon - RDP On TCP 3389 Working As Expected - Frame Details

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

NetMon - RDP On TCP 52659 Not Working As Expected - Frame Details

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.

Starting Azure VM NAT Rule for RDP Access on TCP 52659

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.

Editing Azure VM NAT Rule for RDP Access on TCP 49999

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.

Azure VM NAT Rule for RDP Access on TCP 30000

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.

Azure VM RDP Working on TCP 30000 - NetMon Details

And the server is accessible via RDP.

Azure VM RDP Working on TCP 30000

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

Comments (1)

  1. Dima says:

    I feel your pain, bro! Always wanna kick the network guys! 🙂

Skip to main content