TTechclick ⚡ XP 0% All lessons
Cisco · Meraki Cloud Networking · MX AutoVPN SD-WANInteractive · L1 / L2 / L3

Cisco Meraki MX & AutoVPN — SD-WAN, Hub-Spoke & Integrated Security

Meraki MX AutoVPN is the fastest way to build a secure SD-WAN fabric: one dashboard click turns any MX into a hub or spoke, tunnels form automatically, and the same appliance runs IPS, AMP, and content filtering — all managed from the cloud. This lesson maps the MX architecture, AutoVPN topologies, SD-WAN path selection, and the integrated security stack so you can answer any interview question or design a real network.

📅 2026-06-20 · ⏱ 17 min · 5 infographics · live block demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Master Cisco Meraki MX SD-WAN: AutoVPN hub-and-spoke and mesh topologies, dynamic path selection, integrated IPS/AMP/content filtering, and cloud-first management via the Meraki dashboard.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

MX overview

Cloud-managed appliance, licenses, and the dashboard model.

2

AutoVPN

Hub-spoke, full mesh, IPsec auto-broker, split vs full tunnel.

3

SD-WAN policy

Dynamic path selection, WAN health, per-flow steering.

4

Integrated security

IPS/Snort, AMP, content filtering, cloud updates.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Does configuring AutoVPN require you to set up IKE/IPsec manually on each MX?

Answered in AutoVPN.

2. How does Meraki SD-WAN choose which WAN link to use for a traffic flow?

Answered in SD-WAN policy.

3. Where are IPS rules and AMP signatures updated on a Meraki MX?

Answered in Integrated security.

Most engineers think…

Most people see 'SD-WAN' and picture a complex overlay with manual tunnel configs, IKE negotiation worksheets, and separate firewall boxes for IPS. That model fails you at interview and in production.

Cisco Meraki MX is a cloud-managed security appliance where the dashboard is the brain: you set a device as Hub or Spoke, save, and AutoVPN forms authenticated IPsec tunnels to every other hub or configured spoke automatically — no manual IKE, no pre-shared key spreadsheets. The SD-WAN engine then steers each flow to the best WAN link using live health metrics. On top of that the same box runs Snort IPS (Talos-updated), Cisco AMP for file inspection, and URL content filtering. Understanding that all of this lives in one dashboard-managed appliance is what lets you design, operate, and justify Meraki to an interviewer or a customer.

① The Meraki MX — cloud-managed security appliance and SD-WAN platform

The MX is Cisco Meraki's combined security appliance, firewall, and SD-WAN gateway. Every MX phones home to the Meraki cloud dashboard over an outbound management tunnel — no on-prem controller, no local CLI management for day-to-day operations. Configuration changes push from the cloud; telemetry, alerts, and event logs stream back the same way. This cloud-first model means a branch office MX can be shipped pre-configured, plugged in, and operational in minutes.

MX models span from small branch devices to high-throughput data-centre appliances. Licensing is the key decision: Enterprise license unlocks SD-WAN and AutoVPN; Advanced Security adds Cisco AMP and the Snort IPS engine; both are subscription-based and tied to the cloud dashboard. The Meraki cloud is not just a GUI — it is the control plane that brokers AutoVPN tunnels, holds org-wide policy, and pushes firmware.

Figure 1 — MX management flow — cloud-first control plane
Every MX management action flows through the Meraki cloud, not a local controller.MX management flow — cloud-first control planeAdminconfigures indashboardMeraki Cloudstores & pushespolicyMX Appliancereceives config changeTelemetryevents stream to cloudDashboardshows live status
Every MX management action flows through the Meraki cloud, not a local controller.
Quick check · Q1 of 10 · Understand

What is the role of the Meraki cloud in MX operations?

Correct: b. The Meraki cloud is the control plane — it holds org-wide policy, brokers AutoVPN tunnel negotiation, pushes configuration and firmware updates, and serves the dashboard. Packets still flow directly between MX devices.
👉 So far: Meraki MX is a cloud-managed security appliance — the Meraki cloud is the control plane, not just a GUI; it brokers AutoVPN, holds policy, and pushes firmware automatically.

② AutoVPN — hub-and-spoke and full mesh with zero manual IPsec

AutoVPN is the headline feature: navigate to Security & SD-WAN > Site-to-site VPN in the dashboard, set a device to Hub or Spoke, and the Meraki cloud broker negotiates authenticated IPsec tunnels between all eligible appliances — automatically, with no IKE worksheet. A device set to Hub builds tunnels to every other hub (full mesh between hubs) and acts as a gateway for its spokes. A device set to Spoke builds tunnels only to its configured hubs.

Topologies and tunnel modes

If all appliances in the organisation are set to Hub, the result is a full-mesh topology. Hub priority controls failover: the spoke sends traffic to the highest-priority hub that is reachable and advertising the target subnet. Traffic mode is either split tunnel (only site-to-site subnets go over VPN; internet breaks out locally) or full tunnel (the hub advertises a default route and all spoke traffic — including internet — exits through the hub). Dual-WAN MX appliances run AutoVPN over both links simultaneously, providing built-in redundancy.

Figure 2 — AutoVPN hub-and-spoke topology
The Meraki cloud broker forms IPsec tunnels automatically — spokes connect to hubs, hubs mesh with each other.AutoVPN hub-and-spoke topologyMeraki CloudVPN brokerHQ Hub MXDC Hub MXBranch Spoke 1Branch Spoke 2Branch Spoke 3
The Meraki cloud broker forms IPsec tunnels automatically — spokes connect to hubs, hubs mesh with each other.
Figure 3 — Split tunnel vs full tunnel AutoVPN
Split tunnel sends only site-to-site traffic over VPN; full tunnel routes all spoke traffic through the hub.Split tunnel vs full tunnel AutoVPNSplit TunnelSite-to-site subnets go over VPNInternet breaks out locally atLower hub bandwidth loadBest for branch internetFull TunnelHub advertises a default routeAll spoke traffic exits via hubCentral internet inspection at hubBest for compliance and filtering
Split tunnel sends only site-to-site traffic over VPN; full tunnel routes all spoke traffic through the hub.
🌐
Meraki Cloud (Control Plane)
tap to flip

The cloud broker that stores org policy, brokers AutoVPN tunnel formation, pushes firmware and config changes, and serves the dashboard UI — no on-prem controller needed.

🔗
AutoVPN Hub
tap to flip

An MX set to Hub builds IPsec tunnels to all other hubs (full mesh) and acts as a VPN gateway for its spokes. Hub priority controls failover order for spokes.

📡
AutoVPN Spoke
tap to flip

An MX set to Spoke builds tunnels only to its configured hubs. It uses hub priority to fail over and can run split tunnel (local internet) or full tunnel (all traffic via hub).

🛡️
Dynamic Path Selection
tap to flip

The MX probes each VPN tunnel for loss, latency, and jitter. SD-WAN policies define per-class thresholds; if the preferred link degrades, the MX steers the flow to the next best link instantly.

Name the broker, not just the tunnel

In an interview, say that AutoVPN tunnels are negotiated by the Meraki cloud broker — not by direct IKE between devices. That distinction explains why there is no manual IKE configuration and why a new MX can join the VPN fabric the moment it connects to the internet and checks into the cloud.

Quick check · Q2 of 10 · Apply

A branch MX is set as a Spoke with two hubs configured. Hub 1 loses its WAN link. What happens?

Correct: b. Hub priority controls spoke failover. When the highest-priority hub is unreachable, the spoke automatically builds its tunnel to the next-priority hub that is advertising the target subnet.
👉 So far: AutoVPN: set a device to Hub or Spoke in the dashboard; the cloud broker forms IPsec tunnels automatically. Hubs mesh with each other; spokes fail over by hub priority order.

③ SD-WAN policy and dynamic path selection — best link, per flow

SD-WAN on the MX is a suite of policies that steer traffic per-flow across available WAN links without manual intervention. The MX continuously probes each VPN tunnel using loss, latency, and jitter metrics. When you configure an SD-WAN policy, you specify per-traffic-class thresholds — for example, route VoIP flows only over a link with less than 50 ms latency and less than 1% loss. If the preferred link degrades past those thresholds, the MX instantly moves the flow to the next best link.

Meraki also supports application-aware path selection: traffic can be classified by application signature (e.g. Zoom, Office 365, Salesforce) and steered to the preferred WAN link regardless of IP or port. WAN health dashboards show live and historical loss/latency/jitter per link, making it easy to correlate performance complaints with WAN events. Cellular failover with integrated 4G/LTE on supported MX models provides a last-resort path when both WAN links fail.

Figure 4 — MX SD-WAN path selection — decision layers
The MX evaluates path selection in priority order, from policy match down to default routing.MX SD-WAN path selection — decision layersSD-WAN PolicyPer-class loss/latency/jitter thresholdsApp SignatureApplication-aware link preferenceWAN HealthLive probe metrics per tunnelDefault RouteHub priority or local internet
The MX evaluates path selection in priority order, from policy match down to default routing.
'SD-WAN is just failover' under-sell

Failover (active/passive) is only one mode. Meraki SD-WAN does per-flow dynamic path selection: different traffic classes can ride different links simultaneously based on live health metrics. VoIP goes on the low-latency link, bulk backup goes on the cheap broadband, and a video conference moves to the cellular backup the instant jitter spikes — all automatically.

▶ Watch a VoIP call steer from a degraded WAN link to a healthy backup

How SD-WAN dynamic path selection protects a real-time flow. Press Play for the healthy path, then Break it to see the failure mode.

① Call StartsA branch employee (spoke MX) places a VoIP call. The SD-WAN policy says: route RTP flows on any link with latency under 50 ms and loss under 1%.
② Probe OKThe MX probes both WAN tunnels. Primary link: 20 ms, 0% loss — within threshold. VoIP RTP flow is steered to the primary link.
③ Link DegradesISP congestion pushes the primary link latency to 90 ms. The MX detects the threshold breach within the next probe interval (typically a few seconds).
④ Path SwitchThe MX moves the VoIP flow to the secondary link (30 ms, 0% loss). The call continues without the user noticing a drop — SD-WAN steers mid-flow.
Press Play to step through the healthy SD-WAN steering path. Then press Break it.
Quick check · Q3 of 10 · Analyze

A VoIP SD-WAN policy sets a 50 ms latency threshold on the primary WAN link. Latency rises to 80 ms. What does the MX do?

Correct: c. Dynamic path selection is per-flow: when the primary link breaches the configured latency threshold, the MX steers matching flows to the next available link that meets the policy criteria, without dropping or renegotiating the session.
👉 So far: SD-WAN dynamic path selection is per-flow: the MX probes loss, latency, and jitter on every tunnel and moves flows to the best available link when thresholds are breached — no manual intervention.

④ Integrated security — IPS, AMP, and content filtering, Talos-updated

The MX runs three security engines without a separate appliance. The IPS engine is powered by Snort — the same engine used in Cisco Firepower — with rules curated by Cisco Talos. Rule sets are automatically pushed from the Meraki cloud; you choose between Connectivity (low-noise), Balanced, or Security (maximum coverage) rule modes. No manual signature downloads or scheduled jobs.

Cisco AMP (Advanced Malware Protection) inspects HTTP file downloads: the MX sends a file hash to the AMP cloud, which returns a disposition (clean / malicious / unknown). Malicious files are blocked; unknown files may be tracked retrospectively if a threat verdict changes. AMP requires Advanced Security licensing. Content filtering uses Talos URL categories to block or allow web destinations — the MX inspects the HTTP URL or the TLS SNI field, checks against a local cache of up to 100,000 Talos-categorised records, and enforces the policy with minimal latency impact. All three engines are cloud-updated, so the MX stays current with zero manual intervention.

Figure 5 — MX integrated security — inspection chain
All three security engines run on each MX, updated automatically by the Meraki cloud from Talos intelligence.MX integrated security — inspection chainTraffic Ininbound HTTP/HTTPSContent FilterTalos URL categoryIPS / Snortsignature rule matchAMP Checkfile hash vs AMP cloudAllow/Blockverdict + event log
All three security engines run on each MX, updated automatically by the Meraki cloud from Talos intelligence.

Priya at a Mumbai fintech startup faces this

After enabling the Snort IPS in Security mode on their MX hub, legitimate HTTPS API calls to a payment gateway start failing intermittently, causing transaction errors.

Likely cause

The IPS Security rule set has a signature that matches a pattern in the payment gateway's TLS handshake or HTTP payload, triggering a false positive block.

Diagnosis

Dashboard > Security & SD-WAN > Event log — filter for IDS alerts. Identify the signature ID firing on the payment gateway's IP. Cross-reference with Talos to confirm it is a false positive for this traffic.

Security & SD-WAN > Threat Protection > IDS/IPS mode + Event Log
Fix

Switch from Security mode to Balanced mode to reduce aggressive signatures, or create a Layer 7 bypass rule for the known-good payment gateway IP range. Alternatively, add a content policy exception to prevent the IPS engine inspecting that destination.

Verify

Re-test: payment API calls succeed; the event log shows no IDS alerts for the payment gateway IP. Monitor the event log for a week to confirm no recurring false positives.

Confirm security features need Advanced Security license

Cisco AMP and the full Snort IPS engine on MX require the Advanced Security Edition license. Enterprise license alone gives you SD-WAN and AutoVPN but not AMP. Always check the license tier when designing or troubleshooting — a security feature that appears in the dashboard may simply be greyed out due to insufficient licensing.

Quick check · Q4 of 10 · Remember

Which Cisco service curates and delivers the IPS rule updates to the Meraki MX?

Correct: b. Cisco Talos curates the IPS rule sets for the Meraki MX Snort engine. The Meraki cloud automatically pushes updated rules — no manual download or scheduling needed.
👉 So far: Three security engines in one MX: Snort IPS (Talos rules, auto-updated), Cisco AMP (file hash verdict from AMP cloud), and content filtering (Talos URL categories, local cache). Advanced Security license required for AMP and IPS.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Which Meraki MX configuration makes it build IPsec tunnels to ALL other hubs AND act as a gateway for spokes?

Correct: b. Hub mode causes the MX to mesh with all other hubs (full mesh between hubs) and to act as a VPN gateway for spoke devices that list it as a hub.
Q6 · Understand

A branch MX uses split-tunnel AutoVPN. A user visits a website. Which path does the traffic take?

Correct: d. Split tunnel sends only site-to-site VPN subnets over the tunnel. Internet-destined traffic exits directly from the branch MX's local internet WAN link, not through the hub.
Q7 · Apply

You need to protect branch internet breakout with IPS and content filtering on every branch MX. Which tunnel mode do you use?

Correct: a. IPS and content filtering run locally on each MX appliance. In split-tunnel mode, internet traffic exits the branch MX directly, so enabling IPS and content filtering on that spoke MX protects the branch breakout without requiring full-tunnel back-hauling. (Full tunnel is also valid for centralised inspection but is not the only correct approach — the question asks about protecting branch internet locally.)
Q8 · Analyze

Why can the Meraki cloud broker AutoVPN tunnels without the MX devices having static public IPs?

Correct: c. Each MX reports its current public IP (and NAT mapping) to the Meraki cloud. The cloud acts as a rendezvous/broker, sharing addressing info with peer MX appliances so they can negotiate IPsec tunnels even behind dynamic IPs or NAT.
Q9 · Evaluate

An interviewer asks: what is the benefit of Talos-backed automatic IPS updates on the Meraki MX? Best answer?

Correct: c. Talos is one of the largest commercial threat intelligence operations (monitoring billions of events daily). The Meraki cloud delivers curated rule updates automatically, closing the window between a new threat and protection — a key operational advantage over manually managed IPS appliances.
Q10 · Evaluate

A customer says: 'We want Cisco AMP on our MX but only have Enterprise licenses.' What do you tell them?

Correct: c. Cisco AMP and the Snort IPS engine on the MX are gated behind the Advanced Security Edition license. Enterprise license provides SD-WAN, AutoVPN, and basic layer 7 firewall, but not AMP or full IPS. The customer must upgrade to Advanced Security Edition to enable these features.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is Meraki AutoVPN easier to manage than traditional site-to-site IPsec VPN? Then compare with the expert version.

Expert version: Traditional IPsec requires manual IKE phase 1 and phase 2 configuration on both endpoints — pre-shared keys or certificates, encryption suites, lifetime timers — multiplied by every tunnel pair. Meraki AutoVPN eliminates all of that: the Meraki cloud acts as a broker, each MX registers its current public IP and NAT mapping, and the cloud negotiates authenticated tunnels between peers automatically. You just set Hub or Spoke in the dashboard and save. The same cloud also handles dynamic IPs and NAT traversal, so you do not need static public IPs or complex STUN/TURN setups. The result is that adding a new site means shipping a pre-configured MX, plugging it in, and watching the tunnel appear in the dashboard within minutes.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

AutoVPN
Meraki's zero-touch site-to-site VPN: set an MX as Hub or Spoke and the Meraki cloud broker negotiates IPsec tunnels automatically, with no manual IKE configuration.
Meraki Cloud (Control Plane)
The Meraki cloud service that stores org-wide policy, brokers AutoVPN tunnel formation, pushes firmware and config, and serves the dashboard UI.
Hub (AutoVPN)
An MX set to Hub builds IPsec tunnels to all other hubs (full mesh) and acts as a VPN gateway for spoke devices.
Spoke (AutoVPN)
An MX set to Spoke builds tunnels only to its configured hubs and fails over to the next-priority hub when the primary is unreachable.
Dynamic Path Selection
SD-WAN feature that probes VPN tunnels for loss, latency, and jitter and moves flows per-class to the best available link when thresholds are breached.
Snort IPS (on MX)
Intrusion Prevention System engine embedded in the MX, using Cisco Talos-curated rules delivered automatically from the Meraki cloud.
Cisco AMP
Advanced Malware Protection: the MX sends file hashes to the AMP cloud for a clean/malicious/unknown disposition on HTTP downloads. Requires Advanced Security license.
Cisco Talos
Cisco's threat intelligence research group that curates IPS signatures, AMP verdicts, and URL content-filtering categories used by the MX.
Split Tunnel
AutoVPN mode where only site-to-site subnets travel over VPN; internet traffic exits locally at the spoke MX.
Full Tunnel
AutoVPN mode where the hub advertises a default route so all spoke traffic, including internet, is back-hauled through the hub.

📚 Sources

  1. Cisco Meraki Documentation — Meraki Auto VPN: Configuration and Troubleshooting (hub/spoke/mesh, IPsec broker). documentation.meraki.com/SASE_and_SD-WAN/MX
  2. Cisco Meraki Documentation — Meraki SD-WAN: dynamic path selection, WAN health, per-flow steering. documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure
  3. Cisco Meraki Documentation — Threat Protection: Snort IDS/IPS and Talos rule modes (Connectivity, Balanced, Security). documentation.meraki.com/SASE_and_SD-WAN/MX/Operate_and_Maintain/Content_Filtering_and_Threat_Protection/Threat_Protection
  4. Cisco Meraki Documentation — Advanced Malware Protection (AMP): file hash inspection and Advanced Security licensing. documentation.meraki.com/SASE_and_SD-WAN/MX/Operate_and_Maintain/Content_Filtering_and_Threat_Protection/Advanced_Malware_Protection_(AMP)
  5. Cisco Meraki Documentation — Content Filtering: Talos URL categories, SNI inspection, and local cache. documentation.meraki.com/SASE_and_SD-WAN/MX/Operate_and_Maintain/Content_Filtering_and_Threat_Protection/Content_Filtering
  6. Cisco Meraki — MX Family datasheet: SD-WAN, AutoVPN, IPS, AMP, content filtering feature summary. meraki.cisco.com/product-collateral/mx-family-datasheet

What's next?

Got the MX architecture? Next, go deep on Meraki MR wireless and how the cloud-managed access layer integrates with the same dashboard for unified wired and wireless policy.