AnyConnect Operation and Options on Mobile Devices
About AnyConnect Mobile VPN Connections
This release of the AnyConnect Secure Mobility Client is available on the following mobile platforms:
-
Android
-
Apple iOS
-
Chromebook
-
Windows Phone
AnyConnect Secure Mobility Client is provided on the app store for each supported platform. It is not available on www.cisco.com or distributed from a secure gateway.
AnyConnect mobile apps contain the core VPN client only. They do not include other AnyConnect modules such as the Network Access Manager or Posture (VPN Posture or System Scan). Posture information, referred to as Mobile Posture, is provided to the headend using AnyConnect Identifier Extensions (ACIDex) when the VPN is connecting.
AnyConnect VPN connection can be established in one of the following ways:
-
Manually by a user.
-
Manually by the user when they click an automated connect action provided by the administrator (Android and Apple iOS only).
-
Automatically by the Connect On-Demand feature (Apple iOS only).
AnyConnect VPN Connection Entries on Mobile Devices
A connection entry identifies the address of the secure gateway by its fully qualified domain name or IP address, including the tunnel group URL if required. It can also include other connection attributes.
AnyConnect supports multiple connection entries on a mobile device addressing different secure gateways and/or VPN tunnel groups. If multiple connection entries are configured, it is important that the user knows which one to use to initiate the VPN connection. Connection entries are configured in one of the following ways:
-
Manually configured by the user. See the appropriate platform user guide for procedures to configure a connection entry on a mobile device.
-
Added after the user clicks a link provided by the administrator to configure connection entries.
See Generate a VPN Connection Entry to provide this kind of connection entry configuration to your users.
-
Defined by the AnyConnect VPN Client Profile.
The AnyConnect VPN Client Profile specifies client behavior and defines VPN connection entries. For details refer to Configure Mobile Device Connections in the AnyConnect VPN Profile.
Tunneling Modes
AnyConnect can operate in a managed or an unmanaged BYOD environment. VPN tunneling in these environments operates exclusively in one of the following modes:
-
System-tunneling mode—The VPN connections are used to tunnel all data (full-tunneling), or only data flowing to and from particular domains or addresses (split-tunneling). This mode is available on all mobile platforms.
-
Per-App VPN mode—The VPN connection is used for a specific set of apps on the mobile device (Android and Apple iOS only).
AnyConnect allows the set of apps defined by the administrator on the headend. This list is defined using the Secure Firewall ASA Custom Attributes mechanism. This list is sent to AnyConnect and enforced on the device. For all other apps, data is sent outside of the tunnel or in the clear.
On Apple iOS, a managed environment is required to run in this mode. On Android, both managed and unmanaged environments are supported. On both platforms, in a managed environment, the Mobile Device Manager must also configure the device to tunnel the same list of apps that AnyConnect is configured to tunnel.
-
Multi-tunnel—AnyConnect on iOS supports multiple tunnels with the following patterns: -
One regular (without Per-App) VPN tunnel and one or more Per-App tunnels connected at a time
-
Multiple Per-App VPN tunnels connected at a time
Refer to Multiple Tunnel for iOS for additional information.
-
AnyConnect operates in the mode determined by the configuration information received from the Secure Firewall ASA headend: specifically, the presence or absence of a Per-App VPN list in the Group Policy or Dynamic Access Policy (DAP) associated with the connection. If the Per-App VPN list is present, AnyConnect operates in Per-App VPN mode; if it is absent, AnyConnect operates in system-tunneling mode.
Multiple Tunnel for iOS
A user can only manually start a VPN connection for one tunnel (either without per-app VPN or with per-app VPN). Because per-app VPN automatically starts with the associated application, you must add a MultiTunnel key and set it as true in VendorConfig of the MDM VPN profile to use multi-tunnel.
In the iOS AnyConnect home screen, you will see a table showing the selected tunnel, regardless of whether it is connected or not. A second table is dynamic and only appears when per-app VPN is connected. This second table only shows the connection status of per-app tunnels, until the user clicks Status to see Detailed Statistics of the connection with bytes received and sent.
You can refer to Diagnostics for a log of the currently selected regular VPN. When a user decides to share logs, the log package includes all VPN debug log files for the connected VPN configurations.
Secure Gateway Authentication on Mobile Devices
Block Untrusted Servers
When establishing a VPN connection, AnyConnect uses the digital certificate received from the secure gateway to verify the server's identify. If the server certificate is invalid (there is a certificate error due to an expired or invalid date, wrong key usage, or a name mismatch), or if it is untrusted (the certificate cannot be verified by a Certificate Authority), or both, the connection is blocked. A blocking message displays, and the user must choose how to proceed.
The Block Untrusted Servers application setting determines how AnyConnect reacts if it cannot identify the secure gateway. This protection is ON by default; it can be turned OFF by the user, but this is not recommended.
When Block Untrusted Servers is ON, a blocking Untrusted VPN Server notification alerts the user to this security threat. The user can choose:
-
Keep Me Safe to terminate this connection and remain safe.
-
Change Settings to turn the Block Untrusted Servers application preference OFF, but this is not recommended. After the user disables this security protection, they must reinitiate the VPN connection.
When Block Untrusted Servers is OFF, a non-blocking Untrusted VPN Server notification alerts the user to this security threat. The user can choose to:
-
Cancel the connection and remain safe.
-
Continue the connection, but this is not recommended.
-
View Details of the certificate to visually determine acceptability.
If the certificate that the user is viewing is valid but untrusted, the user can:
-
Import the server certificate into the AnyConnect certificate store for future use and continue the connection by selecting Import and Continue.
Once this certificate is imported into the AnyConnect store, subsequent connections made to the server using this digital certificate are automatically accepted.
-
Go back to the previous screen and choose Cancel or Continue.
If the certificate is invalid, for any reason, the user can only return to the previous screen and choose Cancel or Continue.
-
Leaving the Block Untrusted Servers setting ON (default setting), having a valid and trusted server certificate configured on your secure gateway, and instructing your mobile users to always choose Keep Me Safe is the safest configuration for VPN connectivity to your network.
![]() Note |
Strict Certificate Trust overrides this setting, see description below. |
OCSP Revocation
AnyConnect supports OCSP (Online Certificate Status Protocol). This allows the client to query the status of individual certificates in real time by making a request to the OCSP responder and parsing the OCSP response to get the certificate status. OCSP is used to verify the entire certificate chain. There is a five second timeout interval per certificate to access the OCSP responder.
The user can enable or disable OCSP verification in the AnyConnect settings activity. We have also added new APIs in our framework which can be used by MDM administrators to control this feature remotely. Currently we support Samsung and Google MDM.
Strict Certificate Trust
If enabled by the user, when authenticating remote security gateways, AnyConnect disallows any certificate that it cannot verify. Instead of prompting the user to accept these certificates, the client fails to connect to security gateways.
![]() Note |
This setting overrides Block Untrusted Server. |
If not selected, the client prompts the user to accept the certificate. This is the default behavior.
We strongly recommend that you enable Strict Certificate Trust with AnyConnect for the following reasons:
-
With the increase in targeted exploits, enabling Strict Certificate Trust in the local policy helps prevent “man in the middle” attacks when users are connecting from untrusted networks such as public-access networks.
-
Even if you use fully verifiable and trusted certificates, AnyConnect, by default, allows end users to accept unverifiable certificates. If your end users are subjected to a man-in-the-middle attack, they may be prompted to accept a malicious certificate. To remove this decision from your end users, enable Strict Certificate Trust.
Client Authentication on Mobile Devices
To complete a VPN connection, the user must authenticate by providing credentials in the form of a username and password, a digital certificate, or both. The administrator defines the authentication method on the tunnel group. For the best user experience on mobile devices, Cisco recommends using multiple AnyConnect connection profiles depending on the authentication configuration. You will have to decide how best to balance user experience with security. We recommend the following:
-
For AAA-based authentication tunnel groups for mobile devices, the group policy should have a very long idle timeout, such as 24 hours, to let the client remain in a reconnecting state without requiring the user to re-authenticate.
-
To achieve the most transparent end user experience, use certificate-only authentication. When a digital certificate is used, a VPN connection is established without user interaction.
In order to authenticate the mobile device to the secure gateway using a certificate, end users must import a certificate onto their device. This certificate is then available for automatic certificate selection, or it can be associated with a particular connection entry manually. Certificates are imported using the following methods:
-
Imported manually by the user. See the appropriate user guide for procedures to import certificates to your mobile device.
-
Using SCEP. See Configure Certificate Enrollment for details.
-
Added after the user clicks a link provided by the administrator to import a certificate.
See Import Certificates to provide this kind of certificate deployment to your users.
Localization on Mobile Devices
AnyConnect Secure Mobility Client for Android and Apple iOS supports localization, adapting the AnyConnect Secure Mobility Client user interface and messages to the user’s locale.
Prepackaged Localization
The following language translations are included in the AnyConnect Secure Mobility Client Android and Apple iOS apps:
-
Canadian French (fr-ca)
-
Chinese (Taiwan) (zh-tw)
-
Czech (cs-cz)
-
Dutch (nl-nl)
-
French (fr-fr)
-
German (de-de)
-
Hungarian (hu-hu)
-
Italian (it-it)
-
Japanese (ja-jp)
-
Korean (ko-kr)
-
Latin American Spanish (es-co)
-
Polish (pl-pl)
-
Portuguese (Brazil) (pt-br)
-
Russian (ru-ru)
-
Simplified Chinese (zh-cn)
-
Spanish (es-es)
Localization data for these languages is installed on the mobile device when AnyConnect Secure Mobility Client is installed. The locale specified on your mobile device determines the displayed language. AnyConnect uses the language specification, then the region specification, to determine the best match. For example, after installation, a French-Switzerland (fr-ch) locale setting results in a French-Canadian (fr-ca) display. AnyConnect UIs and messages are translated when AnyConnect starts.
Downloaded Localization
For languages not in the AnyConnect package, administrators add localization data to the Secure Firewall ASA to be downloaded to the device upon AnyConnect VPN connectivity.
Cisco provides the anyconnect.po file, including all localizable AnyConnect strings, on the product download center of Cisco.com. AnyConnect administrators download the anyconnect.po file, provide translations for the available strings, and then upload the file to the Secure Firewall ASA. AnyConnect administrators that already have an anyconnect.po file installed on the Secure Firewall ASA will download this updated version.
Initially, the AnyConnect user interface and messages are presented to the user in the installed language. When the device user establishes the first connection to the Secure Firewall ASA, AnyConnect compares the device’s preferred language to the available localization languages on the Secure Firewall ASA. If AnyConnect finds a matching localization file, it downloads the localized file. Once the download is complete, AnyConnect presents the user interface and user messages using the translated strings added to anyconnect.po file. If a string was not translated, AnyConnect presents the default English strings.
See Import Translation Tables to the Secure Firewall ASA for instructions on configuring localization on an Secure Firewall ASA. If the Secure Firewall ASA does not contain localization data for the device’s locale, the preloaded localization data from the AnyConnect application package continues to be used.
More Ways to Provide Localization on Mobile Devices
Localize the AnyConnect UI and Messages by providing a URI link to the user.
Ask your mobile device users to manage localization data on their own device. See the appropriate User Guide for procedures to perform the following localization activities:
-
Import localization data from a specified server. The user chooses to import localization data and specifies the address of the secure gateway and the locale. The locale is specified per ISO 639-1, with the country code added if applicable (for example, en-US, fr-CA, ar-IQ, and so on). This localization data is used in place of the prepackaged, installed localization data.
-
Restore default localization data. The use of the preloaded localization data is restored from the AnyConnect package and all imported localization data is deleted.
VPN Authentication Using SAML
SAML 2.0 support was added to mobile devices in the following releases. When SAML authentication is used, it applies to the AnyConnect session only. It does not apply to web sites, browser-initiated SAML logins, or installed applications. To provide a seamless reconnect without disruption, AnyConnect intentionally skips the repeating of the SAML authentication process. Additionally, if the user logs out of the IdP using a browser, the AnyConnect session remains intact.
-
iOS—version 4.6; SAML plus client certificate in version 4.8
-
Android—version 4.6; SAML plus client certificate in version 4.8
-
Chrome—version 4.0
Follow these guidelines when using SAML:
-
If you are using always-on VPN in failover mode, external SAML IdP is not supported (however, with internal SAML IdP, the Secure Firewall ASA proxies all traffic to IdP and is supported)
-
Untrusted server certificates are not allowed in the embedded browser.
-
The embedded browser SAML integration is not supported in CLI or SBL modes.
-
(Mobile only) Single logout is not supported.
-
SAML authentication established in a web browser is not shared with AnyConnect and vice versa.
-
Depending on the configuration, various methods are used when connecting to the headend with the embedded browser. For example, while AnyConnect might prefer an IPv4 connection over an IPv6 connection, the embedded browser might prefer IPv6, or vice versa. Similarly, AnyConnect may fall back to no proxy after trying proxy and getting a failure, while the embedded browser may stop navigation after trying proxy and getting a failure.
-
You must synchronize the Network Time Protocol (NTP) server on the Secure Firewall ASA with your IdP NTP server in order to use the SAML feature.
-
The VPN Wizard on ASDM does not currently support SAML configurations.
-
The SAML IdP NameID attribute determines the user's username and is used for authorization, accounting, and VPN session database.
-
You should set Auto Reconnect to ReconnectAfterResume in the AnyConnect Profile Editor, Preferences (Part 1) if you want users to re-authenticate with the Identity Provider (IdP) every time they establish a VPN session via SAML.
-
Since AnyConnect with the embedded browser uses a new browser session on every VPN attempt, users must re-authenticate every time, if the IdP uses HTTP session cookies to track logon state. In this case, the Force Re-Authentication setting in has no effect on AnyConnect initiated SAML authentication.
Refer to the SAML 2.0 section in the appropriate release, 9.7 or later, of the Cisco ASA Series VPN CLI or ASDM Configuration Guide for additional configuration details.
Import Translation Tables to the Secure Firewall ASA
Procedure
Step 1 |
Download the desired translation table from www.cisco.com. |
Step 2 |
In ASDM go to . |
Step 3 |
Click Import. The Import Language Localization Entry window displays. |
Step 4 |
Choose the appropriate Language from the drop-down list. |
Step 5 |
Specify where the translation table will be imported from. |
Step 6 |
Click Import Now. This translation table will be deployed to AnyConnect clients with this preferred language. Localization will be applied after AnyConnect restarts and connects. |
FIPS and Suite B Cryptography on Mobile Devices
AnyConnect for mobile devices incorporates Cisco Common Cryptographic Module (C3M), the Cisco SSL implementation which includes FIPS 140-2 compliant cryptography modules and NSA Suite B cryptography as part of its Next Generation Encryption (NGE) algorithms. Suite B cryptography is available for IPsec VPNs only; FIPS-compliant cryptography is available for both IPsec and SSL VPNs.
Use of cryptography algorithms is negotiated with the headend while connecting. Negotiation is dependent on the capabilities of both ends of the VPN connection. Therefore, the secure gateway must also support FIPS-compliant and Suite B cryptography.
The user configures AnyConnect to accept only NGE algorithms during negotiation by enabling FIPS Mode in the AnyConnect app settings. When FIPS Mode is disabled, AnyConnect also accepts non-FIPS cryptography algorithms for VPN connections.
Additional Mobile Guidelines and Limitations
-
Apple iOS 5.0 or later is required for Suite B cryptography; this is the minimum Apple iOS version that supports ECDSA certificates used in Suite B.
-
Android 4.0 (Ice Cream Sandwich) or later is required for Suite B cryptography; this is the minimum Android version that supports ECDSA certificates used in Suite B.
-
A device that is running in FIPS mode is not compatible with using SCEP to provide mobile users with digital certificates by proxy method or legacy method. Plan your deployment accordingly.