Working with Security Zones (internal and local zones)

[Vanesa_Benito_O]

Hi!

I hope someone can help me to resolve a little doubt

This is my first time working with security zones. Yesterday I performed a migration from Juniper to checkpoint.
So, I tryed to create the same security zone. During the intervention i have observed every policy create from the Zone A to the same Zone A doesnt match any sub-policy rules althrouh We have defined a sub-policy Any Any Allow.

when i take a look to the logs I have observed every traffic from one interface to the same interface are tagged with the security zones internal and local.

This is by design for any reason? This zones appear always when the traffic came from the one interface with destination the same interface?

Thank you!

[Pedro_Espindola]

I think InternalZone to Local means it is coming from the internal zone to the gateway itself.

When you say sub-policy, do you mean inline layers?

It makes no sense to use inline layers with "from any to any" rules, unless it is the Clean Up rule. These rules should be more specific than the mother rule. They should include sources and destinations that are comprised inside the InternalZone or the InternalZone object itself.

[Meital_Natanson]

Hi,

If I understand correctly - you put the same security zone object in the source and destination column.

Which interfaces you connected to that object? only 1 interface (is it a span port interface)? Or more than 1 interface?

What is the traffic you expect to be matched on this rule? Is it traffic that comes and goes out from the interfaces you connected to the security zone object?

If the traffic, for example, only comes from the internal interface but directed to the GW it won't be matched on the rule you defined....

You can send me more details on your policy configuration and I'll be happy to help you debugging this case.

(meitalna@checkpoint.com) 

Thanks,

Meital

[Vanesa_Benito_O]

Hi Meital,

Thank you for your answer, i try to answer your questions:

1. YES I put the same security zone object in the source and destination column.

2. Which interfaces you connected to that object? Just one interface, is the LAN interface.

3. What is the traffic you expect to be matched on this rule? Is it traffic that comes and goes out from the interfaces you connected to the security zone object?

For example, I defined the eth1-- Security Zone A - Network 172.18.0.0/16

If I have for example a monitoring system with ip 172.18.0.1, and this monitorization have to monitored the firewalls' VIP (172.18.0.2), so I expected the policy was:

From Zone A to Zone A

Rule1.1 -- Src 172.18.0.1 Dst 172.18.0.2 Service Accept

But in the checkpoint, I saw this specific log was from Internal Zone to Local, so the traffic didn`t match the rule1.1, like you have said me.

This traffic started to work when I created the rule without the security zone filter. In this case I understand the acces to the gateway itself is defined like zone local or internal, but this case is extended to every virtual ip published in the gateway too right?

Also, I saw some traffic from a Zone A to Zone B didnt work either, for the same reason, the zone was identify like internal in source and destination.

I really want if it's possible to know in which cases the checkpoint defined one zone as internal or local.

Thank you!

[Meital_Natanson]

Hi Vanesa,

In general - security zones match is done based on the interface the traffic came into the GW, and the interface it's going out (decided by the interfces definition and the routing table).

Can you please send me more details to my mail? meitalna@checkpoint.com 

I would like to see the entire interfaces definition, the routing table on the GW, the zones definition and the log you get.

And help you to debug your case.

Thanks,

Meital

[Robert_Decker]

Meital, Vanesa,

Please keep this post updated with your findings.

The information may be very valuable for others as well.

Robert.

[Beja]

hi there!

Meital, you said: " (decided by the interfces definition and the routing table)."

What about PBR? I meant, if traffic lets the firewall due a Policy Base Routing, security zone won't be defined such as we expect.

Routing would send thru Internet1Zone but PBR (it has preference regard to route table) send to Internet2Zone --> Result destination zone will be Internet1Zone although traffic goes out thru Internet2Zone.

Regards.

[Robert_Decker]

Hi Vanesa,

How did you perform the migration - manually or by our SmartMove tool?

Robert.

[Vanesa_Benito_O]

HI Robert

With smartmove tool

[Robert_Decker]

Great!

If you have few minutes, I'll be glad for some feedback on this tool.

Did it really reduce the migration time and effort?

Was it easy to use and understand the process and the reports?

Did the zones based policy layers creation confuse you?

Do you have any comments/suggestions/improvements on the tool?

Thanks,

Robert.

[Vanesa_Benito_O]

Hi Robert,

1. Did it really reduce the migration time and effort?

Of course the tool is very helpfully to reduce the migration effort. Every objects and group are easly migrated.

2. Was it easy to use and understand the process and the reports? Its very easy to use the tool, but in my case for example when i tryed to check the option Convert NAT configuration, I was not able to get the converted configuration. Its seems there is some kind of incompatibility with the Juniper configuration, but the reported error was not very useful to understand why the smartmove cannot convert the Juniper's Nats to checkpoint's nat. FInally I had to uncheck the Convert NAT configuration option and configure the NAT rules manually.

Did the zones based policy layers creation confuse you? No, its easy to understand it.

Do you have any comments/suggestions/improvements on the tool?

Yes I have some suggestion in the way the tool defines the policy in checkpoint

1. When one policy have more than one service defined in Juniper, the smartmove tool create a group with every ports defined in the rule, so this increase the number of service group defined in the Checkpoint and is less visual than you add a list of services in the rule itself.
2. Intead of create Clean-up-rules inside of each layer policy like inline policy layers. why dont use the default action in each layer? I dont know if you understand what I mean...
3. The last thing, is the policies defined in Juniper from one zone to the same, if in Checkpoint the concept is different and this traffic is defined as internal zone, then why smartmove dont migrate this like a simple access rule?

It's just my opinion, but the tool works fine, except the NAT issue.

Thank you,

Regards

[PhoneBoy]

The problem with the default action with a given layer is that any traffic matching it does not log.

Since it's generally best practice to log your catch-all rule, we add it.

If you don't want it, you can always remove it.

SmartMove can ease the process of migrating to Check Point.

That said, it's always a good idea to review the results and make minor tweaks as needed.

[Robert_Decker]

Vanesa, thank you for your valuable feedback.

Please paste here the NAT conversion error, so that I can improve and rephrase it to be more informative.

Regarding your comments:

1. Can you please provide an example from the configuration of a policy rule with the ports and how it is converted to Check Point as a group of services so that I can analyze it?

2. The default policy action from Juniper configuration is used as a default action of a cleanup rule - either accept or drop. If default action is not defined, drop is used. This cleanup rule is always applied per each inline layer and at the end of a rulebase.

3. Regarding the zone to same zone flow, I'll check and inform you.

Thanks a lot.

Robert.

[Vanesa_Benito_O]

Of course,

Below, you can see the nat conversion error:

I'm sorry, I dont know why the message appear in spanish, the meaning is: "the key proportioned didn't find in the dictionary". Its seems like a library issue

Example of ports configuration

Its not a issue, its just cosmetical, because you can`t see in one sight the purpose of the ruleif there are some many ports in the rule, you have to open the group object to see what services are you accepting. Its just my perception

And here an example of the kind of groups services created in Checkpoint

With that definition, the smartmove create a service group for each service combination find in the configuration, the policy of this migration it wasn't too big, just around 200 policy, but I have worked with a very long policy layer where this could be uncomfortable, but works fine!

Thank you!!

Vanesa