RADIUS failing to start correctly when remote DB is unavailable.

[Alan DeKok]

On Jan 12, 2023, at 3:54 AM, Sea Gull <seagull0044 at gmail.com> wrote:
> Yes indeed. RADIUS Authentication and Accounting servers are two different
> physical machines,

  OK.

> which are connected to each other.

  How?

  I asked you to describe the system, and you don't do that.

> ...  Now the issue is that when the remote database is for any
> reason unreachable (could be firewall, maintenance, etc..) RADIUS will no
> longer authenticate users.

  Nick has told you how to help somewhat with that.

  But realistically, if the authentication server *needs* the remote database to authenticate users, then when it's down... no one can authenticate.  This is how computers work.

  If the authentication server doesn't need the remote database, then why is it using the remote database?

> So what I'd like to establish is if there's a
> way for RADIUS to continue with the authentication process of users without
> having them accounted for, when the remote database is unavailable.

  Either you're not describing what you have, or you're using the wrong words to describe things.

  Reading between the lines, what I *think* you mean is:

* RADIUS authentication and accounting are run on the same machine, by the same FreeRADIUS 

* the local database is used to authenticate users

* the local database is used to store accounting data

* the remote database is also used to store accounting data

  Then, when the remote database is down, the RADIUS server blocks trying to reconnect, and it can't make progress on anything.  So authentication stops working, because all of the SQL connections are blocked trying to write accounting packets.

  So if you describe the system accurately and correctly, it helps a lot.

  The solution here is "don't have the remote database go down".  If the remote database is necessary, then it should stay up.

  Another solution is to run a second copy of FreeRADIUS to write to the remote database.  See sites-available/decoupled-accounting.

  The idea is that the main RADIUS server doesn't write to the remote DB.  Instead it writes to a detail file.  The second RADIUS server then reads from the detail file, and writes to the remote DB.

  That way if the remote DB is down, the detail file simply gets bigger.  The main RADIUS server isn't blocked, and can continue running.

  But this is just a guess, because you refuse to describe what your system is doing, or how it's configured.

  Alan DeKok.