FTD: Block with reset vs Block

[HQuest]

Hello all.

I have made a few tests with content block and got stuck with an unexpected behavior - or a bad understanding from my part. 3D sensor runs v6.2.2.2-1, if that adds to the question.

According to the documentation [1]: "The Block and Block with reset actions deny traffic without further inspection of any kind. Block with reset rules also reset the connection."

I was expecting the "Block" action to be completely silent for both parties, until the connection timeout happens, and the "Block with reset" action to be an immediate stop of the connection with both sides aware of the connection being terminated.

I applied some policies for HTTP/HTTPS traffic and I can see traffic being blocked as soon as it matches the policy, however it does not matter if the policy is set to Block with our without reset, on the client side it always delays until the connection time out. Please see attachment for visual details. And this completely destroys the end user experience, as some external services have delays over 2 minutes (for whatever reason).

Am I missing something?

[1] https://www.cisco.com/c/en/us/td/docs/security/firepower/620/configuration/guide/fpmc-config-guide-v62/access_control_rules.html#ID-2190-0000027b

[argrullo]

Hello Alexander, 

You are right on the way the Block and Block with Reset is supposed to work. Block is suppose to leave the page loading until it times out, Block with Reset should be immediate. The one sending the RST is the device itself. 

If this is not working, please open an SR for further investigation. 

[HQuest]

I have a TAC open (delayed after a few hiccups in Cisco's escalation process) and was able to speak to an engineer, however while researching this further, seems I'm hitting bug CSCvf47736. Still waiting to hear from the engineer if my problem confirms as this bug.

[argrullo]

I am glad to you were able to find a bug that might be related and provide a path. Does your environment match the conditions. Do you have an SSL Policy?



The internal bug notes have some information your CSE will be able to use to confirm the bug.

[HQuest]

Yes, we do have SSL policies for internal traffic decryption and for session recording purposes. Not that we are decrypting traffic from this particular policy but a SSL policy is applied. Seems my large scale deployment is going to get postponed - again...

[argrullo]

That is unfortunate. Currently the Fixed version for the bug are 6.2.2.2 and 6.2.3.

I know the versions above are also listed in the problem version, but this is because they were found in it during testing and will be fixed prior to release. 

Version 6.2.2.2 should be released by the end of the month. 

Otherwise the only other option would be to reimage the ASA to FTD. But that would much more work than needed, specially when there is a fixed version around the corner. 

[HQuest]

Well, February's almost over, so should the new code land today/tomorrow, we can put it in on the lab and see if 1) it fixes the issue and 2) what else it breaks. Hopefully, nothing that we might use elsewhere so we can roll this to the other deployments by the end of March.

Thanks for all the hints. I have to say I had better luck getting updates from you than from any of the 3 engineers assigned for my SR...

[HQuest]

Found 6.2.2.2-109 was out, so I gave it a shot on the lab earlier this morning. Applied to the FMC and to the sensor, deployed policies, tested and... same issue. Still not seeing any RESET from the sensor - only from the browser after 20+ seconds and a few packet retries.

[argrullo]

Hello Alexandre,



That is unfortunate and I am sorry it did not work out.

At this is more in depth, I would recommend to open an SR regarding this bug, and how it was supposed to solve the issue and to get the bug revised / find you a workaround.

[HQuest]

I have a SR is open. Waiting now to hear from the TAC engineer. I sent a few more pcaps for analysis and a fresh troubleshooting package too.

[HQuest]

I got CSCvi31751 created “just for me”... now back to the waiting game.

Workaround: set SSL Inspection policy to None at the Access List. You will miss SSL decryption and SSL session statistics.

[netcrackercorp]

Hello! I have the same issue. But it seems that in 6.2.2.2 it was resolved.

I see that with do not decrypt rule and block with reset action everithing is ok.

Could you confirm that you are still facing wit the bug in 6.2.2.2-109?

[HQuest]

On 6.2.2.2 it was acting the same way - if a SSL policy is added, it was a no go. I found out 6.2.3 is out, and gave it a shot. Enabled the SSL policy again and it seems it is fixed. I need to do some more testing but it looks promising.

[jmarugg]

I have the same issue with 6.2.3.9  doesn't matter if ssl decrypt is enabled or disabled.....