I have a new IAP105, upgraded to latest firmware 184.108.40.206-220.127.116.11_39461. I've configured a guest ssid using the internal captive portal. clients get an IP from the controller, but opening a browser results in a redirect loop. Currently set as basic as possible - IP address is VC-assigned, no access restrictions. Any thoughts on resolving this issue?
check that DNS is working. non working DNS has caused this problem for me in the past.
Interesting... I am using my provider's DNS. Wonder if it tries to do dns lookup using the native IP of the client rather than the VC's IP address.
Another interesting bit is that if I change the URL on the client from https://securelogin.arubanetworks.com to http://securelogin.arubanetworks.com, it goes to the captive portal without any problems. The cert on the AP seems to be good, but this is starting to seem like a cert issue of some sort.
hmmm.. more interesting stuff - works perfectly on an ipad, so seems to be windows-related at this point.
windows 7 seems good also. narrowing this down to a windows xp issue.
John, I've seen this occur with certain configurations, but generally only eith external captive portals. Out of curiosity, is auto whitelist enabled?
This is probably related the the homepage the user has set in their browser. A lot of properties such as Facebook and Google automatically redirect users to the HTTPS version.
Assuming the client has their browser homepage set to google.com or facebook.com, the following would happen:
- client associates to the network
- client launches browser to an HTTP page which returns a 302 redirect to its HTTPS equivalent (example: http://google.com and http://facebook.com, which now redirects all users to https://google.com and https://facebook.com by default).
- client reaches the http://google.com servers (due to auto whitelisting), which returns a 302 redirect to https://google.com.
- client follows the 302 and attempts to access https://google.com.
- IAP intercepts the connection, spoofs the SSL certificate and redirects client to http://google.com. This "spoof SSL and redirect to non-SSL" behavior appears to be expected, and is how you intercept outbound HTTPS requests for portaling.
- client reaches the http://google.com servers (due to auto whitelisting), which returns a 302 redirect to https://google.com
There are some forthcoming enhancements planned for a future release of IAP code that will bring some modification to how IAP handles external captive-portal and https sites. Stay tuned for the announcement!
I'll take a look at the auto-whitelist feature. Odd that this just seems to happen with WinXP devices. Apple IOS and Windows 7 get redirected correctly to https://securelogin.arubanetworks.com. On WinXP, if I use Firefox, I can manually change the redirect from https to http and then the captive portal comes up and I can enter login credentials. IE and Chrome don't display the redirected URL.
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.