Proxy Server Deployment - Duplication of Radacct entries in the DB

[Alan DeKok]

On Nov 30, 2023, at 1:38 AM, Gabriel Marais <gabriel.j.marais at 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.