Splash Page redirect limited to "GET HTTP 80" detection

Solved
Gedanken_leben
Here to help

Splash Page redirect limited to "GET HTTP 80" detection

Hello there, I am reading up for the ECMS Certification.

The linked article https://documentation.meraki.com/MR/MR_Splash_Page/Splash_Page_Details_for_Meraki_MR has the following note after describing the considerations of the click through splash page.

 

Note: The AP looks for HTTP GET requests on TCP port 80 in order to redirect users to the Splash page. If Block all access until sign-on is complete is enabled for the Captive Portal Strength, and the user attempts to access a web page that uses HTTPS, the AP will be unable to redirect the browser to the Splash page because the web traffic is encrypted. Additionally, if the user attempts the access a web page that uses a different port other than TCP port 80 the connection will also be blocked. In either case, the user's browser will timeout. If this is occurring, verify users are accessing a web page using HTTP over TCP port 80.  

 

I wanted to ask if the limitation of only detecting a HTTP request on port 80 is still the case. Is it really not possible to redirect HTTPS requests to the splash page? Article is listed as being updated on Aug 7th 2024.

 

 

1 Accepted Solution
PhilipDAth
Kind of a big deal
Kind of a big deal

It is usually not an issue these days because pretty much every platform has a built-in test to retrieve a special URL to determine whether it is behind a guest portal.

 

For example, Windows uses:
http://www.msftconnecttest.com/connecttest.txt

Apple uses:
http://captive.apple.com

 

There are also mechanisms like the "venue-info-url" that a device can use to get info about the captive portal it is attached to.

https://developer.android.com/about/versions/11/features/captive-portal

View solution in original post

4 Replies 4
cmr
Kind of a big deal
Kind of a big deal

Unfortunately it is indeed still the case.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
BlakeRichardson
Kind of a big deal
Kind of a big deal

This is due to how HTTPS works. Most modern browsers and OS have captive portal detection that should mitigate the issue in most cases. 

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
PhilipDAth
Kind of a big deal
Kind of a big deal

It is usually not an issue these days because pretty much every platform has a built-in test to retrieve a special URL to determine whether it is behind a guest portal.

 

For example, Windows uses:
http://www.msftconnecttest.com/connecttest.txt

Apple uses:
http://captive.apple.com

 

There are also mechanisms like the "venue-info-url" that a device can use to get info about the captive portal it is attached to.

https://developer.android.com/about/versions/11/features/captive-portal

Gedanken_leben
Here to help

Thank you to every one that took time to reply, very much appreciated. I learnt something that I would not have understood otherwise.

Marking @PhilipDAth as the solution purely because anyone else reading this thread in the future will benefit from the links.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels