12-15-2006 01:14 PM - edited 03-11-2019 02:09 AM
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
12-18-2006 06:11 AM
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
12-18-2006 02:00 PM
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
12-19-2006 08:04 AM
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.
sincerely
Patrick
12-19-2006 10:52 AM
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
12-19-2006 05:25 PM
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
12-19-2006 07:28 PM
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
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: