Captive portal without needing to login
-
Well this location is a public place. And i get a lot of complaints about people not getting past the redirect page.
i have a page with simple javascript to "press" the continue/login button. But few people get stuck on the page.
Sometimes even rebooting the pfsense helps.
Wonder if the issue is somewhere else in the pfsense?
edit:
Is it possible that the redirect page is working, but there is some problems with DNS? I'ts basically quite default DNS settings.
-
Well this location is a public place. And i get a lot of complaints about people not getting past the redirect page.
i have a page with simple javascript to "press" the continue/login button. But few people get stuck on the page.Script, or not, clicking, tapping, or whatever on the Accept button works for me - or actually, my clients.
https://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/portalusers.html
And believe me, if the "Wifi" (== Internet) connection doesn't work, people tent to contact the reception immediately.Sometimes even rebooting the pfsense helps.
Rebooting ?
I only do that when an upgrade comes in …Wonder if the issue is somewhere else in the pfsense?
Noop.
You and I and thousands of others use the same code.
Only your setup is unique.Is it possible that the redirect page is working, but there is some problems with DNS? I'ts basically quite default DNS settings.
As said here : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting - this helps by gives you info about how to test and check.
These days more and more people use the most exotics setups, if not a totally impossible "solution" for a setup. Or, they often break the rules.
Possible is also that that devices that clients use just don't accept 'strange' networks (and thus won't work with your network, and that is NOT your problem ..).
Always use the golden rule : keep it simple.If needed, but I don't do it often anymore :
I run to the shop in front of my hotel, and I take this brand new iPhone, the latest Samsung or that very recent - of not new - Dell laptop PC.
This as a proof that the device hasn't been setup and tampered with.
I can connect with this device to my wifi network (pfSense captive portal) right away. A browser will popup, we see the login page, we can click on that button (after filling in the user name and four letter password : already quiet a hassle for some people). All this to show to my clients that "it works out of the box". So something else is bothering them … ;) -
Have say for starters, thanks for the help you're giving.
Nice graphs. What is the antivir thing? Is Munin part of pfsense package manager or?
Yes, rebooting seems to sometimes fix the captive portal.
Here's my html which i put on the pfsense. https://pastebin.com/AdSrX86J - can you check if its ok?
Im still curious why does users get stuck on that HTML page. There seems to be some sort of issue with people not getting past it.
I'm kind of new to pfsense. But you seem to have lot less users. I get about 200 clients on a network.
-
And one thing that i am curious.
How does the captive portal idle timeout work?
If timeout is set to be almost as same as DHCP lease time, why does captive portal user count keep rising?
DHCP leases are running between 80-120 users. But concurrent users for captive portal has gone up to 160.
Does it somehow NOT kick out the captive portal users or what?
-
If timeout is set to be almost as same as DHCP lease time, why does captive portal user count keep rising?
You shouldn't.
(this was one mentioned on the DOC pages ….)
The usage of the "idle time out" presumes that you are aware of this : If you have a DHCP lease of x seconds, please note that DHCP clients will renew x/2 (half the lease time).So, rule of thumb : DHCP leases should be at least twice the idle time count. I guess you understand why now.
Use a idle timer with a hard time-out timer, as you already know, some devices (most of them today) never shut up, - they have to hammer that facebook IP 4 times a minute, which means the idle timer will not disconnected, except if the device breaks the connection (leave the place).
-
You would have to modify your portal HTML and possibly index.php (which would be a custom, out-of-gui modification you would have to track yourself during upgrades, etc) to get the IP address, MAC address, and automatically call the portal login function then redirect the user to the after-auth URL.
I know of no way to do what you are asking to do without customizing CP. Maybe some javascript to make it look like the button was automatically clicked but I would expect differences in device compatibility to be your enemy there.
You might be able to bounce to a pre-auth URL that redirects back to the portal with a POST that looks like the login button was pressed, too. Not sure if CP still works with a GET which might be easier to redirect to.
-
You would have to modify your portal HTML and possibly index.php (which would be a custom, out-of-gui modification you would have to track yourself during upgrades, etc) to get the IP address, MAC address, and automatically call the portal login function then redirect the user to the after-auth URL.
I know of no way to do what you are asking to do without customizing CP. Maybe some javascript to make it look like the button was automatically clicked but I would expect differences in device compatibility to be your enemy there.
You might be able to bounce to a pre-auth URL that redirects back to the portal with a POST that looks like the login button was pressed, too. Not sure if CP still works with a GET which might be easier to redirect to.
Yes, ofcourse DHCP pool needs to be big enough. But my point was that DHCP leases do come and go, but Captive Portal just keeps on rising.
-
Then it's configured incorrectly.
-
Then it's configured incorrectly.
Care to advice?
idle timeout is set to 1800, and dhcp lease is 10 hours. Leases do end/renew, but Captive portal users only add up.
-
EDIT : Wait ….
@ttsumak:Then it's configured incorrectly.
Care to advice?
idle timeout is set to 1800, and dhcp lease is 10 hours. Leases do end/renew, but Captive portal users only add up.You already had the advise that solves the (setup) error : https://forum.pfsense.org/index.php?topic=130942.msg722830#msg722830
First things first : ALWAYS set a hardware time out.
And, as already said : DO NOT setup a idle time out with 1800 minutes (= 30 hours) and a DHCP lease time using 10 hours. Your connection will never be idle, because every 5 (x/2) the lease will be renewed, and your instruction 'rule' "disconnect after 30 hours of being idle == NO COMMUNICATION whatsoever" will never apply (and you tested that and figured it out the hard way)
Thus, you get what you asked for : people are never get disconnected.
It's time to read and understand the issue …. :)If not, then (the rest of the message I posted before, presuming a real, original bug ....):
Well, some low level testing is possible.
But, you'll be needing this :
A SFTP tool like SmartFTP, or at least FileZilla (but note : DO NOT USE the FTP protocol, is dead and burried last century, and pfSense doesn't have a FTP server anyway - setup is done as the SSH acces (you should active SSH access in pfSense => System => Advanced => Admin Access and check "Secure Shell Server")
Putty for the SSH access (yep, interesting stuff never uses the GUI).
Enter option 8, and typeps ax | grep 'prune'Does this show you :
[2.3.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ps ax | grep 'prune'
15442 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1
15733 - S 0:01.28 minicron: helper /etc/rc.prunecaptiveportal cpzone1 (minicron)
79162 0 S+ 0:00.00 grep prune
(show here what it show you, do not say : yes - don't paste images of what you see, copy-paste the lines)Are you able to find this file /etc/inc/captiveportal.inc ? (use filezilla to retrieve the file and use a text editor to edit - like Notepad++ NOT MS Word ! - You could use the editor build in pfSense, 'vi', but your live will be to short to handle the interface …)
Are you able to locate the function "captiveportal_prune_old() function in that file ? ( https://github.com/pfsense/pfsense/blob/master/src/etc/inc/captiveportal.inc#L734 )Bonus question : are you able to read PHP ? Can you understand what happens in that function ?
If all the questions are "yes", then there is hope :)
-
The only time I have seen portal sessions not get expired on a properly-configured captive portal is when the minicron for the pruner process died. This is pretty transient though and should be corrected by any change to the portal and a save.
It can be checked in Diagnostics > Command Prompt by executing ps axwww | grep -i prune
You should see something similar to this:
19411 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_test.pid /etc/rc.prunecaptiveportal test
If that is there for the correct captive portal and you still experience climbing CP sessions then either the devices are not leaving the property (anything - even DHCP or ARP renewal will reset the timer as gertjan has explained) or the portal is misconfigured. Prune events are also logged in the portal auth log.
I used a portal idle timeout to great effect at a hotel. I only wanted them to be bothered by the portal once - even on a multi-day stay. I used an 18-hour idle timeout and a shorter DHCP lease time. I just made sure that the dhcp pool was large enough to accommodate the device churn through the property so the same lease was always available to give back to a device until they were long gone. As soon as the device left the property for 18 hours, the dhcp lease and the portal entry were both history.
-
Does this show you :
[2.3.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ps ax | grep 'prune'
15442 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1
15733 - S 0:01.28 minicron: helper /etc/rc.prunecaptiveportal cpzone1 (minicron)
79162 0 S+ 0:00.00 grep prune
(show here what it show you, do not say : yes - don't paste images of what you see, copy-paste the lines)[2.3.4-RELEASE][root@LAN-GW.lan]/etc: ps ax | grep prune
31149 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_client.pid /etc/rc.prunecaptiveportal client
31312 - I 0:00.18 minicron: helper /etc/rc.prunecaptiveportal asiakkaat (minicron)
31143 0 S+ 0:00.00 grep pruneSo as you can see it is running. And i guess my problem really is that the DHCP lease time is less than captive portal idle timeout. Confusing that CP idle timeout is in minutes and DHCP lease in seconds.
But yeah, im ok with vi, ssh and cli. But not good with coding, so the php is too complex for me.
I used a portal idle timeout to great effect at a hotel. I only wanted them to be bothered by the portal once - even on a multi-day stay. I used an 18-hour idle timeout and a shorter DHCP lease time. I just made sure that the dhcp pool was large enough to accommodate the device churn through the property so the same lease was always available to give back to a device until they were long gone. As soon as the device left the property for 18 hours, the dhcp lease and the portal entry were both history.
I was thinking about the same thing. Only once bothered, perhaps every 24 hours.
I guess i just have to change the netmask to something larger first.Thanks alot. I'll see how the tweaking of DHCP and idle timeout affects :)
