TCP Reset-O same sec-level intf

[Edwin Summers]

Assisting colleague with a failing VM restore. Connection terminates after about 1.5 hours. I do not see a network issue but trying to help him narrow down the culprit.

ASA logs indicate the connection was likely reset by TCP Reset-O. Reading shows this typically means the rest originated from the lower security level interface. However both interfaces are at the same sec-level.

Is there another way to interpret the teardown log message to definitively state which host initiated reset? I might be able to find the connection build log which may help based on one doc I found. But in case it is not available, can only the teardown log reveal the guilty resetter?

Thanks!
Ed


Sent from Cisco Technical Support Android App

[Jouni Forss]

Hi,

I actually havent thought about this situation before. I mean how the ASA shows a TCP Reset for a connection between interfaces with equal "security-level". I guess I could try to test this out later on my ASA.

Naturally if you took captures on the ASA itself you could confirm where the TCP Reset comes from. You could configure capture on both of the involved captures and configure the capture to write over the old information with the "circular-buffer" parameter and when the TCP Reset happens you could view the capture on the ASA CLI or copy it to your computer.

A simple "packet-tracer" test on my ASA between interfaces with equal "security-level" results in a connection building log message (in both direction) that says "inbound" which would indicate the same sourt of situation as the connection was formed from a lower "security-level" interface.

Again, the capture might be more conclusive in your situation unless ofcourse I can find some documentation that states specifically what Reset-O means in this situation.

- Jouni

[Edwin Summers]

Thanks for your reply, Jouni.  Note that I referenced some of your earlier posts while researching this topic.

I agree that a packet capture would be the definitive means of determining in this case.  Unfortunately I am limited on tools at this time.  The specific issue revolves around restoration of a 160GB VM that fails about half-way through.  It would be difficult given the amount of traffic passing and the uncertainty of the time of the failure to capture this using the ASA and a circular buffer. I have not researched to see if there is a way to limit the ASA's capture to a specific TCP packet type (containing the RST) but if that is an option we may implement it later.  Of course my "large" packet capture device decided to go belly-up this week.  [sigh]

The session teardown message is as follows (information redacted):

<166>%ASA-6-302014: Teardown TCP connection 811775999 for backup-network:aaa.aaa.aaa.aaa/65352 to  VM-mgmt-net:bbb.bbb.bbb.bbb/902 duration 1:22:47 bytes 8895983 TCP Reset-O

Based on this document (Scenarios 2 and 4) and my inability (so far) to find the session build message, we believe the RST originated from the backup-network (aaa.aaa.aaa.aaa).  I'll try to find the session build message, but just based on a loose reading of the document it appears that the "outside" host is the first one listed.  However I am not fully convinced that is the case.

Appreciate any other info you may have and thanks for reading!

-Ed