Splash page not showing automatically

[Jonas]

Hi!

I am running a wifi network for about 1200 users using a splash page with active directory authentication, and I am often experiencing issues with the splash page not automatically showing when an authentication is required. This happens both with new users and users who simply need to re-authenticate when the authentication times out after 30 days. This issue affects roughly 5-10 % of my users (might be a little less) every 30 days. I dont necessarily hear about the issue all the time as I'm sure they are learning from each other to work around the issue, but my team  and I definitely help out quite a few getting authenticated on our wifi.

I don't wanna start bashing Apple devices just yet as I'm not 100 % sure I remember seeing this issue on other systems, but lately it has only been Apple devices (iPhones, MacBooks).

The workaround is to visit a website that the user has not visited in a while (or never) on their device(s), and then the splash page will show just fine and the user can sign in. I have seen this happen on both laptops and smartphones.

I have looked far and wide online and in this community, but I haven't been able to find anything that fit my description. I have only found one possible explanation to this and that was in the thread below, but that mainly refers to Guest networks.
https://community.meraki.com/t5/Wireless-LAN/Splash-page-does-not-pop-up-on-IOS-Apple-devices-automa...

Has anyone else had this issue, and is there a proper solution available?

I'm sure a lot more information is required to troubleshoot the issue, so I will be ready to answer them.

Best,

Jonas

[nwu1]

Hi Jonas,

I would recommend possibly replicating this issue on a few wireless test devices, systemically on iPhones, Macbooks, Windows laptops and Android. During the authentication, take a packet capture from the MR on it's wired and wireless interface, and take a look at the URL (http) redirects.

This is a good flow of the mechanism:

https://documentation.meraki.com/MR/Splash_Page/Splash_Page_Traffic_Flow_and_Troubleshooting#Splash_...

Cheers,

Nick

[Jonas]

Hi Nick,

Thank you very much for your input!

After some testing and a look at the referenced documentation, it seems the main issue here is that the unauthorized devices are not redirected to the splash page when accessing HTTPS websites. As far as I understand its because the AP cant redirect the device due to the HTTPS traffic being encrypted.
I dont really like the idea of allowing non-HTTP traffic on our network without users signing in, as that defeats the whole purpose of a splash page.
I dont know if I am misunderstanding something here, but it seems like quite a flaw that the splash page cant "handle" the HTTPS requests.

[nwu1]

Hey Jonas,

I know that on Cisco WLC you can use the WebAuth feature so that the controller can redirect HTTPS traffic:

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/115951-web-auth-wlc-guide...

The limitation on the MR can be addressed by using a web proxy on the network and decrypting it, but that would require additional hardware/software. 

Hope it helps,

Nick

[Nolan]

I don't know if "flaw" is the right word because that is the purpose of HTTPS and working as intended but it does present quite the hurdle to get around. I'm having the same issue in my environment. Mainly with windows devices, I don't know the details of how iOS, android, and chrome devices handle the request differently but they must send out some type of HTTP request or something similar because they tend to get the splash page every time. The windows devices you have to tell someone to go to an http site which is sometimes a challenge for the user.

[Jonas]

Hi Nolan,

My main issue is actually with Apple devices (both macOS and iOS) so I can safely say they are affected too.

/Jonas

[JVandermark]

im having the same issue i think. Is your eula page an https site, or the redirect isnt working when the homepage is an https site? it seems flawed to me to that its trying to detect the traffic type to determine if a eula is needed and not just throwing the eula when any traffic is detected.

[Nolan]

The issue is the AP will only detect HTTP traffic for the redirect to the splash page. If it's HTTPS traffic it's encrypted and the AP can't look into the traffic and trigger the redirect. At least that's how I understand it from what I've read. So the client has to browse to an HTTP site for the splash page to display.

To me it seemed that iOS and Android had a way of handling this, I'm not sure of the details. May they throw out a HTTP request when they connect to the AP? But they normally display the splash page. Mainly our windows clients (we dont' have any Mac OS in our environment) have the issue where the splash page doesn't display until they specifically browse to an HTTP site. We have some Chromebooks out there but they normally don't have much of an issue.

[Jonas]

Hi Nolan,

You are definitely reading my post right.

This does not seem to be a device specific issue, but I have recently talked to a Meraki System Engineer when I attended a Meraki workshop, and she promised to get back to me soon with an update when she got a chance to talk to a colleague.

[jamesw]

Hi Jonas

Yeah, when you connect to the SSID the Apple device should automatically fire a HTTP request to an apple URL to detect if its in a captive portal or not. If it is, i.e. it cannot reach this URL, it should automatically popup the CNA and redirect to your configured splash URL. If this isn't happening then first ensure you haven't got any apple based domains in your Walled Garden and that Auto-Join and Auto-Login is enabled on the iOS device itself, under the SSID settings.

Thanks

James

Purple

https://purple.ai

[Jonas]

Hi James,

Thank you for you input!

The thing is if you browse to an HTTPS specific site the HTTP-GET request wont trigger the splash page to appear. This happens with all types of devices. Browsing to websites that use both HTTP and HTTPS protocols the splash page triggers normally as it successfully gets a response from the HTTP-GET request.

An example is I have never been able to trigger the splash page using google.com, and I am pretty sure its because they only use the HTTPS - i dont have any documentation for it, but given Google's security stand on the market it seems logic.

[jamesw]

Hi Jonas

You are correct.

If you manually open a browser and try to browse to a URL that starts with https:// (or a site that only uses https://) - then the AP cannot redirect you to the splash page, because it cannot intercept the traffic. Therefore, it will time out. To reach the splash page, you have to navigate to a http:// site. I understand this is difficult to have users understand and they will typically just try and search Google from their browser, which will also fail as Google use https:// also.

This isn't a Meraki thing, it's an industry standard problem with captive portals and https (SSL). If you try the same on another make of AP you'll see the same behaviour. It's just the way it is I'm afraid. Some AP manufactures try to intercept the https:// request, but this IMO is worse because it then throws a big SSL warning/error page to the user saying the Certificate is invalid any your session might be hijacked (man in the middle warning). this happens because the SSL certificate provided is not the real one, but one provided by the AP and of course the host name on the certificate does not match.

But, the issue here is that you shouldn't get to a position where you need to open a browser and visit a http site. You should automatically get the CNA popup which will then correctly show the splash page on the device.

P.S. There is no problem hosting your splash page on https:// - because the splash URL is in your allowed Walled garden list, so that traffic CAN reach the real site.

The CNA check on iOS/Android/Windows etc is always a http:// request by the way,otherwise that would fail.

Thanks

James

https://purple.ai

[Jonas]

You are absolutely right and I understand that its technically working as intended. However its really bugging me that there seems to be no actual solution that supports this behavior as I really like the authentication part of the splash page.

As I just replied to Nolan, I am in contact with a System Engineer at Meraki that hopefully can bring some insight to this matter. Whatever I get from her I will make sure to keep this thread updated.

Thanks again!

[Nolan]

In my experience it's just that some devices handle it better than others. As James was saying if the device sends out an HTTP request to probe for the splash page then all works as it should with no issues. This seems to happen pretty much everytime on Apple iOS devices and Android OS devices. Very rarely do I see issues on the Chromebook we have in our environment. Windows tends to be the worse offender in my experience. I seem to quite often have issues with windows devices and you have to require the user to type in a HTTP site that don't be redirected to HTTPS.

I personally don't see a technical solution coming from Meraki since there isn't anything technically wrong, but it does present a problem that we have to figure out how the proper way to handle it is. I started a discussion about this issues I'm seeing on a different tread https://community.meraki.com/t5/Wireless-LAN/Getting-the-splash-page-to-load-on-a-Windows-device/m-p...

Someone posted on there and made me aware of a site I didn't know about previously, http://neverssl.com. So now I'm using that as a site to direct users to if they need to make sure they are prompting the AP to display the splash page.

[paolo]

a

[sergio2]

Hello friends, I have the same problem, I automatically redirected to the page https://www.msn.com/es-cl/?ocid=wispr&pc=u477&AR=1. You tried to force redirect to an http page like http://neverssl.com, but it still doesn't work.
I would like to know if to date, You have had any solution, Thank you.

[Jonas]

Hi Sergio,

I am not forcing any redirects in the dashboard or splash page, but I am simply telling the users to navigate to the website http://neverssl.com upon connecting to the SSID if the splash page fails to load automatically for them.

Most new OS versions (both windows and mac) automatically checks with an http -based website when connecting to a splash page wifi option, so we are rarely having this issue now. Unfortunately I do not have any permanent solution, but to keep the neverssl.com website in mind for the users.

[NatJoo]

Has anyone found a workaround for this?

I will not post signs in my lobby to say please navigate to http://neverssl.com to initiate our splash page.  Also will not check the box to allow non-http prior to sign on and then get a random seaming splash page half way through the browsing session if they happen to come across an http site.  I under stand the difficulty from the technology side, but they options are unacceptable for the non-tech person and we have disabled the splash page until this can be corrected.

[Jonas]

Hi NatJoo,

No unfortunately not that I know of. We dont encounter the issue too often any more, so we dont include it in our signs on our premises, but we use the workaround with neverssl when users reach out and we also have it included in our knowledge base.

/Jonas

[NatJoo]

For us it consistently has a pretty significant delay.  Usually 30 seconds to 3-4 minutes before getting the splash dialog.  If it doesn't appear in 5-10 seconds it is worthless for us.  We are a financial institution trying to provide wireless in our lobbies.  If it does not appear it is going to work, the members are going to move on and it will reflect on their opinion in our ability to implement technology.

[Pritam]

Hi,

Did anyone find any solution for this as neverssl.com does not as expected most of the time. This is serious and frustrating issue as there is no way to open the splash page. Please guide me if anyone has some work around.