I would change those settings now, as it is probably the reason you are having the issue to begin with.  See MrVench's reply below; Brave automatically redirects to https (Brave is Chromium based; it's not a stretch to think Chrome may be doing the same thing).  Your settings are currently allowing all non-HTTP traffic to pass through.  What's probably happening is this: FIREFOX: You make a request for http://escapessl.com/ and Firefox executes the request as you entered it.  Since your access control is set to block HTTP traffic, you get the redirect to the captive portal.   CHROME: You make a request for http://escapessl.com/ and Chrome automatically attempts to retrieve https://escapessl.com/ instead.  Since your access control allows non-HTTP traffic (like this HTTPS request), the request goes through and you get a 200 response (Success).   I can verify on my own system that when I attempt to go to http://escapessl.com/ on Chrome, it is bringing me to https://escapessl.com/. ... View more

"Allow non-HTTP traffic prior to sign-on "   I can almost guarantee this setting is what's causing that behavior.  If you're allowing non-http traffic, then you're allowing the vast majority of traffic that goes over the internet today (the fact that websites like neverssl.com and escapessl.com even exist is because most pages redirect to https, making these captive portal situations difficult). Turn it off and the issue should go away.  Keep in mind that if you do have outside authentication requirements, you might have to use a walled garden, which allows users to access certain specified domains prior to authenticating in order to allow them to get to the authentication pages (accounts.google.com, for example).   As for Brave, it could be a setting or an extension.  A common extension, HTTPS-Everywhere from the Electronic Frontier Foundation (HTTPS Everywhere | Electronic Frontier Foundation (eff.org)) automatically forces https connections.  There are also browser settings that do the same thing (and since Brave tends to emphasize security/privacy, it wouldn't surprise me if that was enabled by default).  This is why I like to use the command line utility curl; it does exactly what you ask it to do.  (curl - Documentation Overview). ... View more

Allow non-HTTP traffic prior to sign-on so we can get to the http://escapessl.com and the splash page  the splash page is http traffic. When it says to allow non http traffic, that’s going to include https. My guess is that your captive portal request is happening over https and your settings are allowing that traffic, so you’re getting that 200 response (success). Http should redirect properly, but it has to be over http (try going to https://captive.apple.com/ and then http://captive.apple.com/ my bet is that you see “success” on the first and get a redirect to the splash page on the second). You definitely do not need (nor want) to allow non http traffic to bring up the splash page. ... View more

Bigger problem is on Chromebooks.  They need the internet to log in to the Chromebook, but can't get to the internet if the captive portal is in place.  So user opens Chromebook and is prompted to connect to the internet.  User chooses the network with the captive portal and the pop up comes up telling them to open http://escapessl.com/ in a full browser.  But they don't have access to the full browser until they log in.  Which they can't do unless they have internet. ... View more

See my response to MrVench above.  The "Success" message is a 200 response, which means that the browser successfully completed the http request.  Ensure that the request is actually being made over http and not https and check that your captive portal is set to disallow https traffic.   Usually, captive portal detection works because https traffic is blocked.  The https protocol does not allow redirects in the same way http does.  So the browser attempts an https connection, which is blocked by the network.  The browser then does a captive portal check over http to whichever captive portal detection url that the browser/system uses (http://captive.apple.com/, http://gstatic.com/generate_204, http://www.msftconnecttest.com/connecttest.txt are common examples).  If the redirect happens, then the system knows there's a captive portal in use.  If you get any "success" page, that means that the user is successfully completing a request to whatever endpoint they were trying to reach (i.e. - that user has internet access; assuming you're not viewing a cached page).   You might want to consider using the curl command from the terminal to take the browser out of the equation. curl http://escapessl.com/ should work just as well; plus, if you use verbose (curl -v http://escapessl.com/), you can view the headers and response code. ... View more

You might want to check your Access control configuration.  It sounds like you might have "allow non_HTTP access prior to sign in" enabled.  Did you fully qualify the escapessl.com URL?  If you type "escapessl.com" without specifying http, you may be connecting via https, which would be allowed by this option.  Try navigating to "http://escapessl.com".  The browser definitely shouldn't affect what you're seeing (an http request is an http request; you can verify this using curl in your terminal).   See https://documentation.meraki.com/MR/MR_Splash_Page/Splash_Page_Traffic_Flow_and_Troubleshooting under "Unauthenticated Client Has Full Network Access". ... View more