NAS-Group? - different replies to different NASes?

Adrian adrian at dsl4u.ca
Tue Feb 26 16:49:55 CET 2008


Hello Ivan,

All I'm hearing is that I need to go to version 2.0.  Maybe that is the next
step for me :)  
I will definitely consider that as it seems to be the only "simpler" option.

As for answering your question:
++++++++++++++++++++++++++++++++++++
Q: What? Tunnel attributes are going to be different for each user? Can you
explain in more detail how is that suposed to work.

A: I have a set of "master" tunnel attributes that I always have to send to
this Telco.  
i.e. Service-type, Tunnel-Type, Tunnel-Preference, Tunnel-password,
Tunnel-Server-Endpoint..etc
The way this Telco obtains these attributes is by sending the
Username/Password combination my way. (i.e. I need to authenticate
userxyz at telco.com).  Once I see that user come through from their boxes (3
Static IPs) I have to send back to them the tunnel attributes above.  Once
the tunnel attributes were sent, they establish an L2TP tunnel to my LNS and
my LNS now asks my Radius server again to authenticate the user.  So I see
the same userxyz at telco.com requesting to be authenticated.  Since I
currently cannot distinguish between NASes I am sending the same Tunnel
Attributes to my LNS which causes my LNS to try to initiate a tunnel back to
itself (because the Tunnel-Server-Endpoint attribute is the actual LNS).
++++++++++++++++++++++++++++++++++++++

My hope was to create a grouped response (with the tunnel attributes) to the
Telco's NAS IPs and create a different group response for my LNS IPs which
will exclude the Tunnel information and just include the basic
Framed-IP-Address. Framed-Route Attributes.  Since the common factor here is
the Username/Password combination I have a hard time assigning the same
username/password to multiple groups unless I distinguish between the NAS
Groups first (ie Telco's NAS versus my NAS). Based on the RLM_SQL
documentation the first table the authentication hits is the radcheck table,
then radreply and then the usergroup table.  If there are any changes to be
made, I think it first has to be done in these tables somewhere.

That's my dilemma,

Adrian

-----Original Message-----
From: freeradius-users-bounces+adrian=dsl4u.ca at lists.freeradius.org
[mailto:freeradius-users-bounces+adrian=dsl4u.ca at lists.freeradius.org] On
Behalf Of Ivan Kalik
Sent: Tuesday, February 26, 2008 9:22 AM
To: FreeRadius users mailing list
Subject: RE: NAS-Group? - different replies to different NASes?

>I think I might have another issue, as per the documentation the first item
>to be checked is the radcheck table for any attributes.   Since my user
>exists in there I don't think the request will fall through to the
>radgroupcheck table anymore.
>
It will. In 2.x groups are handled properly in sql and you can separate
groups on bases of NAS-IP-Address.

>The issue becomes more complicated since I want to send the LAC a different
>response, on the same user, than my LNS.
>

So configure the replies in radgroupreply.

>What if I add another column in the radcheck table that is called
>"NAS-Group" for example.  Then modify the sql.conf (I suspect a SQL
>statement in there) to do a check against that new field for allowing
>authentications?
>Also, if at the same time I add a new column in Radcheckgroup (or maybe in
>the nas table) that has the same field name as the "NAS-Group" above and in
>there I assign each LNS/LAC a NAS-Group Identifier?
>
>Will that even be remotely possible?
>

Not like that. Since NAS-Group is not in the request how are you going to
check it? You can check (a single) NAS-IP-Address that way. But there is
no dire need to do that since you can check it as an attribute.

If there are multiple addresses you will need to use regexp or huntgroups.

>Remember, my original problem is that I need to send the Telco's Proxy
>Radius (based on an individual user) a specific set of attributes that will
>be passed on to their LAC. 

What? Tunnel attributes are going to be different for each user? Can you
explain in more detail how is that suposed to work.

Ivan Kalik
Kalik Informatika ISP

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




More information about the Freeradius-Users mailing list