Schrodinger's Firewall

[B_P]

I need to have a firewall that does what it is configured to do, not some black box that may or may not pass traffic depending on its quantum state at the time a packet traverses it.

In the above log snippet, the user accessing the site is explicitly allowed to go to the category that is blocked by URL Filtering yet the firewall blocked it because there's a firewall rule way down the ruleset that blocks it for all users. In the block log it shows the username and in the accept log it shows the username............

This is not how firewalls should work. If there is a rule above another rule that is set to pass traffic, it needs to do that. Whatever other technology in place that my interfere with that type of operation, should not be default. If we enable all the blades it still needs to adhere to proper top-down processing.

[Danny]

You are misunderstanding how Check Point works, and you’re comparing apples with peaches here, because what you’re looking at are three completely different log types from three different inspection layers.

The “Accept” you see is only the Firewall layer saying: “connection can be established.” That’s all it means. It doesn’t promise that the traffic will sail untouched through every other blade. Once the session exists, HTTPS Inspection and URL Filtering jump in, and those blades have their own logic, their own policy order, and—important here—their own logs. So seeing Accept → Inspect → Block is completely normal. That’s just the flow through the pipeline.

Check Point doesn’t treat all blades as one giant top‑down rulebase. Firewall rules are evaluated in their list, URLF/AppCtrl rules in their own list, HTTPS Inspection in yet another. They all run in different parts of the inspection chain. So an “allow” in FW and a “block” in URLF is exactly how the product is meant to behave. The username appearing in multiple logs is also expected because each blade logs identity separately when it handles the flow.

Nothing quantum here. It only looks weird if you assume one unified rule list covers everything.

If you want to make the logs less confusing, a simple trick is to filter by log type or blade in SmartConsole. For example:

• Filter only Firewall logs if you want to see pure rulebase hits
• Filter only URL Filtering logs to see category‑based actions
• Filter for a specific blade: blade:Firewall, blade:"URL Filtering", blade:"HTTPS Inspection"
• Or filter by action to focus on the relevant events: action:Block, action:Accept

Once you split the logs by blade, the whole story becomes much clearer and you won’t get the impression that the firewall is contradicting itself.

[B_P]

Your post explains the issue with Check Point firewalls very well and reinforces my point.

---

@Danny wrote:

three different inspection layers

---

You need to stop looking at the firewall through pre-R80 eyes. IMO R80 set out to address that and it has been a failure.

[Vanness_Chen]

Hi @Danny 

I believe most customers encounter the scenario mentioned by @B_P : an end user is initially restricted from accessing the Internet, but later requests access to a specific website due to business needs.

This kind of frequent and granular policy adjustment can lead to a high level of rule duplication, which may ultimately result in unexpected behavior.

[Lesley]

URL filtering needs a bit of data in order to make a judgement. It can happen traffic is allowed by the firewall rulebase and in later stadium is blocked by URL filtering. That is pretty standard now. The top down process is no longer sufficient. There are to many factors now, for performance, more security etc. 

Not sure if you want to discuss this topic here, or need technical explanation how packet flow works. There are some complex packet flow PDF's that give you a general idea just how many turns a packet can take. Just think about slow path, fast path, PSL , VPN encryption, NAT etc etc

[B_P]

---

@Lesley wrote:

The top down process is no longer sufficient.

---

That is exactly my point! Not only does the firewall obscure what it's doing, the top-down policy is no longer sufficient.

The firewall needs to be incredibly clear and straight forward on what it is doing and why.

---

@Lesley wrote:

There are to many factors now, for performance, more security etc. 

I would strongly argue that any security gains are heavily outweighed by this obscurity. 

[PhoneBoy]

To understand if what you're experiencing is expected behavior, I would need to see the actual rules involved with full log cards for the entries in question (sensitive details redacted).

Note that using Session logs (as opposed to Connection logs) might also help in understanding what's going on, though you lose precise timestamps on repeated connection attempts.
It also reduces storage needed for logs.

[B_P]

The "expected behavior" is from my frame of reference, not the devs and it is 100% not expected -- and that's the problem. I should be able to look at a firewall ruleset and clearly see issues and if not the log should clearly show why, but it does not. This is evidenced by rules that clearly are set to allow traffic but don't.

The issue isn't "can the firewall" -- the issue is "does the firewall clearly show".

The rules that I have are very straight forward -- user is granted access to a category and further down the list there is a general block for that category. The screenshot shows it works.

[PhoneBoy]

Classification by the various blades is not a "one and done" activity, it's done continuously.
Which means if an allowed connection suddenly looks like it violates policy, you might see something like the behavior you're describing.
Another possibility is this is a bug that we should fix.
Either way, more concrete information is needed to validate what is going on here.

[B_P]

I understand that, but the underlying issue is this -- why even allow Application and Firewall rules to co-exist on a layer if "best practices" says to separate them out?

[Vincent_Bacher]

I get where you're coming from, but honestly, this is just how modern firewalls work now — and not just Check Point.

The amount of stuff a firewall has to look at today is nowhere near what it was 15 years ago. You've got HTTPS inspection, URL filtering, app control, identity awareness, all on top of the classic packet filtering. Cramming all of that into one single top-down rulebase just doesn't work anymore. I wouldn't have a clue how to design that completely top-down across all blades while keeping it performant. Check Point decided to split this into blades, each doing their own thing with their own policy. You can agree or disagree with that approach, but it's a design decision, not a bug.

And it's not like the competition does it any differently. Fortinet branches into security profiles from the firewall policy — AV, web filter, app control all do their own evaluation. Palo Alto has their own layered processing. The only place where you still get pure top-down is router ACLs, and that's because ACLs solve a much simpler problem.

So what you're seeing — Accept on the firewall layer, Block on URLF — that's exactly what's supposed to happen. Firewall says "connection is fine", URLF looks at the content and says "nope". Each blade tags its logs, so you can always tell what did what.

Yes, it takes time to get comfortable reading across the different blades, and if you really need the full packet flow you're stuck with fw monitor. That's the reality. But given what we're asking these boxes to do today, I don't see how you'd keep things simple AND maintain serious security coverage. Something has to give.

Just my $0.02.

[B_P]

---

@Vincent_Bacher wrote:

this is just how modern firewalls work now

---

I don't accept this. This is defeatism. 😉

---

@Vincent_Bacher wrote:

I don't see how you'd keep things simple AND maintain serious security coverage. Something has to give.

---

That's why I made this post because that something is R&D money. Top-down ruleset is Firewall 101 and it's not working.

[Vincent_Bacher]

It's not defeatism, it's pragmatism born from experience. 😉

There's a difference between pushing a vendor for better tooling, better visibility, better logs — all valid — and expecting them to redesign their core architecture because somebody doesn't like it.

That's like walking into Mercedes and demanding they replace the star with a fish.
You can ask, but you know what the answer will be.

Calling that a lack of R&D investment is a bit naive if I'm honest 😉 — this isn't a budget problem,
it's a design decision driven by what Layer 7 inspection demands.
We can debate whether Check Point gives us good enough tools to work within that design.
That's a fair conversation.

But asking for flat top-down across all blades in 2026?
That ship has sailed, and not because anyone gave up.

Again just my $ 0,02 😉

[B_P]

---

@Vincent_Bacher wrote:

it's a design decision

---

lol yup

[the_rock]

Hey @B_P ,

Mind sharing how policy layers are configured? Do you have multiple ordered layers? If so, what blades are enabled on each layer?

[B_P]

We have two ordered layers, the first being firewall only for GEO IP and the second being firewall and App/URL.

The second layer has over 70 inline layers in various depths. We only use Firewall and App & URL filtering and only on the ones that need it.

100% our issues revolve around a *single* Firewall and App & URL layer which controls Internet access for our general users and has about 200 rules.

And most of those issues are from higher up rules being overridden by lower rules that block. For example, we want to grant specific identity users a specific app category access and deny everyone else, but because Schrodinger's firewall, users' packets are both accepted and blocked until an admin looks at the log.

[the_rock]

I cant sadly make too many comments about it, as I would need to see what those rules look like and more indepth logs. Other than that, it would more be an educated guess, sorry.