HTTPS inspection block page issue

[the_rock]

Hey everyone,

I hope someone can shed some light on this and provide some suggestions : ). So, here is the situation.

Customer has R81 mgmt and R80.40 jumbo 120 HA cluster. All works fine, but for some odd reason, with https inspection enabled, pages are blocked as per desired categories, BUT, user check block page seems to work super random. So say you go to gambling site, it gets blocked on chrome, but not on safari on mac...then on windows, its also very random, really depends site you go to if blocked page notification comes up or not.

We verified all the rules, logs show correct action and categories, so Im really not sure how to troubleshoot this. We do have TAC case, but wanted to do proper testing myself first.

Not sure if this info is worth much, but say if you try facebook.com, it simply shows connection was reset, yet log shows facebook is blocked according to right rule. 

If someone could give any suggestions/guidance on this, would be greatly appreciated!!

Thanks as always.

[PhoneBoy]

All of that sounds like some pages are NOT getting HTTPS Inspection applied as that is required for the block page to show up.
If HTTPS Inspection isn't enabled, or isn't happening for some reason, the only option to block a connection is a TCP RST.

[the_rock]

I agree with you 100%, but the question is why...any good approach to this behavior?

Thanks as always.

[PhoneBoy]

If it were me, I'd probably be looking at debugging wstlsd.
TAC may have some other suggestions as well.
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[the_rock]

That sounds good...I may call into TAC tomorrow to see if they have any other suggestions. Tx!

A.

[Teddy_Brewski]

Hi @the_rock 

Do you recall any tips from TAC?

We're experiencing the same(?) issue with 1555 SMB appliances running R81.10.17 (996004508) with Application Control and URL Filtering blades enabled.  HTTPS Inspection is not enabled, but we do have "Categorize HTTPS websites" checked.

Accessing http websites that fall into a blocked category results in a blocked page -- no issues here.

Accessing the same website over https doesn't produce the blocked page, but rather Connection Reset error in the browser. Also, there is some random behavior observed when nothing is blocked with certain browsers.

Logs do show correct action and category.

Thanks!

[the_rock · Accepted solution]

This was a while ago, but I remember it worked fine after R81 upgrade, no issues. I would say you definitely need ssl inspection on for this to work right.

Andy

[Tom_Hinoue]

For locally managed SMBs, we have confirmed this issue occurs in R81.10.15/R81.10.17 and a SR is opened to TAC.
A hotfix should be available now for this issue, so if interested open a case to TAC and they should be able to assist 🙂
If you need the SR number, you can DM me and I will be happy to help.

[Teddy_Brewski]

Thank you @Tom_Hinoue ! Good to know we're not alone. 🙂 Going to DM in a second.

[Tom_Hinoue]

gotcha. Will reply in DM regarding what I know.

[the_rock]

On another note, but in the same context, check out what @_Val_ said on November 23rd, 2021 in below post, its perfect explanation.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Categorize-HTTPS-Websites/m-p/134729/emcs_t/S2...

[PhoneBoy]

To show a block page, we need to issue an HTTP Redirect to the UserCheck portal.
For HTTPS connections, this is impossible to do unless HTTPS Inspection is enabled.

[the_rock]

@Teddy_Brewski What @PhoneBoy said is 100% correct. Think of the fw as MITM (man in the middle) in this case...if ssl inspection is off, there is literally nothing to "intercept".

Andy