Panorama sharing Zones between Templates?

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

Panorama sharing Zones between Templates?

L4 Transporter

I'm pretty sure this is a feature request, but I'm throwing it out there in case anyone has info.

 

I would like to share zones between templates for my template stacking scheme.  Currently stacks look something like this - 

 

FIREWALL STACK

------------------------------

  1. Local_FW
  2. Local_FW_HA
  3. Location
  4. City
  5. Global

------------------------------

 

What I want to do is set my zones up in the Global template and have them accessible in my more localized templates.  This way I can create these zones only once, and use everywhere.  Currently I don't think this is possible.

9 REPLIES 9

L0 Member

@jeremy.larsenDid you solve this? I'm in the same position with a global template sending out zones to all my firewalls.

Just cant bind the firewall to the local interface & global template zone..

 

L1 Bithead

Same issue. Which is causing administrative headaches with template stack scheme design, just as the OP stated in their environment. 

 

If I am understanding @BatD's response " even though it looks the oposite in GUI, in the actuall XML file you are adding interfaces to a zone, rather than applying zone to an interface", they are saying that in the underlying firewall configuration (the XML), interfaces get added to zones, not the other way around. So, in the GUI, we can create or edit the zone and add interfaces to it (which I always thought was an odd way to do it), OR we can go to an interface and add it to a zone (more sense to me). But the later is a feature of the GUI for administrator convenience and not the way it actually works under the hood. So, when a zone exists in Template A, it's interface assignments also exist in Template A. When you create and manage interfaces in template B, only the zones from Template B will be available for use... because there is nothing in Template B (where the interface is configured) that can "assign it" to a zone since it is in the zone configuration itself where interface-to-zone assignments live. Wherever the zone exists, the interfaces assigned to it must also exist. 

 

So the crux of this boils down to the problem of having a zone that is configured to have member interfaces that don't exist, which I suppose is a different/worse problem than having a security policy with a non-existent zone as source/destination? How very vexing.

 

Certainly, I don't think I've ever met a firewall engineer or administrator who tended to thinks of zones having interfaces as part of defining that zone, rather than zone membership being a property of an interface that you would define in the interface. Is there any good reason for this being so? Like any security or technical justification for not doing it the other way? Very curious of how this is affected by deeper considerations. 

 

This reminds me of how VLAN assignments are handled in switches by different vendors. Some platforms have interfaces assigned to a VLAN only from the context of configuring that VLAN (you add the interface members of a VLAN as part of defining the VLAN), whereas other NOS's have you go into the interface and configure it's VLAN memberships and tagging as property of that interface. 

 

From an administrative point of view, though... it is a royal pain to have to keep zones and interfaces configured in the same templates and kind of defeats the point of stacking hierarchy. I think most people will tend to want to do just this: globally define all possible zones, then assign those zones when and where they are used (at lower levels). 

You can apply zones from another template if you configure the zone assignment of the interface from the template stack and override.

 

Tutorial: Referencing Template Configuration Within a Template Stack - YouTube

Thanks, I put off watching this video a couple times (vastly prefer text) but eventually did and it was exactly what I was looking for.

 

Edit to add: there are some real UI bugs in doing this.  In the template stack, I had to select the interface, click Override, and then it will pop up the interface settings like you could change some.  If you change the zone here and then click OK, it seems to not save it.  So might as well just leave it as None and click OK.  Then click on the interface name to re-open that settings panel, now change the zone to what you want, click OK, and observe that it actually did save that time.

 

And then if you accidentally choose the wrong one...wow it appears to be impossible to change it a second time, no matter what contortions I tried.  I had to do if from the CLI.  Delete the interface from the old zone, and set it to the new zone.  Examples:

delete template-stack Your-Template-Stack config devices localhost.localdomain vsys vsys1 zone Old-Zone network layer3 ethernet1/2

set template-stack Your-Template-Stack config devices localhost.localdomain vsys vsys1 zone New-Zone network layer3 ethernet 1/2

When you override here, it's also overriding the zone in the template stack.  You can change it there.

But yes the UI gets buggy.  I experience the same thing when clicking override the first time.  Open the window, press ok.  Then open the interface again and make your changes.

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!