ASA5510 - Maximum connect time

[James Walsh]

Quick question.  I have configured the "Maximum Connect Time" as unlimited in my group policy but when a connection is established it shows a "Conn Time Out: 120 minutes".

The connection does get dropped with this timer.  Any idea how to actually make it unlimited and why it get sets to 120?

I having a problem with SSL phone clients dropping throughout the day and think this may be the cause.

Thanks

[Jennifer Halim]

Can you please share the output of:

show run group-policy

as well as a screenshot of where it says "Conn Time Out: 120 minutes" pls.

And lastly after you are connected via SSL VPN, please obtain the output of:

show vpn-sessiondb detail svc filter name

Thanks.

[James Walsh]

Thanks Jennifer. 

All the requested outputs are attached.

[Jennifer Halim]

Seems like it's taking the default value instead of the modified value under group-policy phonevpn.

What authentication server are you using? and are you also doing ldap attribute mapping? can you share the full configuration pls?

[James Walsh]

that's exactly what we are seeing.  config attached.  any help is appreciated.

[Jennifer Halim]

Config looks perfect.

Can you try the following pls:

group-policy phonevpn attributes
  no vpn-session-timeout none

  vpn-session-timeout 35791394

That's 35791394 minutes == about 68 years.

[James Walsh]

I've tried that... but only did 720 minutes.  Didn't change. Reconnected and "Conn Time Out: 120 Minutes".  It's won't go higher than that.

any ideas?

[Jennifer Halim]

Sounds like a bug to me..

What about other group-policy (eg: salientvpn), can you try to connect and see if that has the same issue as that group-policy also has "vpn-session-timeout none" configured?

What about create a new tunnel-group and group-policy with the "vpn-session-timeout none", and see if that makes any difference.

[James Walsh]

It's happening on multiple policies from both phone clients and anyconnect on PC's.

I am with you.  I think it's a bug and am working with TAC right now.  If you have any more thoughts I would love to hear them.

Thanks for all your help!

[Jennifer Halim]

You wouldn't by any chance have reloaded the ASA, have you?

[James Walsh]

No I have not.  Worth a shot?

[Jennifer Halim]

If it's happening on some policies, but not all, then I would suggest reloading the ASA. But if it's happening to all policies, then I would tend to think it's 99% a bug.

You might also want to try upgrading to the latest version of 8.2.x.

[James Walsh]

I ended up rebooting the ASA this morning and it fixed the issue.  Right away the timeout changed to what I had configured it to be and I was also able to make changes.

Here's the response from TAC.  Thanks for helping with this.  Much appreciated.

"I am glad that the issue was resolved on a reboot. Might be that svc sessions were stuck in the memory for some reason and the same sessions would be invoked every time you connected rather than tearing it down and creating a new svc session.

Once rebooted I believe the sessions stuck in memory were cleared and new sessions came up as a result the issue vanished. I shall surely update you as I have an update from the devs on this."

[Jennifer Halim · Accepted solution]

Great news. The "old" reboot trick solves the issue.

Please kindly mark your post as answered and rate useful posts so others can learn from your experience too. Thank you.

[todd_coughlin]

I know this is an old thread, but I just got done troubleshooting and issue just like this. Some had actually changed the session-timeout setting on our RADIUS server (Mircosoft IAS on Server 2003). This setting would override the vpn-session-timeout on our ASA. We banged our heads for hours on this one!