Summary: Explains how Meraki devices connect to and are managed by the Meraki cloud, covering control/data plane separation, protocols and ports, certificate-based authentication, configuration delivery, resilience during cloud outages, and the security controls protecting the management channel.
Meraki devices are managed entirely through the Meraki cloud platform, accessed via the dashboard at dashboard.meraki.com. Every Meraki device — MX, MS, MR, MV, MT — establishes and maintains an outbound connection to the Meraki cloud over the internet.
Key architectural principles:
Meraki's cloud infrastructure is globally distributed and hosted on major cloud providers. Devices connect to the nearest available Meraki cloud region, with automatic failover between regions.
This separation is fundamental to understanding how Meraki operates.
| Plane | What it carries | Path |
|---|---|---|
| Control plane | Configuration, telemetry, event logs, firmware, monitoring data | Device ↔ Meraki cloud (outbound HTTPS) |
| Data plane | User traffic — internet, inter-VLAN routing, VPN, wireless client traffic | Device ↔ network directly (never touches Meraki cloud) |
Examples of data plane traffic flowing without any Meraki cloud involvement:
The practical consequence is that a Meraki network continues to pass user traffic normally even when cloud connectivity is lost. The cloud is only required to make configuration changes or view monitoring data.
Meraki devices require the following outbound connectivity to reach the cloud:
| Protocol | Port | Purpose |
|---|---|---|
| TCP | 443 | Primary management channel — HTTPS/TLS to Meraki cloud endpoints |
| UDP | 7351 | Meraki management communication (some device types and features) |
| TCP/UDP | 53 | DNS — resolving Meraki cloud FQDNs |
Traffic is directed to Meraki cloud hostnames including *.meraki.com and *.cisco.com. The definitive and up-to-date list of required FQDNs and ports is maintained in Meraki's firewall rules documentation.
⚠️ Firewall Rules for Meraki Management
If a Meraki device is behind a stateful firewall, outbound access on TCP 443 and UDP 7351 to Meraki cloud endpoints must be permitted. Blocking these ports will prevent the device from connecting to the dashboard. The MX's own firewall does not need a rule for its own management traffic — the MX self-manages its outbound cloud connection — but upstream firewalls protecting the management interface do.
Every Meraki device is provisioned at the factory with a unique X.509 device certificate signed by Meraki's certificate authority. This certificate is used to authenticate the device to the Meraki cloud when establishing the management connection.
The authentication process:
This mechanism ensures that only genuine Meraki hardware can connect to the management plane. Cloned or counterfeit devices cannot obtain a valid factory certificate and will be rejected.
Claiming a device to a Meraki organisation requires entering its serial number in the dashboard. The cloud then associates the device's certificate with that organisation. A device can only belong to one organisation at a time — it must be removed from one organisation before it can be added to another.
Meraki uses a desired-state model for configuration delivery:
Full configuration synchronisation occurs on initial device registration and after extended connectivity gaps; incremental updates are delivered for subsequent changes. The time between making a change in the dashboard and the device applying it is typically a few seconds under normal conditions.
Meraki devices are designed to operate autonomously when cloud connectivity is interrupted. The current applied configuration remains fully in effect.
| Function | Behaviour during cloud outage |
|---|---|
| Routing and switching | Continues normally — forwarding decisions are made locally |
| Firewall and NAT | ACL rules and NAT rules remain active |
| DHCP | Leases continue to be served (MX DHCP server) |
| SSID availability | SSIDs remain up; clients can connect |
| 802.1X authentication | Continues if a local or on-premises RADIUS server is in use; fails if the RADIUS server is cloud-hosted and unreachable |
| Meraki splash pages | Cloud-hosted splash pages requiring check-in will fail |
| AutoVPN — existing tunnels | Remain active; the tunnel is maintained peer-to-peer |
| AutoVPN — new tunnels | May fail to establish — the Meraki cloud acts as the VPN registry; new peers cannot be discovered without it |
| Configuration changes | Not possible — the dashboard is unavailable |
| Dashboard monitoring | Stops updating; event logs buffer locally |
When connectivity is restored, devices re-authenticate, upload buffered event logs and telemetry, and synchronise any configuration changes that were queued during the outage.
⚠️ AutoVPN and Cloud Dependency
While existing AutoVPN tunnels survive a cloud outage, new tunnel establishment depends on the Meraki cloud as a rendezvous and key negotiation point. Sites that have never established a tunnel to a given peer, or whose tunnel has expired, may be unable to bring up new VPN connections until cloud connectivity is restored.
Meraki applies several layers of security to protect the management channel: