Anti-virus block page issue

[the_rock]

Hey guys,

I really hope someone can help me out with this. I had been working with customer and TAC for 2 months on this and I feel we are little further than back when we started. Here is the requirement and the current situation:

-requirement is to have specific users block from downloading say msi or exe files, but still allow those PC to do windows updates regularly and when file downloads are blocked, its a MUST to have block poage displayed, because client does not want users constantly opening help desk tickets wondering why this is failing

TAC had so far asked us to check the following:

-make sure strict hold is enabled (set to 1) in malware_config file in $FWDIR/conf dir, which it is

-apply sk116022, which we did

-have jumbo 99 installed, also completed

Essentially, say when we go to putty.org (which I also tested in my own lab), and try msi or exe download, yes, block page does work, BUT, if you say go to google.com and google "google chrome download" and try to get the file, its blocked, but block page NEVER comes up. TAC has also built the lab for this, but appears even in their lab this is very inconsistent.

Has anyone ever done this successfully? I would have hard time believing this does not work as intended, unless its due to some weird redirect.

For what its worth, ssl inspection blocking is fine, never an issue. We initially tried using content awareness for it, but since it kept failing, we simply gave up on it. Also, TAC gave me custom fix from R&D for jumbo 99, but sadly that did not improve the situation.

Thanks again for help, as always!

Andy

[PhoneBoy]

I assume you're both explicitly blocking QUIC and using HTTPS Inspection, correct?

[the_rock]

Yes to both.

Andy

[the_rock]

We have remote today (April 30) with T3 and escalation person from TAC, so will update once thats done with any news.

Andy

[the_rock]

We have maintenance window with TAC and customer May 2nd 5.30 pm est for them to make registry change on their cluster as per sk116022, so lets see if the behavior may improve.

Andy

[the_rock]

Did some more tests in my lab today, more less the same behavior, but lets hope we can fix it for customer on the remote.

Andy

[JP_Rex]

Hi,

can you post a link that doesn't work?

I do have the suspicion that this is not a Check Point problem. It might be a HTML/JS  design "problem"

Regards
Peter

[JP_Rex]

Hi again,

if the download is done through an client site script, as it is the case with the chrome download, the 30x redirect inserted by the GW will be handelt by the script. The script will usually not show the page it is redirected to.

There is nothing CP can do about that.

Regards

Peter

[the_rock]

Its not just one link, its random ones. We have remote with escalations today, so will update.

Andy

[the_rock · Accepted solution]

Hey guys,

Appears process from sk116022 fixed it for customer, which Im happy about, though did not work so well in my lab. They will probably upgrade to R82 at some point after its recommended version, as TAC told us there are many improvements for this behavior in it.

Andy

[the_rock]

Hey everyone,

Just wanted to give another quick update for this. So what TAC escalation guy told us is indeed 100% true. I wanted to test this on couple other solutions in the lab and behavior was the same. So, for example, with Fortinet SASE solution, FortiSASE, when you connect with Forti client (equivalent to harmony endpoint on CP end), say if you are blocking exe and msi download, that works from putty.org, BUT, say you go to examplefile.com website and try download exe file as a test, it will NOT work and reason is because it redirects to another link, so only way to reallyt fix this is block examplefile.com fqdn via web filtering.

In my view, its not perfect, but its the only option for now.

Best.

Andy