Load Balancer Behavior and Inbound Port Rules in Azure

Question

I have configured three Windows Server virtual machines in Azure and set up a load balancer with backend rules. Initially, all three VMs were marked as healthy by the load balancer's health probe.

The servers host an HTTP application, and I configured inbound port rules to allow traffic on port 80. Later, I removed the inbound port rule for port 80 on one of the VMs, expecting the load balancer to mark it as down. However, this did not happen, and the VM continued to show as healthy in the health status of Loadbalancer Rule, Only after I stopped the VM did it disappear from the health status of Loadbalancer Rule.

This behavior raises the question: does the load balancer's health check ignore inbound port rules on individual VMs?

Additionally, I restricted the VMs to accept traffic only from the load balancer's frontend IP using inbound port rules. After applying this configuration, I was unable to access the websites through the load balancer's public IP.

I would like to understand the reasons behind this behavior and how the inbound port rules and load balancer health checks interact in this scenario

Answer 1

Azure Load Balancer's health probes operate independently of the inbound port rules configured on the individual virtual machines (VMs). The behavior you're seeing is expected:

---

1. Health Probe Behavior and Inbound Port Rules

• How Health Probes Work: Azure Load Balancer health probes send requests directly to the backend VMs over the configured probe protocol (TCP or HTTP). These probes bypass the Network Security Group (NSG) rules for the specific health probe IP ranges used by Azure. This means that even if an inbound port rule blocks port 80 for general traffic, health probes can still reach the VM if the application on port 80 is running and responding.
• Why the VM Showed as Healthy: When you removed the inbound port rule for port 80, the load balancer health probe continued to reach the VM because Azure bypasses NSG rules for probe traffic. The VM remained healthy as long as the application responded to the health probe requests. Only when the VM was stopped did it fail the health probe checks and get marked as unhealthy.

---

2. Restricting Traffic to the Load Balancer’s Frontend IP When you restricted the VMs to only accept traffic from the load balancer's frontend IP using NSG rules:

• Impact on Accessibility: This likely blocked the load balancer's health probes because the health probes originate from a specific Azure IP range, not from the load balancer's frontend IP. By restricting traffic to the frontend IP, you inadvertently blocked the health probes, leading to a failure in accessing the websites.
• Health Probe IP Ranges: Azure health probes originate from specific IP ranges depending on the Azure region. These IP ranges are documented here, and your NSG rules need to allow these IP ranges for the health probes to function.

---

To address these issues:

1. Allow Health Probes in NSG Rules:
   • Ensure your NSG rules allow traffic on the probe port (e.g., port 80) from Azure's health probe IP ranges. You can add an inbound rule to explicitly permit traffic from 168.63.129.16 (used by health probes) or the documented probe IP ranges for your region.
2. Validate NSG Rules:
   • Use the Network Watcher in Azure to validate effective NSG rules and ensure that health probe traffic is not being inadvertently blocked.
3. Restrict Traffic Securely:
   • If you want to restrict access to your application, consider combining NSG rules with Azure Load Balancer configurations to allow traffic only from the load balancer frontend IP for non-health-probe traffic.
4. Testing:
   • After making changes, confirm the health probe status and test accessibility to the application using the load balancer's public IP.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin