Redirect all pages to Captive Portal login page until authenticated
-
I have a captive portal set up for my open wifi VLAN.
Everything is working correctly with one exception:URL's are not being redirected to the captive portal login page, and instead simply failing to load.
This means that if a user closes the captive portal login page, they have no easy way to get back to it aside from reconnecting to wifi.What I would like to see is that even if a user closes the captive portal login page, when they attempt to browse to www.google.com for example, they get redirected to the captive portal login page until they authenticate.
Let me know if anything is unclear or if you require additional information on my configuration. As a side note, I am using DNS Resolver (unsure if this is necessary information).
EDIT: Redirect works fine for HTTP, just not HTTPS. Reading up over here (https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting), it looks like this is expected behavior. My question becomes, is there any way to redirect HTTPS to the CP prior to Auth just like it does for HTTP?
Thanks in advance,
-The Weasel -
Right. That is the nature of the beast.
You either:
Redirect https throwing certificate errors (bad)
Make https connections hang by not redirecting but no certificate errors (less bad) -
Well, that makes perfect sense.
I think I'll choose the non cert errors and not make any changes. Thanks for the quick response!
-
We were contemplating migrating to Ubiquiti AP's and use pfSense and its captive portal for guest wifi access. Currently we use Cisco 5508 wireless lan controller and all Cisco AP's. More expensive, yes, but the portal redirects perfectly http / https, it doesn't care. Our local hospital uses Cisco too and once you click Agree on their ToS page, it says Authentication succeeded and goes to the hospitals website. They are also using Cisco.
Needless to say it looks like we will have to stick with the Cisco solution because it just works. Without https captive portal, when you join the network on ios devices (iphone/ipad) the portal page does not automatically pop up. Cisco does some kind of pseudo network (like 1.1.1.1) to display the page, then you click accept on the terms and then it rolls you over to the proper vlan where DHCP gives you a correct IP (for us, currently an untangle appliance). Though in this test solution Ubiquiti gets on the vlan immediatly, and pfsense will pop up the captive portal if you try to browse to an http:// page first. Though finding a regular unsecured http:// page is getting harder and harder to come by these days. All your popular sites seem to redirect to https:// now.
I put our wildcard cert in and I can get the page loaded properly, but when the captive portal is using HTTPS one of two things happen.
First if using a regular submit button, it appears to try to authenticate. But you get certificate errors to our website. It looks like its trying to re-sign our website with our godaddy wildcard certificate. I don't know why its trying to re-sign anything, it should just redirect ie) load a new https session, grabbing the cert right then.If I use an image instead of a button, even with alt="submit" in the input code, and everything else the same, it simply just is an infinite loop. Clicking it just reloads the ToS page. Unfortunately to make it look the same as it does in our Cisco WLC, we are trying to match the look, which today is a button.png. I was able to match the look perfectly and upload all supporting images, css and js, and just re-reference it in the html.
If I disable https redirects and use a traditional submit button, I can get it to work, as long as I'm not initially trying to go to an https page. Though like I said before 90% of the internet seems to be https pages (including ours) these days.
Oh well. Was a fun experiment.
-
If I setup HTTPS redirects on Captive Portal on pfSense using a valid certificate like one from Let's Encrypt then it works OK. Both FF and Chrome are smart enough to see the hostname mismatch and kick in portal detection and it all works as well as can be expected.
Browsers may do something odd with cached redirects but I haven't personally had any problems with that in quite some time.
Key things are:
- Clients must have functioning DNS
- Valid certificate (e.g. LE/ACME)
- HTTPS redirects enabled using a hostname that exists in the cert (SAN, etc)
- DNS override so that hostname resolves to the local interface IP address of the portal
-
@kjstech said in Redirect all pages to Captive Portal login page until authenticated:
Though finding a regular unsecured http:// page is getting harder and harder to come by these days
No need to find these.
Take an example : an iPhone or iPad (sorry, no pub intended - but I do not have other devices):
As soon as the Wifi comes up, the DHCP negotiation kicks in. When the dust setles down, the OS (iOS) throws out a simple "http" request using port "80" :http://captive.apple.com/hotspot-detect.htmlThis URL request gets redirected by our pfSEnse ipfw firewall rules to the internal Captive portal web server :
2018-05-31 02:42:20 Local5.Info 192.168.1.1 May 31 02:42:23 pfsense.brit-hotel-fumel.net nginx: 192.168.2.114 - - [31/May/2018:02:42:23 +0200] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1554 "-" "CaptiveNetworkSupport-355.30.1 wispr"Click on the link : http://captive.apple.com/hotspot-detect.html : it returns only one (viewable) thing : the word "Success".
If this word isn't returned, but something else, like our Captive Portal login page, the the OS knows it's probably behind a Captive portal.
The OS will launch a navigator/browser and repeats the question. Our captive portal shows again - and this time the user sees it - and can act upon.Microsoft uses the same technic in its OS's (The Windows stuff) the last decade or so.
So, no need to visit a http://www.whatever.tld site to force an access to the captive portal login page.
At least, I never had to do so.Note : stupid - non-captive portal aware devices (read : OS's) , or users with fckd up default system settings can have real troubles connecting. I remember a lot of smartphones and other devices (OS's dating from the other century), some great firewall software with the "works only at home and no where else" setting ... well .... correct, my place is not your place.
Devices that are locked down by a hardware lease company, or VPN software that is non-portal-minded can give you some hard time, but, hey, you (the portal users) get what they paid for. -
@jimp
hi jimp can you please help me on this -
Jimp made the videos - 3 off them handle the captive portal. Add to that : all the developers made the doc.
You might have questions, that's ok, but they have to be detailed. -
@gertjan can you give me the link of that video made with sir jimp? i have also the same problem with ios users and some android users. current using 2.3.5
-
Try this Video Jimp pfSense Captive Portal.
