Re: [WIRELESS-LAN] Eduroam adoption (and migration process)
I can’t speak for the campuses you named, but we have not switched to eduroam as our main SSID, and we have no current plans to. I’m sure someone is happy about the branding somewhere, but it’s also for technical reasons. Eduroam, like our guest wireless, is routed outside our campus border firewall. When you are on our campus's IllinoisNet SSID you are on the campus side of the border firewall and have more access to campus resources than you do when you are on the eduroam SSID or our IllinoisNet_Guest SSID. Our campus network design has very little internal firewalling - the majority of the protection for offices, labs, classrooms, wireless, and anything other than University-wide Admin applications is the border firewall. So putting guests on the outside, and faculty, staff and students on the inside is important. Additionally the firewall for the eduroam network is set up to allow the minimum ports required by the eduroam agreement, so that when our faculty, staff and students test that something works on eduroam before they travel, they are reasonably well guaranteed it will work on any eduroam net anywhere. With our change from Meru/Radiator to Aruban/Clearpass last summer, it’s likely that it would be much simpler to drop eduroam users that are local onto a “different” version of eduroam that was on the campus side of the border firewall, but then the user experience on eduroam here would not be the same experience as if they were at a different site providing eduroam. Both in what ports were allowed in/out of the eduroam network and much more importantly how connections to campus resources function for networks off-campus. We want users to have a consistent experience with how eduroam works for their use cases, regardless of whether they are on our campus or somewhere else. To answer the other questions, we currently have 3 non-eduroam SSIDs our main SSID that is inside the campus board firewalls is 802.1x we have an open guest SSID that uses the Clearpass guest captive portal system we have a devices SSID that is MAC auth but I believe this one is being phased out in favor of using features in ClearPass to do something similar. This is mostly for gaming consoles and the things that really can’t do 802.1x. It’s been quite a few years since I ran the wireless network on our campus, but I believe I’ve got the current technical details correct, Chuck can correct me if I got anything wrong. -- -debbie Debbie Fligor, n9dn Lead Network Engineer @ Univ. of Il at Urbana-Champaign email: fli...@illinois.edu > On Apr 24, 2017, at 14:18, Marcelo Maraboli wrote: > > I would like to thank all who responded. > > Everybody who responded is making EduRoam their main SSID > deprecating their old SSID (MAC or .1x). > > I still wonder why Universities like MIT,Harvard,Stanford and Berkeley > only use Eduroam as a secondary SSID and still keep their main SSID. > The only thing I can think of is branding. > > > > thanks. > > > On 4/20/17 6:16 PM, Marcelo Maraboli wrote: >> Hello everyone. >> >> We are finally adopting EduROAM in our University and we currently have one >> SSID with MAC-based authentication, so moving to EduROAM is also a 802.1x >> upgrade >> for us as well. >> >> Would you be so kind to respond a couple of questions?: >> >> >> If you adopted EduROAM as your primary SSID: >> - Did you leave an SSID for legacy devices ? (What AUTH mechanism for this >> SSID?) >> - How did you "force-move" your users to EdoROAM from your old SSID ? >> >> If you added EduROAM as just another SSID: >> - why not adopt EduROAM as your primary SSID ? (Branding or no interest? ) >> - Is your primary SSID also 802.1x o MAC-based ? >> - if 802.1x, why have 2 SSIDs with 802.1x ? >> >> ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
Re: [WIRELESS-LAN] Gathering student and faculty feedback
We’ve done just a little bit of this in the last year with a product called NetBeez. We’ve only got 10 or so of our 35 wi-fi units installed, mostly in the building our offices are in. We have a small list of important campus services that they try and reach over wireless. We were able to track down an intermittent issue between some of our wireless users and our Exchange server based on the NetBeez reports of problems for some units and not others by looking into what was different about the ones that worked and those that didn’t. They’ve added some performance testing features (schedulable iperf for example) since I deployed them that I haven’t gone back and setup. It’s on my to-do list, so we can see if that is useful as well. For those curious - the problem they helped us find had to do with the new IP space we deployed for campus wireless when we switched from Meru to Aruba and not having it in certain ACLs/firewalls for the remote data centers where some of the exchange cluster is hosted. With the cluster distributed over multiple locations and the closest ones preferred, only a few clients went to the remote sites and were affected. -debbie > On Nov 30, 2016, at 9:03, Mark McNeil [Staff] wrote: > > I just received about 20 double sided pages of feedback rom one of our > professors. She decided she would do a survey on wireless in classrooms to > two of her classes. The responses as I'm sure you've all experienced are very > accurate(lol). > > My question is does anyone utilize a specific tool or personnel to capture > the usability of their wireless environment. We have an Alcatel/Aruba > Networks environment. We receive lots of stats from our Airmanger application > on bandwidth to user. These metrics however don't seem to parallel the > responses we get from students and faculty. > > We use mobile devices, IOS and Android based devices to test access to the > wireless network. Naturally we are only in a given area for short periods of > time so our capture will not be the same as a professor or student. > > Any feedback is appreciated. > > Thanks > > Mark > > -- > > Mark McNeil > Director, Network Engineering and Operations > Fordham University | Fordham IT > Tel: 718-817-3763 > Business Office: 718-817-3750 > Fax: 718-817-5775 > email: mcn...@fordham.edu > http://www.fordham.edu > _ > ** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > -- -debbie Debbie Fligor, n9dn Lead Network Engineer @ Univ. of Il email: fli...@illinois.edu "I have lived most of my life surrounded by my enemies. I would be grateful to die surrounded by my friends.” Gamora ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
Re: [WIRELESS-LAN] Apple OSX 10.11 beta
> On Jul 28, 2015, at 10:26, Jon Scot Prunckle wrote: > > Debbie, > > Is your group also running freeradius? We run OSC Radiator. Sorry, I should have included that. -debbie > > Sincerely, > > > J. Scot Prunckle > Network Engineer > UITS Network and Operations Services > University of Wisconsin-Milwaukee > Office Mobile: (414) 416-9709 > E-mail: prunc...@uwm.edu > >> On Jul 28, 2015, at 8:57 AM, Fligor, Debbie wrote: >> >> This went out to our campus IT community last Friday, it has some nice >> details about what the wireless/radius team was seeing: >> >> Greetings, >> >> Earlier this week we sent a communication about issues that the iOS 9 and El >> Capitan betas had connecting to the campus network. We are happy to >> announce that the issue has been resolved. While Technology Services does >> not encourage customers to rely on betas for production or every-day work, >> both of the current beta releases are able to connect to IllinoisNet. If you >> have questions regarding this message please contact wirel...@illinois.edu. >> >> *For those with a desire to better understand the technical changes and >> their impacts, feel free to read the additional detail below. >> >> On 2015-07-23 a set of security updates was deployed to the RADIUS >> servers which handle logins for IllinoisNet and eduroam wireless. One >> of these changes was an upgrade to the latest version of Net::SSLeay >> (which provides perl bindings for OpenSSL) to allow clients to negotiate >> TLSv1.1 and TLSv1.2 (as well as TLSv1.0) for the EAP-TTLS tunnel used in >> WPA2 Enterprise authentication. Many modern wireless clients still use >> TLSv1.0 in practice, but Apple OS X El Capitan and iOS 9 do use TLSv1.2, >> and as a result of this upgrade they are now able to successfully >> connect to IllinoisNet and eduroam. >> >> What remains surprising is that, prior to deploying these updates, our >> test iOS 9 client was able to successfully make it all the way through >> the RADIUS authentication stage of 802.11i (producing a RADIUS >> Access-Accept); it failed only during the subsequent four-way handshake >> to construct the PTK (by which point the RADIUS server is no longer >> involved, leading us to believe that the problem resided elsewhere). >> Subsequent re-testing reveals that even with the older Net:SSLeay >> installed, the RADIUS server would respond to the TLSv1.2 Client Hello >> with a TLSv1.2 Server Hello, and side by side comparisons of the >> unencrypted portions of traffic captures in a lab environment show no >> obvious differences in the ensuing conversation depending on which >> Net:SSLeay is installed. We can only speculate at this point that >> perhaps the combination of a modern openssl library with an old >> Net:SSLeay was somehow superficially _appearing_ to correctly support >> TLSv1.2 while in fact producing some subtly different behavior which >> eventually caused iOS 9 to give up on the connection process. >> >> >> >> >>> On Jul 27, 2015, at 18:55, Jason Cook wrote: >>> >>> Thanks everyone for the input, greatly appreciated. We are freeradius 2.2.6 >>> and I’m not sure what opensslchance that this is our problem. >>> >>> >>> >>> Time to get fixing with all this infoJ >>> >>> >>> >>> -- >>> >>> Jason Cook >>> >>> The University of Adelaide, AUSTRALIA 5005 >>> >>> Ph: +61 8 8313 4800 >>> >>> >>> >>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Walter Reynolds >>> Sent: Tuesday, 28 July 2015 2:49 AM >>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> Subject: Re: [WIRELESS-LAN] Apple OSX 10.11 beta >>> >>> >>> >>> The problem we had was because we were running freeradius 2.2.6 and I do >>> not remember version of openssl (1.something) which does support TLSv1.2. >>> There would be a problem after authentication with the 4 way handshake. So >>> you would see a user authenticate every 6 second or so and not receive an >>> IP from the Mac paint of view. >>> >>> Running freeradius 2.2.6 with an older version of openssl (.9 something) >>> would not support TLSv1.2 so no problem. >>> >>> Freeradius 2.2.7 fixes some TLS issues which fixed the issue. >>> >>> I know aruba'
Re: [WIRELESS-LAN] Apple OSX 10.11 beta
This went out to our campus IT community last Friday, it has some nice details about what the wireless/radius team was seeing: Greetings, Earlier this week we sent a communication about issues that the iOS 9 and El Capitan betas had connecting to the campus network. We are happy to announce that the issue has been resolved. While Technology Services does not encourage customers to rely on betas for production or every-day work, both of the current beta releases are able to connect to IllinoisNet. If you have questions regarding this message please contact wirel...@illinois.edu. *For those with a desire to better understand the technical changes and their impacts, feel free to read the additional detail below. On 2015-07-23 a set of security updates was deployed to the RADIUS servers which handle logins for IllinoisNet and eduroam wireless. One of these changes was an upgrade to the latest version of Net::SSLeay (which provides perl bindings for OpenSSL) to allow clients to negotiate TLSv1.1 and TLSv1.2 (as well as TLSv1.0) for the EAP-TTLS tunnel used in WPA2 Enterprise authentication. Many modern wireless clients still use TLSv1.0 in practice, but Apple OS X El Capitan and iOS 9 do use TLSv1.2, and as a result of this upgrade they are now able to successfully connect to IllinoisNet and eduroam. What remains surprising is that, prior to deploying these updates, our test iOS 9 client was able to successfully make it all the way through the RADIUS authentication stage of 802.11i (producing a RADIUS Access-Accept); it failed only during the subsequent four-way handshake to construct the PTK (by which point the RADIUS server is no longer involved, leading us to believe that the problem resided elsewhere). Subsequent re-testing reveals that even with the older Net:SSLeay installed, the RADIUS server would respond to the TLSv1.2 Client Hello with a TLSv1.2 Server Hello, and side by side comparisons of the unencrypted portions of traffic captures in a lab environment show no obvious differences in the ensuing conversation depending on which Net:SSLeay is installed. We can only speculate at this point that perhaps the combination of a modern openssl library with an old Net:SSLeay was somehow superficially _appearing_ to correctly support TLSv1.2 while in fact producing some subtly different behavior which eventually caused iOS 9 to give up on the connection process. > On Jul 27, 2015, at 18:55, Jason Cook wrote: > > Thanks everyone for the input, greatly appreciated. We are freeradius 2.2.6 > and I’m not sure what opensslchance that this is our problem. > > > > Time to get fixing with all this infoJ > > > > -- > > Jason Cook > > The University of Adelaide, AUSTRALIA 5005 > > Ph: +61 8 8313 4800 > > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Walter Reynolds > Sent: Tuesday, 28 July 2015 2:49 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Apple OSX 10.11 beta > > > > The problem we had was because we were running freeradius 2.2.6 and I do not > remember version of openssl (1.something) which does support TLSv1.2. There > would be a problem after authentication with the 4 way handshake. So you > would see a user authenticate every 6 second or so and not receive an IP from > the Mac paint of view. > > Running freeradius 2.2.6 with an older version of openssl (.9 something) > would not support TLSv1.2 so no problem. > > Freeradius 2.2.7 fixes some TLS issues which fixed the issue. > > I know aruba's clearpass is based on freeradius but not sure how close it is > so as one person said they did need to upgrade that as well. > > On Jul 27, 2015 10:20 AM, "Turner, Ryan H" wrote: > > I have also just pinged our campus users. Already have a lot of users > running the platform with no issues. > > We are running a full EAP-TLS deployment with Aruba Controllers running > 6.4.2.8 running an older 2.1 freeradius. > > Ryan H Turner > Senior Network Engineer > The University of North Carolina at Chapel Hill > CB 1150 Chapel Hill, NC 27599 > +1 919 445 0113 Office > +1 919 274 7926 Mobile > > -Original Message- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman > Sent: Monday, July 27, 2015 8:48 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Apple OSX 10.11 beta > > I'm polling our Apple adventurists on this. I did talk to one valued > colleague who said he ran 10.11 for a bit on one machine and had no issues on > our WPA2 Cisco campus networks. He's going to build another test machine and > try it again, and hopefully I'll hear from at least a couple of other > bleeding edgers on this end. > > Lee Badman | Network Architect > Information Technology Services > 206 Machinery Hall > 120 Smith Drive > Syracuse, New Y
Re: [WIRELESS-LAN] eduroam question(s)
On Nov 12, 2012, at 20:55, Jeff Kell wrote: > On 11/12/2012 9:41 PM, Lee H Badman wrote: >> Also... Does anyone get a bit turned off about having yet another SSID in >> the air, or debranding your own in favor of pushing Eduroam as your SSID? >> Again, just wondering. Let's task Phillipe with figuring out a way to make >> the Eduroam underpinnings work automagically with any SSID we choose. >> >> Can we get that by Friday? > > Ah hah... it's a battle of the Oranges :) > > If you have separate SSIDs you can get better statistics, I suppose; but > perhaps your Radius can drop them in different buckets. For us it was a > combination of things, primarily having our production 1X being > NAC-enforced and role-based (requiring an agent, and proxying Radius > through the NAC controller), whereas the eduroam SSID is off-the-grid > (and also locked down by the eduroam firewall recommendations). We have separate Eduroam and local (IllinoisNet) .1x networks. Partly because we had already fully deployed, documented and pushed the IllinoisNet SSID, and partly because we treat Eduroam differently. Our security group didn't want the Eduroam SSID on the same network with all our campus users, and our Eduroam deployment has all the required ports open, but not any extra. That way when people travel to other schools, they're never disappointed by what works -- anything they test on Eduroam here before they leave should work anywhere. We don't have a large number of Eduroam users, Champaign-Urbana is pretty much in the middle of no-where (unlike Chicago locations :-), but we get a small but somewhat regular set of happy emails from our own faculty and from visitors saying that they were traveling (or visiting) and Eduroam "just worked" for them. Since it's not a heavy support load for us, it's a nice thing to be able to provide. Additionally, we don't have a unified SSID across our campuses (each campus does it's own IT support), and since we already had Eduroam, the other campuses are doing that (have done that?) so that staff that do move between campuses have an easy way to do so. > > Jeff > > ** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. -- -debbie Debbie Fligor, n9dn Lead Network Engineer, CITES, Univ. of Il email: fli...@illinois.edu "Every keystroke can be monitored. And the computers never forget." ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
