Sanganak Authority: March 2020

12 min to read.

Abstract

Believe it or not! On-premises firewalls port opening process is proving to be number one blocker for Azure adoption, till the time Site to Site VPN or Azure Express Route is setup.

Problem is not with changing the firewall rules to access Azure VM either by RDP or SSH; It is the “process” setup by an Enterprises to allow an outbound traffic from their on premises network; to Azure or internet in general.

I am not saying security teams working for on premises environment security is bad; it is their job to keep things secure and hence they will always hesitate/ seek approval/ seek clarifications to open 3389 or 22 port for outbound traffic from their network.

In this blog post I will illustrate a way by which you can access Azure VM either by RDP or SSH without asking your internal network/ security team to open any ports.

Let’s go!

Problem Statement

Refer to below diagram – [To get good view of the diagram, click on it]

1.      As you can see in the diagram above; your laptop is sitting in your organizations network which is controlled environment with Firewall and proxy devices.
2.      You have azure VM with public IP x.x.x.x as shown in the diagram.
3.      To make RDP/ SSH into Azure VM you need to use standard ports like 3389 for RDP and 22 for SSH.
4.      There is no Site to Site or Express Route present between your on premises network and Azure environment.
5.     Your organizations on premises firewall device blocks any outbound/ outgoing internet traffic with port 3389/22.
6.      Hence your RDP/ SSH to Azure VM from your laptop fails.

So you may say that let me talk to my network/ security/ firewall team and see if they can open 3389/ 22 port outbound for my laptop IP?

Well you can do that but based on my experience I have seen, it takes weeks to get 3389/ 22 opened for internet or even for particular IP. Also organizations have a process set for making port opening and rule modification in firewall. As security teams and your firewall operations always go through stringent audit and compliance process; it will always be a big battle for you.

If you are financial organization then opening up 3389/ 22 over internet in on premises is never happening!

The most secured solution is to use either Site to Site VPN or Express route to connect to Azure VMs. However configuration of these also takes time.

So what is the solution to quickly get started with RDP/ SSH to Azure VM without opening on premises firewall rules?

Solution architecture – Have Azure VM behind Azure Load Balancer

Although all on premises firewall/ proxy servers will block 3389/ 22 ports; they will always have 443 port

outbound open. For example from my laptop in above diagram if I plan to access https://google.com then this will be accessed over 443 port only as most of the trusted site works on https and default port for https is 443.

So if I take RDP/ SSH from my laptop over 443 port instead of 3389/ 22 port then traffic originated from my laptop should cross on premises firewall and reach out side.

The question is how do I allow RDP/ SSH over 443? Because default port of RDP is 3389 and SSH is 22 and it

can’t be changed. This is where I need “Inbound Network Address Translation [Inbound NAT]”.

Means my traffic should reach to Azure VM over 443 but the 443 port needs to be translated/ changed to 3389 or 22. However Azure VM can’t to inbound NAT and this is where we need Azure Load Balancer.

Azure load balancer is an awesome PaaS service. It takes care of inbuilt HA for you. It comes in 2 flavors –

1. Basic - Free
2. Standard – Cost is associated with it.

For our case we can use Standard or Basic. I am poor guy and always love to avoid unnecessary spend. Because the contract of unnecessary spend I have given to my better half. So I will use Basic layer 4 Azure load balancer for this tutorial.

Refer to below diagram – [To get good view of the diagram, click on it]

1.      From local laptop either for doing SSH or RDP use 443 as a port instead of standard ports for SSH and RDP.
2.      As the traffic to Azure VM is over 443; it is allowed in on premises firewall.
3.      The request for RDP/ SSH lands on Azure public Load balancer.
4.      The inbound NAT rules are processed, and incoming traffic translated to 3389/ 22 ports. Then forwarded to backend pool which is our VM we want to access.
5.      Similarly as session is established within on premises firewall; the return traffic flows back seamlessly to our laptop.

This way even if we don’t open any ports in on premises firewall we are able to reach to our VM on Azure.

Azure Public Load Balancer configuration

I am assuming you have Azure VM public IP, so follow the rest of the process.

First we will remove existing Public IP assigned to VM NIC; so that we can use same Public IP for Azure LB. As we are bringing Azure VM behind Azure LB; we don’t need Public IP for Azure VM.

Below screenshot depicts how can you disable the public IP for Azure VM NIC.

The IP that we assigned to Azure LB while creation will be configured automatically as “Frontend IP configuration” within Azure LB.

Create LB as shown. Attach same Public IP which we removed from Azure VM NIC. You can also create new to attach to LB but not required. Let us leverage existing public IP only.

Configure the existing VM as backend as shown below –

Then click on “Inbound NAT rules -> Add”. Provide the values as shown below –

In above NAT rule I am setting up custom port to 3389 as I am having windows VM to which I am doing RDP. If you have a linux VM, you should put custom port as 22.

After configuration of NAT rule in Azure LB if you see VM; you will still see same Public IP attached. Even if it shows public IP attached to Azure VM, it is actually attached to Azure Load Balancer. This can be confirmed with Public IP information blade from Azure portal as shown below –

RDP view

If you now try to make RDP using simply public IP as below it will not work. Because by default the system assumed the port number 3389.

Try the same RDP with 443 port and it should be successful as below –

In case this doesn’t work, make sure the NSG attached to VM is not blocking any traffic from Azure Load Balancer. By default rule in NSG allows the full traffic from load balancer to Azure VM and it’s weight is 65001 as shown below –

If you have added any other rule with lower weight value than 65001, then that rule might be blocking communication from load balancer to Azure VM. So kindly check NSG rules if this doesn’t work.

Benefits of this approach

Biggest benefit of this approach is you don’t have to inform anything to your security/ firewall teams. This works seamless. Biggest problem I see it as a security risk.

Bonus tip

Tip 1 –

Is this correct practice? Well not really. But if you want to get started immediately while your port opening in your organization is taking place or setup of Site to Site VPN, or Express Route is going to take time, then this is life saver.

Ultimately aim should be setting up Site to Site VNET or Express Route to access Azure resources from your on premises.

Tip 2 -

You can leverage azure offering called as Azure Bastion.

Conclusion

Hope this article helped you to get started on Azure VM quickly. Let me know your views in comments section below to improve and what are your thoughts on this approach.

Happy hacking!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.