14

So the simple idea is that we have a RADIUS server setup to allow users to authenticate with our Ruckus controller via user credentials. On authentication the user should be redirected to a page that allows them to manage MAC authenticated devices.

On everything we have tested so far, including "older" Android devices this seems to be no issue and things run as they should. However with Lollipop (5.0+) versions of Android the captive portal has changed quite a bit, and part of that change is to automatically close the captive portal that launches when you join the network. Because we want them to be redirected to a MAC device management page after authentication so they can add the device they currently logged in with and avoid having to log in again, this is bad.

What I have tried:

  1. Detecting if the browser is being launched in a mobile device and popping an alert in onbeforeunload that attempts to keep the browser open.

  2. Opening a new browser window, pointing to the redirection URL, when successful authentication is detected (essentially managing the redirect ourselves).

  3. Performing Option 2, and then Option 1 on the redirected URL

What won't work:

  • Asking users to disable the captive portal option on their device. Not trying to point general users to advanced controls.

  • Creating an open network to access the MAC manager, it must be behind some authentication.

Solution For Now:

We are unhappy with this solution, but for now we are simply asking users to authenticate with the network and then open their browser and go to the basic login portal page (non-network authentication) that users use to manually add devices they can't connect with (like printers, gaming devices, etc.). Though this works, it is a pain for users to have to login, open a browser, manually enter a url, and login again.

This isn't a problem that people haven't run into, see here, I just haven't been able to find a solution from anyone that has run into the problem. Certainly there is some way of utilizing javascript or something to keep the browser open in this situation. If not, anyone have any better ideas for managing things?

Dharman
  • 30,962
  • 25
  • 85
  • 135
zgc7009
  • 3,371
  • 5
  • 22
  • 34
  • 1
    Did you find a solution ? I'm looking for the same behaviour – M to the K Feb 26 '16 at 11:11
  • @MtotheK no luck as of yet. I will update with an answer if I find one, if you could keep us SO folk posted if you find something on your end it would be appreciated. Frustrating for sure. – zgc7009 Mar 02 '16 at 16:19
  • @zgc7009 any luck with this issue? – Camilo Aguilar Jul 22 '16 at 17:32
  • @CamiloAguilar unfortunately not. Google is aware of the functionality, know that people that need redirects aren't happy, and still see it as intended functionality. They provide very little control over the process in general it seems. – zgc7009 Jul 23 '16 at 16:23
  • managed to solve this, by firewalling off the connectivity checks post authentication, and reverse proxing in the 204 when we need it to close. check my answer in the thread. – Johann Combrink Jun 05 '17 at 09:12
  • I am using TPlink EAP 225 for captive portal with external portal authentication. I have the same problem when user login via captive browser it closes the browser after authentication. Did you find a solution? – Syed Faisal Jun 11 '20 at 08:23

3 Answers3

12

We have managed to keep the UAM Browser / captive portal browser open on lollipop by adding firewall rules blocking :

  • clients3.google.com
  • clients1.google.com ,
  • android.clients.google.com
  • connectivitycheck.android.com
  • connectivitycheck.gstatic.com

Thus after the user is authenticated the UAM / Captive Browser stays open.

You can keep UAM open as long as you need, you can close it by invoking a reverse proxied 204 redirect to google's connectivity page.

Johann Combrink
  • 692
  • 8
  • 18
  • Hi, could you elaborate on this? I'm trying to do this on OPNsense. If you block these domains the connection will be interpreted as with no internet right? And until you unlock them it will stay open. Did it get it right. I don't understand what you mean by a reverse proxied 204 redirect... – Sandro Antonucci Nov 03 '17 at 17:17
  • you need to block them on the "authed" side of the network, not the captivated part. – Johann Combrink Nov 06 '17 at 11:59
  • can we move this to chat? – Sandro Antonucci Nov 08 '17 at 10:28
  • how can we make the reverse proxied 204? Thanks! – Cristiano Sarmento Feb 15 '18 at 17:06
  • Hi @JohannCombrink, How can we reverse proxied 204, I have a captive portal configured on tplink EAP device using an external portal page with radius server authentication. Can you please guide me on how I can implement reverse proxied 204? Thanks – Syed Faisal Jun 29 '20 at 13:20
  • window.location = "http://connectivitycheck.gstatic.com/generate_204" from my Captive page will close the current page? We found it worked in some cases and some end up getting 200 response instead of 204. Hence, our Captive page is not closing in such cases. Also, observed "connection: close" header in success cases but we are unsure how to force such header from Javascript mentioned above. – Karthick Jayaraman Jul 21 '20 at 12:03
  • maybe checkout https://wiki.squid-cache.org/SquidFaq/ContentAdaptation – Johann Combrink Jul 21 '20 at 13:34
  • This worked well on Cisco Meraki. @DominikVogt comment was also needed. – skidadon Nov 01 '20 at 05:04
  • @skidadon I am looking at how to do this with Cisco Meraki - care to expand on what worked for you? – dunxd Sep 12 '21 at 12:09
3

This appears to be new Captive Portal behavior in Android devices since the release of Lollipop (5.0).

We have not yet discovered a workaround. If there is an explicit way to disable the auto-dismissal it is probably only documented in the Android codebase available here (I've been looking, but haven't found anything definitive yet):

https://android.googlesource.com/platform/frameworks/base

FYI, we've also noticed Android uses CloudFront CDN for its captive network detection. Our captive portal solution originally used CloudFront for assets, so we had to whitelist CloudFront subnets in pre-auth ACLs. Whitelisting CloudFront subsequently caused captive network detection to fail on recent Android devices. We had to abandon CloudFront CDN to restore captive portal functionality for Android devices.

derekm
  • 429
  • 1
  • 4
  • 12
  • Thanks for the detailed response. This is certainly a headache, we keep coming back to it hoping we, Google, or someone else has come up with a solution for the problem and it just doesn't seem like anything is even moving in that direction. It isn't _that_ uncommon for redirects to be an important part of hotspotting, it is weird to me that this "issue" has been allowed to linger without at least an explanation as to why. – zgc7009 Jun 08 '16 at 14:37
  • We've found a solution where, for the time being, we're changing when we redirect to the controller to authenticate the client to move them from the pre-auth ACL to the full access ACL until they explicitly click a "Browse the Internet" button. This solution requires our clients to whitelist all external resources they use in their welcome page banner ads and landing URLs. – derekm Jun 08 '16 at 21:18
  • We've identified and tested a second solution where we could whitelist Android's connectivitycheck.gstatic.com IP (w/ hostname-to-IP resolution monitoring to update whitelists on IP assignment changes). This causes Android devices to fallback to DNS-redirect-like captive methods. This solution also requires our clients to whitelist all external resources they use in their welcome page banner ads and landing URLs. – derekm Jun 08 '16 at 21:18
  • We have a client in Syndey that is working with Cisco to identify a better way to recapture the Android audience, perhaps by enchancing Cisco's captive-bypass feature. The second solution above is similar to an Android-only captive-bypass. We're provisionally opting for the first solution because it gives basically the same experience for Android and iOS (where Android captive browser disappears after clicking "Browse the Internet", while iOS captive browser does not). – derekm Jun 08 '16 at 21:21
  • 1
    So we have a matrix of solutions that come with various trade-offs and responsibilities. I can edit the above answer to better describe the scenarios. Recapture options: 1) delay ACL-upgrade controller redirects until they click some bottom-of-page "browse Internet" button; 2) whitelist Android captive network detection URLs for Android-only fallback to DNS-redirect-like captive methods; 3) use something like Cisco's captive-bypass for DNS-redirect-like methods on all devices. Whitelist options: 1) whitelist external ad resources, blacklist all else; 2) blacklist top sites, whitelist all else. – derekm Jun 08 '16 at 21:32
  • 1
    If you wouldn't mind outlining those in the answer as a guide for others, it would be appreciated. While it doesn't solve our problem exactly, it is certainly better than the *shrug* answer I have been able to give people to this point. – zgc7009 Jun 10 '16 at 12:38
  • I managed to get a working solution, firewall the connectivity checks, and reverse proxy to the 204 check to close it, see my answer in the thread – Johann Combrink Jun 05 '17 at 08:28
0

Why don't you just hold captive portal opened after authentication? You can always allow access to every site except captive checking sites.

Tested and working both Android and iOS in all versions. If you need to access cookies/shared storage from default browser (not captive ios/android sandboxed browser), you gotta hop out it before authentication.

lukyer
  • 7,595
  • 3
  • 37
  • 31
  • 2
    My question is _how_ do you hold it open. The OS automatically closes the captive portal after authentication. – zgc7009 Aug 30 '16 at 13:10
  • cite: "You can always allow access to every site except captive checking sites." – lukyer Aug 30 '16 at 13:11
  • That would essentially be an open network. We need the captive portal to trigger any time the user connects to the network. We aren't whitelisting. Thank you for your input though. – zgc7009 Aug 30 '16 at 15:54
  • I mean after authentication, of course. Sorry for misunderstanding. Our flow: user connects to the wifi, captive portal is shown, user chooses authentication method, internet access is allowed, user follows ad/link/ in captive, user closes captive whenever he/she wants. – lukyer Aug 31 '16 at 08:28
  • The problem we are having is that as soon as the user is authenticated the captive portal closes. There is no way to continue on within the captive portal once there is authentication, it won't stay open. If you are able to keep it open please let us know how. Whitelisting won't keep the portal open, it will simply allow the user to browse without authentication, at least to the best of my knowledge. – zgc7009 Aug 31 '16 at 13:08
  • I think that @lukyer means to disable captive "internet detection" method but that would keep it open in annoying way, though is a good alternative. Furthermore, what I've done in the past is to show an special web on captive asking the user to navigate through other browser like Chrome, or Safari saying that "This page needs special features". – Camilo Jan 16 '17 at 18:23
  • You can keep UAM open as long as you need by firewalling off the connectivity check urls, you can close it by invoking a reverse proxied 204 redirect to google's page, see my answer in the thread. – Johann Combrink Jun 05 '17 at 08:27