Captive Portal and Mobile
-
I have a Pfsense box setup with a simple captive portal that has a terms and conditions page, an accept button and a redirect URL. No vouchers are being used
When users on mobile phones (personally tested on Android 8, 2nd hand reports rom iOS), reach the captive portal and click 'Accept', the page just stays there. No redirect, or anything.
If I close the landing page after clicking accept, then open up a browser or any web access, it works as normal.
Any ideas? I don't think it's an issue with Pfsense, just trying to compensate for the oddities of a mobile device. Or, if anyone has any code that can be added to the Portal to make it render better for a mobile device?
-
Go one step back : use the build in portal page first.
When that works for you - and it will, you'll be very close that the reason why redirection is been taken ;) -
But why would I have different results mobile vs. desktop PC? And the issue is that redirection ISN'T happening from mobile phones.
-
I can't explain why it would work differently on mobile (must be a coincidence), but the $PORTAL_REDIRURL$ variable should be called, and forward you on after auth.
Make sure you have the zone set as well.
-
what is the redirect page ?
I had this problem before when I redirect to https web site. pfsense has notice it can't redirect to https. (I saw the doc before, but don't know does it fix in new version)I fix it(not a fix just try the other way). I redirect user to http site not a https site. after then all mobile and website can be reach the page.
for example, redirect to http://www.google.com. , it can pass to google. and google will auto change it to https.
hope my suggestion can help you.
Bear
-
I had this problem before when I redirect to https web site. pfsense has notice it can't redirect to https.
;D
Euh … wrong !
See my "After Authentication Redirection URL" : see attachment. This one works for many years now.
This URL is used after successful authentication. So, it will work. https, or not. Every Internet destination is open, only restricted to the GUI firewall you setup for your captive portal.Btw : pfSense does not need to redirect (or intercept) initial https URL's because :
It can't - and no one on planet earth will break or make that situation.
It's your device that makes it work - togerther with pfSense of course.
All devices always through out an initial 'hidden' basic http request as soon as his NIC commes up with a IP connection - and this hidden request WILL trigger the captive portal … and all will live happy for the rest of their lives.Those devices that do not make this initial http request :
Owners should :
Update them - devices with an IP connection should do work like described
Or : owners should know then that they should open with a http://.... requests, NOT a https:// .... (this is workable, though, as it happened often, years ago, with the first stupid Android stuff etc)
Or : throw away the device - to old.These days, MAC, iOS, Windows (all recent versions), Debian, FreeBSD, whatever, they are "captive portal aware". Not "pfSense Captive portal aware", but universal "captive portal aware" (many others do exist apparently).
The last enemy exists : those who use one of those "commercial 'device' firewall" that lock down 'Ethernet' port on their device, not accepting 'strange networks' (as per owners order !) and after that they complain that they can't connect no where else as their own place ..... Well .....
-
I'm coming back to this topic as it's reared up again.
This is for a campground, and they shut down over the winter. They are now opening up for the season and we'd like to get this resolved.
I built a new PFsense box for them, and rather than re-import a possible error in the config, I built it from scratch. I tested the routing and all the filtering rules, and confirmed they were working. Then I enabled the captive portal.
On a Win 7 laptop with Firefox, I hit the landing page, click accept, and all is well. Delete the user from the CP status page, and retry, still works again and again.
On a Chromebook laptop with Chome, I get a similar reaction. The only difference is I get a popup as soon as the wifi connects. All good.
On an Android phone, first time, it worked great. 2nd time, worked ok. 3rd time, I got stuck on the portal page. I'd click accept, and the progress bar would move across the screen, but leave me right at the portal page. Trying to open a new page would just time out. Closed the tab, opened up a new one, and still says "Connected, no internet". Repeat several times, and all of a sudden I have internet access, without getting the portal page, or a listing in the CP status page. (fyi, mobile data is off for this test)
What is it with mobile devices and CP? there's nothing odd about the HTML in the portal page, so I am at a complete loss.
I've attached the portal page in case there's something off with my HTML.
-
The bit about getting internet access without validating through the portal page is apparently a known bug in 2.4.3: https://forum.pfsense.org/index.php?topic=146046.msg795216#msg795216
