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.

IMG_0049.PNG
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.

@maxkoning:

Thanks! But you didn't make this captive portal. You just edited it.

Kindly read all the contents. Thanks!