We had to create this guide after having multitude efforts to get a simple iLB (Internal Load Balancer) in Azure ARM for setting up the ADFS (Active Directory Federation Services) servers to connect and work via a load-balanced IP in Azure ARM. The tricky part was to get this working as it should, because creating a Load Balancer was an easy task as we have loads of blog posts and Microsoft official documentation links are really good.
We spent a good couple months raising various support tickets with Microsoft via the portal and finally we did get a worthy engineer who figured out what went wrong. We decided to document this points as they are not mentioned anywhere in the blogs which we were searching.
The following guide assumes that the user has basic knowledge of using Windows. Although some familiarity with the Azure Portal would be beneficial, it is absolutely not necessary, as a step by step approach will be provided.
This guide only provides the steps to create an internal load balancer through the Portal. The entire task can be implemented using PowerShell, but this will not covered in any of the below sections.
This guide provides guidelines to perform Internal Load Balancing to a pool of similar functionality VMs ONLY (i.e. DNS Servers). Directed Load Balancing to a specific VM, using NAT rules, will NOT be covered below.
The following prerequisites must be met, before performing the ExpressRoute connection steps.
- Internet connection
- Valid Azure Subscription
- Some familiarity with the Azure Portal would be beneficial, although not necessary
- A VNET and Subnets must exist in the subscription otherwise, please follow the below guide to see how these are created:
- VMs in Availability Sets should exist otherwise, please follow the below guide to see how these are created:
- Some familiarity with Azure Network Security Groups would be beneficial, although not necessary
- See a detailed guide on how to Create NSGs
Only subscription Owners and Contributors have the access level to perform the below activities.
Create the Internal Load Balancer
The below steps show how to create an Internal balancer through the Azure Portal.
Figure 1: Creating an Internal Load Balancer
After finding the “Load Balancers” option on the leftmost pane, the above (Fig. 1) panes appear. The steps to create the new Internal Load Balancer are as follows:
- Click the +Add button on the top and the first step is to fill in the Name textbox
- Select the “Internal” type
- Click the “Virtual Network” button and a pane will appear showing the available VNETs in this subscription
- Select the desired VNET
- Click the “Subnet” button and similarly select the desired Subnet where your ILB will be performing the load balancing
- Select “Static” IP address for your ILB
- Set the desired IP, which must be in the range of the Subnet that was selected in step 5
- Select the Subscription under which the load balancer will be created
- Select the “Resource Group” and “Region” under which the ILB will reside
- A new Resource Group can be used or
- an existing Resource Group can be used
- Click “Create”
Since VMs, VNETs and Subnets will be created before the Load Balancer, at least one Resource Group will be in place and can be used for the ILB. However, it is wise to use separate Resource Groups for components-resources of different type (i.e. VMs, Network Components, or applications) to achieve better segregation in the environment.
Configure Azure Internal Load Balancer
This section will provide a step by step guide on how to setup the configuration of the Internal Load Balancer
Configuring the Backend Pool
In order for your Internal Load Balancer to provide its desired functionality, an already created Availability Set, containing VMs, must be used as a Backend Pool.
Figure 2: Setting ILB Backend Pool
- Select the newly created ILB
- Select “All Settings”
- Select “Backend Pools”
- Click the “+Add” button
- Click “Add a virtual machine”
- Select the VMs to reside behind the load balancer (Fig. 6)
Figure 3: Selecting the VMs where traffic will be load balanced
The VMs to which traffic will be load balanced MUST reside in the same Subnet as the Internal Load Balancer.
VMs need to belong to the SAME Availability Set.
Configuring the Probe
A probe must be created in order for the ILB to be able to check whether the VMs that reside behind it are still alive.
Figure 4: Creating ILB Probe
- From the ILB Settings pane select “Probe”
- Click the “+Add” button on the top of the first blade that opens
- Set the Probe Name in the textbox
- Select the Probing protocol
- Select the port to which your probes will check the load balanced VMs
- Select “Create”
- (Not necessary) Setup probing interval and failure threshold
It is recommended to use HTTP for the Probe, ONLY when Web services are being load balanced, thus not recommended for internal load balancing.
If the Probe is setup to talk to a non-standard port (i.e. 9000), this has to be opened inside the VM, or else the probing will fail.
Configuring the Load Balancing Rule
Finally, the Load Balancing rule has to be setup.
Figure 5: Creating the Load Balancing Rule
- On the Load Balancer Settings select “Load balancing rules”
- Select “+Add” on the top of the middle blade
- Type the Name of your rule in the textbox
- Select the “Protocol” (TCP/UDP)
- Set the “Port” to which the Internal Load Balancer will listen to
- Select the “Backend Port” to which the traffic will be re-directed, when propagated to the load balanced VMs
- Select the “Backend pool” created in section 3.1
- Select the “Probe” created in section 3.2
- Select “OK”
Frontend and Backend ports need to be standalone ports (i.e. 443 443). Port ranges are NOT supported.
Multiple Rules can be created in one Load Balancer.
Frontend and Backend Ports DO NOT have to match. The configuration is up to the designer, i.e. directing traffic from Load Balancer Frontend 443 to VM Backend 8443
Setting up the Network Security Groups
In order for the Internal Load Balancer to properly work, a number of network rules (See Table 1) have to be created, allowing inbound traffic to the Subnet, where it resides. Please refer to Appendix for explanation of the notations used in the below table.
|Name||Source IP Prefix||Destination IP Prefix||Source Port||Destination Port||Type|
|1||ALLOW-DYNAMIC||<IP Range>||<Subnet IP Range>||Any||49152-64535||Allow|
|Allows inbound traffic to the subnet from the defined IP Range, from any port to any of the Dynamic Range Ports.|
|2||ALLOW-<Port>-TO-ILB||<IP Range>||<ILB Front IP>||49152-64535||<Front ILB Port>||Allow|
|Allows inbound traffic to the ILB frontend IP from the defined IP Range, from the Dynamic Range ports to the ILBs frontend port as set in Section 3.3|
|3||ALLOW-PROBE||Tag “AzureLoadBalancer”||<Subnet IP Range>||*||<Probe Port>||Allow|
|Allows the probe to initiate from the Load Balancer (Tag) to the Subnet IP Range, from Any port to the port specified in Section 3.2|
|4||ALLOW-<Backend Port>-ILB-TO-SUBNET||Tag “AzureLoadBalancer”||<Subnet IP Range>||49152-64535||<Backend Port>||Allow|
Allows traffic to the Load Balancer (Tag) to send traffic to the Subnet IP Range (including the load balanced VMs), from the Dynamic Range ports to the Backend port as created in Section 3.3
Table 1: NSGs to allow Internal Load Balancer properly operate
Rule 1 will be common in the NSG for this particular subnet, regardless of the number of ILBs existing in the subnet.
Testing Load Balancing is Properly Working
In order to verify that the traffic flows though the load balancer to the VMs that sit in the Availability Set behind it, the connection must be tested using telnet.
Ensure telnet is enabled on the machine from which you are trying to perform the testing (see Fig. 6).
- Search for “Features” in the Start search box
- Click “Turn Windows features on or off”
- Tick the “Telnet Client” option
Figure 6: Enable Telnet
From the cmd, Telnet the port to which one of the load balanced VMs will listen to. This port should be the one that is configured as Backend Port in your Load Balancer in Section 3.3. Please use the command: telnet <Load Balanced VM IP> <Backend Port>
The above command should allow connection to the port of the VM, provided it has been previously opened (default ports i.e. 443 for HTTPS will be open by default).
This will verify that the VM will be listening to this port.
The next step is to Telnet the IP and port to which the Load Balancer will listen. This IP should be the Load Balancer’s IP, as configured in Section 2, while the port should be the Frontend Port, as configured in Section 3.3.
Please use the command: telnet <Load Balancer IP> <Frontend Port>
The above command should allow redirection of traffic to one of the load balanced VMs behind the Load Balancer (see Fig. 7).
Figure 7: Successful telnet to Internal Load Balancer, redirecting to a VM behind it
You CANNOT control to which VM the traffic will be directed behind the Load Balancer. For this purpose, a NAT rule has to be created, which is NOT covered in this guide.
You CANNOT Ping or Tracert the Internal Load Balancer’s IP.
The below table (Table 2) provides a detailed explanation and examples of what the annotations refer to in the Network Security Group Rules.
|1||<IP Range>||The IP Range from where traffic will be coming from (different than the Subnet, where the ILB and VMs belong to)||10.0.0.0/16|
|2||<Subnet IP Range>||The IP Range of the Subnet, where your Load Balanced VMs reside||192.168.0.0/24|
|3||<ILB Front IP>||The IP of the Internal Load Balancer||192.168.0.250|
|4||Tag “AzureLoadBalancer”||Refers to the Azure Load Balancing Service||–|
|5||<Front ILB Port>||The port to which the Internal Load Balancer will listen to (see Section 3.3)||443|
|6||<Backend ILB Port>||The port to which the load balanced VMs will listen to behind the Load Balancer (see Section 3.3)||443 (could be different than the ILB Frontend port)|
|7||49152-65535||Dynamic Range Ports, from where traffic originates in general||–|
Table 2: Explanation of annotations used in NSG Rules