To set up RADIUS for Cisco Meraki, configure a Cloud RADIUS server with your organization's users, then in the Meraki Dashboard create a WPA2-Enterprise SSID pointing to the RADIUS server's IP and port with a shared secret. Meraki forwards 802.1X authentication requests to the RADIUS server, which validates user credentials and returns accept or reject decisions.
Cisco Meraki is one of the most widely deployed cloud-managed wireless platforms in the world. Its dashboard makes access point management straightforward, but securing your wireless network beyond a simple pre-shared key requires a RADIUS server. This guide walks through every step of connecting Meraki MR access points to IronWiFi Cloud RADIUS for enterprise-grade 802.1X authentication.
Why Use RADIUS with Cisco Meraki?
Meraki access points support several authentication methods out of the box, from open networks to pre-shared keys. But once your organization grows beyond a handful of users, the limitations of shared passwords become a real operational burden. RADIUS authentication solves these problems by giving every user or device a unique identity on the network.
With RADIUS authentication on Meraki, you gain:
- Individual user credentials - Every person authenticates with their own identity, eliminating shared password management
- Certificate-based authentication - Deploy EAP-TLS to remove passwords entirely, using device certificates for authentication
- Dynamic VLAN assignment - Place users into different network segments based on their role, department, or device type
- Centralized access control - Grant or revoke network access instantly from a single dashboard
- Detailed audit trails - Know exactly who connected, when, and from which device
- Identity provider integration - Authenticate against Microsoft Entra ID, Google Workspace, Okta, or any SAML/LDAP directory
PSK vs WPA2-Enterprise: What Changes
Understanding the difference between these two approaches is essential before configuring RADIUS. Here is how they compare across the dimensions that matter for enterprise deployments.
| Capability | WPA2-PSK (Personal) | WPA2-Enterprise (RADIUS) |
|---|---|---|
| Authentication | Shared password for all users | Unique credentials per user/device |
| User revocation | Change password for everyone | Disable individual accounts instantly |
| Encryption | Same key for all sessions | Unique session keys per user |
| VLAN assignment | Single VLAN per SSID | Dynamic per-user VLAN from RADIUS |
| Audit trail | MAC address only | Username, device, time, duration |
| IdP integration | Not supported | Microsoft Entra ID, Google, Okta, LDAP |
| Certificate auth | Not available | EAP-TLS with device certificates |
| Scalability | Difficult beyond 50 users | Thousands of users and devices |
Prerequisites
Before starting the configuration, make sure you have the following in place:
- Cisco Meraki MR access points with an active Dashboard license
- Meraki Dashboard access with Organization Admin or Network Admin permissions
- IronWiFi account - Talk to Sales
Trusted by 1,000+ organizations across 108 countries
Frequently Asked Questions
Cisco Meraki uses the authentication and accounting UDP ports assigned in your IronWiFi Console. These ports must be open on any firewalls between the Meraki access points and the RADIUS server. When using IronWiFi Cloud RADIUS, outbound UDP traffic on these ports must be allowed from the Meraki APs to the IronWiFi server IPs.
Yes, that is exactly what IronWiFi Cloud RADIUS provides. Instead of maintaining a local FreeRADIUS or NPS server, you point your Meraki access points to IronWiFi's globally distributed RADIUS servers. This eliminates the need for on-premises server hardware, OS patching, and RADIUS software maintenance.
Configure three RADIUS attributes in IronWiFi: Tunnel-Type (IETF 64) set to VLAN, Tunnel-Medium-Type (IETF 65) set to IEEE-802, and Tunnel-Private-Group-ID (IETF 81) set to the VLAN ID. In the Meraki Dashboard, enable"RADIUS override" under Access Control so the SSID accepts VLAN assignments from the RADIUS response.
When using an external RADIUS server like IronWiFi, Meraki access points act as a pass-through for EAP negotiation. The supported EAP methods depend on the RADIUS server configuration. IronWiFi supports EAP-TLS (certificate-based), PEAP-MSCHAPv2 (username/password), EAP-TTLS, and EAP-TEAP. EAP-TLS with certificates is recommended for production deployments as it eliminates password-related vulnerabilities.
RADIUS timeouts with Meraki typically have four common causes: (1) Firewall blocking the assigned RADIUS UDP ports between the AP and RADIUS server. (2) Incorrect RADIUS shared secret - even one character mismatch causes silent drops. (3) Wrong RADIUS server IP configured in the Meraki Dashboard. (4) The source IP of the Meraki AP is not added as an authorized client in IronWiFi. Check the IronWiFi authentication logs for rejected or missing requests to narrow the issue.
Meraki's built-in authentication (Meraki Cloud Authentication) is limited to basic username/password authentication with a small local user database. An external Cloud RADIUS like IronWiFi provides certificate-based EAP-TLS authentication, integration with identity providers (Microsoft Entra ID, Google Workspace, Okta), dynamic VLAN assignment, granular access policies, detailed authentication logs, and support for thousands of users across multiple sites.
Meraki allows you to configure multiple RADIUS servers per SSID for redundancy. You can add a primary and one or more secondary RADIUS servers. IronWiFi provides multiple server endpoints across different geographic regions. If the primary server is unreachable, Meraki automatically fails over to the next configured server, ensuring continuous authentication availability.
Yes. You need to allow outbound UDP traffic from your Meraki access points to the IronWiFi RADIUS server IPs on the assigned RADIUS authentication and accounting ports. Since Meraki APs authenticate directly to the RADIUS server (not through the Meraki cloud), the firewall rules must permit traffic from the AP subnet. IronWiFi provides specific server IPs during setup that should be added to your firewall allowlist.
Daniel Konecny
Founder & CEO, IronWiFi
Daniel founded IronWiFi to make enterprise WiFi authentication simple and secure. With deep expertise in RADIUS, 802.1X, and cloud infrastructure, he writes about practical network security for IT teams managing thousands of devices.
About the author