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

[Tritontek]

Hi Sir, does asymmetric routing problem still applies to a single ISP and single FTD? FTD is still using 1 ISP for the meantime and no FTD HA configured. We only have 1 FTD device.

[MHM Cisco World]

No' if you have one Outside then there is no asymmetric.

But one Q' you use FPR instead of router do you use same IP of router?

The SW and host send packet to FPR with different mac address same IP.

This broken any traffic.

And also when add fpr the old tcp traffic will drop until one end established new connection.

[Tritontek]

My topolgy is this:

ISP <-> FTD-ASA5508X <-> Cisco 3850X-Core Switch<-> Internal LAN

FTD data port - XXX.21.1.1

FTD mgmt port - XXX.20.1.31

Core - XXX.21.1.2

[MHM Cisco World]

What you meaning data port?

[Tritontek]

Inside interface. Sorry for the terminology

[MHM Cisco World]

and the Mgmt port is OUTside ?
can you ping from Core to ISP when you connect FW?

[Tritontek]

Outside gig 1/0/7 -> to ISP

inside gig 1/0/1 -> core for inside traffic

mgmt -> core for mgmt purpose (fmc/ise etc.)

[MHM Cisco World]

@Marius Gunnerud  @Tritontek 

Show running access list 

Give use four group of acl

First is for prefilter 

Second is tunnel filter 

Third if you see it L7 rule'

L7 rule meaning there is condition to allow traffic and this traffic send to Snort.

We can see that third one have huge hits.

I reviewed all your old posts I could not get which one is drop traffic.

But may be if you share last event from fmc I can know which one.

I suspect with DNS or blacklist url.

But I need to see event to know.

@Marvin Rhoads your opinion for my notice is appreciate.

MHM

[Tritontek]

Hi Sir,

we finally found the culprit with the help of TAC. i sent TAC the bug report link that was showed here an they confirmed that i hit the similar bug and disabling early application detection and url categorization helped fix the problem,

TAC were looking at these 2 bugs:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwh50060

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwf35573

@Herald Sison 

this bug below may also be related but since pre filter fast path workaround did not work and only the disabling the TLS worked so still considered as a fix.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwd80741

after 3 days of monitoring we did not receive any issue or problem after applying the workaround. 

[MHM Cisco World]

I am so happy your issue solved. 

As I mentioned before there is app policy stop traffic. I was correct but I couldnot helped you to solve it. 

"disabling early application detection and url categorization helped fix the problem,"

Have a nice day

MHM

[Herald Sison]

Happy to share and helped you. Sometimes cisco bug may or may not be related to one or more issues but they sometimes had/have common workarounds. Sometimes it is very hard to pin point what bug you are hitting since bug reports are based on end users reports/SR and actual issues. Even TAC may take time to dig deeper and match what bug might have the same symptoms with your current issues.

A new firmware is now available from cisco portal, you might check it out and plan everything before you make an upgrade since any upgrade may not be an assurance that there will be no bugs anymore or fix the current bugs you have.

[divitgupta]

It appears from the diagnostic data that Snort is indeed blocking packets as requested. Snort is a powerful network intrusion detection and prevention system, and when configured to block or drop packets, it can override other policies that might allow traffic.

In your case, you mentioned that you have a prefilter policy with "any any" and fastpath, as well as disabled access control policies except for the default ACP set to "Trust All Traffic." However, the Snort rules take precedence when it comes to blocking or dropping traffic.