> On 8 Mar 2021, at 14:08, Steve Litt <slitt@???> wrote:
>
> Rick Moen said:
>
>> The above is a vexing problem for travelers w/laptops who prefer to
>> specify their own choice of nameserver and still use hotel/motel WiFi
>> (and wired ethernet, actually). Best case, you have to disable your
>> nameserver IP override long enough to navigate the captive portal, and
>> then can put the override back. But, no, you cannot just leave your
>> choice of nameserver IPs in place (without disappointment).
>
> This is good information. I've sometimes wondered why I couldn't log in
> at the library or Macdonalds.

And the other thing they screw up is that by redirecting you, nothing presents the right certificate ! I hate using such public connections because it's so much hassle remembering to put every bit of software into offline mode first - if you don't then I get a flurry of certificate warnings and it can mean quitting and re-opening software for it to pick up the now correct IP address. But if it's a choice between that or nothing then ...

The process is simple enough. When you are not an authorised user, the captive system responds to every DNS request with the IP of it's captive portal. For HTTP requests that's simple enough - you get their portal page instead of what you were asking for. Once you've signed in (and possibly had to pay for it !), then you get the right IP addresses returned.
But of course, your system has cached the wrong address and may or may not flush it in a timely manner. Your browser has cached the portal page instead of the real page (assuming it was an HTTP request). And everything using secure connections, gives you certificate errors.
That latter point means that you go to https://myfavouritewebsite.com and no you don't get the portal page - you get a certificate warning. Given that most people these days will have https URLs cached in their browser, you have to manually and explicitly try and connect to a site (doesn't matter what, any random URL will do) over HTTP.

Simon