Hi Todd, I am using FR & MySQL and have the following in my radgroupcheck table to limit my dialup customers from connecting to my dsl aggregators. I have created different Groups (dialup & dsl for simplicity). In the dialup group I have rule that reads: ID: xxx GroupName: dialup Attribute: NAS-IP-Address OP: !~ Value: (xxx.xxx.xxx.4|xxx.xxx.xxx.2) This prevents any user in FR with a group of dialup from connecting to a NAS device with an IP of xxx.xxx.xxx.4 or .2 Hope this gives you an idea on where to limit your customers. Cheers, Jeff. -----Original Message----- From: freeradius-users-bounces+listacct=genhex.net@lists.freeradius.org [mailto:freeradius-users-bounces+listacct=genhex.net@lists.freeradius.org] On Behalf Of Paul Bartell Sent: Friday, December 19, 2008 1:26 PM To: FreeRadius users mailing list Subject: Re: Restricting dialup users to certain client definitions only You would use the Calling-Station-ID or Called-Station-ID checks in the groupcheck table. On Fri, Dec 19, 2008 at 9:48 AM, Todd R. <tjrlist@lightwavetech.com> wrote:

In a nutshell here is what I need to do, the long story is after the short version if you are interested.

########Short version##########

I want to restrict dialup users or a group of dialup users living within my MySQL tables to certain clients or list of clients.

So when a user who is only allowed access when coming from clients 1 and 2 dials in and the request comes from client 3 he is denied access.

I already do this with the crappy Windows based radius solution we have been stuck on for years, surely I can accomplish the same with FR.

Any help in a language which a total FR novice can understand would be appreciated.

######end short version########

########Long Version###########

I have read the docs, the archives, the readmes, the examples etc.

So far, I can't get a good handle on how to accomplish the following so I am again asking for some guidance from the list.

Here is my situation and what I need to accomplish, any help in getting this done would be most appreciated. I don't mind doing the footwork, research etc. to build a solution that will work but please keep in mind that I am a total FR Newb and need this in dufus language :)

For the last 8 years or so we have been using a dreaded windows based Radius solution that we just couldn't get away from due to how much code we have written around this horrible solution. Finally, it's time to just do it and deal with the pain.

What we have right now is several dialup wholesale networks/carriers/aggregators who proxy the radius request to us, we then decide to accept or deny the dialup user based on many things but of course username/pass etc.. One of the things we use to determine if they get access or not is which client they came from meaning which of our wholesale dialup network's radius server (client) sent us the request.

So, in short I need to accomplish the same thing on FR.

Let's say I have 5 clients, their short names and IPs configured in my FR clients file.

I need to somehow decide within FR when the request comes in from client #1 that this user (in Mysql table) is allowed to have access to that dialup network.

So:

Joeuser from client1 = OK (allow user) Joeuser from client2 = Not OK (deny user)

I am guessing I should do something with groups within the SQL tables such as assign joeuser to dialgroup1 which is then somehow allowed from client1 or for that fact clients 1, 3 and 5 but not allowed to client2.

I researched huntgroups but can't find much documentation on that, not sure if that's were I need to go or??

Regards, Todd R.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Random quote of the week/month/whenever i get to updating it: "Opportunity knocked. My doorman threw him out." - Adrienne Gusoff "At school you don't get parole, good behavior only brings a longer sentence." - The History Boys - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Just a clarification on my earlier response. I mentioned that I put the rule in radcheck when in fact I was putting it in radgroupcheck. Thing is, when I put it in radcheck it works. When I put the same rule in radgroupcheck, it fails. Example: radcheck Table: (This works and properly rejects the auth attempt if the client IP is not 5.6.7.21) ID: xxx Username: joeuser Attribute: Client-IP-Address OP: == Value: 5.6.7.21 radgroupcheck Table: (Does Not Work) ID: xxx GroupName: dialusers-t Attribute: Client-IP-Address OP: == Value: 5.6.7.21 Of course I also have joeuser assigned to the dialusers-t group in the radusergroup table. Regards, Todd R. -----Original Message----- From: freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius.org [mailto:freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius. org] On Behalf Of Todd R. Sent: Friday, December 19, 2008 3:30 PM To: 'FreeRadius users mailing list' Subject: RE: Restricting dialup users to certain client definitions only Jeff & List, Thanks, this seems fairly simple so I gave a whirl.. For the last two hours or so :( No joy.. Of course, it's entirely possible I totally missed your point. Here is what I tried: I have a user called "user" who is assigned to the "dialusers-t" user group in the "radusergroup" table. I am using NTradPing from my laptop located at let's say 5.6.7.8 which correctly shows up in the debug as Client-IP-Address. Now I wanted to test to see if I could put a rule (based on what you showed me) into the radcheck table and get a reject in my test client based on the fact that the Client-IP-Address I am connecting from with my test client is not the one allowed in my radcheck table for the group the user belongs to. Here is the rule: ID: xxx GroupName: dialusers-t Attribute: Client-IP-Address OP: == Value: 5.6.7.21 So, I thought that this would not allow a user from a client ip unless it was 5.6.7.21. So I tried to auth from my test client located at an IP address OTHER than 5.6.7.21 and I still get an accept. I have played around with different operators and such but still no luck. Any ideas? Thanks! Regards, Todd R.