Request for assistance: FreeRadius configuration for split accounting of users into groups

Ahmad Gharib ahmadrg49 at gmail.com
Tue Apr 4 18:39:49 UTC 2023


Hi Alan,

Thank you for taking the time to answer my questions, and sorry for the
late reply.

The main deliverable was to extend FreeRadius as a AAA server to have the
ability of switching users between groups, trace per-group accounting for
the users (Check the usage of user A while being in group X, and in group
Y), and to apply traffic shaping actions based on the group assignment. The
groups being `limited` or `unlimited` in terms of connection speed in
OpenVPN.

I agree, the setup/deliverable is very complicated, but I have managed to
work around the limitations I faced with the usage of the PERL module
during "Start", "Interim-Update", and "Stop" accounting requests. It all
had to be custom made with the usage of Redis caching along with MySQL.

We aren't using FreeRadius policies as for now, but I'll check it for later
development.

If you need more information on the script and component logic, please let
me know and I'll share it with you. :)

You can consider this case as solved. Thank you. Regards

On Thu, Mar 30, 2023 at 5:17 AM Alan DeKok <aland at deployingradius.com>
wrote:

> On Mar 28, 2023, at 5:25 PM, Ahmad Gharib <ahmadrg49 at gmail.com> wrote:
> > We have configured OpenVPN with the OpenVPN Radius Plugin for
> > authentication and accounting, and we have connected it to a FreeRadius
> server.
> > Our aim is to split users into two groups, Premium and Limited, and
> > configure bandwidth throttling for them depending on their group.
> >
> > For Premium users, we would like to provide unlimited bandwidth without
> any
> > throttling. However, for Limited users, we want to provide free 1GB/day
> and
> > then throttle their connection if they exceed the limit.
>
>   All of these issues end up being local policy rules.   i.e. write down
> what you want the server to do, and then make the server do it.
>
>   If the server doesn't do what you want, it's because there's a
> disconnect between what you want, and what you told the server to do.
>
> > To achieve this, we have configured the PERL module as an External
> > Scripting functionality to check daily consumption and other metrics of
> the
> > user in "Acct-Interim-Updates." We use this functionality to control the
> > user's group by switching them from Premium to Limited and vice versa.
> > Additionally, we apply throttling to the OpenVPN server using tc.
>
>   Dynamic switching like this may work, but it can be a source of
> confusion.  What group is the user in?  Does their current profile match
> their group?
>
> > We also allow users to purchase tokens to top up their allowed bandwidth.
> > If a user exceeds their daily limit, their purchased credits allow them
> to
> > continue their internet usage without any additional throttling.
>
>   These are all complex local rules.  It takes a careful approach to write
> "unlang" policies which match the goals you have.
>
> > However, we are facing issues with the accounting per user group.
> > Specifically, we have noticed that if a user is now in the Limited group
> > and consuming traffic on a throttled connection, the daily_consumption
> > metric continues to add up, even if they have already exceeded their
> > allowed daily bandwidth.
>
>   The default configuration has none of these rules.  So if the rules
> don't do what you want, it's because of rules created on your local system.
>
> > For example, let's say a user has consumed 0.5 GB
> > in addition to their allowed 1 GB per day, which makes their total
> > consumption 1.5 GB/day. If the user then purchases extra credits worth
> 0.2
> > GB, their total allowed consumption would be 1.2.  GB/Day, however, their
> > actual. total daily consumption would still be 1.5 GB/day, which renders
> > the user in the same `limited` group and breaks the accounting purposes.
>
>   So write rules to check for this situation?
>
> > To address this issue, we would like to have split accounting for each
> > group. In other words, once a user is throttled, we want to ignore the
> > bandwidth recorded and only calculate the bandwidth consumed during their
> > Premium group connection.
>
>   You have to update the schema && the accounting queries to do this.
> It's not trivial.
>
> > It is important to note that the `acctinputoctets` and `acctoutputoctets`
> > values are pushed by OpenVPN-Radius Plugin as total incremented values of
> > the connection , and not interval values during each
> `Acct-Interim-Updates`.
>
>   Yes, that's how RADIUS accounting works.  The NAS has no idea what the
> rules are on the server side.
>
> > We would greatly appreciate any assistance or guidance on how to achieve
> > this goal. Thank you in advance for your time and expertise.
>
>   To be honest, this is all very complicated, and I'm still not quite
> clear on what you want it to do.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>


More information about the Freeradius-Users mailing list