Cisco Meraki Anyconnect

Posted on 01-05-2021 by admin

Anyconnect With Meraki
Cisco Meraki Anyconnect Login
Cisco Meraki Anyconnect Client
Cisco Anyconnect Meraki Vpn

When AnyConnect is configured on your MX, it generates a temporary self-signed certificate to start receiving connections. Then the MX initiates enrollment for a publicly trusted certificate; this will take about 10 minutes after AnyConnect is enabled for the certificate enrollment process to be completed.

AnyConnect supports authentication with either RADIUS, Active Directory, or Meraki Cloud. For more details on AnyConnect configuration, refer to the AnyConnect configuration guide.

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. Cisco Meraki is the leader in cloud controlled WiFi, routing, and security. Secure and scalable, learn how Cisco Meraki enterprise networks simply work. Behind the Network Episode 3: The Workplace of the Future: The Office 2.0. United States (English). Cisco Meraki’s unique auto provisioning site-to-site VPN connects branches securely with complete simplicity. Using IPsec over any wide area network, the MX links your branches to headquarters as well as to one another as if connected with a virtual Ethernet cable. Announcing Cisco AnyConnect VPN with Meraki MX. Link to the article.https://documentation.meraki.com/MX/AnyConnectontheMXAppliance.

Note: Systems Manager with Sentry is not supported with AnyConnect.
Note: SAML authentication is not supported at this time.

Meraki Cloud Authentication

Note: IPsec must be enabled and users must be authorized on the IPsec settings tab.
Use this option if an Active Directory or RADIUS server is not available, or if VPN users should be managed via the Meraki Cloud. To add or remove users, use the User Management section at the bottom of the page. Add a user by clicking 'Add new user' and entering the following information:

Name: Enter the user's name.
Email: Enter the user's email address.
Password: Enter a password for the user or click 'Generate' to automatically generate a password.
Authorized: Select whether this user is authorized to use the client VPN.

To edit an existing user, click on the user under the User Management section. To delete a user, click the X next to the user on the right side of the user list.

When using Meraki-hosted authentication, the user's email address is the username that is used for authentication.

RADIUS

Use this option to authenticate users on a RADIUS server. Click Add a RADIUS server to configure the server(s) to use. Enter in the IP address of the RADIUS server, the port to be used for RADIUS communication, and the shared secret for the RADIUS server.

Note: Only one RADIUS server is supported for authentication with AnyConnect today.

Add MX security appliance as RADIUS clients on the NPS server.

In order for the MX to act as an authenticator for RADIUS, it must be added as a client on NPS.

Open the NPS server console by going to Start > Programs > Administrative Tools > Network Policy Server.
In the left-side pane, expand the RADIUS Clients and Servers option.
Right-click the RADIUS Clients option and select New.
Enter a Friendly Name for the MX security appliance or Z teleworker gateway RADIUS client.
Enter the IP address of your MX security appliance or Z teleworker gateway. This IP will differ depending on where the RADIUS server is located:
- On a local subnet: use the IP address of the MX/Z on the subnet shared with the RADIUS server
- Over a static route: use the IP address of the MX/Z on the subnet shared with the next hop
- Over VPN: use the IP address of the MX/Z on the highest-numbered VLAN in VPN
Create and enter a RADIUS Shared Secret (make note of this secret, you will need to add this to the dashboard).

Note: Currently only ASCII characters are supported for RADIUS shared secrets, unicode characters will not work correctly.

Press OK when finished.

For additional information or troubleshooting assistance, please refer to Microsoft documentation on RADIUS clients.

Configure a RADIUS Connection Request

In the NPS server console, navigate to Policies > Connection Request Policies. Right-click the Connection Request Policies folder and select New.
In the Connection Request Policy Wizard, enter a policy name and select the network access server type unspecified, then press Next.
Click Add to add conditions to your policy. Access-request messages will need to meet these conditions to be allowed access.
From the list of conditions, select the option for NAS-Port-Type. Select VPN Virtual and press Next
Press Next on the next three pages of the wizard to leave the default settings intact.
Review the settings, then press Finish.

Configure a RADIUS Network Policy.

In the left-side pane of the NPS server console, right-click theNetwork Policies option and select New.
In the Network Policy Wizard enter a policy name and select the network access server type unspecified, then press Next.
Click Add to add conditions to your policy.
From the list of conditions, select the option for Windows Groups. Click Add Groups and enter the name you would like to give client VPN permission to.
From the list of conditions, select the option for NAS-Port-Type. Select VPN Virtual and press Next.
Leave the default settings on the Specify Access Permission page and press Next.

Deselect all checkboxes and select Unencrypted authentication (PAP, SPAP). An informational box will be displayed, press No to continue, and press Next. Refer to this doc for security information about using PAP.
Press Next on the next two pages of the wizard to leave the default settings intact.
Review the settings, then press Finish.

Active Directory

Use this option if user authentication should be done with Active Directory domain credentials. You will need to provide the following information:

Short domain: The short name of the Active Directory domain.
Server IP: The IP address of an Active Directory server on the MX LAN.
Domain admin: The domain administrator account the MX should use to query the server.
Password: Password for the domain administrator account.

For example, considering the following scenario: Users in the domain test.company.com should be authenticated using an Active Directory server with IP 172.16.1.10. Users normally log in to the domain using the format 'test/username' and you have created a domain administrator account with username 'vpnadmin' and password 'vpnpassword'.

The Short domain would be 'test'
The Server IP would be 172.16.1.10.
The Domain admin would be 'vpnadmin'
The Password would be 'vpnpassword'

Note: Only one AD server can be specified for authentication with AnyConnect at the moment. The MX does not support mapping group policies via Active Directory for users connecting through the client VPN. Refer to this document for more information on integrating with client VPN.

Certificate-based authentication

The AnyConnect server on the MX supports client certificate authentication as a factor of authentication. If certificate authentication is enabled, the AnyConnect server will use the uploaded trusted CA certificate to validate authenticating clients before requesting for the users' credentials. AnyConnect on the MX does not support certificate-only authentication at this time. Authenticating users must input credentials once certificate authentication succeeds. If certificate authentication fails, the AnyConnect client will report certificate validation failure.

Multi-Factor Authentication with RADIUS or Active Directory as a Proxy

MFA is not natively supported on the MX, however, you can configure MFA with your RADIUS or Active Directory server. The MFA challenge takes place between the RADIUS/Active Directory/Idp and the user. The MX will not pass any OTP or PINs between the user and RADIUS. The user connects to the MX and gets prompted for username and password, the MX passes credentials to the RADIUS or AD server, then the RADIUS or AD server challenges the user directly (not through the MX). The user responds to RADIUS or AD server, possibly via push notification, etc, then the RADIUS or AD server tells the MX that the user has successfully authenticated. Only then is the user allowed access to the network. Refer to this document for more information on authentication.

RADIUS Time-Out

Anyconnect With Meraki

The default RADIUS time-out is three seconds. This is how long the AnyConnect server will wait for a response from the RADIUS sever before failing over to a different RADIUS server or ignoring the response entirely. To support two-factor authentication, you can increase the RADIUS time-out by modifying the RADIUS time-out field on the AnyConnect Settings page. The configurable time-out range is 1 - 300 seconds.

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.
Client Download and Deployment
AnyConnect Authentication Methods
AnyConnect Troubleshooting Guide
AnyConnect on ASA vs. MX
FAQ

Feature

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.

An AnyConnect Plus/Apex (termed or perpetual) license will be required to use AnyConnect on the MX when MX16.X firmware goes GA. Until then, if an MX upgrades to MX16, AnyConnect will be available as a feature. If a license is not linked when MX16 goes GA, AnyConnect will become unusable until a license is applied. More details on applying licenses will be available soon.

The MX supports L2TP/IPsec Client VPN and AnyConnect VPN simultaneously.

Caveats

AnyConnect is still in development, hence, there are certain caveats to keep in mind before enabling AnyConnect.

Supported MX models: MX600, 450, 400, 250, 100, 84, 68, 67, Z3, vMX
Future support: MX64, 65
Not supported: MX80, 90, 60, Z1
IPsec and AnyConnect share the same configured RADIUS and active directory servers
The use of a server identity certificate with a custom hostname is not supported at this time. Currently, the MX will automatically enroll in a publicly trusted certificate using the Meraki Dynamic DNS host name on the dashboard network. Follow the instructions on this doc to change the hostname.
A BETA firmware version is required. Known issues are listed below:
- Multicast on the LAN does not work as expected
- BGP routes do not show up on the dashboard route table but are present on the device

How to Enable AnyConnect on Your Dashboard

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

To enable AnyConnect, upgrade to the latest MX-16 firmware by navigating to Dashboard > Organization > Firmware upgrades. For more details on firmware upgrades see Managing Firmware Upgrades
For further inquiries, email meraki-anyconnect-beta@cisco.com

AnyConnect Server Settings

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. The MX uses the Meraki Dynamic DNS hostname when creating a CSR before getting it signed by a public CA. The resulting certificate renews automatically without any disruption in service.

Dashboard administrators do not have to worry about creating or transporting certificates or private keys to the MX or interacting with public CAs to get a CSR signed. At this time, we do not support uploading a server certificate or using a hostname other than the Dynamic DNS name.

Uploading a server identity certificate or using a hostname other than the Dynamic DNS name is not supported at this time. Please use the 'How to create a profile' documentation to create an alias for the Meraki DDNS hostname to ease connectivity for end-users.

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

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 the publicly trusted certificate enrollment. You can change this hostname by following the instructions here.
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.

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.
Authentication Type: This is used to specify authentication with Meraki Cloud, 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 time-out: 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.
DNS name servers: This specifies the 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 tunneled 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.
Default group policy: This is used to apply a default group policy to all connecting AnyConnect clients. For more details see Group Policies.

Authentication Methods

AnyConnect supports authentication with either 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.
Note: SAML authentication is not supported at this time.

Client Routing

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.

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.

Local LAN access

Local LAN access is desired when the Full tunneling is configured (Send all traffic through VPN) but users still desire to their local network for printing, etc 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. Internet traffic will still flow 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)

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 > 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

Client view:
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. Serial number for stage plot pro.

Connection logs can be found under the Message History tab.

Dashboard view:
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.

AnyConnect Event Logging

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.

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.

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.