Migration approach from interface flow policy

[Javier_Sanchez]

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

[Marco_Valenti]

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

[Robert_Decker]

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

It migrates Cisco ASA, Juniper JunosOS and ScreenOS configurations.

Robert.

[Timothy_Hall]

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.

[Vladimir]

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.

[Timothy_Hall]

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.

[Vladimir]

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. 

[Robert_Decker]

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.

[Javier_Sanchez]

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

[Robert_Decker]

Can you please elaborate on what was not complete?

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

Robert.