11-05-2021 08:59 AM
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).
