ASA Idle Connection Timout 60 Minutes

Question

I have an ASA 5512-X and have the Problem, that when I'm starting an SSH session and leave it running, it cancels the conenction after 60 Minutes.

I have two Policy Rules

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
  no tcp-inspection
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 ras 
  inspect rsh 
  inspect rtsp 
  inspect esmtp 
  inspect sqlnet 
  inspect skinny  
  inspect sunrpc 
  inspect xdmcp 
  inspect sip  
  inspect netbios 
  inspect tftp 
  inspect ip-options 
  inspect icmp 
  inspect http 
 class class-default
  user-statistics accounting
!
service-policy global_policy global

I also see this line in my configugartion.

How can I change the timeout conn to 3 hours ?

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

Answer 1

Heritu mentioned timeout conn 3:00:00 which is 100% right but make sure you enter en mode and run conf t prior.

From command line via putty

en

conf t

timeout conn 3:00:00

Answer 2

Strong recommendation: Use session timeout tuning only as the very last and ultimate resort.

Because today it will be 3hrs, and next week, the DB admins will ask for 10hrs for their long-running daily ssh-based remote-command-execution job. Which will run fine for half a month, then the amount of data processed by the remote job increases by 40% (because it might be payroll processing day on the 25th), and the job fails because its idling TCP connection gets killed after 10hrs. They'll come asking for 18hrs. You don't want to know what they'll be asking for for the end-of-year processing jobs.

There's keepalives for that:

• if applicable and feasible at the application level (sending NO-OP codes in the terminal emulation every so often). For example putty can do this easily.

  

• at the TCP layer by using TCP keepalives.

TCP Keepalives need two things: a) The TCP keepalive time on (one of the two TCP speaking) end systems needs to be cut short from default of 2hrs down to something like 10 or 15min. That's usually a global parameter for the entire Operating system. Windows has KeepAliveTime for that, (as explained in https://blogs.technet.microsoft.com/nettracer/2010/06/03/things-that-you-may-want-to-know-about-tcp-keepalives/ and almost anywhere you search for "Windows TCP KeepAliveTime")

b) the application itself MUST set the SO_KEEPALIVE socket option when initiating (or responding to) a TCP connection. Many applications do this by default, some are configurable. Only if SO_KEEPALIVE is enabled for the given TCP connection, the reduced TCP keepalive timers come into play.

Yes, Developpers and Systems Admins will complain at first and refuse to to their part of the work - but in the end, it's worth the effort, and once they understand that they can actually control the longevity of their idling connections themselves, they're happy.

On the other hand, it's one of the big misteries of the IT world why every Operating System defaults to 2hrs, while the firewall industry seems to default to 3600s or even 1800s.