Cisco Meraki
MS switches, MR access points
Examples assume two Edge appliances at 10.10.10.10 and 10.10.10.11, a tenant PSK shown as ARBITER_PSK and a guest portal URL of https://acme-7f3-guest.arbiter.ie/. Substitute your own values from the Arbiter portal.
For the universal context (architecture, AAA dead-server tuning, DHCP relay intent), see the Network devices overview.
Wired: RADIUS server, 802.1X and MAB
Switch -> Access policies -> Add an access policy.
Name: Arbiter 802.1X
Authentication method: my RADIUS server
RADIUS servers:
Server #1 Host: 10.10.10.10 Port: 1812 Secret: ARBITER_PSK
Server #2 Host: 10.10.10.11 Port: 1812 Secret: ARBITER_PSK
RADIUS testing: enabled
RADIUS CoA support: enabled (port 3799)
RADIUS accounting: enabled
Server #1 Host: 10.10.10.10 Port: 1813 Secret: ARBITER_PSK
Server #2 Host: 10.10.10.11 Port: 1813 Secret: ARBITER_PSK
Host mode: Multi-auth
Access policy type: 802.1X
Guest VLAN: <fallback VLAN id>
Voice VLAN clients: Bypass authentication
Apply to ports: Switch -> Switch ports -> select access ports
-> Policy: Arbiter 802.1XWireless: 802.1X SSID
Wireless -> Configure -> Access control -> choose SSID.
SSID: Corp
Association: WPA2-Enterprise with my RADIUS server
RADIUS servers:
Server #1 Host: 10.10.10.10 Port: 1812 Secret: ARBITER_PSK
Server #2 Host: 10.10.10.11 Port: 1812 Secret: ARBITER_PSK
RADIUS testing: enabled
RADIUS CoA support: enabled
RADIUS accounting: enabled (same two servers, port 1813)
Splash page: None
VLAN tagging: RADIUS overrideGuest SSID: open with captive portal redirect
Open SSID with MAC-based access control, no Meraki-hosted splash. Arbiter returns the redirect URL.
SSID: Guest
Association: Open
Network access: MAC-based access control (no encryption)
RADIUS servers: both Edges as above
Splash page: Click-through -> Custom-hosted by Cisco Meraki -> unchecked
(Meraki passes through the redirect URL returned by RADIUS)
Walled garden: add acme-7f3-guest.arbiter.ie
Arbiter returns on the open-SSID Access-Accept:
Cisco-AVPair = url-redirect-acl=GUEST-REDIRECT
Cisco-AVPair = url-redirect=https://acme-7f3-guest.arbiter.ie/DHCP relay to Edge
Meraki MX or MS layer-3 SVIs. Security & SD-WAN -> Addressing & VLANs (MX), or Switch -> Routing & DHCP -> Interface (MS).
DHCP handling: Relay DHCP to another server
DHCP servers: 10.0.0.5 (real DHCP)
10.10.10.10 (Edge #1)
10.10.10.11 (Edge #2)AAA dead-server detection
Meraki exposes RADIUS testing as a single toggle. When enabled, the dashboard probes both servers every few minutes and the device fails over against the probe state. Leave it enabled. Meraki manages dead-criteria and deadtime internally so there are no manual timers to tune, and because the probes target the local Edge appliances on your LAN the cloud-managed timers fail over quickly in practice.
Access policy -> RADIUS testing: enabled
(no further tunables; dashboard manages dead-criteria and deadtime internally)CoA listener
Enabled by the 'RADIUS CoA support' toggle in the access policy. Listens on UDP/3799 from both Edge IPs.
Access policy -> RADIUS CoA support: enabledNotes
- Meraki does not expose per-server timeout values. The RADIUS testing toggle is the only knob; leave it on.
- For MR access points serving the guest SSID, ensure the walled garden lists the portal hostname so the captive portal redirect renders before authorisation.
Verify the integration
Once the device is configured, validate against the Arbiter portal rather than the vendor's own RADIUS test tooling. Vendor tools confirm reachability but not policy outcomes. See the validation checklist on the overview page.
Need help?
Onboarding kit not behaving as expected? Email support@arbiter.ie with the device model, firmware version and the syntax you tried. We can usually identify the difference within a working day.