log shows wrong source/destination, need help! (ASA 8.3)

[pweichmann]

The Cisco ASDM or the event manager show wrong source/destination for teardown tcp messages:

In this example the communication is an ssh session;

from 1.1.1.1 -> 2.2.2.2 ssh and the connection is reseted by 2.2.2.2

The message build outbound is correct, i.e. source is 1.1.1.1 (message id is 302013)

6

May 26 2011

11:27:57

302013

1.1.1.1

54046

2.2.2.2

22

Built outbound TCP connection 575077 for integration:2.2.2.2/22 (2.2.2.2/22) to panalpina:1.1.1.1/54046 (1.1.1.1/54046)

But the teardown is incorrect, i.e. source for the connection is 2.2.2.2 which is definitely not true (message id is 302014)

6

May 26 2011

11:27:57

302014

2.2.2.2

22

1.1.1.1

54046

Teardown TCP connection 575077 for integration:2.2.2.2/22 to panalpina:1.1.1.1/54046 duration 0:00:00 bytes 0 TCP Reset-O

Also there seems to be a documentation bug in syslog messages for ASA 8.4 since the message for the teardown 302014 is gone!

[Allen P Chen]

Hello,

Log ID 302014 is available under the log message guide for both software versions 8.3 and 8.4.

8.3

http://www.cisco.com/en/US/docs/security/asa/asa83/system/message/logmsgs.html#wp4770614

8.4

http://www.cisco.com/en/US/docs/security/asa/asa84/system/message/logmsgs.html#wp6941209

Based on the teardown message, the SSH server at 2.2.2.2 is resetting the connection (the log message indicates the reset is coming from the Outside, TCP Reset-O).  If the SSH server is sending the reset, then the source of the reset packet from host 2.2.2.2 should be correct.

Hope this helps.

[pweichmann]

Hi,

Thanks. It looks like the 302014 is only missing in the pdf where the 302015 follows the 302013 message ;)

I'm used to think that all messages pertaining to a stateful packet inspection session should be shown as the same source ip/port and dest ip/port direction and not show that a RST packet has been sent by the other side.

A.1026 - B.22   SYN

B.22  - A.1026   RST

Usually this is tracked only as a communication of A.1026 -> B.22.

This must be a bug, no?

Regards,

patrick

[Allen P Chen]

Hello,

If the remote end sends a reset packet to prevent the TCP 3-way handshake from completing, the ASA is going to log the source of the reset.  This is expected behavior.

Hope this helps.