Meraki WLAN MAC-based access control with PSK

The Problem:

When looking at the configuration of a Meraki SSID (this is software version 27.5.1), there is no obvious way to configure MAC-based access-control and PSK simultaneously as it is possible with the traditional Cisco WLAN:

We can configure either PSK or MAC-based access control, but the later without encryption.

Why do we need both? One reason is to control Guest-access with the Cisco ISE and there we need a RADIUS-Request from the NAD to start the Guest-Workflow. At the same time we want to protect the SSID, that not every one in range can connect to this Guest-SSID.

The solution to this “problem” is to combine two Meraki features which result in the desired functionality.

The Meraki SSID-config:

Instead of using the option “MAC-based access control (no encryption)” we choose the option “Identity PSK with RADIUS”:

With this feature we assign a PSK to the session that is not configured on the Meraki-side, the PSK gets “pushed” from the RADIUS-server. The Guest-session is then controlled with the Meraki Splash-page, same as we would do it without a PSK;

The ISE is running on 10.255.192.141:

On the Meraki-APs we need the “Walled Garden” feature instead of using Redirect-ACLs like on traditional Cisco APs:

To combine these two features, we just need to make sure that we always return the same PSK for the same session.

The ISE-Config:

Here I show the policy for the “hotspot”-Guest workflow. The other workflows could also be used in a similar way. I assume that the reader knows the Guest-Workflow (which is for example learned in the Cisco SISE-training) .

We need two Authorization rules, one for the unknown guest that starts the workflow and one for the enrolled guest that gets access to the internet.

This is the last authorization rule in my MAB-policy set (yes, not a perfect name, I’ll change that later 😉 ):

When no other rule matches for an unknown MAC, the Authorization profile “WLAN-Hotspot” is returned to the Meraki AP. I match on Wireless MAB and the SSID name. These are the attributes in that profile:

The important attribute ist RADIUS:Tunnel-Password, which implements the “iPSK with RADIUS” feature. The redirect-ACL is not needed and the Meraki-documentation uses the keyword “NULL”. I use the same Authorization Profile also for my traditional Cisco WLAN and that is the reason an ACL is configured.

With this config, the Guest can associate to the WLAN with the PSK “MySuperSecurePSK” and is redirected to the ISE-Portal to start the Guest-Flow. After completing the guest-flow the next authorization-rule is selected:

This example is from a LAB-environment, I use the same authorization for both the Hotspot- and Registered-Guest workflows. These are the RADIUS-attributes that I return:

In this Authorization-Profile the redirect-URL is removed, but most important, the same Tunnel-Password as before is returned. If we skip the Tunnel-Password in the final authorization, the endpoint directly loses the connection. The other parameters are again not relevant, but we can assign a VLAN and/or a Meraki Group-Policy for which I use the “Filter-ID”.

Any drawbacks? Well, just remember that you have to modify at least two authorization profiles when you do your regular PSK-change.

Have fun in combining your Cisco ISE with your Meraki APs!