Azure deployment. NAT rule assistance.

[S.Cantwell]

Howdy Group.

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 140.242.125.50 (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.

Please help.  😝

[mmclimans]

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.

1. Frontend IP Address. 
   • This is the address that is assigned to the public load balancer. This would be 140.242.125.50 in your example. 
2. Backend Pool
   • This is the "target" or "destination" of the load balancer.  This would be the VM-Series untrust interfaces.   
3. Load Balancing Rule
   • The load balancing rule assigns a frontend address to a backend pool.  You can enter the port that you want to allow (i.e. TCP/80).

The load balancer is just forwarding traffic from 140.242.125.50: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...