Professional Documents
Culture Documents
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.
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.
Use Cases
1
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)
2
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.
• 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.
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.
3
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.
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:
4
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.
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
5
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*
*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:
6
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.
7
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
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.
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.
8
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.
9
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)
10
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.
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.
11
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.
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.
12
2. Enable the Filter-ID option on the dashboard. This option is only configurable if you are authenticating with a RADIUS server.
3. 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:
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.
13
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.
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.
14
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.
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.
15
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.
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
vMX100 250
MX600 1000
MX400 750
16
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
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.
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.
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.
17