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:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 12:46 PM To: firstname.lastname@example.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 [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 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" <[EMAIL PROTECTED]> >>Subject: RE: >>To: "FreeRadius users mailing list" >> <email@example.com> >>Message-ID: >> ><[EMAIL PROTECTED]> >>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: >>> [EMAIL PROTECTED] >>> g >>> [mailto:[EMAIL PROTECTED] >>> adius.org] On Behalf Of [EMAIL PROTECTED] >>> Sent: Thursday, March 15, 2007 10:48 AM >>> To: firstname.lastname@example.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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html