Traffic matching an accept rule is dropped, log shows it hitting implied rule 0

[Christopher_Kon]

Some of our previously accepted web traffic outbound is dropped on an accept rule, according to 

fw ctl zdebug drop | grep 207.54.179.36. This is a Hyland Systems Training website. in SmartConsole, the logs show an accept over implied rule 0, but the site never loads, and the origin/source is the NAT IP of our firewall, and not the User with the correct source IP. This seems to only occur over port 443, as port 80 is still rejected, but shows the correct source and user. We have updated IPS twice, and upgraded from take 154 to take 169 and then to take 189 (latest) on the firewalls as well as the management server. 

Our security layer (the one with the accept) is now showing a drop on rule 6 in the debug log via the CLI on the gateway. Most websites seem to be fine, we noted most of the sites affected were hosted on AWS, and from what i've seen on forums, everything from IPS, Inspection Settings, GZIP exceptions have all been the cause for some people. I found this https://community.checkpoint.com/thread/8977-drops-on-accept-rule  forum entry which seems to align with our current problem. We have a case open with TAC but they so far appear to be baffled.

Any thoughts would be appreciated. We are in a clustered environment where we have tried failovers, cpstart/stop and a rule clone to change the UUID and "refresh" the hits, all to no avail. Currently running R80.10 Take 189

[Timothy_Hall]

The reason for the drop stated by fw ctl zdebug drop is just the rule number?  Anything else?

Please provide output of the enabled_blades command.  The IP of the firewall showing up in the source may imply some kind of proxying being done by the firewall, possibly in the context of HTTPS Inspection or some other blade.

--
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com

[Christopher_Kon]

Timothy Hall‌

Thanks for the reply. My apologies. The full output of the syntax of the debug log is: [cpu_22];[fw4_34];fw_log_drop_ex: Packet proto=6 xxx.xx.xx.xx:57695 -> 18.234.32.151:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Perimeter-Policy Security" rule 6;
;[cpu_38];[fw4_2];fw_log_drop_ex: Packet proto=6 xxx.xx.xx.xx:57696 -> 18.234.32.151:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Perimeter-Policy Security" rule 6;

Security policy rule 6 is our accept rule for Outbound Web Access. The site I used that is also (ironically) having the issue is status.checkpoint.com

Enabled_Blades output fw vpn cvpn urlf av appi ips identityServer SSL_INSPECT anti_bot vpn

thanks again. We do have HTTPS inspection rolled out and inspecting, and we found last night that adding sites to an HTTPS bypass rule "fixes" this issue. But why would HTTPS inspection suddenly and randomly break a site that was working without any HTTPS/SSL validation/trust issues? 

**edit, the X's show the internal/LAN IP of the firewall as the source, and the log in SmartConsole shows the NAT/External IP of the active firewall.

[Timothy_Hall]

Unfortunately lots of things can cause issues with sites having their HTTPS traffic inspected; the site may have changed something like required cipher suites that the firewall cannot support.  Keeping up with Jumbo HFAs is very important if using HTTPS Inspection for this reason, but it sounds like you have already taken care of that.

I'm assuming the problematic site does not come up at all, if so the initial HTTPS/TLS negotiations between the firewall and the site are probably failing.  This negotiation takes place in process space via wstlsd, would be worth a shot to take a look in $FWDIR/log/wstlsd.elg to see if any error messages are getting written in there when you try to access the site without a bypass.  Next step will be enabling a debug on wstlsd so you can see what specific problem it is having with that site, see:

sk105559: How to debug the WSTLSD daemon

--
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com

[Christopher_Kon]

Timothy,

Thanks for all your help on this. after debugging this and grinding this one out, it was discovered as a bug in take 189. one of the kernel.conf files has a value that has something about probe bypass and this is usually set to "fail-open" but the JHF changed it to "fail-close". Here are the commands:

fw ctl set int bypass_on_enhanced_ssl_inspection 1      and to permanently enable this feature through a reboot:

In $FWDIR/modules/fwkern.conf, add this line: bypass_on_enhanced_ssl_inspection=1

after a reboot of the associated gateways, things are now working as intended in our Disaster Recovery cluster. we plan to move these changes to Prod next week, barring any issues over the weekend.