- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello Checkmates!
I'm in this unusual dilemma right after migrating to a 2-tier firewall setup. Before when everything is on separate HA instances, everything is working as intended (This was all working from when I started the setup from R80.10 up until R80.40 before we did the activity). Now that everything is running on R81.10, for some reason, categories are not working. Thinking that it might be due to the fact that we have an external firewall that only handles DMZ traffic, I confirmed it by creating a custom application and creating a policy for it. The custom application works for Microsoft Edge, and Mozilla Firefox, but not on Chrome.
Now if everything is working as it should be, it would be blocked by policy 44.2, instead on 44.3 but that's not the case. When I tried to use the HTTPS inspection, user experience is really bad that it would take around a minute or so to just open google.com, and even then, porn sites aren't blocked at all by category. (Policies are currently disabled after testing)
Now I would like your input if the behavior is due to the firewall design being 2-tier? If so do I still need to configure blocking policies on the external NGFW pair? I really remember before on the R80 days that its as easy as clicking 1 2 3, but right now for some reason its not working as it should be.
I'll attach configuration screenshots that might help.
Thanks for the help!
Looks like you have a clean R81.10 without any Jumbo take on it.
Would recommend to upgrade the Jumbo asap:
https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/R81.10/Introduction.htm
Could you run Chrome without HTTP2? -> https://my.f5.com/manage/s/article/K000092500
Let me know results. If positive upgrade to take 158 if not pick GA take 156.
Hello!
I just want to update regarding this, apologies for the delayed response as after this was fixed, activities ramped up.
After the JHF installation, and adding internet connectivity to the internal firewall, the category blocking is now working as intended.
Thanks to you and to everyone in this thread who helped chip in information regarding this.
For the reference of everyone, here's the log entries for the aforementioned working 44.3 policy:
If you are not using HTTPS inspection you should atleast do the light version of it.
Is this enabled? In Application & Url Filtering Settings under Url Filtering -> Categorize HTTPS websites.
Hello @Lesley ,
Yes, it is configured as you mentioned, but even then, the behavior's the same. I can block YouTube as per corporate policy, but not porn sites.
So to make summary,
websites get's blocked in all browsers but not in Chrome? Is it only this website that does not get blocked in Chrome or also others?
What version and jumbo take?
Its somewhat a hit or miss on the browsers, but to summarize:
The target that we want to achieve is to successfully block categories via the blade, and not rely on custom applications/sites.
The internal Firewall is running on: R81.10 take 335
Please see the cpinfo -y all result
Looks like you have a clean R81.10 without any Jumbo take on it.
Would recommend to upgrade the Jumbo asap:
https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/R81.10/Introduction.htm
Could you run Chrome without HTTP2? -> https://my.f5.com/manage/s/article/K000092500
Let me know results. If positive upgrade to take 158 if not pick GA take 156.
Hello Lesley,
This is noted, I'll update you once the JHF is installed.
For the chrome to run without HTTP2, I need to read it first.
Hello!
I just want to update regarding this, apologies for the delayed response as after this was fixed, activities ramped up.
After the JHF installation, and adding internet connectivity to the internal firewall, the category blocking is now working as intended.
Thanks to you and to everyone in this thread who helped chip in information regarding this.
You might be running into sk182318.
You don't have any hotfixes installed and the solution for this behaviour on Chrome/edge is located in Take 150.
Hello @Alex- ,
I'm currently downloading JHF T-156 manually, as I just realized that my internal firewall doesn't have internet access.
I'll upload it and wait for the maintenance window to push the JHF installation.
Your firewall must have internet access for URL Filtering to work reliably, as URLs seen are checked in real time via the resource advisor to match against categories.
But how was it that application control works as intended? I can reliably block Youtube and Dropbox. Either way I'll try to resolve the internet connectivity issue for this, as the behavior is unusual as well. LAN users, which runs on the same IP segment as my internal firewall, has internet connection, but not my firewall.
Application Control works off the database that the gateway has downloaded. It presumably has one from before the re-architecture that's still working ok, but it is likely not getting updates.
I just confirmed that my blade is updating as intended:
Those updates are the management server only, the gateways fetch their own updates. If they are struggling they should throw an error that you can see in the Gateways and Servers view, per gateway.
It is confirmed that the gateway attempt failed:
I know this is not related to the main thread, but I want to ask as I'm troubleshooting the connectivity issue for my internal firewall. I'm currently pinging via clish, and while doing fw ctl zdebug + drop on my external firewall, I can't see anything.
When checking the logs through SmartConsole, I see them as allowed but through the implied rule.
I just want to know, I have the hunch that this is the cause, and would want to know if there's a way to make it not go through the rule so that a firewall rule will accommodate the traffic?
Whether it's an implied rule or an explicit rule, the traffic is being accepted through the policy. If you're not seeing anything in the zdebug + drop then it's not being dropped - go simpler, can you see it in a tcpdump on the external gateway? On both the internal side and the external side of it? Is the external gateway hideNATing the connections?
This thread provides the missing detail.
Internal Firewall Has No Internet Connection, But ... - Check Point CheckMates
Do you see UDP/443 or Quic traffic in your logs?
Hello @Chris_Atkinson ,
Yes there are quic traffic present in the logs and its being blocked by a policy.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 24 | |
| 18 | |
| 15 | |
| 13 | |
| 12 | |
| 10 | |
| 6 | |
| 5 | |
| 5 | |
| 4 |
Wed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY