Multiple trusted interfaces: multiple security zones?

[Anonymous]

  I'm going to take advantage of the collective wisdom and experience of the Community:

I like to consolidate interfaces into as few policy-classes as possible, to keep configs simple and have policy-classes neatly represent actual trust zones.  I know that you can use a separate policy-class for each interface, and many config examples from ADTRAN engineers and in technical documents seem to show a separate policy-class for each interface.

Are examples given with separate "trusted" policy-classes merely because it's arguably simpler to understand what's going on in those examples?  Post your thoughts--Do you see some other benefit from maintaining a security zone separation between trusted interfaces?

I'm taking for granted here that all of the private networks and interfaces are truly trusted in the wide-open sense.  Obviously, situations where some granularity is needed between departments, tenants or whatever would require the use of multiple policy-classes.  I'm thinking about typical small or medium companies where you might have some VLANs or a remote office connected with a T1.

[Anonymous]

@cj - I would agree that sometimes it is just easier to have multiple interfaces share security zones/policy-classes. Although there are several applications that *require* that different policy-classes/security zones be defined, for generic applications it is acceptable to have them shared between interfaces.

For me, I would prefer to have separate policy-classes defined if I am dealing with several interfaces simply because if I need to troubleshoot, it is easier for me to go through the policy-sessions to find the entry that I am looking for and to verify that traffic is being routed correctly.

- Noor

[Anonymous]

Thanks, Noor. Other than applications where there's just more than one trust zone (departments, VLANs, companies, etc.), what would be some common applications requiring separate policy-classes?

We're trying to standardize on our config approaches in my company. Your input is helpful for us to plan ahead and anticipate scenarios that we will encounter.

[Anonymous]

@cj - I would say most of these applications involve multiple WAN interfaces. Failover configurations, load balancing, and route-maps usually require that separate policy-classes/security zones be used since traffic will need to be NATted to different WAN IPs depending on which connection will be used. The separate policy-class/security zones allows the router to NAT traffic based on which interface will be sending the traffic out. Also, these WAN security zones/policy-sessions could very well need a different set of access rules and port forwards configured on each interface.

- Noor

[Anonymous]

@noor

I see. If I understand you, these would be good examples of the need for outside/untrusted interfaces to use discreet policy-classes. Do you think the need to separate is diminished for inside/private interfaces?

Thanks again for helping me think this through.

Chris

[Anonymous]

@cj - Its really a matter of personal preference and how you would like to set up your rules. However, besides the examples you gave and perhaps configuring a DMZ with a private IP and a private interface, I haven't ran into many applications where a separate trusted policy-session/security zones were necessarily needed.

Thanks,

Noor