People who follow my blog may probably know that I'm a big fan of Cisco ASA firewalls and I worked quite extensively with them. When I was first introduced to the Palo Alto firewalls, I was amazed at how easy it is to use the web GUI compare to the ASDM which I absolutely hate.
In my early Palo Alto days, I used to work with just a single HA firewall pair where all the management and configuration were done directly on the firewall - similar to how you configure an ASA via ASDM or CLI.
When I first started working with Panorama, I was struggling to understand device group and template concepts. There were nested device groups, device group hierarchy, templates, templates stacks etc.
After reading various documents and speaking to my colleagues, I managed to get a grasp of the core concepts. At last, I've decided to write a blog post on the concepts I learnt to help fellow engineers. The purpose of this blog post is to simplify the concepts and explain them in plain English.
Palo Alto firewall provides four tabs to configure various configuration elements that are Policies, Objects, Network and Device. When you manage a firewall through Panorama, you configure almost all the configuration elements via Panorama (except for the initial management IP configs) on those same four tabs.
To create an Address Object on the firewall directly, you would navigate to Objects > Addresses. If you were to create the object through Panorama, the process is exactly the same, you would navigate to Objects > Addresses but with a twist.
When you manage hundreds of firewalls via a single Panorama, how do you make changes just to a specific group of firewalls or even to a single firewall? Panorama uses Device Groups and Templates to group the devices based on functionality, geographic location or whatever method you prefer.
Device groups hold the configurations of managed firewalls that you find under the Policies and Objects tabs of a firewall web interface.
- You can add one or more firewalls to the same Device Group. When you push the changes from Panorama to the managed firewalls, each firewall in the device group receives all of the configuration (security rules, NAT rules, objects etc) you have configured in that device group.
- You can have more than one device group (of course), but a single firewall can only belong to one device group.
Device Group Hierarchy
Device groups are hierarchical, meaning the order you arrange them is very important. You can create a Device Group Hierarchy to nest device groups in a tree hierarchy of up to four levels.
A lower device group inherits settings from a higher device group. The shared device group is the highest of all, and the device groups you create will inherit any settings you place into the Shared device group. It doesn't take a genius to work out that anything included in the Shared group will automatically be included in the children's groups.
Please note that if you don't want to use the default Shared device group, you have the option to create a new device group at the top level. For example, you can create a device group called Global under the Shared device group and then create all the other device groups under the Global device group.
Device Group Strategy
Now that we understand what device groups are, how can we organize them? Well, it depends on what best fits your organization.
The most common strategies are based on geographic location or firewall functionality or both combined.
As you can see above, the first level (just below Shared) contains two parent device groups Data Centre and Branch Office. Within each parent device group, there are more additional groups based on functionality and geography location. The firewalls are then finally assigned to the appropriate device groups.
As I mentioned before, device groups lower in the hierarchy inherit configurations from the higher device groups. This reduces the number of duplicates you have within your policies and objects. You can put a configuration item in an upper device group, and all the groups below it will inherit that item.
For example, let's say we want all the firewalls to have a Security Rule that blocks access to Facebook. What we can do is, create the Security Rule in the Shared group, all groups below that one will inherit that rule.
Please refer to the below figure - Now let's say you want to create an Object that belongs to the Data Centre and not to the Branch Offices. To achieve this, you can create that object in the Data Centre device group, all groups below that one will inherit that object (AWS-VM and COLO)
For the purpose of this example, the following device groups were created. The firewalls were then added to the appropriate device groups as shown below.
- Shared (Default)
- Data Centre
- Branch Office
Templates hold the configurations that you find under the Network and Device tabs of a firewall’s web interface.
So, to make a change in one of those tabs in Panorama, you will first choose the correct Template, make the change and then finally push the changes to the firewalls.
Similar to a device group, you need to assign the managed firewalls to the appropriate Template (Template Stack to be precise)
A template stack is a mixture of one or more individual templates that you combine in a specific order.
- The order of the templates in a template stack is very important. The template at the top of the Stack has the highest priority if there are any overlapping configurations.
- You can use the same individual template in multiple template stacks. For example, you can use a template that contains global settings such as the DNS servers and NTP servers in multiple template stacks. Panorama combines all the individual configurations from individual templates within the stack and then pushes those configurations to the firewalls.
- Please note that each managed firewall can be assigned to only one template stack.
Template Stack Example
Let's assume we have the following requirements
- All the managed firewalls should use the same DNS server IPs.
- Interface IP and static routes are different for each firewall (of course)
- Administrator accounts are different for data centres and branch offices.
- Data centre firewalls use syslog whereas the branch office firewalls do not.
- AWS-VM firewalls use 169.254.169.123 as the NTP server whereas all the other firewalls use 192.168.15.12
We might want to start off by creating a global template that contains settings (DNS server for example) we want to apply to all firewalls regardless of their location.
The Administrator accounts are different for Data Centre and Branch Offices so, we will configure the accounts on their respective Templates. The Syslog server profile only needs to be configured under the Data Centre Template as the Branch Offices don't need it.
As you can see in the above diagram, we have 7 firewalls in total. Since we can only add the firewalls to a template stack, we will create 7 template stacks and add each of the firewalls into each one of the stacks. We will also need 7 templates to hold the unique configuration such as interface IP, and static routes that apply to each firewall (to overcome creating unique templates for each firewall, you can use Template Variables - more on this later)
For the NTP servers, we will come across a conflict which we will go through next.
Just to give a quick example, please see the below figure where the Syslog Server Profile is being created under the data-centre template. Since we are creating the profile under the data-centre template, the branch offices will not inherit the configuration.
As you can see below, the data-centre template has been added to the dc-01 template stack. The stack inherits the configuration from the templates so, the syslog Profile configuration is now part of the stack and will be pushed down to the firewall (DC-01)
When there is a conflict, Panorama will use the values from the template that we have placed higher in the template stack.
In the below figure, Panorama will use the value from the PA-VM template that has been placed higher in the stack.
Imagine now you have 100 firewalls to manage, does that mean I need to create 100 templates and template stacks? Well, the answer is no. What you can do is, instead of creating a unique template for each firewall, you can use something called Template Variables.
With template variables, instead of assigning a specific value within a unique template, you can create a template variable that represents those unique elements such as interface IP, static route etc. Template Variable is out of the scope of this blog post and I will try to cover this in an upcoming post.
Hope this article would have given some clarity around Device Groups and Templates. If you have any questions, please let me know in the comments.