# Meraki is a cloud-dashboard session factory. Stamps, then Event log.

Source: https://ai.techclick.in/blog_meraki_session_factory
Markdown: https://ai.techclick.in/blog_meraki_session_factory.md
Publisher: Techclick Infosec Pvt Ltd

Meraki is a cloud-dashboard session factory: MX/MS/MR live in a network, Dashboard prints the recipe, Auto VPN / L3 firewall / wireless stamp the ticket, Event log proves it.

Quick answer

   Cisco Meraki is a  cloud-dashboard session factory . The organization holds networks. A network holds the  MX, MS and MR  you are about to edit. Dashboard stores a configuration container and pushes it to those devices over an out-of-band control plane. User packets never go through the cloud.  Auto VPN , the  MX Layer 3 / Layer 7 firewall , and  wireless Access control  are stamps on that ticket. Success is Event log rows on the right product type — 802.11 / 802.1X / DHCP for the AP, Meraki VPN for the spoke, Appliance status for the uplink — not a green Save.

   Say this out loud

   I name the organization and the network first. Then I name the device family. Association is not MX policy. One spoke down is not a Meraki outage. Event log is the proof. A green Save on the wrong network is a lie.

## 1. Why a green Save is not a session

 Night shift. Ticket: “Corp Wi-Fi at Pune cannot reach the HQ file server.” An engineer opens  dashboard.meraki.com , the last network in the top-left picker is still  HQ-Lab , and they flip a Layer 3 rule. Save turns green. The Pune user is still broken. Eighteen other networks in the lab org never moved.

 That is the Meraki classic miss, and it is the same class of miss as “the firewall rule is allow.” Officially an  organization  is a logical container for networks. A  network  is a logical container for a set of centrally managed devices. Combined networks group MX + MS + MR by physical site. The left-hand menu only shows the network you currently have selected. The factory cannot stamp a ticket it cannot see.

   Hero · out-of-band factory

   Notice: the dashed line is management. The solid line is the user session. Dashboard never carries the file-share packets.

#### What the ticket asked

 “Meraki is down.” That sentence is a hypothesis. The device may already have the last known config and be forwarding. Or you may have saved the recipe on the wrong network.

#### What you prove first

 Organization + network name, then device family (MR / MS / MX), then Event log on that product type. The  evidence desk  is the night-shift version of this order.

   The lie every L1 repeats

   “The Save succeeded, so Meraki applied it.” A green Save means Dashboard updated a configuration container. Official cloud architecture: that container is then pushed to the associated device. If you were in  HQ-Lab , Pune’s MX never received a new recipe. If the device is offline, it keeps the last known configuration until it can reach the cloud again.

 This lesson is the factory: how the session is built. The pair page is the  evidence desk  — first tool plus one official proof field, ticket by ticket. Practice both on the  Cisco Meraki hub simulator .

## 2. Mental model — floor, recipe, three stamps

 Hold four parts. Interviews fail when people mix them.

#### 1. The floor is the device

      MX  manufactures L3 / Auto VPN.  MS  manufactures the wired hop (port, RSTP, VLAN).  MR  manufactures association and 802.1X. Combined networks put all three in one site container.

#### 2. The recipe is Dashboard

     Official: management data flows device ↔ cloud over a secure tunnel. User data (web, file share, VoIP) does  not  flow through the Meraki cloud. Cloud loss ≠ user outage. Last known config stays.

#### 3. The stamps are three tables

      Wireless  = who got on the air and which VLAN.  MX Firewall  = who left the LAN or crossed VLANs.  Auto VPN  = who crossed the overlay. They are not one page.

#### 4. Proof is Event log

      Network-wide → Monitor → Event log  is the live history of the factory. Combined networks: pick the product type first. VPN Status and Appliance status are the MX-side Session Browser.

   Path · four stations

   Notice: four stations, four different Dashboard surfaces. One green Save on the wrong station does not move the packet.

   Flow 1 · one ticket, three stamps, out-of-band recipe

       Meraki factory: MX MS MR devices, Dashboard recipe, Auto VPN L3 wireless stamps, Event log proof

- Org Techclick-Lab · network BR-PUNE · combined MX + MS + MR MX · MS · MR factory floor Dashboard recipe / container Wireless MX L3 / L7 WAN / local internet Auto VPN hub or spoke Data plane (solid) is not the control plane (dashed) Client → MR (SSID + 802.1X) → MS VLAN / RSTP → MX outbound or Auto VPN → hub or local WAN Dashboard only pushes the recipe. Event log is where the factory writes what actually happened. Source: Meraki Cloud Architecture — out-of-band control plane. User data does not traverse the cloud. Read left → right. Do not start on Firewall if the client never associated. Do not start on Wireless if 802.1X already succeeded. Hard words, once Out-of-band control plane — management data to the cloud; user data stays on the LAN/WAN. Bridge mode (External DHCP server assigned) tags client frames and uses upstream DHCP. NAT mode (Meraki AP assigned) puts clients in a private 10.x pool behind the AP. Hub (Mesh) builds tunnels to every other hub. Spoke builds tunnels only to listed hubs. Default route on a spoke sends leftover traffic (0.0.0.0/0) to that hub. Warm spare is MX HA on Appliance status. Site-to-site outbound firewall is the Auto VPN ACL — not the MX outbound Layer 3 table. Official Auto VPN is an opt-in into the organization’s mesh. Every MX that sets Type to Hub or Spoke is choosing to participate. The cloud VPN registry tracks each appliance’s contact (public IP + UDP port), then the appliances form AES-encrypted IPsec-like tunnels to each other. You do not type Phase 1 proposals. You do name Type, exported local networks, and whether a spoke uses a Default route. ## 3. Which stamp? Decision flow Flowchart first. If you cannot answer the diamond, you are guessing in the menu. Flow 2 · right network, then which stamp Decision flow: organization and network, then association, then MX Layer 3 versus Auto VPN Org + network match user? NO YES Switch network Do not Save here Associated? 802.11 + 802.1X Wireless stamp Access control + VLAN HQ app only or local WAN? Auto VPN stamp VPN Status + S2S ACL MX Firewall L3 / L7 outbound Diamond = decision. Green = stay on that screen. Red = stop and switch. If the hop is a switch port (no Wi-Fi), Event log for switches + Switch ports, not Access control. If association failed, stay on Wireless. If association succeeded and the app is RFC1918 across Auto VPN, leave Wireless. Concept in one line Device family decides which Event log product type you open. Symptom decides which stamp you edit. Network picker decides whether that edit can even reach the device. ## 4. How to choose the stamp You are not choosing “Meraki.” You are choosing which table the factory is allowed to write on the ticket. Symptom Stamp / screen Official path Do not Cannot find the SSID or the change “did nothing” Org / network picker Top-left organization and network drop-downs Save in the last network you used yesterday Cannot associate, 802.1X fail, wrong VLAN on join Wireless stamp Wireless → Configure → Access control → Client IP and VLAN Edit MX outbound rules first Associated, DHCP OK, internet or inter-VLAN fails MX L3 / L7 stamp Security & SD-WAN → Configure → Firewall Rebuild the SSID or bounce every AP Only one branch loses HQ apps; hub local apps work Auto VPN stamp Security & SD-WAN → Monitor → VPN Status, then Configure → Site-to-site VPN on that spoke Rebuild the hub MX or warm spare Need to deny spoke-to-spoke or VPN subnets Site-to-site outbound firewall Security & SD-WAN → Configure → Site-to-site VPN → Organization-wide settings Assume MX outbound L3 covers Auto VPN — official docs say it does not Wired client, no Wi-Fi in the ticket MS port stamp Switching → Monitor → Switch ports, then Event log for switches Open Access control and blame Corp One client on Corp but should be guest Client + group policy / SSID VLAN Network-wide → Monitor → Clients, then group policy or SSID VLAN ID Quote only the SSID name Primary source for the MX table Cisco Meraki, MX Firewall Settings : outbound Layer 3 rules do not apply to Auto VPN traffic. Use Site-to-site VPN firewall settings for peer traffic. Layer 7 rules on the Firewall page still apply locally to traffic destined across Auto VPN. In hub-and-spoke with the hub as default route, spoke internet traffic is evaluated against the hub outbound Layer 3 table. Official rule evaluation is flow-based. Existing flows may continue until they time out or the MX is rebooted. New outbound Internet flows see the new table immediately. That is the Meraki cousin of a PAN-OS fast-path slot that ignores your fresh commit. Source: MX Firewall Settings, Considerations and Limitations. ## 5. Runbook Side A → B → C Lab values only. Organization Techclick-Lab , networks HQ-LAN (hub), BR-PUNE (spoke), leftover picker HQ-Lab . Client MAC aa:bb:cc:dd:ee:ff , DHCP 10.10.8.22 , Corp VLAN 20 , guest VLAN 40 , HQ file server 10.20.0.10 . Nothing here is a live tenant. ### Side A — organization, network, device family (the factory floor) Primary source: Meraki Dashboard Organizational Structure + Meraki Cloud Architecture + Combined Dashboard Networks. #### Read the top-left picker out loud Say the organization, then the network. Lab target is the user’s site ( BR-PUNE ), not leftover HQ-Lab or HQ-LAN . Official: a network is the container for the devices you are about to edit. Combined hardware networks hold MX + MS + MR for one physical site.

- #### Name the device family before you open a menu Wi-Fi association = MR. Wired port / RSTP / LLDP neighbor = MS. Internet, inter-VLAN, Auto VPN = MX. Opening Wireless for a docked laptop on a switch port is a factory miss.

- #### Check for a configuration template Bound networks inherit settings from Organization → Monitor → Configuration templates . A local Save can be overwritten or greyed. Official Auto VPN rule: all subnets advertised from a Routed-mode MX must be unique in the topology. Templates that clone the same 192.168.1.0/24 at every branch will not form a clean overlay.

     https://n123.meraki.com — Techclick-Lab · HQ-Lab

     Training mock · not live

       Organization drop-down  ›  Network drop-down (top left)

### Select network

          Organization  Techclick-Lab

          Network  HQ-Lab  ← leftover

        Ticket site  BR-PUNE · Combined hardware · MX-PUNE-A + MS stack + 6× MR

        Template  Branch-IN-Template (bound) — confirm before local Save

       The left nav is the current network’s menu. A green Save here never reaches MX-PUNE-A.

         Stay on HQ-Lab
         Switch to BR-PUNE

    Click next:  switch to the user’s network, then open Event log filtered by the client MAC. Source: Meraki Dashboard Organizational Structure + Combined Dashboard Networks.

### Side B — print the stamps (wireless, MX L3, Auto VPN)

 Primary source: Access Control + SSID Modes for Client IP Assignment + MX Firewall Settings + Site-to-site VPN Settings.

     https://n123.meraki.com — BR-PUNE · Wireless · Access control

     Training mock · not live

       Wireless  ›  Configure  ›  Access control  ›  Client IP and VLAN

### SSID Corp

         SSID  Access control  Firewall

          Security  Enterprise with 802.1X

          Splash page  None

          Client IP and VLAN  External DHCP server assigned

          VLAN ID (Default)  20

        Mode  Bridge — AP does not NAT. Frames tagged 802.1Q VLAN 20.

       NAT mode / Meraki AP assigned isolates clients in 10.0.0.0/8 behind the AP. Official: not the design for an HQ file share.

         Cancel
         Save changes

    Click next:  if 802.11 / 802.1X / DHCP already succeeded on Event log, leave this page. Source:  SSID Modes for Client IP Assignment  and  Access Control .

- #### Open the correct SSID only if association is the question Wireless → Configure → Access control . Select Corp from the SSID menu. Security in the lab is Enterprise with 802.1X, splash None. Prefer External DHCP server assigned (Bridge) and VLAN ID 20 for enterprise. NAT mode / Meraki AP assigned is the guest pattern — clients cannot be initiated to from the LAN, and VLAN tagging is not supported.

- #### Do not confuse SSID firewall with MX firewall Wireless → Configure → Firewall and traffic shaping is the SSID Layer 3 / Layer 7 table. MX outbound is Security & SD-WAN → Configure → Firewall . A wireless allow does not punch an MX deny to RFC1918.

- #### Read MX outbound rules on the network that owns the MX Fields from the official page: Policy, Rule description, Protocol, Source, Destination, Src port, Dst port. Lab dummy: allow TCP 443 VLAN20 → Any; deny Any VLAN20 → RFC1918; default allow internet. Source IPs must match subnets on Addressing & VLANs . Outbound is allow-by-default unless you add a default deny.

- #### If the destination is across Auto VPN, change screen Official: Layer 3 rules on the Firewall page do not apply to Auto VPN or non-Meraki VPN. Open Security & SD-WAN → Configure → Site-to-site VPN . Set Type = Spoke , add the hub, mark Default route only if leftover traffic should go to HQ. Then Organization-wide Site-to-site outbound firewall for peer ACLs. Those rules apply to every MX in the org that participates in site-to-site VPN.

- #### Name the spoke before you touch the hub Security & SD-WAN → Monitor → VPN Status (or Organization → Monitor → VPN Status for the whole mesh). Lab: 17 peers, 16 healthy, BR-PUNE down. Do not rebuild HQ-LAN or the warm spare for one spoke.

  Dummy lab · same shape as the hub simulator (not live)
 MERAKI-LAB > show network BR-PUNE
org=Techclick-Lab type=combined template=Branch-IN-Template
mx=MX-PUNE-A ms=1-stack mr=6

MERAKI-LAB > show firewall l3
allow TCP 443 VLAN20 -> Any
deny  Any VLAN20 -> RFC1918
default=allow internet
note=L3 outbound does not apply to Auto VPN

MERAKI-LAB > show vpn status
type=Spoke hub=HQ-LAN default-route=yes
registry=connected peers=17 healthy=16 down=1 (BR-PUNE)
exported=10.10.8.0/24
last-change=09:05Z

### Side C — prove the ticket in Event log

 Primary source: How to Use the Meraki Event Log + VPN Status Page + Clients List and Details Page Overview.

- #### Open Event log on the network you just named Network-wide → Monitor → Event log . Combined networks: use the drop-down next to Event log and pick the product type — for access points , for security appliances , or for switches . The empty table is usually the wrong product type or the wrong network, not “Meraki is down.”

- #### Filter the client, not the whole building Client field: MAC, hostname, or custom name. Lab filter aa:bb:cc:dd:ee:ff . Official: only events affecting that client are displayed. Event log uses the network time zone.

- #### Read the stamps that actually fired MR: 802.11 association, 802.1X / WPA, DHCP . MX: Meraki VPN , Appliance status (primary uplink), DHCP , VRRP (warm spare). MS: 802.1X , Spanning Tree , Switch port . Copy AP name + RSSI, VLAN, and the VPN peer name onto the ticket.

- #### If 802.1X succeeded and the app is still dead, leave Wireless That is MX Firewall, VPN Status, or Appliance status (Active vs Ready on the uplink). The evidence desk names the first tool per ticket. This page only demands that you stop editing Access control.

     https://n123.meraki.com — BR-PUNE · Network-wide · Event log
     Training mock · not live

       Network-wide  ›  Monitor  ›  Event log  ›  for access points

### Event log

         Client: aa:bb:cc:dd:ee:ff · Type: 802.11, 802.1X, DHCP

         Search

               Time
               Type
               Client
               Device
               Event

               09:06:12
                802.11
               aa:bb:cc:dd:ee:ff
               AP-3F-02
               association · rssi=-62 · ssid=Corp

               09:06:13
                802.1X
               aa:bb:cc:dd:ee:ff
               AP-3F-02
               authentication success

               09:06:14
                DHCP
               aa:bb:cc:dd:ee:ff
               AP-3F-02
               ack 10.10.8.22 · vlan=20

               09:06:40
                802.11
               aa:bb:cc:dd:ee:ff
               AP-3F-02
               still associated — app fail is not here

       Three green wireless rows end the Wi-Fi debate. Next click: Security & SD-WAN → Firewall or VPN Status — not another SSID Save.

    Click next:  if those three rows exist, leave Wireless. Open VPN Status and name the spoke. Source: How to Use the Meraki Event Log — filter by client MAC; combined networks pick the product type first.

   Proof · Event log cockpit

   Notice: juniors stare at Save. Seniors stare at Event log product type, then VPN Status peer name.

   Green success on this runbook

   Picker =  Techclick-Lab  /  BR-PUNE . Event log  for access points  shows association + 802.1X success + DHCP ACK on VLAN 20. Client details: ssid=Corp, vlan=20, policy=normal. If the app is HQ RFC1918: VPN Status peer  BR-PUNE  is up, exported subnet listed, Site-to-site outbound firewall is not denying the pair. If the app is internet: MX outbound L3 on the  hub  (Default route) allows it, uplink on Appliance status is  Active  not merely Ready. The same user click then works. That is working. A green Save on  HQ-Lab  is not.

## 6. Runtime — last known config, old flows, templates

 Once the recipe is on the device, later packets do not walk back to Dashboard. Official cloud architecture: if cloud connectivity is lost (usually a local ISP), the hardware continues with its last known configuration. User data never needed the cloud in the first place. “Dashboard is slow” is not “Pune cannot print.” Prove the data plane on Event log and VPN Status before you blame the control plane.

 Official MX Layer 3 is flow-based. Existing flows may continue until they time out or the MX reboots. A new deny you just saved can look like “it did nothing” because the old flow is still alive. That is the Meraki cousin of a PAN-OS fast-path slot. Re-test with a  new  client flow, or wait for timeout, before you add a second deny.

 Hub-and-spoke with Default route is a second-factory problem. The spoke sends leftover traffic to the hub. Official MX Firewall Settings: that spoke internet is then evaluated against the  hub  outbound Layer 3 table. Editing the spoke Firewall page will not move a full-tunnel user. Edit the hub, or stop advertising 0.0.0.0/0 from that hub.

 Layer 7 on the Firewall page is the exception students invert. Official Site-to-site VPN Firewall Rule Behavior: VPN traffic is never subject to the global Layer 3 table, but Layer 7 rules configured on Security & SD-WAN → Configure → Firewall still apply locally to client traffic destined across Auto VPN and IPsec peers. Quote the table you edited.

 Templates are a delayed stamp. Changes to  Organization → Monitor → Configuration templates  push to every bound network. A “local” SSID tweak that vanishes on the next sync was never local. Unique Routed-mode subnets remain mandatory for Auto VPN — two bound branches advertising 10.0.0.0/24 will collide even if the SSIDs look identical.

 Warm spare is two copies of the MX factory. Configure it on  Security & SD-WAN → Monitor → Appliance status → Configure warm spare . VRRP events land in Event log  for security appliances . Green spare state means the pair can fail over. It does not mean the Pune spoke recovered. Replay the same file-share click.

 Uplink language: Appliance status shows  Active  versus  Ready . Ready is a healthy spare path, not the path carrying traffic. Failback delay and uplink preference can leave users on WAN2/LTE after WAN1 returns. Quote Active, not “the circuit is up.”

   Flow 3 · runtime stations after go-live

       Runtime path: associate, VLAN, MX or Auto VPN, then Event log proof

- 1 Associate 802.11 + RSSI 2 802.1X success / fail 3 DHCP + VLAN vlan=20 lab 4 MX / VPN L3 or spoke 5 Event log product type Green Event log: association AP-3F-02 rssi=-62 · 802.1X success · dhcp ack 10.10.8.22 vlan=20 If those three lines exist, stop debating Wi-Fi. Open Firewall or VPN Status. Cloud outage does not unwind steps 1–4. Last known recipe stays on the device. Proof fields: AP name, RSSI, 802.1X result, DHCP ACK, VLAN, SSID, MX rule intent, Auto VPN peer name, uplink Active vs Ready. ## 7. Traps + Event log proof Symptom Looks like Actually First move Save succeeded, user unchanged Meraki ignored the change Wrong network, or a template overwrote it Read org + network. Switch. Then edit. Wi-Fi bars, file share dead Need a new SSID / PSK 802.1X already succeeded; MX or spoke dropped it Event log for access points, then Firewall / VPN Status Only Pune loses HQ apps Rebuild the hub MX / warm spare One Auto VPN spoke is down VPN Status → name BR-PUNE → spoke uplink / Type MX deny to RFC1918 “does nothing” Layer 3 is broken Destination is Auto VPN; outbound L3 does not apply Site-to-site outbound firewall (org-wide) Full-tunnel branch still hits a deny Spoke Firewall page Hub outbound L3 evaluates Default-route traffic Edit the hub table, or drop Default route New deny, old session still flows Save failed Flow-based L3 — old flow until timeout / reboot New client flow, then re-read Event log “They are on Corp” but guest portal SSID name is enough VLAN or group policy override Client details: SSID + VLAN + group policy NAT mode, cannot reach file server MX rule missing Clients sit in 10.x behind the AP; no L2 to the LAN Bridge + VLAN ID; DHCP on MX VLAN or upstream Dashboard unreachable, users still browse Split-brain / outage Out-of-band control plane; last known config Do not reboot the MX “to restore the cloud” Empty Event log Logging is broken Wrong network, or wrong product-type drop-down Switch network, then pick for access points / appliances / switches Proof checklist — Pune Corp can actually reach the file share Organization and network spoken and written on the ticket ( Techclick-Lab / BR-PUNE ).

- Network-wide → Monitor → Event log → for access points → client MAC: 802.11 association, 802.1X success, DHCP ACK, AP name, RSSI.

- Client details: SSID Corp , VLAN 20 , group policy normal , IP 10.10.8.22 .

- If the hop is wired: Event log for switches + Switch ports (RSTP, LLDP neighbor) — not Access control.

- If the app is internet: MX outbound L3/L7 on the appliance that actually evaluates the flow (spoke, or the hub if Default route) + uplink Active .

- If the app is HQ RFC1918: VPN Status peer name up, exported subnet listed, Site-to-site outbound firewall not denying the pair.

- Same user click then works. Dummy lab values only — no live tenant IDs.

   Interview close you can steal

   Meraki is a cloud-dashboard session factory. MX, MS and MR live in a network. Dashboard prints an out-of-band recipe — user packets never go through the cloud. Auto VPN, Layer 3 firewall and wireless are three stamps, not one page. I prove the ticket in Event log on the right product type, then VPN Status or Appliance status. A green Save on the wrong network is not success.

 Related:  Meraki evidence desk  — first tool + one official field per ticket. Factory model stays on this page.

## Knowledge check

   Six judgment questions. Map each miss back to the section named in the reason.

       Q1
       Dashboard is unreachable from your laptop. Pune users are still browsing SaaS. Best explanation?

           User traffic hairpins through a backup Dashboard region until the primary returns
           Out-of-band control plane — user data never traversed the cloud; the MX/MS/MR keep the last known recipe
           Auto VPN fails closed, so all traffic is forced to local breakout
           Event log caches packets and replays them without the devices

       Correct:  b . Official Meraki Cloud Architecture: management data goes to the cloud; user data does not. Hardware continues on last known configuration during cloud-connectivity loss. Re-read Why a green Save is not a session and Runtime.

       Q2
       A Pune user says “Meraki is down.” Your Dashboard picker still shows HQ-Lab. What is the first action?

           Confirm the organization and switch to the user’s branch network before any Save
           Rebuild the Corp SSID in HQ-Lab so the Save is fast
           Disable Auto VPN on the hub so traffic goes local
           Factory-reset the nearest MR

       Correct:  a . Wrong network is the classic miss. The left nav is the current network’s factory. Re-read Side A and the mental model.

       Q3
       Event log  for access points  shows 802.11 association, 802.1X success, and DHCP ACK on VLAN 20. File server 10.20.0.10 is unreachable. What do you open next?

           Recreate the SSID with a new PSK
           Air Marshal and a channel walk
           Leave Wireless — MX Firewall and/or VPN Status, because the wireless stamp already succeeded
           Switch Corp to NAT mode so the AP can route RFC1918

       Correct:  c . Successful 802.1X ends the Wi-Fi debate. Re-read the decision flow, Side C, and How to choose the stamp.

       Q4
       You add an MX outbound deny Any VLAN20 → RFC1918. Site-to-site Auto VPN traffic to HQ still flows. Why?

           Meraki has no Layer 3 firewall
           You must reboot every AP for L3 rules to attach
           Auto VPN ignores every policy by design
           Outbound L3 on Security & SD-WAN → Firewall does not apply to Auto VPN; use the Site-to-site outbound firewall

       Correct:  d . Official MX Firewall Settings + Site-to-site VPN Firewall Rule Behavior. Layer 7 on the Firewall page still applies locally. Re-read How to choose and Side B.

       Q5
       What is the Session Browser analog on a Meraki combined network?

           The green Save toast on any Configure page
           Network-wide → Monitor → Event log on the right product type, then VPN Status or Appliance status if the hop left the AP
           Organization → Inventory serial list
           Wireless → Configure → SSIDs, because the SSID name is the session

       Correct:  b . Event log is the factory’s written ticket. Combined networks require the product-type drop-down first. Re-read Side C and the proof checklist.

       Q6
       Corp is set to External DHCP server assigned / Bridge mode, VLAN ID 20. What does that mean?

           The AP NATs clients into 10.0.0.0/8 and VLAN tagging is supported
           Clients cannot use 802.1X on that SSID
           Clients get DHCP from upstream and frames are 802.1Q tagged VLAN 20 — the enterprise pattern for an HQ file share
           The Site-to-site VPN page is unused on that network

       Correct:  c . Official SSID Modes for Client IP Assignment. NAT mode is the guest / isolation pattern and does not support VLAN tagging. Re-read Side B and hard words.

       Check answers
       Reset

## Sources

- Cisco Meraki — Meraki Cloud Architecture — organization / network containers; out-of-band control plane; last known configuration; user data does not traverse the cloud

- Cisco Meraki — Meraki Dashboard Organizational Structure — account, organization, network; Combined type

- Cisco Meraki — Combined Dashboard Networks — one Event log page; filter by device type

- Cisco Meraki — MX Firewall Settings — Security & SD-WAN → Configure → Firewall; outbound L3 fields; L3 does not apply to Auto VPN; hub evaluates Default-route spoke internet; flow-based rules

- Cisco Meraki — Site-to-site VPN Firewall Rule Behavior — org-wide Site-to-site outbound firewall; L7 on Firewall still applies to VPN-destined client traffic

- Cisco Meraki — Meraki Auto VPN Configuration Settings — Type Off / Hub (Mesh) / Spoke; Default route; local networks; VPN registry; monitor on VPN Status

- Cisco Meraki — Configuring Hub-and-spoke VPN Connections

- Cisco Meraki — VPN Status Page — Organization → Monitor → VPN Status and Security & SD-WAN → Monitor → VPN Status

- Cisco Meraki — Access Control — Wireless → Configure → Access control; Client IP and VLAN

- Cisco Meraki — SSID Modes for Client IP Assignment — Bridge vs NAT (10.0.0.0/8); VLAN tagging not supported in NAT mode

- Cisco Meraki — VLAN Tagging on MR Access Points

- Cisco Meraki — How to Use the Meraki Event Log — Network-wide → Monitor → Event log; product-type filter; client MAC / hostname; 802.11, 802.1X, DHCP, Meraki VPN, VRRP, Spanning Tree

- Cisco Meraki — Clients List and Details Page Overview

- Cisco Meraki — Managing Multiple Networks with Configuration Templates

- Cisco Meraki — MX Warm Spare — Appliance status → Configure warm spare

 Related:  Meraki evidence desk  ·  Cisco Meraki interview hub  ·  Dummy lab  ·  Auto VPN / SD-WAN deep dive  ·  SSID security  ·  MS switching  ·  All lessons

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt