Does your Meraki MX support Cisco Secure Client?

Two support threads disagree about whether Meraki can do AnyConnect, and both are confidently wrong in the same way. The question is not whether an MX speaks IKEv2, because AnyConnect on the appliance is a TLS service rather than an IPsec one. Two separate checks decide the answer, and neither is a brand comparison. Work them in order and you get a compatibility record instead of an opinion.

Model and release come first

Start with the exact appliance and the software it runs, because the feature is scoped to both. Meraki publishes a matrix naming supported models and the minimum firmware, and that matrix is the only authority worth quoting. A model that appears in the list is not automatically on a release that supports the feature, and a release that supports it may not be the one you are running. Record the model and the installed firmware as two separate facts. Then read the matrix for that pair.

Do not reason from a similar model in the same family. The list is per model, and the differences are real.

AnyConnect is an SSL service, not IPsec

Meraki describes AnyConnect on the MX as a TLS and DTLS application-based VPN, and documents it beside a separate L2TP/IPsec client VPN service. Those are two products that happen to share a dashboard. Comparing IKEv1 against IKEv2 tells you about the IPsec service and nothing about whether the TLS service exists on your appliance. If your evidence is an IKE version table, you have been answering a different question.

Identify which service the appliance exposes before comparing clients. A working L2TP/IPsec profile does not become an AnyConnect profile because it reaches the same organisation, and the two need different client configuration.

Which features the MX actually offers

Cisco's ASA feature list is not the MX feature list, and a client that supports twelve things does not make the gateway support them. Compare the functions you actually need: authentication method, split tunnelling behaviour, DNS handling, and whatever entitlement the appliance requires. Take each from the Meraki documentation for the deployed release.

Authentication is where this usually bites. A method the client offers and the appliance cannot configure is a support case waiting to happen.

Client version and entitlement

Cisco Secure Client is the current name for the same client family, so a document mentioning AnyConnect is not necessarily stale. What matters is the version your organisation deploys and whether the appliance release is validated against it.

Check the licensing requirement in the same guide rather than assuming it from another platform. Then keep the endpoint name, certificate verification and approved authentication workflow together in one service record, because those three fail independently. A certificate warning that users click through is not a compatibility result; it is an unverified configuration. Remote access is also only half the job, since the user still needs routes and permissions to reach the destination.

Write the record with five fields

Model, firmware, remote-access mode, client version, and the functions the deployment requires. Five fields, and the answer to can we use AnyConnect lives in the combination rather than in any single one of them. That record also tells the next engineer what to recheck after a firmware upgrade.

Then test the path end to end: authenticate, resolve an internal name, reach a permitted resource, and confirm a resource you should not reach is refused. A login that succeeds with a resource that never loads is a partial result, and the missing half is usually routing or authorization rather than the client. File the tested combination with the change, so the next person inherits evidence instead of a slogan.