10-19-2012 06:46 AM - edited 03-11-2019 05:11 PM
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
10-19-2012 01:08 PM
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
10-22-2012 07:21 AM
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
10-22-2012 09:48 AM
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.
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