Skip to main content
Cisco Meraki Documentation

AnyConnect on the MX Appliance

Overview

The Cisco AnyConnect Secure Mobility Client consistently raises the bar by making the remote-access experience easy for end users. It helps enable a highly secure connectivity experience across a broad set of PC and mobile devices. This document provides information on the AnyConnect integration on Meraki appliances and instructions for configuring AnyConnect on the Meraki dashboard.

AnyConnect Client Download and Deployment
AnyConnect Authentication Methods
AnyConnect Troubleshooting Guide

AnyConnect Load Sharing
AnyConnect Licensing on the MX Appliance
AnyConnect on ASA vs MX
Secure Connect (AnyConnect) Cisco TAC Support
FAQ

Feature

The AnyConnect VPN server on the MX uses Transport Layer Security (TLS) & Datagram Transport Layer Security (DTLS) for tunneling and requires AnyConnect VPN client version 4.8 or higher on either Windows, macOS, Linux, or mobile devices to terminate remote access connections successfully. The AnyConnect client negotiates a tunnel with the AnyConnect server and gives you the ability to access resources or networks on or connected to the AnyConnect server (MX). Unlike the AnyConnect implementation on the Adaptive Security Appliance (ASA), with support for other features like host scan, web launch, etc, the MX security appliance supports Secure Socket Layer (SSL), VPN, and other AnyConnect modules that do not require additional configuration on the MX. For more details, see AnyConnect on ASA vs. MX

The MX supports Layer 2 Tunneling Protocol (L2TP)/Internet Protocol Security (IPsec) Client VPN and AnyConnect VPN simultaneously. 

AnyConnect can be used in place of L2TP/IPSec Client VPN configurations on operating systems that no longer support L2TP VPN services as it is a TLS & DTLS application based VPN. 

AnyConnect is currently not supported on template bound networks.

Use Cases
Diagram illustrating use cases for AnyConnect at a branch office, Data Center/VPN Concentrator, or public and private cloud environments.

AnyConnect can be used to securely connect remote users to Branch Offices, Datacenter or Public Cloud environments. Using AnyConnect with the Meraki MX Appliance for remote access can enable users secure and seamless connectivity between different locations. Remote users can connect to a Branch office and transverse the Secure Software Defined Wide Area Network (SD-WAN) AutoVPN tunnel to access recourses in the Amazon Web Services (AWS)/Azure, etc., or other locations within the SD-WAN fabric.

Caveats

There are certain caveats to keep in mind before enabling AnyConnect:

  • Supported MX models: MX600, MX450, MX400, MX250, MX105, MX100, MX95, MX85, MX84, MX75, MX68(W,CW), MX67(C,W), MX65(W)*, MX64(W)*, Z3(C), Z4(C), vMX

*MX65(W) and MX64(W) only supports AnyConnect when running on firmware 17.6+

Not supported: MX90, 80, 60, Z1 (The AnyConnect Settings page will not be visible on dashboard for these models)

  • Either NAT Exceptions (No NAT) on MX Security Appliances or AnyConnect can be enabled per WAN uplink

  • IPsec and AnyConnect share the same configured RADIUS and Active directory servers

  • AnyConnect does not currently support cellular uplink (integrated or USB modem)

Note: 

Stateless high availability and WAN failover are supported with AnyConnect on the MX. This means, when HA or WAN failover occurs, active user sessions will be disconnected and users will need to reconnect to the new active WAN link or the new primary MX. If you have two uplinks, its recommended to use the unique DDNS names of WAN1 and WAN2 as primary and backup servers in the AnyConnect connection profile.

How to Enable AnyConnect on Your Dashboard

Having reviewed the caveats, upgrade your MX security appliance to the required firmware version.

  • To enable AnyConnect, ensure that your network firmware version meets the minimum requirement. For MX64(W) and MX65(W), the firmware version must be 17.6+, and for all other supported models, the latest MX-16 firmware. Upgrades can be managed by navigating to Dashboard > Organization > Monitor > Firmware upgrades. For more details on firmware upgrades see Managing Firmware Upgrades

Server Settings

To enable AnyConnect VPN, select Enabled from the AnyConnect Client VPN radio button on the Security & SD-WAN  > Configure > Client VPN > AnyConnect Settings tab. The following AnyConnect VPN options can be configured:

Hostname: This is used by Client VPN users to connect to the MX. This hostname is a Dynamic DNS (DDNS) host record that resolves to the Public IP address of the MX. The DDNS hostname is a prerequisite for publicly trusted certificate enrollment. You can change this hostname by following instructions on the Dynamic DNS (DDNS) article. For an alternative to DDNS enrolled certificates, see Custom hostname certificates section in this article. 

AnyConnect port: This specifies the port the AnyConnect server will accept and negotiate tunnels on.

Log-in banner: This specifies the message seen on the AnyConnect client when a user successfully authenticates. If configured, a connecting user must acknowledge the message before getting network access on the VPN. To disable the log-in banner simply leave the banner field blank. 

Profile update: This specifies the AnyConnect VPN configuration profile that gets pushed to the user on authentication.

AnyConnect Settings tab on the Client VPN page showing client connection details.

Certificate Authentication: This is used to configure the trusted Certificate Authority (CA) file that is used to authenticate client devices. This configuration is only required if you need to authenticate client devices with a certificate. Only certificates PEM format (*.pem) are supported at this time.

Authentication Type: This is used to specify authentication with Meraki Cloud, SAML, RADIUS, or Active Directory.

Group Policy with RADIUS Filter-Id: This is used to enable dashboard group policy application using the filter passed by the RADIUS server.

RADIUS timeout: This is used to modify the RADIUS time-out for two-factor authentication and authentication server failover. 

AnyConnect VPN subnet: This specifies the address pool used for authenticated clients.

IPv6 Prefix (MX 18.104+): This specifies IPv6 prefix for AnyConnect to support IPv6 to both terminate a client VPN tunnel as well as IPv6 traffic inside the tunnel. More information can be found in IPv6 Support on MX Security & SD-WAN Platforms - VPN document in Configuring IPv6 for AnyConnect section.


DNS nameservers: This specifies the Domain Name System (DNS) settings assigned to the client.

DNS Suffix: This specifies the default domain name or DNS suffix passed to the AnyConnect client to append to DNS queries that omit the domain field. This domain name only applies to tunnelled packets.

Client Routing: This is used to specify full or split-tunnel rules pushed to the AnyConnect client device. You can send all traffic through VPN, all traffic except traffic going to specific destinations, or only send traffic going to specific destinations.

Dynamic Client Routing: This is used to specify full or split-tunnel rules pushed to the AnyConnect client device by hostname. For more details see Dynamic Client routing section in this article.

Default Group Policy: This is used to apply a default group policy to all connecting AnyConnect clients. For more details see Group Policies section in this article.

 

 

 

 

AnyConnect Settings tab on the Client VPN page showing Authentication and Access configuration options.

   

Server Certificates

The AnyConnect server on the MX uses TLS 1.2 for tunnel negotiation, hence it needs a server identity certificate. The MX supports three certificate options:

Option 1: Auto-generated certificate with DDNS hostname

This is the default option. With this option, the MX Appliance will enroll in a public trusted certificate using the DDNS hostname of the Meraki network. This publicly trusted certificate renews automatically. The DDNS hostname is not easy to remember, hence, it is highly recommended to use an AnyConnect profile to create a DDNS alias to simplify user interaction. For more information see, how to create a profile. Dashboard administrators do not have to worry about interacting with public CAs to get a signed certificate.

Example of hostname as it appears on AnyConnect Client Connection Details section.

DDNS hostname is configurable on MX Appliances in Passthrough/VPN Concentrator mode when AnyConnect is enabled.        

Automatic certificate generation is not supported for networks hosted on dashboard.meraki.cn or dashboard.meraki.ca

If the MX is in High Availability (HA) mode with a virtual IP and behind a NAT device, we recommend using the custom certificates feature to enable you manage your certificates and DNS records. The automatic DDNS hostname certificates may not suffice. 

Option 2: Custom hostname certificates

Requires MX firmware version 16.16+.

Custom hostname certificates do not renew automatically. Administrators will need to renew certificates manually in addition to managing their DNS record (to enable their hostname resolve to the MX IP on the Internet)

Custom hostname certificates are supported in High Availability mode. Adminstrators are required to download Certificate Signing Requests (CSRs) and upload certificates for both Primary and Spare MX Appliances with the custom certificates Primary | Spare tab only visible when the MX Appliance is in High Availability mode.

Administrators can generate a CSR, that can be signed by a public CA. The signed certificate should be uploaded to the MX Appliance via the dashboard. This option allows administrators to use a preferred hostname. For example, vpn.abc.com

 

Configuration options for "Secure Connection between MX and AnyConnect clients." Server Certificat Generation Method" is set to "Custom."

 

 

Step 1. Generate and download a CSR

"Enter CSR Fields" window with Common name, Subject Alt Name (Hostnames), Subject Alt Name (IPs), and Organization fields visible.

Step 2. Get the CSR signed by a public CA of your choice

Step 3. Upload the signed certificate and CA chain from your CA*

Upload Signed Certificate.png
 

*Note:  A chain certificate must establish a full chain of trust back to a root CA. Such certificates are self-signed by the CA providing them, as the following example demonstrates:

Example of a certificate titled "DigiCert High Assurance EV Root CA."

Image courtesy of Mozilla Software Foundation and Wikipedia

Note that both the Subject Common Name and Issuer Common name are equal.

An incomplete or invalid chain of trust will result in the error "Failed verifying Device Cert with Cert Chain" being seen on dashboard when you go to upload the certificates.

Questions on how to obtain such a certificate should be brought up to whatever entity is providing the ones in question.

Option 3: Self-signed certificates:

Only available for testing purposes.
 

Authentication Methods

AnyConnect supports authentication with either SAML, RADIUS, Active Directory, Meraki Cloud and Certificate authentication. For more details on authentication configuration, refer to AnyConnect Authentication Methods.

Client Routing

"Client Routing" options with three radio button options available.

  1. Send all traffic through VPN​​This is the same as full tunneling. All traffic from the client is sent over the VPN tunnel.
  2. Send all traffic except traffic going to these destinations: This is the same as full tunnel with exclusions, when configured, the client will send all traffic over the VPN except traffic destined for the configured subnet. This option is not supported on Android devices.
  3. Only send traffic going to these destinations: This is the same as spilt tunneling, when configured, the client will only send traffic destined for the configured subnet over the VPN. Every other traffic sent over the local network.

When selecting "Only send traffic going to these destinations" or "Send all traffic execpt traffic going to these destinations" at least one IP must be entered otherwise the following error will be presented:


"The AnyConnect traffic destination (Client Routing) must contain at least one valid subnet in CIDR format."

Dynamic Client Routing

Dynamic Client Routing is only supported on MX16.5+ firmware
Dynamic Client Routing is only supported on Windows and Mac platforms. It is not supported Linux or any mobile platforms.

Dynamic split tunneling/client routing allows for the specification of traffic that should be included or excluded in the VPN tunnel based on domain name rather than IP/Classless Inter-Domain Routing (CIDR) notation. This is critical for services that do not have dedicated or fixed IP addresses. Dynamic split tunneling can be used with or without the regular split tunneling feature.

Please note that every hostname configured is treated as a wildcard. For example, cisco.com is treated as *.cisco.com. Wildcards, for example, *.cisco.com cannot be configured on the dashboard. For the end user, routes are populated when a user tries to access the specified hostname. 

"Dynamic Client Routing" options. "Only send traffic going to these destinations" option is selected.       Virtual Private Network (VPN) route details.

When selecting "Only send traffic going to these destination" or "Send all traffic except traffic going to these hostnames" at least one FQDN should be entered otherwise the following error message will be presented:

"The AnyConnect traffic destination (Dynamic Client Routing) must contain at least one valid destination."

Local LAN access

Local LAN access may be desired when full-tunneling is configured (Send all traffic through VPN), but users still require the ability to communicate with their local network. For example, a client that is allowed local LAN access while connected to the MX in full tunnel mode is able to print to a local printer at home, while other traffic flows through the tunnel.

To enable local LAN access, two things need to be done. Local LAN access will not work if both conditions are not satisfied.

1. Configure the MX: Select "Send all traffic except traffic going to these destinations" option on the dashboard and configure a 0.0.0.0/32 route. This will cause the AnyConnect client to automatically exclude traffic destined for the user's local network from going over the tunnel.

            Radio button option called "Send all traffic except traffic going to these destinations." "0.0.0.0/32" is entered in the text field below.

2. Configure the Client: Enable Allow local LAN Access on the AnyConnect Client. This can be enabled manually or via the AnyConnect profile.

                AnyConnect "Preferences - VPN" window with "Allow local LAN access when using VPN (if configured" selected).

After connection, the user should see their local network subnet added as a non secure routes (destinations that should be accessed locally not via the VPN tunnel)

AnyConnect VPN Route details showing Non-Secured Routes and Secured Routes.

Session Timeout

The client session timeout can be configured using one of the predefined values (8 hours, 1 day, 7 days). Or, you can use the custom option and specify up to a maximum of 256 hours.

Session Timeout dropdown menu with four options: 8 hours, 1 day, 7 days, or custom.

Group Policies

The need for access control over remote access connections cannot be over-emphasized. While some administrators use multiple address pools to segment users, others use VLAN tagging to existing subnets. From a Client VPN standpoint, multiple subnets or separate VLANs do not provide access control in itself. What segments users from talking to each other or other network resources is the presence and the enforcement of access rules. For example, if users are in different VLANs and access policies are not enforced somewhere, users could access anything. 
 
AnyConnect on the MX does not support multiple VLANs or address pools for Client VPN users. However, the MX supports the application and enforcement of policies to AnyConnect users on authentication. It is also important to note that, from a Client VPN standpoint on the MX, having users on the same subnet does not mean they are in the same VLAN. Users are assigned a /32 address (one address) from the pool configured on dashboard. Group Policies can then be used to limit users on the same AnyConnect subnet from talking to each other or other resources on the network.

Default Group Policy

Administrators can apply a global group policy to all users connecting through AnyConnect by selecting a configured policy from the default Group Policy drop-down menu. Group policies can be configured via Dashboard > Network-wide > Configure > Group policies. Refer to Creating and Applying Group Policies for more details.

Default Group Policy options with three options: No Group Policy, No UDP, No ICMP.
Note: If a default group policy set and group policy with Filter-ID is also enabled, the Filter-ID policy passed by the RADIUS server will take precedence over the default group policy.  

Group Policies with RADIUS Filter-ID

AnyConnect supports the application of dashboard-configured group policies to AnyConnect users when authenticating with RADIUS. This is achieved using the RADIUS Filter-ID attribute. To set this up on your MX:

  1. Create group policies on Dashboard > Network-wide > Group Policies. Specify rules within the policy. Multiple group policies can be mapped to different user groups on the RADIUS server. In this example, we are matching CONTRACTOR policy to CONTRACTOR user group.

    Group Policies table with Contractor group highlighted.             Contractor group policy page with configuration options: Name, Schedule, Bandwidth, Hostname visibility, Firewall and Traffic shaping, and Layer 3 firewall.

 

  1. Enable the Filter-ID option on the dashboard. This option is only configurable if you are authenticating with a RADIUS server.
            "Group Policy with RADIUS Filter-Id" dropdown menu with two options: Enabled or disabled.

  2. Configure the RADIUS server to send an attribute in its accept message containing the name of a group policy configured in dashboard (as a String). Commonly, the Filter-ID attribute will be used for this purpose. The screenshot below shows a network policy in Windows Network Policy Server (NPS), configured to pass the name of a dashboard group policy ("CONTRACTOR") within the Filter-ID attribute:

Multiple pop-up windows showing Microsoft Windows Network Policy Server, VPN User  properties, Radius Attributes, and Attribute Information.

The RADIUS server is configured with the group policy "CONTRACTOR" defined on dashboard. When a user in the group successfully authenticates, the "CONTRACTOR" group policy name for the authenticated user will be sent in the RADIUS accept message, allowing the MX to apply the requested policy to the user. The group policy name sent by the RADIUS server must match verbatim what is configured on the dashboard for policies to apply correctly. Currently, policies do not show up on Network-wide > Monitor > Client list page if you have only a security appliance in your dashboard network, however, If you have a combined network, the policy will show under the 802.1X policy column.


Client VPN Connections  

Client view:
You can see client stats and connection details by clicking on the graph in the bottom-left corner of the client. 

AnyConnect window showing graph button and AnyConnect statistics window.


Clients can also see available routes on the Route Details tab. Secure routes are accessible by the client over the VPN while nonsecure routes are not accessible by the client over the VPN. Nonsecure routes are visible when split-tunneling is configured. 

AnyConnect window showing graph button and AnyConnect  Route Details window.
 

Connection logs can be found under the Message History tab.

AnyConnect window showing graph button and AnyConnect Message History window.

Dashboard view:

After configuring client VPN, to see how many users are connected to your network, navigate to Network-wide > Monitor > Client. All AnyConnect clients will be seen with the AnyConnect icon. You can filter by client VPN using the search menu.


Table in dashboard showing AnyConnect clients and information.
 

Note: The MAC address seen on the client list is is not the actual MAC address of the AnyConnect client. Instead, the displayed address is pseudo-randomly generated, using the provided username as its base. For example, each time someone connects using the name xyz.test@example.com, an entry will show up as active on the clients list with the same given MAC address.

In the event that multiple devices are connected simultaneously with the same set of credentials, the data seen on the list will reflect the most recently connected device.

Event Logging

To see all available events, navigate to Network-wide > Monitor > Client and filter the Event type include field by AnyConnect.

Event Log table and "Event type include" dropdown filter menu.

To see log-on and log-off events, go to Dashboard > Network-Wide > Monitor > Event logs and filter by VPN client connected and VPN client disconnected.

Event Log table displaying VPN client connected and VPN client disconnected events.
 

 

 

 

 

 

 

 

Number of Supported Sessions per MX Model

Below is the number of sessions allowed per MX model. When the limit is reached, new sessions will not be formed.

Model

Max sessions

MX450 1,500
MX250 1,000
MX105 750
MX100 250
MX95 500
MX85 250
MX84 100
MX75 250
MX67/68 100
MX64/65 50
Z3 5
vMX S/M/L 100/250/500
vMX100 250
MX600 1000
MX400 750

FAQ 

  1. Who signs the Meraki facilitated publicly trusted certificates?
    A publicly trusted Certificate Authority.

  2. Can I use my own hostname or publicly trusted certificate on the MX as a server certificate?
    Yes, see Custom hostname certificates

  3. How will AnyConnect be licensed on the Meraki MX?
    See AnyConnect licensing on the MX

  4. Which MX/vMX models support AnyConnect? 
    See caveats section

  5. Can I use AnyConnect profiles?
    Yes, see the AnyConnect Profiles section. Only VPN profiles can be pushed via the MX. Others profiles, like Umbrella profiles, etc will not be pushed via the MX.

  6. Can I configure different split-tunnel rules/VLANs/IP address pools for different sets of users?
    No, not at the moment. However, you can use group policies when authenticating with RADIUS to apply access policies to a user or groups of users on authentication.

  7. Can I do certificate-based authentication?
    Yes, as a combination with username and password. See the certificate-based authentication section. Certificate-only authentication is currently in beta see Certificate-only authentication for more details.

  8. Where can I download the AnyConnect client?
    On the AnyConnect Settings page on dashboard in the Client Connection section or on cisco.com

  9. What are the current caveats/known issues with the AnyConnect feature & firmware?
    See caveats section

  10. Which features are supported? Any plans to support Umbrella, posture scan, 802.1x, etc?
    VPN Only. Other AnyConnect modules that do not require additional server support can be used as well, for example, DART, Umbrella. This module must be deployed and configured separately as the MX does not support web launch, client software deployment, or update at this time. See AnyConnect on ASA vs. MX for more details. 

  11. Can I use IKEv2 on AnyConnect to connect to the MX Appliance?
    No, AnyConnect only supports TLS and DTLS 1.2 connections on the MX.

  12. Can I run L2TP/IPsec Client VPN and AnyConnect VPN simultaneously on the MX?
    Yes.

  13. Can I connect to the inside interface of the MX with AnyConnect? For example, connect to the MX from the LAN side?
    No, only inbound connections on the WAN side are supported at this time.

  14. When will AnyConnect General Availability (GA)?
    AnyConnect GA'd on the MX 16.16+ firmware released in March 2022.

  • Was this article helpful?