Multiple FreeRadius servers with one PostgreSQL backend

[Ruslan Kalakutsky]

>  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.

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.

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.

>> Automate deployment of radius service on
>> each IPSEC server easier than having another single point of failure.
>
>   You'll still have a single point of failure in the database.
Yes, but instead of two in case of centralized RADIUS.

>   If the IPSec servers are physically close to the database, this will work.  It's not a good idea, but it will work.
They will be close to each other.

>   If the IPSec servers are scattered around the net, this won't work.
>   You're almost always better off centralizing RADIUS, and having a database close to the central RADIUS server.  But if you think you know better, it's your network.

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?

Best Regards,
Ruslan.