Understanding teardown from log

3moloz123 — Tue, 12 Mar 2019 03:39:43 GMT

Is the Reset-I always from the device on the higher security level interface (in this case 172.16.112.10/3389?

In the second case, what conclusions can be drawn from the teardown information "TCP FINs" - who is it that send the first FIN?

I'm strugglig to find the reasons for connections "freezing" or closing, but no errors that I can relate to the connection ids what so ever.

asa.log:2014-02-03T15:04:32.186954+01:00 10.1.4.1 %ASA-6-302013: Built inbound TCP connection 1730891653 for wan:195.195.195.195/49624 (195.195.195.195/49624) to vlan547:172.16.112.10/3389 (212.112.9.209/3389)

asa.log:2014-02-03T17:21:36.585964+01:00 10.1.4.1 %ASA-6-302014: Teardown TCP connection 1730891653 for wan:195.195.195.195/49624 to

vlan547:172.16.112.10/3389 duration 2:17:05 bytes 35781464 TCP Reset-I

asa.log:2014-02-03T13:14:51.660321+01:00 10.1.4.1 %ASA-6-302013: Built inbound TCP connection 1729135626 for wan:195.195.195.195/50005 (195.195.195.195/50005) to vlan547:172.16.112.10/3389 (212.112.9.209/3389)

asa.log:2014-02-03T18:05:02.785968+01:00 10.1.4.1 %ASA-6-302014: Teardown TCP connection 1729135626 for wan:195.195.195.195/50005 to vlan547:172.16.112.10/3389 duration 4:50:14 bytes 36231472 TCP FINs

Re: Understanding teardown from log

Jouni Forss — Mon, 03 Feb 2014 19:28:40 GMT

Hi,

The TCP Reset-I and TCP Reset-O should refer to the TCP RST coming from either higher or lower "security-level" interface.

There are some other things affected by the "security-level" also in the output of the ASA. For example when you check the output of "show conn" command the host on the lowest "security-level" interface is listed first. Same goes for log messages. The host on the lowest "security-level" interface is mentioned first in the log messages for Building and Teardown the connection.

To my understanding there is no way to determine the side which normally closed the connection from the log message itself. I would presume that the Client would usually do this but can't be 100% sure that its always like this.

If there is not a clear indication that the firewall is doing something to the connection then I would suggest capturing traffic to find out what is happening to the connection. You can either attach some host to the network to capture all the traffic from some port or perhaps capture traffic on the ASA itself.

You could for example configure a capture for your RDP connection like this

access-list RDP-CAP permit tcp host host

capture RDP-CAP type raw-data access-list RDP-CAP interface outside buffer 33500000 circular-buffer

If you are expecting a lot of data you will either have to do the capture on some other device (ASAs buffer limited to approx the above amount of Bytes) or you can either create a capture for each direction separately to maximize the amount of traffic that can be captured.

You could also leave out the Data in the actual packets and only capture the headers by using this command

capture RDP-CAP type raw-data access-list RDP-CAP interface outside buffer 33500000 circular-buffer headers-only

You can naturally use both of the above commands. Naturally you will have to use a different name for the "capture", I am not sure do you have to use a different ACL.

You can then use this command to check if there is traffic captured

show capture

If you wish to show capture contents on the CLI then you can use this command

show capture RDR-CAP

Then again you might want to load the capture to your host/server and open it with Wireshark then you could use this command

copy /pcap capture:RDP-CAP tftp://x.x.x.x/RDP-CAP.pcap

You can remove the capture with the command

no capture RDP-CAP

You will have to remove the capture ACL separately.

I am not sure how much information can be gotten from the RDP server itself. I dont have to deal with the IT side at all usually so I don't really know to what extent you would be able to log what the actual server does during those connection issues. A traffic capture would certainly tell what happens to the data/connection.

Hope this helps

- Jouni

topic Re: Understanding teardown from log in Network Security

Understanding teardown from log

Re: Understanding teardown from log