ASA5512 Firepower module silently drops traffic

[hoffa2000]

Greetings

On two occasions the last week I've had issues where two different ASA5512s has dropped traffic seemingly at random. Nothing is logged on the FMC but the ASA logs alot of " SFR requested to drop TCP packet from inside:xxx.xxx.xxx.xxx/33124 to outside:xxx.xxx.xxx.xxx/443". Destinations like Facebook our intranet are among those dropped. Sadly I haven't had the time to investigate further once the problem occurs, what I do is fail to the secondary 5512, reboot the primary and all seems fine again.

My software versions are ASA 9.5.3, FMC 6.2.0.2 and Firepower 6.2.0.2. Things have been going smooth for half a year but this started after my recent reboot of all the units to mitigate the CSCvd78303 213 days uptime bug.

Any ideas?

/Fredrik

[Dinesh Verma]

Do you have SSL policy applied on SFR in order to inspect the intended encrypted traffic? If not then

"Messages such as "SFR requested to drop TCP packet" are normal. This happens when the SFR notices that traffic coming in is encrypted. Since the SFR module cannot decrypt encrypted traffic, there is no need to waste resources by having it sent through to the module. The messages is generated so the rest of the traffic in that connection can be bypassed.

Traffic was really dropped or you're saying so on basis of syslogs on ASA? If it's really dropped then open TAC case and we will verify all the aspects and see where exactly it is being dropped.

Regards,

Dv

[hoffa2000]

Hi

No, I don't have an SSL policy. I deduced that the "SFR requested to drop" messages had something to do with my problems because they aren't very common in the ASA logs and can usually be combined with an event in the FMC. 

I'm waiting for Cisco to sort out my contracts, after that I will open a TAC. If it is as you say it seems to me the ASA message is poorly described if it's a normal condition. I mean we have messages saying "SFR requested to bypass" for flows that the ASA shall allow, as told by the SFR. Then the opposite message should mean the ASA is dropping the flow.

/Fredrik

[Dinesh Verma]

Hi Fredrik,

Instead of failover and reboot, next time try removing the redirection of traffic towards SFR. That would be one way to quickly verify if it is SFR causing the drops.

Regards,

Dv

[#5]

I have had the same issue.  I disabled the SFR service policy and traffic resumed.  Do not have an answer on the issue yet though.

[Dinesh Verma]

If disabling the SFR solves the issue then pretty much troubleshooting needs to be done on SFR. Once packets enter SFR, we've several possible factors where packets might get dropped. I would suggest if you can open up a case with us, we will help you find out. If you've any existing SR for this issue, let me know, would be glad to assist you.

[#7]

It was a SFR issue.  When upgrading from version 5.x to 6.2 there was a code change.  We had a policy object that had a space in the name.  Apparently version 6.x and above so not support the space character in names.  Took me a bit to find but we are up to date and fully functional now.

[Dinesh Verma]

Glad you found it.