Azure Standard Load Balancer | NSGs are a must

Azure Standard Load Balancer is a new Load Balancer SKU that provide 10x performance and more features than the Basic SKU. One of the coolest features is the ability to use two Standard Load Balancers as a public and internal Load Balancer at the same time. This allows a VM NIC to be connected to the backend pool of one public and one internal Load Balancer resource  where both are of Standard SKU.

I’m my test lab I tried to replicate the Internal + External loadbalancing scenario and found that only the Internal Load Balancer has been working. I’ve tried every possible change I could do including:

  • replicating the same inbound rules as the Internal LB,
  • deleting and re-creating the LB,
  • changing the health probes countless time,
  • changing the health probe settings,

and none of the tweaks I did worked for the External Azure Standard LB.

The Culprit

This article explains the security model of the new Azure Standard Load Balancer.  I had a through look in the documentation and found out the following section.

Standard Load Balancer is fully onboarded to the virtual network. The virtual network is a private, closed network. Because Standard Load Balancers and Standard public IP addresses are designed to allow this virtual network to be accessed from outside of the virtual network, these resources now default to closed unless you open them. This means Network Security Groups (NSGs) are now used to explicitly permit and whitelist allowed traffic. You can create your entire virtual data center and decide through NSG what and when it should be available. If you do not have an NSG on a subnet or NIC of your virtual machine resource, we will not permit traffic to reach this resource.

As you can see if we don’t assign an NSG rule to explicitly allow inbound traffic from the Internet to reach the LB backends (VMs) connected to the Azure Standard Load Balancer. Let’s examine a practical example.

In my example the backend VMs are connected to an Azure Standard LB that resides in the DMZ subnet of a VNet. I have created subnet specific NSGs so therefore the rule I’m going to create is assigned to the DMZ NSG.

As you can see all the inbound traffic originating from the Internet which are destined to ports 443,8443,8444 on DMZ subnet  have been whitelisted in this rule.  Also note that the External Azure Standard LB has three loadbalancing rules corresponsing to the same ports.

It is a simple solution yet can cause a huge trouble in your environment. In my case not having the NSG rules assigned has resulted in a Traffic Manager endpoint (of course the endpoint was an External Azure Standard LB) to be  in a degraded state during a DR drill. Therefore it is quite important to make sure that you have created the appropriate NSG rules if you are using the Standard SKU for your external Azure LBs.