Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Cusna
Community Record
5
Posts
0
Kudos
0
Solutions
Badges
As a matter of fact, we can achieve extreme flexibility in the use of PPSK with most of vendors because their PPSK-without-RADIUS mode supports many PSKs (not 50 like Meraki). Ref: https://docs.cusna.io/ With Meraki, unfortunately we can't make this happen... The only PPSK+RADIUS implementation I found that support this auto-provisioning is - unfortunately - Ruckus (look at this)
... View more
My understanding is that the AP only sends a MAC authentication request (with MAC as username/password). The RADIUS validates that the MAC address matches with a valid device (that's why the need to be added in advance). If the RADIUS finds a match, replies with an Access Accept including the Passphrase (associated to the user and know to the RADIUS) in the Tunnel-Password attribute. The AP, then, performs the WPA2 4-way handshake (ref) verifying the passphrase entered by the user in the client vs the one obtained form the RADIUS in the Tunnel-Password attribute.
... View more
My understanding (and tests) suggest that Meraki does not send it in the access-request (and for obvious security reasons). Is the RADIUS server adding it as attribute in the access-accept back to the AP, so the AP would start the 4-way handshake, and if the PSK entered by the user match the one the RADIUS replied with in the tunnel-password attribute, then the association will be successful. So basically the RADIUS has no clue on what passphrase the user entered. If it finds the mac address of the client, then it replies saying "by the way... if the user entered this passphrase, let him connect"...
... View more
Thanks Philip for the feedback. Regardless the "formula" used, the point is that right now Meraki is not sending any information in the access-request that would allow the RADIUS server to understand who is attempting to connect, except for the MAC address of the client. The other solutions referred above send some parameter that (with a "formula") allow the RADIUS server to see what passphrase the user entered. At this point I would have the user device MAC address and a passphrase to match him with a user account. Form here there are many cool experience that could be triggered to automatically provision that device without having the user to manually enter a MAC address anywhere.
... View more
Jun 27 2022
9:47 PM
IPSK is an amazing solution for many scenario and verticals. The IPSK solution of Meraki without RADIUS supports only up to 50 PSKs per SSID, which is not really scalable. The solution with RADIUS, however, requires the RADIUS to know in advance the MAC address of clients allowed in the network. There are several solution out there that require users to manually enter their client MAC address (especially for headless devices, while other devices can be onboarded via a captive portal). This seems to me very complicated and prone to error and leading to a lot of support requests - it may work in campuses with young students but not much in senior living scenario). Is there a solution to make this work without having the RADIUS to know in advance the client MAC address? The Ruckus DPSK solution, attaches to RADIUS access-request some additional attributes that basically allow the RADIUS server to compute the PSK and, if correct, automatically add the MAC address to the client list (details here). Any idea about how this could be implemented, right now, on Meraki?
... View more
© 2024 Cisco Systems, Inc.
