02-03-2014 11:07 AM - edited 03-11-2019 08:39 PM
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
Solved! Go to Solution.
02-03-2014 11:28 AM
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
access-list RDP-CAP permit tcp 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
02-03-2014 11:28 AM
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
access-list RDP-CAP permit tcp 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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide