05-08-2014 12:11 PM
We have a customer that is using their Controller 6000 to authenticate their users using Captive Portal.
They use CP to authenticate around 2000 users and in occassions the CP login page doesn't show.
When it is increased the "web-max-clients" value to 100 or 200, sometimes the issue is fixed but also sometimes the CPU load goes sky-high and GUI logins fails.
So, I need to know how many web sessions they're reaching in the controller using CP login page to authenticate.
Is there a command to show the current web sessions or a SNMP OID to retrieve that info so they can graph using tools like Cacti and figure it out how many web sessions they're using?
We know that using the controller to CP that many users is not the best way. We know that is best to use an external web server to handle that kind of traffic. But our customer refuses to do this and they just want to upgrade the controller to a better one (7200 series).
So I need to know how many web sessions they use or reach in the morning when all people is authenticating and using CP login Page. With this info maybe we can know if a 7200 controller can handle or not the CP usage.
Thanks guys in advance!
Solved! Go to Solution.
05-08-2014 09:47 PM
This is a pretty common complaint these days, especially if this is an older (i.e. non 72xx) controller. As more and more apps and people move to https as a default method of accessing the web, the load caused by cert processing on the controller has gone up and up.
Most of the time, if there are open SSIDs and CP with https enabled, then the clients that are associated (especially with smart phones) are banging away on all sorts of https URLs, such as facebook, twitter, akamai, amazonAWS, playstore, apple etc.
A given client sitting in the initial-role (with CP) with no intent of logging into the captive portal is still generating these https requests periodically. Each of these will put load on the controller as it intercepts the https and sends the 302 redirect for the captive portal.
There are a few options, I will outline them here in terms of increasing complexity but better return on CPU. If you need assistance with these, TAC can help.
1> switch to http captive portal with https submit
Change the form in the CP source to be https:// action. This will prevent every single session from causing https cert processing load until the user actually attempts to log into the captive portal. In some cases this will be sufficient, if it's a full on public hotspot, it may not be. The users credentials are still protected since the form action is https.
If you are using the Aruba internal CP and a custom login page, take a flash backup and then edit the "login" page file (it will be in upload\custom\<name of cp profile\) in a text editor. Find the login form, it looks like this:
<form action="/auth/index.html/u" method="post"> <input type="hidden" name="user" id="user" type="text" value="user1" class="text" accesskey="u" /> <input type="hidden" id="password" name="password" type="text" value="passwd1" class="text" accesskey="p" /> <input type="hidden" name="cmd" value="authenticate" /> <button type="submit">I Agree to this Terms and Conditions</button> </form>
then modify the "action" within the form to be as follows:
save the file and re-upload to the controller as a custom login page. If you renamed it, dont forget to edit the CP profile login URL. Note that the above assumes the Aruba default cert with CN="securelogin.arubanetworks.com" is still present, if you are using your own cert, then modify as required.
Finally, go to the captive portal profile and tick the "Use HTTP for authentication" checkbox.
2> disable https redirection
This is a bit of a big hammer approach, but will solve the problem instantly. Perform this in conjunction with 1> above, and it essentially means to modify the https redirection rule in the captiveportal ACL to deny rather than dst-nat 8081 the https traffic. The caveat with this approach is that any user that is trying to pop the captive portal with some https:// home page, will get an error until they attempt to launch some http:// based website.
3> same as 2> but with whitelisted sites
If there are some wellknown https:// based sites, you can try introducing a named netdestination that allows some of these through, thus allowing the captiveportal to pop up for something like https://www.facebook.com.
This can be achieved by creating a netdestination called something like allowed_https and populate it with things like name www.facebook.com or name *.yahoo.com as examples. Then we need to modify the "denied" https rule from 2> above to be "user alias alllowed_https svc-https dst-nat 8081 position 3".
Note that you have to be careful with approach 3> not to add too much back in, else you are just back to the same problem.
hope that helps,
05-08-2014 09:57 PM
Forgot to answer some of your specific questions
-- there is no SNMP oid for this
-- there is not really any CLI command, you could use "show netstat | include 8081" but you then have to filter it again to remove the TIME_WAIT and FIN_WAIT sessions (or include only the ESTABLISHED)
-- the main problem is https requests per second
-- external CP doesn't change/fix this, since the controller has to complete the https setup in order to send the 302 redirect to the client to tell it to go to the external CP
-- 72xx controller can handle larger certs (2k etc.) in hardware, doesn't need to offload to software like older controllers
05-09-2014 09:07 AM
Man, I really never thought that HTTPS could cause that kind of trouble in this scenario.
Thanks man, you've answered the specific question and also give a full explanation of How to help fix this issue. I'll give it a try.
Really appreciate it.