Premature timeout using Cisco AnyConnect with Phonefactor 2-factor authentication

Unanswered Question

We have an ASA 5510 that handles our vpn client traffic, and occasionally, we run into a client that, while using Cisco AnyConnect in conjunction with Phonefactor, the connection attempt will timeout before the connection actually establishes.

The odd thing is - The logs show the client finished connecting, and the Phonefactor server shows completed authentication.  We even added a custom timeout script to increase the default 12 second timeout to 30 seconds.

This behavior has proven difficult to find a common factor for, as it has affected different versions of the client, 2.3 and 2.5, as well as Windows XP, Vista and 7 installs. 

This problem does not affect our Anyconnect/RSA clients, and if the same person on the same client with the issue is migrated over to the Cisco IPSec vpn, the problem disappears.

Has anyone encountered this issue before?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
sl_bishop Wed, 11/02/2011 - 13:46
User Badges:

By default, AnyConnect waits up to 12 seconds for an authentication from the ASA before terminating the connection attempt.  AnyConnect then displays a message indicating the authentication timed out.  Cisco added the ability to configure that timeout last year in version 2.5.1025.  You can see the release notes describing the "Authentication Timeout Control" at

Support for this feature requires either an AnyConnect Essentials or an AnyConnect Premium SSL VPN Edition license.  This feature is supported on all OSs supported by AnyConnect.  However, I have heard from a couple of PhoneFactor customers that there is an issue in the Mac client that causes it to ignore the configured timeout if it is set to anything higher than 30 seconds.  I have also heard reports of the iPad client ignoring the timeout. 

The AnyConnect profile lets you specify the authentication timeout value in the range 10-120 seconds.  To use the Profile Editor to change the authentication timer, open the Preferences (cont) window and enter the number of seconds into the Authentication Timeout Values field.  Alternatively, you can use a text editor to add the XML tag to the AnyConnect profile.

The following example sets the authentication timeout to 45 seconds:


Also, when you configure the ASA to send a RADIUS request to PhoneFactor, you have to set the RADIUS timeout there as well so that the ASA doesn't time out waiting for a response from PhoneFactor.  So, both the ASA and the AnyConnect client need to have a high enough time out for the call to take place and get a response.

If your timeout is set to 30 seconds, that might not quite be long enough for some clients to receive the phone call and respond, especially if the user doesn't answer their primary phone number and PhoneFactor has to call the user's backup number.  I would recommend setting the timeout to 45 seconds unless dealing with the Mac client issue mentioned above.


Weare indeed using AnyConnect essentials, and have already increased the timeout to 30 seconds, the maximum on the phonefactor server.  The timeout occurs within 10 seconds for those clients suffering the issue, which is what is stumping everyone.  This unusual timeout is occuring in well under 30 seconds.

For those not experiencing this issue, the 30 second timeout has presented no problem.

From the user's point of view, they initial the tunnel, enter their username and password, and no sooner has the phone rung from the Phonefactor Agent than the client shows a disconnect, yet the RADIUS logs show a successful authentication.

The hardest part of this is being able to retain a laptop that experiences this, in order to duplicate the issue for TAC.



sl_bishop Wed, 11/02/2011 - 14:06
User Badges:

The clients experiencing the issue are obviously ignoring or not understanding the timeout set in the AnyConnect profile, and therefore timeout before PhoneFactor even responds to the ASA.  PhoneFactor completes the authentication and sends a RADIUS ACCEPT back to the ASA, but the client has already stopped waiting for a response by that time.  You mention above that the clients with problems have been v2.3 and 2.5.  Since the Authentication Timeout setting was added to 2.5.1025, I wouldn't expect it to work on 2.3, and it is possible that the 2.5 clients with problems are older than 2.5.1025 as well.  If the clients are at 2.5.1025 or newer, they should accept and recognize the Authentication Timeout set in the AnyConnect profile.

sl_bishop Fri, 11/04/2011 - 12:22
User Badges:

If any of your users are using the Apple iOS AnyConnect client, they will need v2.5 of the client.  That client was just recently released and older versions of the client have the hard-coded 12-second timeout.

bj2001holt Thu, 12/15/2011 - 16:23
User Badges:

I am running clients with 2.5.3055 and experiencing this exact same issue on OSX 10.6.8. The client is using phonefactor for authentication. When logging in from the web portal there are no issues with authentication. However when launching the anyconnect client directly the timeout appears to be ignored. I have adjusted the Authentication Timeout Value in the anyconnect profile to 120sec but the end-clients do not appear to be recognizing the setting.

We have not experienced the issue with any Windows PCs yet.

sl_bishop Fri, 12/16/2011 - 07:44
User Badges:

I have heard from a couple of PhoneFactor customers that there is an issue in the Mac client that causes it to ignore the configured timeout if it is set to anything higher than 30 seconds.  Try setting the authentication timeout in the AnyConnect profile back from 120 seconds to 30 seconds and see if it works for the Mac clients.

bj2001holt Fri, 12/16/2011 - 09:42
User Badges:

Adjusted down to 30 seconds and same result. The Anyconenct client timesout at 12 seconds. It would appear that the Mac version of the client ignores the authentication timeout setting completly. I have tested with 10.6 and 10.7 Apple OS now with the same result.

sl_bishop Mon, 12/19/2011 - 12:49
User Badges:

Cisco has told us (PhoneFactor) that some fixes for the authentication timeout went into v3.0.4 of the AnyConnect client.  I recommend upgrading to that version to see if that works for the Mac clients.

bj2001holt Tue, 12/20/2011 - 13:20
User Badges:

Attempted to use version 3.0.4235 with no success. In fact the 3.0.4 version actually broke the policy on Windows PCs as well. I tried the 30 second and 120 second settings under the 3.0.4 software, neither made any adjustment in the timeout.

sl_bishop Tue, 12/20/2011 - 13:41
User Badges:

At this point, I recommend contacting Cisco support about this issue.  Our contact at Cisco has also told us that if we can provide a DART log bundle, they can look into the issue.  If you would rather try that, please call PhoneFactor's main line at 913-499-4100 and ask for me.  We can connect and exchange email addresses so that you can send us your DART log bundle.

BK Rogers Thu, 01/17/2013 - 14:12
User Badges:

OK, I may have an answer to this because I stumbled my way through it with some help from the DART Logs.

It appears when the AnyConnect client starts a VPN connection the client will only apply profile parameters to connections with the host name listed in the Servers section.  So even if the profile downloads and the is defined, if the ASA is not defined as a HostEntry in the Server List of the client profile, the client profile will not be applied at connect time.

The section you need in the client profile looks like...



      Your ASA

      FQDN referenced in VPN Clients



You can edit this in the AnyConnect profile editor, Server List, Add Host Name.

Also profiles are pushed down after a successful VPN connect.  So you either have to push the profile to the AnyConnect client before you start two factoring, manually copy the file, or have end users be real quick the first time.

BK Rogers

Mike Hochstein Mon, 10/21/2013 - 08:51
User Badges:

Thanks - Adding in host name and host address forced the new/longer timeout for me as well.

dclangst1 Mon, 06/30/2014 - 12:40
User Badges:

I know this is an old thread but we ran into it recently as well.  In our case, our 2nd factor was a third party.  It took exactly 12 seconds for you to authenticate against both factors, the phone to ring, and the keypad on a mobile device to become available.  It would time out before all that.  What we did was increase the timeout on the default context without 2 factor.  You might now have one, but we're a school and we have a number different VPN contexts.  Once users connected to the one without 2 factor with the longer time out, they were then able to connect to two factor since the default one didn't cut them off too soon.  That also gave them time to get the two-factor xml file pushed down.  Hope that helps other people.


This Discussion

Related Content