access control list

You buy a new Azure subscription, spin up an Azure Virtual Machine. Now you want to test if it is working or not. So, you pull up the infamous Command Prompt (or powershell) and Ping the VIP (Virtual/Public IP) of your Azure Virtual Machine. Wola!! The ping fails with 100% loss. But you can see that the Azure Portal shows that your virtual machine is up and running. To double check, you even RDP to your VM and it is all good. This is one of the many situations where the Azure new comers get confused. Let me break down this for you:-

The explanation for this behaviour is that the good old, Windows Ping.exe uses ICMP protocol to communicate. But the Azure Load Balancer does not support ICMP protocol when a connection is being made from external source to Azure. This means, your local computer will not be able to “Ping” (probing using Ping.exe) the Azure virtual Machines. However Azure Load Balancer allows ICMP protocol inside the azure (internally). This means, two Azure virtual machines are able to talk to each other.

The solution is to ping the port of your Virtual Machine.

Example: Ping xx.xx.xx.xx:1234

Since Ping.exe does not support probing the port, we have to use the other tools like PSPing, TCPPing etc, to achieve this.

This explains most of it. I am going to demonstrate whatever I just explained.

Below is the details of my virtual machine:

VM Details

When I ping the VIP – 13.76.247.67, using the default Ping.exe. You can observe that we end up having 100% packet loss.

packet_loss

This behaviour is because the Azure Load Balancer does not allow ICMP communication between Azure and the external source. And Microsoft’s Ping.exe uses ICMP protocol.

The solution is to use PSPing (among many other options), and ping the port of the Virtual Machine. Please note that you have to add relevant entry in the NSG (Network Security Group) to allow incoming traffic to your Virtual Machine.

Since this is just a Demo, I have allowed all the traffic to my Virtual Machine via the port 3389. You have to use appropriate NSG and ACLs to your Virtual Machine and Subnet, in your production environment.

NSG_Allow_All

PSPing.exe comes with a bundle – PSTools. This toolset can be downloaded here.

Copy PsPing onto your executable path. Typing “psping” displays its usage syntax.

psping_syntax

Note: If you are using the PSPing tool for the first time, you may have to agree to the terms and conditions before using it.

Since I have my port – 3389 opened for all incoming traffic. I will go ahead and use the PSPing tool to ping the port from my local computer. And as you can see it works like a charm !!

ping_success

Finally, note that you can ping only to the port for which you have enabled the incoming traffic. Since I have not enabled port 80, I expect the packets to be dropped.

packet_loss_wrong_port

This topic is pretty straight forward. Once you have your Azure Windows Server spun up, you can connect to it using RDP tool if your source is a Windows operating System.

But when you are in Linux the story is different, as it does not have the RDP tool. We have plenty of open source tools that we can use to make a connection from Linux Box to Windows Server.

Since we are discussing about Azure, I am using an Azure VM. Below is the details of that machine:

VM Details

We are going to use the “RDesktop” tool to connect from Linux to Windows. Installation of RDesktop is pretty simple. You may google/bing for assistance, or check this link for the complete installation guide in RedHat/CentOS/Fedora Operating System.

Once you have your RDesktop setup. Enable the RDP port- 3389 in your Azure virtual Machine. You can achieve this by adding “Inbound Security Rules” into your Network Security Group, via the Azure Portal.

For demo purposes, I am allowing all incoming traffic for the port – 3389. However, incase of production environment, you may have to provide appropriate rules for your NSG (Network Security Group) and ACLs (Access Control List) for better security.

NSG_Allow_All

Once RDesktop and RDP ports are configured. You may now run the RDesktop command to connect to your Virtual Machine.

Command: sudo rdesktop <IP Address>

rdesktop_fail

As you can see in the above screenshot, the connection fails. This is an expected behavior, because by default the RDP connection is set to “Allow connections only from computers running Remote Desktop with Network Level Authentication”

NLA_Enabled