Suggestions for a changing landscape.

nrasmus

There are numerous otherwise good changes happening out there that to my perspective are hampering the effectiveness of Captive Portal. Or perhaps I'm just missing key info.

The web moving to SSL: I'm not interested in forced MITM for our WiFi users. Do we just need to point users to a predifined URL?
Securing DNS at a higher level: Mozilla is experimenting with a planned default to DOH/TRR using cloudflare's 1.1.1.1. Avast also now does an application-level DNS "verification" step. Both of these "break" captive portal out of the box, but are further hampered by PFBlockerNG, and the problem also exacerbates any local DNS overriding.

Am I missing info on workarounds for these trends? Or is there new development underway to address them in some way? As a public library, public wifi is a big part of our business, and I'm just trying to keep up.

jimp

For your first point, you don't need to hijack or MITM SSL for Captive Portal. It works fine. Current browsers are good about probing for portals if the initial connection doesn't work as expected.

It works a lot smoother for customers if your Captive Portal supports HTTPS (valid certificate, correct hostname that clients can resolve, CP HTTPS enabled, etc) -- Look on youtube at the recent Captive Portal hangouts I've done, I talk about that a lot and show examples of the setup and browser detection working.

Firefox TRR and DNS over HTTPS are going to be trickier but I don't believe they will break too badly. First, you could set an allowed IP address entry of 1.1.1.1 to pass it through if you want. That said, TRR will fall back to the native OS resolver if it fails to resolve via TRR. See the Dynamic Blacklist section on https://wiki.mozilla.org/Trusted_Recursive_Resolver

I haven't tested with TRR enabled to see if it causes any additional delay, but for me at least on a current Firefox the portal detection is nearly immediate for HTTPS.

jimp

Actually it doesn't use 1.1.1.1 like I thought, but made a more in-depth post on TRR just now: https://forum.netgate.com/topic/133679/heads-up-be-aware-of-trusted-recursive-resolver-trr-in-firefox

nrasmus

Thank you! I will check out the hangouts--been meaning to enable https on the portal now that we are rolling w/ ACME, but I didn't realize it would help the situation.

It's possible the trouble we've been having with Avast (and I assumed firefox soon) is related to a firewall rule we've used to limit DNS to pfsense. Will dig deeper. Appreciate all you have done and continue to do @jimp