Running two 5508 controllers and have an open SSID that uses WebAuth.
This works great for laptops & iPads... It even used to work great for Android & iPhone.
But Android 1.6 and above and iPhone's new ios4 won't connect using this method.
You get connected to the wlan and get an IP, but when you open a web browser (redirects to https://188.8.131.52/login.html) the mobile device says the web page is not available.
I've read some Android forums that say this is a known issue (some have fixed it, others haven't).
Is there anyone that has run into this and found a workaround?
I have this very same issue and have not seen it addressed by Cisco or any clever WCS / WLC admin who has figured out the answer.
The only solutions I can find are of the "hack your phone" variety. I would not like to offer that as a solution to the general public user of my free wireless network. I am seeing more and more devices which are prone to this authentication / redirect problem, including Kindle, Barnes & Noble NOOK, and Nintendo PSP.
i have a guest WLAN using web-auth deployed and i can connect to it easily from my android device running version 2.2.i also have not heard any reports of iphone users having issues connecting.if your open WLANs work on certain versions and not on others then that will be really intriguing.
dhcp appearss to work fine but then failing to load the redirect login page suggests something is amiss there.
can you post some controller settings details and the output of a debug on the android/iphone client mac id?
Well my own device is Android 2.1-update1. we actually have very good luck with iPhones on our open WLAN. It's a group of Androids, and other "smaller" handhelds like the Nook reader and PSP game devices that are not accepting or following the controller redirect to the WebAuth login page ( http://mycontroller.mydomain.org/login.html - at ip address 184.108.40.206 )
However on the Android devices I am able to pass web authentication by directly getting http://220.127.116.11/login.html. This does not work on the NOOK device.
We have received a fair number of cases regarding concerns with handheld devices connecting to Web Authentication and Web Passthrough WLANs. By default, the WLC includes a self-signed SSL certificate for its internal web server. On a normal desktop browser, you will likely see a security warning informing the user that the SSL Cert is not validated against a root CA installed on the machine, however, these handhelds appear to just drop the page completely without warning.
One solution is to deploy a 3rd Party SSL Certificate on your WLC from a valid CA. This way, the handheld device will be able to validate the SSL cert against its pre-installed root certificates. Keep in mind that some earlier iPhone and Andriod OSs are missing some major root CA certificates (also causing the page failure). Bottom line is, make sure your Phone's OS is on the latest code.
If all else fails. Disable HTTPS globally on the WLC, and then all Web Policy users will authenticate/passthrough via the WLC's HTTP server instead, skipping the Certificate process altogether. Please keep in mind that disabling the HTTPS server on the WLC is a global setting, which will also disable HTTPS on the Web Admin (Web GUI).
Finally, if you find you're having issues with just the redirect, try it first with a laptop or notebook, then proceed to test your mobile device. If the mobile client can browse to https://18.104.22.168/login.html, then you likely have a DNS issue. Check the WLC's Virtual Interface Hostname, and verify that you have that same DNS A Record created on your DNS servers that the mobile device is querying.
For more information on troubleshooting the Web Authentication Re-direct, please take a look at the following document:
Troubleshooting Web Authentication on a Wireless LAN Controller (WLC):
Drew, Thanks for looking at this thread!
We have been running with a 3rd party certificate from a trusted valid CA for almost as long as we've had Cisco WCS deployed. So that solution is, effectively off the table. My Android default browser on this device actually likes the certificate just fine.
In fact, the only workaround I have for some devices is to manually open http://22.214.171.124/login.html ... but this doesn't work on the Barnes and Noble NOOK, and i'm not sure about the PSP. So, half a solution... but if I had to choose, I'd rather not have to instruct scores of users to enter the strange ip address url to get authenticated. This doesn't go over well with our users at the public library.
I'd also rather not pull back from using HTTPS, for reasons related to our users' mis-perceptions about wireless security.
The DNS for the virtual interfaces is also verified good. In fact I have been through each of these steps as outlined in the Troubleshooting Web Authentication document. All our clients have been working just fine with this "best practices" setup for a couple years. It is just the influx of new handhelds that is becoming a problem. Laptops and netbooks are all fine.
Please consider whether this could be considered a bug with the WCS web-auth system, as you yourself indicate you've been seeing a fair number of cases with handhelds.
I was a bit taken aback by the volume of individual user help messages I found on various cell provider and Android hardware forums, that pretty much ALL end up saying "they use a Cisco WLC system and the IT department won't do anything to fix it." I don't want to be that IT department. The Public Library can't afford to alienate the public!
Please let me know if there is any configuration file you'd like to see, or screen shots from my device... I want to help get this resolved if possible!
No problem at all! I agree, I too would like to see all devices using Web Authentication as expected. We run into these types of issues due to the rapid introduction of mobile devices into the wifi arena. Officially, we only support Firefox and IE for Web Authentication/Passthrough, however the same process should translate to multiple browsers, including these proprietary devices, such as the Nook.
Let's grab a Nook, and run the following debugs while connecting, and browsing to http://www.google.com:
debug pm ssh-appgw enable
debug pm ssh-tcp enable
If you have the ability to grab a wireless sniffer capture, that would be very helpful as well to better understand the Nook's behavior.
April 26th, 2013
We just opened up the subnet on our guest wifi network to a /23 subnet.
There is no encryption on it. Laptops and Iphones work.
But Andriod devices do not. I get an IP address but DNS times out. I can ping my gateway and 126.96.36.199, and the DNS server IP address is correct. But I can't ping google.com.
It really looks like something is up with the DNS response.
This seems to only effect my Android devices.
Anyone have any updates on this problem???
I just had a very interesting case here in the TAC with the Nook eReader. The device could not associate to a completely open WLAN (no authentication). After running wireless captures, we were able to discover that the device would stop sending packets once issued an IP Address on a /23 subnet (255.255.254.0). Once the subnet was changed to /24 (255.255.255.0), the device began sending Layer 3 packets as expected.
Thought this information may be beneficial to the community. Hopefully the makers of the Nook device will fix this in a future software release.
Im having the exact issue, most specifically the ipad. I plug in the PSK and then a "web auth" window automatically opens and I plug in my credentials. Then the window stays open with just a grey bar at the top with back and forward arrows. Works fine on android devices. Anyone seen similar?