Responsive captive portal login page for Aruba wireless
January 8, 2015 13 Comments
During the course of the year we’ve ramped up the number of APs on our campus Wi-Fi network in order to increase take-up of BYOD and provide blanket coverage across all sites. We’ve been using the standard out-the-box Aruba login screen for authentication but have had feedback that it isn’t the easiest thing to use on mobile devices (particularly phones).
Fuelled by a large coffee and equally large chocolate dessert at lunch I decided to get creative and have a go at improving the login experience.
Aruba controller options
The default Aruba page is functional but is showing its age now, the controller allows you to change the background image and text but that’s about it unless you go for something more custom, as confirmed on one of the posts in the Aruba forums
In the controller options there’s an option to upload a custom login page, along with supporting files (referred to as Content in the Aruba interface). However it’s not easy to manage the additional files once they’ve been uploaded, which is a bit of a pain.
The Aruba manual linked below shows where to go in the web interface to customise the portal, just make sure you select the correct authentication profile for the SSID you want to edit!
Responsive themes & styling
Fortunately one of the replies about using a custom page got me thinking and initially I looked to use the Verti template as suggested. Initial attempts to strip it down didn’t quite look right so I had a search for something simpler. Soon I’d found exactly what I wanted with the Grayscale Bootstrap theme
The beauty of this theme is in the simplicity of it, everything on one page and just a couple of images to tweak (along with the usual colour changing in CSS). Adding the Aruba code for the login form was fairly trivial, along with some tweaks to the CSS to increase the height of the fields so they’re easier to hit on a touch device.
For the background I used the very handy advanced search tools on Google Images to find a subtle background. A cropped version of this image from the Colorado Clouds blog did the trick nicely, along with the usual Photoshop layer-mask trick to fade out to a solid colour for the remainder of the page.
My previous favourite base64 converter website seems to have been taken down so I’m now using http://www.base64-image.de instead.
A nice feature of the Grayscale template is the way the page is split into sections with shortcuts in the top menu bar. It made sense to put the AUP text in one of them rather than how it was displayed previously (in a slightly clumsy pop-up window).
Custom error handling
The advantage to reading the errors this way was that we’re now able to customise and CSS style the message shown to the user. Contrary to the Aruba documentation I’ve seen 3 possible messages so far (Aruba only mention one); two of them dealing with failed login due to invalid credentials and one for authentication server timeout.
Web server maximum concurrent clients
After enabling the new login page we noticed that the Aruba controller was struggling to load the page after users connected to the SSID. Rebooting the controller didn’t help, although the first user to load the captive portal after the restart was able to log in at normal speed.
A bit of investigation revealed a setting on the controller that limits the maximum number of concurrent connections to the internal web server used to provide the captive portal and ours was set to the default of 25. It seems that this was sufficient for the standard login form but soon gets overwhelmed with a more complex page (total size of the page plus supporting files is still under 1MB though).
To change the setting follow the information in the links above, or to save you time here’s the steps in abbreviated form 😉
- log into your Aruba controller’s Instant CLI using Putty or similar SSH client
- enter the console enable password and enter the commands that follow
- configure terminal
- web-max-clients 100
The change applies immediately. Use the commands below to check that it’s applied as expected and also keep an eye on your CPU and memory stats as the more concurrent sessions you allow the more resource gets used on the controller.
Note the web-max-clients setting goes from 25-320 (may vary depending on your controller). In our case with ~500 active Wi-Fi users (last time we looked) a web-max-clients setting of 100 seems to be working well but this will likely vary dependent on your usage patterns.
- show web-server
- show cpuload
- show memory
Login page screenshots
The screenshots below show the login page on both phone and tablet \ desktop views, the bootstrap responsive element doing a great job as the page resizes 🙂