topic Re: Palo Alto - Azure Interface DHCP in VM-Series in the Public Cloud

Palo Alto - Azure Interface DHCP

junior_r — Fri, 20 Apr 2018 01:46:26 GMT

Hi,

Are you guys using DHCP client on the interfaces or are you staticly assign IPs on PAN side?

Thanks

Re: Palo Alto - Azure Interface DHCP

jmeurer — Fri, 20 Apr 2018 01:50:03 GMT

DHCP is the way to go. It eases automated deployments and prevents any possible misconfiguration. If you statically assign and it does not match what was assigned on Azure side, the traffic will not flow.

Re: Palo Alto - Azure Interface DHCP

junior_r — Fri, 20 Apr 2018 01:58:35 GMT

What about when you assign multiple IPs to a interface for NAT purposes

Re: Palo Alto - Azure Interface DHCP

jmeurer — Fri, 20 Apr 2018 03:13:04 GMT

You still assign them on the Azure side. You then need to specify them direcdtly as either objects or directly in the security or NAT policy.

Re: Palo Alto - Azure Interface DHCP

kblackstone — Fri, 20 Apr 2018 13:17:59 GMT

There are 2 options here when you want to service multiple ips on a load balancer:

1) add additional ips to the firewall interface from within the azure portal AND you will have to switch to static on the firewall and manually add the first + additional ips that you want to service (they'll match the ips on the azure portal). dhcp only picks up the first address from the azure side in my experience (this may have changed so please double check).

#1 isn't the best option for ease of management

2) on the load balancer, enable floating ip on the rule and you will see the ip requested by the user come through to the firewall (even when having multiple front-side ips on the load balancer). you can then create corresponding nat and security rules based on that. using this method you can stay with dhcp on the firewall and do not need to add additional virtual ips from the azure portal side, nor on the firewall itself.

#2 is the better way to go.

Re: Palo Alto - Azure Interface DHCP

junior_r — Sat, 21 Apr 2018 00:44:32 GMT

Hi,

Would you configure this on Panorama and push to device using templae or just have DHCP configure on local PAN side.

PROs Panorama

* Can you push routes/interface(dhcp mode) to both devices at once

Cons

* If UDR messes up you cannot modify interface/route settings

Thanks

Re: Palo Alto - Azure Interface DHCP

kblackstone — Sat, 21 Apr 2018 01:58:01 GMT

The UDR is at the subnet level, so all firewalls put into those subnets would behave the same from the routing perspective if they have the same policy and virtual router configuration. I would bootstrap to get the interfaces up and in dhcp mode for both untrust and trust, and possibly the virtual router setup. Then let Panorama push down the policy and other information when the vm registers itself.

The way bootstrapping works within Azure, you could have multiple bootstrapping configuration options available behind different shares on the same disk.

Re: Palo Alto - Azure Interface DHCP

junior_r — Wed, 25 Apr 2018 17:19:01 GMT

Thanks would you keep the network interface and VR configuration on Panorama?

Re: Palo Alto - Azure Interface DHCP

kblackstone — Wed, 25 Apr 2018 18:11:33 GMT

The network interfaces I would add to the bootstrap.xml file. The VR configuration I would let Panorama push, along with the interface management piece if any load balancers are in play, and the larger security policy, etc..

Re: Palo Alto - Azure Interface DHCP

Harcharan — Fri, 06 Aug 2021 12:35:24 GMT

Referring to the solution- "#2 is the better way to go." Can we still go with this solution with below scenario.

Scenario- Active/Active Palo-alto Firewalls without Panorama managed and without HA between firewalls. The firewalls will be independent behind External and Internal Load Balancers.

Can we use floating IP on External Load Balancer to reflect on both Active Firewalls.

Will the Load Balancers still maintain the 5 tuple Hash and send packets to correct firewall of same session.

Because there will be same floating IP on both the Firewalls, how will External LB maintain the hash.