HTTPS drop in R80.10

[KennyManrique]

Hello Community,

I'm experiencing an strange issue after Gateway upgrade to R80.10 (T56 now) on Open Server.

Previously when blocking Web Advertisements category on R77.30 all work fine with one "Block and show usercheck" rule. After upgrade to R80.10, the same rule was applied, and since Block option does not exists on the new architecture for APC and URL Filter, the option was replaced to drop instead.

I put you an example using the Drop option. There is a news site www.eldeber.com.bo where embedded advertising exists. When I open a link of a report inside the site, the page remains loading forever in blank despite the news is already received (pressing F5 the report is showed on screen briefly). All this is because HTTPS advertising, according to the Logs, and it seems the session is still trying to establish despite the drop rule.

I got similar error on www.amazon.com  and some other sites with embedded advertising.

As a workaround, what I had to do was create an inline layer for Web Advertisements and choose Reject for HTTPS and HTTPS_proxy. After this, the sites with embedded advertising load normally (I did the same test with the sites mentioned above).

So far, Web Advertisements is the only category who give me problems, but perahps this behavior reproduces in other categories. This issue is reproduced on all categories where the action for HTTPS is Drop; and specially on those sites who point to external content Droped somehow by the policy. Would be great if can test this for yourself's and verify why the problem only reproduces when using drop.

Regards.

[PhoneBoy]

What if you change the action to Reject in the top-level rule?

[KennyManrique]

It works, but cannot show UserCheck message for HTTP traffic.

Regards.

[PhoneBoy]

Looks like this is a known bug and you should open a TAC case for a potential fix to this.

Contact Support | Check Point Software 

[KennyManrique]

Thanks Dameon.

Do you have a bug ID to search it?

I will open a TAC case to further review.

Regards.

[PhoneBoy]

Offhand I do not, but I did inquire internally with R&D about it and they suggested opening a task regarding the issue.

If you can send me the SR number privately, I'll make sure the dots are connected on the backend.

[Hugo_vd_Kooij]

If the client gets a REJECT the client knows it doesn't work and it will now it fast.

If you silently drop the SYN packet it is up to the client to retry a few times before giving up. This will give you a terrible penalty in the user experience.

As a rule of thumb I would considere to DROP anything from the outside that I don't want to allow. And REJECT anything from the inside that I don't want to allow.

While some auditers may not approve I find it saves your users a lot time as they get an error very fast if you block them and they don't have to wait for the timeouts.

[KennyManrique]

Thanks for the reply Hugo. 

You are absolutely right about the drop and reject behaviors. However, some things like this must be modified if you update from R77.30 (where all work without this issues). Also I noticed this strange case is not only in Web Advertisements category but in some others like Social Networking or Media Streams (Peraphs for all dropped apps in R80.10??) 

Do you know the exact behavior of Block in R77.30 App rulebase? Remember this option does not exists in R80.10 App rulebase.

Regards. 

[Hugo_vd_Kooij]

Kenny,

it's on my todo list somewhere. Unfortunalty not on page 1.

[PhoneBoy]

Did you open a TAC SR like I suggested above?

[KennyManrique]

Hi Dameon,

I was a little busy with other SR's for customers.

I will open the SR once the others had been closed.

Regards.

[KennyManrique · Accepted solution]

Check Point published an official SK documentation for this behavior on Sep 2018 using my Reject workaround as one of the solutions (I'm waiting for sk modification with special thanks 😞

sk135132: Websites take time to load when certain applications/links in APPI/URL Filtering rule base are block... 

I hope this be useful to all.