Fwd: Bind radius client requests to a database
HI've the following freeradius configuration that I use to bind radius clients to a specific db. The problem is that I use a virtual radius associated to every db and I would avoid this. Is that possible to have a single radius instance listening and forward the request to db using radius client password (eventually contained in the nas table)? server rad1 { listen { ipaddr = * port = 1820 type = auth } listen { ipaddr = * port = 1821 type = acct } authorize { db_rad_1 dailycounter_db_rad_1 noresetcounter_db_rad_1 preprocess chap mschap digest suffix eap { ok = return } files expiration logintime pap totalbytecounter_db_rad_1{ reject = 1 } if(reject){ update reply { Reply-Message := \"SESSION TERMINATED - YOUR TICKET IS EXPIRED\" } reject } } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } digest eap } preacct { preprocess acct_unique suffix files } accounting { db_rad_1 exec attr_filter.accounting_response } session { db_rad_1 } post-auth { exec Post-Auth-Type REJECT { db_rad_1 attr_filter.access_reject } } pre-proxy { } post-proxy { eap } } sql db_rad_1 { database = "mysql" driver = "rlm_sql_${database}" dialect = "mysql" server = "localhost" port = 3306 login = "test" password = "test" radius_db = "radius1" acct_table1 = "radacct" acct_table2 = "radacct" postauth_table = "radpostauth" authcheck_table = "radcheck" authreply_table = "radreply" groupcheck_table = "radgroupcheck" groupreply_table = "radgroupreply" usergroup_table = "radusergroup" delete_stale_sessions = yes sqltrace = no sqltracefile = ${logdir}/sqltrace.sql num_sql_socks = ${thread[pool].max_servers} connect_failure_retry_delay = 60 lifetime = 0 max_queries = 0 group_attribute = "${.:instance}-SQL-Group" read_clients = yes client_table = "nas" $INCLUDE ${modconfdir}/${.:name}/main/${dialect}/queries.conf }
On Sep 22, 2017, at 9:49 AM, Ti Ti <tt91em@gmail.com> wrote:
HI've the following freeradius configuration that I use to bind radius clients to a specific db.
I'm not sure what that means.
The problem is that I use a virtual radius associated to every db and I would avoid this. Is that possible to have a single radius instance listening and forward the request to db using radius client password (eventually contained in the nas table)?
The SQL queries are customizable. You can write "if / then / else" statements in Unlang to select the database you're using, based on what client is coming in. Just write the rules: if (Packet-Src-IP-Address == client1) { sql1 } else if (Packet-Src-IP-Address == client2) { sql2 } It's that simple. Alan DeKok.
Hello, I've the following freeradius configuration that I use to bind radius clients to a specific db.
I'm not sure what that means.
The problem is that I use a virtual radius associated to every db and I would avoid this. Is that possible to have a single radius instance listening and forward the request to db using radius client password (eventually contained in the nas table)?
The SQL queries are customizable. You can write "if / then / else" statements in Unlang to select the database you're using, based on what client is coming in.
Just write the rules:
if (Packet-Src-IP-Address == client1) { sql1 } else if (Packet-Src-IP-Address == client2) { sql2 }
It's that simple.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Hello, I've the following freeradius configuration that I use to bind radius clients to a specific db.
I'm not sure what that means.
I mean that the requests and accounting of radius client that uses the password "pwd1" have to go the the sql1, the requests of client with password "pwd2" on sql2 and so on.
The problem is that I use a virtual radius associated to every db and I would avoid this. Is that possible to have a single radius instance listening and forward the request to db using radius client password (eventually contained in the nas table)?
The SQL queries are customizable. You can write "if / then / else" statements in Unlang to select the database you're using, based on what client is coming in.
Just write the rules:
if (Packet-Src-IP-Address == client1) { sql1 } else if (Packet-Src-IP-Address == client2) { sql2 }
It's that simple.
Alan DeKok.
In my case the clients can have dynamic IP, so I have to use tens of if statement to evaluate the client password? Are there different methods to achieve the result of binding the users?
On Sep 22, 2017, at 10:30 AM, Ti Ti <tt91em@gmail.com> wrote:
I mean that the requests and accounting of radius client that uses the password "pwd1" have to go the the sql1, the requests of client with password "pwd2" on sql2 and so on.
I have again no idea what that means. Perhaps using *standard RADIUS words* would be useful here.
In my case the clients can have dynamic IP,
RADIUS doesn't support dynamic IP addresses for clients.
so I have to use tens of if statement to evaluate the client password?
What is the client password"? Again, inventing your own terminology is not useful. It makes communication more difficult, ad it wastes everyone's time.
Are there different methods to achieve the result of binding the users?
Binding users to what? You've invented your own terminology to describe things. This makes it impossible to know what you really want. Alan DeKok.
2017-09-22 16:41 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On Sep 22, 2017, at 10:30 AM, Ti Ti <tt91em@gmail.com> wrote:
I mean that the requests and accounting of radius client that uses the password "pwd1" have to go the the sql1, the requests of client with password "pwd2" on sql2 and so on.
I have again no idea what that means.
Perhaps using *standard RADIUS words* would be useful here.
Sorry for the terminology. My purpose is to obtain this result: A NAS, so the radius client, make an auth or acct request to the freeradius server; this server has to discriminate the requests using the nassecret and them forward to the right sql database. Each sql database has its own radcheck, radactt etc.
In my case the clients can have dynamic IP,
RADIUS doesn't support dynamic IP addresses for clients.
Is it possible to use 0.0.0.0/0 on the nasname of NAS table of each sql
database?
On Sep 22, 2017, at 11:10 AM, Ti Ti <tt91em@gmail.com> wrote:
My purpose is to obtain this result: A NAS, so the radius client, make an auth or acct request to the freeradius server; this server has to discriminate the requests using the nassecret
That's not how RADIUS works. You can't accept packets from random IPs, and "check the secret". The secret isn't in the packet.
and them forward to the right sql database. Each sql database has its own radcheck, radactt etc.
What you want to do is impossible. Each client should instead set up a TLS connection to the server. That way they can be authenticated via certificates. Alan DeKok.
2017-09-22 17:30 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On Sep 22, 2017, at 11:10 AM, Ti Ti <tt91em@gmail.com> wrote:
My purpose is to obtain this result: A NAS, so the radius client, make an auth or acct request to the freeradius server; this server has to discriminate the requests using the nassecret
That's not how RADIUS works. You can't accept packets from random IPs, and "check the secret".
The secret isn't in the packet.
Thanks for the replies. Do you have any advice on what parameter can I use to discriminate the sql database instead of src-ip? As you described before *>if (Packet-Src-IP-Address == client1) { *> *sql1 *>*}* And in any case can I use 0.0.0.0/0 to accept packets from all the possible IPs?
Only if they've got the right secret. You need to check what each NAS is sending.... There may be something the request that you can key off for DB access... Eg if you have a decent deployment plan you might have the country or region locations or customer details etc alan On 22 Sep 2017 4:48 pm, "Ti Ti" <tt91em@gmail.com> wrote:
2017-09-22 17:30 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On Sep 22, 2017, at 11:10 AM, Ti Ti <tt91em@gmail.com> wrote:
My purpose is to obtain this result: A NAS, so the radius client, make an auth or acct request to the freeradius server; this server has to discriminate the requests using the nassecret
That's not how RADIUS works. You can't accept packets from random IPs, and "check the secret".
The secret isn't in the packet.
Thanks for the replies. Do you have any advice on what parameter can I use to discriminate the sql database instead of src-ip? As you described before
*>if (Packet-Src-IP-Address == client1) { *> *sql1 *>*}*
And in any case can I use 0.0.0.0/0 to accept packets from all the possible IPs? - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
2017-09-22 18:29 GMT+02:00 Alan Buxey <alan.buxey@gmail.com>:
Only if they've got the right secret.
Every nas will have its own right secret.
You need to check what each NAS is sending.... There may be something the request that you can key off for DB access... Eg if you have a decent deployment plan you might have the country or region locations or customer details etc
alan
We have all the details but some clients have dynamic IP on wan side. Perhaps the "called id" could be used as unique string to discriminate the nas and so forward the requests to the right db?
participants (3)
-
Alan Buxey -
Alan DeKok -
Ti Ti