As you said :
You should "code" this yourself.

IF
you know how PfSense 'works"
AND
you can fnd /etc/inc/captiveportal.inc
AND
you can read/write PHP
THEN
you are close to a solution ;)
ELSE
No.

Hi,

That question is already being asked. About ones a week, in fact.

The short answer is : No.
A next best answer will be, knowing we all have a smartphone these days : On the login form, say to your clienst that they program a xx minuts timer.

you have to login on your captive portal that you made to gain access.

Hi,

I advise you to read  https://doc.pfsense.org/index.php/Category:FAQ : check out Captive Portal Pre-authentication Redirect.

Well, you can use two separate, synced authentication systems, though it's a bit redundant. How many users are you going to have on each network?

I dont think it can be done easily.

The SquidGuard Package allows you to:

Limit the web access for some users to a list of accepted/well known web servers and/or URLs only.
Block access to some listed or blacklisted web servers and/or URLs for some users.
Block access to URLs matching a list of regular expressions or words for some users.
Enforce the use of domain names/prohibit the use of IP addresses in URLs.
Redirect blocked URLs to an info page.
Redirect banners to an empty GIF.
Have different access rules based on time of day, day of the week, date etc.

Or just make two access codes. One that allows so little bandwidth 1-2 Mbps would pretty much allow just web browsing and email. Another access code with no bandwidth restrictions.

@Gertjan:

@PeterITG:

…..
With Pfsense the user has to connect then browse to a Http:// Site to get redirected.

When launching a https://…. you will NOT get redirected.
That's what https is all about.

Modern OS's (Windows, iOS, MacOS, etc) launch a hidden http://portal.microsoft.com or http://portal.apple.com or ...) when a Wifi connection is established. When the reply is redirected, a browser will open that shows you the "reply" : the portal login page.

I'm using pfSense in a hotel (read : NON-initiad clients end users). No one come down to the reception asking me why they can't acces sthe Internet. They will see the pfSense login page, they will hunt down the access password in mentioned on the papers present in their room, and they connect.

I never used "Antlabs Inngate, Nomadix, ValuePoint, and Unifi Ubiquiti". These are also "free-ware" solution ?

Yes I had allowed my DNS servers through the captive portal. So it was resolving the hidden OS checks so the captive portals weren't starting. So they weren't really being redirected till they tried a http site and most sites are https now. Our support know to have them try a http site but i knew something was wrong when it wasn't opening automatically.

Also those other devices are hospitality gateways that have the splash page, Integrate with a PMS system. Charged Tiered Bandwidth.

Why not set the hard-timeout in your captive portal settings directly? It's under Services/Captive Portal, then choose the CP instance and set the Hard Timeout setting to whatever you like.

The default form of Captive Portal already input the username, so you only create $username=$_POST['auth_user'] then echo $username;  :)

Hi,

Check out this page : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting
Execute the commands listed - and see the firewall rules numbers that ipfw is using.
The "64500" is a limit, you can't go (much) above.

Also note that " /var/db/captiveportaldn.rule" can not grow indefinitely. I guess it about 700 K when it starts, and depending on the length of the name(s) of your captive portal zone(s) is might double, maybe triple.

You can 'read' this file to understand its structure. Its a serialized PHP array.

The nasty thing :
Every time a user connected and passes through (== authorized) "pass" rules are injected in the firewall ipfw AND the rule set (two: "the numbers" and the "portal zone name") are injected into this array (which becomes a file called /var/db/captiveportaldn.rule on disk).
When the connections times out, the firewall rule is removed, and the corresponding entry  in to array is set to false (something like "").

All this reading and writing (updating) of this 1 (2 , 3 ?) MB file happens when users login AND are being thrown off the portal.

function captiveportal_free_dnrules($rulenos_start = 2000, $rulenos_range_max = 64500) {

Just one question : your system can keep up with it ?

OK. I've done the existing router setup before, so that's not difficult. I am going to do some reading up on the VLAN setup and test it out. Never done that before.

@johnpoz:

IOS still fails with badly configured wifi all the time.. Just ran into this.. Yes it tries to get you to the login page once you connect.. But gets sent to 1.1.1.1 from default cisco configuration and invalid cert which ios fails at and no way to just accept the bad cert so you can get login in..

Hummm.
That might be my saver over here : no Cisco devices or what so ever.
Just tried it again (I could post a vidéo !) :
I connected to one of my 4 portal Wifi radio networks.
I accept on my device (iPhone).
A couple of seconds, the (my) pfsense portal page pops up and I can login.

@johnpoz:

You would hope anyone that has ever used wifi would have the brains to figure out to go to http for portal auth, and or accept any cert errors when they are trying to auth, etc.  Your always going to run into that typical users that doesn't get it, never been to a hotel and used their wifi, etc.  So you can make it atleast less likely to cause problems.

True.
Except for the bad cert - I'm not using autosigned ones, but (free) certs from startssl, recognized by all browser as "ok".

People/clients do login by themselves https://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/portalusers.html  (noop, no doc in the building how to do so) and I'm not explaining them how to do so. It just works ….

Ok, so it is not an option in the default setup.  :-\ My hope that I could achieve this with freeradius or so.

Thanks for the reply!

I think you've had your answer already. Either post a bounty and wait for someone to pick it up, or just create a welcome page with the overall time available to your users posted there at the outset.

You could limit access to just a handful of sites by setting their client machines to a static address (or setting their DHCP server to assign a pre-assigned address) and setting an internal firewall rule. The more elegant solution would be to use a proxy server.

No.  Not it.  Because I have 4 boxes and they all experienced the same thing when I turned it on.  The 4 boxes are in different vlans.

Irritating!

@deltix:

Basically still doesn't work as intended. Correct? I can just forget I guess.

Define your 'intended'.
According to RFC and family, all is ok.
But, breaking https (SSL) connections isn't easy - but it can be done.
Like : a visitor is hitting the (your) portal with https://www.google.com - You generate a certificate (on the fly) that says your portal IS "google.com", and you better assure that a major certificate broker says that google.com is YOU (your portal). Then, the visitor's browser will be happy …. and your visitor can log in (would he really think he IS visiting google.com at that moment ?  ;)). When done, you portal will redirect the visitor the other, real google.com https site.
Can you pull this one off ?

Personally I think there's already enough + buttons on there and the added complexity of having to pick which portal it gets added to makes it even less desirable.

Hi,

That's where the hard- and soft timeout is all about  :)