IPSK with RADIUS - how does it work?

Getting noticed

IPSK with RADIUS - how does it work?

I have read below but still not 100% how does IPSK work.




So the IPSK idea is to have a single SSID to provide different VLAN and Group Policy to different type of devices right?

It is based MAB which I understand the process.

However, I don't understand how Radius server/ISE assigns the Meraki Group policy to endpoint.

In 802.1x Meraki doco, it uses typically airespace-id. 

In the IPSK doco, it mentioned Tunnel-password attribute, how does this link to different MAC and policy?



Separate question: can I use windows NPS instead of ISE to achieve this feature?

4 Replies 4
Kind of a big deal
Kind of a big deal

The most basic use case for iPSK is having different pre-shared keys for different users. They can be separated by special policies but you don‘t have to do that.


The group policy is assigned by RADIUS attribute „Filter-ID“ by default, but you can choose to have another attribute within the Access Control Cnfiguration for your iPSK-enabled SSID.


As long as your RADIUS server is able to return a specified attribute, it can be used. Even when you‘re using NPS. 😉

Hi @CptnCrnch ,


I haven't had any handson on NPS but found this pic online, looks like custom attributes.




Does this mean NPS is qualified?😀

Kind of a big deal
Kind of a big deal

From what I understand IPSK is where the PSK's are stored on the radius server and will be returned to the NAD ( access point ) in the radius attribute tunnel-password.

So basically the access point's software understands it needs to receive the tunnel-password from the radius server to be used to start the 4way handshake.

So again from my own understanding.
A client associates to the access point and receives an AID.
The AP sends a radius access-request to the configured radius server (service-type call-check, user/pass/calling station ID : MAC address from client).

The radius server finds the MAC address while processing the authentication rule.

The radius server finds the correct authorization profile while processing the authorization rules.  The radius server should know what authorization policy rule to match by matching on called station ID that contains the SSID.  In this authorization profile there will be a tunnel-password attribute and optionally a filter-ID containing the name of a group-policy that must be configured in dashboard.

The radius server returns access-accept with the aforementioned attributes.

The AP now has the material to create the PMK and the four-way handshake can be performed.

The client now is connected with the correct group policy.

The only thoughts I have:

- Does the client have some sort of timeout that could be triggered before the radius server returns it response to the AP?

Thank you @GIdenJoe @CptnCrnch .


In order for IPSK to work, is that correct that I have to prep the below?

  • Upload client MAC into ISE/Radius server
  • Assign the wireless client into groups with different PSK


ISE will catch the above PSK as tunnel password attribute in radius msg and check against MAC, then assign to different vlan and optionally policy?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.