topic Re: zdebug drop question in General Topics

zdebug drop question

Neil_ZInk — Fri, 16 Feb 2018 20:50:25 GMT

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.

Re: zdebug drop question

KennyManrique — Fri, 16 Feb 2018 20:57:05 GMT

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.

Re: zdebug drop question

Neil_ZInk — Fri, 16 Feb 2018 21:11:53 GMT

Kenny

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

thanks

Re: zdebug drop question

KennyManrique — Fri, 16 Feb 2018 21:19:49 GMT

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

Regards.

Re: zdebug drop question

Neil_ZInk — Fri, 16 Feb 2018 21:32:45 GMT

Yes I do.

thanks

Re: zdebug drop question

AlekseiShelepov — Fri, 16 Feb 2018 22:01:21 GMT

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.

Re: zdebug drop question

KennyManrique — Sat, 17 Feb 2018 13:36:52 GMT

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.

Re: zdebug drop question

Neil_ZInk — Fri, 23 Feb 2018 15:35:06 GMT

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

Re: zdebug drop question

Steve_Moran1 — Thu, 09 Aug 2018 16:37:51 GMT

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

Re: zdebug drop question

Lloyd_Crosby — Fri, 10 Aug 2018 20:29:08 GMT

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.

Re: zdebug drop question

Steve_Moran1 — Thu, 16 Aug 2018 21:18:08 GMT

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.

Re: zdebug drop question

Lloyd_Crosby — Fri, 17 Aug 2018 00:36:30 GMT

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?

Re: zdebug drop question

Martin_Raska — Fri, 05 Oct 2018 13:31:24 GMT

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