Breaking IPv6 is indeed undesirable ;-) Fortunately, other vendors do not share your opinion. Good news for the majority on this list: the bug is limited to Cisco's FlexConnect. -Frans
Jake Snyder schreef op 18/03/15 om 20:19: > It is expected from an 802.11 perspective. May not be desirable, but > that is how the wireless standard works. Unicasting RAs over the air > fixes this. > > Sent from my iPhone > > On Mar 18, 2015, at 12:42 PM, Frans Panken <frans.pan...@surfnet.nl > <mailto:frans.pan...@surfnet.nl>> wrote: > >> No, it is not. The result is that it breaks IPv6 on local VLANs: >> clients receive multiple prefixes on local VLANs. >> >> Jake Snyder schreef op 18/03/15 om 17:51: >>> Leaking of RAs between VLANS is expected behavior as RA are >>> multicast. Because the 802.11 protocol sends multicast traffic as >>> broadcast over the air and every device on a BSSID shares the same >>> group key for encryption, any client can decode any multicast >>> packet, including RAs not on the same VLAN. Again, this is expected >>> behavior. The solution to this is to use multicast to unicast >>> conversion for the RA, however i've never done this in a flexconnect >>> deployment. >>> >>> This is also important in IPv4 deployments where you need to secure >>> who can gain access to a multicast stream. >>> >>> On Wed, Mar 18, 2015 at 10:32 AM, Frans Panken >>> <frans.pan...@surfnet.nl <mailto:frans.pan...@surfnet.nl>> wrote: >>> >>> We use FlexConnect in both central and local switched mode (v >>> 8.110.6). >>> We use a single SSID and distinguish various user groups, >>> differentiated >>> by Radius and mapped on different VLANs. >>> We observe that VLANs leak traffic to other VLANs. This is in >>> particular >>> very undesired with IPv6, where router adverstisements from one >>> VLAN is >>> broadcast to other VLANs (this also happens on IPv4, e.g., with >>> ARP and >>> other broadcast traffic). Even VLANs that are only centrally >>> accessible >>> leak traffic to local VLANs. >>> >>> This is a security issue that in my oppinion does not receive the >>> desired attention. >>> >>> Frans >>> >>> >>> >>> Watters, John schreef op 18/03/15 om 07:29: >>> > Please post any results you have if/when try expand >>> FlexConnect to your entire campus. It looks like you are close >>> to our size (we now have about 125 buildings & about 38K >>> students plus about 4K faculty/staff). >>> > >>> > Thanks. >>> > >>> > Sent from my iPhone >>> > >>> >> On Mar 17, 2015, at 4:12 PM, Hector J Rios <hr...@lsu.edu >>> <mailto:hr...@lsu.edu>> wrote: >>> >> >>> >> I've not performed tests to that scale yet. Plus we are only >>> considering this for our ResHalls, of which we have 21 buildings >>> only. >>> >> >>> >> -Hector >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of >>> Watters, John >>> >> Sent: Tuesday, March 17, 2015 11:55 AM >>> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> >>> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless - FlexConnect >>> >> >>> >> We played with FlexConnect for a number of months but still >>> could not get what we needed it to do on a consistent basis. >>> Essentially we wanted FlexConnect to drop users into their >>> building VLAN so they would be able to easily interact with the >>> same devices that the wired connections in the buildings could >>> see. As I'm sure you know, this also resolves many of the Apple, >>> Chromecast, etc., problems. >>> >> >>> >> We did have one caveat though that we just couldn't get past >>> -- we wanted to drop faculty/staff into one VLAN and students >>> into another (we can easily return the proper VLAN for a >>> particular client in a particular building from Radius server - >>> FreeRadius with a call to our LDAP server for info) but we also >>> need to send everything else back to the controller for central >>> switching (e.g., police connections, special bar-code scanners >>> that roam and serve to identify a user, but not being used for >>> client traffic, for example, to give out free flu shots to >>> eligible folks or let folks into a sporting event). We just >>> couldn't get past having 95+% locally switched and the remainder >>> centrally switched for over 200 buildings many with now over 100 >>> APs each without using FlecConnect groups which are limited to >>> numbers way too small for our campus. >>> >> >>> >> We can even live comfortably without roaming between >>> buildings. MOst folks are not used to being able to roam between >>> buildings downtown or many cannot roam between apartments off >>> campus. >>> >> >>> >> How did you get around the FlexConnect group problem? >>> >> >>> >> >>> >> >>> >> >>> >> ========================== >>> >> -jcw >>> >> ________________________________ >>> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >>> [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] on behalf of Hector >>> J Rios [hr...@lsu.edu <mailto:hr...@lsu.edu>] >>> >> Sent: Tuesday, March 17, 2015 9:27 AM >>> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> >>> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless >>> >> >>> >> I tested FlexConnect on 8.0.110.0. Here are my observations: >>> >> >>> >> *Great alternative to switch data locally (obviously) *No AVC >>> Support *When controller is down, AP goes into standalone more. >>> Must make sure that AP is not able to reach any other controller >>> you don't want. This was fixed with an ACL. >>> >> *Client details page does not show client IPv6 address. >>> Client still gets IPv6 address. (PRIME does show it if you run a >>> report). >>> >> *Client details page does not show VLAN ID. >>> >> *Putting AP in FlexConnect mode does not require reboot >>> (Cool!) *No IPv6 ACL support >>> >> >>> >> More testing to do, but so far so good. >>> >> >>> >> -Hector >>> >> >>> >> >>> >> >>> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of Hector >>> J Rios >>> >> Sent: Thursday, March 12, 2015 11:13 PM >>> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> >>> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless >>> >> >>> >> We use Cisco's wireless solution with WiSM2s and a variety of >>> WAPs. We actually implemented the guest anchor controller >>> solution last year with dual controllers (WLC2504) and we've >>> been happy. >>> >> >>> >> I like Britton's idea of using FlexConnect at the dorms to >>> switch the student data locally. However, I believe there are >>> some limitations that would keep us from using it such as no >>> support for AVC, and some limitations on IPv6. >>> >> >>> >> -Hector >>> >> >>> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv >>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of >>> Osborne, Bruce W (Network Services) >>> >> Sent: Thursday, March 12, 2015 7:42 AM >>> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU><mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >>> <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> >>> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless >>> >> >>> >> Hector, >>> >> >>> >> You do not say what wireless solution you are using. Let me >>> assume a Cisco or Aruba controller based solution. You can have >>> vlans from your controller tunnel to an anchor controller in a >>> DMZ. Use 802.1X authentication based on AD groups. >>> >> >>> >> This solution permits controlled internal access and, if you >>> desire, unfiltered Internet access. Until recently, we did >>> something similar with our open Guest wireless network on our >>> Aruba system. We now use a different solution for this. >>> >> >>> >> The anchor controller idea was based on Cisco wireless >>> training several years ago. At that time, it was their >>> recommended guest solution. >>> >> >>> >> Bruce Osborne >>> >> Wireless Engineer >>> >> IT Infrastructure & Media Solutions >>> >> >>> >> (434) 592-4229 <tel:%28434%29%20592-4229> >>> >> >>> >> LIBERTY UNIVERSITY >>> >> Training Champions for Christ since 1971 >>> >> >>> >> From: Hector J Rios [mailto:hr...@lsu.edu <mailto:hr...@lsu.edu>] >>> >> Sent: Wednesday, March 11, 2015 9:48 AM >>> >> Subject: ResHall Wireless >>> >> >>> >> I'm wondering how many of you treat the wireless in the >>> ResHalls differently from the wireless on the rest of your >>> campus. In terms of geography, we have 21 ResHalls that are in >>> the perimeter of our campus. Some of these buildings are next to >>> academic or administrative buildings. Eduroam is our main SSID. >>> So, for the longest time it has only made sense to broadcast >>> eduroam everywhere. Now, on the wired side of the house, our >>> ResHalls have a dedicated connection that gives them direct, >>> non-firewall access to the internet (for access to campus >>> resources, a student must VPN). This came about as a request >>> from the students to have more freedom in their residence. Makes >>> sense. But wireless is different as it goes through our campus >>> core, traverses our perimeter firewall, and goes out our main >>> internet connection. >>> >> >>> >> I've struggled to find an alternative solution to this. We >>> recognize that students in ResHalls are different in the sense >>> that they pay for a place to live and should get an internet >>> service that is similar to their home service. However, any >>> alternatives that we have considered (separate SSID, dynamic >>> VLAN assignment, user groups) just seem to complicate the setup. >>> >> >>> >> Any good ideas out there or creative ways in which you have >>> tackled this challenge? >>> >> >>> >> Thanks, >>> >> >>> >> Hector Rios, CCNP, CCA >>> >> Assistant Director, Network Engineering >>> >> Dept. of Networking and Infrastructure >>> >> Information Technology Services >>> >> Louisiana State University >>> >> >>> >> ********** 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 >>> 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 >>> 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/.
