A bug from 5 years ago ? No one is talking about this one, so I consider it doesn't exist any more. I was using pfSense 5 years ago, and I never saw this "send() failed (40: Message too long)”" in my logs. Back then, I remember that I could force pfSEnse (nginx or lighthttpd) to show this message by 'programming' a redirect error in my home made captive portal html page (it went recursive, and the web server reply became to long). When you say "Users can not login" you should also post the firewall rules that you obtained by reading this : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting

[image: 1527673600966-chose-one-resized.png] You can use Voucher or Radius Not both at the same time at the same portal instance. This means that vouchers all share the same bandwidth settings, set up on the captive portal page. FreeRadius gives you the possibility to set a per-user bandwidth setting.

thanks, I will study it

@Gloom: Silly question but have you put rules in place to allow the connections to the interface on VLAN20 from the subnet? Hrm What do you mean? Should I need an additional rule besides the Firewall Rule on the mvneta1.20 VLAN IF that allows all protocols/ports to pass? This is the only rule I have in that IF: [image: capEwMk.png]

Nice. The progress is the word "Failure". This message is the result of one check ( see /usr/local/captiveportal/index.php  - at the bottom ) : if the user+pass are in the local user list, access is granted. A second check is done if you checked "Allow only users/groups with "Captive portal login" privilege set" on the Captive portal settings page. If these test(s) are ok, you are logged in. If not, a "Failure" is thrown out. So, if you are sure the user and password are ok when entered, and you are sure they are in the local user manager list, the conclusion is simple : Consider your system broken - probably a hardware (disk) failure. If a login works - and after some time (hard or soft time out ?) the user can't login anymore, then something is not working as it should. Btw : I'm replying knowing that you did not mention anything about your setup, so I consider every setting is set (kept to) to default (value). It is of course possible that a user logs in, and after  time out he can't login anymore for the rest of the day. Or something like that.

solved : i have to not use cap letters

and why can i access other zones' captives portals just by changing this this is too weird EDIT nevermind i solved it… i addes multiple rules in the captive portal but i guess something went wrong... can anyone help me allow all those ports without causing any problem ? i suspect that the ipfw rules must have a limit or they are used elsewhere ... can i use any other method to allow those ports before the authentication ? like with a table where there are all the ports and like one or two rules that wont cause any other problem ? appreciate the help and thanks in advance here are the rules i tried https://fr.scribd.com/document/379814591/Captiveportal-Rules PS : the rules worked perfectly but caused many other problems 53 UDP (keep-state and out) 138 UDP (in out and keep-state) 137 UDP(in out keep-state) 389 UDP TCP (same) 88 TCP (same) 445 TCP (same) 139 TCP (same) 135 TCP (same) and from 49152 to 65535 TCP (same for everyone one of them) for what i'm trying to do : allow ports for the windows authentication through captive portal to the active directory EDIT 2 : trying again same problem, the redirection ends up on one captive portal for all interfaces, it's like something gets messed up. when i get rid of those rules, everything works normally, so how can i allow without having to face such problems ? EDIT 3 : Solved : https://www.freebsd.org/cgi/man.cgi?ipfw(8)

Solved, i should have used the other form : $cprules .= captiveportal_create_ipfw_rule

Hi, Gave it some thoughts, but I think you already found the solution : add (white list) these 230 IP's.

Yep, that's a new 'feature' I guess. For now, "do not calibrate  the system while it's running"  ;) https://forum.pfsense.org/index.php?topic=147413.0

k, I just subscribed to Gold. The current information about Voucher Sync is out of date. I think there should be at least something that suggests you to enable HASync here: https://portal.pfsense.org/docs/book/captiveportal/vouchers.html#synchronizing-vouchers Asfar as I understand the current version of that section is that it would be enough to use the settings mentioned.

@drduckun: I'm using wifi controller and firewall connecting to radius server. Everytime user connect to wifi, it will request user input ID&Pass. But this network system don't have captive portal and use authenticate with voucher. What Wi-Fi controller are you using out of interest.

The captive portal is not a redirecting thing. By default, close to  nothing get through the interface and when authenticated, the rules on the GUI interface are used. No redirecting comes into play here … or I'm not understanding how you use the captive portal. Btw, I believe this is more a wifi-radio connection issue - just cable up a device, not a phone of course, to see if the problem still exists.

Have a look at Zebra, used to use the industrial ones years ago. https://www.zebra.com/gb/en/products/printers/desktop.html

The patch : moving a line : https://redmine.pfsense.org/projects/pfsense/repository/revisions/29a272f7361689c87dd7ad9fc1c903e843a1c593/diff/src/etc/inc/captiveportal.inc Not rocket science. Some text-editing skills are needed though.

Reduce DHCP lease time. But keep in mind that the pool should be bigger as the potential number of devices requesting an IP. If not, you'll be stressing your DHCP server and your users. A Captive portal should run on it's own interface - so a 10.0/16 (65 K addresses) is two clicks away.