5.4 Inbound NAT Rules, Port Forwarding & Health Probe Design
Key Takeaways
- An inbound NAT rule performs port forwarding from a load balancer frontend IP and port to a specific backend instance and port, and unlike a load balancing rule it does not require a health probe.
- Inbound NAT rule V1 gives a 1:1 mapping between one frontend port and one backend virtual machine, which remains fully supported for single-VM RDP or SSH access.
- Inbound NAT rule V2 references the entire backend pool and preallocates a frontend port range from a start port and a maximum backend pool size, creating and removing per-instance mappings automatically as the pool scales.
- Inbound NAT Pools, the scale-set feature of inbound NAT rule V1, are retiring on September 30, 2027, and new pools cannot be created after November 15, 2026; single-VM V1 rules are unaffected.
- Every Azure Load Balancer health probe originates from 168.63.129.16, so an NSG or host firewall that blocks that address marks every backend instance unhealthy and the load balancing rule stops delivering traffic.
Inbound NAT Rules, Port Forwarding & Health Probe Design
A load balancing rule spreads traffic on one frontend port across many backend instances. An inbound NAT rule does the opposite: it forwards traffic arriving on one frontend port to one specific backend instance on a chosen backend port. It is Azure's port-forwarding primitive, and it is the standard way to reach individual virtual machines for management without giving each one a public IP address.
| Construct | Purpose | Health probe required? |
|---|---|---|
| Load balancing rule | Distribute a flow across all healthy backend instances | Yes |
| Inbound NAT rule | Port-forward to a specific backend instance | No |
| Outbound rule | Explicit SNAT for backend-initiated internet flows | No |
[!IMPORTANT] Inbound NAT rules do not need a health probe attached. This is stated explicitly in the documentation and is a reliable exam discriminator: an option that claims a NAT rule failed because its health probe was misconfigured is describing a load balancing rule, not a NAT rule.
1. Inbound NAT Rule V1 — Single Virtual Machine
V1 provides a straightforward 1:1 port mapping between a load balancer frontend IP and port, and one specific backend virtual machine and port.
| Element | Example |
|---|---|
| Frontend IP / port | 20.51.x.x:50001 |
| Backend VM / port | 10.10.1.4:3389 |
| Typical use | RDP or SSH to an individual VM through the load balancer |
The classic pattern is one NAT rule per VM — 50001 to VM1:3389, 50002 to VM2:3389, and so on — so a jump-host-free administrative path exists without publishing a public IP per machine. Microsoft states that for a single virtual machine port, inbound NAT rule V1 continues to be fully supported.
2. Inbound NAT Rule V2 — Backend Pool with a Port Range
V2 is the recommended option for Standard Load Balancer deployments that target multiple virtual machines or virtual machine scale sets. Instead of naming one VM, a V2 rule references the entire backend pool.
| Setting | What it does |
|---|---|
| Frontend port range start | The first frontend port Azure will allocate |
| Maximum number of machines in the backend pool | Determines how many ports Azure preallocates from the start port |
| Backend port | The single port on each instance that traffic is forwarded to, for example 3389 |
Azure preallocates the frontend port range when the rule is created and then creates per-instance port mappings from within it.
Scaling behaviour
- Scale down — existing port mappings for the remaining VMs persist. Instance-to-port assignments are stable.
- Scale up — new port mappings are created automatically for the new instances. No update to the NAT rule is required.
[!WARNING] Undersizing the port range blocks scaling. If the predefined frontend port range does not have enough free ports, scaling up the backend pool is blocked, which can leave new instances with no network connectivity. Size the "maximum number of machines" setting for the pool's eventual ceiling, not its current size.
You can retrieve the actual per-VM port mappings in the portal from the load balancer's inbound NAT rule view.
3. Inbound NAT Pools Are Retiring
Inbound NAT Pools are a feature of inbound NAT rule V1 that automatically create a NAT rule per virtual machine scale set instance from a frontend port range.
| Date | Event |
|---|---|
| November 15, 2026 | You can no longer create new inbound NAT pools |
| September 30, 2027 | Inbound NAT Pools are retired |
The documented migration path is to move scale-set deployments to inbound NAT rule V2. Single-VM inbound NAT rule V1 configurations are explicitly not affected by this retirement.
4. Health Probes: What They Actually Gate
Health probes determine which backend instances a load balancing rule will deliver new flows to. They do not gate inbound NAT rules.
| Probe protocol | Success condition | Typical use |
|---|---|---|
| TCP | The TCP handshake completes on the probe port | Generic services with no HTTP endpoint |
| HTTP | The probe path returns HTTP 200 within the timeout | Web tiers where a real health endpoint exists |
| HTTPS | The probe path returns HTTP 200 over TLS | Standard SKU only; web tiers requiring encrypted probing |
The probe source address
All Azure Load Balancer health probes originate from the Azure infrastructure address 168.63.129.16. Three practical consequences:
- The
AzureLoadBalancerservice tag must be permitted inbound on the backend NSG. It is allowed by an NSG default rule, so problems appear only when someone writes a higher-priority deny. - A host firewall on the guest OS — Windows Defender Firewall,
iptables,nftables— must also allow the probe port from168.63.129.16. - If every instance fails its probe, Standard Load Balancer stops delivering new flows entirely. Note the asymmetry: existing management access through an inbound NAT rule keeps working, because NAT rules do not consult the probe. "I can still RDP to the VMs through the load balancer, but the application VIP returns nothing" is the textbook signature of a probe failure.
[!TIP] Prefer an HTTP or HTTPS probe against a purpose-built health endpoint over a bare TCP probe for web tiers. A TCP probe only proves the listener socket is open; it will happily report a web server as healthy while every request returns HTTP 500.
An operations team manages a 12-instance virtual machine scale set behind a Standard Load Balancer and needs individual RDP access to each instance. They currently use an inbound NAT pool and have been told to modernise the configuration before it stops working. Which change is correct, and what is the deadline that matters?
After a hardening change, an application behind a public Standard Load Balancer returns nothing on its frontend IP, yet administrators can still reach each backend virtual machine over RDP through the load balancer's existing port-forwarding configuration. Which explanation best fits both observations?