Traffic dropped only in clean-up rule??

[RemoteUser]

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

behavior:

• 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

[PhoneBoy]

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. 

[RemoteUser]

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.

[PhoneBoy]

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.

[RemoteUser]

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.

[PhoneBoy]

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.

[Lesley]

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?

[RemoteUser]

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

[the_rock]

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

[the_rock]

Let me clarify that...traffic has to be allowed on all the ORDERED layers.

[Lesley]

Try background and give it couple more tests

[RemoteUser]

I treid in R82 environment, and ti's works.
there only one site that it's accessbile on chrome but not in edge...

[the_rock]

Hey bro,

I will test this in the lab Sunday.

Andy

[RemoteUser]

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

[Chris_Atkinson]

What TLS version do you observe for communication with this this site, is it using encrypted SNI?

[RemoteUser]

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

[Chris_Atkinson]

Don't believe it is currently planned.

To clarify R82 is working for you with or without HTTPS inspection?

[RemoteUser]

Yes, some sites are blocked on the R82, but not on the R81.20.

[Chris_Atkinson]

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.

[RemoteUser]

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..

[Chris_Atkinson]

I asked if HTTPS inspection was enabled in the case of R82 or not, thanks for clarifying.

[RemoteUser]

Https inspection was not enabled in either lab.
you’re welcome brother 

[the_rock]

Thats EXACTLY how Im gonna test the lab.

Andy

[the_rock]

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

[RemoteUser]

Hey brother,
I'm happy to see that we've the same result!

[the_rock]

No worries...I tested some other categories as well and result was more less the same.

Andy

[RemoteUser]

what do you think may be the factor in this behavior?Did you happen to make any traffic captures about it?

[the_rock]

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

[RemoteUser]

i got you, thk brother

[the_rock]

No problem...if you need me to test anything else, let me know.

Andy