- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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.
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?
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.
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%

I believe, I've seen same behavior in straight R80.10 implementations as well, not only the upgrades.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 16 | |
| 15 | |
| 7 | |
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 4 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY