Introduction
Two-factor authentication, or multifactor authentication, for VPN access has been around for a long time to ensure only trusted devices, personnel and consultants are able to access the corporate network from the outside. With the rise of smartphones in the past 10 years, there are now several authentication engines that leverage Push Notifications with simple Permit or Deny buttons that can be used to perform two-factor authentication without having the user to deal with One-Time Passwords (OTP) via SMS or code-generating apps.
Writer’s Update September 23rd, 2020 - starting with AnyConnect 4.8.02045 - the default authentication timeout has been increased from 12 seconds to 30 seconds as per TAC information and documented in TAC-case CSCve01989
Topology
This is the set of devices and services relevant to the point of this article:
The Problem
The first time I was tasked with implementing two-factor authentication using a Push Notification smartphone app I pretty quickly discovered that there was something wrong with my setup. I had a Cisco ASA-firewall (which users connect to over the internet) talking to a RADIUS-server which did lookups in an Active Directory using LDAP to validate users’ credentials. The RADIUS server also issued Push Notifications to users’ smartphones. The idea was that users first must log in using Active Directory credentials (username and password) and if those are correct then the RADIUS-server would send a Push Notification to the user’s smartphone, asking them to authenticate the session by pressing “Permit” on their smartphone app.
Sure thing I did get a push notification… and then another one… and another one. Before I even had the chance to “permit” the first Push Notification, I had already received another two of them.
It didn’t take too long to figure out that something was triggering multiple Push Notifications but nailing down where they came wrong wasn’t too obvious. Naturally, I started working my way through the ASA and trying different Timeouts and Retry timers for my RADIUS server and my RADIUS Group configuration. No matter how much I tinkered with this I was still getting sent too many Push Notifications sent to my smartphone every time I tried to log into the VPN.
Following the stream of packets
Next up, I fired up the Packet Capture tool in ASDM and caught the packets which would tell the truth of what was going on. You can see below what the packet capture looked like when opened in Wireshark.
Frame #1 is the result of me pressing Enter after I have entered my credentials in the AnyConnect VPN-client software. The ASA sends a RADIUS-request packet to the RADIUS-server with my credentials in it. Frame #2 shows the ASA doing a Retry of this request after 10 seconds have passed. This is because the Retry timeout of the RADIUS-server is configured to 10 seconds in ASA, which is the maximum number of seconds for Retry. It can only be configured for less, not more.
But then something else enters the flow of packets: another new RADIUS session. After approximately 12 seconds, another RADIUS-Request packet is sent from the ASA towards the RADIUS-server and it is using a different session-ID compared to the first RADIUS-sessions started in frame #1.
Another 8 seconds pass (for a total of 20 seconds since frame#1) and the ASA can be seen doing another Retry inside the first RADIUS session.
At 22 seconds we see the ASA doing a Retry of the second RADIUS session (12 + 10 seconds).
We see another 2 seconds pass and when the clock hits 24 seconds a third RADIUS session has appeared before us.
What is happening
Writer’s Update September 23rd, 2020 - starting with AnyConnect 4.8.02045 - the default authentication timeout has been increased from 12 seconds to 30 seconds as per TAC information and documented in TAC-case CSCve01989
Doing similar captures over and over again while changing timers on the ASA between every attempt, I could quickly narrow down that there was an interval of 12 seconds that kept showing up and creating new RADIUS sessions while others were still in progress. Throwing together “ASA VPN” and “12 seconds” on your favorite search engine will probably earn you the answer and that is that Cisco’s AnyConnect VPN-client software has an authentication timeout of 12 seconds (by default). That means that every 12 seconds, AnyConnect will re-send your credentials to the ASA, which in turn will send them to the RADIUS server, creating a whole new RADIUS session. If you fire up the VPN Profile Editor you can see this default value at the bottom of the Preferences (Part 2) window:
Effectively, the user will only have 12 seconds on them to unlock their smartphone, launch the app, and press “Permit” inside the app. Some two-factor authentication apps ever have passwords of their own, making it even harder for users to keep up.
The Solution
So, how do we increase the 12 seconds authentication timeout of AnyConnect? For corporate computers managed by your organization, you can simply create an AnyConnect VPN Profile using the VPN Profile Editor. In my case, I increased the Authentication Timeout to 120 seconds (which is the maximum value you can set according to the documentation) and after that, I had no trouble releasing this solution into the production network.
An important note is that changing the authentication timeout doesn’t take effect unless you configure it together with a pre-defined VPN server (the FQDN/DNS-name of the ASA VPN service). Please note that it has to be an FQDN that is defined in the VPN Profile, simply pre-filling the IP address of the outside interface of your ASA will not work!! This is a very odd and specific configuration that I assume is a bug that has been along for the ride for a long time based on what I’ve been reading online.
This solution isn’t all great though because VPN solutions are often used to grant access to consultants outside of your organization and usually you don’t have control of their computer. What you can do is create a VPN Profile directly in your ASA and assign it to the Group Policy that is to be used by consultants but the issue here is that the profile is not downloaded and activated until the consultant has performed a successful authentication first. This means the first login is gonna be a bit tough and short on time but once they get through it they will be able to download the VPN profile which increases the AnyConnect authentication timeout to whatever value your set it to in the profile (preferably 60 seconds or more).
How are One-Time Passwords solutions different?
Many of these two-factor authentication apps are also capable of generating One-Time Passwords inside the app instead of relying on Push Notifications. Some solutions use SMS to send out the OTP code to users. The OTP code is then entered into AnyConnect by the user after they have completed their first authentication (which validates their credentials towards an LDAP or AD-server).
To demonstrate this I have set up another AAA-server that is only using OTP-SMS to perform 2FA-authentication. The setup is as follows:
And when 2FA takes place using OTP-SMS instead of push notifications, the packet capture looks like this:
The big difference here is that the ASA receives a RADIUS Challenge packet from the RADIUS server after the user’s credentials have been verified. This packet makes the ASA tells AnyConnect that an additional piece of authentication needs to take place. Because of this, AnyConnect will know it has to wait for the user to input the OTP code and as a result will not re-send user credentials every 12 seconds.
Final words
Browsing the Cisco Support forums you can find quite a few discussions about how to deal with these kinds of 2FA/MFA solutions where timeouts are a pain in the butt and I thought it was worth taking a deep dive into the issue at hand and going through the steps of what is actually happening. Cisco has sort of acknowledged the weird issue with the Authentication Timeout in AnyConnect requiring an FQDN being present in the configuration, through the Knowledge Base article of their own 2FA/MFA product called Duo. You can see Duo’s statement on this issue on this link https://help.duo.com/s/article/1146?language=en_US