Part 1 of 2 – Port forwarding in Azure Resource Manager Virtual Machines with Azure Load Balancer: The Basics

In this post, I will show you how to use the Azure Load Balancer to easily setup port forwarding to Azure Resource Manager (ARM) Virtual Machines (VM).
This blog post is part of a two-part series on the topic of “Port forwarding in Azure Resource Manager Virtual Machines with Azure Load Balancer”:

• Part 1: The basics (this blog post)
• Part 2: Implementation in Azure Portal

I really hope you enjoy this two-part series and feel free to post your comments.

When to use port forwarding?

I can think of at least two reasons why you want to use port forwarding to ARM Virtual Machines:

1. You are behind a firewall that doesn’t allow access to standard ports like 3389 for RDP or 1433 for SQL Server. You can then use port forwarding to expose a port that is allowed by the firewall.
2. You want to use the same Public IP or DNS endpoint to access multiple virtual machines through port numbers, and at the same time you don’t want to (or can’t) change the ports internally on the VMs.

How does it work?

The trick is to use the Azure Load Balancer as part of the following setup:

• Azure Load Balancer Basic or Standard
• Load Balancer Backend  Pool pointing to the target VMs or Availability Set
• Load Balancer Inbound NAT rules
• Custom Port Mapping

The diagram below shows an overview of a setup where an external Microsoft Remote Desktop (RDP) client connects to a VM on port 8088 and 8089, but the receiving VMs wants to stay compatible with the standard RDP port (3389) internally:

(Azure RM (ARM) port forwarding using Azure Load Balancer)

So, what happens in the diagram?

Step :
A client tries to access an Azure VM based on IP 50.1.2.3 and port 8088 using the RDP (remote desktop) protocol.

Step :
The client hits the Azure Load Balancer through its public IP (PIP) and the NAT rule engine selects an inbound NAT rule.

Step :
Based on the port number (8088) requested by the client the corresponding NAT rule is selected.
This NAT rule then redirects the traffic into the VM0s internal IP (10.0.1.1) on port 3389. The NAT rule is configured specifically to redirect to VM0 and Custom Port Mapping ensures that port 8088 is translated into port 3389.

Step :
VM0 receives RDP traffic on port 3389 (the standard port for RDP) and never needs to do any tricks to support the non-standard port 8088; hence staying compatible with other clients that rely on port 3389 for RDP access.

Step ,  and :
These steps are basically the same is step 1-4, but in this case, the client requests port 8089. The NAT rule (in step 6) is now redirecting to VM1 because port 8089 activates the NAT rule which redirects traffic to VM1 (IP 10.0.1.2) on port 3389.

Next up…

Do you want to see a real-life example of how you can implement this yourself using the Azure Portal?

If the answer is yes then follow on to Part 2!