Strange match on inline layer

[KM1895]

hi,

Im currently investigating a bit of a strange case.

Users are able to access the internet and download a file, even though it should have gone to clean up.

This is an inline layer rule, and the users get accept on the main rule, which is basically internal nets -> external nets

but when going through the inline layer rules, there is no accept rule for the destination, so it should end up in the clean up rule.

But the users are able to download sucessfully, and in the logs, we see accept and "connection terminated before the gateway..." message. Not sure if that is relevant for this case, but thought i should mention it.

So the traffic is then accepted, on rule xxx, and not dropped in clean up rule on xxx.yy

Anyone seen anything similar like this before?

[PhoneBoy]

It's very relevant because it's the reason this is occurring.

"Connection terminated before the gateway..." means the connection terminated before the gateway could determine what application the traffic was (thus what rule applies).
Note that in most cases, it should only require a few packets to make the determination.
This is generally expected behavior.
See: https://support.checkpoint.com/results/sk/sk113479 

To troubleshoot this, we'd need to see the rules in the inline layer in question along with one of the logs where this occurred (redact sensitive details).

[KM1895]

hi,

Yeah, im familiar with the sk, and why the message is appearing in general. The strange thing here, is that the inline layer rules is not "invoked" or checked, when the traffic hits the rule. So the traffic acts as a basic access rule, with src,dst, port, instead of passing the traffic through the inline layer rules, to find a match. and the match would then be the cleanup rule.

Unfortunately, i dont think i can provide a screenshot of this, as there is too much information/naming standards etc, that can identify parts of the customer's infrastructure.

So i can try a better description of the rules.

The "main rule" is: src: internal networks dst: external networks ports: any

the inline layer rules then consist of various source nets towards url's and applications, some of them custom.

So i have checked that there isnt a match for the url in question, so if the traffic had passed normally, it would then be dropped.

So what we see, is that the users are accessing a url externally, and they are able to download files from the site they are acessing.

So the logs are showing an accept on main rule, but no entries on any inline layer rules, to summarize. hope this helps a bit.

[PhoneBoy]

Even without the exact rulebase, an example log card of such a connection being accepted (with sensitive details redacted) should be helpful.
However, I suspect you'll need TAC to troubleshoot this.

[the_rock]

It would help us if you sent a screenshot of the actual inline layer, along with "child" rule in question. Please blur out any sensitive data.

Andy

[the_rock]

I just read your issue again and I have a gut feeling I may know why this happens. I had similar problem with a client couple of years back and I can check my notes tomorrow how we made it work, but I recall customer had content awareness enabled, as they wanted to just test it out for 30 days to see how it works. 

Is content awareness blade involved here? If yes, I will be able to tell you how we made it work.

Andy

[KM1895]

hi,

No, Content Awareness is not activated. They are running full NGTX bundle and https inspection for outbound inspection.

[the_rock]

Here is the catch...you need to BLOCK that site using https inspection (or if you use urlf layer) first, cause if its not inspected, it will never get blocked. 

Andy

**********************************

see below link I had about this back in 2022

https://community.checkpoint.com/t5/Security-Gateways/Content-awareness-issue/m-p/156026/emcs_t/S2h8...

[the_rock]

Hey @KM1895 

Going back to link I gave in my last response, I think even if you do NOT use content awareness, key here is to uncheck bypass option to known update servers in legacy dashboard https inspection tab and then allow the same through the ordered (or inline) policy layer. Just my 2 cents and Im saying this based on what escalation engineer told me back when I had the case with customer about this in 2022.

Andy