HTTPS Inspection Strange Browsing

[Ed_Eades]

We recently turned on HTTPS Inspection and used Best Practice setup. We are using a Gateway self-signed cert and have pushed it out to clients. Our HTTPS Inspection policy is applied on a very small sub set of devices and networks for testing purposes before applying it to more enterprise wide. We have also noticed some strange behavior when opening web pages. Some pages may load as expected, some pages do not load, and some pages may only load partially. The partially loading seems to be the most common but all of it is somewhat random in nature and not related to specific sites. When either a page doesn't load or somewhat loads a simple refresh will make the page load. The partial loading does seem to be most present on sites that may have more content delivery images and links present. That is where you may see partial images load. This behavior can be noticed across all web browsers. We are hesitant to push this out further to include more networks until we have a resolution.

We have 2 clusters both running 80.40 Take 118 and have the strange behavior from both clusters.

We have engaged TAC. In the meantime hoping to see if anyone has had similar experiences or even possible resolution.

Came across another thread that had some similarities and starting this new post for advice

https://community.checkpoint.com/t5/Security-Gateways/HTTPS-inspection-not-working-correctly/m-p/139...

Many Thanks.

[Chris_Atkinson]

Are these clusters of normal gateways or VSX?

Potentially relevant fixes are included in the latest ongoing JHF take but you should consult with TAC to diagnose properly to confirm this.

[Ed_Eades]

Normal Gateways, 15600 appliances

[Timothy_Hall]

The partial loading and then pages completely rendering with a reload kind of sounds like CRL retrieval taking too long or not always working properly, are you seeing any "CRL timeout" error messages in your logs?

Make sure the OSCP Protocol is allowed outbound, and also very importantly that all DNS servers configured in the Gaia OS of the firewall are working and returning fast results; test each defined DNS server yourself via nslookup.

Finally you could try temporarily disabling CRL Validation on the firewall and see if it impacts the problem; this setting can be found under Manage & Settings...Blades...HTTPS Inspection...Configure in SmartDashboard...HTTPS Inspection...HTTPS Validation...Server Validation.

[Ed_Eades]

We do see a very steady flow of Invalid CRL Retrieved in the logs for the devices setup to use HTTPS Inspection policy.  After reading the suggestions I checked DNS on our Gateways and they are setup with Google DNS (8.8.8.8 & 8.8.4.4) which may not be the best setup or most efficient when it comes to lookups. Not exactly sure why they were set this way and have been for many many years. This setup could possibly explain that we may not always be getting the fastest results or maybe stale caching. Nslookups are working on the GWs as they are but I do feel like this could be a good place to start with changing to see if results are different.

I am thinking that we should adjust the DNS configured to instead point to our Internal DNS Servers and wanted to check if there were any best practice on DNS setup for the GWs themselves. There is an implied rule for udp/53 but wanted to check on what interface would we expect for the GW to use for dns lookups?

Thanks again.

[the_rock]

I worked lots with a customer for https inspection over course of many, many months. I dont remember they had this specific issue like one you described, but I remember TAC always asking us to make changes for certain kernel parameter (I probably should not mention which one, as I got in "trouble" last time I mentioned it : - ). But, in all seriousness, I would say its difficult to pin point 100% those things, unless you disable the blade or add sites to be bypassed, that way you know, no doubt, thats its https inspection. Be free to message me privately, happy to do remote with you and check it.

I would also check below, its very helpful:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...