External RDP Access To Azure RM VM

Depending upon how your organisation has deployed Azure there may or may not be a need to have RDP access to Azure VMs from the Internet.  In cases where there is a site to site VPN (S2S)  the S2S VPN will typically be used to access VMs. Traffic will be routed from the corporate network over the S2S tunnel to the VMs.  Client VPN may also be provided in some companies as an alternative.

Should there be no VPN connectivity it may be necessary to open and configure RDP to the existing Azure VMs.  This can be enabled in a couple of ways:

• Public IP address assigned directly to the VMs Network Interface
• Via Public Load Balancer

Be sure to read the note about Network Security Groups at the end of the post.

Note that if you are creating a simple Azure RM VM from scratch then you probably want to start with Create a VM with a static public IP using the Azure portal.

Public IP Address Assigned to Network Interface

This is very similar to creating a standard VM, and providing a public IP.  Though a neat trick is that this can also be used for VMs which are already part of a load balanced set.  You can maintain the existing load balanced config, and add a public IP address to the server.  This allows you to target the server directly to test and validate the application/service running on the machine.  Yes we do define heath checks on the Azure load balancer, but there is still often value in being able to target specific machines.

Navigate to the VM in question.  Select Network Interfaces, and you will see the below:

Note that there is currently no Public IP address assigned to this Azure RM VM.  Noting is present as indicated by the underlined red line.

Click on the network interface, in this case it is called Tail-CA-Proxy-PrimaryNic.  This will open up the properties of the NIC.

Then click onto IP Configurations  then click onto the name of of the configuration, in this case it is Tail-CA-proxy-PrimaryNic-IpConfig, to see the configuration of the NIC.

We need to modify the Public IP address settings in the below.  Note that the private settings should not be modified.  We just want to add the public IP.

Click to Enable the Public IP address, and complete the configuration.  Typically you will create a new public IP address.  You can decide if you want a static or dynamic IP address.  Once the IP has been added, click save.

Note in this example the Public IP address has been added, and is about to be saved.

After the configuration has been saved, we can obtain the IP address from the same property sheet.  Note that the save button is greyed out, and that a class A public IP address is now displayed rather than “(unassigned)”.

Another place where you can quickly see the public IP address is under the Essentials pane of the VM’s properties.  Note that we can see the external IP below.

Those a just a couple of ways to determine what the public IP address currently is.  This is especially handy if you set the IP as dynamic as it will change when the VM is unallocated.

Additionally if you are using a dynamic IP, then it will change when the resource is unallocated.  Rather than using the IP, Azure also provides an option to assign a DNS label to the public IP address.  Thus you can use the FQDN and not worry if the underlying IP changes.  This is set on the configuration of the Public IP address, under the configuration element.  Note in the below screenshot a valid DNS entry was manually added.

This allows us to refer to the external IP via the created FQDN.  In this case the FQDN was tail-ca-wap1.eastus.cloudapp.azure.com

This is shown in the NSLOOKUP test below:

It may take a few seconds for the DNS information to update on the Azure zone.

Access Via Public Load Balancer

Using the Azure Public Load Balancer to distribute traffic is a common deployment scenario.  When load balancing HTTP or HTTPS requests from users we do not want to target individual servers behind the load balancer.  We want the load balancer to balance the load.  Hence it is called a load balancer…..

The below shows a typical HTTPS load balanced configuration.  This is the public load balancer for my Azure based WAP servers.

What we need to add is at the bottom of the screen in the left hand corner – inbound NAT rules.

In my lab, three NAT rules have been added.  This is because there are three VMs behind this load balancer.

If we examine one of the rules, there are a few things to point out.  Since there is a single external IP, we need to have some way of differentiating between each of the VMs.  This is done by using a different TCP port on the external IP.  Internally though RDP is still running on the standard port on the VM, 3389 TCP.  So we need to map the non-standard external port to the regular RDP on the VM.  This is done by defining the external port as custom, and also using a custom port mapping to the internal port.

In this case 51753 TCP is the external port which is being mapped to 3389 TCP on the VM.

You can use the TCP which makes you happy, just ensure that there are no conflicts….

As noted above, you can either use the public IP address, or define a DNS label on the public IP and use that instead.

Note that when configuring your remote desktop client, be sure to specify the custom port you specified.   In the below example we are connecting to TCP 5567 on the public IP address of 13.34.6.84.

Network Security Group

Regardless of which method you chose, you will need to ensure the Network Security Group configuration will allow your traffic.

Note in the below example, the underlined ACL allows access to the VMs by RDP.

Do not do what one of my other customers did and fall to this falsehood with regards to the ACLs.

Failure to Update

When configuring a public IP on one VM, I did hit an issue.  The Azure portal would fail to add the public IP address to the VM’s Network Interface. The below shows that the external IP is not correctly defined on the VM.

There was an issue with the underlying Azure fabric.  It took almost two hours to deallocate the VM.  When the VM was powered back on, all worked as expected.

Cheers,

Rhoderick