ASA 60 minute inactivity timeout - Poor choice?

[ds6123]

Hello Friends!

We had an issue the other day where doing backups through the firewall (don't ask) caused the "control" session to timeout while the backups were still going on over the "data" connection.  This broke the backup about two hours into the job.  My first thought was that the backup solution vendor should implement some kind of tcp keepalive for the control connection.  A packet capture showed they indeed were --  after 2 hours!  Ah ha!  Busted!  How could they choose such a poor choice of TCP keepalive timer for their application that would not be compatible with the 60 minute inactivity timer that so many firewall vendors use (Cisco, Juniper, Checkpoint and Fortinet all use a default 60 minute inactivity timer for TCP)?

Well, a colleague of mine pointed out that there is actually an old RFC that covers this.  RFC 1122.  It says:

Keep-alive packets MUST only be sent  when no data or acknowledgement packets have been received for the  connection within an interval.  This interval MUST be configurable and  MUST default to no less than two hours.

Now I know that RFC is old (October 1989), but that's all I could find.  Is there something that supercedes that?  Maybe common sense perhaps?  I understand not wanting to fill up your connection table because of mis-behaving applications, but I'm just looking for ammunition to use against the backup solution vendor.  Surely they're going to point to this RFC.

Thanks!

ASA(config)# timeout conn ?
configure mode commands/options:
  0:0:0 | <0:5:0> - <1193:0:0>  Idle time after which a TCP connection state
                                will be closed, default is 1:00:00
  <0-0>                         Specify this value to never time out

[Jouni Forss]

Hi,

Certain application behaviour sometimes forces our hand to reconfigure the "timeout" values for certain customer connections. Though this has been pretty rare in my own case atleast.

I would imagine that any kind of keepalive would be something that would be constantly transmitted on the connection that needs to stay up and it would certainly be something that the application handles itself.

I did a quick try on my home ASA to check if this could be corrected by the ASA wihtout globally affecting all connections through the ASA and it seems to work fine

Here is the configuration I did

Where

• TIMEOUT = Is simply the name for each configuration (ACL, Class-Map and Policy-Map) that I chose
• x.x.x.x = Is the destination IP address for which I want to create these rules for
• LAN = Is my ASAs "inside" interface

access-list TIMEOUT extended permit ip host 10.0.1.1 host x.x.x.x

class-map TIMEOUT

match access-list TIMEOUT

policy-map TIMEOUT

class TIMEOUT

  set connection timeout idle 3:00:00

service-policy TIMEOUT interface LAN

Output of "show conn long" with 2 connections through the ASA. Other going with default "timeout" values and other matching the configured "timeout" values.

TCP WAN:x.x.x.x/80 (x.x.x.x/80) LAN:10.0.1.1/59074 (y.y.y.y/59074), flags UO, idle 15s, uptime 17s, timeout 3h0m, bytes 2

TCP WAN:a.a.a.a/80 (a.a.a.a/80) LAN:10.0.0.21/57482 (y.y.y.y/57482), flags UIO, idle 13s, uptime 14s, timeout 1h0m, bytes 598

Where

• x.x.x.x = Is the destination IP for the connection for which you want to configure its own "timeout" values
• y.y.y.y = Is my ASA public IP
• a.a.a.a = Is the connection destination IP address for which the global "timeout" values are applied

Theres is also an option called "dcd" in the same "set connection timeout" configuration

Here is the Command Reference section for "set connection timeout"

 set connection timeout 
 To specify connection timeouts within a policy map for a traffic class, use the set connection timeout command in class configuration mode. To remove the timeout, use the no form of this command. 
set connection timeout {[embryonic hh:mm:ss] [idle hh:mm:ss [reset]] [half-closed hh:mm:ss]  [dcd [retry_interval [max_retries]]]} 
no set connection timeout {[embryonic hh:mm:ss] [idle hh:mm:ss [reset]] [half-closed hh:mm:ss]  [dcd [retry_interval [max_retries]]]} 
 Syntax Description

 

 dcd 

 Enables dead connection detection (DCD). DCD detects a dead connection  and allows it to expire, without expiring connections that can still  handle traffic. You configure DCD when you want idle, but valid  connections to persist. After a TCP connection times out, the ASA sends  DCD probes to the end hosts to determine the validity of the connection.  If one of the end hosts fails to respond after the maximum retries are  exhausted, the ASA frees the connection. If both end hosts respond that  the connection is valid, the ASA updates the activity timeout to the  current time and reschedules the idle timeout accordingly. 

 embryonic hh:mm:ss 

 Sets the timeout period until a TCP embryonic (half-open) connection is  closed, between 0:0:5 and 1193:0:0. You can also set the value to 0,  which means the connection never times out. A TCP connection for which a  three-way handshake is not complete is an embryonic connection. 

 half-closed hh:mm:ss 

 Sets the idle timeout period until a half-closed connection is closed,  between 0:5:0 and 1193:0:0. You can also set the value to 0, which means  the connection never times out. Half-closed connections are not  affected by DCD. Also, the ASA does not send a reset when taking down  half-closed connections. 

 idle hh:mm:ss 

 Sets the idle timeout period after which an established connection of  any protocol closes. The valid range is from 0:0:1 to 1193:0:0. 

 max_retries 

 Sets the number of consecutive failed retries for DCD before declaring  the connection as dead. The minimum value is 1 and the maximum value is  255. 

 reset 

 For TCP traffic only, sends a TCP RST packet to both end systems after idle connections are removed. 

 retry_interval 

 Time duration in hh:mm:ss format to wait after each unresponsive DCD probe before sending another probe, between 0:0:1 and 24:0:0. 
 Defaults 
 The default embryonic timeout is 30 seconds. 
 The default half-closed idle timeout is 10 minutes. 
 The default dcd max_retries value is 5. 
 The default dcd retry_interval value is 15 seconds. 
 The default tcp idle timeout is 1 hour. 
 The default udp idle timeout is 2 minutes. 
 The default icmp idle timeout is 2 seconds. 
 The default esp and ha idle timeout is 30 seconds. 
 For all other protocols, the default idle timeout is 2 minutes. 
 To never time out, enter 0:0:0. 

Source:

http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/s1.html#wp1453113

I can't really say anything else to this other than it seems stupid to me to not have a mechanism to keep the Control connection active with frequent (enough) messages that will keep it active as long as there is data transfer on the actual Data connection. I dont know what kind of keepalive it is that polls at minimum on 2hour interval. Kind of beats the whole purpose of keepalive.

Though then again this is not a subject I could comment on any kind of certainty. Only comment on the way it seems to me.

- Jouni