How to prove a firewall is killing a TCP session?

[ryancisco01]

How to tell if a firewall is killing a session?

If I have a tcp connection between Host A and server B with a firewall in between, lets say its ftp, and the user reports the ftp session is disconnecting how do we prove what is really going on.

Lets say the firewall is running ftp inspection and does indeed kill the session for whatever reason, I can only assume the firewall will send the tcp RST packet using a source IP of the server, not itself (ie the host wouldn't accept a RST for a session from a different IP address right?)

So if I am capturing packets, whether it be on wireshark on the host itself and/or packet capture on the firewall how can I tell where the reset originated from? Lets say for fun sake I cant do anything like show conn or show inspection and all I have access to is packet capture from the firewall. Are there any flags set that will indicate this?

[johnlloyd_13]

hi,

you can use the packet tracer feature/command on the ASA.

[ryancisco01]

packet tracer shows layer 4 information, it wont show me how the firewall will behave if it receives invalid layer 7 information or something not doing a correct tcp handshake.

If you want to try this for yourself, enable smtp inspection, telnet to a mail server from a windows command prompt then type a command like "ehlo" you will see session disconnected or just no response, turn off smtp inspection, repeat test you will receive a reply from the mail server. 

In that same example packet tracer would show the connection as permitted, so the network engineer would tell the server engineer the traffic is permitted however in reality the firewall is bjorking the traffic. This probably isnt the best example for what I am trying to do but it proves the same point. 

[Evgeny Taskaev]

If you want to prove that firewall stops a TCP session (not server) i suggest you start packet capture between host and server on both interfaces of ASA, which traffic crosses.
So, compare two captures of the TCP session you can see, who indeed send RST packet or what is going on.
Who knows, may be it is not ASA inspection issue. I would take a look at the captures. For fun sake.

[ryancisco01]

Well yes I guess that would be the logical way.

I don't actually have a fault or anything, I am just curious and trying to learn!!

Seems ASA doesnt have a way of reporting when it sends the RST itself other than figuring it out for yourself with captures!

[Evgeny Taskaev]

I think we are complicating a problem with packet capture :-).
What about ASA logs? Deletion of a TCP connection should go along with "Teardown" message. 
So "Teardown" log entry contains a reason.
There are list of them http://www.cisco.com/en/US/docs/security/asa/asa80/system/message/logmsgs.html#wp4770614