Thanks again @Gertjan for the great response! For starters, I will tweak the DHCP lease to 12-24 range and keep an eye. Then we'll see I guess :P BTW, now that I think of the session pfSense assumes, perhaps it's a ticket for the dev team to investigate that even though the client IP changes (MAC stays the same), the portal session is detected by the server and the portal login page prompts for a "Disconnect" ("you are already connected"). Then the clients press "Disconnect" and log in again, of course. I would expect from what we established above that pfSense would create a new session (MAC / IP mismatch) and prompt for login immediately.

Moved to here.

@Gertjan that is a good idea in theory, but this would also mean that the voucher is not going to be "invalid" on all systems when used up in one.

@veldthui said in Captive Portal with login but no authentication: That was why I was asking if i could just get them to input their name Why do you want them to enter a name ? It's easy to create a text field, and have the content discarded. Doing something with name the user entered, like writing it to a file, is another level. It is technically possible that the portal login code adds the entered user name as a pfSense user, the ones you can see under "System > User Manager > Users" but this creates a situation where unknown / non trusted users starts to add 'stuff' to the pfSense config file ..... that's far from safe. Like the password, you can also hard code a user name : all logged in users will actually use the same login name and password at that moment. You don't want to use this method : [image: 1715263643111-323c1821-1dcc-421d-9eec-bbeed1cabfa6-image.png] as the user now doesn't have to enter anything, right ?

@Gertjan Thanks for clarifying. I was guessing somewhat like this, but was not sure. Yes, allowing access to someone using self registration could be difficult. Beside of some law restrictions the requestor must be able to receive the access code by mail/SMS or somehow else. My favorite would be sending the code by mail, anyhow, after an update you may need to check if all is still running. So my pages for the voucher QR code printing need to copied to the pfSense again after every update. Back to self registration: its a challenge, if connected to CP you are already connected to the WiFi, but without internet access (code still not entered), so how to receive the access code? May be by building a dynamic portal page which shows the access code after entering a string, a captcha or something else, as said a challenge . Regards

@Gertjan - This is the solution! Thank you very much.

@uggiz said in Captive Portal - Cron - Authentication issues: its possible to get a "Quota used" message when the users gets logged out? A browser getting a none solicited message from a web server with info ? Noop. Never seen that before. Browers can connect to web server, get the file (page) they are looking for, and bye bye the connection. It is possible to have a "logout" or "you are connected" browser windows open, and have that windows load some Jave stuff that questions the current status. if it was possible to get the "max allowed" and "current" bytes used .... but ..... See for yourself : #!/usr/local/bin/php -q <?php require_once("/etc/inc/util.inc"); require_once("/etc/inc/functions.inc"); require_once("/etc/inc/captiveportal.inc"); /* Read in captive portal db */ /* Determine number of logged in users for all zones */ $count_cpusers = 0; /* Is portal activated ? */ if (is_array($config['captiveportal'])) /* For every zone, do */ foreach ($config['captiveportal'] as $cpkey => $cp) /* Sanity check */ if (is_array($config['captiveportal'][$cpkey])) /* Is zone enabled ? */ if (array_key_exists('enable', $config['captiveportal'][$cpkey])) { $cpzone = $cpkey; /* Zone selected -> count users and add */ $cpdb = captiveportal_read_db(); foreach ($cpdb as $cpent) { print_r($cpent); echo date("m/d/Y H:i:s\n", $cpent[0]); echo "---------------\n"; } } ?> Create a file called /root/cap.php and put the above content in it. Now call it : php -q /root/cap.php and you see : no 'used' info is avaible in the pfSense portal session database. The max quota is : [traffic_quota] => 104857600 = 100 Mbytes in my test case = Ok. Ok ... you could, on the web server java side, get the max and used info from these files directly. Another info source is : [image: 1713961353494-32e69f3b-9c5f-4239-9d3d-417955ee1941-image.png] as the main log will be bombarded with these message (imho : they do not belong there - call me and I'll tell you how to ditch them). edit : Another way to have the user have page where you control the info : Have seat-belts ? Put them on. Read this close the initially irrelevant forum thread : captive portal is not working on mobiles But in that forum thread I discovered something : the future of the captive portal ( ! ) It already exist, and you add it easily. One condition : don't use KEA as your DHCP (portal ) server, you have to use ISC. because you have ti create a DHCP option for the HCP portal server. Instructions are present in the forum thread. You need to create one file (content of this file : see thread): [image: 1713962350669-26a4bd49-d5c9-43a8-9383-374fd662abfe-image.png] and now, if you have an Apple device, you can test : connect to the portal - and notice is connects faster - and when connected, tap on the SSID of the portal, and you'll see something new. Open the new suggestd link called "Portal" and the text "This network proposes a portal page". The page you now open - the "You are connected page" is the future "portal status page". Btw : I've also see (real) Samsung devices using this new RFC 8910. Others devices : dono ... Why I'm telling all this ? The page you saw is created here : /usr/local/captiveportal/index.php That where uyour changes go with the info you want to show - if the user wants to see it (and if they know how to request the info, because again, this is "portalling" as it will be done in the future ...) Btw : I've this method running for several month now. Works great. Doesn't interfere with the existing capture method at all, it completely bypasses it. The device will know where to go as soon as DHCP request has been answered. No more DNS hassle, web interception. Just plain KIS. Read the RFC and you'll get the picture. edit : sorry : I went way to far again / was ranting. Sorry.

I came to the conclusion that running a proxy filter is a pain in the a**. It did not work on Android, sometimes it did not work with iOS - at least Windows was the least pain as it seems to implement WPAD in an administrator-friendly way (we announced our proxy using DHCP). My solution: no Squid at all. I am now running two machines with Pi-Hole. The to-be-released version 6 supports allowlists so we can configure a "you cannot do anything per default" and allowing certain websites using our pre-defined lists. The other DNS filter runs the current stable release with a bunch of blocklists. You can also use pfBlocker-ng's DNSBL capabilities, but Pi-Holes web interface is so much faster and easier to work with (it get's even faster with v6). I am using pfBlocker-ng's IP blocking capatabilities :) Regards

@Gertjan thank you for the info, gonna test it

@Gertjan Thanks for your reply. Your pointer to /tmp/rules.debug was a good hint for me. I found the relevant scripts as well. I will first have to learn about pf and will then decide if I want to continue efforts to adjust the scripts. It's just weird that there is no documentation. Even the scripts are very sparsely commented.

@DominikHoffmann said in Need pfSense captive portal tutorial—not sure, where to put HTML code: The key for me was to check “Enable to use a custom captive portal login page.” Without that, I could not get a captive portal to appear. This : [image: 1711204901822-06b9ae74-b82e-4b53-b203-dcc6627e0783-image.png] option doesn't have to be check. If it isn't, the default login, build-in, page will be sued.

@Fidelinho88 ? The first IP of a network is 'normally' the IP of the pfSense LAN = 192.168.0.1 The next IP could be 192.168.0.2 and that will be your "AP" (look again previous posts). Btw : my opinion, but have the AP use a static IP setup, not DHCP. @Fidelinho88 said in Configuration of captive portal and Router for use: It has been shown as offline ... Offline means here : not in the pfSEnse arp cache. See here : Diagnostics > ARP Table You can - should be able - to ping the 192.168.0.1, your AP, so it is online. And as soon as you ping it from pfSense, pfSnse will have it in it's arp cache for several seconds, and by magic now it shows online. To be offline again afterwards .... or, the AP is still there, up and running.

@skveen said in Management for Vouchers: Yes, but I don’t want to use psk What is psk ? @skveen said in Management for Vouchers: It is a good idea to use one Voucher per day or per table Look in the future. For some reason, you've decide to use a version that is severally depreciated : @skveen said in Management for Vouchers: In the end I chose the version pfSense-CE-2.7.0-RELEASE With the now declared "zero day OpenSSL ready" version 1 ? You've missed : Netgate Will Migrate to OpenSSL 3 in pfSense Plus Software Version 23.09 to name just one. Euh ... ok. Good luck. Normally, a firewall is about security. "Confort" shouldn't come first.

@Gertjan Thank you for all of the info regarding the captive portal. The APs in the facility don't support LDAP authentication, hence the use of the captive portal. They do support Radius, but I don't have a Radius server running/integrated with AD at this time, so the captive portal was a quick way to get something working with LDAP. Management doesn't want all employees to have access to the WiFi, and since the password on the WiFi can be easily shared and is cumbersome to change, the captive portal is the current solution. We do use MAC address access control for company devices, but not for personal devices of employees who are authorized to use the WiFi. I'll probably look into adding a Radius server so we can just perform the authentication at the AP level instead of the captive portal.

@robsonvitorm You dont need to obfuscate private addresses (RFC1918) or mac addresses generally. If you don't see packets leaving then you have a problem on the host level. Either your network stack on the host is corrupted or you got something else going on.

@getcom said in captive portal: nginx 504 GW timeout & 'dnctl: need a pipe/flowset/sched number' => MAC addr cleanup job needed: https://github.com/pfsense/pfsense/commit/8bfe17dae7ab15b7af802f69dbb7c421d098d38c Looks like that related. It's an easy edit, go ahead ! @getcom said in captive portal: nginx 504 GW timeout & 'dnctl: need a pipe/flowset/sched number' => MAC addr cleanup job needed: You said "Easy to rebuild as "if voucher is expired, then ditch the auto added MAC"". Should we implement that and commit a fix? The easiest solution would be : don't "auto add", as this is only a comfort option for your portal users. On the long run not for you ! They, the portal users, log in once using the voucher code, and from then on they stay logged in forever. Its up to you to remove the 'old' macs manually. Seems tedious to me. Is there a comment add to the auto added MAC entry ? If so, and it contains the voucher ID, it's easy to parse over all the mac entries, isolate the voucher code, test for validity (still time left) and if not, delete the mac entry all together (does doing a auto clean up ^^). I'm not using vouchers at all on my portal, but I'll have some spare time next week, and I'll see what I can come up with.

@gsrinivsn Got the same behavior and ran into similar problems: https://forum.netgate.com/post/1157259 This problem is from my perspective unrelated to the firmware version. If I`m not mistaken, it can happen after backup restore or reboot. The reason for this are described in the linked thread: tons of MAC addresses in the config file & DBs.