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

Rule set with track none, but still logging

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 ? 

0 Kudos
29 Replies
Bob_Zimmerman
Authority
Authority

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?

0 Kudos
Jacob_W
Contributor

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

0 Kudos
Timothy_Hall
Champion
Champion

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:

force_logging.png

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
the_rock
Legend
Legend

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

Andy

0 Kudos
Jacob_W
Contributor

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.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Jacob_W
Contributor

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:

Capture111.JPG

0 Kudos
the_rock
Legend
Legend

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

 

Andy

0 Kudos
Timothy_Hall
Champion
Champion

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:

track.png

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Jacob_W
Contributor

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
Legend
Legend

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
Contributor

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
Legend
Legend

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

0 Kudos
Jacob_W
Contributor

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

Thanks,

 

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
the_rock
Legend
Legend

I meant $FWDIR/lib 🙂

0 Kudos
Jacob_W
Contributor

There You go

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
Jacob_W
Contributor

Will do! thanks for the effort.

the_rock
Legend
Legend

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

0 Kudos
Jacob_W
Contributor

the_rock
Legend
Legend

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

0 Kudos
Jacob_W
Contributor

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

Thanks for assistance.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Timothy_Hall
Champion
Champion

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Timothy_Hall
Champion
Champion

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Ilya_Yusupov
Employee
Employee

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 

0 Kudos
erann
Contributor

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.

0 Kudos
dphonovation
Collaborator

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events