cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3389
Views
0
Helpful
3
Replies

Tcp flags and timeout on ASA55XX 8.4(3)

riccardobelli
Level 1
Level 1

I would like to understand someting about the behaviour of ASA with our traffic scenario and the management of  tcp sessions.

1) In particular we noticed that we have connections with the flags Fin without any acknowledgement. The session is silent (the bytes counters aren't incremented) but it remains in the session table as an established connection with the idle timeout of an established conn.

We have about 20%  (60K on 300K total) of conns in this state: at our eyes it seems to be an incorrect behaviour...

TCP OUTSIDE 62.149.128.151:110 INSIDE 10.254.158.12:61527, idle 0:11:36, bytes 433, flags UFIO

TCP OUTSIDE 17.151.0.200:443 INSIDE 10.254.229.94:52367, idle 0:01:25, bytes 4597, flags UfIO

TCP OUTSIDE 184.169.79.33:443 INSIDE 10.255.249.146:60143, idle 0:10:39, bytes 5590, flags UFIO

TCP OUTSIDE 157.55.235.158:80 INSIDE 10.170.37.102:62421, idle 0:00:53, bytes 1770, flags UfIO

2) On the connections considered as half -closed we have received an ack to the fin (r or R flag is present), we would like to set the idle timeout to a value lower than 5 minutes but we were not able to reach that result

timeout pat-xlate 0:00:30

timeout conn 0:10:00 half-closed 0:05:00 udp 0:02:00 icmp 0:00:02

!

access-list timeoutClass extended permit tcp any any eq www

access-list timeoutClass extended permit tcp any any eq 8080

class-map timeoutClass

match access-list timeoutClass

class timeoutClass

3) And this type of conns with a Fin on both side that I'm not able to understand... with an ack on one of the side how can I have the other fin??

TCP OUTSIDE 69.171.247.38:443 INSIDE 10.168.139.244:51236, idle 0:11:28, bytes 10536, flags UfFIO

TCP OUTSIDE 69.171.247.38:443 INSIDE 10.168.139.244:51234, idle 0:12:22, bytes 9070, flags UfFIO

TCP OUTSIDE 88.40.119.73:36962 INSIDE 10.255.93.162:36875, idle 0:13:27, bytes 3562, flags UfFIO

Can you help me to understand if this is a bug or a misconfiguration can cause these kinds of behaviour?

thanks in advance

best regards

Riccardo Belli

3 Replies 3

Julio Carvajal
VIP Alumni
VIP Alumni

Hello Riccardo,

As you know there are 2 ways a TCP connection can be closed:

The gracefull one ( FIN processure) or the aggresive one ( Reset)

The FIN processure:

A host sends a FIN packet, he expects a FIN-ACK from the other device

The other devices sends its own FIN packet, the host responds with a FIN-ACK.

At that point the ASA will consider the session as closed, if we are waiting for a FIN-ACK the connection will still up in a half-closed state so it will appear on the tables maintained by the ASA.

There is nothing you can do on the ASA regarding the host not sending a FIN-ACK. Is the host the one that sends those packets..

Now regarding the timeout that do should work, Can you share the entire configuration you setup for the half-closed connections??

Any other question..Sure..Just remember to rate all of the answers of the support forum

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Hi Julio,

I tried to modify the timer of half-closed connections but I couldn't reach my goal, not lower than 5 minutes

ASAxxx-2-(config-pmap-c)# set connection timeout hal

ASAxxx-2(config-pmap-c)# set connection timeout half-closed ?

mpf-policy-map-class mode commands/options:

  0:0:0 | <0:5:0> - <1193:0:0>  Idle time after which a TCP half-closed

                                connection will be freed, default is 0:10:00.

                                Specify 0:0:0 to never time out

  <0-0>                         Specify this value to never time out

ASAxxx-2(config-pmap-c)# set connection timeout half-closed 0:01:00

                                                                          ^

ERROR: % Time should be >= 0:5:0.

ASAxxx-2((config-pmap-c)#

timeout conn 0:10:00 half-closed 0:05:00 udp 0:02:00 icmp 0:00:02

And what about the conns of type 1? In my opinion  those conns are "broken" and the asas still maintain 20% of their  resources considering them as established !?!?

And what  about type 3: it seems that something not acceptable is occuring... how  can we observe two fin from differnt side without any ack??

thanx in advance

bye

Hello Ricardo,

timeout conn 0:10:00 half-closed 0:05:00 udp 0:02:00 icmp 0:00:02

That is de lowest value possible, so no way you can use a lower value

And what about the conns of type 1? In my opinion  those conns are "broken" and the asas still maintain 20% of their  resources considering them as established !?!?

Agree with you but I mean that is how the TCP protocol works.....There should be an FIN-ACK from the client and server

And what  about type 3: it seems that something not acceptable is occuring... how  can we observe two fin from differnt side without any ack??

Can you do a capture between one of those connections on both interfaces ( inside/outside) and check if the FIN-ACK is reaching one of the ASA's interface??

Regards,

Remember to rate all of the helpful posts, that is as important as a thanks.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card