Template stacks limitations

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Template stacks limitations

L4 Transporter

Hey all,

I think I am hitting a limitation on the template-stacks, but maybe there is a nice workaround that you guys can help me with...


Contrary to Device groups, which have "shared" objects, templates use stacks which is a little different.
The limitation to this seems to be that you can not reference a template value between different templates...

Simple example to explain what I mean:

  • create a "shared-template" and add a local admin user
  • create a "FW1-template" add some specific network interfaces
  • create a "FW2-template" add some specific network interfaces
  • create a "FW1-template-stack" which includes the FW1 and shared template => assign this to your FW-1
  • create a "FW2-template-stack" which includes the FW2 and shared template => assign this to your FW

=> if you commit; the device will receive its unique network interfaces + the shared admin user = this works and looks like template-stacking is the solution to all the "duplicate" objects between FW-templates



If we want to do something a bit more advanced (the following is just an example)

  • add an ldap profile to the "shared-template"
  • add an auth profile to the "shared-template" referencing to the ldap-profile above
  • add an admin user which is only allowed to login to FW1 (not FW2) => This means you would create the admin user in the "FW1-template" an not to the "shared-template".

=> HERE IS THE ISSUE: you can not select the ldap-auth-profile, because the auth-profile was created in another template (the "shared-template")


So you have to be sure that all the components that will ever use a template object will have to be configred within the same template. This limitation becomes difficult fast, because a lot of the template objects are linked ex: ldap profile -> auth-profile => admin users, but also: group-mapping, globalprotect config, etc... and a lot of these things will have different config on the devices.


Anybody had similar experiences? How did you work around them?


Cyber Elite
Cyber Elite

this contradicts the nature of 'shared' 🙂



::edit:: ok i see what you did there, youre not adding the user1 in the shared, but on the firewll

pre-compilation the templates are standalone and not 'aware' of eachother, so you can't build in one template what is defined in another


Tom Piens
PANgurus - SASE and Strata specialist; (co)managed services, VAR and consultancy

guess I'll just make a feature request

L1 Bithead

A very simple and yet practical example of this limitation and a workaround is with Interface Management Profiles.


Say I have three templates (I prefix my templates with "T-")


  • T-ACME-Baseline
  • T-ACME-User
  • T-ACME-Datacenter


From those three templates I build two template stacks (note that template stacks cannot have hyphens in their names, I use "TS_") and their constituent templates.



  • T-ACME-User
  • T-ACME-Baseline



  • T-ACME-Datacenter
  • T-ACME-Baseline


2018-05-16 21_59_57-Window.png


The "User" TS is assigned to the ficticious "User" firewall and the "Datacenter" TS to the fictitious "Datacenter" firewall.


Build an Interface Management Profile called "Ping-Only" in T-ACME-Baseline (which is a constituent T of both TS's). Build the Interface configuration in T-ACME-User and T-ACME-Datacenter.


From T-ACME-User and T-ACME-Datacenter this "Ping-Only" Interface Management Profile is not visible when building the Interfaces within these templates. However, from the Template Stacks themselves (TS_ACME_User and TS_ACME_Datacenter) "Ping-Only" is visible and can be applied.


When opening up an Interface from the Template Stack itself, the "Ping-Only" profile is present, but Panorama says the entire dialog box is Read Only and won't permit clicking OK. See screenshot below.


2018-05-16 22_26_31-Window.png


Lucky for us we can Override (note the Panorama Template selected is still the Template Stack).


2018-05-16 22_30_55-Window.png


After selecting Override the dialog box is no longer Read Only, "Ping-Only" profile is still visible, select it, click OK, Commit and Push.


Since the Override is within Panorama (and not a local firewall change), it will be unaffected by a "Force Template Values" push (good).


With that we are able to build a "Ping-Only" Interface Management Profile in a "Baseline" T, build our Interfaces in other T's, then apply the "Ping-Only" profile in the TS.


I have not tried the specific examples you mentioned in the post.


In summary, referencing a specific template's constructions directly in another template is not possible. However, constructions from a specific template can be combined with another specific template and actually applied using the Override function within the Template Stack.


The option to override values directly in the template stack is only available since PAN-OS 8.1. But even with this option this does not solve the example mentionned by @mr.linus. it is still not possible to reference opjects in one template which exist in another template. And back to the example with the ldap-adminuser: of course it is possible to create the ldap server and authenication profile in one base profile, but then you would have to configure the adminuser on every templatestack or at least some template stacks depending on your configuration. For other examples 8.1 solves the issue like the one with global protect: configure the server and auth profile in the base profile and then configure global protect in the template stack, like in your example. This way you can reference objects from templates that belong to thw template stack.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!