GWLB cannot be used for east west inspection due to source IP replacement

Question

GWLB cannot be used for east west inspection due to source IP replacement

Chao, Oliver 0

Problem statement

Required capability

Preserve original source IP for transparent internal traffic inspection

Business impact

Healthcare / regulated workloads require a single inspection plane for north south and east west traffic

Ecosystem relevance

Required for Palo Alto / NVA bump in the wire designs

0 comments

2 answers

Your answer

Answer 1

Hello @ Chao, Oliver,

Thank for reaching out to Microsoft Q&A.

You’re right that if you front your NVAs with an Azure Standard Load Balancer (internal or public) and rely on its outbound rules, you’ll see SNAT applied, which replaces the original source IP. That SNAT behavior is baked into the load-balancing data path and blocks transparent east–west inspection.

What you want instead is the VXLAN-based pass-through that Gateway Load Balancer (GWLB) offers, because it preserves the client’s original source IP. Here’s how to get there:

Chain GWLB to your VMs’ NICs —not to a Standard Load Balancer front end

• In the GWLB overview docs you’ll see that you can “chain” the Gateway Load Balancer to a Standard NIC IP configuration. That means any traffic hitting the VM NIC is automatically steered through the GWLB + your NVA pool, and it returns with the original source IP intact.

• If you chain via a Standard Load Balancer instead, Azure applies SNAT on egress, so your NVAs only ever see the LB’s SNAT port, not the actual VM source IP.

Use UDRs (user-defined routes) for east–west flows

• In each subnet that hosts VMs you want inspected, add a 0.0.0.0/0 (or just your VNet CIDR) route pointing at the GWLB frontend as the next hop. That forces all cross-subnet traffic onto the GWLB chain.

• Because GWLB is a pass-through device, it VXLAN-encapsulates, sends to your NVAs, decapsulates, and returns to the VM—again preserving original source IPs.

Skip any outbound rules on a Standard Load Balancer

• If you also need north–south inspection, put your public traffic through GWLB in the same way—chain the public-facing Standard LB or NIC to the GWLB, not via any outbound rules that do SNAT.

• For purely internal traffic, you don’t need an Azure Load Balancer at all—you can just chain the GWLB to each NIC and rely on your UDRs.

Double-check NVA and VM settings

• Make sure IP forwarding is enabled on the NICs of your NVAs. • Verify the GWLB backend pool health probes are green.

• No NSG/UDR should break the return path—both directions must flow via the GWLB.

References

Gateway Load Balancer overview (chaining & source-IP preservation): https://learn.microsoft.com/azure/load-balancer/gateway-overview#configuration-and-supported-scenarios
Azure Load Balancer outbound rules & SNAT behavior: https://docs.microsoft.com/azure/load-balancer/load-balancer-outbound-connections#snatporttable

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 2

Gateway Load Balancer (GWLB) is designed for transparent service insertion for inbound/outbound (north–south) flows to workloads that are fronted by a public or internal Standard Load Balancer or public IP. It preserves the original source and destination IPs for those flows, but it cannot be used to insert NVAs into pure east–west traffic between Azure virtual machines.

For east–west inspection, the supported pattern is to place NVAs (or Azure Firewall / Cloud NGFW) in a hub VNet or Virtual WAN hub and steer traffic through them using routing (UDRs or Virtual WAN routing intent), not GWLB:

Hub-and-spoke with internal Load Balancer + UDRs
- Deploy NVAs in a dedicated subnet in the hub.
- Place an internal Load Balancer in front of the NVAs.
- Use user-defined routes (UDRs) on spoke subnets so that traffic between spokes or between on-premises and Azure is sent to the NVA ILB for inspection.
- This pattern supports east–west inspection and keeps traffic symmetric; the internal Load Balancer ensures both directions of a flow hit the same NVA instance.
Virtual WAN with Azure Firewall or Cloud NGFW
- In Virtual WAN, deploy Azure Firewall or a third-party NVA such as Palo Alto Networks Cloud NGFW in the virtual hub.
- Use routing intent or Virtual WAN routing policies so that VNet-to-VNet and VNet-to-on-premises traffic is routed via the firewall/NVA for east–west inspection.
- This provides a centralized inspection plane for private traffic (east–west) and can also handle north–south inspection.
Why GWLB cannot be used for east–west
- GWLB service chaining is supported for inbound traffic to a public load balancer, its return traffic, and outbound traffic from Azure.
- The platform explicitly does not support using GWLB to inject NVAs into east–west traffic between Azure virtual machines.
- For east–west, NVA insertion must be done via routing (UDRs/Virtual WAN) and, where needed, internal Load Balancers in front of the NVAs.

For regulated workloads that require a single inspection plane for both north–south and east–west traffic, the recommended approach is:

Use a hub-and-spoke or Virtual WAN architecture.
Centralize NVAs (including Palo Alto or other NGFWs) or Azure Firewall in the hub.
Use UDRs / Virtual WAN routing intent plus internal Load Balancers (for NVA HA) to steer both north–south and east–west flows through the same inspection plane, while preserving original source IPs at the NVA.

GWLB can complement this for north–south scenarios where transparent service insertion is needed for internet-facing workloads, but it cannot replace routing-based designs for east–west inspection.

References: