Wireless Access

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 6.3.1.8 and CPPM 6.3.4.

 

#7220

hipzilla,

 

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.

If not the "sign in" pop-up I need the browser to at least properly redirect. Our "access" SSID leads to a captive portal for people with older devices as well as instructions on how to get onto our 802.1x SSID. We're a (large) community college with an almost non-existent helpdesk, so the captive portal with informational blurbs is a big deal for us.

hipzilla,

 

Are there any devices that it is not consistently redirecting for?  How many VLANs are in use for your Captive Portal Virtual AP?

 

 

Do all of your VLANs have an IP interface on the controller?

cjoseph - iOS and Windows devices all seem to redirect without issue. The captive portal assistant on iOS always triggers and W8/8.1 open IE automatically. W7 requires the user to open a browser manually but it does redirect.

cappalli - Yes, they do.

This really is an ease of access issue for our users. If I connect to our access SSID with my Nexus 5 and open Chrome (since I never get the sign in notification) I don't get redirected. I can manually punch in our captive portal address and move on but I can't expect the same of our end users.

hipzilla,

 

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:

 

 

config t

firewall allow-tri-session

 

 

http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/Firewall_Roles/Global_Firewall_Paramete.htm

 

 

 

 

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.

 

 

hipzilla,

 

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. :)

hipzilla,

 

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.

hipzilla,

 

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.

 

Name: Android

 

Position Type IP addr Mask-Len/Range
-------- ---- ------- --------------
1 name 0.0.0.4 ocsp.geotrust.com
2 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.

try blocking android.clients.google.com and see how it goes.

make sure the version is 4.x for android


Kind Regards,
Islam Hassan

The URL is   http://clients3.google.com/generate_204    http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection

Gr8 thanks Colin for finding the urls.

Kind Regards,
Islam Hassan

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

Can you show us the output of “show rights ”?

And then any ACLs that are in that user role?

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 data
Check your Windows Host File
Remove Proxy
Flush DNS and reset TCP/IP
Run Chrome Cleanup Tool