Why won't my Meraki AutoVPN tunnel form even though both sites are online?

Most often an upstream firewall is blocking the VPN registry. Both MX appliances must reach the Meraki cloud registry on UDP 9350-9381 outbound. If one MX can reach the registry but the peer can't, the tunnel never forms. Check Security & SD-WAN > Monitor > VPN status — a 'NAT type: Unfriendly' or registry-unreachable flag points straight at the upstream filter.

What is the difference between hub-and-spoke and full-mesh AutoVPN on Meraki?

In hub-and-spoke, every spoke builds a tunnel only to the designated hub(s); spoke-to-spoke traffic transits the hub. In full-mesh, every site is a Hub, so every site tunnels to every other site directly. Mesh gives the lowest latency but the tunnel count grows as N*(N-1)/2 — 50 sites = 1,225 tunnels. For scale, Cisco recommends dedicated hubs and hub-and-spoke.

What does 'NAT type: Unfriendly' mean on a Meraki MX and how do I fix it?

It means the upstream NAT device won't allow the MX to use UDP hole punching to form AutoVPN tunnels. The fix is to set NAT traversal to Manual: Port forwarding under Security & SD-WAN > Configure > Site-to-site VPN, and forward the chosen UDP port (default 51200 range) on the upstream router to the MX WAN IP.

What is a Meraki SD-WAN performance class and when does traffic fail over?

A performance class defines minimum thresholds for latency, jitter and loss. The built-in VoIP class targets low latency/jitter/loss; you can also build a custom class. When the active uplink breaches the class threshold, matching flows fail over to the other uplink — without dropping the session. ICMP is not subject to traffic shaping, so ping alone won't show the steering.

Which Meraki MX models support SD-WAN Plus?

SD-WAN Plus (which unlocks Internet flow preferences and richer SD-WAN policy) is available on supported MX models including MX67, MX68, MX75, MX85, MX95, MX105, MX250 and MX450. With an SD-WAN Plus licence you see 'Internet flow preferences' plus the ability to configure SD-WAN policies in the dashboard.

Which outbound UDP port range must reach the Meraki cloud for AutoVPN's VPN registry to work?

Correct: a. AutoVPN's registry uses outbound UDP 9350–9381 from the MX WAN to the Meraki cloud. It is not standard IKE 500/4500 (c) — that's classic IPsec, not the registry. The ports are UDP, not TCP (d), and 443 alone (b) won't carry the registry keepalives.

Sneha must connect 40 branches to a single datacentre. Branch-to-branch traffic is rare; HQ is the only common destination. Which topology does she configure?

Correct: b. Rare branch-to-branch + a single common HQ destination is the textbook hub-and-spoke case. Full-mesh (a) would create 820 tunnels for no benefit. Mixing hubs/spokes arbitrarily (d) just inflates tunnel count. No VPN (c) defeats the requirement.

A datacentre MX terminates 250 spokes AND routes for 400 LAN clients, and CPU is pegged. What's the cleanest fix?

Correct: c. A dedicated one-armed VPN concentrator offloads LAN routing so the MX spends its CPU purely on tunnels — the documented scale design. Disabling keepalives (a) breaks the registry. Making spokes hubs (b) multiplies tunnels. MTU (d) is unrelated to CPU.

Two MXs are both online in the org dashboard, yet the tunnel between them never forms. Site A's NAT type shows "Friendly", Site B's shows "Unfriendly". What's the most likely cause and fix?

Correct: d. "Unfriendly" NAT means the upstream device won't allow hole punching, so the peer can't be reached. Manual port forwarding bypasses it. Model mismatch (a) doesn't block AutoVPN. Expired licence (b) would flag org-wide, not as a NAT type. Site A's DNS (c) is unrelated — A is already "Friendly".

After enabling AutoVPN, two sites form a tunnel, but hosts on each side can't reach each other and the dashboard won't install the routes. Both sites use 192.168.1.0/24 on their LAN. Root cause?

Correct: b. Identical subnets on both ends create a routing conflict — the MX can't know which side "owns" 192.168.1.0/24, so no route installs. The classic fix is to re-IP one LAN. The tunnel did form (rules out d and a), and performance classes (c) affect uplink steering, not VPN routing.

A team wants every one of 70 retail stores to reach every other store with the lowest possible latency, and proposes setting all 70 to Hub for a full mesh. As the reviewer, is this sound for a fleet of MX67s?

Correct: d. The proposal ignores tunnel-count scaling (2,415 tunnels) and the modest capacity of MX67s. The right trade-off is dedicated hubs and a one-hop transit for inter-store traffic, which is rare in retail anyway. Full mesh isn't "always best" (a). Disabling the registry (b) breaks AutoVPN. VPN scales far past 10 sites with the right design (c is false).

Two designs for a 5,000-user SOC branch with fibre + LTE: (X) plain failover only, or (Y) SD-WAN+ with a VoIP performance class and RTP flow preference. Which is right and why?

Correct: c. Plain failover is blind to "brownouts" — a congested-but-alive link still carries voice badly. SD-WAN+ performance classes act on latency/jitter/loss, steering voice proactively. They are not identical (b), voice quality clearly matters in a 5,000-user site (a), and the win has nothing to do with LTE being faster (d) — it's about picking whichever link currently meets the bar.

Cisco Meraki MX & AutoVPN SD-WAN — Tick One Box, Tunnels Build Themselves

30-second warm-up — don't peek

Three quick predictions before we start. You won't be scored — this just primes your brain to notice the answers as they show up below.

Q. AutoVPN tunnels use IPsec — true or false? (watch Section 1)
Q. For 50 sites, is full-mesh or hub-and-spoke the saner choice? (Section 2)
Q. Which outbound UDP ports must reach the Meraki cloud for AutoVPN to work? (Section 4)

Why this matters — the chai-tapri version

Think of an IPsec VPN the old way: two routers, matching crypto maps, a shared secret, and a public IP on both ends. Add a 30th branch and you are editing 29 configs. Now picture a WhatsApp group instead. You don't dial each member's number — you join the group and you can instantly message everyone. Meraki AutoVPN is that group. Each MX checks in with a cloud "directory", and the directory tells every member how to reach every other member. You tick one box; the tunnels build themselves.

Imagine every branch office is a kid in a classroom. Normally, for two kids to pass secret notes, they'd each need the other's exact desk address — and you'd rewrite all of them every time a new kid joins. Meraki AutoVPN is like a friendly class monitor (the cloud) who knows where everyone sits. Each kid tells the monitor "here I am", and the monitor whispers everyone's seat to everyone else. Now any two kids can pass encrypted notes directly. You didn't set up a single address by hand.

In production this is the difference between a 3-week VPN rollout and a 3-day one. Interviewers love it too: "How does Meraki form a VPN without you configuring IPsec?" is a top-5 question in any Meraki or SD-WAN screen. Get the registry story right and you sound like you've actually deployed it.

Big picture: the cloud registry is the control plane (dashed). The blue lines are the actual encrypted data tunnels — they ride the internet directly between MX boxes, not through the cloud.

Four words you'll hear in every Meraki VPN conversation

☁

VPN Registry

tap to flip

The cloud "directory". Each MX checks in every 10 seconds; it hands out everyone's public IP + port so peers can reach each other. No registry = no AutoVPN.

🕳

UDP Hole Punching

tap to flip

How two MX boxes behind NAT reach each other. Each opens an outbound UDP flow; the registry swaps the port mappings so the tunnel forms without inbound port-forwarding.

🎯

Hub

tap to flip

An MX set to "Hub" tunnels to every other Hub and to any spoke that lists it. Datacentre MXs are hubs; for scale, keep them dedicated.

🛰

Concentrator

tap to flip

An MX in one-armed mode (no LAN routing) that only terminates VPN tunnels. The classic datacentre design — it aggregates spokes, nothing else.

① AutoVPN & the registry — watch a tunnel form

Here's the climax reveal: AutoVPN does use IPsec under the hood — but you never touch a crypto map. The MX negotiates IPsec automatically once the registry has introduced the two peers. So the pre-quiz answer is "true, but you don't configure it." That's the part most freshers get wrong in interviews.

Let's trace it. Aditya at a Pune branch wants to reach the HQ file server. His MX has never spoken to the HQ MX before. Press Play and watch the handshake.

▶ Watch AutoVPN form a tunnel

Click Play. Each stage lights up as the two MX appliances meet through the cloud registry.

① REGISTER Pune MX → registry: "I'm 203.0.113.40, NAT'd, here are my LAN subnets"

▼

② REGISTER HQ Hub MX → registry: "I'm 198.51.100.5, advertising 10.0.0.0/16"

▼

③ INTRODUCE Registry tells each peer the other's public IP + UDP port. This is the control plane only — no data yet.

▼

④ HOLE PUNCH Both MXs send outbound UDP to each other. NAT lets the return packets back in — tunnel path opened with no inbound rule.

▼

⑤ IPSEC The MXs auto-negotiate IPsec (AES). You configured none of it. 🔒 Encrypted tunnel up.

▼

⑥ DATA Aditya's traffic to 10.0.0.20 now rides the direct tunnel — Pune ↔ HQ, not through the cloud.

Press Play to step through how two MX boxes that have never met form an encrypted tunnel. Next advances one stage.

Scenario · Aditya at Infosys

Aditya enables Site-to-site VPN on the Pune MX and picks the HQ as its hub. Within ~40 seconds the dashboard shows a green tunnel. He didn't open a single inbound firewall port on the branch router — UDP hole punching did it. His teammate asks "where are the pre-shared keys?" Aditya's answer: "There aren't any I typed. The cloud brokered it."

The actual config — three clicks

Dashboard · Security & SD-WAN > Configure > Site-to-site VPN

Type:        ◉ Spoke        (HQ MX = ◉ Hub)
Hubs:        [ HQ-Datacentre ▼ ]   Default route: ☐
Local networks in VPN:
  VLAN 20  10.20.0.0/24   ☑ Use VPN: yes
NAT traversal:  ◉ Automatic
→ Save

Expected — Security & SD-WAN > Monitor > VPN status

Peer            Status     Last contact   NAT type
HQ-Datacentre   ● Online   3 sec ago      Friendly
Tunnel: 10.20.0.0/24  ⇄  10.0.0.0/16  (AES, up 41s)

Pause & Predict

If the Meraki cloud registry went completely offline for 10 minutes, would your existing AutoVPN tunnels keep passing data? Decide before you reveal.

Existing tunnels keep flowing. The registry is the control plane — it introduces peers and refreshes keepalives. Established data tunnels run MX-to-MX directly, so a brief registry outage doesn't tear them down. New tunnels and re-keys after a long outage are what break. This is why the registry being reachable matters most at tunnel setup.

Quick check · Q1 of 10

A junior engineer claims "Meraki AutoVPN is its own protocol, it doesn't use IPsec." How do you correct them?

a) They're right — AutoVPN is a proprietary non-IPsec tunnel b) AutoVPN does use IPsec for the data tunnel; the cloud registry just automates peer discovery and key exchange so you never configure crypto maps c) AutoVPN uses SSL/TLS like a browser VPN d) AutoVPN tunnels all data through the Meraki cloud

Correct: b. The data plane is standard IPsec (AES). The Meraki cloud registry handles introductions + key brokering so admins skip crypto maps and pre-shared keys. Data rides directly MX-to-MX — not through the cloud (that kills option d). It is not SSL (c) and not non-IPsec (a).

② Hub-and-spoke vs full-mesh — pick the right shape

Every site can be a Hub or a Spoke. That one toggle decides your whole topology. The trap: full-mesh feels "better" because every site talks to every site directly — lowest latency. But the tunnel count explodes.

The math is N×(N-1)/2. Ten sites = 45 tunnels. Fifty sites = 1,225 tunnels. Each MX has a finite tunnel + route capacity, so mesh quietly hits a ceiling. Cisco's own best practice: for scale, use hub-and-spoke with dedicated hubs.

Decision tree: full-mesh only for small, latency-critical, any-to-any needs. Everything bigger leans hub-and-spoke with dedicated hubs.

Scenario · Priya at TCS

Priya is asked to connect 60 retail stores to two datacentres. She almost sets every store as a Hub for "fast store-to-store". Then she does the math — 60 hubs would mean 1,770 mesh tunnels and the small MX67s would choke. She switches the stores to Spokes pointing at two dedicated MX450 hubs. Store-to-store traffic transits a hub (one extra hop, fine for retail). Tunnel count per store drops to two.

Architect note: when you need spoke-to-spoke without hub transit, you can still keep hub-and-spoke and rely on the spokes learning each other's routes via the hub — but true direct spoke-to-spoke needs the spokes to also be hubs, which reintroduces the mesh scaling problem. The clean answer for large fleets is dual dedicated hubs for redundancy, and accept the single hub-transit hop for inter-spoke flows.

🧪 Firewall & routing lab 📘 Refresher: zones & routing

Pause & Predict

You set a branch MX to "Hub" by mistake instead of "Spoke", in an org that already has 40 hubs. What happens to that branch's tunnel count?

It tries to tunnel to all 40 other hubs. A Hub forms tunnels to every other Hub plus any spoke that lists it. A small branch MX suddenly building 40+ tunnels can exhaust its capacity, spike CPU, and flap. The symptom you see: that one branch shows dozens of tunnels and intermittent VPN status. The fix: set it back to Spoke pointing at the right hub.

Quick check · Q2 of 10

A 25-site deployment is configured full-mesh. The team plans to grow to 80 sites next year. What should you flag in design review?

a) Mesh tunnel count grows as N×(N-1)/2 — 80 sites ≈ 3,160 tunnels; migrate to hub-and-spoke with dedicated hubs before scaling b) Nothing — full-mesh scales linearly c) Buy bigger internet circuits and keep mesh d) Disable the VPN registry to reduce overhead

Correct: a. Tunnel count is the scaling wall, not bandwidth (c). 80 sites in full mesh ≈ 3,160 tunnels — far beyond small/mid MX capacity. Hub-and-spoke with dedicated hubs is the documented scale design. Disabling the registry (d) would break AutoVPN entirely.

③ SD-WAN+ — send the right traffic over the right link

Branches usually have two uplinks — say a fibre line and a 4G/LTE backup. Plain failover only switches when a link dies. SD-WAN is smarter: it watches latency, jitter, and loss, then moves sensitive traffic to the better link before the user notices.

On Meraki this lives in two controls. Flow preferences pin a flow to a chosen uplink (e.g. "Office 365 always over WAN1"). Performance classes define the quality bar — the built-in VoIP class, or a custom one — and traffic fails over when the active link breaches it. SD-WAN+ (the upgraded licence) adds Internet flow preferences on top.

▶ Watch a VoIP call get steered

A Teams call is on WAN1 (fibre). Jitter spikes. Watch SD-WAN move it to WAN2 mid-call.

① BASELINE Voice flow 10.20.0.55 → cloud PBX on WAN1 fibre · latency 18ms, jitter 4ms ✓

▼

② PROBE MX sends active probes both uplinks. WAN1 jitter climbs to 62ms (neighbour saturating the fibre).

▼

③ CLASS BREACH VoIP performance class threshold (jitter ≤ ~20ms) is exceeded on WAN1. Decision triggered.

▼

④ STEER MX moves the voice flow to WAN2 (LTE) — latency 26ms, jitter 9ms. Call never drops.

▼

⑤ RECOVER WAN1 jitter settles. MX can move the flow back per policy. Bulk downloads stayed on WAN1 the whole time.

Press Play. Notice: only the voice flow moves — file traffic is unaffected. That's policy steering, not blunt failover.

SD-WAN pipeline: classify → flow preference → performance class → uplink. The breach path (amber) is the failover that keeps the call alive.

Building a VoIP-steering policy

Dashboard · Security & SD-WAN > Configure > SD-WAN & traffic shaping

Uplink selection > SD-WAN policies > Add a preference
  Traffic filter:   Custom — Protocol UDP, dst port 16384-32767 (RTP)
  Source:           10.20.0.0/24
  Preferred uplink: WAN 1
  Fail over if:     Performance class = VoIP   (latency/jitter/loss bar)
→ Save

Expected — Monitor > Uplink (during a WAN1 jitter spike)

Flow: voice 10.20.0.55  active uplink: WAN2 (failover)  reason: VoIP class breach
WAN1 jitter 62ms (bar ~20ms)   WAN2 jitter 9ms
Bulk flow 10.20.0.71            active uplink: WAN1 (unchanged)

Scenario · Karthik at Wipro

Karthik's branch users complain Teams calls "go robotic around 2pm" daily. Ping looks perfect — because ICMP isn't shaped. He builds a VoIP performance class and a flow preference for RTP. Now at 2pm, when the shared fibre saturates, voice silently rides the LTE uplink and the robotic audio disappears. The bulk file sync stays on fibre. Users notice nothing — which is the point.

Pause & Predict

A branch has only ONE uplink (no LTE backup). You build a VoIP performance class anyway. Does it do anything useful?

With one uplink, there's nowhere to steer. A performance class fails traffic over to a healthy link — but a single-uplink branch has no alternate path. The class can flag the breach in monitoring, yet it can't fix the voice quality. SD-WAN steering needs two or more uplinks to actually help. The real fix for a single-link site is QoS/traffic shaping to protect voice from bulk traffic on that one link.

Quick check · Q3 of 10

You built a VoIP flow preference but testing with continuous ping across the WAN shows no uplink change during congestion. Why?

a) The policy is broken — rebuild it b) SD-WAN only works on the LAN side c) ICMP is not subject to traffic shaping / flow preferences, so ping won't reflect SD-WAN steering — test with real RTP or the dashboard's per-flow uplink view d) You need to reboot the MX after every policy change

Correct: c. Meraki explicitly exempts ICMP from traffic shaping, so flow preferences have no effect on ping. The policy can be perfectly correct (a is wrong). SD-WAN steers WAN-bound flows (b wrong), and policy changes apply without a reboot (d wrong). Validate with actual app traffic or Monitor > Uplink.

④ "Tunnel won't form" — the 4-step playbook

This is the single most common Meraki VPN ticket. The good news: ~90% of cases are one of four causes, and you can rule them out in under two minutes from the dashboard.

▶ Diagnose a stuck tunnel

A spoke shows red in VPN status. Step through the diagnosis ladder.

① REGISTRY REACH Check both peers reach the registry: outbound UDP 9350–9381 open on each upstream firewall?

▼

② NAT TYPE VPN status shows "NAT type: Unfriendly" → upstream NAT blocks UDP hole punching.

▼

③ FIX NAT Set NAT traversal = Manual: Port forwarding; forward the chosen UDP port on the upstream router to the MX WAN IP.

▼

④ SUBNETS / MTU Confirm both sides advertise non-overlapping subnets, and large packets aren't dropped — lower MX VPN MSS/MTU if a path has low MTU.

▼

⑤ GREEN Peer flips to Online. Tunnel up. Keepalives every 10s keep it registered.

Press Play. The order matters — registry reachability first, NAT type second. Most tickets die at stages 1–3.

Common mistakes — symptom first

Symptom: tunnel never forms, both MXs show online in the org. → Cause: upstream firewall blocks the registry. Allow outbound UDP 9350–9381 from the MX WAN to the Meraki cloud.
Symptom: VPN status reads "NAT type: Unfriendly". → Cause: a symmetric / strict NAT upstream defeats UDP hole punching. Switch NAT traversal to Manual: Port forwarding and forward the port.
Symptom: tunnel forms but some apps hang / large file transfers stall. → Cause: MTU / fragmentation on a low-MTU path (often DSL/PPPoE). Lower the VPN MSS/MTU.
Symptom: a single branch shows dozens of tunnels and flaps. → Cause: it was set to Hub in a multi-hub org. Set it back to Spoke.
Symptom: routes don't appear / "subnet conflict". → Cause: two sites advertise overlapping subnets (both 192.168.1.0/24). Re-IP one side; AutoVPN won't install conflicting routes.

Pro tips from the field

Keep hubs dedicated. A datacentre MX that's also serving LAN clients and terminating 200 spokes will hit CPU before it hits bandwidth. Use a one-armed VPN concentrator.
Patch the AnyConnect DoS. CVE-2025-20271 (CVSS 8.6) lets an unauthenticated attacker restart the MX AnyConnect VPN server. If you use AnyConnect with client-cert auth, upgrade to fixed firmware (e.g. 18.107.13 / 18.211.6 / 19.1.8 branches) via Organization > Firmware upgrades.

Yaad rakhna (interview gold)

The registry is control plane only. Data never tunnels through the Meraki cloud — it rides directly MX-to-MX. If an interviewer asks "isn't that a privacy risk, Meraki seeing my traffic?", the answer is no: the cloud brokers introductions, your encrypted data stays on your own internet path.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated from Meraki documentation + community Q&A. For live prod issues, paste your VPN status + event log into chat.techclick.in.

✍️ In your own words

One line, no peeking: why is the Meraki cloud registry a control-plane component and not a data-plane one? Type your answer, then reveal the model answer to compare.

Model answer: The registry only introduces peers (shares public IP + port mappings) and tracks keepalives — it never carries user packets. Once peers are introduced, the encrypted IPsec data tunnel runs directly MX-to-MX over the internet, so the cloud sees no traffic. Control plane = who-can-reach-whom; data plane = the actual bytes, which stay off the cloud.

🗣 Teach a friend

Tap to generate a one-liner you can paste to a colleague — the fastest way to lock in what you just learned.

📩 Quiz me later

Opt in and we'll send you 3 micro-questions on this lesson at Day 1, Day 7, and Day 30 — spaced repetition is how this actually sticks. Opt-in only; unsubscribe anytime.

✓ You're in. Watch for Day-1, Day-7 and Day-30 micro-quizzes.

📖 Glossary — the terms in this lesson

AutoVPN: Meraki's cloud-brokered site-to-site VPN. You tick Hub/Spoke; the cloud automates IPsec peer discovery and key exchange.
VPN registry: The Meraki cloud directory that introduces MX peers and tracks keepalives. Control plane only — no user data passes through it.
UDP hole punching: Technique letting two NAT'd MXs reach each other via outbound UDP flows the registry coordinates — no inbound port-forward needed.
Hub / Spoke: Topology roles. A Hub tunnels to every Hub + listing spoke; a Spoke tunnels only to its chosen hub(s).
VPN concentrator: A one-armed MX that only terminates VPN tunnels (no LAN routing) — the scalable datacentre aggregation design.
SD-WAN: Policy-based steering of app traffic across multiple WAN links by performance, not just up/down state.
SD-WAN+: The higher Meraki licence tier; unlocks Internet flow preferences and richer SD-WAN policy.
Flow preference: A rule pinning a matched flow to a chosen uplink (e.g. O365 over WAN1).
Performance class: A latency/jitter/loss quality bar (built-in VoIP or custom). Breach it and matching flows fail over.

One-glance cheat sheet: the six facts that answer 90% of Meraki AutoVPN + SD-WAN interview and ticket questions.

Quick reference — last-minute revision card

Topic	Key fact	Where
Enable AutoVPN	Set Hub or Spoke, tick subnets, Save	Security & SD-WAN > Configure > Site-to-site VPN
Registry ports	Outbound `UDP 9350–9381` to Meraki cloud	Upstream firewall
Keepalive	Every 10s; >6 missed = node marked down	Registry
NAT "Unfriendly"	Set NAT traversal = Manual: Port forwarding	Site-to-site VPN settings
Scale topology	Hub-and-spoke + dedicated hubs; mesh = N(N-1)/2 tunnels	Design choice
SD-WAN+ models	MX67/68/75/85/95/105/250/450 (and more)	Licensing
VoIP steering	VoIP performance class + RTP flow preference	SD-WAN & traffic shaping
ICMP gotcha	ICMP is NOT traffic-shaped — ping won't show steering	Testing
2025 advisory	CVE-2025-20271 AnyConnect DoS — patch firmware	Organization > Firmware upgrades

📚 Sources

Cisco Meraki Documentation — Meraki Auto VPN — Configuration and Troubleshooting. documentation.meraki.com
Cisco Meraki Documentation — Configuring Hub-and-spoke VPN Connections on the MX Security Appliance & Auto VPN General Best Practices.
Cisco Meraki Documentation — SD-WAN and Traffic Shaping & MX Load Balancing and Flow Preferences.
The Meraki Community — AutoVPN Troubleshooting & AutoVPN tunnels not re-establishing after WAN drop. community.meraki.com
Hummingbird Networks — Hardening Meraki Auto VPN for High-Scale Performance (practitioner war-stories).
Cisco Security Advisory — CVE-2025-20271: Meraki MX & Z Series AnyConnect VPN DoS (CVSS 8.6, June 2025).
Cisco — Engineering Cisco Meraki Solutions (ECMS) 500-220 exam blueprint (Design/Implement/Operate/Troubleshoot).

What's next?

The MX isn't just a router — it's a full security appliance. Next we open the Layer-7 side: content filtering, the Cisco AMP malware engine, and the Snort-based IDS/IPS that inspects traffic inline.

Next · Meraki Layer-7 Security — Content Filtering, AMP & Snort IDS/IPS → Practice on exam.techclick.in

— Techclick Team

Cisco Meraki AutoVPN & SD-WAN — Tick One Box, Tunnels Build Themselves

By the end of this lesson you'll be able to

Pick where to start — jump straight to it

AutoVPN & the registry

Hub-spoke vs mesh

SD-WAN+ steering

Tunnel won't form

Why this matters — the chai-tapri version

Four words you'll hear in every Meraki VPN conversation

① AutoVPN & the registry — watch a tunnel form

▶ Watch AutoVPN form a tunnel

The actual config — three clicks

② Hub-and-spoke vs full-mesh — pick the right shape

③ SD-WAN+ — send the right traffic over the right link

▶ Watch a VoIP call get steered

Building a VoIP-steering policy

④ "Tunnel won't form" — the 4-step playbook

▶ Diagnose a stuck tunnel

🤖 Ask the AI Tutor

📝 Wrap-up — six more

✍️ In your own words

🗣 Teach a friend

📩 Quiz me later

📖 Glossary — the terms in this lesson

Quick reference — last-minute revision card

📚 Sources

What's next?