Telnet timeouts

Unanswered Question

We have an new ASA 5510 configured for IPSEC remote VPN connections. Everything is working well except that telnet sessions to a business system at headquarters timeout while idle. It appears that they time out after about 2 hours. Our idle timeout is set to 4 hours in the group policy for IPSEC users. I don't see any other idle timeout setting that could possibly apply to this issue. Anyone have any ideas on what could be causing this?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Herbert Baerten Sun, 11/15/2009 - 02:49
User Badges:
  • Cisco Employee,

The idle timeout configured in the group-policy is for the tunnel as a whole, i.e. it will bring down the tunnel if there is no traffic for that amount of time.

If I understand your description correctly, the problem is not that the VPN tunnel goes down, nut just a single TCP connection times out.

ASA will normally time out TCP connection after 1 hour, so 2 hours seems strange (unless you meant that the user works for 1 hour and then is idle for 1 hour - or unless you configured the TCP timeout to be 2hrs).

Can you do a telnet and then check "show conn long | inc x.x.x.x" where x.x.x.x is either your client (tunnel) address or the server address.


Check the syslogs, there should be a message giving a reason for the connection teardown (not at the time when the user tries to re-active the session, but somewhere before).



Herbert Baerten Mon, 11/16/2009 - 07:31
User Badges:
  • Cisco Employee,

Sorry, I hadn't looked into the doc in detail. I think it says this because in the example, a separate policy named "telnet" is created and this is applied to the outside interface. This will indeed not work for traffic entering over a VPN tunnel.

For tunneled traffic, the global policy should be used, so something like this:

access-list telnet extended permit tcp any any eq telnet

class-map telnet

description telnet

match access-list telnet

policy-map global_policy

class telnet

set connection timeout tcp 10:00:00 reset

service-policy global_policy global


This Discussion