East-west traffic within azure single Vnet

L1 Bithead

East-west traffic within azure single Vnet

Regarding East-west traffic within azure single Vnet, in this Guide page 127 states


"Azure networking does not require the use of source NAT on the firewall to enforce

symmetry if both directions of the flow pass through the same Azure internal loadbalancer

front-end IP and backend pool. The private subnets have UDRs directing East/

West traffic to the firewall layer, so NAT is not required."



What I don’t understand if you don’t enable session persistence in LB setup (page:97) what forces the return traffic to be load balanced to the same firewall.

L4 Transporter

Re: East-west traffic within azure single Vnet

To clarify, persistence is not related to symmetry of the return traffic, but determines which firewall  packets will be sent to. In theory the return packets can bypass the firewall regardless of the persistence setting. You are asking a valid question though and this is how it was previously with the “basic” Azure load balancer. There used to be a requirement to always configure source NAT behind the firewall’s internal interface for East-West traffic, otherwise the return packets were sent directly to the originating server, bypassing the firewall and creating asymmetric traffic flow.


However sometime last year Azure introduced the “Standard” Load Balancer SKU, which fixed a lot of the issues with the basic SKU. One of them is that you no longer need to configure souce NAT and the load balancer takes care of the correct routing of packets, so they are sent to the correct firewall.


Also previously we had to configure “session perssistance” on the LB, otherwise different packets  of the same session could have been sent to different firewalls, which would have broken the session. Then  again in the Standard SKU, they introduce a concept of “HA Ports”, desinged exactly for high availability. One of its attributes is that load balancing is done per flow and not per packet, ensuring that all packets for a session will be sent to a single firewall.


"The load-balancing decision is made per flow. This action is based on the following five-tuple connection: source IP address, source port, destination IP address, destination port, and protocol. "



 Hope it makes sense. I did not explain it very well, but these are the reasons for no longer configuring persistence and source NAT.

L1 Bithead

Re: East-west traffic within azure single Vnet

Thank you for your reply and sorry for my late reaction.

Two more question in regard 

-If so why persistence still exist in standard LB? 

-What about the internal traffic (inside zone) going to on-premise (vpn zone) and there's internal LB for every zone? i see in the article that there's no coordination between the two LB and they are working independently hence no guarantee that the traffic will traverse the same firewall back and forth.  

L4 Transporter

Re: East-west traffic within azure single Vnet

@MalakIbrahimPersitance is not required only when you use the "HA ports" function. 

If you don't have HA Ports (which areonly for internal LB anyway), then you can balancing with or witout session persistance. 


You second question is regarding a different case: "Backhaul and Management Traffic"  and works differently to the "East-West Traffic".

As described in the guide you menitioned (p.13, p162), you will need to configure two way NAT to ensure the return traffic is sent to the correct firewall: 


" Because you configure the load balancer with two front-end IPs and two backend pools for backhaul traffic, the firewall applies source NAT in both directions—from backhaul to private subnets and from private subnets to backhaul. "


Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!