Ordered Layers - Logging shows wrong Access Rule/Layer

[Nüüül]

Hi,

while testing ordered layers for a customer, i ran over a behaviour i cannot explain to myself - perhaps someone else can (?):

at top layer:

Accept communication "any to any with any service" but "tracking: none"

(cleanup rule of a small policy to block traffic from/to defined ips)

subordinated layer:

communication is allowed with tracking enabled (log)

my understanding is now, that in logs i get rulename and number of the access rule hit at the subordinated layer.. instead i get the cleanup allow rule of the top layer with tracking set to "none"

Looking into SmartTracker no informations regarding the matched rule is being given

Setup:

Virtual Management Server, virtual Check Point Gateway (GAiA) and physical smb device. all updated to las recent versions. behaviour can be seen with logs of both gateways

Someone has an idea what is wrong? or is this kind of an expected behaviour?

 

[_Val_]

It says "cleanup rule", and I assume, it is a clean-up rule of your sublayer. How does that sublayer look?

[Nüüül]

Hi Val,

"Cleanup rule" of first ordered layer is set to Accept Any any Tracking: none

("Cleanup Rule of "lyr_block")

There are two layers in this policy package

subordinated layer is meaning the "normal" policy rule set (pol_xyz) - where the communication is allowed (or not) with Tracking set to "log"

 for instance https://community.checkpoint.com/t5/image/serverpage/image-id/21986i7BAB34C1DF1DF157/image-size/medi...

 

[_Val_]

Hmm, this is a bit odd. Do I see correctly that you have two network policy layers in this security policy package? Why is that?

[Nüüül]

this is to address a requirement in being able to rapidly block communication to/from several networks if needed. if used in the same network policy layer you would run into policy verification errors, because those objects are used somewhere else in the policy. resolving these errors is not possible within the term "rapid"

Using an inline layer would workaround the policy verification error too, but is not possible here for now. so i went towards ordered layers

[Scott_Paisley]

I observed exactly this behaviour with the same layered policy approach for the same reason (block unwanted traffic) and opened a support ticket.

Support have advised this is expected behaviour, although I think it is a bug.

If you select the rule in the lower layer that the traffic hits and look at 'logs' at the bottom of the console window, it shows the traffic as hitting the rule on the upper layer. The 'logs' view in smartconsole has a predefined filter which is supposed to match 'current rule' but in this scenario it matches a different rule in a different layer...

EDIT: I forgot to add, the reason we decided to use a layered policy is that is how Playblocks are implemented, so if they display the same behaviour that will be a problem

[Scott_Paisley]

I think the behaviour may be different in R81.20 also

[Nüüül]

Hi Scott,

i am afraid not - i am on 81.20

an additional layer is also added, when using IOT Protect... 

nevertheless, if with or without it (IOT Protect / PlayBlocks), the behaviour is the same - logging shows the wrong rule. (which has logging disabled)

[Nüüül]

...when deleting the cleanup rule (policy is set to implicit accept), the only thing that changed is, logs are now shown with "implicit cleanup" as matched rule. 

SmartTracker does not show a matched rule, so SmartLog inserts the first matching rule for a communication? Someone knows a possibility, so SmartLog adds the "last matching" rule instead of "first"?