VM Series in Azure - Active/Passive or Active/Active

[jeromecarrier]

Hello

I have currently 1 firewall VM-Series deployed on Azure. We plan to deploy a second for HA. My question is : is-it recommanded to configure the cluster in Active/Passive mode ? Or to configure the 2 VM-Series as active FW with Azure Load Balancer (what is the risk to have assymetric trafic) ?

Regards

Jerome

[TomYoung]

Hi @jeromecarrier ,

This document specifies active/passive only -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClD9CAK.  It has a link to the specific instructions.  Active/active is not mentioned with no instructions.  So, active/passive is implicitly recommended.

This document -> https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resour... says on page 39, "Although you can configure high availability so that both firewalls are passing traffic, in the majority of deployments, the firewalls operate as an active/passive pair where only one firewall is passing traffic at a time."

Thanks,

Tom

[sthornton]

The majority of our customers run their firewalls all active.  Active-Passive is not recommended unless you have a specific case for it.  Please see the Azure Reference Architecture for details.  Utilizing the Azure Load Balancer and running the firewalls active is the recommendation.  The Azure Load Balancer maintains symmetry via its algorithm.  

https://www.paloaltonetworks.com/resources/reference-architectures/azure

[TomYoung]

Hi @sthornton ,

That's good information to know that your customers are doing active/active successfully.  I like active/active better for Azure, but I would like to see instruction docs and a recommendation from PANW.

Do you have configuration instructions for active/active?  The one I found is active/passive.  Also, my 2nd URL above is a document on the URL page you posted.  It does not recommend active/active.

Thanks,

Tom

[sthornton · Accepted solution]

Hi Tom.  I want to clarify something on the active/active.  This is done with the use of a native Azure Load Balancer acting as a front end device.  The firewalls both run active, both process traffic, have the full config, etc.  They do NOT however, share state as in a traditional A/P or A/A with an HA4 interface.  So this active-active is not stateful.  I just want to make sure that is clear so no expectations are missed.

Azure gives us a couple features to make this work.  First, we can route traffic to their load balancer, second is with the use of UDRs we can steer our traffic accordingly to said load balancer.  

In the link I posted in my previous reply, if you choose the Deployment Guide you can see how all of this done.  There are some templates available on GitHub as well if you want to spin it up and test.  If you need eval licenses I can ask someone to reach out.  Also, if you’d just like to have a meeting to discuss as well, your account team can make that happen.  If you don’t have one, we can get an SE to speak with you in more detail.  

Also, I’m happy to continue this discussion here and try to answer any other questions.

Enjoy the rest of the weekend.

[TomYoung]

Hi @sthornton ,

Excellent!  Thank you for pointing me to the specific reference.  So, it looks like the 1st URL I referenced above is not recommended any more.  The 2nd URL I posted is the same Deployment Guide you recommend.  This is what I quoted:  "Although you can configure high availability so that both firewalls are passing traffic, in the majority of deployments, the firewalls operate as an active/passive pair where only one firewall is passing traffic at a time."  These are the sentences immediately following:  "Unlike traditional implementations, this architecture achieves VM-Series resiliency in Azure through the use of native public cloud services. The benefits of configuring resiliency through native public cloud services instead of firewall high availability are faster failover and the ability to scale out the firewalls as needed. However, in a public cloud resiliency model, configuration and state information is not shared between firewalls."

I didn't read far enough!  Thank you, again.

Hi @jeromecarrier ,  Please mark @sthornton 's 2nd response as the solution.  That way other people that have the same question can jump straight to the answer.  Or please post if still want the asymmetric traffic question answered.

Thanks,

Tom

[jeromecarrier]

Hi

Thank you for your answer. So if I understand, the recommanded configuration is to deploy 2 VM-Series "standalone" (without HA configuration) and use Azure Load Balancer feature to route the trafic correctly on each firewall.

I plan to use our VM-Series in Azure with GlobalProtect to connect our users on the network with a vpn SSL. In this configuration, is-it possibleto provide a redundant solution to keep access to the newtwork even if a firewall reboots dûe to an upgrade version for example ? Or, if I restart FW1 for an upgrade version, all GlobalProtect SSL VPN connexions started on this firewall will be cut ? And what's happening for new connexion during the firewall reboots ?

Regards 

[TomYoung]

Hi @jeromecarrier ,

Yes, the recommendation in the Deployment Guide is to use the Azure Load Balancer for cloud services, as explained on page 40.  It provides faster failover and scale.

Since you plan to use Azure for GlobalProtect (I will abbreviate as GP), your questions are very valid.  I will answer them to the best of my knowledge:

1. A stateful solution for GP can be provided with the 1st URL I posted, deploying active/passive HA in Azure.  It is also linked in the Deployment Guide as an option.  This stateful solution should keep GP sessions intact during failover.
2. With the Azure Load Balancer, the GP sessions will be cut.  I know the GP client will try to reconnect on its own, but will probably require re-authentication.
3. The Azure Load Balancer detects NGFW failure by monitoring cloud services through each NGFW.  If you have an application that you can monitor, the the LB will detect the NGFW is down and not route new connections to it.  Otherwise, new connections may be routed to the down NGFW.

Thanks,

Tom

[aleksandar.astardzhiev]

Hi @jeromecarrier ,

If I may also add my personal opinion/experience.

One think to remember - there is no best practice when comes to cloud networking. You need to define your goals and find the setup that best suites your use case:

- Will you inspect Outbound traffic

- Will you inspect east-west (inter-vnet or inter subnet) traffic

- Will you inspect inbound traffic

- Will you have GlobalProtect

- Will you have IPsec tunnels terminated on the PAN FW

PAN high-availability (active/passive) will take between 2 and 5 minutes. This is because in case of failover the IP address needs to be transferred to the secondary member. In Azure (same is for AWS and other public clouds), FWs needs to instruct the cloud to do it. So basically when FWs detect issues and need to failover they will make some API calls to ask Azure to move the IP, which takes time.

When I said 2-5mins I am quoting the same document that @TomYoung and @sthornton  mentioned. For me this is too long for any normal TCP session to survive. For that reason I believe (not really tested, but almost certain) that GP will lose connection and will try to reconnect, while Azure is moving the IPs to the secondary member.

So although active/passive setup will be simpler from GP setup perspective (you will have single IP for GP portal and gateway), it may have cause short interruptions for your GP users in case of failover (like you mentioned for PanOS update).

As you can see here another user have consulted with Palo cloud consultant, who recommended to set GP directly to the public IPs for the firewalls. https://live.paloaltonetworks.com/t5/globalprotect-discussions/recommended-config-for-globalprotect-...

Which means you don't need external LB, only internal LB if you plan to route outbound traffic (from VMs to internet) over Palo FWs

On other hand I am big advocate for PAN FW + Azure Gateway Load Balancer. With combination of the above link I would suggest:

- Deploy two standalone PAN FWs

- Use internal Azure LB behind the PAN FWs which will be used by VMs for outbound traffic

- Use Gateway Load Balancer for any inbound traffic.

- Setup GP portal and gateway directly on the outside interface for each FW. Set your DNS for the GP portal to resolve to the two IPs. Set your GP portal config to assign two external GP gateway and put the two FW addresses.

[jeromecarrier]

Hi @aleksandar.astardzhiev 

Thank's for your comment. Regarding our VPN site 2 site between our on-prem and Azure, your recommandation is to create our VPN between our local site and the Azure VPN Gateway and forward the trafic to the Azure LB-->FW-->VM and not to create the VPN directly on the VM-Serie to avoid lost connection when I upgrade the first firewall in architecture with 2 VM-Series with LB ?

Regards 

[aleksandar.astardzhiev]

Hi @jeromecarrier ,

I personally prefer to use Azure VPN gateway and build the the tunnel between on-prem and VPN GW, instead of terminating it on the VM-Series FW. This will eliminate the complexity for handling redundant inbound traffic.

It would vouch for such setup instead of terminating the VPN on the FW.

The only benefit (IMHO) of terminating the VPN on the FW is to reduce the cost, which for us is not worth it. 

By the way you don't really have to route the traffic from VPN GW over VM-Series VM.

You most probably will use NGFW (Palo or other vendor) to terminate the on-prem side of the tunnel. Which means you already have a way to restrict/inspect traffic on-prem <--> cloud. But to achieve this you will need to add your on-prem IP range as separate route in the UDR (user defined route table) for each vnet/subnet. which means:

- Outbound traffic: default route pointing to internal LB and traffic flow is VM -> internal LB -> FW ->  Internet

- On-prem traffic: on-prem range route pointing to VPN GW. traffic flow would be VM -> VPN GW -> on-prem FW -> on-prem network
respecting opposite direction on-prem FW-> VPN GW -> VM

In our case we decided to route the on-prem traffic over VM-series firewall (on-prem FW -> VPN GW -> internal LB -> FW -> VM), because we wanted to control/restrict traffic with VM firewall. Mainly our idea was to use the Azure plug-in for Panorama. The plugin will monitor Azure tag and create ip-to-tag mapping, which will be used with dynamic groups and allow VMs automatically after deployment.

[jeromecarrier]

Hi @aleksandar.astardzhiev 

Why I saided Lan(OnPrem) --> FW (OnPrem) -->Azure VPN Gateway --> AzureLB-->FW VM-Series-->VM, it's to control all traffic to/from our servers in Azure via the VM Series Palo Alto.

[aleksandar.astardzhiev]

Hey @jeromecarrier ,

That is exactly our current setup.

The only problem with this setup it is hard to manage - you will need to allow same traffic on both firewalls.

That is why you can create "trust all" rule on one of the firewalls. For example on on-prem FW create "any on-prem to/from any azure, any port/app, allow". Then on the VM-series FW you can create specific rules and control the traffic only with one policy.

[jeromecarrier]

Hi @aleksandar.astardzhiev 

I would like to have your opinion. My architecture is similar than the below architecture provided by Palo Alto (without VPN gateway at the moment). But in the following configuration, if I understand, all traffic from On-Premisses network to App01 or App02 servers  is not controled  by the VM-Series (the default route from VPN Gateway is the private LB 10.110.0.21).

If I wan't to control all traffic from On-Premisses to our servers zones (10.112.0.0/16 or 10.113.0.0/16 VNet), I need to add 1 network interface on each VM-Series and add one LoadBalancer between or firewalls and the VPN Gateway ? So at the end, we will have 2 LB : 1xLB dedicated to the traffic between the Gateway and firewalls and 1xLB for the traffic between servers networks (10.112.0.0/16 or 10.113.0.0/16) and VM-Series firewall (10.110.0.4 & 10.110.0.5) ? Is-it correct ?

[aleksandar.astardzhiev]

Hi @jeromecarrier ,

Quite the opposite actually.

1. Traffic from on-prem will travel over the tunnel and reach VPN Gateway (VNG)

2. VNG needs to be associated with User Defined Routing table (UDR), which should have route for App1 and App2 Vnet ranges pointing to internal LB

3. Internal LB will select available FW and forward the traffic over the INSIDE interface

4. FW will receive this traffic, inspect it and should have route for AppX Vnets and on-prem pointing to INSIDE subnet gateway (which means traffic will route the traffic back from the same interface, therefor traffic will be intrazone)

5. Azure will forward the traffic to the peered AppX Vnet and the corresponding VM instance

6. When VM send a reply back it will take the default route in the UDR pointing again to internal LB

7. With the help of the Standard LB with "HA ports" enabled, LB will know that this packet belongs to existing session and route the traffic to the same firewall which processed the request packet.

8. FW will receive the packet match it with existing session, inspect it and route it INSIDE subnet gateway

9. Azure will forward the traffic to the VNG (checking the destination and route in the UDR for FW INSIDE subnet) and from there it is back into your on-prem

The picture you send above it one of the suggested approached by Palo Alto - to have separate firewall for East-West and Outbound/Inbound traffic. As you can imaging this could get quite expensive. The second option is the so called "common firewall"

Basically the same I explained above, but here they haven't put the detailed information for the UDRs.