Policy redesign after Juniper to Check Point conversion

[Alex_Sykes]

Hi,

We're in the process migrating from Juniper SRX to Check Point FWs (we have a combination of both currently).  For the policy conversion we're using SmartMove with the help of Check Point Profession Services.

Once the policy is converted, we want to change the policy again to a more 'traditional' CP type of policy my moving away from the zone-based policy the SRX uses.

Has anyone experience of doing this, and if so, can you share some tips on how you did it?

The reason we want to move away from zone-based polices is because of the sheer amount of policy you need to write in.  For example, if you have a host in Zone 1 and it needs access to hosts in Zones 2, 3, 4, 5 and 6, you need to write in 5 times the amount of policy as opposed to CP.

In addition, if we stick with the zone-based model, we'll have multiple different types of CP policy on our Mgmt platform and we want standardisation.

Any help you can off is appreciated.

Thanks

Alex

[Sorin_Gogean]

Hey,

I would recommend to have a look on the in-line layer rules format. (there are some youtube videos as well regarding that)

There you could have a similar approach with zones, like you had before, and run your rules based on source and in the below layer treat each destination. Just an thought.

If you could share a sketch on how your rule are now, maybe I can come up with other dumb ideeas.

Thank you and have a nice weekend,

[Alex_Sykes]

Hi @Sorin_Gogean and @the_rock 

Thanks for your replies.

In-line layers are something we already use in another CP policy and that's where I would like to get to. 

What's the best way to get away from the zone-based policy and convert to ordered layers, do you know?

Do we literally copy and paste the rules from zone1 to zone 2 (for example) and paste them into an in-line layer?  Do we need to remove the associated security zone in the Topology Settings on the gateway cluster?

The existing CP policies we have are a 'traditional' sequential policy and in-line layer policy on different gateways. Having zone-based will mean we have three different types of policy.

Many thanks,

Alex

[the_rock]

Yea, you can copy/ paste, thats fine, BUT...make sure after every change you make to verify the policy first, as it would tell you whats wrong (if anything). You have to keep in mind that parent rule of the inline layer has to make sense in order for all the "child" rules below it to work.

So, for example, what I do with customers is have them associate given interface to a zone and then create inline layer rule like this:

source -> given zone (external, internal, dmz...)

dst -> any

service -> any )or whatever you want in there)

vpn -> any

action -> create new layer and make sure to check url / app control option if you plan to use that feature inside the layer

[the_rock]

I agree with @Sorin_Gogean  , though I strongly recommend ordered layers.