Summary Compares Meraki MR authentication using WPA2-Enterprise with a RADIUS server against sign-on splash page authentication, with traffic flow diagrams for 802.1X and for every splash mode, covering where each operates in the stack, the encryption consequences, and the failure modes specific to each.
Both methods ask a user for credentials, and to an end user they can look similar. Architecturally they are not comparable.
RADIUS with 802.1X is a Layer 2 authentication that happens before the client is admitted to the network. The client cannot send a single frame of user traffic — cannot even request a DHCP address — until authentication succeeds.
A sign-on splash page is a Layer 3 web authentication that happens after the client is already on the network. The client associates, obtains an IP address, and is then held in a captive portal until it authenticates through a browser.
Everything else that differs between the two follows from that single distinction.
⚠️ You Cannot Use Both on One SSID: A sign-on splash page is incompatible with MAC-based and with any Enterprise association requirement. To use one, the SSID association must be Open or Pre-shared Key. This is a hard constraint in the dashboard, not a recommendation, and it is the reason the encryption section below matters so much — choosing a sign-on splash page means giving up 802.1X on that SSID. The single exception is Cisco ISE authentication, which works the other way round and requires MAC-based access control or Enterprise with my RADIUS server.
802.1X defines three roles:
Client Meraki AP RADIUS Server
(supplicant) (authenticator) (NPS / ISE)
| | |
|------ Association ------>| |
|<----- Assoc Response ----| Client port blocked: |
| | EAPOL frames only |
| | |
|===== EAPOL-Start =======>| |
| |--- Access-Request ------->| UDP 1812
|<==== EAP-Req/Identity ===|<-- Access-Challenge ------|
|===== EAP-Resp/Identity =>|--- Access-Request ------->| shared
| | | secret
|<======== EAP method exchange (PEAP / EAP-TLS) ======>| signs each
| inner credentials inside the EAP tunnel | exchange
| | |
| |<-- Access-Accept ---------|
| | + keying material |
| | + Tunnel-Private-... |
| | + Filter-Id |
|<===== EAP-Success =======| |
| | |
|<==== 4-way handshake ===>| Per-session keys derived |
| | Client port unblocked |
| | |
|------ DHCP DISCOVER ---->| Only now does the client |
|<----- DHCP OFFER --------| obtain an IP address |
The ordering is the point. No user traffic — not even DHCP — crosses the AP until the RADIUS server has returned an Access-Accept.
Native RADIUS is authenticated between the AP and the server by a shared secret. It is a string configured identically in two places, and both must match exactly:
| Where | What to configure |
|---|---|
| Meraki dashboard | Wireless > Configure > Access control > RADIUS servers — host, port (1812 by default), and secret |
| RADIUS server | Each AP added as a RADIUS client by its LAN IP, with the same secret |
⚠️ Every Access Point Must Be a RADIUS Client: Each MR sends RADIUS from its own LAN IP, so every gateway AP broadcasting the SSID must exist as a client entry on the RADIUS server. Adding an AP to a site without adding it to the server produces a failure that looks intermittent — users authenticate normally until they roam onto the new AP, then fail — and it will not reproduce for anyone testing elsewhere in the building.
Where the APs sit on a dedicated management VLAN, an entire subnet can be registered as a RADIUS client instead of enumerating each AP. This is only advisable when the subnet contains nothing but APs, since any host in that range is then trusted to submit RADIUS requests with that secret.
The secret is frequently assumed to encrypt RADIUS traffic. It does not. Under RFC 2865 it is used to authenticate the client to the server, to sign the Authenticator field so responses can be validated, and to obscure the User-Password attribute. Everything else travels in cleartext, including the username and the attributes returned on the Access-Accept — VLAN IDs and Filter-Id values among them.
For 802.1X the practical exposure is limited, because the user's credentials are carried inside the EAP method's own TLS tunnel rather than in User-Password. The secret's password-obscuring role matters far more for MAC-based authentication and for splash-page RADIUS, where PAP may be in use. In every case the returned authorisation attributes are readable on the wire, so RADIUS should stay on a trusted management path.
A mismatched secret typically appears as silent drops or rejects rather than a clear error. The dashboard event log shows the request timing out; the server logs a signature or shared-secret validation failure. Because the symptom is indistinguishable from a firewall or reachability problem, confirm the secret before investigating the network path.
RadSec carries RADIUS inside a TLS tunnel over TCP 2083, using mutual certificate authentication between the AP and the server. It removes the cleartext exposure described above without changing the client-side authentication process at all. Support was introduced in MR firmware 30.X.
One detail catches people out: a secret must still be supplied in the RADIUS server configuration even when RadSec is enabled, despite the certificates doing the actual authentication.
The RADIUS response can carry authorisation as well as authentication:
| Purpose | Attributes |
|---|---|
| Per-user VLAN assignment | Tunnel-Private-Group-ID (the VLAN ID), Tunnel-Type (VLAN), Tunnel-Medium-Type (IEEE-802) |
| Group policy assignment | Filter-Id, Reply-Message, Airespace-ACL-Name or Aruba-User-Role, naming a dashboard group policy |
For a returned VLAN to take effect, RADIUS override must be enabled under the SSID's VLAN setup — set to "RADIUS response can override VLAN tag". Without this the attributes are received and ignored, which is a common cause of users landing in the SSID's default VLAN despite a correct RADIUS configuration.
If a group policy returned by Filter-Id itself contains a VLAN ID, that VLAN is applied to the user.
The dashboard offers a range of splash options under Wireless > Configure > Access control. They differ in who validates the credential, not in how the client is intercepted.
| Mode | Credential validated by | Association requirement |
|---|---|---|
| None (direct access) | Nothing — no portal | Any |
| Click-through | Nothing — acknowledgement only | Open or PSK |
| Sponsored guest login | Cloud, plus a sponsor's email approval | Open or PSK |
| Sign-on with Meraki authentication | Meraki cloud user database | Open or PSK |
| Sign-on with my RADIUS server | Meraki cloud, via RADIUS to your server | Open or PSK |
| Sign-on with my LDAP server | The access point, via LDAP bind | Open or PSK |
| Sign-on with Active Directory | The access point, via LDAP bind to a Global Catalog | Open or PSK |
| Sign-on with Google Sign-In | Google, via OAuth | Open or PSK |
| Sign-on with SMS authentication | Cloud, with a code delivered via Twilio | Open or PSK |
| Systems Manager Sentry enrolment | Enrolment state in an SM network | Open or PSK |
| Billing (paid access) | Payment provider | Open only |
| Cisco ISE authentication | ISE, via central web authentication | MAC-based or Enterprise |
MX appliances support a much smaller subset — None, Click-through, and Sign-on with my RADIUS server or a third-party credential. Splash settings on an MX are configured per VLAN.
Every splash mode begins identically. The client is already associated and holds an IP address; what follows is the redirect that puts the splash page in front of it.
Client Meraki AP Meraki Cloud
network-auth.com
| | |
|------ Association ------>| Open or PSK SSID |
|<----- Assoc Response ----| |
|------ DHCP DISCOVER ---->| |
|<----- DHCP OFFER --------| Client now HAS an IP |
| | Captive portal applied |
| | |
|--- HTTP GET example.com->| Intercepted by the AP |
|<-- TCP SYN-ACK ----------| AP answers on behalf of |
| | the site (its own MAC) |
|<-- HTTP 307 Redirect ----| to the splash URL |
| | |
|------ GET splash URL ---------------------------> |
|<----- 200 OK + splash page + p_splash_session --- |
From this point the flow diverges by mode. The sections below pick up where this one ends.
No credential is collected. Acknowledging the page is the authentication.
Client Meraki AP Meraki Cloud
| | |
| [ common interception above; splash page shown ] |
| | |
| [ user clicks Continue ] |
|------ GET grant URL + continue_url + cookie -----> |
| | |
| |<-- notify all APs --------|
| | Captive portal lifted |
| | |
|<----- 302 to grant_user_access ------------------ |
|------ GET grant_user_access --------------------> |
|<----- 302 to continue_url ----------------------- |
| | |
|------ traffic now flows normally ------------------->|
This covers Meraki authentication and sign-on with your own RADIUS server. In both cases the credentials are posted to the cloud, and the cloud performs the validation. The only difference is what the cloud checks against.
Client Meraki AP Meraki Cloud RADIUS Server
| | | (if configured)
| [ common interception; sign-on form shown ] |
| | | |
|--- POST credentials + cookie --> | |
| | | |
| | Meraki auth: check cloud |
| | user database |
| | | |
| | RADIUS: |--- Access-Req ->|
| | |<-- Accept ------|
| | | |
| |<-- notify APs -| |
| | Portal lifted | |
|<-- 302 to grant_user_access ---- | |
|<-- 302 to continue_url --------- | |
Because the cloud originates the RADIUS request in this mode, the RADIUS server must accept requests from Meraki's cloud addresses rather than from the AP LAN IPs. That is the opposite of the 802.1X case earlier in this note, and it is a frequent source of confusion when the same RADIUS server serves both.
Sponsored guest, SMS and Google Sign-In are variations on this shape. The form collects something different and the cloud validates it against a different source — a sponsor's email approval, a Twilio-delivered code, or a Google OAuth exchange — but the interception, the POST to the cloud, and the notify-and-lift sequence are unchanged.
These two modes behave differently from everything above, and the difference matters operationally: the access point contacts the directory itself rather than the cloud doing it.
Meraki AP Domain Controller
(Global Catalog)
| |
|--- TCP connect -------------------------> | TCP 3268
|--- STARTTLS ----------------------------> |
|<-- TLS handshake, certificate validated -> |
| |
|=== TLS tunnel established =============== |
| |
|--- BIND as dashboard service account ----> |
|<-- bind OK ------------------------------ |
| |
|--- SEARCH sAMAccountName = <username> ---> |
|<-- return user's distinguished name ----- |
| |
|--- BIND as user DN + submitted password -> |
|<-- bind OK = user authenticated --------- |
Two binds occur per sign-in: the first proves the AP may query the directory, the second proves the user knows their password. If the service account is wrong the first bind fails and no user can sign in; if only the second fails, that user's password was incorrect.
The requirements that follow from this are specific:
A useful side effect of the bind-account model is that access can be scoped per SSID by denying the bind account read permission on the organisational units that should not be able to authenticate to that SSID. Users the bind account cannot see cannot be authenticated.
⚠️ Not All Splash Methods Authenticate in the Same Place: With Active Directory or LDAP selected, the access point contacts the directory directly. With Meraki authentication or RADIUS selected, the Meraki cloud does the validation instead. This changes which firewall paths matter and which component fails when authentication breaks, so confirm which method is configured before troubleshooting. Meraki does not document how the submitted credentials pass from the splash page to the access point for the directory modes, so that handoff is shown above as a gap rather than invented.
Where the splash page is hosted on your own server rather than by Meraki, an extra redirect appears at the front and the page itself comes from your host. Authentication still completes against the Meraki cloud.
Client Meraki AP Meraki Cloud EXCAP Server
| | | |
|--- HTTP GET ---->| | |
|<-- HTTP 307 -----| | |
| | | |
|--- GET splash URL -----------> | |
|<-- 302 to custom URL + cookie- | |
| carries base_grant_url and user_continue_url |
| | | |
|--- GET custom splash URL ------------------------> |
|<-- 200 OK + your splash page -------------------- |
| | | |
| [ user clicks Continue, or submits credentials ] |
| | | |
|--- GET grant URL / POST to login URL --------> |
| | | |
| |<- notify APs-| |
|<-- 302 to grant_user_access -- | |
The EXCAP server must be in the walled garden. If it is not, the client is redirected to a page it is not permitted to reach, the AP redirects it back to the splash server, and the browser loops until it gives up with a "too many redirects" error.
ISE is the exception to the association rule. It pairs with MAC-based access control or with Enterprise and your RADIUS server, not with Open or PSK, and the redirect is driven by RADIUS rather than by a dashboard splash setting.
Client Meraki AP Cisco ISE
| | |
|--- Association ----->| MAC-based or Enterprise |
| |--- RADIUS Access-Request --->|
| |<-- Access-Accept with -------|
| | redirect URL and ACL |
| | |
|--- HTTP GET -------->| Matched by the redirect ACL |
|<-- redirect to ISE portal ------------------------- |
| | |
|--- guest login / posture assessment -------------> |
|<-- portal exchange ------------------------------- |
| | |
| |<-- CoA, reauthorise ---------|
| | Full access granted |
This is a simplified view of the exchange; posture assessment in particular adds further steps. It is included here to show where ISE sits relative to the other modes rather than as a configuration reference.
Sentry checks enrolment state rather than a credential. A device that is not enrolled in one of the organisation's Systems Manager networks is presented with a prompt to enrol; once enrolment completes, access is granted. The splash page is pre-configured and cannot be customised.
The Enrolment network, Strength and Enforce On settings appear beneath the splash section once Sentry is selected, and control which SM network is offered and which device types are forced to enrol.
Three settings govern what an unauthenticated client can reach and what happens when the cloud is unavailable. All three apply regardless of which splash mode is chosen.
| Setting | Options | Notes |
|---|---|---|
| Captive portal strength | Block all access until sign-on is complete; Allow non-HTTP traffic prior to sign-on | The permissive option also bypasses access firewall rules on a click-through SSID until sign-on. Disabled by default |
| Walled garden | List of IPs and domains, wildcards permitted | Must include the EXCAP server, and any host the splash page itself needs |
| Controller disconnection behaviour | Open; Restricted; Default for your settings | Default resolves to Open for click-through and Restricted for sign-on |
The captive portal strength setting has a consequence that is easy to miss. "Allow non-HTTP traffic prior to sign-on" permits everything except HTTP on port 80. Because almost all traffic is now HTTPS, a client whose authorisation has expired continues working normally until it happens to issue a plain HTTP request. To make expiry actually take effect, use "Block all access until sign-on is complete".
Devices that cannot interact with a splash page at all — gaming consoles, VoIP handsets, DVRs, most IoT — are handled with a group policy whose Splash setting is Bypass, applied to those clients.
| WPA2-Enterprise with RADIUS | Sign-on splash page | |
|---|---|---|
| Layer | 2 | 3 |
| Authenticates | Before network access | After network access |
| Client has an IP before auth | No | Yes |
| Association requirement | Enterprise | Open or PSK only |
| Protocol to identity store | RADIUS, UDP 1812/1813 | Varies by mode — see above |
| Device trust to identity store | Shared secret per AP, or certificates with RadSec | Service account bind credentials, or cloud-side |
| Who contacts the identity store | The AP | The AP for AD and LDAP; the Meraki cloud for the rest |
| Encryption keys | Derived per user from the authentication | Independent of authentication |
| Client requirement | 802.1X supplicant and profile | A web browser |
| Non-browser devices | Supported | Not supported without a bypass policy |
| Per-user VLAN | Yes, via RADIUS attributes | Not from the directory response |
| Machine authentication | Possible | No |
| Reconnection | Automatic and silent | Re-prompted when the session expires |
| Survives a Meraki cloud outage | Yes | No, for new authentications |
This is the difference that matters most and the one most often missed.
Under 802.1X the encryption keys are a product of the authentication exchange. Each user session derives its own pairwise key, so no client can decrypt another client's traffic even on the same SSID. Authentication and confidentiality are inseparable.
A splash page provides no encryption of its own. It is a gate placed in front of an SSID whose encryption was already decided independently — and because a sign-on splash page forces the association to Open or PSK, the options are limited to exactly two, both weak:
⚠️ Splash Authentication Does Not Secure the Air: Requiring domain credentials at a splash page can create a false impression that the wireless network is secured to enterprise standard. It is not. The credentials control access, not confidentiality. If corporate data traverses the SSID, use WPA2-Enterprise — and note that the dashboard will not let you add a sign-on splash page to an Enterprise SSID, so this is a choice between them rather than a layering of both.
There is a second consequence. Splash authorisation is bound to the client's MAC address, so an attacker who observes an authenticated client's MAC and spoofs it can inherit that authorised state. 802.1X is not vulnerable to this, because possession of the session keys cannot be spoofed.
The AP can only intercept and redirect cleartext HTTP. When an unauthenticated client requests an HTTPS site outside the walled garden, the AP cannot inject a redirect into an encrypted session, so the connection is simply blocked. The user sees a browser timeout rather than the sign-in page.
Modern operating systems mitigate this with captive portal detection, fetching a known plain-HTTP URL on association and raising a sign-in prompt. Where that detection is disabled, blocked, or fails, users report "the wireless is broken" when the splash page simply never appeared.
The splash page is served from network-auth.com in the Meraki cloud. If the cloud is unreachable, new clients cannot authenticate. Controller disconnection behaviour decides what happens next, and leaving it on the default means click-through SSIDs fail open while sign-on SSIDs fail closed. Make that a deliberate choice rather than an inherited one.
802.1X does not have this exposure. The AP and RADIUS server talk directly over the LAN, so authentication continues through a cloud outage. See KBA-035 - Meraki Dashboard — Cloud Management Architecture for the wider control plane and data plane split.
The splash flow depends on the p_splash_session cookie to correlate the session. A browser blocking or clearing cookies will complete the sign-in form and still show as unauthorised, typically presenting a blank page.
Printers, cameras, sensors, medical equipment and similar devices cannot complete a splash sign-in. They require a bypass group policy, a separate SSID, or MAC-based RADIUS authentication. Any splash deployment needs a plan for these before rollout, not after.
802.1X has its own overhead. Clients need a configured profile, and correct certificate trust for the RADIUS server, normally distributed through Group Policy, Intune or an MDM. A client configured to blindly trust any server certificate is vulnerable to an evil twin harvesting credentials — so validating the RADIUS server certificate is not optional in a correct deployment.
Use WPA2-Enterprise with RADIUS for any SSID carrying corporate traffic or accessed by managed devices. It is the only one of the two that provides per-user encryption, per-user VLAN and policy assignment, silent reconnection, and independence from cloud availability.
Use a sign-on splash page where the requirement is accountability rather than confidentiality, and where devices are unmanaged — guest and contractor access being the usual cases. Recording who signed in and when has real value even when the underlying SSID is open, provided nobody mistakes it for a security control on the traffic itself.
Because the two cannot coexist on one SSID, the usual pattern is a WPA2-Enterprise SSID for corporate devices alongside a separate guest SSID with a splash page, each with its own VLAN and firewall policy.
| Method | Where to look |
|---|---|
| Splash | Wireless > Monitor > Splash logins and Wireless > Monitor > Login attempts |
| 802.1X | Client details page, plus the event log for association and authentication failures |
| Client state | Client details page shows "Splash: Not authorized" or "Authorized" with time remaining |
Splash authorisation can be cleared for a single client from Network-wide > Monitor > Clients by selecting the client and choosing revoke next to the Splash field. The control is visible on MX appliances but does not function there.