Slow page loading issues and errors Internal system error in HTTPS Inspection due to categorization

[Arturxr]

Good afternoon, a few days ago, a problem with slow page loading appeared. Sometimes when loading a page, an error appears and after a couple of seconds the page loads completely.

At this point, the following errors may appear in the firewall logs:

Internal system error in HTTPS Inspection due to categorization service timeout

It turns out that the problem is not constant and appears from time to time, but there is no load on the CPU

We restarted the RAD process and there seemed to be no errors for a while, but then they continued to appear in the logs from time to time.

Have you encountered this behavior before?
We encountered this for the first time, since usually before, when we had problems with categorization, there was no access to the Internet at all, but now only at a certain time the pages start to load slowly

[PhoneBoy]

The behavior sounds consistent with issues related to RAD.
There are debug steps for it here: https://support.checkpoint.com/results/sk/sk92743

It's possible this may be fixed by applying the latest recommended JHF for your release.
More than likely, TAC will need to be involved.

[the_rock]

Out of curioisity, how are blade settings configured in smart console? Will send screenshot later of what Im referring to.

[the_rock · Accepted solution]

This is what I meant, but here are screenshots, just in case.

https://community.checkpoint.com/t5/General-Topics/https-inspection-tip-feedback-suggestion/m-p/2530...

     

[Arturxr]

mode: hold in http inspection and app control

http inspection: fail open
app control: fail close

enforce safe search +

[the_rock]

I would try test it with settings I outlined. I honestly always found works best that way.

[Arturxr]

We set it up similarly and we stopped getting errors and it seems like resources are loading faster. We'll monitor it.

[the_rock]

Glad it helped.

[Arturxr]

Unfortunately, there are still some problems with the connection download speed. In the logs, we see errors like "The probe detected that this destination cannot be inspected and its identity cannot be verified due to a TLS alert (TLS alert: protocol_version)"

The probe sent to destination has encountered a general error

The probe was unable to establish a TCP connection to the destination

Internal system error in HTTPS Inspection (Error Code: 2)

[Chris_Atkinson]

Out of interest are you already bypassing sites known to have issues with TLS inspection using the relevant updatable objects?

[Arturxr]

But what's strange is that the problem only concerns Wi-Fi networks; no other problems have been detected yet.

[Chris_Atkinson]

Are we talking about BYOD vs Corp Wi-Fi clients or both?

[Arturxr]

We have a bypass rule to the "internet" object, which contains all external subnet ranges.

[the_rock]

Here is something I would test...disable quic in the policy and if still no progress, disable it in the browser itself. For example, for chrome, chrome://flags/ then search for quic and disable it. Restart browser and test.

[the_rock]

Example from my lab, @Arturxr 

  

[Bob_Zimmerman]

The "Hold" mode causes this. I most often see this behavior when somebody enables URL filtering on an internal firewall which isn't allowed to talk out to the Internet. Suddenly all kinds of traffic has six seconds of latency per pass added to opening the connection (e.g, let's say clients go through the firewall to hit a load balancer, then the load balancer goes through the firewall again to get to the servers; that's two passes, so 12 seconds of latency).

Switching to Background provides immediate relief. Ultimately, you need to figure out why the firewall sometimes can't reach the categorization service.

[the_rock]

I always found block and background options work the best.

[Chris_Atkinson]

Do you have any rules in your HTTPS inspection policy with 'Any' or non-HTTP based services?

[the_rock]

Definitely good point Chris. I saw that be an issue before.

[Arturxr]

We have a couple of rules from hosts to specific resources with "any" in services. Could this also affect traffic that doesn't fall under this rule?

[the_rock]

100% it could.

[the_rock]

One thing you can also test is add website(s) with the issue to bypass rule and see if it helps.