Anyconnect Meraki Mx



MX Server certificate: The AnyConnect server on the MX uses TLS for tunnel negotiation, hence it needs a server identity certificate. Currently, when AnyConnect is enabled, the MX will automatically initiate a certificate-signing request to get a publicly trusted identity certificate; this is entirely transparent to the dashboard administrator. Secure connections built to a virtual MX benefit from the same SD-WAN capabilities as a physical MX appliance. Easy deployment Virtual MX is deployed on an AWS EC2 instance or Azure VM and configured in the Meraki dashboard, just like any other MX. An AnyConnect profile is a crucial piece for ensuring easy configuration of the AnyConnect client software, once installed. The MX does not support the use of custom hostnames for certificates (e.g. The MX only supports use of the Meraki DDNS hostname for auto-enrollment and use on the MX. .Academy 11 October 2017 Cisco Meraki Cloud Networking Series Exploring Security & SD- WAN with Meraki MX 2© 2016 Cisco and/or its affiliates.

The support for AnyConnect VPNs is probably one of the most wanted features for Meraki customers. It was first announced at Cisco Live 2015 (at least that is where I first heard of it) and after no more than six years the first public beta (v16.4) is available. Lets look at it.

My first try was with a Meraki Z3 which should be supported, but that device did not want to enroll a public certificate. Either it kept a self-signed-certificate or did not enable the AnyConnect server at all. Well, early Beta …

The next try was my MX68 (which I got from Meraki for my recognition as a Meraki All-Star, thanks again for that!). With this device the AnyConnect VPN was working.

Configuration

The configuration is Meraki-easy as expected. For a basic setup we need:

  1. Enable AnyConnect Client VPN
  2. Change or accept the AnyConnect-port (default 443) and login-banner (default “You have successfully connected to client vpn.”)
  3. Upload a client profile (optional, but I would always do so)
  4. Configure the Authentication (RADIUS, Meraki Cloud or AD)
  5. Configure the AnyConnect VPN subnet, Nameservers and DNS Suffix
  6. Configure Split Tunneling

Thats all that has to be done and it is working.

What is different to an AnyConnect implementation on the ASA

Certificate Enrollment

The certificate is automatically deployed for the DDNS hostname of the MX. It comes from the QuoVadis Root CA which should be trusted on all relevant systems and is valid for three months. The documentation says that it should auto-renew before it expires.

I expected that they implement an automatic Let’s Encrypt enrolment, but at least at the moment that is not possible. It’s also not possible to import your own certificate.

Crypto

This is a disappointment. On all my ASA implementations, I only enable TLS 1.2 with next-generation encryption and disable everything that has no Forward Secrecy (FS).

The MX also only uses TLS/DTLS 1.2 which is great. But there are a lot of non-FS algorithms enabled. SSLLabs only rates the VPN-Server with a “B” which is not state of the art any more. Having a default config (that can not be tuned) that gives a “B” is a little bit awkward nowadays.

Authentication

The default Authentication is AAA only. But you can also use double authentication (certificate and AAA) which I didn’t test yet.

There is no dedicated MFA-Config, but with RADIUS we can access any MFA server of our choice. After increasing the RADIUS timeout (default 3 seconds) MFA with the DUO authentication proxy directly worked like a charm.

Anyconnect Meraki Mx Client

The Authentication Protocol is “PAP_ASCII”, so there is no password-management for AnyConnect-users on the MX.

Authorization

On the ASA you can configure different IP subnets for different user groups, this is not possible with the MX and all users share the same VPN-subnet. It is also not possible to use a DHCP-server for address assignment.

In contrast to the legacy client VPN where all remote access users had to share the same “permit any” authorisation, with AnyConnect the RADIUS server can apply a group-policy to the session with the help of the RADIUS attribute “Filter-Id””.

Be carefull with the group-policy-names. If you configure the Filter-Id as “RA-USER”, and the RADIUS-server automatically appends an “.in” to the attribute, the group-policy has to be named “RA-USER.in” in the Meraki dashboard.

Same as with the AnyConnect pool, also the Split-Tunnel-config is global and can not be configured per user-group.

AnyConnect Profiles

As of now, only VPN-profiles can be pushed to the client. My first test did not work because the filename was like an FQDN (vpn.example.com.xml). After replacing the dots with dashes and only keeping the dot of the extension, it worked. The Meraki-Cloud added a second “.xml” so the profile name resulted in vpn-example-com.xml.xml but that does not harm anything.

There is no Profile-Editor embedded, the profiles have to be created in the standalone Profile-Editor or in a text editor.

Meraki

Meraki-All-Star PhilipDAth created an online-version to generate a basic profile: https://www.ifm.net.nz/cookbooks/online-anyconnect-profile-editor.html

Redundancy

If the ASA is has multiple ISPs-interfaces, the ASA can be configured to accept connections on all interfaces. The MX only accepts AnyConnect-connections on the primary WAN-interface. But on the failure of the primary interface, the DDNS entry is updated to the IP of the secondary interface and that interface accepts the connections. Switching over took a couple of minutes which is not as good as configuring backup-servers in the profile, but at least we have basic redundancy.

AnyConnect versions

While the ASA supports a wide range of AnyConnect versions, the MX needs at least AnyConnect 4.8. But you should run a recent version anyhow.

The AnyConnect client can not be deployed from the MX as it is possible from the ASA. You need to implement any type of pre-installation.

Licensing

While in Beta, no extra license is needed, you even can download the AnyConnect client through the dashboard. But it is documented that the AnyConnect PLUS license is needed when this feature goes GA. I expect that we will have to connect the dashboard account to Cisco Smart licensing for that.

Conclusion

The AnyConnect implementation on the Meraki MX is by far not as powerful as on the ASA. But probably no one expected that.

There are a couple of restrictions, but at least for me, I can probably arrange with it. I only hope that it does not take another couple of years for this release to become GA as most of my customers will not run Beta-code.

References:

AnyConnect on the MX Appliance
https://documentation.meraki.com/MX/AnyConnect_on_the_MX_Appliance

AnyConnect Troubleshooting Guide
https://documentation.meraki.com/MX/AnyConnect_on_the_MX_Appliance/AnyConnect_Troubleshooting_Guide

AnyConnect on ASA vs. MX
https://documentation.meraki.com/MX/AnyConnect_on_the_MX_Appliance/AnyConnect_on_ASA_vs._MX

AnyConnect Client Download and Deployment
https://documentation.meraki.com/MX/AnyConnect_on_the_MX_Appliance/Client_deployment

The purpose of this article is to demonstrate how to configure VPN settings through Systems Manager (SM).

A Virtual Private Network ( or VPN) is used to allow secure, remote connection and access to a network. Systems Manager can be used to automatically push the VPN settings to managed iOS, macOS, Windows 10, and Samsung KNOX enabled Android devices. Within SM, a VPN connection can be configured manually, or with the addition of a MX Security Appliance or Cisco Meraki Concentrator in the same Dashboard organization, configured automatically. Automatically importing the VPN settings from the MX or Concentrator network will not only greatly simplify the configuration process, it will also prevent any typo errors in the VPN settings.

Note: Deploying VPN settings via SM is available for iOS, macOS, Windows 10, and Samsung KNOX enabled Android devices.

More Information: Configuring client VPN.

More Information: For detailed information on how to create and deploy SM configuration profiles to different groups of managed devices, please consult this article.

Sentry VPN on Meraki MX-Z Devices

Anyconnect Meraki Mx Player

Sentry VPN Security allows you to define a tag-scope to receive a Dynamically generated VPN Configuration from the Security appliance > Configure > Client VPN page, and configured by selecting the appropriate tag scoping for your SM devices:

Sentry Configuration for VPN in Systems Manager

This option uses the Cisco Meraki cloud to automatically configure a VPN connection to a MX Security Appliance or VM Concentrator added in the same Dashboard Organization as the Systems Manager network.

  1. Navigate to the Systems Manager > Manage > Settings page.
  2. Select the VPN tab.
  3. Configuration: Select Sentry.
  4. Security Appliance: Select the Dashboard network (MX or Concentrator) that contains the desired VPN connection.
  5. Auth type: If choosing Specify account, a prompt to specify the name of the user account for authenticating the connection will appear. If Use device identity is selected, Dashboard will automatically generate and use unique identifying credentials for each device when connecting to the MX VPN.
  6. Send All Traffic: Check this flag to send all device traffic through the VPN connection (Optional).

Anyconnect Meraki Mx Driver

The following screenshot displays an example of how to set up the Sentry VPN connection:

Manual Configuration

This option allows you to manually configure VPN settings. The supported and configurable manual VPN protocols are L2TP, PPTP, IPsec (Cisco), and Cisco AnyConnect.

  1. Navigate to the Systems Manager > Manage > Settings page.
  2. Select the VPN tab.
  3. Configuration: Choose Manual.
  4. Connection Name: Input a name for the VPN connection that will be displayed on the iOS device.
  5. Connection Type: Select either L2TP, PPTP, or IPsec (Cisco).
  6. Sever: Input the public IP address of the VPN server.
  7. Shared Secret (L2TP Only): Input the shared secret for the VPN connection.
  8. User Authentication: Select the user authentication method. Choosing Password allows the device user to be prompted for a password when using the VPN connection.
  9. Account: Specify the name of the user account used for authenticating the connection (e.g., DOMAINusername, or username@domain.tld).
  10. Group Name (AnyConnect Only): Specifies the group in which the AnyConnect Account resides).
  11. Send All Traffic: Check this flag to send all device traffic through the VPN connection (Optional).
  12. Proxy Setup: Configure a proxy to be used with the connection (Optional).

The following screenshot displays an example of how to setup the Manual VPN connection. Settings vary depending on the VPN connection type.

Systems Manager can be used to push VPN configuration settings to remotely managed iOS, macOS, Windows 10, and Samsung KNOX enabled Android devices. Adding a MX or Concentrator network to the Dashboard Organization can greatly simplify the configuration process by importing the VPN settings, and automatically updating them if any changes are made. Once the managed devices are able to check-in with SM, the VPN connection profile payload will install and be available for the device user to select.

Cisco AnyConnect and AnyConnect Legacy

When selecting the Cisco Anyconnect connection type, a certificate will be required to be uploaded. This certificate can be exported from the VPN endpoint device and uploaded to dashboard after clicking on the 'Add Credentials' option.