- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hi Guys.
I’m running tests on URL Filtering with a Check Point cluster running R81.20 with Jumbo Hotfix Take 99.
HTTPS Inspection is not enabled.
There is a rule inside an inline layer that blocks traffic categorized as Sex/pornography
When the cleanup rule of the inline layer is set to Drop, the site is blocked correctly
When the cleanup is set to Accept, the site loads successfully
The site in question is correctly categorized as Sex/pornography
QUIC traffic is blocked via a separate rule
Why is this site being blocked only when the inline layer's cleanup rule is set to Drop, even though it doesn’t match the rule above that should block it based on its category?
Thanks a lot
Does it happen with all pornography sites or just specific ones?
And if I understand you correctly, you ARE seeing the correct category when it’s dropped by the Cleanup rule, correct?
You might want to use fw up_execute on the gateway to see what rule(s) the traffic might be potentially matching.
Hi @PhoneBoy
Some websites are correctly categorized under the "Sex" and "Pornography" categories.
The inline layer is configured as follows:
RULE 1
Source: WK-LAB
Destination: Internet
Services: HTTPS and HTTP
Action: Inline Layer (this is the parent rule)
Inside the inline layer:
RULE 1.1
Source: WK-LAB
Destination: Internet
Services: Sex, Porn
Action: Drop
RULE 1.2
Source: WK-LAB
Destination: Internet
Services: Any
Action: Accept
Now, a few websites are correctly classified under the "Sex" and "Pornography" categories, so I would expect them to be blocked by Rule 1.1 and indeed, the SmartConsole logs show that these connections are being dropped by Rule 1.1.
However, the websites are still accessible in the browser, despite being dropped in the logs.
If I change the cleanup rule (Rule 1.2) from Accept to Drop, then the sites are no longer accessible which is expected behavior.
But when Rule 1.2 is set to Accept, the websites remain accessible, even though they are logged as being dropped by Rule 1.1.
This behavior is confusing and I cannot explain why it's happening.
In modern versions of web browsers, QUIC (UDP 443) is preferred, not HTTP/HTTPS (TCP 80/443).
We do not support filtering of QUIC traffic until R82, and I believe this also requires HTTPS Inspection,
In all other cases, QUIC should be explicitly dropped in your policy or you can expect to see results like this.
If QUIC traffic fails, browsers will fall back to using HTTPS.
Your top-level rule doesn't mention QUIC at all, which means the traffic is being allowed by another rule.
Yes, this is clear to me.
But beware that I made explicit a drop rule to the QUIC protocol, above the inline layer.
And not inside the inline layer.
I can only work off the information given, which didn't mention QUIC at all. 🙂
On your inline rules, change the logging to Extended.
This should show ALL the URLs accessed, some of which might be allowed.
If you can send me some working and non-working examples in PM, I can have a look.
However, I suspect a TAC case is probably where this is heading.
Check the following in SmartConsole -> Manage & Settings -> Blades -> Application control & URL filtering
- first check if categorize is enabled
- second check if website categorization mode is hold or background
Double check if this bug is relevant for you:
PRJ-57181, PRHF-36126 |
URL Filtering |
URL Filtering may not classify a site in a specific rare scenario when the Security Gateway is configured as a proxy. |
I think this site is not in gateway cache. GW is going to cloud and in the mean time the site is allowed. Does this makes sense?
Hey Buddy,
the gw does not use a proxy to go out on internet, i have a simple nat rule that says from the wk to go out on the internet natt it with the gw...
categorize is enabled
website categorization mode is hold
Ola bro,
That sounds like normal behavior. Technically, for example, what I do in my lab is this.
net layer, allow access from windows 11 machine behind cluster
urlf layer, block access to desired categories, then any any allow at the bottom
Traffic has to be ALLOWED on all the layers, thats the key.
Andy
Let me clarify that...traffic has to be allowed on all the ORDERED layers.
Try background and give it couple more tests
I treid in R82 environment, and ti's works.
there only one site that it's accessbile on chrome but not in edge...
Hey bro,
I will test this in the lab Sunday.
Andy
Hey brother,
Yes, keep me posted, i tried the behavior in R81.20 and R82, the url filtering work better in R82 there is no doubt
What TLS version do you observe for communication with this this site, is it using encrypted SNI?
Traffic inspection over QUIC or HTTP/3 is supported as of R82.
This future will also be implemented in R81.20??? I think that is precisely why it was not going
Don't believe it is currently planned.
To clarify R82 is working for you with or without HTTPS inspection?
Yes, some sites are blocked on the R82, but not on the R81.20.
Your answer is not clear, depending on which it is either there are other variables between the tests or you need to consult TAC to explain.
What’s not clear?
The rules used in R81.20 and R82 are identical, and the settings are the same...
In R82, websites are being blocked that were not blocked in R81.20 – using the same browser.
Is it possible to open a case for lab environments? I thought cases could only be opened for production environments..
I asked if HTTPS inspection was enabled in the case of R82 or not, thanks for clarifying.
Https inspection was not enabled in either lab.
you’re welcome brother
Thats EXACTLY how Im gonna test the lab.
Andy
Hey bro,
Sorry about the delay, just came back from a long trip, so did not get a chance to test sooner, apologies. You are 100% right, here are results of my tests.
R81.20 - 20 porn sites tested, only 10 blocked
R82 - same amount tested, ALL sites blocked
In either case, there was NO ssl inspection enabled.
Andy
Hey brother,
I'm happy to see that we've the same result!
No worries...I tested some other categories as well and result was more less the same.
Andy
what do you think may be the factor in this behavior?Did you happen to make any traffic captures about it?
Honestly, got no clue. I believe it could be that R82 has different "engine" if you will, for urlf / htpsi, but I never did any captures when testing this.
Andy
i got you, thk brother
No problem...if you need me to test anything else, let me know.
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
14 | |
12 | |
11 | |
9 | |
8 | |
7 | |
5 | |
5 | |
5 | |
5 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY