That will be Calling-Station-ID attribute:

DEFAULT   Calling-Station-ID =~ ^192.168.100 , Auth-Type := Reject
                 Reply-Message = "Let them know what's going on."

you probably don't need to escape the dots with backslashes. Not sure if
you need " before and after regexp.

Ivan Kalik
Kalik Informatika ISP

Dana 15/3/2007, "Sam Schultz" <[EMAIL PROTECTED]> piše:

>I'm not sure what that "cli" value is. Have you checked the radius
>attributes page to see if it is standard? If you have any way to
>pull that information to the radius server external of freeradius,
>I suppose you could use the exec module. I doubt it would be
>efficient at all, though.
>Looks like your best bet is to pour through your radius debugging
>logs, and see if you can find a radius attribute that has what you
>need in it. If you do happen to find one, my previous suggestion
>would be easy enough to modify to accommodate.
>On Thu, 15 Mar 2007 13:09:06 -0500 "Capelle, Mark (PCMC-GB)"
>>Actually, I don't think this will help since the wireless
>>controller IP
>>that freeradius "sees" is *not* in the 192.168.100.* range.  This
>>controller uses LWAPP, so the IP ranges that the wireless networks
>>are totally contained within the wireless infrastructure, which
>>that the NAS IP is actually the LAN IP address of the controller.
>>Again, it appears the only way for my to determine that the client
>>request is coming from the wrong subnet is via the "cli" value.
>>Cisco would just fix the guest wireless implementation to only
>>look at
>>the internal database or give you an option to specify this, all
>>be well.  But... since they don't, I have to figure out how to
>>RADIUS for one subnet and yet allow it to function for the rest.
>>-----Original Message-----
>>From: Sam Schultz [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, March 15, 2007 12:46 PM
>>To:; Capelle, Mark (PCMC-GB)
>>Subject: Re: Reject authentication attempts based on "cli" value?
>>An entry like this in your 'users' file should work:
>>DEFAULT     NASIPAddress =~ "192.168.100.*"
>>            Auth-Type := Reject
>>I'm not sure '*' is the appropriate regular expression character
>>for freeradius, but you should be able to verify that pretty
>>from the documentation. Operator information itself can be found
>>On Thu, 15 Mar 2007 11:23:23 -0500 [EMAIL PROTECTED] wrote:
>>>It is a Cisco WLAN 4402.  For reference, here is a log entry from
>>>a user
>>>connecting from the Guest network:
>>>   Thu Mar 15 07:10:52 2007 : Auth: Login OK: [guestuser] (from
>>>PCMCWLANCTRLR1 port 0 cli
>>>And here is a log entry from someone connecting via 802.1x on
>>>   Thu Mar 15 07:26:36 2007 : Auth: Login OK: [DOMAIN\\guestuser]
>>>client PCMCWLANCTRLR1 port 1 cli 00-12-F0-19-6E-B3)
>>>As you can see the only way I have to differentiate these two
>>>is via the "cli" value.  192.168.100.x is the subnet range of my
>>>network.  I want all auth attempts from 192.168.100.x to be
>>>Hope someone can help me out with this.
>>>>Date: Thu, 15 Mar 2007 10:55:55 -0400
>>>>From: "King, Michael" <[EMAIL PROTECTED]>
>>>>Subject: RE:
>>>>To: "FreeRadius users mailing list"
>>>>     <>
>>>>Content-Type: text/plain;    charset="iso-8859-1"
>>>>What manufacturer makes the NAS (the wireless controller?)
>>>>I would look to the Called-Station field.  Usually (Based on
>>>Cisco AP's)
>>>this is the MAC of the AP, followed by the SSID they connected
>>>>> -----Original Message-----
>>>>> From:
>>>>> g
>>>>> [mailto:[EMAIL PROTECTED]
>>>>>] On Behalf Of [EMAIL PROTECTED]
>>>>> Sent: Thursday, March 15, 2007 10:48 AM
>>>>> To:
>>>>> Subject:
>>>>> I have a situation where I have a wireless controller that
>>>>> multiple wireless networks (vlans).? When the controller
>>>contacts the
>>>>> RADIUS server with an authentication request, it does so with
>>>the IP
>>>>> address of the controller as the client address.? The problem
>>>is I
>>>>> have a guest network that has lower security than my other
>>>>> networks.? The guest network has it's own user/password
>>>>> stored in the controller, but the way authentication occurs is
>>>that it
>>>>> checks RADIUS for the user first and assumes it will fail,
>>>>> use the internal database.? The issue with this is that if one
>>>of my
>>>>> users jumps on the guest network, they are authenticated which
>>>is not
>>>>> what I want to happen.? Looking at the logs, I noticed that
>>>>> guest network users have the IP address of the client in the
>>>>> field.? My guest network is a totally different VLAN and IP
>>>>> Is there a way to key off of the "cli" field and then make it
>>>so that
>>>>> all requests from clients with a specific subnet in this field
>>>are not
>>>>> authenticated?? This would stop my internal users from
>>>connecting, but
>>>>> allow the correct users (those in the internal DB) to still
>>>>> connected.
>>>>> Thanks.
>>>>>  CONFIDENTIALITY NOTICE:  This e-mail may contain trade
>>>>> privileged, undisclosed or otherwise confidential information.
>>>If you
>>>>> have received this e-mail in error, you are hereby notified
>>>that any
>>>>> review, copying or distribution of this message in whole or in
>>>part is
>>>>> strictly prohibited.
>>>>> Please inform the sender immediately and destroy the original
>>>>> transmittal. Thank you for your cooperation.
>>>>> -
>>>>> List info/subscribe/unsubscribe? See
>>> CONFIDENTIALITY NOTICE:  This e-mail may contain trade secrets
>>>privileged, undisclosed or otherwise confidential information. If
>>>you have
>>>received this e-mail in error, you are hereby notified that any
>>>copying or distribution of this message in whole or in part is
>>>prohibited. Please inform the sender immediately and destroy the
>>>transmittal. Thank you for your cooperation.
>>>List info/subscribe/unsubscribe? See
>>Click here for free information on nursing jobs, up to $150/hour
>Click for free info on online masters degrees and make $150K/ year
>List info/subscribe/unsubscribe? See

List info/subscribe/unsubscribe? See

Reply via email to