Yup. Also in 25.11: [25.11-RC][admin@6100.stevew.lan]/root: pfSsh.php playback pfanchordrill cpzoneid_2_allowedhosts rules/nat contents: hostname_0 rules/nat contents: pfctl: DIOCGETRULES: Invalid argument pfctl: Anchor does not exist. Did you open a bug for this yet?

@EDaleH Thanks for your input on this matter. This issue is not related to the DHCP server, especially KEA DHCP. We are still on pfSense 2.6 as mentioned, so ISC DHCP is in use, and there are no lease problems. Lease times are already configured correctly. The core reason that @Gertjan pointed out is correct and seems to be the right direction to get this resolved. It doesn’t affect everyone, but systems under heavy load during peak hours are the ones that usually run into it. The issue is a race condition under load. If the pruning process takes a long time to enumerate and remove old entries, and a new session or disconnection occurs, or if the process is interrupted or times out, the lock file may remain or the process might not finish its database write cleanly. This can leave the system in a partial state where the voucher record is removed but the session is still present. I also believe this issue also exists in pfSense+ since the captive portal code is same in the areas related to this behavior.

@Leksandr hi hope you are doing well.i read your post.pkease can you share your work as i have one such requirement. We will ask some info and use that . To give a demo I am ok if the information gathered from user is stored in the local file in pfsense. Much appreciated it

@Gertjan Thanks for taking the time to respond here For some context: I manage the gateway/firewall remotely for an IT admin who reports the issues to me. Not really sure what was going on at the time. The fact that the portal landing page was not appearing across the entire network but then would appear again after I would login to pfSense and hit 'save/Apply Changes' in the captive portal settings, remains a mystery to me. At the time the version was 2.8.0 but I upgraded to 2.8.1 as soon as I could. It seems stable now but will report if the issue comes back.

@Gertjan said in IPv6 support for Captive Portal planned?: @anakha32 said in IPv6 support for Captive Portal planned?: have multiple routed subnets behind our captive portal. KIS : keep it simple => make it more simple : one portal interface with one big switch and loads of APs all over the place and no more routers. If that's possible for you of cours. Btw : for my own curiosity : why placing routers on the portal network ? I'm part of a team that runs the network for a large university. The core of the network is all routed to limit the blast radius of problems. Each building has its own router with various networks on, including the guest wireless. But it makes sense just to have one captive portal box (pair), so all 300ish building subnets are routed through that. Perhaps one day there will also only be one wireless system in the university. At which point tunnelling all the guest wireless traffic back to one point might be feasible and the guest wireless could become one big subnet.

@Balooshy said in captive portal page with only voucher login: there is any way to make the page with only voucher authentication without using custom portal page? Short answer : no. You don't want this : [image: 1762158273441-57565a19-49ba-4083-b5cc-0c267c6de242-image.png] You don't want the User and Password fields to be shown. Info : I use Firefox. When I see this page, I hit Ctrl-U and then I see the 'source' of the page : [image: 1762158477799-3bb1e934-bf62-443f-8361-4b6e6c173c0b-image.png] Copy paste this file in an editor like Notepad++. Remove these two lines : <input type="text" name="auth_user" placeholder="User" id="auth_user"> and <input type="password" name="auth_pass" placeholder="Password" id="auth_pass"> <br /> Save the 'html' file. In pfSense, check this button : [image: 1762158665190-ebb231af-8803-4798-9a54-89eb058ad92b-image.png] and upload your file here : [image: 1762158695260-d86d5757-b891-46d4-8505-7ac0a39e1871-image.png] and Save.

@leonida368 pfSense has a captive portal which allows you to control who and how a pfSense LAN (the portal network) is accessed. This can be done with or without login credentials. A LDAP or (Free)Radius access, or ordinary pfSense users can be used. pfSense has no notion what so ever of what "Google Workspace" is. Look at these forum messages. Btw : IP addresses : these are the logged in devices. As pfSense gave these RFC1918, they are known. Device MAC addresses, these are know and logged by pfSense, but are normally randomized by every device. Traffic - Ethernet packets, can be logged, so you'll know the destination IP, the web site the portal user have visited. You will not be able to see 'what they did there'. You could use Traffic Monitoring tools, or IDS/IPS although the latter won't show much, as all traffic is encrypted (remember : https = TLS) these days.

@rds25 said in Captive Portal: Restrict Ports for Allowed IP Address?: As far as I understand, IPs listed under "Allowed IP Addresses" completely bypass the rules defined in the "PORTAL" tab. That's what I initially also thought. This is the portal rule that blocks all portal-to-LAN IPv4 traffic : [image: 1756797401971-c9aa3733-1739-40f8-b7cf-757f4f3abb37-image.png] I connected my phone to the portal, it got 192.168.2.10, and then I started to send ICMP packets to 192.168.1.33. While doing so, I was packet capturing on my portal interface for ICMP traffic, send by 192.168.2.10, my phone. I saw the packets, ICMP requests, coming in - but no answers logged. At the same moment, I was : [25.07.1-RELEASE][root@pfSense.bhf.tld]/root: tail -f /var/log/filter.log and I saw : ... <134>1 2025-09-02T09:15:05.661320+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,271,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1564 <134>1 2025-09-02T09:15:06.661321+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,52479,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1664 <134>1 2025-09-02T09:15:07.661337+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,19671,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1764 <134>1 2025-09-02T09:15:08.661389+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,9817,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1864 <134>1 2025-09-02T09:15:09.661321+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,17809,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1964 <134>1 2025-09-02T09:15:10.661336+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,16478,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,2064 <134>1 2025-09-02T09:15:11.661399+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,17854,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,2164 <134>1 2025-09-02T09:15:12.661402+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,34051,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,2264 ... which tells me that my firewall rule (shown above) was blocking my ICMP requests (to 1492.168.1.33). GUI equivalent : [image: 1756797907823-8d2a4a54-06d5-45d4-afb3-c5e359d61e79-image.png] The firewall log label is "LAN Block" so I knew which firewall rule was blocking, the one I showed above. This really makes me think that even when you Allow an IP address, the portal's GUI firewall rules still apply. As soon as I activated this first portal's firewall line : [image: 1756797755652-ed4331af-495b-42e3-ae7e-5464c718cba4-image.png] which allows ping packets from the portal interface to go to my LAN, 192.168.1.33, my NAS, ping packets came back / the NAS was replying.

oops... Sorry, did not see this question earlier. No, there is no Github repo for this. And unfortunately at least in v24.11 of pfSense+ the modified status pages do not work any longer. I am updating to 25.07.1 in the next days and will take a look about that. But I am afraid the the changes made in the status pages can not be modified in a short time. And time for this is currently one thing, I do not have. Regards P.S. Sept. 8th, 2025 Last weekend I did updatte my SG-3100 to pfSense+ 25.07 and checked the status voucher pages and all was running fine again. May be it was a bug in v24.11? Anyhow, all works at my appliance as expected.

If you must have reliable limits, better to run FreeRadius on a dedicated server (Linux or NPS on Windows) with proper SQL/LDAP backend. Also worth noting: since FreeRadius relies on MySQL/MariaDB tables for accounting, if those get corrupted you’ll see weird behavior with limits. In that case a tool like Stellar Repair for MySQL can help fix broken tables so accounting works again.

Yeah this use to be an issue, where once a new release came out updating packages could install package from new release even if you were on old.. But I thought that was addressed while back. From my understanding you shouldn't see new packages available for version Y when you are still on X.

@DominikHoffmann said in Forcing captive portal only once a week: Do I extend the DHCP lease to six days, or would this be handled by the idle and hard timeouts of the captive portal configuration page alone? First, the basic rule is : DHCP IPv4 leases are typically a day or two max. That's the sweet spot. If you need to change this, something isn't 'right'. Very long leases might do the trick, but be ware, you have a limited pool size, for example (my portal) : 192.168.2.10 to 192.168.2.254. (the first 10 are reserved for pfSense portal IP itself, and several APs), so 244 devices can be logged into my portal. If you only have a couple of devices simultaneously every week, and if the device connects back after one day (night) decides to give to the same device - connected yesterday - the same IP, as the lease is still valid, then you'll be good. If you have 'many' devices, and leases are "7 days" you might run out of free pool IPs. Even if you use "7 days" vouchers : when the device comes back and the lease was 'recycled' the IP will change. They have to re enter the voucher code again - and as it is still valid, the connection resumes. Or : use "auto MAC pass through" : [image: 1755079584371-4efaf598-9a82-4dcf-9225-ba8aa2a7bd0d-image.png] so when the user connects ones, his MAC will get add to the list - so no more login needed (that is, it still must receive the same IP / same lease all the time). You, at the end of the week, you throw everybody out manually from the MAC list : There is still one thing you need to be aware of : some users (devices) are totally paranoid, and regenerate their device Wifi MAC all the time. In that case they have to re logging all time - not your fault (I've seen this twice now ...).

@Elnatan And without MAC info, portal management becomes more like, a lame duck. It might 'work' but will only by IP based.

@Gertjan: My client has an ongoing relationship with a web development and graphic design firm. They programmed the image into the html code directly, by encoding it as base64. Makes it especially easy to handle in pfSense. They also skipped the fancy Google Analytics (?), fonts and external style sheet. It works really well now.

@Gertjan Is this english? @PierreFrench Sorry to revive this old topic but has there been any developments since this post? I am also interested in shortening voucher codes on newer versions of PFSense.

Maybe you have 'https login' set?

@LadiesMan217 @and those who do the same : Be aware that commenting this 'break;' will break "mac mask" support.

@Gertjan said in Strange (occasional) malfunction on captive portal and mac address whitelist: Do you use several portal instances ? Yes I use two portal instances: [image: 1750968051898-0314ffa0-fd0b-4c1d-959d-3371f62da1cf-immagine.png] The first one for guest users (MAC white list and vouchers) The second one use MAC white list and LDAP auth, Indeed, there have only been reports of problems on the first one and not on the second one (in relation to the MAC white list) but it could be that users use the former much more while the latter is little used except with authentication by LDAP working properly.

Hi may i ask if is this still works on latest pfsense 2.8