I'm starting to get more and more people using our new Aruba wireless deployment and in turn lots of new devices/variants are going through the process and exposing bugs to me. The latest seems to be specifically on Android devices.
There seems to be a 50/50 chance that when a user connects to our "access" SSID tha they receive the "Sign into WiFi" notification on their Android device. Beyond that, if they open Chrome and try to browse to a different site (which would typically force them to hit the captive portal) they get what appears to be an SSL cert error. Other browsers allow them to bypass this error, but Chrome does not.
Have any of you seen something similar, and if so, how did you fix it? I've got a TAC case open and my engineer is researching the issue but I figured it wouldn't hurt to reach out here as well. For reference, we're using 7220 22.214.171.124 and CPPM 6.3.4.
Unfortunately, the technical requirement to have the "Sign in" popup appear is not documented. In addition, not all Android devices are capable of it. AKA....don't depend on it...
Long-Term solution: Deploy 802.1x so users do not have to sign in, at all. Many more helpdesk tickets are generated from Captive Portal networks than 802.1x networks, and the experience is better.
Are there any devices that it is not consistently redirecting for? How many VLANs are in use for your Captive Portal Virtual AP?
On that controller, please enable Firewall allow-tri-session. This is for when the controller is not the default gateway for clients in a Captive Portal configuration with multiple VLANs:
cjoseph - Reading the description of that setting leads me to believe that we may be going in the wrong direction with a fix. As stated, Apple iOS/OSX and Windows 7/8/8.1 are working fine. Certain versions of Android appear to break the captive portal redirect functionality. Those Android devices can punch in the captive portal address and log in like that or skip over to the 802.1x SSID (what most do). I think the attached screenshot is part of the problem.
The securelogin.arubanetworks.com cert that Aruba presents to Chrome generates an HSTS error and Chrome never redirects on that users phone/tablet.
Why don't you open a TAC case in parallel, since you can give them all of your information to get to the bottom of this.
We are just guessing here based on what information you can feed us.
I've got one open already, just polling the crowd here. Airheads have been super helpful with other issues I've run into. :)
Are all the devices ending up on the same VLAN or are you using VLAN pooling?
cjoseph - VLAN pooling is enabled. Devices get dropped in VLANs based on a) what set of access points they're connected to and b) what authentication source their username is found in.
To narrow down the issue, you should make sure that all users are dropped into the same VLAN and remove the complexity. That would make it easier to understand what is going on.
Can you show us the contents of the Android netdestination? Each vendor has a different connectivity check URL which is why the issue may appear sporadic.
clients3.google.com needs to be blocked in order for Chrome to treat rhe page like a captive portal (no cert error).Show netdestination Android
cjoseph - When I get into the office tomorrow I'll drop everyone into one VLAN and see if it helps.
cappalli - This netdestination was built by a TAC member in an attempt to get around the cert error.
Position Type IP addr Mask-Len/Range-------- ---- ------- --------------1 name 0.0.0.4 ocsp.geotrust.com2 name 0.0.0.5 *.geotrust.com
I'll block clients3.google.com when I'm onsite to see if it fixes the issue.
Again, I really appreciate you guys providing me with ideas to test!
Small inquiry, is the DNS address being received by the clients reachable and can resolve without any issue ? try from a laptop to do an nslookup and see if you will get the reply correctly.
client3.google.com is for any google app i think, android is using something similar to CNA from Apple to automatically open the browser for the user to sign in, it check specific websites or services as well and available in the new anrdoid versions only.
Islam Soliman - Yes, I can resolve client3.google.com from the initial logon role.
The URL is http://clients3.google.com/generate_204 http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
I added client3/clients3.google.com as well as clients.l.google.com (the returned name on nslookup) to a named destination and have it dropped in the initial logon role. It hasn't changed the situation unfortunately.
I really appreciate you guys spending your time trying to help me fix this. TAC said they were unable to reproduce this in their lab using my flaskbackups, but I should be doing more troubleshooting with them this week. If we come to a solid conclusion I will definitely follow up here.
I wish I knew what the solution was because I'm having the same issue...
Case number: 5315410296
cappalli - I attached the output in a text file. Formatting wasn't looking nice in this window.
When connecting to a website, if Google Chrome browser fails to fetch the website to the browser, it throws an error saying "This site can't be reached Error" – ERR_CONNECTION_TIMED_OUT. It means the server is taking too much time to replying. The main reason behind this error is your computer can’t be able to access the internet connection or maybe something blocking your network to establishing a connection. Apart from the Network issue, there can be multiple reasons why this error shows up. Before going to any fix, please make sure the server you want to open is exist. If server exist, there are numerous solutions which can be used to solve this error.
Clear your Chrome browsing dataCheck your Windows Host FileRemove ProxyFlush DNS and reset TCP/IPRun Chrome Cleanup Tool
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 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.