topic Re: Captive portal does not work with https! in Wireless

Captive portal does not work with https!

Corsani — Tue, 27 Oct 2020 14:41:30 GMT

I have a cisco meraki AP infrastructure. I defined an SSID with radius authentication and a walled garden. Everything was ok until the web-world migrate to https. That's the problem:

- the domani www.bing.com is not in the walled garden;
- http://www.bing.com correctly redirect the user to the login splash page to authenticate the user;
- https://www.bing.com does nothing and the browser got time out;

Asking to meraki they said that can't works because: "Meraki devices are not able to decrypt. This is why it's working fine with http (no encryption) but not with https (encryption)".

But...

- if I put the domain www.bing.com in the walled garden;

- https://www.bing.com works!

Why? I'm not an expert but seems to me that meraki can detect the url the user ask for, to check the walled garden. Isn't it? Why if the domain is not in walled garden, meraki won't redirect to the login splash page even if it's in https? Let me understand, please, why if a request is out of walled garden, meraki won't redirect to splash login page regardless of http or https.

Re: Captive portal does not work with https!

BRUCE NEWTON — Tue, 27 Oct 2020 21:57:42 GMT

Hi @Corsani, this is to do with the way the browser handles HTTPS sites. When you put something in the walled garden then Meraki allows access to it before the user has authenticated, so it just passes the traffic straight to the site. This is exactly the same for whether you're accessing an HTTP or HTTPS site. It's just as if the Meraki didn't exist - hence why it works.

In the scenario where you are trying to authenticate you need to think about what is happening (this is going to be a pretty high-level explanation, but should help you to understand it). In the case of an HTTPS request you're asking to fetch a page from bing.com using an encrypted connection - that's what starting the URL with HTTPS means. So your browser goes out to get the public certificate from bing.com to encrypt the connection. However, at this point the Meraki device intercepts it and can't do anything. It could pass back the bing.com public certificate, but then it doesn't have the private key so can't encrypt/decrypt the messages. Or it could pass back its own certificate and become a 'man-in-the-middle', but then the browser will generate all sorts of errors because the certificate name won't match the website name (i.e. bing.com). And this is where the problem lies, there is no easy way to do web-based authentication for HTTPS based sites. The user needs to first go to a HTTP (unencrypted) site to authenticate successfully, and then once that's happened all should be good.

Re: Captive portal does not work with https!

RonW1 — Thu, 29 Oct 2020 21:02:50 GMT

I have been telling my users to go to neverssl.com to log in. Do you have any HTTP sites that you tell them to hit to see the authentication page?

I know this isn't a Meraki thing but an Internet thing about how https is designed to work.

Re: Captive portal does not work with https!

Karsten Iwen — Thu, 29 Oct 2020 21:11:15 GMT

I also use example.com, example.net etc. when I know I have to go to a captive portal.

Luckily, modern operating-systems have captive-portal detection which always uses HTTP. In the future a new DHCP-option will be used to find the captive portal.

Re: Captive portal does not work with https!

Corsani — Fri, 30 Oct 2020 12:25:46 GMT

My library has some free pc access. We give users: firefox, chrome and edge. Firefox can detect the captive portal and suggest, in a bar, to login - no ones watch it! - the other browser don't.

As you can immagine I give to users our web page, that is free. Only when user want to get out the walld garden they should authenticate themselves. Users can't understand such "trick": using http://www.bing.com rather than https://www.bing.com. They normaly use google as internet. That's it! And google gives back only https link. And nothing works. And user call us that nothing works.

That is very annoying!

Re: Captive portal does not work with https!

Corsani — Fri, 30 Oct 2020 12:29:41 GMT

Normally I have 500 users a day! Not now under covid situation. But normally I have such numbers, most

of them use their own laptop with wahtever configuration.

Re: Captive portal does not work with https!

lpdelacruz — Sun, 03 Jan 2021 05:17:43 GMT

Good day! I am also encountering this issue using Google as authentication. It was working fine recently then our end-user reported that the redirect to google splash page is not working on mobile devices. Is there any solution to this other than instructing their users to go to an HTTP site first since most of their users are not tech-savvy.

Re: Captive portal does not work with https!

JohnT1 — Fri, 19 Aug 2022 20:52:58 GMT

I'm dealing with this right now and I'm not actually sure how to handle this. We use the splash page on our guest network so the guests can accept the terms of service. It seems that I have three options. 1) Allow non-HTTP traffic and allow guest users to bypass our network firewall rules. 2) Block all access to the network until the splash page is clicked. Knowing that half of the guest users will just time out because they are accessing HTTPS. 3) Turn off the splash page and just have an open network with no terms of service

I've opened a ticket with Meraki support and I'm not sure they even understand what I'm talking about. The Meraki documentation clearly states that what we are experiencing is as designed. https://documentation.meraki.com/MR/MR_Splash_Page/Enabling_Click-through_splash-page

Curious, how are you all handling your guest network portals?

Re: Captive portal does not work with https!

CMR — Tue, 23 Aug 2022 23:45:50 GMT

We took over a site that had option 1 and the odd thing is, for pretty much every device it does make you click through the portal... However we changed to option 2 as that seemed better and we found Android devices seemed fine, but Apple devices had issues. We're not sure of the best way forward either!

Re: Captive portal does not work with https!

BlakeRichardson — Thu, 15 Jun 2023 02:37:12 GMT

@CMR did you ever find a solution for this. I am about to have this issue with wired devices. Wireless devices aren't a problem as they look for a captive portal on their own.

Re: Captive portal does not work with https!

CMR — Thu, 15 Jun 2023 06:33:01 GMT

We now have option 2 with a walled garden that has about 10 domains in to let them get the splash page, so that they can then get out!

Re: Captive portal does not work with https!

DainBrammage — Mon, 19 Jun 2023 12:13:18 GMT

This is expected behavior. The recognition of a captive portal is up to the browser/OS that is being used. Has been this way for many many years. WBA has a good rundown on what does what.

https://captivebehavior.wballiance.com/

Re: Captive portal does not work with https!

JohnT1 — Wed, 28 Jun 2023 00:58:28 GMT

The design spec is solid, but in practicality it doesn't seem work properly which is the problem. If I turn on "Block all access until sign-on is complete", I will start getting calls from our employees that their personal devices and customer devices can't surf the Internet on guest Wi-Fi. In theory, the phones should reach out to an HTTP url and redirect to the portal, but some devices just don't behave properly. So, I either get lots of support tickets, or I allow non-HTTP traffic prior to sign in. Neither option is good.

Re: Captive portal does not work with https!

DainBrammage — Wed, 28 Jun 2023 21:54:51 GMT

Block all access until sign on is complete is fine and works great. the doc from the WBA lays it all out and it does work. That is not to say that an end user will not have issues with their device from time to time due to whatever reason but in 99.9% of those cases it is not the AP or the RF. It starts with end user education about how your wireless environment operates.

Re: Captive portal does not work with https!

Nolan H. — Sun, 08 Dec 2024 19:40:18 GMT

Hey @CMR - I know this is somewhat old but I'm actually possibly running into this issue myself using OPTION 2 and what I believe are possibly older iPhone devices. It's a hit or miss situation, sometimes they struggle, most of the times clients don't. Again I suspect it's just old iOS devices. What list did you end up putting in? I did a pcap with an old and new iPad but both seem to be showing similar resolutions for DNS queries prior to clicking the accept button to get past the walled garden.

captive.apple.com
captive-cidr.origin-apple.com.akadns.net
captive-cdn.origin-apple.com.akadns.net
captive.g.aaplimg.com