Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

TCP Reset Confusion

I have confiugred TCP string signature to reset the connection when user try to open certain URL.

I have configured no device for blocking action.

but still i am able to block. Why it is so, How IPS able to block URL.

Please let me know is TCP reset require any device to be in blocking list or IPS itself send the reset packet to user.

Cisco Employee

Re: TCP Reset Confusion

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.

New Member

Re: TCP Reset Confusion

Thanks for the great explanation.

but i am not able to configure the IPS to shun traffic for Pix firewall.

I have correctly added the firewall in blocking device list with correct authentication credentials.

But when i configure the IPS for blocking device the block option was not highligted.

Even when i type on firewall who command unable to see the IPS login.

Please let me know why blocking option is dimm. as shown in the snap shot

Cisco Employee

Re: TCP Reset Confusion

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.