Join us for a month-long contest with heaps of swag to win!Learn More ›
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.
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.
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:
I know that on Cisco WLC you can use the WebAuth feature so that the controller can redirect HTTPS traffic:
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,
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.
My main issue is actually with Apple devices (both macOS and iOS) so I can safely say they are affected too.
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.
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.
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.
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.
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.
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.
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.