@John-3 said in Captive Portal on 2.7 not redirecting to login page:
For starters DHCP Works fine and the client does get IP/Gateway and all the information from the DHCP Server.
I've already tested that dns answers my queries with pinging random addresses which of course doesn't reply to my pings because i haven't authenticated yet but resolves the addresses to Ip's and as i've mentioned if i enter the portal login page manually then everything works fine!
Ok. Good to know, and now this is out of the way, let's continue.
I'm using pfBlockerng, so I have a file I can use to test if DNS works :
If you haven't, switch the resolver to "Level 3" (query level) on the Services > DNS Resolver > Advanced Settings, and then Save + Apply.
I use
tail -f /var/unbound/var/log/pfblockerng/dns_reply.log
you can also use (I didn't test but sur ethat DNS requests will show up - do not forget to undo this "Level 3" setting as it will produce a huge log file) :
tail -f /var/log/resolver.log
As soon as I connect my 'iPhone' to the portal, before a browser pops up on my phone, showing the login page, I saw a lot of (20+) DNS requests flying by.
This is what I just saw :
......
DNS-reply,Nov 22 11:52:03,reply,A,CNAME,30,captive.apple.com,192.168.2.35,17.253.109.202,FR
.....
This was the the OS of my phone that emitted a http (not https !!) request to a known web server (from Apple of course) and my device does this because it wants to test (all devices do this these days) if it can reach a 'test' site available on the internet.
Click to see the test.
This was my iPhone 'calling home' 😊
Androids don't call to apple, they use some other site.
Same thing for Microsoft device, they use a xxxx.microsoft.com http site.
If the resulting page contains the word (in my Apple case) 'Success' then the device knows it has a direct (non portal !) connection to the Internet. This is by far the most common case.
If it doesn't, (something else came back) then the device knows that a captive portal might be present.
It will fire up a 'browser', and repeat the same request.
On the pfSense side of things, a http request "with destination port 80 (http)" will get redirected by a captive portal firewall rule. To something like http://a.b.c.d:8002/xxxxxxx
Now, welcome that nice feeling : you start to understand how a portal works, that a 'captive portal' isn't actually a pfSense thing, but a BJOD device thing.
pfSense uses a rather simple firewall rule - and a web server to show a web (login) page if requested. Most of the heavy lifting is done by your device.