cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12784
Views
0
Helpful
8
Replies

Deny TCP (no connection)

Manoj Wadhwa
Level 1
Level 1

Hi Experts,

I've been struggling to find out the reason for high no. of Deny TCP (no connection) messages on my ASA FW. As per the below logs, the ACL is already permitting the traffic, however after the connection tear down, there are many TCP (no connection) logs. Any help in this regard will be helpful. Thanks!

Apr 06 2011 14:03:21: %ASA-3-106100: access-list users_acl_in permitted tcp users/172.28.5.58(4758) -> server/isaproxy(8080) hit-cnt 1 first hit [0xca351c26, 0x85cb1438]
Apr 06 2011 14:03:21: %ASA-6-302013: Built inbound TCP connection 820138268 for users:172.28.5.58/4758 (172.28.5.58/4758) to server:isaproxy/8080 (isaproxy/8080)
Apr 06 2011 14:03:24: %ASA-6-302014: Teardown TCP connection 820138642 for users:172.28.5.58/4760 to server:isaproxy/8080 duration 0:00:00 bytes 10710 TCP Reset-O
Apr 06 2011 14:03:24: %ASA-6-106015: Deny TCP (no connection) from 172.28.5.58/4760 to isaproxy/8080 flags RST  on interface users
Apr 06 2011 14:03:24: %ASA-6-106015: Deny TCP (no connection) from 172.28.5.58/4760 to isaproxy/8080 flags RST  on interface users
Apr 06 2011 14:03:24: %ASA-6-106015: Deny TCP (no connection) from 172.28.5.58/4760 to isaproxy/8080 flags RST  on interface users

Regards,

Manoj

8 Replies 8

sean_evershed
Level 7
Level 7

Do you have any asymetric routing issues in your network?

Hi Sean,

Dont think there are any asymetric routing issues in our network. Thanks!

Regards,

Manoj

Shrikant Sundaresh
Cisco Employee
Cisco Employee

Hi Manoj,

Please let me know if i have understood your topology correctly:

(172.28.5.58)------------------(out)ASA(inside)---------------- (isaproxy)

One of the possible scenarios, I think, is that the 172.28.5.58 is sending multiple Resets because it is perhaps not receiving an acknowledge for the reset.

Apr 06 2011 14:03:24: %ASA-6-302014: Teardown TCP connection 820138642  for users:172.28.5.58/4760 to server:isaproxy/8080 duration 0:00:00  bytes 10710 TCP Reset-O

Reset-O means the Reset was from the lower security interface, ie. outside. So 172.28.5.58 sent a RST to close the connection.

When this happens, ASA removes the connection entry and forwards the RST to the isaproxy server.

If the server sends a RST-ACK then it would be dropped on the ASA, since there is no connection entry now.

However, I think the user PC is expecting a RST-ACK and since it is not getting any, it thinks the RST has not reached the server, and resends that packet. Now since the connection entry for the RST no longer exists, the ASA drops this packet and logs it.

As you can see, the resent packet has RST flag set.


Apr 06 2011 14:03:24: %ASA-6-106015: Deny TCP  (no connection) from 172.28.5.58/4760 to isaproxy/8080 flags RST  on  interface users
Apr 06 2011 14:03:24: %ASA-6-106015: Deny TCP (no  connection) from 172.28.5.58/4760 to isaproxy/8080 flags RST  on  interface users
Apr 06 2011 14:03:24: %ASA-6-106015: Deny TCP (no  connection) from 172.28.5.58/4760 to isaproxy/8080 flags RST  on  interface users

I hope this helps.

-Shrikant

P.S.: Please mark the question resolved if it has been answered. Do rate helpful posts. Thanks.

Hi Shrikanth,

Thanks for the reply. You were right in understanding the topology and your explanation was helpful. However i would like to know

1. Will the RST-ACK packet be sent by the isa server? Does this mean that the server is not sending back the RST-ACK packet?

2. Is there any problem in the configuration of the ISA server? Why is the isa server not sending the RST-ACK packet?

3. What are the possible solutions to resolve this issue. Do i need to contact the isa server administrator for this ?

Thanks!

Regards,

Manoj

Hi Manoj,

It is not mandatory for the RST-ACK to be sent. So there is no config issue on the ISA server.

Even if it did send the RST-ACK, the packet would be dropped, since connection entry no longer exists on the ASA.

I don't think there is any solution to this on the server or ASA side. If the user could be configured to not send multiple RST packets, or not wait for RST ACK, then that would help. Else you would have to just ignore such messages.

I think that on a Linux machine such parameters can be modified in the sysctl.conf. I am not aware of anything like this for Windows though.

Hope this helps.

-Shrikant

P.S.: Please mark the question resolved, if it has been answered. Do rate helpful posts. Thanks.

Hi Shrikanth,

Is the same explanation applicable for the logs as mentioned below ?

Apr 07 2011 18:49:14: %ASA-6-302013: Built outbound TCP connection 80956576 for Outside:10.10.1.253/444 (10.10.1.253/444) to Inside:10.10.3.37/25312 (10.10.3.37/25312)

Apr 07 2011 18:49:14: %ASA-6-302014: Teardown TCP connection 80956576 for Outside:10.10.1.253/444 to Inside:10.10.3.37/25312 duration 0:00:00 bytes 9434 TCP FINs

Apr 07 2011 18:49:14: %ASA-6-106015: Deny TCP (no connection) from 10.10.3.37/25312 to 10.10.1.253/444 flags RST  on interface Inside

Apr 07 2011 18:49:14: %ASA-6-302013: Built outbound TCP connection 80956578 for Outside:10.10.0.209/444 (10.10.0.209/444) to Inside:10.10.3.37/25313 (10.10.3.37/25313)

Apr 07 2011 18:49:14: %ASA-6-302014: Teardown TCP connection 80956554 for Outside:10.10.0.209/444 to Inside:10.10.3.37/25308 duration 0:00:02 bytes 5503 TCP FINs

13Apr 07 2011 18:49:14: %ASA-6-106015: Deny TCP (no connection) from 10.10.3.37/25308 to 10.10.0.209/444 flags RST  on interface Inside

Apr 07 2011 18:49:14: %ASA-6-106015: Deny TCP (no connection) from 10.10.3.37/25308 to 10.10.0.209/444 flags RST  on interface Inside

Here the connection is being terminated using the FIN flag, however still the deny logs keep appearing. Thanks!

Regards,

Manoj

Hi Manoj,

Would it be possible for you to run a capture using Wireshark on 10.10.3.37 and initiate a connection to 10.10.1.253:444?

The capture should capture the packets from beginning of connection till it ends. (connection terminates within 0-2 seconds according to the logs).

This capture along with the logs generated during that time, would help in determining what's happening.

-Shrikant

Hi Shrikant,

Sure, will try to get the capture done using Wireshark, however needs client approval and may take some time. I will try to get this done by tomorrow and reply to you post. Appreciate your assistance so far. Cheers !!!

Regards,

Manoj

Review Cisco Networking for a $25 gift card