Routing public websites via Palo in Azure?

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Routing public websites via Palo in Azure?

L4 Transporter

I have a pair of VM-300 in a load balancer sandwich configuration in Azure. An internal load balancer is on the inside and handles outbound traffic. An external load balancer is on the outside and is intended for inbound traffic from internet.  I can assign a public IP as the front end of the external load balancer. My first question - can a single external load balancer have multiple public IP front ends defined?


My second question concerns how traffic flows from an internet client to one of my backend servers. This is my understanding - please correct me if i am wrong:


The external interface of each of the two firewalls resides on a privately addressed subnet. Example: with fw1 being and fw2 being Each firewall has a default route to internet via Azure gw ip


The frontend of the ELB has a publicIP described as 'webserver1'. It has a backend pool called webserver1-pool. The real backend webserver is But that is not directly reachable from the LB. And we want the traffic to route via the firewalls.


If i want the LB to forward traffic via the vm-300 pair, then the backend pool members would have to be addresses on subnet yes? fw1 could have a secondary IP of associated with its external interface. It would then have a nat rule such that traffic destined for is destination natted to go to

Similarly, fw2 could have a secondary IP of associated with its external interface. It would then have a nat rule such that traffic destined for is destination natted to go to

Therefore the backend pool defined on the ELB would have members webserver1a and webserver1b


Would each firewall also have to source NAT the traffic so the real server's replies path correctly? Or will that just work?

Is there a cleaner way of doing this? having multiple NATs is a pain.  having to use the firewall's external interface subnet for all NATs is also awkward.



L4 Transporter

You are on the right track, you don't actually need secondary IPs of the Untrust interface.  We typically use Port Address Translation.  The Load Balancer Backend would be the firewall's Untrust Interface IP on a custom port such as 4431.  The load balancer rule would then map the front end IP on the standard port to the backend pool on the non-standard port.  The firewall performs both source and destination nat.  The original packet is the non-standard port traffic arriving on ETH1/1, the translated packet sources from Interface Eth1/2 and the destination is the actual application on the proper port.  We document this path in the reference architecture.


Its my understanding that the Azure external load balancer cannot do port address translation. So i'd need to use an Azure application gateway to do that?

EDIT: I am incorrect. The standard load balancer can use a different port for the backend traffic:

L0 Member

Hi, sorry to ingite an old thread. I am on the same path as the original post right now. My question is - is there a better way compared to doing port address translation to let a client access multiple backend webservers via the Azure load balancer and the PA firewalls ? Asking the client to remember port numbers for multiple different backend webservers seem clumsy. Could I get multiple public IPs assigned to the Azure load balancer each NAT-ted to unique IPs for the backend Webservers but routed via the firewalls ? How would I need to configure the firewall for that ? Thanks

  • 3 replies
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!