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.
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.
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 –
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.
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 -
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.
Or just use the cloud app based rdp connection you get from the vms blade in the portal.
ReplyDeleteOr better yet just get the firewall opened up, as soon as you show the security team is obstructing business by not allowing traffic and adding to the operational cost by needing an lb for one node. If opsec are getting in the way of a cloud migration they need to be included in the cloud migration team otherwise things like storage migration and phase 2 reimplementations will fail (phase one is lift and shift vms and physical servers, phase 2 is reimplent as app services, k8s and functions to take advantage of the scalability)
Thanks Nakchak for your comments. This is not for inclusion o IT team. They should be included. This is to be only used during the setup of either Bastion, Site to Site or ER is completed. As soon as we have things setup properly; this approach is not required.
DeleteThis doesn't work unfortunately. Certain firewalls can detect RDP traffic and block it. I'm able to connect to my VM via the LB's public IP on 443, but only when I'm not connected to my company's network with their firewall inspecting the traffic.
ReplyDelete