Feature Request: Nested Zones

[bascheew]

I'm not sure where to request features, so let me know if there is a better way to send this.

We would love the ability to nest zones inside other zones!  This would lower the number of policies required - especially in multi-tenant situations.  In the example below this would allow for incredible flexibility.

Zone - Client 1 Networks
   - Client 1, Network 1
   - Client 1, Network 2

Zone - Client 2 Networks
   - Client 2, Network 1
   - Client 2, Network 2

Zone - Guests
   - Guest, Network 1
   - Guest, Network 2

Zone - Clients
   - Client 1 Networks
   - Client 2 Networks

Zone - Untrusted
   - Clients
   - Guests

[Toshi_Esumi]

If a multi-tenant situation, I would recommend separating tenants by vdoms. Then they don't share routing-tables and policies.

[bascheew]

I agree with you, and in most cases we do use VDOMs. Thanks!

That doesn't mean that nested zones couldn't still be useful, that was just the first example that came to mind.  Here's an alternate use, but substitute any use case for nesting zones:

Zone DMZ
   -DMZ Network 1
   -DMZ Network 2

Zone Servers
   -Servers Network 1
   -Servers Network 2

Zone High Security
   -DMZ
   -Servers

[Toshi_Esumi]

Zone doesn't aggregate networks but interfaces. Do you have multiple groups of DMZ interfaces?

[bascheew]

When I put networks in my examples, I am referring to interfaces.  But yes, depending on the client, we often run into scenarios where there are many interfaces.   Some have common purposes, and others do not.

There are times we want to put policies on large groups of interfaces and other times when we want a subset of interfaces.

[emnoc]

Never seen any vendors with nested zones. PANW , nope.  CHKP,nope. CSCO, nope.  Forcepoint , nope.

An "interface" should be of ONE zone only , and zones provide separation. Are you confusing nested-groups? Maybe ?

Ken Felix

[bascheew]

Thanks for contributing to the discussion!

Nested groups are useful too, but that's not what I'm referring to.

Fortinet does many great things that other vendors don't do, so I don't think that alone is a good reason not to innovate. Maybe there is a good technical reason that many vendors don't do this, but I do believe that some of that is based on how they use zones.

With Fortinet, zones do two things.

[ol]

First they allow for an abstraction layer.  When policies are applied to zones instead of interfaces, the infrastructure can adapt and change without forklifting policies.  Need to change from layer 3 interfaces to a trunked interface with VLANs?  If your policies are on zones, then no problem!  Just disassociate from the zone, make your network changes and then re-associate with the zone.

Second, zones allow for grouping of interfaces.  When interfaces are grouped together, then policies can be applied to many interface in a single organized step.  This grouping is very powerful when you need to ensure that new interfaces have an exact set of policies.  A field tech who needs a new interface can simply add the interface to a zone that already has loads of policies that have been carefully created to meet company security demands.  The tech doesn't need to figure out what policies to add the interface to (and they don't need to copy any policies).  They just need to add it to the specified zone, and the security admin can rest easy knowing that everything iota of the company requirements are in place.[/ol]

Am I missing anything?  Does a zone do anything else besides these two things?

The challenge is that when an interface is added to a zone, it can no longer have unique policies applied to it because the interface itself can't be referenced for policies. Usually we group interfaces because the client indicates that the interface should have the same policies as other interfaces.  We tend to group by network classification.  But when the client calls back later and says the new network should behave like all other networks in that classification except for XYZ, then our grouping and organization breaks down.

How can we have the best of both worlds?  How can we allow for the powerful grouping of interfaces without sacrificing the ability to have the occasional unique policy for a single network?  Yes we can add multiple zones to policies, but what happens if the field tech misses a policy?  We'd love to minimize the "attack surface" of human error!

My proposal would be to allow interfaces to be added to zones and then to allow zones to be added to parent zones.  This way there could be hierarchy and would remove the limitations with the current model.

I have some real world examples that I'll gather, so that we can leave the theoretical world behind.  I'll post again when I have those ready.

Thanks everyone!

[emnoc]

Item#1 and item#2  are doable as is today in a zone concept for FortiOS. Not if you had a question in those two items but wanted to point that out.

 

it can no longer have unique policies applied to it because the interface itself can't be referenced for policies

That's the down fall with zones, once you decide on zones you can't do interface filter for a src/dst-intf, but you can still write specific rules as required.

The use of zones doesn't magically prevent you from writing rules that impact traffic from an interface or network level.

How can we allow for the powerful grouping of interfaces without sacrificing the ability to have the occasional unique policy for a single network?

Again, keep in mind traffic is only going to be allowed if you "allow" it. Firewalls don't magically allow all traffic to all interfaces in that zone-group unless you write a policy to allow it.

I'll try to demo  what I'm getting at;

zone == INSIDE

     members;   vlan10, 20, 30  ( networks 10.10.0.0/16 10.20.0.0/16 10.30.0.0/16 )

zone == OUTSIDE

     member;  wan1 wan2

I could  write a very simple policy that allows ALL of those members ;

     src-zone INSIDE

     dst-zone OUTSIDE

     src-addr all

     dst-addr all

     service http https

     action allow

     schedule always

      # that how a lot of fwadmin write such a rule which could be ideal or very much not, or total bad if some one add a new interface into INSIDE but didn't want that networks associated to existing rules for INSIDE--to--OUTSIDE zone.

or

If I  only wanted to allow 10.20.0.0/16 and not 10.10.x.x or 10.30.x.x, then I would need to adjust the rule to allow that traffic and just only that traffic.

     src-zone INSIDE

     dst-zone OUTSIDE

     src-addr  10.20.0.0/16

     dst-addr all

     service http https

     action allow

     schedule always

BOTH encompass the deployment of "zones", one is probably written much better or secured,  YMMV but the ideal of zone management  is demonstrated.

So determining what you need in rule set is critical , & when designing rules that uses zones and positioning of interfaces in a zone very critical and should be reviewed in depth.

Also to throw this out; vendors like CHKP and Forcepoint has an allowance for both zone and non-zone rules inject or mingled together in the rule-base. These rules allow for broad and fine crafting of traffic flows, but you still need to be careful in rules creations and where you use zones at.

So you can craft rules with  src/dst zones;  or even src-zone & dst address or even match statements similar to the following;

(  ( src-zone & src-address)   &&  ( dst-zone & dst-addr)  ) this is what fortios, jnpr,panw...... can already can do btw so this is nothing new here..

I still do not see a clear picture of a grouping of zones and the benefits. Send an FR to sales and see what they say. Most admins are using zones for the 1> wrong reasons or 2> deploying them incorrectly or 3> without a full understanding of the zone concepts, and this based on my 20+ years of observations with zone based firewalls.

So my final answer, everything you mention can be controlled with the degree of a fine-tooth comb or as loose as mane comb for a horse , within the current usage of zones. You just have to think it out and design the zones to meet the security INF needs.

Ken Felix

[bascheew]

I just realized that enabling the feature "Multiple Interface Policies" takes care of many of my problems!