Captive Portal acting weird in 2.4(2.4.2-RELEASE-p1)
-
I meant, I do run pfSense on a dedicated machines, my old pc, but today, as I was trying to figure out these problems, I used vms, because I can't do all of my NAT again, I just put it from the backed up file, but in the vms, I do everything from scratch to find out if the problem is with the main machine, and I still have the same problem, on the dedicated pfSense machine with restored some of the settings, and the virtual machine with a completely fresh and default config. So no, not problem solved.
-
I found out the problem for packages not being installed, it's because they are made for that newer kernel, freebsd 11, and so can't be installed on 2.3.5, both 2.3.5 and 2.4 use the same links to packages, which is a bummer, what would be the point of 2.3.5 then? Nonetheless, I'll try 2.4 again to see if it still has the same problem with captive portal and can only hope that if it does, it gets patched soon for me.
-
System > Update, Update Settings
Switch to Legacy 2.3.X and you will hit the correct package repo for 2.3.5 / FreeBSD 10.3.
-
OK here we go, finally some kind of error(pfSense 2.4 latest stable):
Message from syslogd@pfSense
pfSense nginx: [ emerg ] 99236#100114: bind() to [0.0.0.0]:8002 failed (48: Address already in use)
Another same one, but instead of 0.0.0.0 it's ::
Help? -
Message from syslogd@pfSense
pfSense nginx: [ emerg ] 99236#100114: bind() to [0.0.0.0]:8002 failed (48: Address already in use)Ah, now we're getting somewhere ;D
Only one instance of nginx process will bound to port "8002" : normally the first instance, your first zone. More zones could be be defined.
8002 for http access (first zone)
8003 for https access (first zone)
8004 for http (second zone)
and so on.But : one is already running on that very port. (NOT normal - a previous instance could not be stopped ?! … )
On my systems, when everything is running, I see this :
[2.4.2-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ps ax | grep 'nginx-' 5611 - Is 0:00.00 nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-webConfigurator.conf (nginx) 6159 - Is 0:00.00 nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-cpzone1-CaptivePortal.conf (nginx) 7546 - Is 0:00.01 nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-cpzone1-CaptivePortal-SSL.conf (nginx)which shows on instance for the GUI (webConfigurator) and two for the captive portal (CaptivePortalxxxx) (one for http access and one for https access).
When I stop the captive portal, the latter two will (should !) disappear.
Btw :
sockstat -4l | grep 'nginx'Check out the logs when everything start from boot or reboot and at least one captive portal is active. When changing settings, it should be stopped, and restarted.
Another same one, but instead of 0.0.0.0 it's ::
The IPv6 counterpart. Useless for the Captive portal, because its IPv4 only.
-
Ok, I tried both of those commands and they are the same for me(not the ids of the services ofcourse). I only have 1 CP zone, so for the first command, it's those 3 lines. Now, where should I check logs for starting up captive portal, or what do I even need to look for in logs? Thanks a lot, finally some advancement :D
-
What I suspect your problem is your are running a captive portal on the same LAN that you are accessing the firewall through. So while you are connected to the pfSense you activate the portal but your state is not dropped. Your mac is not authorized so you are not forwarded to the redirect page and you get the error that you are getting. I bet if you connect another PC, phone or something that was not on the LAN at that time (so it didn't have any open states) that new device will be forwarded to the portal splash screen. The fix would be to clear all your states, but because you can't connect to the firewall you can't do it. That is why restarting pfsense allows you to work once again. Maybe a fix for you would be to create another interface where you can configure the firewall instead of trying to activate a CP on the same interface you are accessing it through.
-
No, you suspect falsely. I already have my macs added, since the pfSense 2.3.0, because that's when I set my everything up. Now in the upgraded 2.4 the only problem with pfSense is when changing some settings under the CP zone tab and saving those options, then the nginx breaks and I have to restart the machine. The changes ARE ACTUALLY SUCCESSFULLY SAVED.
-
No, you suspect falsely. I already have my macs added, since the pfSense 2.3.0, because that's when I set my everything up. Now in the upgraded 2.4 the only problem with pfSense is when changing some settings under the CP zone tab and saving those options, then the nginx breaks and I have to restart the machine. The changes ARE ACTUALLY SUCCESSFULLY SAVED.
See bugs in https://github.com/pfsense/pfsense/pull/3640 maybe this is the problem that you are running into?
-
Could be this too? https://redmine.pfsense.org/issues/8238
-
Do not administer captive portal from a device subject to the captive portal. Period.
Please fix that and try again.
-
I don't see my problem in this, but as I see that is some guy who changed the works of captive portal on pfsense? How would I apply his patch then? Thanks in advance. If I don't fix this issue soon, because I just noticed that my captive isn't working at all, not redirecting nor blocking anyone on the network who isn't signed in, even if I manually block the MAC, I'll have to make a switch to 2.3.5, again, as I got a reply on the fix that works for my packages not being installed there.
-
Do not administer captive portal from a device subject to the captive portal. Period.
Please fix that and try again.
True.
From an administration point of view, live would be so easy if the captive portal would refuse to be activated on LAN. Only OPTx should be an option.
On the other hand, many will start to use pfSense with just one ( 1 ! ) NIC, not the 'minimum required' of 2 interfaces (Captive portal : 3).
Better : no dedicated hardware but VM's - and/or VLAN's as a quick solution.Just for the fun, I activated the captive portal on my LAN this morning.
Added a new zone - gave it a name, filled in and minimum soft- and hard time-out, checked 'local user manager' and "Save".
My current browser session … timed out, as was stated above, this is actually quiet normal. I launched a second, different navigator (IE8) from the same PC, and found myself facing a login screen, (see image). I had to login to be able to do something, like writing this post.
Thus, I showed myself that the captive portal works well when activated from (my) LAN.
Note : I have just one firewall rule on my LAN, an explicit "pass-all for IPv4/IPv6/etc".Btw : This https://redmine.pfsense.org/issues/8238 is a very small bug that was surfaced recently - not related right now, as it handles the case of removing a MAC from the captive portal's white-list.
https://github.com/pfsense/pfsense/pull/3640 : a feature request … not implemented yet.… not redirecting nor blocking anyone on the network who isn't signed in, even if I manually block the MAC, ...
Blocking manually a MAC ? How did you do that ?
-
You can block internet access for someone under Captive Portal > MACs
-
You can block internet access for someone under Captive Portal > MACs
You're right !
Never actually saw the Block option. Thanks. -
You're welcome!
I'll be trying to install pfSense 2.3.5 now, again, as I can install packages without a problem on it now, and I'll try captive portal to see if it works. Will let you know soon! :D -
Yep, I installed pfSense 2.3.5 and set everything up, runs flawlessly, thanks for the help everyone, hope my bug is just random and will be automagically fixed in the next update :D
