Template stacks limitations

[mr.linus]

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

BUT

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?

[reaper]

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

[mr.linus]

guess I'll just make a feature request

[JohnUrbanek]

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.

TS_ACME_User

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

TS_ACME_Datacenter

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

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.

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

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.

[Remo]

@JohnUrbanek

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.

[RichaSB]

This worked for me. Thank you @JohnUrbanek 

[CosminM]

Hello,

You can do the following:

1. on "shared-template" create a LDAP Server profile and an Authentication Profile that use the LDAP Server Profile
2. on "FW1-template" create a Authentication Profile but configuring only the minimum info needed to activate OK button. That means that you will create a Auth Profile with THE SAME NAME as the one create on "shared template" and select only type as LDAP.
3. 
4. then on your "FW1-template" you can use it to authenticate admin users.
5. when you add these two templates into your stack, it will MERGE both configs