Meraki IPSK with FreeRADIUS

This is a follow up to my Post IPSK on Cisco without ISE but FreeRADIUS. The FreeRADIUS server has already been running in the state since that post, and I will show what has to be done specific to the configuration when working with Cisco Meraki APs.

Meraki’s IPSK comes in two flavors: with RADIUS server and without.

The “without” option lets you configure multiple PSKs that are valid to every client that knows them. Numerous vendors support this system, and the AP basically tries all valid PSKs on client join to find the one that matches. The issue with this approach is that it can’t work with WPA3. With WPA3 (and with that, I mean WPA3-SAE, not 802.1X) the AP has to know the correct secret and has no chance of trying multiple possibilities. One vendor claims to have worked around that, but there have yet to be any technical details.

This leaves us with “Identity PSK with RADIUS” - because we “pre-register” our clients with MAC-address in our RADIUS-Server, the AP can query it for the correct passphrase as soon as it receives a join from a client, which makes this possible with WPA3-SAE. But, as of today, Meraki APs (version MR 30.6) do not support this yet. Ciscos 9800 controller supports this starting from 17.9.2, so we can hope that Meraki will support this soon too. The security issue itself is not that big, because some of the weaknesses of WPA2-PSK are a bit offset by IPSK, but missing WPA3 support also means no IPSK in 6 GHz, as WPA3 is required for the 6 GHz band.

Having said the theoretical parts of this post, let’s get to configuring.

As our FreeRADIUS Server is already running, we add our new IPSK client to the “users” file and restart the freeradius-service afterwards:

961b74ac43ae	Cleartext-Password := "961b74ac43ae"
		        Tunnel-Password = mylonglongpsk

The MAC-address of our client, with the same as cleartext-password, as the MAC-auth that the Meraki AP does sends it for both username and password, so this is a check-item for FreeRADIUS. The thing we want to send back is in this case the “Tunnel-Password”. This is the big difference to IPSK on classical Cisco (9800 Controller, and also AireOS starting from 8.5). Classical Cisco sends the PSK as you can see on my original post in “Cisco-AVPair” attributes, and Meraki uses Tunnel-Password. We come back to that later. The interesting thing is that you can use both if you need it on Meraki and 9800.

If the IP address of your Meraki AP is not already in the clients list of FreeRADIUS, add it to the clients.conf file. I already put my subnet in there, so I am good to go - just need to make a note on my RADIUS shared secret.

Now, it is time to fire up my Meraki AP. A few minutes after I gave it POE power, it is online in my Meraki dashboard.

AP online in dashboard

In the security settings of a new SSID, I choose “Identity PSK with RADIUS” and define my FreeRADIUS server in the RADIUS section, with the IP address of my VM, the default auth port 1812 and the shared secret from my clients.conf file.

IPSK with RADIUS setting

defining the RADIUS server

And… that is it! The whole thing is setup in just minutes.

I point my iPhone - which is the MAC address I wrote into the users file - at the new SSID and join it, which it does without any issues.

iPhone joined

Meraki dashboard showing my iPhone

The FreeRADIUS log confirmes the MAC auth:

Sun Apr  7 13:46:11 2024 : Auth: (0) Login OK: [961b74ac43ae] (from client merakiap port 0 cli 96-1B-74-AC-43-AE)

And the Meraki log shows the MAB authentication:

Meraki log

Now the interesting part is in a packet capture, that I did between the Meraki AP and the FreeRADIUS server, especially the answer packet - the “ACCESS-ACCEPT”. As we remember, the accept-message is used to transport the PSK attribute, with C9800 and Meraki, but Meraki uses Tunnel-Password instead of Cisco-AVPair.

Packet capture of ACCESS-ACCEPT

If you look at the highlighted detail, you might notice “encrypted”. As is defined in RFC 2868 Section 3.5, the Tunnel-Password attribute is salted and then encrypted using our shared secret in RADIUS. My guess is, that the nature of the installations of Meraki gear is much more often over unsecure networks, so they opted for this method to give some security to the Pre-Shared-Key. Another option would be to use RADSEC, but this way this works out of the box.

And that is it! We successfully enabled IPSK on the Meraki AP, using the FreeRADIUS server from the 9800-IPSK post.