Meraki Vpn Anyconnect
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 …
- When using Systems Manager Sentry VPN security, the username and password used to connect to the client VPN are generated by the Meraki cloud. Usernames are generated based on a hash of a unique identifier on the device and the username of that device.
- AnyConnect Specific Features. AnyConnect is more than just a VPN client. It is a fully-fledged end-point mobility client solution. However, unlike the AnyConnect implementation on the ASA or FirePOWER with support for multiple features like Host scan, Web launch, etc, the MX security appliance supports SSL Core VPN and other AnyConnect modules that do not require additional configuration on.
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.
The Conclusion - meraki VPN client anyconnect to test makes definitely Sense! The Group of promising Means, to those meraki VPN client anyconnect counts, is unfortunately very often merely short time on the market, because the fact, that Natural sun effective can be, sets Competitors under pressure.
Configuration
The configuration is Meraki-easy as expected. For a basic setup we need:
- Enable AnyConnect Client VPN
- Change or accept the AnyConnect-port (default 443) and login-banner (default “You have successfully connected to client vpn.”)
- Upload a client profile (optional, but I would always do so)
- Configure the Authentication (RADIUS, Meraki Cloud or AD)
- Configure the AnyConnect VPN subnet, Nameservers and DNS Suffix
- 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.
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-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
AnyConnect supports authentication with either RADIUS, Active Directory, or Meraki Cloud. For more details on AnyConnect configuration, refer to the AnyConnect configuration guide.
Note: Systems Manager with Sentry is not supported with AnyConnect.
Note: SAML authentication is not supported at this time.
Meraki Anyconnect Beta
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
Meraki Vpn Vs Anyconnect
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.
Meraki Mx Vpn Anyconnect
RADIUS Time-Out
Meraki Vpn Anyconnect Free
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.