Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Esteban_Cardona
Participant

Interfaces based Polcies to Zone based Policies

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

Labels (2)
8 Replies
PhoneBoy
Admin
Admin

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
Participant

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

0 Kudos
Timothy_Hall
Champion
Champion

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

"Max Capture: Know Your Packets" Video Series
now available at http://www.maxpowerfirewalls.com
Esteban_Cardona
Participant

Thank you Tim !

Very clear explanation,

0 Kudos
Timothy_Hall
Champion
Champion

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

"Max Capture: Know Your Packets" Video Series
now available at http://www.maxpowerfirewalls.com
0 Kudos
Daniel_Kavan
Advisor

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?

0 Kudos
PhoneBoy
Admin
Admin

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. 

0 Kudos
Hugo_vd_Kooij
Advisor

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, .....