cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1160
Views
7
Helpful
6
Replies

ACK,RST being dropped by ASA5540/7.0.6

dro
Level 1
Level 1

Hey NetPros,

I'm running into an odd problem. I have many remote PIX's set up, all running v6.3(5) and a head office ASA5540 running 7.0(6).

All devices are set up with 'service resetinbound' and 'service resetoutside'. If I attempt to connect to one of the remote PIX's from behind my ASA on a port that isn't open (forcing a rejection response), the connection hangs.

If I follow the same process originating from a workstation OUTSIDE of the ASA, the connection is properly rejected.

Doing some sniffer traces, the ASA is ignoring the ACK,RST response and not forwarding it on to the clients on the inside interface.

Has anyone encountered this before? Any suggestions? This is occurring to all PIX's and ASA's that I've tested from.

-Joshua

6 Replies 6

jgervia_2
Level 1
Level 1

Are you receiving any log messages when it drops? If you do a 'clear asp drop', initiate the connection, and then do a 'show asp drop', do you seen any information there?

--Jason

Thanks for the Tip, Jason. Unfortunately, I have too much traffic going through this device to pin-point the problem for sure. One of the counters that is incrimenting pretty close to when I do a 'clear asp drop' is for 'Bad TCP SACK ALLOW option'. SACK appears to be enabled on all traffic from the particular host I'm having the majority of issues with, so I'm not sure if this is the cause, or just other traffic on the wire.

Thanks,

-Joshua

I think this is a normal PIX or FWSM behavior.

The PIX ignores the RST ACK because it has allready closed the connection and other packets following will be dropped because there is no connection in the state table.

To confirm it might be good to open a TAC case.

I have seen the same behavior in some customer networks too.

I think PIX only respond to RST-ACK when service resetinbound or resetoutbound is configured.

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801cd841.html#wp1045404

sincerely

Patrick

Thanks for the response, Patrick. However, the problem isn't that I need the ASA to respond to the RST-ACK (or generate one!), I just need it to forward it on to the requestor (a user on the inside network), instead of silently dropping it.

The ASA is dropping the RST-ACK (generated from a remote network), and so the initiator (inside user) ends up having to wait for the TCP connection to time out, instead of breaking the connection immediately.

Bug CSCsg00748 appears to be related to this issue, but it's only a functionality request to allow the "tcp-options window-scale clear" filter to work on non-SYN packets..

-Joshua

Joshua,

There are several bugs dealing with RST flags in the 7.0 code - I would try upgrading. I know I hate this answer as well, but given the fact in 7.0 code you can load multiple versions of code, you could always switch back fairly quickly, given a change window.

Also, the BUG id you referenced: says this in the 7.2 release notes:

Clear window-scale sack option in non-syn packets instead of dropping it

Which implies it is dropping it.

--Jason

Upgrading is never fun :-P

Once I get back from vacation, I'm hitting the lab with a few firmware versions to test out. I was trying to stay away from 7.2 due to stability problems I've had with it in the past, but I might not have a choice anymore..

Thanks for the tips. I'll follow up on this thread after I can get some testing done.

-Joshua

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: