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.
Client Download and Deployment
AnyConnect Authentication Methods
AnyConnect Troubleshooting Guide
AnyConnect on ASA vs MX
AnyConnect licensing on the MX
The AnyConnect VPN server on the MX uses TLS & 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 ASA, with support for other features like host scan, web launch, etc, the MX security appliance supports 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 L2TP/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 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 SD-WAN AutoVPN tunnel to access recourses in the AWS/Azure, etc or other location within the SD-WAN fabric.
There are certain caveats to keep in mind before enabling AnyConnect:
Supported MX models: MX600, 450, 400, 250, 105, 100, 95, 85, 84, 75, 68, 67, 65*, 64*, Z3, vMX
*MX65 and MX64 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) or AnyConnect can be enabled per WAN uplink.
IPsec and AnyConnect share the same configured RADIUS and Active directory servers
How to Enable AnyConnect on Your Dashboard
Having reviewed the caveats, upgrade your MX security appliance to the required firmware version.
To enable AnyConnect VPN, select Enabled from the AnyConnect Client VPN radio button on the Security Appliance > 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 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 the instructions here. For an alternative to DDNS enrolled certificates, see Custom certificates.
Profile update: This specifies the AnyConnect VPN configuration profile that gets pushed to the user on authentication.
Certificate authentication: This is used to configure the trusted 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 are supported at this time.
Group policy with RADIUS Filter-ID: This is used to enable dashboard group policy application using the filter passed by the RADIUS server.
RADIUS time-out: This is used to modify the RADIUS time-out for two-factor authentication and authentication server failover.
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
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:
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.
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
If the MX is in 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.
Custom hostname certificates
Requires MX firmware 16.11+ and needs to be enabled by the Meraki Support
Administrators can generate a certificate signing request (CSR), that can be signed by a public Certificate Authority. The signed certificate should be uploaded to the MX Appliance via the Dashboard. This option allows administrators to use a preferred hostname. e.g. vpn.abc.com
Step 1. Generate and download a Certificate signing request
Step 2. Get the CSR signed by a public Certificate Authority of your choice
Step 3. Upload the signed certificate and CA chain from your Certificate Authority*
*Note: A chain certificate must establish a full chain of trust back to a root certificate authority. Such certificates are self-signed by the CA providing them, as the following example demonstrates:
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.
Note: 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 certs is supported in High Availability mode. Adminstrators are required to download CSRs and upload certificates for both Primary and Spare MX Appliances with the custom certs Primary | Spare tab only visible when the MX Appliance is in High Availability mode.
Only available for testing purposes.
AnyConnect supports authentication with either SAML, RADIUS, Active Directory, or Meraki Cloud. For more details on authentication configuration, refer to AnyConnect Authentication Methods.
Note: Systems Manager with Sentry is not supported with AnyConnect.
i. Send all traffic through VPN
This is the same as full tunneling. All traffic from the client is sent over the VPN tunnel.
ii. 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.
iii. 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.
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/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. E.g. cisco.com is treated as *.cisco.com. Wildcards e.g. *.cisco.com cannot be configured on the Dashboard. For the end user, routes are populated when a user tries to access the specified hostname.
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.
2. Configure the Client: Enable Allow local LAN Access on the AnyConnect Client. This can be enabled manually or via the AnyConnect profile.
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)
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 > Group Policies. Refer to Creating and Applying Group Policies for more details.
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:
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.
Enable the Filter-ID option on the dashboard. This option is only configurable if you are authenticating with a RADIUS server.
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 NPS, configured to pass the name of a dashboard group policy ("CONTRACTOR") within the Filter-ID attribute:
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 > 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
You can see client stats and connection details by clicking on the graph in the bottom-left corner of the client.
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.
Connection logs can be found under the Message History tab.
After configuring client VPN, to see how many users are connected to your network, navigate to Network-wide > Clients. All AnyConnect clients will be seen with the AnyConnect icon. You can filter by client VPN using the search menu.
Note: The MAC address seen on the client list is randomly generated; it is not the actual MAC address of the AnyConnect client.
To see all available events, navigate to Network-wide > Event log and filter the "Event type include" field by AnyConnect.
To see log-on and log-off events, go to Dashboard > Network-Wide > Event logs and filter by VPN client connected and VPN client disconnected.
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.
Dashboard API Support
APIs can be used to configure or return the AnyConnect server settings on the MX. Navigate to Dashboard > Help > API docs - AnyConnect VPN Settings for more information.
Who signs the Meraki facilitated publicly trusted certificates?
A publicly trusted Certificate Authority.
Can I use my own hostname or publicly trusted certificate on the MX as a server certificate?
Yes, see Custom hostname certificates
How will AnyConnect be licensed on the Meraki MX?
See AnyConnect licensing on the MX
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.
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.
Can I do certificate-based authentication?
Yes, as a combination with username and password. See the certificate-based authentication section. Certificate-only authentication is not supported at this time.
Where can I download the AnyConnect client?
On the AnyConnect Settings page on dashboard in the Client Connection section or on cisco.com.
How can I provide feedback on this feature?
Email firstname.lastname@example.org or via the “give your feedback” button at the bottom right corner on your dashboard.
What are the current caveats/known issues with the AnyConnect feature & firmware?
See caveats section
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. e.g. 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. Please email email@example.com if you have any questions.
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.
Can I run L2TP/IPsec Client VPN and AnyConnect VPN simultaneously on the MX?
Can I connect to the inside interface of the MX with AnyConnect? e.g. connect to the MX from the LAN side?
No, only inbound connections on the WAN side are supported at this time.
When will AnyConnect GA?
AnyConnect GA'd on the MX 16.16+ firmware released in March 2022.