I have those problems too.  I don't believe the timeout is long enough before iOS gives up on the Wi-Fi and goes back to cell.

It is impossible infeasible to successfully captive portal HTTPS connections unless you control all your prospective client devices and can pre-install trusted root certificates.  It is better to just drop TCP/443 traffic until the portal session has been negotiated via TCP/80.

thank you cmb!!! i plug the WAN to LAN and set it same subnet. now i can start the voucher sell. :D

thanx ill try that

Ok, did a little digging and this does what I need it to do. Sort of: https://forum.pfsense.org/index.php?topic=63531.0 Ideally it would still be useful to implement bandwidth restrictions only when usage reaches a certain threshold. I suspect there is nothing in the traffic shaping rules which will do this, but thought someone might like to prove me wrong.

Not to mention https://doc.pfsense.org/index.php/Using_Captive_Portal_with_FreeRADIUS#Amount_of_Bandwidth

@sine_kitt: Hi i want to know , is there a way that users can manually logout from captive portal..users get logout popup window once they authenticated with CP…but imagine if they accidentally closed that page..what shall we do then...i closed the connection to CP for that user on status --> captive portal.....but after that user wont get any captive portal authentication page till i restart the service from pfsense... What about setting the idle-time out to 5 minutes ? If users come back within 5 minutes, they have access to the net because their device is still on the "permitted list". If they come in later then 5 minutes, they WILL have the auth page again. Their is no real need to have people being logout out by themselves. Every minute the list with logged in clients is purged if needed (timed out). You control the time out. You can see (test) so by watching the portal log and captive portal status page.

Or this, maybe: $auth_list = radius(strtolower($user),$paswd,$clientip,$clientmac,"USER LOGIN", $radiusctx); You could also strtolower() the password, but that would just be to let people log in with capslock on.  If you do you need to make sure you also strtolower() the password before you save it/hash it/etc in whatever RADIUS is using as a backend. Back in the dialup days we used to have some logic that would lowercase the password and try again if the initial login failed and the entered password wasn't mixed case.  Kept the phone from ringing unnecessarily.  Today, that would just give the assholes two tries for every attempt.

Just use the "After authentication Redirection URL" to point your users to a page containing a message.

It's also possible a captive portal config section was imported from 2.0.x or before into 2.1 and not a whole config. That will happen if the configuration wasn't properly migrated to the zone structure. It may need the entire <captiveportal>section removed (or at least anything outside of the cpzone tags)</captiveportal>

The key thing here is I do not want to segment the network here, I just want to prevent access from this interface without authentication. As in I want the DHCP server on the existing LAN to handle machines that communicate the pfsense box.

Hi,     This message "Error: This computer wasn't used to login initially" is from the portal auth log. It seems that when the DHCP server reuses an IP address and reassigns it to a different host/mac-address, the IP/MAC pair does not match what's in the online users list for this user. I did put a timeout of 6000 for users to be disconnected from the portal though, but it seems they are not being removed.

Bom dia, Gostaria de saber como calcular o Magic Number , na parte da criação dos voucher no pfsense, Preciso mudar os caracteres do voucher para que seja criados apenas com numeros, ai com isso preciso mudar o Magic Number para serrem validados no captive portal, Thank´s