We hear from a lot of environments that struggle to decide on the right high availability architecture for Palo Alto firewalls in cloud environments, as it’s not as straightforward as traditional on-prem environments.

 

 

High Availability in Cloud Environments: Challenges and Considerations

One of the questions we hear a lot is whether a High Availability (HA) cluster is really needed. The cloud never goes down, right?
Well, the fact that cloud vendors have mechanism to deploy Virtual Machine (VM) clusters on separate hardware should answer that question. For Azure that feature is called Availability zones. Where you specify what VMs should be on different hardware to mitigate the risk of the VMs being impacted at the same time.

Another thing to consider are the upgrades of the Palo Alto VM-series firewalls themselves, with a cluster you can upgrade them one by one without impact. But with a standalone firewall you will need to find a maintenance window to as your entire cloud environment will be impacted (depending on the placement of the VM-series in your cloud environment).

 

Active-Passive vs. Active-Active Deployments in Azure: Pros and Cons

So, we’re going for a HA cluster. And most environments have a active-passive cluster on-prem, so we are doing that in the cloud as well. We could, but should we?
A general rule of thumb in regards of the cloud is doing exactly the same in the cloud like it’s done on-prem is not a good idea. So let’s discuss the active-passive and active-active deployments in Azure.

Some advantages of an active-passive HA setup are the familiarity of such a setup and the lack of extra complexity it introduces.
But the biggest downside of active-passive is how this works in the cloud. In on-prem environments a Palo Alto firewall does a failover by sending Gratuitous ARP messages so that the other network devices know when the IP addresses live.

Because Layer2 is not a thing in the cloud, Gratuitous Address Resolution Protocol (GARP) isn’t either. So a failover is done by doing Application Programming Interface (API) calls, that removes the Network Interface Card (NIC) from the active VM-series and attaches it to the other VM-series.
If you ever have done this action manually you known this process can take a while. That’s also the case when this is performed by API calls.

Putting a number on the failover time is difficult, as it’s not only depending on the load on the cloud itself, but also on the configuration. If you have a NIC with a public IP then it will take longer then moving a NIC without a public IP, for example.
In general, this takes between 30-90 seconds. But I have seen this going over 10 minutes. And when the NIC move is started, no traffic is received until the process is completed. So impacting your environment.

 

Active-Active Setup with Load Balancers: Session Sync and Config Sync Limitations

Let’s talk about the active-active setup next. This setup is not the same as a traditional active-active setup in an on-prem environment, active-active is achieved by adding multiple standalones VM-series firewalls behind a load balancer.
The Palo Alto Azure architecture guide describes it perfectly. “The benefits of configuring resiliency through native public cloud services instead of firewall high availability are 1)faster failover and 2) the ability to scale out the firewalls as needed.”
There are some downsides to this as well, as these are standalone firewalls there is 1)no session synchronization and 2)no config synchronization.

 

Evaluating Load Balancer Options: Exploring Web Application Gateway

The config synchronization can easily be achieved with a Panorama server. Which can be deployed in Azure or anywhere else where there’s network connectivity.
The session sync is a different story. HA Clustering (session sync over HA4) would be cool, but it’s not supported in public clouds.

So let’s think about what does have sessions? Indeed, the load balancer in front of the firewalls.
The goal is have the initial and return traffic passing the same load balancer. In that way the entire flow will be sent to the same firewall as the Azure Load Balancer will use it’s session table to send the return traffic to the same firewall.
The detail that’s often overlooked is the SAME load balancer (LB). Some deployments have a external load balancer and an internal one, where east-west traffic both initial and return traffic will be routed over the internal LB.
But when traffic from the external LB is load balanced to a firewall and routed to the server, the return traffic will be send to the internal load balancer and it won’t know that session. So the only solution here is source NAT. That way the return traffic will be routed to the translated IP of the firewall and not load balanced.

That’s why it’s good to evaluate other options besides the external load balancer, like the web application gateway.
Because the web application gateway is deployed in it’s own subnet, the routing can be manipulated towards the internal LB.

As the return traffic will pass the internal LB as well, Source Network Address Translation (SNAT) is not required. Do keep in mind that the zone will be same as the internal zone if you route the web application gateway like this.
And because the web application can’t handle all types of traffic, it won’t solve everything.

 

Introducing Cloud Next Generation Firewall (NGFW) for Azure: Advanced Security Functionality

A lot of options and lot of complexity, right? Enter Cloud Next Generation Firewall (NGFW) for Azure.
Palo Alto’s new Cloud NGFW for Azure released last week in preview (also available in AWS). It aims to mitigate all complexity while still protecting your Azure workloads with the best-in-class security.
Cloud NGFW for Azure is a managed cloud-native next-generation firewall service delivered by Palo Alto Networks on the Azure platform. Meaning the service is owned and managed by Palo Alto Networks themselves.

The service is built using the well-renowned Palo Alto Networks’ NGFW technology and provides advanced security functionality. This  includes App-ID, Advanced Threat Prevention, Advanced URL Filtering, file sandboxing (WildFire), and Domain Name System (DNS) Security.

 

 

Benefits of Cloud NGFW: Managed Service and Integration with Azure

So customers get both best-in-class security and an easy, managed cloud-native experience.

• Customers no longer have the operational overhead of managing the infrastructure, scaling, availability, resiliency, and software/content updates associated with a network virtual appliance solution.
• Cloud Security teams can now deploy this service with ease and speed at scale in their Azure environment by using the Azure Portal and Azure automation tools.
• Network Security teams have the flexibility to use Panorama for centralized security policy management and logging.
• Cloud NGFW seamlessly integrates with Azure services (e.g., Azure Portal, Azure Key Vault, Azure Log Analytics). These out-of-the-box integrations reduce the operational burden for security teams. They no longer need to maintain custom solutions or specialized expertise to provision and operationalize NGFW.

 

Feature Parity and Availability: What to Expect from Cloud NGFW

Is there a full feature parity with the VM-Series? Unfortunately not (yet). At launch on May 2nd 2023, Cloud NGFW for Azure will be integrated with Panorama. This with the majority of the VM-Series security functionalities included. There are some routing and advanced VM-Series features that are not supported today, such as BGP routing, VPN termination, and Global Protect.
If Cloud NGFW is managed through Panorama, Advanced Threat Prevention (ATP), Advanced URL Filtering (AURL), WildFire (WF), and DNS security are available.
If Cloud NGFW is managed through the Azure portal, Advanced Threat Prevention (ATP) and Advanced URL Filtering (AURL) are available.

 

 

Public Preview of Cloud NGFW for Azure: Support and Pricing Details

Cloud NGFW for Azure launched in Public Preview, what does that mean? During Public Preview, the service is fully supported by Palo Alto Networks and Microsoft Azure.
They will strive to meet our SLA commitment of 99.99%. But it is not guaranteed and no refunds will be provided in the event of an outage.
During the Public Preview period, Cloud NGFW is available at a 50% discount to the list price. When Cloud NGFW moves to General Availability (GA) (planned for Aug 2023). Then the SLA commitment will be in place and the price will change to the regular price.

 

Pricing and Cost Structure: Hourly Rate and Data Processing Charges

How is Cloud NGFW for Azure priced? Cloud NGFW for Azure is priced the same way as other Azure virtual networking resources – Per Hour plus Per GB of traffic.
With Cloud NGFW for Azure, customers pay an hourly rate for each Cloud NGFW resource. Data processing charges apply for each GB processed by the Cloud NGFW resource.

Customers can use additional security capabilities such as Advanced Threat Prevention and Advanced URL Filtering as an add-on to the Per Hour and Per GB prices. Additional information on (public offer) pricing can be found in the Cloud NGFW for Azure documentation .

 

Private Offer for Enhanced Pricing: Exploring Jarviss Services

Jarviss can provide a private offer in Azure with better pricing conditions for your company! And not only for the Cloud NGFW, but also for the VM-series firewalls, Prisma Cloud,…

 

Jarviss has extensive knowledge in Palo Alto Networks. If you are interested in learning more about these technologies.

Send us an email at info@jarviss.be or give us a call at +32 9 394 99 11.

 

Author: Dries De Cokere