No subject

[markcapelle at pcmc.com]

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 use are
totally contained within the wireless infrastructure, which means 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.  If Cisco would
just fix the guest wireless implementation to only look at the internal
database or give you an option to specify this, all would be well.  But...
since they don't, I have to figure out how to break RADIUS for one subnet
and yet allow it to function for the rest.

-----Original Message-----
From: Sam Schultz [mailto:segfault90 at hushmail.com]
Sent: Thursday, March 15, 2007 12:46 PM
To: freeradius-users at lists.freeradius.org; 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 quickly from the
documentation. Operator information itself can be found on:

http://wiki.freeradius.org/Operators

On Thu, 15 Mar 2007 11:23:23 -0500 markcapelle at pcmc.com 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 client
>PCMCWLANCTRLR1 port 0 cli 192.168.100.101)
>
>And here is a log entry from someone connecting via 802.1x on another
>network:
>
>   Thu Mar 15 07:26:36 2007 : Auth: Login OK: [DOMAIN\\guestuser] (from
>client PCMCWLANCTRLR1 port 1 cli 00-12-F0-19-6E-B3)
>
>As you can see the only way I have to differentiate these two auth
>attempts is via the "cli" value.  192.168.100.x is the subnet range of
>my Guest network.  I want all auth attempts from 192.168.100.x to be
>rejected.
>
>Hope someone can help me out with this.
>
>Thanks.
>
>>Date: Thu, 15 Mar 2007 10:55:55 -0400
>>From: "King, Michael" <MKing at bridgew.edu>
>>Subject: RE:
>>To: "FreeRadius users mailing list"
>>     <freeradius-users at lists.freeradius.org>
>>Message-ID:
>>
><6641F169E241EA40B29DE7BFAD24674DA7A43B at EXCH2.campus.bridgew.edu>
>>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 to.
>>
>>> -----Original Message-----
>>> From:
>>> freeradius-users-bounces+mking=bridgew.edu at lists.freeradius.or
>>> g
>>> [mailto:freeradius-users-bounces+mking=bridgew.edu at lists.freer
>>> adius.org] On Behalf Of markcapelle at pcmc.com
>>> Sent: Thursday, March 15, 2007 10:48 AM
>>> To: freeradius-users at lists.freeradius.org
>>> Subject:
>>>
>>> I have a situation where I have a wireless controller that
>services
>>> 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
>wireless
>>> networks.? The guest network has it's own user/password
>database
>>> stored in the controller, but the way authentication occurs is
>that it
>>> checks RADIUS for the user first and assumes it will fail, then
>will
>>> 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 all
>the
>>> guest network users have the IP address of the client in the
>"cli"
>>> field.? My guest network is a totally different VLAN and IP
>subnet.
>>>
>>> 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 get
>>> connected.
>>>
>>> Thanks.
>>>  CONFIDENTIALITY NOTICE:  This e-mail may contain trade secrets
>or
>>> 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
>>> http://www.freeradius.org/list/users.html
>>>
> CONFIDENTIALITY NOTICE:  This e-mail may contain trade secrets or
>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
>http://www.freeradius.org/list/users.html
 CONFIDENTIALITY NOTICE:  This e-mail may contain trade secrets or
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.