The sensor itself sends the TCP Reset packets. So the sensor can cause the client and server to stop the connection.
Part of your confusion is terminology.
When using terms like "block", the sensor has a specific "block" feature and so we limit our usage of the term "block" to only when we are discussing that specific feature.
So we would not say that a "TCP Reset" is able to "block" a connection. Because "TCP Reset" and "block" are 2 completely separate features of the sensor.
Here are some terms that do NOT refer to a specific feature of the sensor: Drop, Stop, Prevent
These terms, however, DO refer to specific features of the sensor: Reset, Block, Deny
The "TCP Reset" feature is able to Stop the connection by getting the client and/or server to Drop the connection by sending a TCP Reset packet to each of the boxes for that connection. The sensor itself sends the Resets.
The "Block" feature is able to Stop active connections as well as Drop and Prevent future connections by modifying configuration on other devices like Routers, Switches, and Firewalls. The actual Dropping of packets happens on that other device.
The "Deny" feature is able to Drop the actual attack packet and Prevent it from getting to the victim ip address. This only works when the sensor is deployed Inline where the packets have to go through the sensor to get to the rest of the network.
The option is not configurable for Firewalls(or a Cat 6K switch as well).
This is because the option is only applicable to the Routers.
With Routers you have to choose whether to do Blocking or Rate Limiting or both.
With the Firewalls (and Cat 6K Switches) the only thing you can do is Block. Since the only thing you can do is Block, it is not necessary to select it. The parameter just simply doesn't exist for the Firewall because it is unnecessary.
This is a bug in IDM. IDM re-used the Router screen for Firewalls and greyed out the field, but it should have creatd a new Screen for Firewalls and left it completely out.
As for why shunning to the Firewall is not working, here are a few things to try.
1) Through IDM add an address to Shun/Block. Then check the Firewall with a "show shun" command to see if the address was shunned. If not proceed to step 2.
2) Execute "show events past 00:05:00" to look at the events for the past 5 minutes. FInd the event where you added the shun/block, and look to see if there were any errors after it.
3) Execute "show stat network-access" and look to see what is reported for your Pix. It may report an error as to why it can't connect.
If there is still no luck figuring out why it can't connect then try:
4) In the shun/block configuration screens there should be a Block Enable option that you can set to False and Apply the configuration. This should force the sensor to disconnect from all Shun/Block devices.
5) Execute "show events" in a CLI connection and keep it running.
6) Now set Block Enable back to True and Apply the configuration.
7) Look back at the "show events" output and look for any messages about the sensor connecting to the Firewall to see if an Error is generated.
I also remember a bug in an older version, that I believe is fixed in newer service packs.
Execute "show shun" on the Firewall and see if there are any existing shuns.
Remove any existing shuns on the Firewall with the "no shun" command.
And then try numbers 4-7 again.
There were special cases where some existing shun entries caused a problem on the sensor because newer Pix versions modified how they output the shun list.
If clearing out the shun list fixed your problem, then you may have been hitting this bug, and you may need to upgrade your sensor in order to keep from hitting it in the future.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...