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 -
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.
I think what you describe is actually working now. If you configure zone a temlate applied to all your devices,then it will be pushed to all your firewalls.
The zone may not show the first time you use it in secuirty policy, but as long you copy and paste the exact name, it will show for future changes.
Then the config pushed to firewalls will be valid, even though zone has been
@jeremy.larsen Sorry, misread what you are trying to do.
Ineed this can be a feature request. The problem is that, 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.
So there will not be a way to "share" the zone, unless you have identical interfaces on each firewall.
You must have deleted your post. I was replying to it.
Yes I get that (intefaces applied to zone, bad wording on my part). I want to apply an interface to a zone in a different template basically. So you agree, feature request.
I just don't like having to create the same zone multiple times for every firewall. This allows for human error and broken consistency.
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).
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!