- Freeradius-Users - lists.freeradius.org

From inner to outer
by Roland Hedberg 11 Oct '11

11 Oct '11

Hi! I have the following problem. A module I have written uses the inner tunnel User-Name to find information about the user from an outside source. This user information must be returned in the outer tunnel. Is this doable ? I can think of two ways of doing this: 1) The module while running in the inner tunnel context puts the inner User-Name somewhere where the module when running in the outer tunnel context can pick it up and do the external source lookup. 2) Do the external source lookup in the inner tunnel context and then put the found information somewhere where the module while running in the outer tunnel context can find it. I'd prefer the later. -- Roland

3 2

Re: Local Auth if Proxy Auth fails ---OR--- Proxy Auth if Local Auth fails
by "Яцко Эллад Генна дьевич (ngs)" 11 Oct '11

11 Oct '11

Hello! Is it possuble to use another Auth-mechanism if primary Auth failed? The below is what I meant: 1) NAS -> FreeRADIUS: User/Password 2) FreeRADIUS - Does User exist in Local DB? 3) If "yes" - Access-Acept! 4) If "no" - Are any Proxies configured? FreeRADIUS -> Proxy: User/Password 5) Proxy answers, FreeRADIUS translates the answer further to NAS. Kind regards, Ellad Yatsko

3 9

about Simultaneous-Use and Multiple NAS
by Dagia Dorjsuren 10 Oct '11

10 Oct '11

Hello, Anyone advise me for my below problem pls. How to configure simultaneous login count for each NAS? for example : there is one account and 2 NAS like NAS1 and NAS2. That account's total simultaneous login count is 2. So, there is that account's first simultaneous login must be from NAS1 and second simultaneous login must be from NAS2. Thanks,

2 1

Re: Dynamic Attributes Based on NAS Type !
by Alan DeKok 09 Oct '11

09 Oct '11

Stefan A. wrote: > I never talked about sending policies to the NAS. That *was* the subject of conversation. If you're not going to talk about that, start a new thread. > The question was, what would be the recommendation, if the RADIUS client is > a RADIUS Proxy server (..in between the original NAS and my FR...) > In that case, "%{client:nas_type}" won't work, because it would always be > the same (... proxy server....) Uh... the "nas_type" field is whatever you want. Put in "nas_type = proxy" for a proxy server. You can then key off of that, and send *no* NAS-specific attributes back. > Would one use "%{NAS-ID}" instead of "%{client:nas_type}"? No. The NAS-Identifier is created by the NAS, which may be 2-3 hops away from the proxy. Alan DeKok.

2 1

Dynamic Attributes Based on NAS Type !
by Suman Dash 09 Oct '11

09 Oct '11

Hi Everyone ... Currently i am planning to integrate freeradius with different NAS like Chillispot , Cisco etc and enable roaming users so that they can log in from any of the NAS. As the reply items are different with different NAS , i am looking for ideas how to enable a single user to roam and connect from different NAS. In my case i think static reply items are not possible per user wise or per groupwise so my question is what trick can be used to achieve the same. I had not tried anything as i have no clue on the same so some highlights on the approach will be a good starting point for me. Cheers Suman

5 6

Re: Dynamic Attributes Based on NAS Type !
by Alan DeKok 09 Oct '11

09 Oct '11

Stefan A. wrote: > What would you recommend to do, if your client is a proxy server? NAS-ID? No. Don't send policies back. You don't control the NAS. So you have no business sending it NAS-specific policies. > Nice idea, as long as a NAS vendor does not introduce another or additional way(/attribute) to do things in never NAS OS Versions. > In that case you would possible get in trouble if you have both NAS OS versions in your network and feed them with mixed attributes. > Starent did this in the past, where they had a bunch of QoS attributes in one Version and a single Attribute (177) to handle them all at once in never versions. Yes, well, NAS vendors have been known for doing weird things. Hence RFC 6158. Alan DeKok.

2 1

Re: Dynamic Attributes Based on NAS Type !
by Alan DeKok 09 Oct '11

09 Oct '11

Stefan A. wrote: > If you read it ‚one of the ideas of having different virtual servers is > separation of policies for different NASses’ you are right. > > Suman was asking on how to send several NASses into the same policy. The simplest way to do it is to set *generic* policies, and then re-write them in post-auth. For example, define a "Policy-Name" attribute in the dictionary, and set it somewhere in the "authorize" section. Then: post-auth { ... if ("%{client:nas_type}" == "foo") { // map policies for client foo } elsif ("%{client:nas_type}" == "bar") { // map policies for client bar } ... } The underlying issue is that different NAS vendors have defined different attributes for the same functionality. An even simpler solution is to just return all of the VSAs to each NAS. As was said earlier, each NAS will ignore the ones it doesn't understand, and apply the ones it does. Alan DeKok.

3 2

Re: Dynamic Attributes Based on NAS Type !
by Suman Dash 09 Oct '11

09 Oct '11

To be specific , I am concerned about the QoS VSA's . For Example. Mikrotik NAS - Mikrotik-Rate-Limit Chillispot - Chillispot-Max-UP , Chillispot-Max-Down Cisco - Cisco-Policy-UP , Cisco-Policy-Down Now if the user logged from different NAS's the VSA will differ so it is not possible to have a single entry in radgroupreply or radreply pertaining to a kind of NAS. I guess that this is not an out of the box feature in freeradius , instead i need to use some kind of custom script in Post-Auth section which will check the NAS Type and reply out the correct VSA's I am looking for a unique identifier from NAS by which freeradius can understand what type of NAS it is. I tried it and it seems that i have no control on the Access-Request sent by NAS to freeradius. The only idea which currently comes into my mind is to use nas.type value in DB but incase the NAS Type is incorrectly specified reply attributes will go nuts . So any idea if there are any unique identifiers ? Regards Suman On Sat, Oct 8, 2011 at 9:40 PM, Stefan A. <a.freeradius(a)premit.de> wrote: > ** ** > > Suman,**** > > As you did not say anything about the exact attributes, you will send to > the NAC, here is how we do this:**** > > ** ** > > we are also using different NAS and have to reply with different VSAs for > setting up the QOS.**** > > We use the “existence of a specific VSAs” (specified per NAS type) in the > request to select the VSAs to be used in responses.**** > > ** ** > > e.g: if we found the Starent Networks VSA ‘SN-Service-Type’ in the request, > we reply with ‘SN-QOS-Profile’ to set up QoS**** > > This is save, as we won’t see any Starent VSAs in Cisco or Chillispot > NASses.**** > > ** ** > > To make this flexible, we have set up our own VSA to configure users QOS, > which is then translated into the specific reply attributes for the NAS, the > user is currently using.**** > > ** ** > > Regards**** > > Stefan**** > > ** ** > > *From:* freeradius-users-bounces+a.freeradius= > premit.de(a)lists.freeradius.org [mailto: > freeradius-users-bounces+a.freeradius=premit.de(a)lists.freeradius.org] *On > Behalf Of *Suman Dash > *Sent:* Saturday, October 08, 2011 4:40 PM > *To:* FreeRadius users mailing list > *Subject:* Dynamic Attributes Based on NAS Type !**** > > ** ** > > Hi Everyone ... Currently i am planning to integrate freeradius with > different NAS like Chillispot , Cisco etc and enable roaming users so that > they can log in from any of the NAS. > > As the reply items are different with different NAS , i am looking for > ideas how to enable a single user to roam and connect from different NAS. > > In my case i think static reply items are not possible per user wise or per > groupwise so my question is what trick can be used to achieve the same. > > I had not tried anything as i have no clue on the same so some highlights > on the approach will be a good starting point for me. > > Cheers > Suman > > **** > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > >

3 2

canceling/redirecting realm in pre-proxy ?
by Robert Roll 08 Oct '11

08 Oct '11

There seems to be some comments about being able to "cancel" a proxy in the pre-proxy section.. # When the server decides to proxy a request to a home server, # the proxied request is first passed through the pre-proxy # stage. This stage can re-write the request, or decide to # cancel the proxy. What I really want to do is test some variables (unlang) and based on the outcome, I want to actually handle the request locally rather than proxy. Maybe this is obvious, but I am not seeing it ? Thanks, Robert

3 6

git.freeradius.org
by James J J Hooper 07 Oct '11

07 Oct '11

Hi Alan et al, I'm having trouble getting FR by git (was previously working): $ grep url .git/config url = git://git.freeradius.org/freeradius-server.git $ git pull origin v2.1.x:v2.1.x fatal: The remote end hung up unexpectedly Is there an issue with git.freeradius.org? (Is anyone else having the same issue?) ... or is it just me? -James

3 2