Proxy Server Deployment - Duplication of Radacct entries in the DB

[Nick Porter]

On 30/11/2023 06:38, Gabriel Marais wrote:
> The problem now, as far as I can ascertain, is the duplication of
> sessions in some cases for the same "user name" and as far as I can
> tell this happens when a proxy server sends the accounting start
> packet to radius server 1 in the EU - the radius server adds the
> information to the DB with an unique accounting session id. When the
> interim update is received by the proxies and that interim update
> packet is sent to radius server 2 in the EU, the server then creates a
> new radacct entry in the DB with a new unique accounting id since it
> cannot find an existing session in the DB with the unique accounting
> id created by the radius server that first received the start packet.

The root of your issue is likely to be the calculation of the accounting 
unique ID.

In the stock FreeRADIUS configuration, this is done with the acct_unique 
policy found in policy.d/accounting.

Take a look at the attributes which are being used to create the MD5 
hash stored in Acct-Unique-Session-Id - if those differ depending on 
which route the packets are taking, that will be your issue.

There are two solutions:

1) Use the insert_acct_class policy in your post-auth section to return 
a Class attribute in Access-Accept packets.  Correctly behaving NAS will 
return this value in all accounting packets and then the acct_unique 
policy will pick up this value for the accounting unique session id.

2) Amend the list of attributes being u

> Is there some specific way I need to modify my queries.conf files on
> the radius servers in the EU or some specific way I need to configure
> my proxies for them to better handle cases like this? My queries.conf
> file is the standard out-the-box config apart from adding some
> relevant 3GPP values to be written on accounting start and interim
> update packets into the DB as received from the carrier.

It is simpler to get a consistent unique accounting id rather than amend 
the queries - whilst there is potentially something that can be done 
with the queries, there are likely to be corner cases where things don't 
work as expected.

Nick

-- 
Nick Porter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20231130/87fe5b50/attachment.sig>