topic Re: How to troubleshoot an app drop with the extended log options in Firewall and Security Management

How to troubleshoot an app drop with the extended log options

Tomer_Sole — Thu, 18 Jan 2018 20:51:05 GMT

Let's say you enabled an application, but traffic still gets dropped from some reason.

In the logs, all you see is hits on the any, any, drop rule, but this could come from many different users.

What you can do is to change the default logging setting in the Track column from "Log" to:

- "Extended Log": Adds application info to the logs.

- "Detailed Log": Adds resource and file to the logs.

You could also add the option to generate another Log Per Session, in addition to the usual log per connection.

Please note that each addition to a log gets adds a performance impact. This is why the defaults for a Track column are relevant to what you picked in a rule: Rules with application objects get the Extended Log by default, while rules with content awareness get the Detailed Log by default.

So if adding more log details to the highly hit cleanup rule can add performance to the log server, how can we overcome this?

a. You could apply that temporarily until fixing the problem, and then revert to "Log"

b. You could take that source traffic, make that an inline layer, and in the Drop rule of that inline layer which will probably get hit a lot less than the general policy, change the log setting. Afterwards you can undo the inlining or just keep it segmented as it is.

Let us know your feedback on this case.

Re: How to troubleshoot an app drop with the extended log options

Kaspars_Zibarts — Fri, 19 Jan 2018 10:11:51 GMT

You hit a nail on the head Tomer! It's been bugging me for a while but so far have had no time to dig into it. I noticed that some of our logs started reported sessions after R80.x upgrades even though we never specifically set them. And when i check the rule it's not ticked.

Do you have any more information about how R77.30 to R80.x should have treated this particular option. Also what are CPU impacts of all those options in more detail?

To give you example, this traffic is logged as "session"

but the rule is set to "none"!

Is this a SR candidate?

Re: How to troubleshoot an app drop with the extended log options

KennyManrique — Fri, 19 Jan 2018 13:32:38 GMT

Hello Kaspars,

Have you verify this solution regarding upgrade from R7X to R80.10: Tracking Objects are missing after upgrade to R80.10 (Track column in Access Policy) ?

Regards.

Re: How to troubleshoot an app drop with the extended log options

Vladimir — Fri, 19 Jan 2018 14:22:06 GMT

I believe, I've seen same behavior in straight R80.10 implementations as well, not only the upgrades.

Re: How to troubleshoot an app drop with the extended log options

Kaspars_Zibarts — Fri, 19 Jan 2018 18:49:01 GMT

Great - didn't see this SK before!. Bit late now And now that I actually spent whole 5mins (instead of whinging..) I found it set on Application layer. So even though we use it as a "plain" firewall, we must have messed around at some point and created this app rule. Or it came as default in R80. Not 100%