How many firewalls justify Panorama

[fmurray]

Curious to see if there's some group concensus on how many firewalls an organization needs to have before the cost of Panorama is justified?  Right now we have two H.A. pairs (four total) and im not sure Panorama would make life that much easier.

Thanks for your input.

[jvalentine]

"It depends"

There are a handful of scenarios that would make Panorama interesting for your environment:

1.) Expanded log retention.  Most firewalls (excluding the 5200/7000 series) have log storage capabilities measured in the tens/hundreds of GB.  Panorama can scale to Terabytes.  While applicable to multiple firewalls, this could also be applicable to a single firewall / single pair.  Another option is to use a 3rd party syslog server to extend log retention.  Running reports & filtering logs in that syslog server may be cumbersome depending on which syslog server is used.  Panorama will give you the exact same reports & log viewing/filtering capabilities that the firewalls provide.    

2.) Centralized logging and reporting.  It can be very convenient to create a single report (from Panorama) that includes logs & events from multiple firewalls.  Even more beneficial if there are traffic flows that involve both pairs of firewalls...  A single log query could show results from both firewalls, which could make troubleshooting a little easier. 

3.) Centralized objects, policies, network, and device configuration.  If you find yourself creating address objects (or making any other changes) on both pairs of firewalls, and if it's something you do often, then Panorama could be beneficial in reducing the duplication of efforts between the two (or more) pairs of firewalls.  

[sam_miller]

You have to consider not just the number of firewalls, but how dynamic your environment is.

In a hub-and-spoke setup, where each spoke represents a branch office, and you have internet breakout at each local office, you'd want Panorama to ensure that the rulebase on each firewall is kept consistent. Last thing you want is staff at one location to be less secure than another, or able to access files/URLs that can't be accessed at another site

On the other hand, if the environment is quite statiuc (ie rulebase changes regyularly) then the administrative overheard of keeping the configurations identical may be low - or you may even want predominantly different configs on the different devices.

In that case Panorama is there primarily for centralised logging & reporting, and again you have to ask whether you want that. Do you have one IT dept. taking care of all devices? Then Panorama should be considered with a relatively low number of devices for the purposes of unified log searching, ACC lookups & consolidated reporting/alerts. On the other hand if you have 3 offices, each with their own PA and local engineer (say in a corporate owner/subsidiary environment) the unified approach may not be worth a lot to you.

Ultaimtely the calculation in terms of cost should come down to hours. How many hours is the IT department spending on splicing together logs, searching across multiple firewalls manually, repeating the same config change/update on all devices or any other kind of repetitive work on PANW devices. Multiply that by an average hourly figure and that's your savings to be had with Panorama.

Then it's just a matter of talking to your Sales Rep.

[BPry]

@fmurray,

As others have pointed out it really depends on a number of factors. When working in new enviroments or consulting it's more important for me to ask who's going to be managing these things and if they know how to work in the API. I've had enviroments that have Panorama with a handful of firewalls because they see it as being easier to manage, on the other hand I'm in an enviroment now that has dozens firewalls and we perform every action we would need Panorama for through the API. 

Overall, if you have any question that Panorama would actually be worth it then it likely isn't in your enviroment. A lot of people who utilize Panorama don't actually need it, and many don't take close to full advantage of what Panorama has to over. 

1) Log retention is a big part of why many people utilize Panorama. It often isn't worth it monetarly to build out a new syslog server enviroment if it isn't already setup. If the syslog server is already setup and the firewalls are simply another item that feed into it (and the syslog server in question can be easily queried) than this isn't much of an advantage for you. 

2) Centralized configuration is another big option. Depending on how much you utilize the API keeping the configuration in sync can be very easy. However if you aren't comfortable with the API or writing scripts then it would likely be better to simply utilize Panorama if you get to the point where you can't manage the firewalls individually. 

In general most of the features available to Panorama can be duplicated by the API and scripts; it's just how comfortable you are actually building it out. Reports can be built out and scheduled with the API; policies can be pushed out to all of your firewalls at once using the API; you can schedule commits via the API; essentially everything I want to use Panorama for is available through the API.

[BrianRa · Accepted solution]

Multiple people have covered the logging benefits so I won't go over that.

I agree with everyone above in first determining your environment.  Once you have figured that out you will be able to better determine if Panorama is correct for you.

*NOTE:  We have just upgraded Panorama to 8.0.x and have not had the time to see the improvements for templates.

Panorama is great for standardizing the Policies and Objects.  Nesting Device Groups works very well for these.  Creating a "Global Device Group" and putting things like GeoIP security rules (Pre Rule) and "Deny All" security rules (Post Rule) that effect every device in your network.  Then sub Device Groups for branch offices, facilities, and Primary/DR sites works great.  All objects can be standardized across all sites (as we have done) in the "Global Device Group" or broken out again in the sub groups.  This leaves very little for configuring on each firewall.  For example (short of our Primary and DR sites) we only have 3-5 security rules per site and maybe 3 NAT and PBF rules.

The biggest downside to the "Device Groups" section is the rule order.  All rules go as follows:

Global Pre Rule -> Subgroup Pre Rule -> Pushed Device Rule -> Local Device Rule -> Subgroup Post Rule -> Global Post Rule

We have had a couple instances where locally on the firewall we needed to put a rule between Global Pre Rule and Subgroup Pre Rule, this is not possible and we have had to get creative.

Panorama and Templates (Network and Device tabs) are a different story.  At this point (we were last on 7.1.x) nesting Templates just does not work.  The nice thing about templates is that you can create a generic 90% template and copy it to make a new devices template.  Then finish that last 10% configuration.  When changes do need to be made each template still needs to be updated so this does not save time in the sense it is across the board.  It does save time as there is only one web page logged into not a lot of individual devices (especially if remote connections are slow).  I've heard 8.0.x does a better job nesting Templates but until I test it I won't suggest it.

Pushing configurations is fairly easy from Panorama.  The configs are saved to Panorama then pushed to the devices.  On the push screen both Validating configs and Previewing changes are available.  I think once the firewalls are built the validating/previewing/pushing is one of the best time savers.  Doing it all from one place really does save time.

The oddities:

As much as you may have loved that show command it will no longer be nearly as useful on each firewall (see messages 9 & 11 on this thread for what I am talking about).

When Panorama and the firewall have a conflict the section will have to be overwritten on the local config.  This can be a pain to revert depending on how many components are overwritten to the local config.

There are rare occasions when the entire Panorama config will have to to be pulled into the local config.  This can also be painful to revert back into Panorama.  I guess with 8.0.x this is supposed to be easier as well.

Personally I find Panorama very useful and of all the firewall brands we vetted before picking Palo Alto it was the best all in one management tool.  Probably 30% of our choice in Palo Alto had to do with Panorama.

Hope that helps, if you have an questions please ping me.

Brian

[jsalmans]

@BrianRa I need to check in again on nested templates as well.  I started down that path when we initially had our 7.1.x Panorama but abandoned it.  My goal was to have one place to configure VPN client settings/networks instead of doing it on each of our active/active firewalls which doubles the work.

The problem, just like you described, was nested templates didn't really work.  The templates didn't seem to be able to "talk" to each other, therefore if you were trying to change something that has another setting as a dependancy you couldn't set it even though it was already set in a lower foundation template.

*edit* Just to add, as others have mentioned the unified logging is great as is the increased storage capability.  Be aware that, to increase log storage, you often have to increase CPU and/or memory as well (at least this is the case for the virtual Panorama appliance).  For the most part, configuration is generally easier as well.  We've got just two firewalls added to our Panorama appliance but I think it has been worth it.

[sam_miller]

Whilst you cant 'nest' templates in the same way as you can Device Groups, you can make use of Template Stacks.

In a typical corporate environment, with a single head office and multiple branches, we often use Template Stacks to mimic Device Group nesting. With a 'base' template, then a template that covers all branches (or all branches of a particular subsidiary), then finally the template for the device itself. When defining a template stack you define the order in which templates are applied, so it's easy enough to make it effectively 'nest'.

It's a little clunky compared to Device Groups, but it also has flexibility that Device Groups may not have, and with a bit of tweaking accomplishes the same goal

[BrianRa]

@jsalmanswe had a similar experience.  We started stacking/nesting them right off the bat and ended up deleting everything and just making a default template concept to copy.

@sam_millerI do agree they work differenty.  With Template stacks the config priority goes to the farthest down the chain.  Device Groups are the opposite in the sense that whatever is configured Globaly takes priority.

Another interesting thing to note is that the Device Groups and Templates are developed by different groups.  I would guess the Device Group developers are more of the CheckPoint experienced devs and the Template group are more the Juniper devs.