Multiple FreeRadius servers with one PostgreSQL backend

[Alan DeKok]

On Jan 22, 2016, at 12:24 PM, Ruslan Kalakutsky <r.kalakutsky at gmail.com> wrote:
> 
>> Databases can have multiple clients reading and writing at the same time.  This is what databases do.
> I know it. The question is about RADIUS.

  Then ask a better question.  "Can I use one DB with multiple RADIUS servers" is a vague question.

  Ask a bad question, get a bad answer.

> E.g. if two servers authorize one user simultaneously and user have
> 'Simultaneous-Use' restriction with only one session than:
> 
> Scenario 1:
> - server 1 and server 2 creates two records at accounting table with
> AcctStopTime == NULL
> - server 1 and server 2 checks other records and each found that there
> are two records
> - both refuse to auth a user because of limits.
> Result: user can't auth on both servers.

  That's how Simultaneous-Use checks work.

Question: Why is this any different for two servers, than for one server where the user logs in twice?

Answer: if both servers use the same DB, it's not any different.

  This isn't a RADIUS question.  This is a database question:

Q: Will two clients querying the database see a consistent view of the database?
A: yes.

Q: Will one client querying the database twice see a consistent view of the database?
A: yes.

> Scenario 2:
> - server 1 auth user and checks if there a record at accounting table
> with AcctStopTime == NULL (success)
> - server 2 auth user and checks if there a record at accounting table
> with AcctStopTime == NULL (success)
> - server 1 creates an accounting record
> - server 2 creates an accounting record
> Result: user has two sessions instead of possible one session.

  This is a database question.  Not a RADIUS question.

Q: Will a client querying the database get a the correct answer to the query?
A: Yes.  Always.  That's what databases do.

  I'm not sure what you think will happen here.  The SQL queries in FreeRADIUS are just text.  Go read them.  There's nothing in them which is specific to the server which queries the DB.

> Just wonder why do you think it is a bad idea? WIll it be slower, more
> unreliable or any other reasons? We're going to have a dynamically
> scalable architecture with a number of VPN gateways from 1 to 100.  Of
> course, SQL server should be optimized to work with this load, but is
> there any reason to have centralized RADIUS?

  It's networking 101.

  If you have RADIUS servers scattered all over the planet, it's a *terrible* idea to have them connect over TCP to a central SQL server.  They should instead proxy RADIUS to a central RADIUS server.  UDP is much better than TCP for time-critical traffic.

  That's how RADIUS was designed to work.

  Alan DeKok.