Proxy Server Deployment - Duplication of Radacct entries in the DB
Hi Guys, I need some advice on setting up Proxies (correctly). Currently, I have two freeRadius servers in the EU and two proxies in Africa. The proxies are configured in a fail-over scenario pointing to the two freeRadius servers in the EU. We receive accounting packets from an upstream carrier which has a fail-over, and in some cases have a load-balance configuration on their side pointing to our proxies. Our proxies receive those packets and they are forwarded to the radius servers in the EU where all the "processing" takes place. The radius servers in the EU are connected to a MySQL cluster where we make use of accounting information for session and capping purposes. 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. 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. Thanks in advance. Regards, Gabriel
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
On Nov 30, 2023, at 1:38 AM, Gabriel Marais <gabriel.j.marais@gmail.com> wrote:
I need some advice on setting up Proxies (correctly).
Proxies should be pretty much transparent to RADIUS packets. i.e. they should forward packets, but not much else. There are very, very, few reasons for proxies to mangle the packets. That requirement means that it shouldn't matter which path a packet takes through the network. All of the possible paths just forward the packet without change, so all possible paths are the same.
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.
So, what's in the packets? You're looking at the database, and trying to debug RADIUS proxy issues. That's not going to work. Instead of looking in the DB, look at the packets. Use radsniff, tcpdump, or wireshark. Or use the "detail" module to dump packets to disk. Then, compare the packets, Packets taking path X look like ??? and packets taking path Y look like ??? But I suspect that's not the issue. The key thing for me here is that the start packets are treated differently than interim-update packets. The mostly likely cause of the different treatment is that the packets are different. Looking at the Acct-Unique-Id calculation (raddb/policy/accounting), we see: update request { &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}" } I suspect that that the values of those attributes are *different* between accounting "start" and "update". i.e. the start packet may be missing NAS-Port, but the update packet has NAS-Port. Again, don't waste your time looking at the database. Look at the packets. Nothing else will get you the information you need. It's why ALL of the documentation says "run the server in debug mode and look at the output". So go do that.
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.
The correct approach isn't "do some magic database thing to fix things". The correct approach is "understand what's going on, and then use that understanding to fix the problem". If the start packets are different from the update packets, then edit the Acct-Unique-Session-Id so that it only uses the attributes which are common to both packets. Perhaps User-Name and Acct-Session-Id. The default Acct-Unique-Session-Id policy uses more attributes, because some NASes re-use Acct-Session-Id across reboots. So if the defaults are to only use User-Name and Acct-Session-Id, some people will see problems. Maybe the NASes here create better Acct-Session-Id values, but are broken in that they don't send the same NAS-* attributes. It's RADIUS, every NAS is broken, Every vendor thinks that they're a genius, and that they don't need to fix anything. As the admin of the systems (or victim of the NAS vendors), you have to figure out what works for you, and what doesn't. The defaults in FreeRADIUS *mostly* work, but we can't document all of the "inventiveness" (i.e. insanity) of all of the possible vendors. We can only give general advice on *methods to solve the problem*. There is no magic wand. There's no "poke the queries and it will just work". You have to go through a methodical process to understand the problem, and then come up with a fix. Alan DeKok.
participants (3)
-
Alan DeKok -
Gabriel Marais -
Nick Porter