Before any SSID — the one idea that confuses everyone
A wireless client joins a Meraki SSID in two distinct steps, and mixing them up is the root of 80% of "Wi-Fi is broken" tickets. Step one is Layer-2 association: Open, WPA2-PSK, WPA3-SAE, OWE or iPSK — this happens on the radio before the client has any IP. Step two is the optional splash page, a Layer-3 gate the client only hits after it already holds an IP.
One sentence to memorise: "Encryption is Layer 2, the splash page is Layer 3." Get an IP but no internet? That's a Layer-3 / splash problem. Can't even join the SSID? That's a Layer-2 / security problem. This single distinction is a top-asked ECMS 500-220 concept.
ELI5: Joining Wi-Fi is like getting into a building. The door lock (WPA2/WPA3 password) is Layer 2 — you need the right key to even open the door. The reception desk sign-in sheet (splash page) is Layer 3 — you're already inside the lobby, but you can't go anywhere until you sign in.
Practitioner: All of this lives in Wireless > Configure > Access Control, per-SSID. The Security radio buttons choose Layer-2 auth (Open, WPA2/3, iPSK, Enterprise). The Splash page dropdown chooses the Layer-3 captive portal. They are independent — you can run WPA3 and a splash page on the same SSID.
Architect: Separate the planes when you design. Layer-2 (SAE/PSK/802.1X) protects the air and gives encryption + key management. Layer-3 (splash / captive portal) is for acceptable-use, billing, identity capture or guest onboarding — never treat it as encryption. A click-through splash on an Open SSID leaves the air fully unencrypted.
Simultaneous Authentication of Equals replaces the WPA2 4-way handshake. Offline dictionary attacks no longer work — but SAE allows only ONE passphrase per SSID.
Identity PSK — many pre-shared keys on one SSID. Each device gets its own key, mapped to a group policy. Needs WPA2 (SAE can't do multi-PSK).
Protected Management Frames stop deauth / disassoc spoofing. WPA3 needs it Required; transition mode uses Enabled; WPA2-only can be Disabled.
A Layer-3 captive portal. Click-through = just accept terms; sign-on = real login. No encryption — it's only an acceptance / identity gate.
Predict first: if you put a click-through splash page on an Open SSID, is the over-the-air traffic encrypted?
① WPA3 & Transition Mode — stronger lock, one sharp edge
WPA3-Personal swaps the crackable WPA2 4-way handshake for SAE. The catch: most fleets still have a few WPA2-only devices. Meraki's answer is WPA3 Transition Mode, where one SSID advertises both WPA2-PSK and WPA3-SAE so old and new clients share the network.
▶ Watch a client associate to a WPA3-transition SSID
Click Play. Each stage lights up as the client moves through Layer-2 association.
Symptom you see: the audit ticks "WPA3 enabled" but a red-team still cracks the passphrase. Cause: transition mode keeps WPA2-PSK live in the same beacon, so an attacker joins via the weak path and the offline handshake attack still works. Transition mode is a migration stepping-stone, not a destination. Once every client supports SAE, disable transition mode so only WPA3-SAE is advertised.
On a Meraki MR network you enable WPA3 in Transition Mode so old WPA2 laptops keep working. A pen-tester reports the SSID is still crackable. Why?
② Identity PSK (iPSK) & Wi-Fi Personal Network
Standard WPA2-PSK gives everyone the same password — change one device, you re-key the whole fleet. Identity PSK (iPSK) fixes this: many pre-shared keys on ONE SSID. Each printer, camera or IoT sensor gets its own passphrase, mapped to a group policy with its own VLAN and firewall rules.
Meraki offers iPSK without RADIUS (keys stored in the Dashboard, paired with WPN) and iPSK with RADIUS (keys returned by a RADIUS server as the Airespace-PSK attribute). On the Access Control page you select Identity PSK without RADIUS, then Add an Identity PSK — name, passphrase, group policy.
Security: Identity PSK without RADIUS WPA encryption: WPA2 only # SAE can't do multi-PSK yet 802.11w (PMF): Enabled Add Identity PSK Name: Flat-204-IoT Passphrase: aZ7q-Kel2-9rPv Group: VLAN-204-Isolated (WPN enabled)
Identity PSK 'Flat-204-IoT' created. → 1 key · Group policy VLAN-204-Isolated → WPN: clients on this key see only their own devices → SSID remains a single broadcast: 'Apartments-WiFi'
Predict: you tick WPA3 only on an iPSK SSID and devices report "wrong password" even though the key is correct. What broke?
Without RADIUS — keys live in the Dashboard, simplest to run, pairs with WPN for isolation. Best for IoT, dorms, apartment Wi-Fi. With RADIUS — keys are returned by your RADIUS server (Airespace-PSK attribute) keyed on the client MAC, so you centralise key management and logging. Use it when you already run RADIUS / ISE and want one source of truth. Either way the SSID stays a single broadcast.
You configured Identity PSK (iPSK) without RADIUS on a Meraki SSID and ticked WPA3 only. Devices fail to join with a wrong-password error even though the passphrase is right. Why?
Identity PSK without RADIUS is paired with Wi-Fi Personal Network (WPN). What does WPN add on top of plain iPSK?
③ Splash Pages — the Layer-3 captive portal
A splash page is the web page a client must view before it can route traffic. Two common flavours: Click-through (just accept terms) and Sign-on (real credentials, Meraki-hosted or external). Remember Figure 1: the client already has an IP at this point. Before sign-on, only DHCP, DNS and walled-garden hosts are reachable; everything else is blocked.
http:// site to trigger the page.
▶ Splash-page redirect — watch the Layer-3 flow
A guest joins an Open SSID with a Click-through splash. Follow why the page does (or doesn't) appear.
http://example.com → AP intercepts the plaintext request
If your splash uses an external portal (or loads logos / scripts from a CDN), add every one of those domains and IPs to the walled garden — otherwise the AP blocks them and the page never finishes loading. Set Captive portal strength = "Block all access until sign-on is complete" so clients can't sneak traffic through before accepting. Tell users to keep browser cookies enabled, or the splash reappears far more often than the timeout.
A guest connects to a Meraki SSID with a Click-through splash page. The phone joins Wi-Fi but the splash page never appears, and the user has no internet. What is the most likely cause?
④ Troubleshoot — "SSID not working" playbook
SSID misbehaving? Start with the symptom, not the config. This symptom-first ladder runs in under a minute.
Layer-2 problem. Check PMF (Required drops legacy gear), wrong passphrase, or iPSK-on-WPA3. Dashboard → Network-wide > Clients shows the failed association reason.
Layer-3 / splash problem. Splash not accepted, HTTPS-first redirect miss, or a missing walled-garden entry. The client is authorized only after sign-on.
Re-prompts every few minutes. Cause: cookies blocked, or MAC randomization presents a new MAC each reconnect → looks like a new device. Allow cookies; account for random MAC.
Use Wireless > Monitor > Connection log for per-stage failures (Assoc / Auth / DHCP / DNS), and the per-client Ping / Throughput live tools to isolate L2 vs L3.
▶ Read the connection log like an L2 engineer
Sneha's laptop won't get online. Step through the Meraki connection-log stages to find where it dies.
www.example.com via 10.10.0.53 — DNS works
http://neverssl.com to trigger the portal, or check walled garden / captive-portal strength.
Symptom you see: right after you tighten an SSID, a group of barcode scanners or IoT sensors silently drop off Wi-Fi and won't rejoin. Cause: you set 802.11w (PMF) to Required, and those legacy devices don't support management-frame protection, so they can no longer associate. Set PMF to Enabled (capable / optional) so PMF-aware clients still use it while legacy gear connects — or move the old devices to their own WPA2 SSID.
Predict: users say the guest splash re-appears every few minutes on their phones. Before reading on — what's the usual culprit?
Open Wireless > Monitor > Connection log and confirm the client shows green at Assoc, Auth, DHCP and DNS. If all four are green but status is "Pending", it's a splash/Layer-3 issue — never a passphrase change. Then run the per-client Ping tool from the Dashboard to prove routing opens after sign-on.
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from Cisco Meraki docs + community Q&A. For complex prod issues, paste your connection-log export + SSID Access-Control screenshot into chat.techclick.in.
📝 Wrap-up — six more
You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 Make it stick — explain it back
Self-explanation: in one or two lines, write why a splash page can't protect corporate data the way WPA3 can. Typing it in your own words is what moves it to long-term memory.
Teach a friend: message one teammate the single sentence — "Encryption is Layer 2, the splash page is Layer 3." If they get it in 20 seconds, you've understood it too.
Spaced recall: want a 3-question refresher emailed in 3 days? Drop your email — no spam, just this lesson's recall set.
📖 Glossary
- SAE (Simultaneous Authentication of Equals)
- The WPA3 handshake that replaces the WPA2 4-way handshake and resists offline password-guessing. Supports one passphrase per SSID.
- iPSK (Identity PSK)
- Many pre-shared keys on one SSID, each mapped to a group policy. Runs on WPA2; "without RADIUS" stores keys in the Dashboard.
- WPN (Wi-Fi Personal Network)
- Per-key Layer-2 isolation layered on iPSK so devices on different keys can't see each other on the same SSID.
- 802.11w / PMF
- Protected Management Frames — stops deauth/disassoc spoofing. Required for WPA3, Enabled for transition, optional for WPA2.
- Splash page / Captive portal
- A Layer-3 web gate. Click-through = accept terms; sign-on = real login. Performs no encryption.
- Walled garden
- The allow-list of hosts a client can reach before sign-on (portal, CDN, payment provider).
📚 Sources
- Cisco Meraki Documentation — WPA3 Encryption and Configuration Guide. documentation.meraki.com
- Cisco Meraki Documentation — 802.11w Management Frame Protection (MFP) & Access Control. documentation.meraki.com
- Cisco Meraki Documentation — Wi-Fi Personal Network (WPN) & IPSK with RADIUS Authentication. documentation.meraki.com
- Cisco Meraki Documentation — Splash Page Overview, Traffic Flow & Troubleshooting. documentation.meraki.com
- The Meraki Community — "Customer having problems with splash page not showing" & "Splash page not showing automatically". community.meraki.com
- TrustedSec — The Dangers of Transition Mode; The Networking Nerds — The iPSK Challenge (WPA3 / 6 GHz / Wi-Fi 7).
- Cisco — 500-220 ECMS Exam Topics (Design 15% / Implement 30% / Operate 25% / Troubleshoot 30%); Cisco Security Advisory CVE-2025-20212 (Meraki MX AnyConnect VPN).
What's next?
You've locked down the air with WPA3, iPSK and splash pages. Next we move from "what key" to "who are you" — 802.1X with RADIUS / ISE, and how Meraki Adaptive Policy carries Security Group Tags (SGT) for identity-based segmentation.