Betr.: Re: [WIRELESS-LAN] Same Radius server, more than one SSID, different groups of users?
Nick, You want to keep the amount of SSID's flying around as low as possible. Why? http://revolutionwifi.blogspot.com/2010/10/limit-ssids-data-rates-to-maintain.html?spref=tw My 2 cents Best regards, Kees. Netwerkbeheer Avans Hogeschool Diensteenheid ICT en Facilitaire Dienst (DIF) - ICT-Beheer Bezoekadres: Hogeschoollaan 1, Kamer HG204 4818 CR Breda Postadres: Postbus 90116 4800 RA Breda E: cl.pr...@avans.nl T: 076-5238054 @rovinguser ( people move, networks don't ) Hanset, Philippe C phan...@utk.edu 9/19/2011 7:50 PM Nick, Most RADIUS servers will let you do that (freeRADIUS, RADIATOR, ACS...) If you want to separate users you can also Use the same SSID that you use currently And return an attribute item from AD that would Set the VLAN per user or per group of users. Philippe, eduroamus.orghttp://eduroamus.org University of Tennessee (using a tiny keyboard) On Sep 19, 2011, at 9:33 AM, Urrea, Nick urr...@uchastings.edumailto:urr...@uchastings.edu wrote: We at UC Hastings would like to create a new SSID that only allows certain users with WPA-Enterprise authentication to access. We currently have two SSIDs one which uses WPA-Enterprise with RADIUS which checks against and Active Directory group and the other which uses Web-Auth which checks against the same Active Directory. We are using the Cisco Solution for enterprise wireless. I would like to use the same RADIUS server for both WPA-Enterprise SSIDs. Any ideas? --- Nicholas Urrea Information Technology UC Hastings College of the Law San Francisco, CA, 94102 urr...@uchastings.edumailto:urr...@uchastings.edu help desk: 415-581-8802 helpd...@uchastings.edumailto:helpd...@uchastings.edu ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. --- Op deze e-mail zijn de volgende voorwaarden van toepassing: The following conditions apply to this e-mail: http://emaildisclaimer.avans.nl --- ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Wireless in dorms
On Mon, 19 Sep 2011, Lee H Badman wrote: At the risk of being seen as shameless in self-promotion, I just wrote a brief piece about Extreme Networks Snap On WiFi (built on Motorola under the hood) Altitude 4511. If you buy into the philosophy, and under the right conditions I would, no additional wiring needed beyond the Cat 5 already installed for Ethernet. There are a growing number of ways to skin the wireless cat, and if you are new to wireless the options are many and interesting beyond the controller based stuff. See http://www.networkcomputing.com/wireless/231601558 Sounds like the Brocade product, which I believe is also Motorola under the hood. We were shown it a few months back. It's a nice idea, although I agree with your comments that dual-band would be more useful. I wonder how far the time is before we say N is the future, b/g are no longer specifically provisioned and let it die off. My other concern is for those cases where you have a mix of wifi vendor technologies. For example you might like this Motorola product in some deployments, but otherwise be running C-word wireless or A-word wireless. Or perhaps with T-word wireless, you also want to deploy a Xirrus box in a particularly dense environment. How do you deal with managing these two sets of wireless network? Are there integration tools? Is roaming possible (or desirable?). Or, do we just say that we already have a number of management tools for different bits of the network anyway, so one more won't make much difference. To address some of the other points: we have just deployed one small wireless installation in half of one dorm that was refurbished this summer. Otherwise, while the residents might get a signal bleeding from surrounding buildings, there is a officially no wireless provision. In this day and age that's not a happy proposition, but we're looking to replace our wireless generally so do not want to spend large amounts of money we don't have until that's in progress. For the wired connections, we specifically prohibit the connection of anything other than an edge device to the network. We currently do dhcp-snooping, need to look at other things like unknown unicast limiting and port security for number of MACs. And we suffer from the dreaded IPv6 RA problem too, unfortunately our current switch hardware does not give us a built-in mechanism to filter those out, which means a tedious exercise of tracking the offender when we get the internet is down calls (when the network is otherwise clearly functional). Jethro. And Extreme's page on these at http://extremenetworks.com/products/altitude-4511.aspx Given that wiring can be as expensive as the APs, this sort of solution is at least interesting. -Lee Badman From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Oakes, Carl W Sent: Monday, September 19, 2011 12:49 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms Depending on your switch vendor, you can setup DHCP Trust, which says only certain ports can respond to DHCP requests. Solved the rouge DHCP problem for us instantly. :) (Our access layer is Cisco 3750). As for our wireless, we have Aruba deployed in our newer locations, and are in progress on the older buildings. Actually looking to use the students wired jack to activate the AP. We discourage via policy BYO Access Points campus wide, but don't enforce heavily in the non covered Res Hall areas, that will change as the Aruba deployment expands. Carl Oakes Network Architect California State University Sacramento (916) 278-5551 / oake...@csus.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ray DeJean Sent: Monday, September 19, 2011 9:11 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edumailto:r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie
RE: [WIRELESS-LAN] Wireless in dorms
Lee this is a really interesting article, and something we've been looking at as a UK Extreme networks customer. Have you experienced rolling these out to a dorm yet, as I'm quite interested to find out how low the DBI output can be dropped to, to see if is it practical to install 1 per room (with alternate 2.4Ghz and 5 Ghz radios.) so that on a corridor of dorms you have a large number of APs with signal limited (as much as possible) per AP to just a couple of rooms. Many Thanks Peter Mr Peter Methven, Network Specialist Information Technology (IT) Allen McTernan Building, Edinburgh Campus Tel: +44 (0)131 451 3516 For IT support queries or requests, please email ith...@hw.ac.uk mailto:ith...@hw.ac.uk or +44 (0)131 451 4045, with full details of your query or request and your contact details. http://www.hw.ac.uk/it From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: 19 September 2011 18:12 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms At the risk of being seen as shameless in self-promotion, I just wrote a brief piece about Extreme Networks Snap On WiFi (built on Motorola under the hood) Altitude 4511. If you buy into the philosophy, and under the right conditions I would, no additional wiring needed beyond the Cat 5 already installed for Ethernet. There are a growing number of ways to skin the wireless cat, and if you are new to wireless the options are many and interesting beyond the controller based stuff. See http://www.networkcomputing.com/wireless/231601558 And Extreme's page on these at http://extremenetworks.com/products/altitude-4511.aspx Given that wiring can be as expensive as the APs, this sort of solution is at least interesting. -Lee Badman From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Oakes, Carl W Sent: Monday, September 19, 2011 12:49 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms Depending on your switch vendor, you can setup DHCP Trust, which says only certain ports can respond to DHCP requests. Solved the rouge DHCP problem for us instantly. J (Our access layer is Cisco 3750). As for our wireless, we have Aruba deployed in our newer locations, and are in progress on the older buildings. Actually looking to use the students wired jack to activate the AP. We discourage via policy BYO Access Points campus wide, but don't enforce heavily in the non covered Res Hall areas, that will change as the Aruba deployment expands. Carl Oakes Network Architect California State University Sacramento (916) 278-5551 / oake...@csus.edu From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ray DeJean Sent: Monday, September 19, 2011 9:11 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz
RE: [WIRELESS-LAN] Wireless in dorms
Hi Peter, I cannot stand behind the 4511 from experience at Syracuse University, as we are a very large Cisco lightweight wireless environment (with a 35 AP Meraki deployment in our London facility). I covered the 4511 as the wireless/mobility blogger for Network Computing, where I have the good fortune of being introduced first hand to a wide-range of hardware and applications by product managers, CTO types, and those who actually develop the products. As someone who has been in the business of wireless design and deployment since 2001, and who has also been writing about various solutions for just as long, I have come to the conclusion that there are advantages and disadvantages to pretty much any WLAN solution. This is a space where marketing departments have an absolute field day sparkly-eying potential customers and vendors constantly one-up each other with lab tests that the typical customer would be hard-pressed to verify in the real world. My bottom line recommendation: keep an open mind to the right solution FOR YOU for different scenarios. Greenfield and brownfield situations allow you to be far more flexible in your choices. If you like the way a solution looks, but it's not from a market leader, get as many real testimonials as you can, do an eval, try not to hurry to conclusions, and drive for a good price if you ultimately commit. Back to the 4511- the ability to use existing wiring and provide Ethernet pass-through with a low-cost 2x2 11n AP that flush mounts in a low profile way does deserve consideration. As I mentioned, I'd love to see other vendors including Cisco provide this form factor. I'm a fan of Motorola's WiNG 5 approach and features that are under Extreme's hood (I have come to appreciate most approaches that reduce the reliance on a big honkin' controller and provide robust client support tools built in to the AP) and would personally give the solution consideration if I was looking at well-wired buildings that didn't yet have wireless in them. But I would start with an eval and have to get happy that both the wireless client experience and system admin halves of the equation were a good fit with the rest of my IT environment (auth, NAC, quarantine, etc) and that scaling to my ultimate largest would be OK before signing. Lee H. Badman (In this case, Network Computing Magazine blogger) From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Methven, Peter J [p.j.meth...@hw.ac.uk] Sent: Tuesday, September 20, 2011 6:11 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms Lee this is a really interesting article, and something we’ve been looking at as a UK Extreme networks customer. Have you experienced rolling these out to a dorm yet, as I’m quite interested to find out how “low” the DBI output can be dropped to, to see if is it practical to install 1 per room (with alternate 2.4Ghz and 5 Ghz radios.) so that on a corridor of dorms you have a large number of APs with signal limited (as much as possible) per AP to just a couple of rooms. Many Thanks Peter Mr Peter Methven, Network Specialist Information Technology (IT) Allen McTernan Building, Edinburgh Campus Tel: +44 (0)131 451 3516 For IT support queries or requests, please email ith...@hw.ac.ukmailto:ith...@hw.ac.uk or +44 (0)131 451 4045, with full details of your query or request and your contact details. http://www.hw.ac.uk/it From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: 19 September 2011 18:12 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms At the risk of being seen as shameless in self-promotion, I just wrote a brief piece about Extreme Networks “Snap On WiFi” (built on Motorola under the hood) Altitude 4511. If you buy into the philosophy, and under the right conditions I would, no additional wiring needed beyond the Cat 5 already installed for Ethernet. There are a growing number of ways to skin the wireless cat, and if you are new to wireless the options are many and interesting beyond the controller based stuff. See http://www.networkcomputing.com/wireless/231601558 And Extreme’s page on these at http://extremenetworks.com/products/altitude-4511.aspx Given that wiring can be as expensive as the APs, this sort of solution is at least interesting. -Lee Badman From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Oakes, Carl W Sent: Monday, September 19, 2011 12:49 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms Depending on your switch vendor, you can setup “DHCP Trust”, which says only certain ports can respond to DHCP requests. Solved the rouge DHCP problem for us instantly. ☺ (Our
RE: Issue with Microsoft NPS certs and ipads/iphones
Dennis, How does that work? The two servers have different hostnames DNS entries, I assume. I do not think it would work in our NPS environment anyway. Our NPS servers are also Read-Only Domain Controllers (each in their own site). This removes the RADIUS server load from our production Domain Controllers. Bruce Osborne Wireless Network Engineer IT Network Services (434) 592-4229 LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011 -Original Message- From: Dennis Xu [mailto:d...@uoguelph.ca] Sent: Monday, September 19, 2011 3:04 PM Subject: Re: Issue with Microsoft NPS certs and ipads/iphones We use the same certificate on two ACS servers for PEAP authentication to avoid the certificate warning when user connects to the 2nd ACS server. We haven't seen any issues with that. --- Dennis Xu Network Analyst, Computing and Communication Services University of Guelph 5198244120 x 56217 - Original Message - From: Bob Richman robert.b.richma...@nd.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Monday, September 19, 2011 1:11:02 PM Subject: [WIRELESS-LAN] Issue with Microsoft NPS certs and ipads/iphones We have a new issue that popped up when we upgraded our radius backend for our dot1x/peap from 2 microsoft widows 2003 IAS servers with Equifax certs to 3 microsoft windows 2008 NPS servers with geotrust certs. What we have is issues with ipad/iphones that seem to only sometimes remember the cert they most recently accepted. So for example, an IPAD connecting to the wireless using NPS server 1 will prompt the user to accept and they get on. Subsequent attempts to an AP that uses that same server will work fine. But an attempt to another set of APs using server 2 will cause the user to have to accept the cert corresponding to the new server. We do use the Cloudpath installers, but they seem to be of no help here. So, we did change 2 things at once, new certs and going from IAS to NPS. Anyone having any issues like this? Thanks, Bob Richman University of Notre Dame. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Wireless in dorms
On 09/20/2011 04:06 AM, Jethro R Binks wrote: My other concern is for those cases where you have a mix of wifi vendor technologies. For example you might like this Motorola product in some deployments, but otherwise be running C-word wireless or A-word wireless. Or perhaps with T-word wireless, you also want to deploy a Xirrus box in a particularly dense environment. How do you deal with managing these two sets of wireless network? Are there integration tools? Is roaming possible (or desirable?). Or, do we just say that we already have a number of management tools for different bits of the network anyway, so one more won't make much difference. I've heard good things about the AirWave product (formally independent, now owned by Aruba) for this sort of thing; it was actually designed as a control console for multiple vendor gear, so as long as you're dealing with relatively common equipment, you should be able to manage everything from one place with it. (No hands-on experience, just demos before Aruba bought it up.) -- Matt Gracie (716) 888-8378 Information Security Administrator grac...@canisius.edu Canisius College ITSBuffalo, NY http://www2.canisius.edu/~graciem/graciem_public_key.gpg ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] Wireless in dorms
The dorms are a lose-lose situation. We have 100% coverage, but the dorms require more support than any other buildings, when things don't work (it's Wireless, after all) we get flooded with calls (especially from mommy and daddy) AND then the students bring in their own devices (against the Acceptable Use Policy). I'm kind of liking the Wild West approach, if the DHCP situation can be controlled. -Brian From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Garry Peirce [pei...@maine.edu] Sent: Monday, September 19, 2011 3:17 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms 2 cents from someone in a similar boat. Unfortunately, some of our campuses have been unable to support ubiquitous wireless in dorms due to cost. In some cases they have only common areas covered. That being the case , with wireless being the preferred access method along with a lack of local campus policy in this regard they’ve understandably connected SOHO wireless routers. Some our of ResHalls caused us significant problems on the wired side at the start of this semester. Although we enable L2 features (such as DHCP snooping/DAI/SG,MAC limits) we weren’t able to corral an issue until implementing blocking of unknown unicast (cisco UUFB) on the ResHall subnets. This being a wireless forum, I’ll omit the details but in a nutshell, the issues were ICMP redirect/ARP-amplification related and would intermittently peg the attaching campus router’s CPU. I think efforts to searchfix offending devices or train students is entering a never ending battle. As cheaper devices will not have A radios (not that many clients will either….) co-channel interference is likely common. Add in interference , ex. assuming a fair # of microwave ovens, and I’d think their wireless experience is less than spectacular with no one to reach out to for insight/support. I feel such devices in ResHalls add an unmanaged infrastructure that not only underserves the users but may also have consequences for the managed infrastructure it connects to. I suppose by allowing them to use such devices, one can remove themselves from wireless infrastructure/client support, but I’d rather be in a position where we could supply the needed wireless service in a managed way and avoid their need to use them. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ray DeJean Sent: Monday, September 19, 2011 11:04 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Wireless in dorms All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. thanks, ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edumailto:r...@selu.edu http://r-a-y.org ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Wireless in dorms
We have gone the route of enhancing our wireless in the dorms. Our dorms hold approx. 125+ students per bldg. We provide wired - 100mB and Gigabit as well as wireless. We've upgraded our APs to increase coverage every year including this year. The replacing of the Ciscos to Ruckus has resulted in greater coverage with less devices; it's been a set it and forget it type of transition so our network calls from the dorms has dropped by over 90% from two years ago. Each complex of 5 bldgs. and has a separate vlan with a full outside Class C address set. We control bandwidth and applications with an Exinda box to prevent Bit torrent and other types of no-no applications. The students also have video game machines as well as IP tvs. We require that any device attached to our network must be NetReg'd or it simply won't work. There are a number of rogue APs which we monitor but the amount has shrunk with each year as the school wireless proves to be more reliable. We don't allow wireless printers or wireless BluRay players on our network and require the student who wants them to purchase a wireless router that we program and monitor. The DHCP addresses come from our central systems; by providing the student with better access and requiring that their router be programmed by our department, the problems of rogue DHCP routers have for the most part disappeared. Now if I can keep student from plugging both ends of a network cable into both jacks in their room I would be happy. Harry Rauch Sr. Network Analyst Eckerd College 4200 - 54th Ave S St. Petersburg, FL 33711 On 9/20/11 8:26 AM, Brian Helman wrote: The dorms are a lose-lose situation. We have 100% coverage, but the dorms require more support than any other buildings, when things don't work (it's Wireless, after all) we get flooded with calls (especially from mommy and daddy) AND then the students bring in their own devices (against the Acceptable Use Policy). I'm kind of liking the Wild West approach, if the DHCP situation can be controlled. -Brian *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Garry Peirce [pei...@maine.edu] *Sent:* Monday, September 19, 2011 3:17 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] Wireless in dorms 2 cents from someone in a similar boat. Unfortunately, some of our campuses have been unable to support ubiquitous wireless in dorms due to cost. In some cases they have only common areas covered. That being the case , with wireless being the preferred access method along with a lack of local campus policy in this regard they’ve understandably connected SOHO wireless routers. Some our of ResHalls caused us significant problems on the wired side at the start of this semester. Although we enable L2 features (such as DHCP snooping/DAI/SG,MAC limits) we weren’t able to corral an issue until implementing blocking of unknown unicast (cisco UUFB) on the ResHall subnets. This being a wireless forum, I’ll omit the details but in a nutshell, the issues were ICMP redirect/ARP-amplification related and would intermittently peg the attaching campus router’s CPU. I think efforts to searchfix offending devices or train students is entering a never ending battle. As cheaper devices will not have A radios (not that many clients will either….) co-channel interference is likely common. Add in interference , ex. assuming a fair # of microwave ovens, and I’d think their wireless experience is less than spectacular with no one to reach out to for insight/support. I feel such devices in ResHalls add an unmanaged infrastructure that not only underserves the users but may also have consequences for the managed infrastructure it connects to. I suppose by allowing them to use such devices, one can remove themselves from wireless infrastructure/client support, but I’d rather be in a position where we could supply the needed wireless service in a managed way and avoid their need to use them. *From:*The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Ray DeJean *Sent:* Monday, September 19, 2011 11:04 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* [WIRELESS-LAN] Wireless in dorms All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with
RE: Issue with Microsoft NPS certs and ipads/iphones
I do this. In the certificate the common name is Auth.central.edu. Then I have auth2 and auth3 listed as additional names on the certificate. I have the certificate installed on both servers and auth points to both servers. With server 2008R2 I also disable strict name checking. Thank you, Lee Weers Central College IT Services Assistant Director for Network Services 641-628-7675 Vcard https://www.mcpvirtualbusinesscard.com/VBCServer/LeeWeers/interactivecard Vprofile https://www.mcpvirtualbusinesscard.com/VBCServer/LeeWeers/profile -Original Message- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Osborne, Bruce W Sent: Tuesday, September 20, 2011 6:20 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Issue with Microsoft NPS certs and ipads/iphones Dennis, How does that work? The two servers have different hostnames DNS entries, I assume. I do not think it would work in our NPS environment anyway. Our NPS servers are also Read-Only Domain Controllers (each in their own site). This removes the RADIUS server load from our production Domain Controllers. Bruce Osborne Wireless Network Engineer IT Network Services (434) 592-4229 LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011 -Original Message- From: Dennis Xu [mailto:d...@uoguelph.ca] Sent: Monday, September 19, 2011 3:04 PM Subject: Re: Issue with Microsoft NPS certs and ipads/iphones We use the same certificate on two ACS servers for PEAP authentication to avoid the certificate warning when user connects to the 2nd ACS server. We haven't seen any issues with that. --- Dennis Xu Network Analyst, Computing and Communication Services University of Guelph 5198244120 x 56217 - Original Message - From: Bob Richman robert.b.richma...@nd.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Monday, September 19, 2011 1:11:02 PM Subject: [WIRELESS-LAN] Issue with Microsoft NPS certs and ipads/iphones We have a new issue that popped up when we upgraded our radius backend for our dot1x/peap from 2 microsoft widows 2003 IAS servers with Equifax certs to 3 microsoft windows 2008 NPS servers with geotrust certs. What we have is issues with ipad/iphones that seem to only sometimes remember the cert they most recently accepted. So for example, an IPAD connecting to the wireless using NPS server 1 will prompt the user to accept and they get on. Subsequent attempts to an AP that uses that same server will work fine. But an attempt to another set of APs using server 2 will cause the user to have to accept the cert corresponding to the new server. We do use the Cloudpath installers, but they seem to be of no help here. So, we did change 2 things at once, new certs and going from IAS to NPS. Anyone having any issues like this? Thanks, Bob Richman University of Notre Dame. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Issue with Microsoft NPS certs and ipads/iphones
On 20/09/2011 12:19, Osborne, Bruce W wrote: -Original Message- From: Dennis Xu [mailto:d...@uoguelph.ca] Sent: Monday, September 19, 2011 3:04 PM Subject: Re: Issue with Microsoft NPS certs and ipads/iphones We use the same certificate on two ACS servers for PEAP authentication to avoid the certificate warning when user connects to the 2nd ACS server. We haven't seen any issues with that. Dennis, How does that work? The two servers have different hostnames DNS entries, I assume. I do not think it would work in our NPS environment anyway. Our NPS servers are also Read-Only Domain Controllers (each in their own site). This removes the RADIUS server load from our production Domain Controllers. The names on the certificate are irrelevant as such, as long as: - The client trusts the CA that signed the cert - The client trusts the CN on the presented cert. The certificates are used for TLS in the EAP transaction that forms the authentication. There is no DNS at this point - you don't even have a network connection as such yet. This is why [some] supplicants allow you to specify certificate CN verification. In windows this is the Connect to these servers: field. Without this your supplicant would trust any cert signed by your CA (which is why it's recommended that you do not use a public CA for EAP). Regards, James -- James J J Hooper Senior Network Specialist, University of Bristol http://www.wireless.bristol.ac.uk -- ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Issue with Microsoft NPS certs and ipads/iphones
Bruce, The certificate is used for 802.1x authentication only, not for management access or other purposes. As I understand, PEAP authentications do not bother with server's hostnames and DNS. It happens before clients get IP address. But if your certificate is used for other purposes, this may not work. --- Dennis Xu Network Analyst, Computing and Communication Services University of Guelph 5198244120 x 56217 - Original Message - From: Bruce W Osborne bosbo...@liberty.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Tuesday, September 20, 2011 7:19:31 AM Subject: Re: [WIRELESS-LAN] Issue with Microsoft NPS certs and ipads/iphones Dennis, How does that work? The two servers have different hostnames DNS entries, I assume. I do not think it would work in our NPS environment anyway. Our NPS servers are also Read-Only Domain Controllers (each in their own site). This removes the RADIUS server load from our production Domain Controllers. Bruce Osborne Wireless Network Engineer IT Network Services (434) 592-4229 LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011 -Original Message- From: Dennis Xu [mailto:d...@uoguelph.ca] Sent: Monday, September 19, 2011 3:04 PM Subject: Re: Issue with Microsoft NPS certs and ipads/iphones We use the same certificate on two ACS servers for PEAP authentication to avoid the certificate warning when user connects to the 2nd ACS server. We haven't seen any issues with that. --- Dennis Xu Network Analyst, Computing and Communication Services University of Guelph 5198244120 x 56217 - Original Message - From: Bob Richman robert.b.richma...@nd.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Monday, September 19, 2011 1:11:02 PM Subject: [WIRELESS-LAN] Issue with Microsoft NPS certs and ipads/iphones We have a new issue that popped up when we upgraded our radius backend for our dot1x/peap from 2 microsoft widows 2003 IAS servers with Equifax certs to 3 microsoft windows 2008 NPS servers with geotrust certs. What we have is issues with ipad/iphones that seem to only sometimes remember the cert they most recently accepted. So for example, an IPAD connecting to the wireless using NPS server 1 will prompt the user to accept and they get on. Subsequent attempts to an AP that uses that same server will work fine. But an attempt to another set of APs using server 2 will cause the user to have to accept the cert corresponding to the new server. We do use the Cloudpath installers, but they seem to be of no help here. So, we did change 2 things at once, new certs and going from IAS to NPS. Anyone having any issues like this? Thanks, Bob Richman University of Notre Dame. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms)
Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman Sent: Tuesday, September 20, 2011 5:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] Sent: Monday, September 19, 2011 12:11 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edumailto:r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edumailto:grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. You don't mention what kind of network architecture you have - if you're using a relatively flat topology, with comingling of residence hall, administrative, and academic traffic, be sure that you've got technology and procedures in place to shut down misconfigured endpoints. Nobody will be happy when they start getting RFC1918 addresses from the DHCP server on little Timmy's free-with-rebate Linksys AP. -- Matt Gracie (716) 888-8378tel:%28716%29%20888-8378 Information Security Administrator grac...@canisius.edumailto:grac...@canisius.edu Canisius College ITSBuffalo, NY http://www2.canisius.edu/~graciem/graciem_public_key.gpg ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms)
We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett _ From: Jason Todd [mailto:jt...@westernu.edu] Sent: Tuesday, September 20, 2011 08:06 To: WIRELESS-LAN@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman Sent: Tuesday, September 20, 2011 5:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian _ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] Sent: Monday, September 19, 2011 12:11 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. You don't mention what kind of network architecture you have - if you're using a relatively flat topology, with comingling of residence hall, administrative, and academic traffic, be sure that you've got technology and procedures in place to shut down misconfigured endpoints. Nobody will be happy when they start getting RFC1918 addresses from the DHCP server on little Timmy's free-with-rebate Linksys AP. -- Matt Gracie (716) tel:%28716%29%20888-8378 888-8378 Information Security Administrator grac...@canisius.edu Canisius College ITSBuffalo, NY http://www2.canisius.edu/~graciem/graciem_public_key.gpg ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at
Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms)
On 9/20/2011 11:52 AM, David Gillett wrote: We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. Just be a bit cautious... our city buses offer free WiFi on board. We were deauth-ing / dropping users on the buses when they drove through campus :) Jeff ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms)
We are using the last version of this script: https://roguedetect.bountysource.com/ It's pretty old but works for us. We may have made some minor changes for our environment. I think mainly the script would only email the mac, and i modified it to also report the interface/vlan. Each of our 22 dorms is a different vlan, so we brought 22 vlan interfaces up on a central linux box, and just kick off the script on each interface every 30 minutes. It emails us the vlan and mac address of rogues, and we put that mac in a quarantine vlan. All traffic in the quarantine gets redirected to a page that says let us know when you unplug the router and your internet access will be restored. It works, but it's a manual process for us and sometimes frustrating for the student (especially at the beginning of the semester). Dropping DHCPOFFER's at the edge seems like a much better solution, which is what we're moving to this week. (Our 3com 5500 switches can do it with ACLs. The older 4400 switches can do it with a QoS profile) ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Tue, Sep 20, 2011 at 7:21 AM, Brian Helman bhel...@salemstate.eduwrote: Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian -- *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] *Sent:* Monday, September 19, 2011 12:11 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.eduwrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. You don't mention what kind of network architecture you have - if you're using a relatively flat topology, with comingling of residence hall, administrative, and academic traffic, be sure that you've got technology and procedures in place to shut down misconfigured endpoints. Nobody will be happy when they start getting RFC1918 addresses from the DHCP server on little Timmy's free-with-rebate Linksys AP. -- Matt Gracie (716) 888-8378 Information Security Administrator grac...@canisius.edu Canisius College ITSBuffalo, NY http://www2.canisius.edu/~graciem/graciem_public_key.gpg ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group
RE: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms)
The state mandates a competitive bidding process, so it will be some time before I know the vendor, let alone the model. We're far enough into the process that I probably can't get this added to our list of required functionality. I just have to hope it has become a common enough feature (since the last time we did this) that whoever we wind up with supports it, one way or another. David Gillett _ From: Leo Song [mailto:s...@uoguelph.ca] Sent: Tuesday, September 20, 2011 09:03 To: WIRELESS-LAN@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms) Hi, David. What specific switch model you are going to use? Leo Song, Senior Analyst Cluster Lead Computing and Communication Services - Networking and Security University of Guelph (519) 824-4120 x 53181 _ From: David Gillett gillettda...@fhda.edu To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Sent: Tuesday, September 20, 2011 11:52:34 AM Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett _ From: Jason Todd [mailto:jt...@westernu.edu] Sent: Tuesday, September 20, 2011 08:06 To: WIRELESS-LAN@listserv.educause.edu Subject: Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Helman Sent: Tuesday, September 20, 2011 5:22 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian _ From: The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] Sent: Monday, September 19, 2011 12:11 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded 2.4ghz space... The University of Wisconsin-Madison (http://www.housing.wisc.edu/resnet/gameConsoles.php) already has a policy like this in place. Just looking to hear from other universities who have or are considering a policy such as this. You don't mention what kind of network architecture you have - if you're using a relatively flat topology, with comingling of residence hall, administrative, and academic traffic, be sure that you've got technology and procedures in place to shut down misconfigured endpoints. Nobody will be happy when they start getting RFC1918 addresses from the
Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms)
Most enterprise class equipment (Cisco, Brocade, etc) come with dhcp-snooping standard now. Not sure about Juniper, and I think I heard the HP does it. I have DHCP-Snooping up in all student areas. Heath On 9/20/2011 11:16 AM, David Gillett wrote: The state mandates a competitive bidding process, so it will be some time before I know the vendor, let alone the model. We're far enough into the process that I probably can't get this added to our list of required functionality. I just have to hope it has become a common enough feature (since the last time we did this) that whoever we wind up with supports it, one way or another. David Gillett *From:* Leo Song [mailto:s...@uoguelph.ca] *Sent:* Tuesday, September 20, 2011 09:03 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms) Hi, David. What specific switch model you are going to use? Leo Song, Senior Analyst Cluster Lead Computing and Communication Services - Networking and Security University of Guelph (519) 824-4120 x 53181 *From: *David Gillett gillettda...@fhda.edu *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Sent: *Tuesday, September 20, 2011 11:52:34 AM *Subject: *Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett *From:* Jason Todd [mailto:jt...@westernu.edu] *Sent:* Tuesday, September 20, 2011 08:06 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences *From:*The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Brian Helman *Sent:* Tuesday, September 20, 2011 5:22 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian *From:*The EDUCAUSE Wireless Issues Constituent Group Listserv [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] *Sent:* Monday, September 19, 2011 12:11 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu mailto:r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu mailto:grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of course we realize the interference issues that may arise in a crowded
Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms)
I can confirm Juniper does it. On Tue, Sep 20, 2011 at 5:47 PM, Heath Barnhart heath.barnh...@washburn.edu wrote: Most enterprise class equipment (Cisco, Brocade, etc) come with dhcp-snooping standard now. Not sure about Juniper, and I think I heard the HP does it. I have DHCP-Snooping up in all student areas. Heath On 9/20/2011 11:16 AM, David Gillett wrote: The state mandates a competitive bidding process, so it will be some time before I know the vendor, let alone the model. We're far enough into the process that I probably can't get this added to our list of required functionality. I just have to hope it has become a common enough feature (since the last time we did this) that whoever we wind up with supports it, one way or another. David Gillett -- *From:* Leo Song [mailto:s...@uoguelph.ca s...@uoguelph.ca] *Sent:* Tuesday, September 20, 2011 09:03 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was[WIRELESS-LAN]Wireless in dorms) Hi, David. What specific switch model you are going to use? Leo Song, Senior Analyst Cluster Lead Computing and Communication Services - Networking and Security University of Guelph (519) 824-4120 x 53181 -- *From: *David Gillett gillettda...@fhda.edu gillettda...@fhda.edu *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Sent: *Tuesday, September 20, 2011 11:52:34 AM *Subject: *Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) We'll be replacing our switches over the next 6-18 months, and I'm hoping the new ones may include this capability. David Gillett -- *From:* Jason Todd [mailto:jt...@westernu.edu jt...@westernu.edu] *Sent:* Tuesday, September 20, 2011 08:06 *To:* WIRELESS-LAN@listserv.educause.edu *Subject:* Re: [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN]Wireless in dorms) Our rogue DHCP server problems went away once we started blocking DHCP offers at the edge. Before that we were hooking protocol analyzers up to the segment having problems to detect rogues. Jason Todd Network Security Officer Western University of Health Sciences *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDUWIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Brian Helman *Sent:* Tuesday, September 20, 2011 5:22 AM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* [WIRELESS-LAN] Rogue Device detection. (was [WIRELESS-LAN] Wireless in dorms) Oh, tell me more about this perl script you are using. Anyone else have good methods for identifying and terminating rogue DHCP (and rogue AP's for that matter) servers? -Brian -- *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [ WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Ray DeJean [r...@selu.edu] *Sent:* Monday, September 19, 2011 12:11 PM *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU *Subject:* Re: [WIRELESS-LAN] Wireless in dorms We do have dorms segregated on separate vlans behind a firewall from the rest of the network. However, the Rogue DHCP server issue is one of the main reasons we find out that a student is trying to run their own router. We have a roguedhcp perl script that sends out dhcp requests every hour or so and sees who responds... if any rogue's respond we quarantine them and tell them to unplug the router. However that's not good enough for the BYOD policy. So we're currently testing out ACLs and qos profiles on our switches that will just block the dhcp server responses on the endpoint ports. So Timmy can run a dhcp server in his room all he wants without affecting anyone else. I don't know why we didn't think of that years ago... ray -- Ray DeJean Systems Engineer Southeastern Louisiana University email: r...@selu.edu http://r-a-y.org On Mon, Sep 19, 2011 at 10:54 AM, Matthew Gracie grac...@canisius.edu wrote: On 09/19/2011 11:04 AM, Ray DeJean wrote: All, We don't currently provide wireless in our dorms, and our official policy is to not allow students to bring their own wireless devices. We don't actively enforce this policy though, and as long as the students' device isn't causing problems, they typically don't hear from us. (We do provide at least a 100mbps wired connection to each student). We are considering changing our policy to allow BYOD (bring your own device) in the dorms. I know lots of students already BYOD, but we're not policing it. We're considering the costs associated with deploying our Aruba system to all the dorms, and the fact that students are going to BYOD anyway. Rather than fight them, allow it. We'll secure our wired network obviously, but also have workshops and online instructions to show the students how to properly connect and secure their device. Of
