On a single 3400 controller with 48 AP-s there is one profile with radius authentication and another with captive portal using the same radius server on local network to authenticate but it is hogging the cpu with lots of "user httpd" type of processes. Already logged the case with support but they just not advising how to construct captive portal profile with radius which does not hammer the cpu.
As soon as this problematic captive portal is disabled, cpu goes back to normal (less than 30% approx).
There could be an issue with digital certificate which is never trusted on the client side, no matter which one is used.
The CPU is limited by the number of simultaneous users that hit the captive portal. You might want to move users over to an authentication method like 802.1x which is not as hard on the CPU. Even users who have not authenticated will tax the Captive Portal CPU vs. 802.1x where the CPU is taxed while users are actively authenticating.
Radius server is 2008R2 (NAS) and network policies condition is already IEEE 802.11 OR Wireless.
So, not sure what you meant by "move users over to.." ?
In controller configuration, captive portal profile (SSID) says 802.11 Security=None.
What I meant is you should move your users to an encrypted 802.1x WLAN, instead of the captive portal WLAN. The change would be made on the controller to wpa2-AES, instead of an open ssid.
Thanks for your fast response.
I already have SSID profile configured exactly like that - WPA2 &AES encryption. Only reason for having open type SSID like captive portal was to present a welcome page with AUP and logo, because some clients at the time could not digest internal certificate easily, which they had to ignore. So much for captive portal - never knew it would hog the CPU as it did.
Now, re digital certificate which one to use:
- internal self signed one generated on radius server (has to be ignored by clients)
- wild card validated domain style certificate used on web servers (not working)
- some other type that all clients will be happy with (laptops included as they have no way to verify it before they connect to wifi)?
If you have a domain, it is easiest to setup your own Domain-Integrated CA and provide the certificate from there: https://community.arubanetworks.com/t5/ArubaOS-and-Controllers/Step-by-Step-How-to-Configure-Microsoft-NPS-2008-Radius-Server/m-p/14392/highlight/true#M6113
Yes, been there, done that long time ago but these days the problem with that type of certificate is in clients not trusting it, so they have to ignore it. Or clients cannot validate it in good time because they have to be connected to the domain first, that's why such certs are not trusted. Catch 22 situation.
To confirm original problem, captive portal does increase CPU significantly no matter what authentication is used because clients just connect to it first as they see open network as preference. In an environment of approx 500-800 users within a campus and single controller, this will cause CPU to peak and once had caused loss of Internet service while clients still had wifi connection. Performance improved only by switching off captive portal, using SSID with radius instead.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.