@regexaurus said in Captive portal + DNS redirect:
Yes, I have ACME set up to request/renew a TLS/SSL cert and added a host (A) record to Resolver, pointing to the captive portal interface, for the CN host on the cert. Under HTTPS Options for the captive portal, I checked/enabled the Enable HTTPS login option, entered the certificate CN hostname for the HTTPS server name, and selected the appropriate certificate from the SSL/TLS Certificate drop-down. After additional testing/tweaks, this seems to be working quite well
👍
@regexaurus said in Captive portal + DNS redirect:
Adding the RFC8910 option seems to be a significant improvement
Easy check to see what device is using the RFC8910 login method, obtained by the DHCP lease request.
The rfc8910.php file, line 97, remove the comment :
Change
/* captiveportal_logportalauth("rfc8910", "EMPTY SESSION", $clientip, $cpzone); */
to
captiveportal_logportalauth("rfc8910", "EMPTY SESSION", $clientip, $cpzone);
and now you'll see all the request made for this rfc8910.php file.
This will somewhat flood your captive portal authentication log.
@regexaurus said in Captive portal + DNS redirect:
but on one system (an iMac running Sequoia 15.4.1 + Google Chrome 136.0.7103.93), with Google Chrome as the default browser, sometimes the system wouldn't automatically load/display the captive portal login. Once when this happened, I manually opened Chrome and simply entered google.com in the address bar. When I did so, this appeared:
Upfront : I use Apple devices like ipads and iphones. My latest Apple computer experiences dated from ... not sure, probably the the Apple II.
Afaik, as soon as the device knows that it is behind a portal, as it will be aware of this as soon as it connects to a wifi or cabled network and the DHCP event will return a the option 41 ID = the URL to a file where it should connect to using a browser.
On ipads and iphones, this is done automatically, as soon as the wifi connection to the portal SSID becomes active and a DHCP lease was acquired.
On iMac OS : behavior could somewhat be different.
Somewhat strange; imho, that you need to type in 'some' URL to force the browser's to show you the login page. The browsers knows their is a captive portal : it showed you the login URL
The Wi-Fi you are using may require you to visit ....
What was the URL you've shown ? Not the host name (I use portal.bhf.tld here on the forum, that isn't my real host name neither). What is the file ? index.html or rfc8910.php ?
That's isn't a may .... the URL shows was obtained by the DHCP request and needs to be visited so a login page shows up, so the user (human) can identify.
Btw : Chrome from Google. That's not -imho- a browser, more a system / user data collector. I'm a FF man, as long as it lasts.
Be careful with commercial browsers, as they tend to not use the system (iMac, PC's) DNS, they go straight to their own DNS server, like 8.8.8.8, most probably using DoH or DoT, so the pfSense Resolver never sees their DNS requests. So pfBlockerng can't work ... DNSSEC can't work .... But, when a portal is used - present in the network -, this won't work.
And because DNS doesn't work for them, they have a hard time dealing with portals.
Rfc8910 should make live easier on us, but if the browser doesn't care, well, then nothing can be done to solve that.
Well, something can be done. Like not using these kind of browsers 😊
