Palo Alto VM series on Microsoft Azure with a Azure load balancer failover?

[nikoolayy1]

As the Azure failover based on the plugin is much slower than the same failover in AWS as the Azure API is much slower I am wondering if I can use floating IP address and azure load balancer infront of it?

I have done the same for F5 BIG-IP devices and I know that the Azure Load balancer main pool can be the virtual machine local private ip addresses (as there will be Azure LB the public ip address will be attached to the azure lb frontend) and the azure load balancer rule can have another pool with a health monitor the floating IP address. Has someone done this? Maybe I will need to add also managment profile on the interfaces to open HTTPS for the health monitor and limit access only from the Azure Load balancer with network security group 🤔

Also I hear that the Azure API now is faster so maybe there is no need for this but I have no info.

https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/high-availability/set-up-activeactive-ha/...

[aleksandar.astardzhiev]

Hi @nikoolayy1 ,

I don't believe active/active is an option for Azure at all. Yes, you can use internal LB, but you will need to have  the two firewall running as standalone - without any session sync. This is actually what Palo Alto are suggesting in their Azure Reference Architecture.

If my understanding is correct you cannot have any kind of floating IP, because PAN rely on MAC and ARP to move this IP, while Azure and AWS native components does not actually use MACs.

I would say the following was a really good discussion about the same topic - https://live.paloaltonetworks.com/t5/vm-series-in-the-public-cloud/vm-series-in-azure-active-passive...

Cloud NGFW for Azure also sound really good - https://live.paloaltonetworks.com/t5/cloud-ngfw-for-azure/ct-p/Cloud-NGFW-for-Azure but I haven't look too much into details as I am afraid that the cost will be significatly higher.

[nikoolayy1]

Hello @aleksandar.astardzhiev , I know that for cloud environments GARP is not possible and this why the Plugin exists so that the pulic floating ip can be changed with API requests to the cloud environment. As the deployment is for Globalprotect VPN active/passive is selected and with floating ip addresses you can do similar thing by using the just one floating IP address as seen in https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/high-availability/set-up-activeactive-ha/... .

I was wondering to do something like I do for the F5 devices seen in https://github.com/F5Networks/f5-azure-arm-templates/blob/main/supported/failover/same-net/via-lb/3n... that uses the F5 virtual server objects that are active only on one device in HA pair, similar to the floating ip address but maybe my idea is a little non standard as most will use the Azure LB load balancing method and persistance, so that the same users go to the same firewall as in the discussion you mentioned, to make active/active without a floating ip address but I prefer to make certain that just one firewall is active.

The Palo Alto FW as a service could be nice but not from what I have checked for Globalprotect VPN deployments, also Prisma Access is still not on the table at this moment.

[aleksandar.astardzhiev]

Hi @nikoolayy1 ,

To be honest I didn't fully understand F5 documentation in the github link. I am curios how exactly you have managed to deploy active/passive F5? If you configure two VIPs (same IP) on the two F5 VE, how the failover is performed?

In my humble opinion since you are limited by the cloud the options are as follow:

- Anything related to GARP, ARP or virtual MACs is out of the question .There is no way to have same IP on two VE/NVA (network virtual appliance) and reply on ARP or GARP to point the traffic to the second unit during failover. Which leave you with:

- API calls to Azure and move the IP from one VM to another

- Azure Load Balancer with the two FWs as LB pool.

If you check some of the docs for "Cloud NGFW for Azure" it is actually using LB under the hood.

Some other vendors support session sync for standalone units, which is absolutely perfect when you use Azure LB for FW HA. Sadly PAN are still getting there. It looks like HA Clustering is step in that direction - https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/high-availability/ha-clustering-overview but currently it is not supported for public cloud.

I haven't really checked, but I wouldn't be surprised if Cloud NGFW for Azure wouldn't currently support GlobalProtect. But as I mentioned it is using LB sandwitch under the hood so it may be supported.

Regarding GlobalProtect HA in Azure - since I cannot imagine any other way to have HA active/passive in Azure (excluding the API calls), I still believe the best option is to

- run two standalone FWs

- with public IP assigned directly to VM

- Using DNS LB like traffic manager and perform health checks to direct user to primary FW and in case of issues DNS to resolve to secondary member.

- Not using Azure LB will allow you to use IPsec for GP, With LB you will must use SSL

One intersting issue I faced (well with AWS NLB, but it should be probably the same with Azure) - if you use LB for VPN, you may have issues with SAML

[nikoolayy1]

For the F5 setup you just use an Azure LB that checks which F5 device responds to health probes and sends traffic to it as the F5 are in HA the VS will be active just on one F5 device and if there is an issue it will just failover to the other F5 device (f5 have keepalive between them to detect issues) and after the F5 seconds the Azure LB will health probe will detect that the other F5 device responds to the probe and will forward traffic to it. Only GARP does not work in a cloud environment.

I think the same can be done with an F5 floating IP and thus Palo Alto floating I{ but maybe this needs to be tested. If Azure have fixed their API latency maybe there is no need for this and normal palo alto deployment without Azure LB will work but I need info if someone has how fast is the new API communication in Azure as I know they updated the API in Azure.