ISE Captive portal redirection to customer's predefined URL doesn't work on Android mobile

[AndrejJ]

Hi, our customer is having problem with ISE captive portal redirection to custom URL after authentication on Android. The reason is once cell phone with Android connects to SSID it automatically pop-up window (pseudo-browse probably) with captive portal which asks for credentials. Once you put correct credentials authentication is done and window with captive portal disappears and no redirection happens. This works completely fine with other OSes as Windows Mobile or iOS which after connecting to SSID open standard browser with captive portal, goes through authentication and once you're successfully authenticated it redirect you to customer's predefined URL address. I have found that behaviour on Android might be correct as stated in ISE CWA and Hotspot Flows config guide: "For endpoints where the CNA launches a pseudo-browser, this may break the flow when redirected to an ISE captive portal. This typically affect Apple IOS devices and it has especially negative effects in flows that require device registration, VLAN DHCP-Rlease, compliance check, etc." Did you have similar issue? Do we have any workaround or recommendation how to get the proper redirection to customer's defined URL after authentication through captive portal on Android mobile device? Any advice will help. Thanks!

[Jason Kunst · Accepted solution]

Well it can be expected if the auto pop browser is gone that you can’t redirect them correct? Not something ISE can resolved.

It sounds like you have your wireless controller set for bypassing captive portal? SO you’re suppressing Apple device Captive Network Assistant? And that’s why its not a problem?

Are you using wireless controller code that supports URL based ACL? Try open up android site to suppress the minibrowser

clients3.google.com

http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection

Shill, the connection manager for Chromium OS, attempts to detect services that are within a captive portal whenever a service transitions to the ready state. This determination of being in a captive portal or being online is done by attempting to retrieve the webpage http://clients3.google.com/generate_204. This well known URL is known to return an empty page with an HTTP status 204. If for any reason the web page is not returned, or an HTTP response other than 204 is received, then shill marks the service as being in the portal state.

[PulkitMittal4180]

Facing similar issue

[Jason Kunst]

I'd suggest open a tac case to investigate this as well. Or send them to success page and give them a message there that they will need to click on to go to the customer site. Nothing really we can do technically here as workaround but will check to see if any scripting can be done but unlikely

[PulkitMittal4180]

Hi Jason,
We have tried using the link on the success page, however, the success page only loads for 2-3 seconds and even if I manage to click the link on the success page, the mini browser closes by the time it tries to load the redirected landing page.
I have opened another thread because it seems the accepted solution on this thread doesn't really work for us.

[PulkitMittal4180]

This is very specific to android version as well as vendor. Android 9 seems to have no default server variable in the code.
http://androidxref.com/9.0.0_r3/xref/frameworks/base/packages/CarrierDefaultApp/src/com/android/carrierdefaultapp/CaptivePortalLoginActivity.java
as that compared to android 6. (private static final String DEFAULT_SERVER = "connectivitycheck.gstatic.com")
http://androidxref.com/6.0.0_r1/xref/frameworks/base/packages/CaptivePortalLogin/src/com/android/captiveportallogin/CaptivePortalLoginActivity.java

I have also seen vendor specific URLs for MI, Xiomi, etc.

[howon]

One can use ACL to achieve what the original poster wants. Create an ACL that does not allow endpoint to access the captive portal detection sites such as “connectivitycheck.gstatic.com” but allows everything else. When guest user authenticates, instead of sending back simple permit access, also send this ACL so the captive portal detection thinks it is still in captive portal state. It would be easier to achieve this using URL ACL instead of IP ACL.

[PulkitMittal4180]

We have tried to suppress the android mini browser using URL ACL list as below:

clients3.google.com
clients1.google.com
connectivitycheck.gstatic.com
connectivitycheck.android.com

However, these are very specific to device manufacturers as well as different android version and not able to achieve the target. Please refer the latest discussion for similar issue, at this link.

[howon]

I think you have a point, but above suggestion is not to suppress mini browser, rather to keep it open post authentication.

[PulkitMittal4180]

Got you, but the problem is getting the list of all detection sites, like “connectivitycheck.gstatic.com” as android is open source and different vendors have different detection URLs. Android 9 does not have a static variable for default server. Refer to one of my posts on above. It is not just the android versions, but also vendors like MI, Xiomi, etc.

[howon]

I would suggest targeting 10 to 20 most used devices and find out what the detection addresses are. It may not be as many as most thinks. I can see certain vendors use and maintain their own sites, but most may use the default Android site.

[PulkitMittal4180]

Hard to tell when it comes to Android 9 as most of the android are using this version at the moment, I couldn't locate the address in the code at http://androidxref.com/9.0.0_r3/xref/frameworks/base/packages/CarrierDefaultApp/src/com/android/carrierdefaultapp/CaptivePortalLoginActivity.java
I hope in future, ISE can control the way captive portal opens and closes on android devices, as it is open source. check this out https://android.stackexchange.com/questions/186993/captive-portal-parameters/186995

[Jason Kunst]

I’m wondering how you’d ever make the browser go away if you’re blocking all sites? There is no COA after success

[PulkitMittal4180]

Not sure of the Post Auth, but my workaround was to allow the URLs before COA, that suppresses the mini browser, so that users can just use default one. After success, it is not possible, you are right.

[Jason Kunst]

---

@howon wrote:

I think you have a point, but above suggestion is not to suppress mini browser, rather to keep it open post authentication.

---

I don't see that working as it would never go away. Best is to suppress permanently so all the flows work pre and post auth