Rule set with track none, but still logging

[Jacob_W]

Hi,

I wanted to exclude some monitoring traffic from being logged across few gateways. It worked fine for R77.30 ones, but the one we have R80.40 is still logging for the rule although track is set to none. 

I tried recreating the rule, pushing policy, etc.

Any more suggestions ? 

[Bob_Zimmerman]

What module does the log show? Firewall, or something else?

If it shows firewall, is it being logged on the rule which says not to track the connections?

[Jacob_W]

Exactly, it shows firewall and rule number that is set with track -> none

[Timothy_Hall]

Was the Track column for the rule that is not supposed to be logging recently changed?  Is it possible that you are still seeing logs for connections that were present before the Track change to None was made? 

Otherwise check this setting in the Global Properties which will force logging for all rules even if their Track is set to None:

[the_rock]

EXCELLENT point Tim! I recall that being an issue once for one of my customers.

Andy

[Jacob_W]

Hi Tim,

The rule I have was created just for some traffic that we don't need logging. It was set to track -> none from beginning and I can still see logs for it. 

That setting You mentioned in global properties is missing in R80.40. I went through all the settings and I couldn't find it.

As I mentioned at the start this is the issue only on R80.40 gateway the others (R77.30) are working fine with track set to none.

[the_rock]

Thats odd...I just checked my R80.40 (3 of servers as a matter of fact) and all of them have that setting Tim mentioned.

Andy

[Jacob_W]

My bad! Sorry, I missed that. Was checking gateways itself instead of open global properties from Menu.

However it is unticked as per screen below:

[the_rock]

Weird...Tim might be correct, maybe it is indexing issue. Sorry man, TAC case might be next best option.

Andy

[Timothy_Hall]

Hmm that is a strange one, do you have TCP state logging enabled on the gateway under Additional Logging Information?

Check the advanced Track properties of the rule in question; even if Track is none, try making sure that both Log Generation boxes are also unchecked as shown here even though they are greyed out:

Also I'm wondering if this could be some kind of bizarre indexing issue, if you bring up ye olde SmartView Tracker do the unindexed logs for the rule with a Track of None show up there as well?

The traffic in question isn't HTTP is it?  There is a hidden variable called http_log_every_connection in GUIdbedit that is false by default.

Beyond that probably need to engage with TAC for a kernel debug out on the gateway to figure out why it is logging those.

[Jacob_W]

Hi,

I checked all what You wrote above and joy. 

Also logs are visible in samrtview tracker. 

Looks like TAC case is needed. 

Thanks for all the help. 

[the_rock]

Just a suggestion...maybe when you do open a TAC case, you should probably ask them to escalate it rather sooner than later, because to me personally, this is type of an issue where someone more senior might be required to look further into it.

[Jacob_W]

After a tshoot session with TAC we found that the issue is gone when we turn off global properties setting Log implied rules.

This is strange because in the logs we can clearly see that it is being logged by Firwall layer on the rule that has track set to none. 

TAC suggested to remove implied rule Accept ICMP requests and re-create it in the policy instead - from what was said this is because there was some change in R80.x in comparison to r77.30 (for which all works as expected).

In my opinion this is workaround not solution, but looks like nothing more we can do here. 

[the_rock]

I cant say Im surprised by that answer from TAC, but I agree, its not a solution and I dont think its a good workaround either. If you think about it logically, it really makes no sense at all why you would have to disable option for logging implied rules, when rule you created was manually done, so it certainly would not be applicable in your case. This really got me curious now, so I will try it in my lab to see the result...I have a feeling this could be a bug.

Andy

[Jacob_W]

I totally agree with You. If You'll need any details reach out to me.

Thanks,

[the_rock]

Just tried, same issue, this has to be a bug...by the way, can you send the content of $FWDIR/lob/implied_rules.def file on mgmt server? I would like to compare it to mine to see if there are any differences.

Andy

[the_rock]

I meant $FWDIR/lib 🙂

[Jacob_W]

There You go

[the_rock]

Just dumped it in compare tool and EXACTLY same like mine. Im on R80.40...I really think you should ask them to escalate that case and have R&D further check it, just my personal suggestion.

[Jacob_W]

Will do! thanks for the effort.

[the_rock]

Im not happy you have that issue, but at least Im glad I got the same problem, since it confirms the behavior!

[Jacob_W]

This is latest reply from TAC: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[the_rock]

I dont see any logic in that sk...I really dont. Just my personal opinion. 

[Jacob_W]

Agree with You. anyway way looks like it's the end of topic. 

Thanks for assistance.

[the_rock]

Its a total cop-out in even modifying that article to simply prove they know its a problem they cant fix. Totally unacceptable...

[Timothy_Hall]

Not sure if it will help at this point, but it is possible to enable "informative logging" for implied rules that might help in the future with diagnosing this type of logging issue:

sk110218: How to enable logging of informative implied rules on R80.10 Security Gateway

[Timothy_Hall]

Thanks for the follow-up. That is an interesting finding, wouldn't have guessed that checkbox would be the cause.

[Ilya_Yusupov]

hi @Jacob_W ,

According to your explanation you upgraded from R77.30 to R80.40 which means post upgrade you have 2 layers, one for Access Layer and one for APPI layer unless APPI blade was not enabled.

Can you please confirm if you had APPI blade enabled?

If it was enabled so this may explain why you see logs as the traffic is matched on 2 layers, if one of the layers have track log, you will get a log and it doesn't matter on implied rules.

please let me know if i understood this incorrectly.

Thanks,

Ilya 

[erann]

Hi, I have R81.10 and i'm experiencing the same issue, I've created a new policy layer for geo protection, and in the cleanup rule I changed tracked to NONE and still the logs are showing, I unchecked the "Log implied rules" option but it didn't help.

Any ideas?  this creates duplicate logging for me, since the connections are accepted twice, once in the geo layer and 2nd on the network access layer.

[dphonovation]

I'm in the same boat here. I don't want to log the cleanup rule on my top geopolicy layer.

I'm actually only getting 1 log, from the geopolicy layer. The next layer isn't logging (despite track being on). It starts logging if i remove the geopolicy layer.