zdebug drop question

[Neil_ZInk]

r80.10 Take 56.   15600 cluster

fw ctl zdebug drop : grep  172.20.10.10 is giving me the following errors

;[cpu_2];[fw4_27];fw_log_drop_ex: Packet proto=(public website IP):443 -> 172.20.10.10:51123 dropped by cphwd_pslglue_handle_packet Reason: PSL Drop: ASPII_MT

closest think on Check Point's support sk121732.  this SK does not seem to apply in my situation.

has anybody seen this before?

thanks.

[KennyManrique]

Hello Neil,

I had a similar issue before. It seems in R80.10 some https traffic does not match any Category or Application on that layer (and is logged as connection instead session), so to me, the traffic was dropped on a deny any rule.

My workaround was allow https on Service/Application from any to internet by creating a before last rule.

Regards.

[Neil_ZInk]

Kenny

Thanks for quick reply. I already had HTTPS allowed on my egress rule.

thanks

[KennyManrique]

Even with src 172.20.10.10, destination Internet and Any Application do you have this problem?

Regards.

[Neil_ZInk]

Yes I do.

thanks

[KennyManrique]

Try to disable SecureXL (fwaccel off) and make a fw monitor capture on all inspection points for this traffic (fw monitor -p all -e "host(public_Server) and host(172.20.10.10), accept;"). You can verify at which chain the traffic is dropped.

After that, you can try to disable IPS from CLI (ips off) and verify if the problem persists.

Regards.

[AlekseiShelepov]

Maybe this one is closer to your situation? 

Application Control/URL Filtering drops traffic from internal web server 

There is also another similar ticket for DNS packets - sk81320. And a case from a couple of years ago - CPUG - Firewall blocking without rules.

But in any case, I would recommend to open a service request in Check Point support.

[Neil_ZInk]

I believe I found out Why I am getting the error message.  

I recreated the same messages from an Isolated network.  (default deny)

for testing purposes   i did 2 different pings

ping 8.8.8.8

ping www.yahoo.com

with the rule set below I could not Ping or or DNS resolution.  Application/URL was block request

Policy: ICMP,  tcp/53, udp/53. tcp/443 is open

Application/URL.   MyAllowed sites

Application/URL.   block everything else

Rule set Set B:   Ping works / DNS resolution does not

Policy: ICMP,  tcp/53, udp/53. tcp/443 is open

Application/URL.   MyAllowed sites

Application/URL.   echo-request

Application/URL.   block everything else

Rule set Set d:   Ping works / DNS works

with every DNS request I get drop message:  cphwd_pslglue_handle_packet Reason: PSL Drop: ASPII_MT

Policy: ICMP,  tcp/53, udp/53. tcp/443 is open

Application/URL.   MyAllowed sites

Application/URL.   nds

Application/URL.   echo-request

Application/URL.   block everything else

tested again with IPS off

#ips off

#fwaccel off;fwaccel on

same results.

It looks to me that Application/URL blade does not like protocols.    Is there a better way to setup a rule set?

thanks everyone

[Steve_Moran1]

I am having the same output from the zdebug, but with RDP (tcp 3389) traffic.  

[Lloyd_Crosby]

Zombie Thread. But here is what can help you both out. The APII drop is the application control blade not being happy. First make sure that you not only have an accept for the FW rule base but the app/URLF control rules for this either DNS or RDP service. This must of course be above and deny rules it the URLF side.

You might want to check to see if you are in a fail open or fail close state for the APP/URLF if you have a high CPU load as it can also cause for the firewall to do funky stuff.

[Steve_Moran1]

That's what I found, if you set the logging for you app/urlf rules to extended logging, you can see what the firewall is thinking the application is.  In my case, it was detecting the packet to be some other odd application and therefore dropping it.  I created a new rule specifically allowing RDP and it went way.

[Lloyd_Crosby]

Some times I wish that the errors were a bit logical.. but hey I'd probably be out of a job it Check Point errors made too much sense eh?

[Martin_Raska]

Thanks for tip, I had the same problem

; 5Oct2018 14:56:54.086198;[cpu_2];[fw4_1];fw_log_drop_ex: Packet proto=17 10.XX.XX.XX:53 -> 10.YY.YY.YY:56615 dropped by cphwd_pslglue_handle_packet Reason: PSL Drop: ASPII_MT

When DNS server was replying it went drop.

also for LDAP and other services

Problem is that there is no sk in support center except sk81320, but this not work for me.

What worked was remove DROP rule at the end of APCL layer and magic happened, all was working