- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
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!
We block anonymizers and can see that at least open.spotify.com, www.bing.com teams web etc are being blocked as they are tagged as anonymizers by URL categorization.
Had reports this has been happening since last Friday.
online Checkpoint URL checker shows the spotify one as what you would expect (entertainmnet etc.) and the IP's on it as uncategorized.
But the URL & App DB on my management server says it's up to date with a version of 141202403031347 created 03/03/2023 13:47 and won't update past that one.
Anyone else seeing similar issues?
I agree 100%, best to oppen TAC case and see what they come back with.
Andy
Have not noticed it in my lab, shows up fine. When in doubt, I always check below, its correct 100% of the time
Best,
Andy
I've been putting all the sites that the Anonymyzer rule has been catching into that classification site and they are all coming back green...so there are definitely issues.
This is the log I see when going to bing.com
Andy
Yes, I have heard this from multiple customers within the last week or so. Heard that they needed to whitelist Bing, Teams, Office, WebEX and more - all categorized as Anonymizers.
What version? We have many customers on R81.20 and no one reported this.
Best,
Andy
I think the majority of those with the problem are running R81.10
That could be why...I will try later in R81.10 lab as well.
Andy
Thanks for the info Morten, yes we are on R81.10 as well.
Just tried, yes, seems like it is an issue in R81.10. Btw @Jennifer_Wilson , https categorization is NOT replacement for ssl inspection, but regardless of the fact you dont have inspection turned on, even if you did, you would most likely have the same problem.
I would consider upgrading to R81.20, if you can.
Best,
Andy
Don't suppose you know if that would work if we upgraded just the management server? (leaving the gateways on R81.10)
I do know...it would NOT work, Im 100% positive. You need to upgrade the gateways, because upgrading the mgmt server only would not do much to change this behavior.
Best,
Andy
cheers, thanks for the confirmation it would not work.
No worries.
Andy
Is this test a new installation of R81.10 or an old one? Which Jumbo? I know it's much to ask, but does it help to clear the URLF-cache (sk64280)?
All good mate, questions are FREE ; - ). Its not new install, had it for some time.
Btw, tried that first actually and its latest jumbo.
Best,
Andy
We are seeing this on R81.20... I've disabled my anonymyzer rule for the time being until we see a solution.
I had not heard of any customers we have reporting this or had seen it in my lab and I do lots of ssl inspection testing in my eve-ng and also Azure lab.
Best,
Andy
As I see it, this is not related to HTTPS-inspection - I don't think that any of my customers that are seeing this issue uses HTTPS-inspection.
I think normal URLF/APCL is causing this.
You wont see this issue if you were using uhttps inspection. As I said to @Jennifer_Wilson , http categorization is sadly NOT a replacement for inspection feature.
Best,
Andy
Don't suppose you have the full list?
It's hard to figure out from our logs (lots of IP's rather than app names and we don't do SSL Decryption (do HTTPS Categprization))
I don't think there is a full list - I just heard that lenovo.com is now also an Anonymizer....
Best solution would be to open an Service Request. Not everyone can just upgrade to R81.20 overnight
I agree 100%, best to oppen TAC case and see what they come back with.
Andy
Just need to add that we've discovered that (AV sig/Defender etc.) updates to microsoft windows PCs are also being blocked because of this (ie Windows Updates, Windows 11 Updates) etc.
I hate to say this, but in your case, without even having inspection enabled, it would be totally pointless to add anything as bypass rules in the inspection policy, as that would only take effect if the feature is turned on.
Best,
Andy
I'm seeing this behaviour on my R81.20 appliance as well...so not just 81.10
Can you share some Log Details of these false positives?
Response from TAC is that it is a known issue, they are working on it. I've had apps that have worked for years suddenly being blocked...going out to internet and coming in from internet.
Is the anomyzer before the allow rule? I need to think ahead. Hope it will not hit us 🤪
Let us know what they provide you as a solution.
Best,
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
19 | |
7 | |
6 | |
5 | |
4 | |
4 | |
4 | |
2 | |
2 | |
2 |
Fri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAFri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY