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.
Kenny
Thanks for quick reply. I already had HTTPS allowed on my egress rule.
thanks
Even with src 172.20.10.10, destination Internet and Any Application do you have this problem?
Regards.
Yes I do.
thanks
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.
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.
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
I am having the same output from the zdebug, but with RDP (tcp 3389) traffic.
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.
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.
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?
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
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.