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.