Interfaces based Polcies to Zone based Policies

[Esteban_Cardona]

Hi,

We migrated from R77.30 to R80.10.

Before we bought Check Point, we had Juniper SSG and Juniper SRX, and of course we used to use policy based on zones and not on interfaces.

Now R80.10 give us the chance to come back to zone based policies, and my questions are:

- Do you recommend to migrate to interface based policies to zone based policies ? What are the main benefits ? 

- If yes, Why ? Will this new zoning approach better in  performance ?

- Did anyone make this migration before ?

Thank you,

Esteban

[PhoneBoy]

If you've already made the switch to non-zone policies, I don't see a huge benefit to switching back to zone-based policies.

Zone-based policies do have a couple of limitations:

• NAT rules do not support use of Zone objects
• You still need to configure anti-spoofing on your gateways

I believe both of these are planned to be addressed in later releases.

[Esteban_Cardona]

Thank you very much for you answer Dameon !

Yes, I think that is a worthless effort make this change, but I thought that maybe exists some kind of performance explanation,

Thanks!

Esteban

[Timothy_Hall]

Hi Esteban,

I assume you are referring to gateway performance, both for throughput impact and policy evaluation. The short answer is that using Security Zones vs. using host/network/group objects doesn't make a noticeable difference in gateway performance, and I explicitly stated this in my book.  This is all based on my own research, and I'm sure if anything is incorrect someone from Check Point will be chiming in shortly.  🙂

Using Security Zones vs. network/host/group makes no difference as far as throughput performance. 

As far as policy evaluation overhead on the Firewall Worker cores, the Source and Destination Zone is always calculated for traffic anyway regardless of whether you are actually using Zone objects.  Security Zones also work just fine with SecureXL Accept Templates and the new Column-based policy matching.  I suppose if you have an extremely large group of objects in the source and/or destination of a policy layer rule Security Zones would provide a slight advantage as far as policy evaluation overhead, but even that potential gain is probably limited due to Column-based matching.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Esteban_Cardona]

Thank you Tim !

Very clear explanation,

[Timothy_Hall]

Sure thing, the main motivation for use of Security Zones right now is policy simplification.  When they hopefully become available for use in NAT policies though that will be a big deal and make things a lot easier.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Daniel_Kavan]

Hi,

I've seen a recommendation to use zones in the parent Inline layer.   Can you define new/customZones for a particular gateway? 

I'm trying to for example make a zone for a few email servers for smtp traffic for example.   My mail servers are in the internal zone, but why direct all smtp traffic to my internal zone to this inline rule?   As I'm tying this, I'm starting to convince myself I could have the destination as the internal zone, but it seems like such a large set.  I guess there is just the internal, DMZ and Intranet zones and you're limited to those.

Any other changes now, with Zones in R81?

[PhoneBoy]

You can create custom zones, yes.
However, I believe you can only assign one zone per interface.
In R81, zones can be used in the NAT rulebase. 

[Hugo_vd_Kooij]

In my R80.10 lab I use Zones on my main policy and use sub policies for any combination of them. So there is a DMZ to DMZ policy and an Internet to DMZ policy, .....