@scilek I work for a hotel and I use pfSense, and one the reason is : it has portal functionality build in. I'm using this pfSense portal for the last 10+years now. It works great. Why does a hotel needs a portal ? Because we all have probably have one thing in common : some one is responsible for the "Internet' connection" as people can do 'things' with a connection that can have legal consequences. And guess what ? As you don't know who did what, the subscriber of the connection faces the judge. So, to keep things simple : don't offer a portal. Never ever share a network connection with some one else. Share the connection only if you are will do do "time" for these people. This seems harsh, but is probably very valid for a family internet usage case : you are responsible for the actions and interactions of your kids after all. So : If you really want to keep things simple : do NOT share your Internet (phone, credit card, passport) connection. If you really have to, start by looking up possible (legal) consequences. I think a universal concept is : you won't be able to say "I didn't know". It's like driving : you can buy a car, and you will need assurance and a driver license. Exception : you drive on your own 'land', not on the public roads. For a company's connection : the stakes are probably even higher, as you really (can't) know who uses your portal connection. Consider this : use a separate Internet connection for your portal network, so if something happens, you don't lose all your Internet access. With all this out of the way, I can start answer your questions. A portal exists because it very unpractical to give everyone a WPA2 wifi access code. The pfSense portal doesn't care if portal clients are connected using Wifi or by wire. A wire connection doesn't have a WPA2 code anyway. When you change the WPA2 code, all connected clients will have to use the new one. And your own devices connected to the portal/wifi network need to be reconfigured with the new WPA2. This is why a 'captive portal' exists. Most often it's a 'open (!) Wifi connection, so an SSID and no WPA2 password. This is known as a scary thing, as traffic goes 'non encrypted' over the air, but this isn't the case in reality. As you've said already yourself, "http" web traffic shouldn't be used anymore. Like no where, and no exceptions. So : the portal login page can't be a "http" page. This means : a captive portal isn't free of charge. You need to rent a domain name, and this will cost you like what ? 5 $/€ a year ? Why a domain name ? Because you need to obtain a signed certificate, one that is recognized by all existing browsers. When you have this certificate, you can create a https portal login page (and also, why not, a pfSense GUI https access). The good news : you need the acme.sh pfSense package to obtain this eradicate, and it will be free. Ones setup, it's "for live" : no admin time needed. Fast recap : https is mandatory these days. http is dead. And because https means "traffic encrypted" the portal login phase is already not visible anymore over the wifi, so no one can see and 'steal' the login (or other) credentials. Now, you'll understad that this : @scilek said in Is it possible to create a multi-page custom captive portal?: not be bothered by the ubiquitous IT-illiterate users asking what to do with the browsers' "This certificate is not good enough so I refuse to open your page." warning. has to be rephrased as this : the ubiquitous IT-illiterate admins ... These days, if some one want to make a 'public' accessible web page (used by "IT-illiterate (portal) users", we all agree) , it has to https. Period. @scilek said in Is it possible to create a multi-page custom captive portal?: I'm not a fan of captive portal, I'm more of a FreeRADIUS person. Planes are not cars (both have tires, that's true). FreeRadius is not needed for the pfSense captive portal. It can be used to handle portal authentication if needed. Freeradius can be used if you want to 'totally NOT KIS' portal authentication. The build in pfSense user manager can handle your needs just fine. You don't need FreeRadius. Btw : be aware : the pfSense FreeRadius package offers about 5 % of the capabilities of what FreeRadius really can do. The rest isn't exposed in the pfSense GUI, so inaccessible. If you really want to use FreeRadius and have all the Radius tricks at your disposal, do not use the pfSense FreeRadius, but get the real FreeRadius, and inform pfSense to use that external (on a LAN ?!) FreeRdius server, and now you have full control. I do use the pfSense FreeRadius for my portal, because I said to myself "why not" ? I'm using for classic user/password access, nothing else, no fancy options. I might as well use the pfSense user manager. @scilek said in Is it possible to create a multi-page custom captive portal?: On that page, they had the "Register" button, which I clicked, which directed me to another page, where I registered myself. After successful registration, that page redirected me to the main login page, where I entered my credentials and then managed to log in Like what ? A portal user has to give his name ? mail ? Credit card ? Social security number ? If you want to use a portal for a company, here in France, you have a serious legal problem in less then a day. It's 2026, which means handling (== asking) really hard to manage. Most potential portal user will refuse flat out. It's ok to ask, but you have to store this info, give them access to this info so they can delete, modify etc this, at any time (that now a basic right for everybody I guess). Making such a system is ... daunting. I mean, big companies like amazon, netflix etc deal with this and it costs them boat loads of $/€. If they don't, they can't propose their services in that country (for me : that's all Europe and some other civilized countries). So : fast recap : do not ask people for their 'private' info. The perfect 'why not' : give a lawyer 50 $/€, and he'll talk you out if in 10 minutes. I'm not done yet, by far. I'll continue posting later on. Continued : You've probably seen this : [image: 1770382451035-121832e9-1d43-4418-835e-c98712b51757-image.png] and some post in this forum (use the search button on this forum ^^) that used a "web front", a database (like MySQL or Maria or MongoDB) behind it, so the potential portal user can (== "has to") enter info, after which a the page, after clicking a button, bring the visitor to the real (pfSense) portal login, where final 'authorization' is handled. You can also 'redo' the entire portal html script file (which may include PHP, so a lot is possible), and - I'm brainstorming now - with the installed MySQL client, you can make the login page 'communicate' with a back end database. Note : Just install the pfSense FreeRadius package, and you have the MySQL client PHP part installed as a bonus. But .... me thinking out loud again : All this was nice and simple when 'http' was used. These days, it's https. Now, roll the drums, no need to tell you you can not (shall not) redirect https pages to "some where else" - the client's browser will refuse that. This means, afaik, that you have to 'mod' the pfSense portal page where you do the data collection. More to come ....

Thank you for all these answers. We will look into this more closely.

@Gertjan ah so that's why mine won't work... I haven't found any solution yet... whereas with the old versions it worked...

@mpeterson0418 Be assured : my pfSense GUI is also only accessible from only the 'main' LAN, and not from the other non-trusted LANs which is a captive portal (I've a hotel here, that's worlds most none-trusted collection of network users ^^) and another LAN with 'other' stuff I don't trust like cameras and other "worse then Temu and Aliexpress"' combined stuff.

@Dmc it doesn't have to be easy then...

Ok, I fixed it out using my old test VM. Seems, that I am getting old . Yes, it was mandatory to write the voucher code first to a csv file. Then, only then, the qrcodes can be printed out. Regards

The pfctl error is already resolved upstream (and in 26.03).

@_malek said in I cannot used google analytics for captive portal: I know DNS and DHCP work as expected, but standard GA scripts seem completely blocked in this pre-auth phase. The device using the GA (?) script, or the GA script isn't portal aware. Be aware : most of the portal support isn't what pfSense does. The actual portal support must be build into the device you use. Most recent OS's are portal aware, but there can still be 'programs' (processes) that 'see' the Ethernet interface is 'up' so a 'Internet' connection' must be there. This is a wrong assumption. You don't do "Google Analytics" or anything else for that matter before the user has been authenticated on the portal. Like unlocking your phone before using it, or leaving the toilet before unlocking the door. @_malek said in I cannot used google analytics for captive portal: or is it technically impossible due to browser/portal restrictions? A good browser is portal aware by itself. Stupid browser plugins might exists that break this. That's not new. @_malek said in I cannot used google analytics for captive portal: or is it technically impossible The portal can have "Allowed IPs" and "allowed host names" lists : these two destinations types - both are eventually the same : a list with IPs - will pass through the portal firewall even when the user (device) hasn't been granted portal access yet. So it's a matter of 'find all the IPs' and your done. The thing is : you want to use services from the "big ones" (Meta, Google, Microsoft, Apple, etc) and that is hard. These guys have thousands of IPs, entire AS sections, and they swap them in and out all the time. Basically, what you are trying to do isn't the correct way. If you have to use "Google Analytics" because, for example, you sold your user's device Internet usage to Google, don't put these devices behind a portal. Or tell the users that they should connect first, and then and only then they can do what they have to do. Like : before driving a car, they have to start it first. They'll understand. The portal is just a concept that gives you the control "who us using your Internet resources". For example, I have a hotel, so I want to offer an Internet connection to my hotel clients as an extra service. Not everybody surrounding the hotel. After all, I am still somewhat (more or less) responsable for what these stranger 'do' with 'my' connection. Ones connected, the entire 'Internet' opens up for them. They can even launch nukes if they have the credentials to do so. What they are doing isn't my business. If needed, I can route all portal traffic out over a VPN connection, so my hotel visitors , who use my ISP WAN IP (!) won't blacklist my (static) WAN IP. This rarely happens though, as the portal ads - I think - a strange effect to them : they think they are watched ^^

@_malek said in Tracking User Interactions in Google Analytics for a Website Opened via an iFrame from a Captive Portal: I added all required URLs (including google-analytics.com) to the Allowed Hostnames, Google Analytics still doesn't record any events When you add "Allowed Hostname" to the portal, a DNS lookup is performed and an ( 1 !! ) IPv4 is rteurn so the pf firewall can filter to 'allow'. Remember : a firewall can ='can't filter hos names. Just "IP addresses" (see for yourself : [what is in an Ethernet packet header]( what is in an Ethernet packet header)). Gues what : "Google Analytics" isn't one IPv4 - it changes all the time, as that site (service) is used by billions any moment thousands of times per second (everybody want to do Google Analytics for some reason) so the load is DNS pre distributed / balanced over a lot of (major understatement) IPv4 addresses. https://docs.netgate.com/pfsense/en/latest/captiveportal/allowed-hostnames.html : [image: 1763986053001-41301874-d0e5-4a18-a5fe-8d55e22431f6-image.png] If you manage to get them all, and you add all the possible IPv4s to the "Allowed IP Addresses" list, it might work.

@paulatz said in Skip captive portal for static ARP: some documentation Euh, it's open source. So everything you need to know is already there. No one ever wrote a book, guide or manual about these millions of lines of 'script'. If you know what 'PHP' is : ssh into your pfSense and start to discover. this will take you some time ;) If you want write scripts for a system, you have to know (some what) that system.

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

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