However, we’d still suggest using templates for common system settings.Ī common issue that comes up is when template overrides come into play. Obviously Device Groups can and should be leveraged in these cases for the purpose of centrally managing policies and objects. Not using templates at all - For small environments that have Panorama and perhaps 2-3 firewalls, it isn’t uncommon to see templates unused.Also, it’s important to note that Panorama backs up the firewall local configuration every time a commit operation is performed. This includes interface and routing configuration, as well as High-Availability (HA) configuration. In this strategy, we recommend configuring the network settings locally on each firewall. Additionally, template stack heiarchies could be used if there are different baseline settings for different regions, or firewall use types. Of course there may be a different baseline template for data center firewalls versus branch office firewalls, and that’s ok.

It always makes sense to templatize these types of settings for the sake of consistency. A firewall fleet usually has common settings for things like SNMP, NTP, logon banner, administrator accounts, just to name a few. A template only used for managing common system settings - Generally we feel that this strategy works the best for most deployments.This strategy might work well for a retail environment, where the firewall at each location is very cookie-cutter and the variable options meet all of the requirements. However, there are limitations and not all parts of a template can use variables. The variables are primarily for network related config elements such as IP addresses, routing, VPN configuration, etc. The idea is that you can take a baseline template, clone it, make it part of a template stack, then define the unique variables at the stack level for a particular installation.

Template variables - Although not as common, it’s definitely an improvement over the first strategy above when properly executed.

This almost always leads into manageability and scale issues due to the number of templates being maintained. The issue here is that every firewall now has its own template which defeats the purpose of using templates because it just as much work (if not more) to manage. The firewalls are imported to Panorama using a config bundle import process.

A template per firewall to manage all device and network settings - Many times this is the end result when Panorama was introduced after existing firewalls were deployed.

There are a few template strategies that we encounter in the field: It’s much easier to build out with the right approach than have to rebuild it once already in production. The best time to plan a template strategy is at the time of a new deployment.

However, if not properly planned and executed it can lead to the opposite effect by introducing unnecessary complexity, additional deployment tasks, and the potential for issues down the road. Our customers often ask for improvements that make deploying or maintaining firewalls a more repeatable, consistent process. Palo Alto Networks Panorama is a great tool that enables organizations to manage and analyze many firewalls at scale.

Palo alto panorama