topic ASA 8.4(3) timeout configuration in Network Security

ASA 8.4(3) timeout configuration

pmoresi74 — Tue, 12 Mar 2019 00:04:22 GMT

Hi to everybody,

I would like to know something with more accuration about idle timeout configuration.

In particular why is impossible to set "half-closed connections" to a value lower than 5 minutes neither through a policy-map? In my particular scenario, my asa is used to nat mobile phones traffic, it should be advisable to use less than 5 minutes

In my configuration I've set the timers as follows:

timeout xlate 0:15:00

timeout pat-xlate 0:00:30

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

policy-map timeoutPolicy

class timeoutClass

set connection timeout idle 0:01:00 reset

...

The access-list timeoutClass is selecting http and similia traffic.

With this setting I note that I've this types of connections:

1) flags UfFrIO, idle 2m27s, uptime 3m54s, timeout 5m0s, bytes 15578 >>> Recognized as half closed... I've fin from both side and even an ack from inside

2) flags UfF, idle 6m3s, uptime 7m23s, timeout 14m0s, bytes 0 >>> This connection is considered established ... 14minutes of idle timeout

In my opinion the 2nd type of connections should be released immediatly... because it's obvious that the client/server channel is broken and nothing can flow between them and the asa considers this connection as established 😞

Is this correct? I'm experiencing a misconfiguration or I've misunderstood something?

Thanks in advance

Riccardo

ASA 8.4(3) timeout configuration

Julio Carvajal — Thu, 04 Oct 2012 19:53:09 GMT

Hello Riccardo,

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

A) The gracefully option ( Using TCP FIN packets)

For this to happen each device will send a TCP FIN packet, this will let the other device he does not have anything else to send so the connection can be closed, the other device should send a FIN-ACK and his own FIN packet.

So in order for a TCP connection to be closed both devices should sen a FIN and the respective FIN-ACK for the other end FIN packet.

In the second case you showed us we do not see the -R or -r flag ( so we are still missing those packets in order to close the TCP session ( Expected behavior)

B) the Reset option:

The TCP connection is killed inmediatly.

Any other question..Sure.. Just remember to rate all of the helpful posts..

Regards,

Julio

ASA 8.4(3) timeout configuration

pmoresi74 — Fri, 05 Oct 2012 07:52:52 GMT

Hi Julio,

thanks for your answer, but I'm still perplexed about the behaviour of the asa.

I still can't understand why asa maintains in its state table a conn with a flag UfF as an established connection (with 14 minutes of idle timeout)... in my opinion it's absurd, it's not an established connection.

In my traffic scenario I've about 400k TCP connections on each asa and about 25% of this traffic is in "UfF" state and each connection is a xlate entry too, so I've about 25% of asa's ideal capacity wasted in this way.

thanks in advance

bye

riccardo

ASA 8.4(3) timeout configuration

pmoresi74 — Mon, 15 Oct 2012 12:58:39 GMT

Hi Julio,

Have you got an analisys of our asas' behaviour?

I can't understand the meaning of a connection with flag "UfF": how can I see a fins on both side without having an ack on one of the side? is it a bug or I have misunderstodd something?

thanks in advance

regards

Riccardo

ASA 8.4(3) timeout configuration

Julio Carvajal — Mon, 15 Oct 2012 17:26:05 GMT

Hello Paolo,

The ASA will keep that connection up as the connection has not been gracefully closed as the TCP protocol states.

It might be absurd but that is the way TCP works. As soon as the ASA receive both FIN and both ACK the connection will go down inmediatly.

Regards,

Any other question..Sure.. Just remember to rate all of the helpful posts..

Julio