I have a newbie question and wanted to ask the group.
Maybe I am thinking too hard about it.
Customer wanted a FW load balancer on both sides… and this was the screen capture of the solution.
I have a nice easy question about incoming traffic and how it gets to its proper destination.
My question is surrounding NAT and the need to use it.
In a traditional FW, a session is created with a SA/DA pair, that hits the public interface of a FW, and the NAT rules show how the traffic will be evaluated and forwarded.
But my experience in Azure and with LB, and how traffic gets from point A to point B is confusing me.
Lets say… I have a web server at www.my company.com, that resolves to a public IP of 220.127.116.11 (some made up IP)
How does the traffic session get created. Walk me through the setup. What is doing the NAT, to get to the private server IP, where the server resides in Azure, on the internal LB.
Confusing pieces for me in Azure (limited experience). You can bind a public IP to a private IP (just like you manage the FW).
So, in this case, Azure “magic” knows when I hit the public IP of my FW, to send traffic to the mgmt. IP. This is perfect and makes sense.
Now… company.com goes to the public IP as I described above.
My customer believes the external LB will forward the request to the nic-1 of the FW (or in my case 10.5.30.4).
We set up NAT rule to fwd traffic hitting 10.5.30.4:443 to internal server of 10.5.1.4 (DG of 10.5.1.1 or what I call the Azure magic IP)
Traffic failed. Quite simply… as I understood it… my NAT rule did not translate my original src IP of 10.5.30.6 (test computer)
When the 10.5.1.4 server saw that the SA was on a different subnet, it fwd to its default gateway, and 10.5.1.1 fwd the packet (around the FW)… Azure magic.. asymmetric routing.
I did a DNAT where I did both a SNAT and a DNAT, so the traffic would respond back to my FW internal IP of 10.5.30.4, and the return traffic worked, and all is good.
But… it gets away from how/IF/why do I need a NAT rule (according to the customer)
My customer really thinks the external LB will fwd traffic to the backend pool (the nic-1 of either FW) and then the FW should have logic (NAT rule) to fwd it through the FW.
But I cannot get my head around… in Azure, not every single packet (from a public FQDN) would have a private IP of the PANW FW nic-1.
I am missing the logic of how we get the NAT rule defined.
To add complexity (maybe not….lol) is that I am using Panorama to manage both FWs, so now I have 2 devices in the same device group, with different IPs for nic-1… but…. Same NAT policy statement.
So, for example… if my nic-1 is 10.50.30.4 and 30.5, then this is how my NAT policy looks.
If my FW could be in Vwire mode, (which is what I think the customer believes.) then traffic from the external LB is fwd to the nic-1, which would automatically fwd to nic-2, which would fwd to the internal LB, to get to the web server in the backend pool.
But… that is not how it is… and I cannot find documentation (or have experience) on how it should be setup.
I do not know if you are still looking for a resolution, but I have placed answers to some of your questions below:
The public load balancer forwards the traffic to the VM-Series. The load balancer itself is comprised of 3 major components.
The load balancer is just forwarding traffic from 18.104.22.168:80 to the VM-Series untrust interfaces (private IP). When the VM-Series receives the request, the firewall DNATs the traffic to the internal address in Azure. We must also apply a dynami SNAT on the policy. This is required because the public load balancer does not maintain flow symmetry. The SNAT guarantee's synchronous responses for a given request.
This post may also answer your question on how to NAT inbound traffic from a public LB: https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/active-active-gateways-in-azure-a...
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!