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
27 Replies
Bob_Zimmerman
Advisor

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

"Max Capture: Know Your Packets" Video Series
now available at http://www.maxpowerfirewalls.com
the_rock
Advisor

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
Advisor

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
Advisor

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.

"Max Capture: Know Your Packets" Video Series
now available at http://www.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
Advisor

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
Advisor

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
Advisor

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
Advisor

I meant $FWDIR/lib 🙂

0 Kudos
Jacob_W
Contributor

There You go

0 Kudos
the_rock
Advisor

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
Advisor

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
Advisor

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
Advisor

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

"Max Capture: Know Your Packets" Video Series
now available at http://www.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.

"Max Capture: Know Your Packets" Video Series
now available at http://www.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