[c-nsp] Timeout value on ASA

Wed May 9 13:51:07 EDT 2012

Hi Antonio,

The first output is showing "PATed" connections - or ones which have
been Port Address Translated.  In this case, the xlate timeout is
hard-coded to 30 seconds, and is not user configurable.

If instead you look at "NATed" connections, you will see the timeout
would be set to the user-configured value - 3 hours in your case.

Hope that helps explain it.

Sincerely,

David.

Antonio Soares wrote:
> Hi David,
>
> Can you elaborate a little more about the xlate timeout, it's something I
> never understood very well. For example, taking this output as an example:
>
> ASA# sh xlate       
> 2 in use, 229 most used
> Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T -
> twice
> UDP PAT from IN:xxx.xxx.xxx.xxx/54337 to OUT:xxx.xxx.xxx.xxx/6630 flags ri
> idle 0:00:01 timeout 0:00:30
> TCP PAT from IN:xxx.xxx.xxx.xxx/1028 to OUT:xxx.xxx.xxx.xxx/5281 flags ri
> idle 0:00:13 timeout 0:00:30
>
> Why do we see 30 seconds as the timeout ? By default it's 3 hours:
>
> ASA# sh runn timeout
> timeout xlate 3:00:00
> timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
> timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat
> 0:05:00
> timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect
> 0:02:00
> timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
> timeout tcp-proxy-reassembly 0:01:00
> timeout floating-conn 0:00:00
> ASA# 
>
> timeout xlate:
>
> Configure idle time after which a dynamic address will be returned to the
> free pool, default is 3:00:00
>
> The output above was taken from an ASA. For example, this FWSM reflects the
> timeout correctly as configured globally (25 minutes):
>
> FWSM# sh xlate debug
> Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,
>        o - outside, r - portmap, s - static
> 45 in use, 281 most used
> NAT from IN:172.23.254.149 to OUT:xxx.xxx.xxx.xxx flags i idle 0:06:35
> timeout 0:25:00 connections 1
> NAT from IN:172.23.254.155 to OUT:xxx.xxx.xxx.xxx flags i idle 0:00:54
> timeout 0:25:00 connections 0
> NAT from IN:172.23.254.167 to OUT:xxx.xxx.xxx.xxx flags i idle 0:00:14
> timeout 0:25:00 connections 6
>
> This debug option is not available on the ASA.
>
>
> Thanks.
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> amsoares at netcabo.pt
> http://www.ccie18473.net
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David White, Jr.
> (dwhitejr)
> Sent: terça-feira, 8 de Maio de 2012 23:20
> To: Peter Rathlev; Judith Sanders
> Cc: 'cisco-nsp at puck.nether.net'
> Subject: Re: [c-nsp] Timeout value on ASA
>
> An alternative is to use Dead Connection Detection (DCD) on the ASA to
> validate if both endpoints on the idle connection are still alive, and if so
> reset the idle timeout, else tear it down.
>
> http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/conns
> _connlimits.html#wp1080752
>
> Additionally, one point for Peter.  Increasing the idle conn timeout does
> not require you to increase the xlate timeout.  The xlate timeout only takes
> effect once all conns associated to that xlate no longer exist.
>
> Sincerely,
>
> David.
>
> Peter Rathlev wrote:
>   
>> Hi Judith,
>>
>> On Tue, 2012-05-08 at 19:16 +0000, Judith Sanders wrote:
>>   
>>     
>>> I have a Cisco ASA5520-I have an established VPN with a third party 
>>> vendor. We are running applications over this tunnel and experiencing 
>>> timeouts. The tunnel never drops, just the application. I know that 
>>> there are default timeouts set on the ASA for certain protocols, but 
>>> if the tunnel is established, would it not be an application issue 
>>> and not a firewall/VPN timeout issue?
>>>     
>>>       
>> The ASA defaults for TCP timeouts (1 hour IIRC) are not compliant with 
>> RFC 5782 "NAT Behavioral Requirements for TCP", a BCP. It specifies 
>> that the timeout "MUST NOT be less than 2 hours 4 minutes". Use 
>> "timeout conn 2:04:00" on the ASA to adjust. You might also want to 
>> consider adjusting the "timeout xlate" upwards at the same time.
>>
>> Informational level debugging can tell you if and why the ASA have 
>> torn down a session; the "ASA-6-302014" messsage ("Teardown TCP ...") 
>> states the specific reason. Look for "Conn-timeout", meaning that the 
>> TCP connection has been idle for too long and is therefore closed.
>>
>> Even with a 2:04:00 timeout you still need to convince the application 
>> developers to actually use TCP Keep-Alives. We have been forced to 
>> apply a 24 hour timeout for certain connections because the developers 
>> couldn't/wouldn't use Keep-Alives. A policy-map can select just the 
>> right connections, so you avoid a long timeout for every connection 
>> through the ASA.
>>
>>   
>>     
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>   