How to Set Up Cloud RADIUS with Cisco Meraki: Complete Guide

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 Azure AD, 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	Azure AD, 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 - sign up for a free trial if you do not have one
• Firewall access to allow outbound UDP on ports 1812 and 1813 from your AP subnet to IronWiFi server IPs
• A test client device (laptop or phone) that supports WPA2-Enterprise

Step 1: Set Up IronWiFi Cloud RADIUS

Start by configuring the RADIUS server side in IronWiFi. This creates the authentication endpoint that your Meraki APs will send requests to.

1. Log into the IronWiFi Console at console.ironwifi.io and navigate to Networks.
2. Create a new Network by clicking Add Network. Give it a descriptive name (e.g., "Meraki Corporate WiFi") and select the server region closest to your access points.
3. Note the RADIUS server details that IronWiFi generates: the server IP address, authentication port (1812), accounting port (1813), and the shared secret. You will enter these into the Meraki Dashboard in the next step.
4. Add your Meraki AP source IPs under the network's authorized clients. This is the public IP address (or range) that your Meraki APs use for outbound traffic. If your APs are behind NAT, use the NAT gateway IP.
5. Configure authentication sources. Under the network settings, connect your identity provider - Azure AD, Google Workspace, Okta, or create local user accounts for testing.

Step 2: Configure RADIUS in Meraki Dashboard

Now configure the Meraki Dashboard to point to your IronWiFi RADIUS server. This tells the access points where to send authentication requests.

1. Log into the Meraki Dashboard at dashboard.meraki.com and select your network.
2. Navigate to Wireless > Configure > Access control. Select the SSID you want to configure (or create a new one).
3. Under Security, change the association requirement to WPA2-Enterprise with my RADIUS server.
4. In the RADIUS servers section, click Add a server and enter:
   • Host: The IronWiFi RADIUS server IP address
   • Port: 1812
   • Secret: The shared secret from IronWiFi
5. Add a secondary RADIUS server for redundancy. IronWiFi provides multiple server endpoints - add the second server IP with the same port and secret.
6. Under RADIUS accounting, enable accounting and add the same server(s) with port 1813. This sends session data to IronWiFi for logging and analytics.

Step 3: Configure Your SSID for 802.1X

With the RADIUS server configured, finalize the SSID settings for enterprise authentication.

1. On the same Access control page, confirm the security mode shows WPA2-Enterprise. For newer deployments, you can also select WPA3-Enterprise if your client devices support it.
2. Under Splash page, select None (direct access) for 802.1X. The RADIUS server handles authentication, so no captive portal is needed for enterprise users.
3. Configure RADIUS-based client IP assignment if you want the RADIUS server to control VLAN placement (covered in Step 4).
4. Under Wireless options, set the SSID name to something users will recognize (e.g., "CorpNet-Secure" or your organization name).
5. Set Band selection to "Dual band operation (2.4 GHz and 5 GHz)" for maximum compatibility, or "5 GHz band only" for higher-performance environments.
6. Click Save Changes. The Meraki APs will update their configuration within a few minutes.

Step 4: Dynamic VLAN Assignment

One of the most powerful features of RADIUS authentication is dynamic VLAN assignment. Instead of putting all users on the same network segment, the RADIUS server tells the access point which VLAN to assign based on user attributes.

Configure VLANs in Meraki

1. In the Meraki Dashboard, go to Wireless > Configure > Access control for your 802.1X SSID.
2. Under Client IP and VLAN, change the setting to Use VLAN tagging.
3. Set the Default VLAN to a fallback VLAN ID (e.g., 100) for users whose RADIUS response does not include VLAN attributes.
4. Enable RADIUS override. This allows the RADIUS server to dynamically assign VLANs by returning VLAN attributes in the Access-Accept response.

Configure VLAN Attributes in IronWiFi

In the IronWiFi console, configure the following RADIUS attributes for each user group or policy:

RADIUS Attribute	IETF Number	Value
Tunnel-Type	64	VLAN (13)
Tunnel-Medium-Type	65	IEEE-802 (6)
Tunnel-Private-Group-ID	81	Your VLAN ID (e.g., 200)

For example, you might assign VLAN 200 to employees, VLAN 300 to contractors, and VLAN 400 to IoT devices. IronWiFi lets you define these mappings based on user groups, identity provider attributes, or device certificate properties.

Step 5: Testing Authentication

Before rolling out to all users, verify that the RADIUS configuration works correctly.

Use the Meraki Built-in RADIUS Test

1. In the Meraki Dashboard, go to Wireless > Configure > Access control.
2. Scroll to the RADIUS servers section and click Test next to your configured server.
3. Enter a test username and password (from your IronWiFi user database or identity provider).
4. Click Run test. Meraki will send a test RADIUS authentication from each AP to the RADIUS server using PEAP-MSCHAPv2.
5. A successful test shows a green checkmark. If it fails, check the troubleshooting section below.

Test with a Real Client Device

1. On a test laptop or phone, search for the configured SSID and select it.
2. When prompted, enter the username and password (for PEAP) or select the certificate (for EAP-TLS).
3. On the first connection, you may be prompted to trust the server certificate. Accept it to proceed.
4. Once connected, verify the assigned IP address is in the correct VLAN range.
5. Check the IronWiFi authentication logs under Logs > Authentication to confirm the request was processed and the correct attributes were returned.

Troubleshooting Common Issues

Even with careful configuration, RADIUS integrations can run into issues. Here are the most common problems and how to resolve them.

RADIUS Timeout (No Response)

If the Meraki Dashboard shows RADIUS timeouts or the test fails with no response:

• Firewall rules - Verify UDP ports 1812 and 1813 are open from the AP subnet to the IronWiFi server IPs. Many corporate firewalls block outbound UDP by default.
• Source IP mismatch - The public IP of your Meraki APs must be registered as an authorized client in IronWiFi. Check your NAT gateway IP if APs are behind NAT.
• Wrong server IP - Double-check the RADIUS server IP in the Meraki Dashboard matches what IronWiFi provided.
• DNS resolution - If you entered a hostname instead of an IP, ensure it resolves correctly from the AP network.

Authentication Rejected (Access-Reject)

• Wrong credentials - Verify the username and password in IronWiFi. Remember that authentication is case-sensitive.
• Shared secret mismatch - Even one character difference causes the RADIUS server to reject the request. Re-enter the secret in both Meraki and IronWiFi.
• Disabled account - Check that the user account is active in IronWiFi and not blocked by a conditional access policy.
• EAP method mismatch - Ensure the client is configured for an EAP method that IronWiFi supports (PEAP, EAP-TLS, EAP-TTLS).

Certificate Errors

• Server certificate not trusted - Clients need to trust the IronWiFi RADIUS server certificate. On managed devices, deploy the CA certificate via your MDM. On BYOD devices, users must accept the certificate prompt on first connection.
• Certificate expired - If using EAP-TLS, check that both the client certificate and the CA certificate are within their validity period.
• Wrong certificate selected - On devices with multiple certificates, ensure the correct one is selected for WiFi authentication.

VLAN Assignment Not Working

• RADIUS override not enabled - In Meraki, the "RADIUS override" option must be turned on for the SSID. Without it, Meraki ignores VLAN attributes from RADIUS.
• Missing VLAN attributes - All three tunnel attributes (64, 65, 81) must be present in the RADIUS response. Missing any one will cause the assignment to fail.
• VLAN not trunked - The VLAN must be configured on the switch port connecting to the Meraki AP. Verify with your switch configuration.
• VLAN ID format - Ensure the Tunnel-Private-Group-ID is a plain integer (e.g., "200"), not a VLAN name.

Best Practices for Production

Once authentication is working, apply these practices before rolling out to your entire organization.

Security

• Use EAP-TLS in production - Certificate-based authentication is significantly more secure than username/password. Deploy certificates through IronWiFi SCEP or your MDM for automated enrollment.
• Rotate RADIUS shared secrets annually and use strong, randomly generated strings (32+ characters).
• Enable RADIUS accounting to maintain a complete record of who connected and for how long.
• Restrict RADIUS client IPs in IronWiFi to only your known AP subnets.

Redundancy

• Configure multiple RADIUS servers - IronWiFi provides multiple server endpoints. Add at least two servers in Meraki for failover.
• Test failover behavior - Temporarily block traffic to the primary server and verify that clients authenticate against the secondary.
• Set appropriate timeouts - In Meraki, the default RADIUS timeout is suitable for most deployments. Avoid setting it too low, which can cause false failures during brief network latency spikes.

User Experience

• Pre-deploy certificates on managed devices using your MDM to avoid certificate prompts.
• Use a clear SSID name that indicates it is the secure corporate network.
• Provide a separate guest SSID with captive portal authentication for visitors, keeping the 802.1X SSID for employees and managed devices.
• Document the connection process for your IT helpdesk so they can assist users who have trouble connecting.

Monitoring

• Review IronWiFi authentication logs regularly for failed attempts, which may indicate misconfigured devices or unauthorized access attempts.
• Set up alerts in IronWiFi for authentication failures exceeding normal thresholds.
• Monitor RADIUS server response times in the Meraki Dashboard to identify latency issues early.