Packet is blocked as requested by snort with Prefilter anyany fastpath

[Tritontek]

Is there any way that Snort can still block or drop a packet/traffic even if i already added a prefilter policy that sets as any any network and with fastpath? Also i have disabled all my access control policy except for default ACP that is set to "Trust All Traffic"

These are the diagnostic data gathered below, random users experienced dropped traffic specifically accesses to cloud servers.

326: 12:06:43.000030 192.168.7.122.54741 > 20.189.173.14.443: P 1630889135:1630889364(229) ack 3677944706 win 1024 Drop-reason: (snort-block) Packet is blocked as requested by snort, Drop-location: frame 0x000055e9e3316112 flow (NA)/NA

327: 12:06:43.257463 192.168.5.100.56591 > 142.251.221.3.443: P 91537800:91538757(957) ack 1105471243 win 512 Drop-reason: (snort-block) Packet is blocked as requested by snort, Drop-location: frame 0x000055e9e3316112 flow (NA)/NA

328: 12:06:43.305953 192.168.9.102.55730 > 13.107.136.10.443: P 1070331683:1070331874(191) ack 3766062448 win 1024 Drop-reason: (snort-block) Packet is blocked as requested by snort, Drop-location: frame 0x000055e9e3316112 flow (NA)/NA

ASP Drop data below:

Are these drop counts normal or expected even after creating a fastpath inf pre filter policy and disabled all ACP rules and just retained the default action which is "TRUST ALL TRAFFIC" 

We are using FTD7.0.6 and FMC7.3.1

[Marius Gunnerud]

I suppose you have the relevant NAT rules configured for this traffic flow?

Could you do a "system support trace" from the  > prompt and then send some test traffic that is being dropped and post complete output here.

When entering the values for the trace only enter the client and server IPs, leave everything else blank.

[MHM Cisco World]

Hi, 
I make deep dive check all info you provide
rule 9 of ACP this in Lina permit any any but in Snort application opera VPN opera is Block.
can you remove it and but in end of ACP.

Thanks A Lot
MHM

[Tritontek]

Hi Sirs,

@MHM Cisco World @Marvin Rhoads @Marius Gunnerud 

Here are the latest logs and setting made below:

During the log capture these are the current settings on our FTD

1) i removed all unecessary ACP rule and left only 1 allow rule with in to out zone any any 

2) in ACP advanced tab, i set TLS = enabled, Pre-Filter Polic = Default Pre-filter, Intrusion Policy& Network analysis = Balanced Security and Connectivity with default set, Removed FTD Service Policy = 0.

default pre-filter policy is empty.

3) removed the unused OUTSIDE2 interface, removed routing for OUTSIDE2, removed routing for OUTSIDE2, removed NAT for OUTSIDE2 and VPNs, since we are using OUTSIDE1 and INSIDE for now,

and removed OUTSIDE2 in the platfrom settings DNS and ICMP.

4) removed RAVPN and S2S VPN confiurations to completely isolate the issue

5) removed OUTSIDE2 Zone and SLA MOnitor  to completely isolate the issue

So overall the traffic will just pass between INSIDE - OUTSIDE1 for now to see more clear troubleshooting.

Here are the logs from the system support trace and debug attached. 

NOTE: Prefilter policy, Service Policy removed, ACP rule allow all from in to out with default action balanced security and connectivity were set during the capture of these logs.

i have attached Packet Capture from FMC UI and Putty logs via FTD CLI. i have noticed a lot of snort drop and acl drop from these captures and i also noticed that it drops several amazon and azure ip addresses which is very odd.

Thank YOu So Much

[MHM Cisco World]

I suggest not remove ACP but remove application rule check connection 
then add it if the connection is success.

Thanks A Lot
MHM

[Marius Gunnerud]

@MHM Cisco World If the poster is giving us the whole picture then there are no active rules with application defined.

[Tritontek]

hi sir. i just removed inactive and unnecessary rules under access control policy and left 1 rule only that defines In-out any any see image below. 

this is what confused me even if i have only 1 rule left and that is an allow rule under ACP for any any any any i can still see acl-drop and snort drop from debug and trace capture.

any thoughts?

[Marius Gunnerud]

It might be security intelligence that is dropping it.  Have you checked under Analysis > connection events?  What is stated there?

You could try adding the IP or subnet in question to the security intelligence white list to see if that is what is causing the drop.

[Tritontek]

Hi Sir,

The sad thing is whether i searched all possible block actions in event i always get zero results, all events are just showing ALLOW NO block actions are recorded.

do you mean this Security Intelligence under access control? I have added any-ipv4 Network under Do-Not-Block List.

disabling TLS in advanced tab, Disable Early application detection and URL categorization.

not really sure if i am hitting this bug or not but i have suppressed the snort drop (That is one of the workaround mentioned), assuming i am hitting this bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwc59953 or this bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwc07015.

but acl-drop still exist.

after making these changes, i have managed to get rid of the Snort drop but STILL ACL-DROP count keeps on hitting. Now, i will focus my attention in stopping the ACL-DROP Count. Is there a way in doing this?

upon running show access-list i don't see any deny/block/drop of some sort, so why am i seeing acl-drop in show asp drop and in capture asp-drop acl-drop? how can i bypass this?

[tvotna]

Acl-drop dropcode is a catch-all drop code meaning that it is assigned if software needs to drop the packet, but cannot find a better reason code to tell you why. Asp-drop capture is your best friend if you want to troubleshoot this and you'll need to guess what software doesn't like in your traffic. Sometime Lina syslog can help.

[Tritontek]

Yes, that is right. That is why i am confused if these drop counts really meant dropping some packets and might related to our current issue.

see capture results below. Its hard to conclude that these data below are the culprit. IT is hard to ask 200+ users what Public IP's they are accessing to do their daily task so i cant point which IP should i allow or add in the bypass.

that is why the big question is why are they dropping? Even with allow rules and etc. has been done.

[MHM Cisco World]

you Now clear all ACP. 
please access via CLI to FTD 
do
clear conn 
and check again. 
clear counter is not help here. 

Thanks A Lot
MHM

[Tritontek]

i have always run clear conn clear asp drop everytime i get capture data.

may i ask what is the difference between the rule i created In -> Out Any Any Any Any to the default action in ACP?

see below image. if i set the default action to block all traffic would that make any difference with my active mandatory rule allow any any any?

[Herald Sison · Accepted solution]

Have you checked this one? https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwd80741 this bug is much related to these 2 bugs (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwc59953 and https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwc07015.) you mentioned above.

The workaround is pretty the same and since you disabled TLS already and deployed it to the device, did that fixed your issue?

[Tritontek]

correct! we will try that one, 

[MHM Cisco World]

sorry for late reply 
Now I check the show ASP drop 
and I see show acl, 
the acl hit count is all with permit any any so ACL is OK there is no more issue 
let go to ASP drop 
there is TCP packet without SYN and FP L2 drop count increase
@Marvin Rhoads  mention about asymetric traffic, can you share your topology 
the TCP first without SYN meaning that the packet take two or more path and FW drop this packet (and it retrasmit)