Limit users in the number of login to the captiveportal

vahidmoghadam

Hello,
I'm using CaptivePortal and FreeRadius on the pfSense.
I want to limit the users in the number of logins to the captive portal. I tried to use the concurrent connection option on the captive portal setting page but it's not useful,
In the concurrent connection option, there is a FirstLogin option. this option limits the users to one login and when a user logs in to the captive portal second user with the same username can not login.
I want this option but with a two-time concurrent login with the same username, not one.

Is there any way to have this option by making some changes to the CaptivePortal options or source code or even making changes to FreeRadius source codes or options?

Thanks

Gertjan

@vahidmoghadam

Ok if I use these words "captive concurrent freeradius" ?

Then click here on this icon :

edit : not sure if what has been said over there is still valid, but it will show you where to look.

EDaleH

@vahidmoghadam said in Limit users in the number of login to the captiveportal:

Is there any way to have this option by making some changes to the CaptivePortal options or source code or even making changes to FreeRadius source codes or options?

Look at Redmines 13843, 13844, 14118 and 14119.

If freeRadius is on the same server as pfSense, your issues with multi logins to a single user account are handled well on the freeRadius end if you want a single account accumulation of data quota for multiple users as long a reauthenticate connected users every minute is "on" and you have a small number of users. Time is not handled properly though. In order to accommodate these issues, we:

Modified the "reauthenticate connected users every minute" to use the interim accounting value instead (default 10 minutes). This makes it possible to handle hundreds of connected users as with a built in one second "sleep" in the reauthenticate routine the current pfSense code is very limited in quantity of users reauthenticating through freeRadius.
Removed the logout option from all custom login screens, the logout screen/popup is now a dashboard that relays time and quota remaining to the logged in user. This was done so that we could use a custom routine in captiveportal.inc that counts the number of currently connected users on a single account (ensure captive portal preserve connected users across reboot is checked). We can then cumulate the time for all users on that single account and terminate their session within the reauthenticate routine in captiveportal.inc based on the time quota assigned to the account. Terminating is done by simply looking up the max-octets file for that user, adding one octet to it and then writing that value to the used-octets file. The next reauthenticate check per login will now log out that user on that account (catching the rest within one "accounting interval"), as will their acutally reaching their data quota for that account as freeRadius is accumulating data usage correctly for multiple users on a single account. (Note freeRadius does not have a problem with 4096 GB quota limit, that is a pfSense issue so as long as no one reauthenticate session has exceeded that 4096 limit, it works fine)
We do not limit the number of users per account but the logic used to count users/account for tracking time could likely be applied as per the tunnel attribute discussion below. The authentication routine is also within captiveportal.inc. As there is no GUI entry to set the number of users, we would implement that through a file on disk and a simple http screen to edit and change it. Otherwise you would have to hard code it.

We are currently processing up to 200 logins on accounts with multiple users per account using this method and it has been working without issues for almost 2 years. Accounts have up to 1TB data quotas and typically 31 day time quotas and managed to the nearest interim accounting value (10 minutes). The captiveportal.inc file is different for plus than CE and you have to re-do/check the custom code for every release so this is not a simple solution to administer. Unfortunately there is no evidence that the referenced Redmines will be addressed any time soon, if ever. The Redmines address more than multi-users per account, there is the failure to respect the Tunnel attribute which allows freeRadius accounts to log into the wrong captive portal if you have multiple portals authenticated by freeRadius on a single server. We use custom code to check the day/week/month/forever attribute and only permit one captive portal to match that attribute. We then force a fail if the user account is not associated with the correct attribute, i.e. captive portal. A kludge but it works for us.

You asked if it could be done and your answer yes with limitations, the rest is in the Redmines referenced above.