Does this show you : [2.3.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ps ax | grep 'prune' 15442  -  Is      0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1 15733  -  S        0:01.28 minicron: helper /etc/rc.prunecaptiveportal cpzone1 (minicron) 79162  0  S+      0:00.00 grep prune (show here what it show you, do not say : yes - don't paste images of what you see, copy-paste the lines) [2.3.4-RELEASE][root@LAN-GW.lan]/etc: ps ax | grep prune 31149  -  Is      0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_client.pid /etc/rc.prunecaptiveportal client 31312  -  I      0:00.18 minicron: helper /etc/rc.prunecaptiveportal asiakkaat (minicron) 31143  0  S+      0:00.00 grep prune So as you can see it is running. And i guess my problem really is that the DHCP lease time is less than captive portal idle timeout. Confusing that CP idle timeout is in minutes and DHCP lease in seconds. But yeah, im ok with vi, ssh and cli. But not good with coding, so the php is too complex for me. I used a portal idle timeout to great effect at a hotel. I only wanted them to be bothered by the portal once - even on a multi-day stay. I used an 18-hour idle timeout and a shorter DHCP lease time. I just made sure that the dhcp pool was large enough to accommodate the device churn through the property so the same lease was always available to give back to a device until they were long gone. As soon as the device left the property for 18 hours, the dhcp lease and the portal entry were both history. I was thinking about the same thing. Only once bothered, perhaps every 24 hours. I guess i just have to change the netmask to something larger first. Thanks alot. I'll see how the tweaking of DHCP and idle timeout affects :)

We are authenticating users against a radius server that connects to AD - as 99% of our users have accounts.  The rest we assign vouchers on a per-case basis. We have enabled "Enable Pass-through MAC automatic additions" and "Enable Pass-through MAC automatic addition with username" so they only have to authenticate once and then we have their username associated with their device.  The issue arises when we have more than 9000 separate device/username pairs in the db.  I know there are some php files that may help in pruning the mac auth table, just not sure which ones they are and what parameters to pass to them. In the past, I've just been deleting the mac auth table once a year (just before fall semester - we are a University) and then everyone has to re-authenticate.  But with the growing number of devices everyone has, we are easily exceeding 9000 records within a year.

Btw : I think that you never filled in what so ever, but our 'intelligent' browser will auto-fill some entries - check always everything before you validate a page. I didn't try to mess with cookies and stuff like that - just changed from my loved Firefox to Microsoft Edge… and it worked. There should be something wrong. So I decided to show all my steps just in case. STEP 1 - CREATE CAPTIVE PORTAL ZONE >>> X - Enable Captive Portal INTERFACES - OPT1 AUTHENTICATION METHOD - X LOCAL USER MANAGER/VOUCHERS Click SAVE - OK STEP 2 - ACTIVATE VOUCHERS Click over EDIT CREATED CAPTIVE PORTAL Click over VOUCHERS Enable    X - Enable the creation, generation and activation of rolls with vouchers Click SAVE - OK STEP 3 - CREATE AND GENERATE A VOUCHER ROLL Click over VOUCHER ROLLS Click over ADD Roll # - 0 (zero) Minutes per ticket - 10 (minutes only) Count - 5 (vouchers code) Click SAVE - OK - Voucher created - a new roll line appear at screen Click GENERATE - a button besides - asked for where to save a .csv file with vouchers codes - OK STEP 4 - CUSTOMIZE CAPTIVE PORTAL PAGE Click over EDIT CREATED CAPTIVE PORTAL Created a custom file VOUCHER.HTML to only ask voucher code ENTER YOU VOUCHER <form method="post" action="$PORTAL_ACTION$">         <======= DELETED THIS LINE FROM SAMPLE     <======= DELETED THIS LINE FROM SAMPLE </form> =============== Look down for HTML Page Contents / Portal page contents Click over SEARCH and load voucher.html Click SAVE - OK 5 - TEST It worked fine Thanks to all the community again !!!

Hi, You should tell us more, much more about your setup. Right now, I default to : your setup is wrong. You should correct it. Captive portal works fine for me for years now.

@mostafa.adel: only open when i am write any ip on URL like 8.8.8.8 This looks and smells like a DNS problem (DNS is the thing that translates domain names like pfsense.com to 2610:160:11:1000::18 (or the old fashoined IPv4, I guess it still exists). So, the ….. /  ..... continue to read here : https://forum.pfsense.org/index.php?topic=130521.msg723896#msg723896

@chek69: You checked you firewall ? well, as he said, … My start page, or any other page, opens immediately .... traffic (http https and - important - dns) works …. The default pfSense rule " let everything go out " should be in place. And the same firewall rule would be enough to make the portal work. I'm presuming of course, this still is a typical case of "My firewall doesn't work and I'm NOT showing you my firewall rules so you could NOT see why it doesn't work …" I connect a device to the LAN network Detail the connection please - is this by wire ? Or Wifi, and thus an AP is involved … Or : Others are uploading their own 'portal page' without knowing that "html" is not a human language, the slightest error will take everything down ... (the built in page works great). Help exists for many years already. This page will cover 99 % of all problem case : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting

Can you give us more informations

In your Captive Portal configuration, you 'll find Concurrent user logins = If enabled only the most recent login per username will be active. Subsequent logins will cause machines previously logged in with the same username to be disconnected.

Every wifi device that joins your network takes a DHCP lease whether they go through your portal or not. The pool size needs to be sized to accommodate your device churn and your lease times and your portal timeouts, hard or idle.

hello , tough able to login into the pfsense webconsole using  the ldap user by giving it the webcfg privileges , it just works.

@stinkfly: It seems like when you tick the authentication method as Local User Name/Voucher, you don't have a choice, you have to use all 3?  Is this correct? When using vouchers, guest do not enter a user name and password, just the voucher. Even if these fields are present on the login page, the voucher ID is the one that will be used. Of course, this ID is the only identification the system has when it shows who's online. @stinkfly: What's the benefit of using Freeradius over a local database?  Number of users will be < 100, so scale shouldn't be an issue Example : "FreeRadius" can instruct the portal for each user a dedicated bandwidth. Or : How long a user can connect … Or : .... (see Google "pfSense + FreeRadius) => Answer on first link : https://doc.pfsense.org/index.php/Using_Captive_Portal_with_FreeRADIUS

Are you using a wifi access point, or a router? If its a router, you are performing a nat before the Captive Portal.

It might be easier for you to use a Ubiquity access-point and cloudkey controller as you have staff that are non IT types. You can set up guest access with a hotspot and use an app on an iDevice, Android device or web browser to print vouchers. Just remember to create a firewall rule out the guest network to the cloudkey port 8880. I had a play yesterday and it was quite easy to set up, NB I have multiple VLANS and have now disabled the hotspot SSID.       [image: IMG_0049.PNG] [image: IMG_0049.PNG_thumb]

Figured it out. In my nas table in the database, I thought "nasname" was a name/description of the NAS. Turned out to be the IP address, so after changing that everything is working as expected.

That happens when the device thinks the page it was originally going to is the portal page itself. I have found that about the only way to defeat it is to use an after-authentication URL redirect. You could probably get clever and test if the redirect URL is the portal page and, if so, issue a redirect somewhere, else redirect to the original browser request page. Or just forget about trying to send them to the page they originally requested and do the after-auth redirect.