Captive portal + DNS redirect

regexaurus

I have a simple captive portal (no auth / click through) set up on a guest vlan, that is generally working as expected. I tried setting up DNS redirect (NAT port forward and firewall rules) on the same vlan / interface, but that partially broke the captive portal. I could still manually access http://captive_portal_ip:8002?zone=captiveportalzone and click to "log in", but I couldn't access any web pages. And yes, under captive portal status, I could see I was logged in. Interestingly, test DNS queries (PowerShell: Resolve-DnsName) failed before logging in (connected to captive portal vlan, but not logged in), but succeeded after logging in. I'm not sure why I was still unable to access any web pages...
I found another post/discussion about this scenario (captive portal + DNS redirect) which mentions workarounds involving adding rules in /etc/inc/captiveportal.inc. The last reply to that discussion includes rules for this setup on 2.4.x. I'm on 2.7.2, and it seems captiveportal.inc has changed substantially enough that those rules won't work. Besides, I'm not thrilled with the idea of modifications that need to be documented and possibly reworked in the event of future pfSense upgrades. Is there a way to get captive portal + DNS redirect working in 2.7.2? I'm open to modifying captiveportal.inc if needed, but prefer a web interface approach if possible, and I don't mean Diagnostics > Edit File...
Without DNS redirect in play, captive portal generally works for me. It works fine on an iPhone I tested. It works OK on a Windows 11 laptop I tested, if Firefox or Edge are the default browser. If Chrome is the default browser, when I connect to the guest (captive portal) vlan, Chrome tries to open http://www.msftconnecttest.com/redirect. If I wait several minutes, eventually it opens the captive portal login page (with a redirect URL of http://www.msftconnecttest.com/redirect), and I can log in. It seems this may be related to "active probing". Any suggestions for this?

Thank you!

Gertjan

@regexaurus

This DNS redirect : these are the first 4 firewall rules of my captive portal :

The very first rule isn't related, it's a pass rule so my Unif portal APs can contact the controller on my LAN.
Btw : my captive portal uses 192.168.2.1/24

Rule 2 and 3 are the DNS redirect rules. I've created these years (a decade ?) ago, as instructed by the pfSense DNS redirect documentation page.

Rule 4 block all the other DNS requests."

Btw : when you use the captive portal, all bets are off : you're not allowed to break DNS anymore.
The solution is : use the revolver's default (change nothing) settings, and the portal will works just fine.

@regexaurus said in Captive portal + DNS redirect:

I found another post/discussion about this scenario

Yeah, maybe, that was ages ago, when pfSense was still using the ipfw firewall, not the pf firewall.

@regexaurus said in Captive portal + DNS redirect:

Chrome tries to open http://www.msftconnecttest.com/redirect.

Noop.
That http (not https !!) request is executed by the, probably a Microsoft Windows device.
It's executed as soon as the DHCP client did it's work.
This "none browser" request is send by the OS to test if an "Internet connection" is available.
Every OS uses its own test URL, for example, Apple OS devices uses this http test request : http://captive.apple.com/hotspot-detect.html
Click on it,, and see what happens ^^
If the OS got a "page" back that shows :

then it knows that is has a direct working Internet connection, no further actions are needed.
If something else comes back, like ... the pfSense captive portal login page, then the OS knows that the device might be behind a captive portal. The OS will signal the user with a message that user interaction is probably needed, or it will launch a default browser with the same http://captive.apple.com/hotspot-detect.html, which will get, again, intercepted, and the captive login page will be shown.

Because URLs are used, DNS needed to work

A device that uses a captive portal should (must) use DHCP.
So the device will receive 192.168.2.1 as a DNS (my case).
If the device is stupid enough to use something else, like 1.1.1.1 or 8.8.8.8, then yeah, that is going to fail, as these destination are forbidden by the portal.
That's where the DNS redirect trick comes in : it redirect port 53 UDP or TCP connections to the local 127.0.0.1 on pfSense, where the pfSense resolver unbound is also listening.
Don't presume : you've checked that ? :

[25.03-BETA][root@pfSense.bhf.tld]/root: sockstat -4 | grep ':53 '
unbound  unbound    27811 5   udp4   *:53                  *:*
unbound  unbound    27811 6   tcp4   *:53                  *:*

so my unbound listens on 'everything' which included 127.0.0.1 === localhost using UDP and TCP. The portal is IPv4 only.

If the device uses DNS tricks like DoH or DoT, then you can't do anything about it. They, the device's owner has chosen the "max security" so portal usage is excluded. Not only your pfSense captive portal, but any other captive portal available on planet earth. Si be it.

Tip : be aware that the device to connect to the portal remembers teh Wifi (network, whatever) settings. It doesn't only remember that a password is use, but also if a portal is used.
So, when you activate the portal on a pfSense network, remove/reset the SSID wifi config from your device and the reconnect again.

Tip : install 2.8.0 Beta right away.
I'm using the latest 24.03 Beta 2 for a hotel, and have my hotel clients have no issues what so ever. 99 % connects just fine.

Tip : in the portal forum, have a look at the forum threads that mention "rfc8910". That's the more modern way to handle a portal. No file edits are needed, but you have to create a PHP file (examples are given) and you need the latest kea server functionalities so you can add a DHCP server option so your clients (for those who are RFC8910, many are these days) can connect even "faster and better". I'm using this method for nearly a year now, and works flawlessly.