The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes Cisco AnyConnect Secure Mobility Client tunnels, the reconnect behavior and Dead Peer Detection (DPD), and inactivity timer.
There are two methods used in order to connect an AnyConnect session:
Based on the way you connect, you create three different tunnels (sessions) on the Cisco Adaptive Security Appliance (ASA), each one with a specific purpose:
Note: The AnyConnect-Parent represents the session when the client is not actively connected. Effectively, it works similar to a cookie, in that it is a database entry on the ASA that maps to the connection from a particular client. If the client sleeps/hibernates, the tunnels (IPsec/Internet Key Exchange (IKE)/ Transport Layer Security (TLS)/Datagram Transport Layer Security (DTLS) protocols) are torn down, but the Parent remains until the idle timer or maximum connect time takes effect. This allows the user to reconnect without reauthenticating.
Here is sample output from the two connection methods.
AnyConnect Connected via Web-launch:
ASA5520-C(config)# show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed
Username : walter Index : 1435
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Protocol : Clientless SSL-Tunnel DTLS-Tunnel
License : AnyConnect Premium
Encryption : Clientless: (1)RC4 SSL-Tunnel: (1)RC4 DTLS-Tunnel: (1)AES128
Hashing : Clientless: (1)SHA1 SSL-Tunnel: (1)SHA1 DTLS-Tunnel: (1)SHA1
Bytes Tx : 335765 Bytes Rx : 31508
Pkts Tx : 214 Pkts Rx : 18
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : My-Network Tunnel Group : My-Network
Login Time : 22:13:37 UTC Fri Nov 30 2012
Duration : 0h:00m:34s
Inactivity : 0h:00m:00s
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
Clientless Tunnels: 1
SSL-Tunnel Tunnels: 1
DTLS-Tunnel Tunnels: 1
Clientless:
Tunnel ID : 1435.1
Public IP : 172.16.250.17
Encryption : RC4 Hashing : SHA1
Encapsulation: TLSv1.0 TCP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : Web Browser
Client Ver : Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Bytes Tx : 329671 Bytes Rx : 31508
SSL-Tunnel:
Tunnel ID : 1435.2
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : RC4 Hashing : SHA1
Encapsulation: TLSv1.0 TCP Src Port : 1241
TCP Dst Port : 443 Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : SSL VPN Client
Client Ver : Cisco AnyConnect VPN Agent for Windows 3.1.01065
Bytes Tx : 6094 Bytes Rx : 0
Pkts Tx : 4 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
DTLS-Tunnel:
Tunnel ID : 1435.3
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : AES128 Hashing : SHA1
Encapsulation: DTLSv1.0 Compression : LZS
UDP Src Port : 1250 UDP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : DTLS VPN Client
Client Ver : Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Bytes Tx : 0 Bytes Rx : 0
Pkts Tx : 0 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
AnyConnect Connected via the Standalone Application:
ASA5520-C(config)# show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed
Username : walter Index : 1436
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Protocol : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
License : AnyConnect Premium
Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)RC4 DTLS-Tunnel: (1)AES128
Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA1 DTLS-Tunnel: (1)SHA1
Bytes Tx : 12244 Bytes Rx : 777
Pkts Tx : 8 Pkts Rx : 1
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : My-Network Tunnel Group : My-Network
Login Time : 22:15:24 UTC Fri Nov 30 2012
Duration : 0h:00m:11s
Inactivity : 0h:00m:00s
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
AnyConnect-Parent Tunnels: 1
SSL-Tunnel Tunnels: 1
DTLS-Tunnel Tunnels: 1
AnyConnect-Parent:
Tunnel ID : 1436.1
Public IP : 172.16.250.17
Encryption : none Hashing : none
TCP Src Port : 1269 TCP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : AnyConnect
Client Ver : 3.1.01065
Bytes Tx : 6122 Bytes Rx : 777
Pkts Tx : 4 Pkts Rx : 1
Pkts Tx Drop : 0 Pkts Rx Drop : 0
SSL-Tunnel:
Tunnel ID : 1436.2
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : RC4 Hashing : SHA1
Encapsulation: TLSv1.0 TCP Src Port : 1272
TCP Dst Port : 443 Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : SSL VPN Client
Client Ver : Cisco AnyConnect VPN Agent for Windows 3.1.01065
Bytes Tx : 6122 Bytes Rx : 0
Pkts Tx : 4 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
DTLS-Tunnel:
Tunnel ID : 1436.3
Assigned IP : 192.168.1.4 Public IP : 172.16.250.17
Encryption : AES128 Hashing : SHA1
Encapsulation: DTLSv1.0 Compression : LZS
UDP Src Port : 1280 UDP Dst Port : 443
Auth Mode : userPassword
Idle Time Out: 2 Minutes Idle TO Left : 1 Minutes
Client Type : DTLS VPN Client
Client Ver : 3.1.01065
Bytes Tx : 0 Bytes Rx : 0
Pkts Tx : 0 Pkts Rx : 0
Pkts Tx Drop : 0 Pkts Rx Drop : 0
The session is considered Inactive (and the timer begins to increase) only when the SSL-Tunnel does not exist anymore in the session. So, each session is time-stamped with the SSL-Tunnel drop time.
ASA5520-C# show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed
Username : walter Index : 1336
Public IP : 172.16.250.17
Protocol : AnyConnect-Parent <- Here just the AnyConnect-Parent is active
but not SSL-Tunnel
License : AnyConnect Premium
Encryption : AnyConnect-Parent: (1)none
Hashing : AnyConnect-Parent: (1)none
Bytes Tx : 12917 Bytes Rx : 1187
Pkts Tx : 14 Pkts Rx : 7
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : My-Network Tunnel Group : My-Network
Login Time : 17:42:56 UTC Sat Nov 17 2012
Duration : 0h:09m:14s
Inactivity : 0h:01m:06s <- So the session is considered Inactive
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
There are two ways that an SSL-Tunnel can be disconnected:
anyconnect dpd-interval command under the WebVPN attributes in the group-policy settings. By default, the DPD is enabled and set to 30 seconds for both the ASA (gateway) and the client.Caution: Be aware of Cisco bug ID CSCts66926 - DPD fails to terminate DTLS tunnel after lost client connection.
As explained previously, the DPD does not kill the AnyConnect session itself. It merely kills the tunnel within that session so that the client can reestablish the tunnel. If the client cannot reestablish the tunnel, the session remains until the idle timer expires on the ASA. Since DPDs are enabled by default, clients can often get disconnected due to flows closing in one direction with Network Address Translation (NAT), Firewall and Proxy devices. Enabling keepalives at low intervals, such as 20 seconds, helps to prevent this.
Keepalives are enabled under the WebVPN attributes of a particular group-policy with the anyconnect ssl keepalive command. By default, the timers are set to 20 seconds.
AnyConnect attempts to reconnect if the connection is disrupted. This is not configurable, automatically. As long as the VPN session on the ASA is still valid and if AnyConnect can re-establish the physical connection, the VPN session is resumed.
The reconnect feature continues until the session timeout or the disconnect timeout, which is actually the idle timeout, expires (or 30 minutes if no timeouts are configured). Once these expire, the client cannot continue because the VPN sessions have already been dropped on the ASA. The client continues as long as it thinks the ASA still has the VPN session.
AnyConnect reconnects no matter how the network interface changes. It does not matter if the IP address of the Network Interface Card (NIC) changes, or if connectivity switches from one NIC to another NIC (wireless to wired or vice versa).
When you consider the reconnect process for AnyConnect, there are three levels of sessions that you must remember. Additionally, the reconnect behavior of each of these sessions is loosely coupled, in that any of them can be re-established without a dependency on the session elements of the previous layer:
Tip: These ASA releases and later contain a stronger cryptographic session token: 9.1(3) and 8.4(7.1)
A Disconnect Timeout timer is started as soon as the network connection is disrupted. The AnyConnect client continues to try to reconnect as long as this timer does not expire. The Disconnect Timeout is set to the lowest setting of either the Group Policy Idle-Timeout or the Maximum Connect Time.
The value of this timer is seen in the Event Viewer for the AnyConnect session in the negotiation:
AnyConnect Reconnect Behavior - Session Timeout, Disconnect Timeout, and Idle Timeout values in Event Viewer
In this example, the session disconnects after two minutes (120 seconds), which can be checked in the Message History of the AnyConnect:
AnyConnect Reconnect Behavior - Session disconnect logs in AnyConnect Message History
Tip: For the ASA to respond to a client that attempts to reconnect, the Parent-Tunnel session must still exist in the ASA database. In the event of failover, DPDs also need to be enabled for the reconnect behavior to work.
As is visible from the previous messages, the reconnect failed. However, if the reconnect is successful, here is what happens:
Caution: Be aware of Cisco bug ID CSCtg33110. The VPN session database does not update the Public IP address in the ASA session database when AnyConnect reconnects.
In this situation where the attempts to reconnect fail, you encounter this message:
AnyConnect Reconnect Behavior - User Error message on reconnect failure
Note: This enhancement request has been filed in order to make this more granular: Cisco bug ID CSCsl52873 - ASA does not have a configurable disconnected timeout for AnyConnect.
There is a roaming feature that allows AnyConnect to reconnect after a PC sleep. The client continues to try until the idle or session timeouts expire and the client does not immediately tear down the tunnel when the system goes into hibernate/standby. For users who do not want this feature, set the session timeout to a low value in order to prevent sleep/resume reconnects.
Note: After the fix of Cisco bug ID CSCso17627 (Version 2.3(111)+), a control knob was introduced in order to disable this reconnect on resume feature.
The Auto-Reconnect behavior for AnyConnect can be controlled through the AnyConnect XML profile with this setting:
<AutoReconnect UserControllable="true">true
<AutoReconnectBehavior>ReconnectAfterResume</AutoReconnectBehavior>
</AutoReconnect>
With this change, AnyConnect tries to reconnect when the computer is brought back from sleep. The AutoReconnectBehavior preference defaults to DisconnectOnSuspend. This behavior is different from that of AnyConnect Client Release 2.2. For reconnect after resume, the network administrator must either set ReconnectAfterResume in the profile or make the AutoReconnect and AutoReconnectBehavior preferences user controllable in the profile to allow users to set it.
A. From the client perspective, DPDs only tear down a tunnel during the tunnel establishment stage. If the client encounters three retries (sends four packets) during the tunnel establishment stage and does not receive a response from the primary VPN server, it falls back to using one of the back up servers if one is configured. However, once the tunnel has been established, missed DPDs do not have any impact on the tunnel from the client's perspective. The real impact of DPDs is on the VPN server as explained in the section DPDs and Inactivity Timers.
A. Yes, IKEv2 has a fixed number of retries - six retries/seven packets.
A. In addition to being a mapping on the ASA, the parent tunnel is used in order to push AnyConnect image upgrades from the ASA to the client, because the client is not actively connected during the upgrade process.
A. You can filter inactive sessions with the show vpn-sessiondb anyconnect filter inactive command. However, there is no command to log off just inactive sessions. Instead, you need to log off specific sessions or log off all sessions per user (index - name), protocol, or tunnel-group. An enhancement request, Cisco bug ID CSCuh55707 , has been filed in order to add the option to log off just the inactive sessions.
A. The Idle TO Left timer of the AnyConnect-Parent session is reset after either the SSL-Tunnel or DTLS-Tunnel is torn down. This allows the idle-timeout to act as a disconnected timeout. This effectively becomes the allowable time for the client to reconnect. If the client does not reconnect within the timer, then the Parent-Tunnel is terminated.
A. The head-end has no knowledge of the client's state. In this case, the ASA waits for the client to hopefully reconnect until the session times out upon the idle timer. DPD does not kill an AnyConnect session; it merely kills the tunnel (within that session) so that the client can reestablish the tunnel. If the client does not reestablish a tunnel, the session remains until the idle timer expires.
If the concern is about sessions that are used up, set simultaneous-logins to a low value such as one. With this setting, users who have a session in the session database have their prior session deleted when they log in again.
A. Initially, when the session is established, the three tunnels (Parent, SSL, and DTLS) are replicated to the Standby Unit. Once the ASA fails over, the DTLS and the TLS sessions are reestablished as they are not synced to the standby unit, but any data that flows through the tunnels must work without disruption after the AnyConnect session is reestablished.
SSL/DTLS sessions are not stateful, so the SSL state and sequence number are not maintained and can be quite taxing. Thus, those sessions need to be reestablished from scratch, which is done with the Parent session and the session token.
Tip: In the event of a failover, SSL VPN client sessions are not carried over to the standby device if keepalives are disabled.
A. When the protocols were developed, two different timeouts were provided for:
The disconnected timeout was never implemented on the ASA. Instead, the ASA sends the idle timeout value for both the idle and disconnected timeouts to the client.
The client does not use the idle timeout, because the ASA handles the idle timeout. The client uses the disconnected timeout value, which is the same as the idle timeout value, in order to know when to give up reconnect attempts since the ASA has dropped the session.
While not actively connected to the client, the ASA times out the session via the idle timeout. The primary reason to not implement the disconnected timeout on the ASA was to avoid the addition of another timer for every VPN session and the increase in overhead on the ASA (although the same timer could be used in both instances, just with different timeout values, since the two cases are mutually exclusive).
The only value added with the disconnected timeout is to allow an administrator to specify a different timeout for when the client is not actively connected versus idle. As noted earlier, Cisco bug ID CSCsl52873 has been filed for this.
A. By default, AnyConnect does attempt to re-establish a VPN connection when you lose connectivity. It does not attempt to re-establish a VPN connection after a system resume by default. Refer to AnyConnect Client Behavior in Case of System Suspend for details.
A. A tunnel-level reconnect does not do either. This is a reconnect on just SSL or DTLS. These go about 30 seconds before they give up. If DTLS fails, it is just dropped. If SSL fails, it causes a session-level reconnect. A session-level reconnect completely redoes the routing. If the client address assigned on the reconnect, or any other configuration parameters that impact the Virtual Adapter (VA), have not changed, then the VA is not disabled. While it is unlikely to have any change in the configuration parameters received from the ASA, it is possible that a change in the physical interface used for the VPN connection (for example, if you undock and go from wired to WiFi) could result in a different Maximum Transmission Unit (MTU) value for the VPN connection. The MTU value impacts the VA, and a change to it causes the VA to be disabled and then re-enabled.
A. AnyConnect does not provide any extra magic to accommodate session persistence for applications. But VPN connectivity is restored automatically, shortly after network connectivity to the secure gateway resumes, provided the idle and session timeouts configured on the ASA have not expired. And unlike the IPsec client, the automatic reconnect results in the same client IP address. While AnyConnect attempts to reconnect, the AnyConnect Virtual Adapter remains enabled and in the connected state, so the client IP address remains present and enabled on the client PC the entire time, which gives client IP address persistence. The client PC applications, however, still perceive the loss of connectivity to their servers on the enterprise network if it takes too long for VPN connectivity to be restored.
A. This feature does work on Mac and Linux. There have been issues with Mac and Linux, but recent improvements have been made, particularly for the Mac. Linux still requires some additional support (Cisco bug ID CSCsr16670, Cisco bug ID CSCsm69213), but the basic functionality is there as well. With regards to Linux, AnyConnect does not recognize that a suspend/resume (sleep/wake) has occurred. This basically has two impacts:
A. AnyConnect is not tied to a particular physical interface for the life of the VPN connection. If the physical interface used for the VPN connection is lost or if reconnect attempts over it exceed a certain failure threshold, then AnyConnect no longer uses that interface and attempt to reach the secure gateway with whatever interfaces are available until the idle or session timers expire. Note that a change in physical interface could result in a different MTU value for the VA, which cause the VA to have to be disabled and re-enabled, but still with the same client IP address.
If there is any network disruption (interface down, changed networks, changed interfaces), AnyConnect tries to reconnect; no re-authentication is needed on reconnect. This even applies to a switch of physical interfaces:
Example:
1. wireless off, wired on: AC connection established
2. disconnect wired physically, turn wired on: AC re-established connection in
30 seconds
3. connect wired, turn off wireless: AC re-established connection in 30 secs
A. In a resume, you resubmit the authenticated token that remains for the lifetime of the session, and the session is then re-established.
A. This is only performed in the initial connection.
A. No, these run on the initial connection only. Something like this would be slated for the future Periodic Posture Assessment feature.
A: Yes, this is correct since you do not re-resolve the hostname via DNS for re-establishment of a current session.
| Revision | Publish Date | Comments |
|---|---|---|
3.0 |
22-Dec-2023 |
Updated Alt Text, Machine Translation and Formatting. |
2.0 |
22-Nov-2022 |
Updated title and introduction, machine translation, style requirements, gerunds, and formating. |
1.0 |
13-Aug-2021 |
Initial Release |