To support the needs of some of our large service provider customers, Meraki now supports the Wi-Fi Alliance WISPr protocol. What this means is that wireless users who subscribe to a multi-provider service like Boingo can roam across different service provider networks like AT&T, T-Mobile, and Telmex and authenticate seamlessly via RADIUS without the need to interact with a captive portal. This is similar to how cellphone users are allowed to roam across different networks, and is also known as Smart Client roaming. For example, one of our larger service provider customers can now allow users to roam across networks covering hundreds of Starbucks cafes and restaurants like Burger King. This allows service providers to offer convenient, hassle-free wireless access wherever their customers need it with minimum hassle as an added value service to their subscribers. This is a great example of how Meraki networks can be used by service providers to expand their businesses and improve service levels to their own customers.
WPA-Enterprise encryption with 802.1X authentication is the method of choice for providing secure access in an Enterprise WLAN environment. Unfortunately it’s also notoriously tricky to configure, with a range of possible configuration issues involving the three key players in the system (client devices, access points, and the RADIUS authentication server itself).
We’re pleased to announce a handy diagnostic tool in our Enterprise Cloud Controller which helps identify many problems with a custom 802.1X setup.
After configuring your RADIUS server for 802.1X, you now have the option of testing your setup directly from Meraki Dashboard:
Enter the username and password for a test user and click the Test button. The system initiates a test from each of your Access Points to your RADIUS server using 802.1X authentication with PEAP and MS-CHAPv2. Each AP in the network is individually tested; this enables us to detect network issues or RADIUS server configuration problems that might affect only a few of your APs.
If all goes well, you’ll see results like this:
(In the example above one AP is shown as “unreachable”, meaning that it was powered off and was therefore not tested. This is common for example if your network has one or two spare APs which are not normally kept powered on.)
If there are test failures, however, you’ll see results like these:
In this example there was a timeout while attempting to reach the server from one out of five APs tested. This error often results from forgetting to add an AP’s IP address to the whitelist on your RADIUS server, and it’s usually a very difficult error to discover and debug.
We think this is a useful tool that makes it super easy to troubleshoot the security of your WLAN. In addition, this tool provides peace of mind that each AP can authenticate users correctly. Automated testing is especially valuable in large, 100+ AP environments, where testing each AP manually could literally take days.
We look forward to hearing your feedback about it!