@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.

@neuf_16 Scrapped ? About about not using it ? I won't disable it , as it is working pretty well for me for the last 15 years or so. I'm using it for a hotel, and no instructions or guide lines are shown no where. People, more often then not, are total computer-illustrate but can still connect to the hotel Wifi, login (room number and password interpreted on their room key). That said, not all devices can work with a captive portal. More often because the owner made some 'DNS' related decisions, and/or installed so called 'security' software (apps) that totally make the device 'portal' incompatible. Not just the pfSense portal, but any portal, as they all work the same. In that case it isn't your portal's (or your) fault. It's their choice. As a firewall/router admin, part of your live will be : explaining people that they can mess up their DNS, but they will have bear the consequences. Example : July and August just came by, so I saw a lot of tourists. A guy had issues connecting with it's phone, while his laptop was doing fine. DHCP lease, etc, all was well, but no login browser screen would show up. After some inspection (Packet capturing on my = pfSense) side, I saw his device wanted to speak to "8.8.8.8" only. I didn't even asked if this was his own doing, or if it was the phone OS enforcing this behavior. So, yeah, so be it. I already learned I can't make everybody happy. Let's get into it : @neuf_16 said in Captive Portal Stops Working pfsense 2.8.0. Hitting 'save' resolves the issue: The experience from an end device is that it will have an IP via dhcp but the captive portal page will not appear. Try this. Have a look at them all first. I know, these video's are a bit old but still very valid. @neuf_16 said in Captive Portal Stops Working pfsense 2.8.0. Hitting 'save' resolves the issue: Device then has no internet and cannot ping the gateway As soon as the device connects to the portal network, using wire or wifi, it should (has to !) ask for a DHCP lease. On the captive portal interface you should have a DHCP up and running. DHCP isn't blocked by the 'captive portal' firewall rules. So : captive portal or not, DHCP should work as usual. If you use a Microsoft Windows device, type : ipconfig /all the result should tell you an lease IP was obtained, and the gateway and DNS should (must be !) the pfSense captive portal's interface IPv4. On a phone you can see the wifi details/status screen where the same info is shown. @neuf_16 said in Captive Portal Stops Working pfsense 2.8.0. Hitting 'save' resolves the issue: The gateway could not ping the device nor vice versa The device should be logged in. You have to pass (allow) ICMP on the portal's firewall GUI interface. Be ware that not all device reply to 'ping' when they are connected to 'unknown' networks. A Microsoft PC won't, for example. @neuf_16 said in Captive Portal Stops Working pfsense 2.8.0. Hitting 'save' resolves the issue: pfsense 2.8.0 Upgrade to 2.8.1. If the forum was littered with messages saying "don't install 2.8.1, stay with 2.8.0" you shouldn't stay with a version that contains 'old bugs'. Get the version with the new bugs, as these are all discussed right now, and workarounds have been found. Afaik, there are no 'real' portal issues right now. This said, I'm using 25.7.10, but the portal part of pfSense is identical to 2.8.1.

@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

@Gertjan This is beautiful. I've managed to get things working good enough to accomplish my first-level goals and turn it over to my relief so I get to go on vacation without getting emails about radius. And I noticed from my attempts earlier that as I was making changes trying to get SQL to update the Portal would stop working every so often and need to be restarted, so I'm going to leave things here for now. I was able to brute force a bash script that could calculate daily data usage as a percentage of the cap by poking around the datacounter directory and scp it to my desktop, and my relief will just have to live with the GUI user manager for a few trips. But when I get back and have more than a couple days I'm going to dig into why radacct isn't updating then work on these changes you've outlined. Being able to view and edit all this through SQL will be a huge advance. (No smart children onboard so I added pHPmyadmin to my synology immediately after MariaDB.) Thanks so much for this, I really appreciate it.

@regexaurus This usermod ? You have to re-polish your definition of pfSense pfSense maintains a (one !) system wide config. Nearly everything you see in the GUI is stored in this file. When the system boots, every system or process config file, for example the "GUI nginx web server" config file ( here : /var/etc/nginx-webConfigurator.conf ) is re-created with the GUI settings. Then the process (nginx) is started, and the GUI becomes active. The same thing is valid for system users. As you can see; under /home/, every portal user has actually a (limited) system account there. If you want to change delete or add a user, use the GUI. Everything you do with the command line will not be persistent, not taken in account, and undone when the related process restart. 'Real' CLI command is still possible, but you need to script things. For example, adding or modifying a user, see how the GUI does it. Know that, you know how to write your own script. It could be as simple as modifying the pfSense config.xml file, and then restart related processes.

@regexaurus said in Captive portal + DNS redirect: Yes, I have ACME set up to request/renew a TLS/SSL cert and added a host (A) record to Resolver, pointing to the captive portal interface, for the CN host on the cert. Under HTTPS Options for the captive portal, I checked/enabled the Enable HTTPS login option, entered the certificate CN hostname for the HTTPS server name, and selected the appropriate certificate from the SSL/TLS Certificate drop-down. After additional testing/tweaks, this seems to be working quite well @regexaurus said in Captive portal + DNS redirect: Adding the RFC8910 option seems to be a significant improvement Easy check to see what device is using the RFC8910 login method, obtained by the DHCP lease request. The rfc8910.php file, line 97, remove the comment : Change /* captiveportal_logportalauth("rfc8910", "EMPTY SESSION", $clientip, $cpzone); */ to captiveportal_logportalauth("rfc8910", "EMPTY SESSION", $clientip, $cpzone); and now you'll see all the request made for this rfc8910.php file. This will somewhat flood your captive portal authentication log. @regexaurus said in Captive portal + DNS redirect: but on one system (an iMac running Sequoia 15.4.1 + Google Chrome 136.0.7103.93), with Google Chrome as the default browser, sometimes the system wouldn't automatically load/display the captive portal login. Once when this happened, I manually opened Chrome and simply entered google.com in the address bar. When I did so, this appeared: Upfront : I use Apple devices like ipads and iphones. My latest Apple computer experiences dated from ... not sure, probably the the Apple II. Afaik, as soon as the device knows that it is behind a portal, as it will be aware of this as soon as it connects to a wifi or cabled network and the DHCP event will return a the option 41 ID = the URL to a file where it should connect to using a browser. On ipads and iphones, this is done automatically, as soon as the wifi connection to the portal SSID becomes active and a DHCP lease was acquired. On iMac OS : behavior could somewhat be different. Somewhat strange; imho, that you need to type in 'some' URL to force the browser's to show you the login page. The browsers knows their is a captive portal : it showed you the login URL The Wi-Fi you are using may require you to visit .... What was the URL you've shown ? Not the host name (I use portal.bhf.tld here on the forum, that isn't my real host name neither). What is the file ? index.html or rfc8910.php ? That's isn't a may .... the URL shows was obtained by the DHCP request and needs to be visited so a login page shows up, so the user (human) can identify. Btw : Chrome from Google. That's not -imho- a browser, more a system / user data collector. I'm a FF man, as long as it lasts. Be careful with commercial browsers, as they tend to not use the system (iMac, PC's) DNS, they go straight to their own DNS server, like 8.8.8.8, most probably using DoH or DoT, so the pfSense Resolver never sees their DNS requests. So pfBlockerng can't work ... DNSSEC can't work .... But, when a portal is used - present in the network -, this won't work. And because DNS doesn't work for them, they have a hard time dealing with portals. Rfc8910 should make live easier on us, but if the browser doesn't care, well, then nothing can be done to solve that. Well, something can be done. Like not using these kind of browsers

@Summer1000 said in CRASH REPORT CAPTIVE PORTAL: will uodate ? Oops. @Summer1000 said in CRASH REPORT CAPTIVE PORTAL: amd64 14.0-CURRENT FreeBSD 14.0-CURRENT and also : @Summer1000 said in CRASH REPORT CAPTIVE PORTAL: pfSense-Plus-snapshots-23_09_1-main I didn't spot the ancient software ... Yeah, suddenly : you experience ancient bugs. Good news : solved months ago ^^ And it gets better : I'm using the latest beta 25.03 version, with a captive portal, and it works great.

Ok that was too, quick it seems that this was my Phone cache. The page does not load the uploaded files. Not any of them. When i use the Preview of the page or use my phone or device, it shows a blank icon where it should show the logo or the background image. When i click on the Preview button the page opens and show the same behavior like the user Devices, http://192.168.7.1:8002/captiveportal-background.jpg.