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

Migration approach from interface flow policy

Hi all,

im facing a migration from various vendors to checkpoint environment, and im considering some options for the policy migration. Considering that the actual vendor used the interface policy flow definition, i would like to ask you about some experiences you have had in such deplyments ¿

Have you tried replicating the interface-flow policy, using the security zones ? I though that it would be the easiest approach but im not sure if considering that its not the "native" approach for checkpoint policy, im not sure if that replication attempt would be the safest bet.

But on the other hand, with the security zones, and layers is .. tempting to say the least :-). Could you please share you experiences if you had any in migrations similar ? Any regrets on using this approach if you did it that way ?

Regards

Javier Sanchez

0 Kudos
9 Replies
Highlighted

Re: Migration approach from interface flow policy

at the moment with r77.30 I'm using this kind of approach , section for interface and a clean up rule for every section with the relative associated networks , connection to the "internet" are the last on on the policy set although someone can say I'm trashing securexl and hit mechanism

In r80 you will have a lot more flexibility for sure using zones and layers

0 Kudos
Highlighted
Employee++
Employee++

Re: Migration approach from interface flow policy

If you are addressing R80.10 migration, you can use our SmartMove tool.

It migrates Cisco ASA, Juniper JunosOS and ScreenOS configurations.

Robert.

0 Kudos
Highlighted

Re: Migration approach from interface flow policy

I've seen Security Zones in action for R80.10 and they are great tools for simplifying policies; using them does not eliminate the need to still configure anti-spoofing though.  This isn't really documented yet, but use of Security Zones in policies does not appear to have a negative impact on SecureXL for throughput acceleration & templating, and even works with new features such as column matching/early drop.  There are underlying mechanisms visible in R80.10 gateway that ensure all these features are not negatively impacted by the use of Security Zone objects.

Now if only we could use Security Zones in manual NAT rules....

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com
0 Kudos
Highlighted
Pearl

Re: Migration approach from interface flow policy

Tim,

Can you describe the use case for the security zones in the manual NAT rules?

If zones are applied to more than one gateway/cluster, I have trouble visualizing the benefits.

Thank you.

0 Kudos
Highlighted

Re: Migration approach from interface flow policy

The main reason I wish Security Zones were available in manual NAT rules is ease of converting NAT policies from Cisco (which uses interface pairs) or from other firewall vendors that use Security Zones in their NAT policies.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com
0 Kudos
Highlighted
Pearl

Re: Migration approach from interface flow policy

In this case having the ability to make nested security zones would be beneficial.

Local zones could be used in cases you are describing whereas "global" or "parent" zones could be used for multiple gateways. 

0 Kudos
Highlighted
Employee++
Employee++

Re: Migration approach from interface flow policy

You can create network group objects from the interface's routing table, and use them in manual NAT rules.

With one caution - if you have several interfaces with overlaping networks, you should use groups with exclusion instead...

Robert.

0 Kudos
Highlighted

Re: Migration approach from interface flow policy

I definitelly see benefits from having layers algo on the nat policy, hopefully we will see that feature during the R80 evolution.

By the way, i finally had to use the non optimized policy conversion from smartmove, the optimized one was not complete 😕

Regards

0 Kudos
Highlighted
Employee++
Employee++

Re: Migration approach from interface flow policy

Can you please elaborate on what was not complete?

Your input is valuable for our SmartMove tool to perform correctly.

Robert.

0 Kudos