- 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
Hello Community,
I recently saw a working environment, where an Inline Layer was used which had only one blade active: Application Control & URL Filtering. The firewall blade was not enabled on that layer.
In this layer, there were multiple rules. Most of them used Application Objects in Services & Application Column, but not all.
There were multiple rules in that layer, that are clearly a job for plain firewall blade:
These rules are working normally. They have matches like they should.
Now the question(s):
Is this a supported setup and working correctly by design?
Or is the customer just lucky that it works this way at the moment and I should tell him to enable firewall blade in that layer?
Any performance penalties?
Environment:
Gateway: R80.40 JHF T120
Management: R80.40 JHF T120
SmartConsole R80.40 Build 994000424
Thank you for your ideas 🙂
The Firewall checkbox in the layer's properties seems to be purely superficial and is only there to add the icon in the layer's content. I suggest CP would remove the checkbox and pre-populate each layer with the firewall icon in situations where this statement is true.
Cloning the policy containing Firewall+APCL/URLF+Content Awareness and unchecking the Firewall does not affect functionality.
As per my offline discussion on this subject with @Timothy_Hall , he has suggested calling the firewall functionality in APCL/URLF layers as "inferred" whereas I may suggest "inherent".
I believe FW layer should be enabled there.
It should be, yes, but I think even if you don't explicitly enable it, basic firewall rules will still work by design.
I believe thats expected behavior if you have rule like that...I also saw that with couple customers before.
The Firewall checkbox in the layer's properties seems to be purely superficial and is only there to add the icon in the layer's content. I suggest CP would remove the checkbox and pre-populate each layer with the firewall icon in situations where this statement is true.
Cloning the policy containing Firewall+APCL/URLF+Content Awareness and unchecking the Firewall does not affect functionality.
As per my offline discussion on this subject with @Timothy_Hall , he has suggested calling the firewall functionality in APCL/URLF layers as "inferred" whereas I may suggest "inherent".
If you actually think about this, it kinda makes sense that firewall rules still work in layers where it isn't specifically enabled.
You may need to exclude certain network segments from the advanced inspection done in these other blades.
The only way to do this...with firewall rules.
That said, I agree it could be represented better in the UI.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 12 | |
| 10 | |
| 9 | |
| 8 | |
| 6 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 |
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