East-west traffic within azure single Vnet

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

East-west traffic within azure single Vnet

L1 Bithead

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.

1 accepted solution

Accepted Solutions

L4 Transporter

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. "

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ha-ports-overview

 

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

View solution in original post

4 REPLIES 4

L4 Transporter

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. "

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ha-ports-overview

 

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

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.  

@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. "

 

L1 Bithead

Hi, we have deployed Palo-alto firewalls on Azure and a Standard Internal Load Balancer with single front-end IP and single backend pool, does LB maintain session state if -

(1) communication is sourced from Azure VNET destined to On-premise ?

(2) communication is sourced from On-premise destined to Azure VNET ?

 

We don't have a Virtual Network Gateway deployed instead we have a Cisco vRouter in Azure VNET that has GRE tunnel to on-premise, so for on-premise communication we are routing all traffic (after firewall inspection) to Cisco vRouter which further forwards the traffic to on-premise.

 

I have read in guide (page 56, Securing Application in Azure Reference Architeccture Guide (paloaltonetworks.com)"If the destination traffic is within the Azure VNet, then the load balancer maintains session state to ensure that return traffic to the resource enters through the firewall that processed the outgoing traffic. If the same front end and back-end pool of the load balancer see both directions of the traffic flow, the load balancer maintains the session state. For destinations outside the VNet, the firewall must translate the source IP address to the IP address of the egress interface. Without this source NAT, routing might send the return traffic to a different firewall."

 

Request guidance if source NAT is needed or not.

  • 1 accepted solution
  • 10264 Views
  • 4 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!