We are working on implementing a centrally managed Bluesocket 2100 to replace our home-grown authentication/firewall for our small but growing wireless network. Our long term goal is to move to 802.1x deployment from a smart AP, but also to have the Bluesocket portal as a backup and as guest access.
When we talked to vendors, over a year ago, we had 200 per day on the network. Now were are seeing 200 simultaneous users during the busy hour. I have read on this listserv that many of you use the 2100 and can support over 1000 users. Bluesocket recommends the 2100 for 400 simultaneous users tops, but admits many campuses are doing much more. What is your take on simultaneous users? Are you using bandwidth restriction to up the numbers? We are trying to determine if we need to buy a bigger box or if we are seeing a little too much "marketing" from Bluesocket. Thanks Zack Zackary O'Donnell Communications Resources University of California One Shields Ave PH: 530.752.5947 Davis, CA 95616 FX: 530.754.9747 Telecommunications: Be careful how you use it. -----Original Message----- From: 802.11 wireless issues listserv [mailto:[EMAIL PROTECTED] Behalf Of Christopher R. Hertel Sent: Friday, October 10, 2003 9:43 AM To: [EMAIL PROTECTED] Subject: Re: [WIRELESS-LAN] Bluesocket.... On Fri, Oct 10, 2003 at 11:10:54AM -0400, Sean Che wrote: : > 802.1x traffic should NOT pass through AP. What I said is that 802.1x > can pass through Bluesocket. In this case, the link between > authenticator(AP) and authentication server ( Radius Server) is > transparent, even thought bluesocket box sits between them. > > FYI, here's the authentication process of 802.1x: > > * The client may send an EAP-start message. > * The access point sends an EAP-request identity message. > * The client's EAP-response packet with the client's identity is > "proxied" to the authentication server by the authenticator. > * The authentication server challenges the client to prove > themselves and may send its credentials to prove itself to the > client (if using mutual authentication). > * The client checks the server's credentials (if using mutual > authentication) and then sends its credentials to the server to > prove itself. > * The authentication server accepts or rejects the client's request > for connection. > * If the end user was accepted, the authenticator changes the > virtual port with the end user to an authorized state allowing > full network access to that end user. > * At log-off, the client virtual port is changed back to the > unauthorized state. Think about that. In order for that to work all of the APs must support the system completely. Consider: * The APs that do support 802.1x are more expensive, which makes a difference when you multiply by 1000 APs. (...and that's just for starters. We have a big campus.) * There are hundreds if not thousands of APs on my campus already that don't support 802.1x. Folks just pop out on their lunch hour and buy a new AP at the discount store for $70 or less. They get back and plug it in. It's hard enough convincing them to use the standard SSID and hook up the auth server. Many of these APs won't be upgradable to run 802.1x. * The more APs I have the more APs I have to manage. The more features the AP has the more of a pain it is to manage it. I want my APs dumb and simple. If I could get APs that were little more than a transceiver that would be very, very nifty. * On the client side, all of the clients would have to support 802.1x in order to make it a viable solution. We have a diverse client population that includes MacOS, *BSD, Linux, PalmOS, Symbian, even MS-Windows... I'm sure there are more. Until all of these (and those I've missed) support 802.1x I cannot deploy it. I would be blocking access based on the user's client platform choice and that just wouldn't fly. (We tried recently to block all Windows filesharing ports to prevent virus/worm spread, but there was this small, vocal minority...) In short, 802.1x is currently impractical on my campus. Instead, we have tried to move complexity in the wireless network toward the center. Our goal is to make it easier to manage the network, easier to accomodate a wider variety of clients and APs, easier to make changes, troubleshoot, etc. Our architecture is quite simple. The APs are placed onto a vLAN that is also connected to a firewall system. The firewall (FreeBSD with IPFilter and a custom Divert daemon) blocks access to the campus network. Users must bring up a browser and try to connect to a web page (on or off campus). The connection is redirected to an HTTPS web page that requests authentication. If the authentication is successfull, the custom Divert daemon allows packets through. The firewall also has a hole poked in it to allow connections to our campus VPN server, so that users can choose to use a VPN connection instead. The VPN server also requires authentication. This works well enough (though it's not perfect). If the APs would send all packets (even local traffic) to the back-end firewall then we could prevent un-authenticated local wLAN access as well. Again, a simple wireless to wired LAN transceiver would be really nice here. > >Curious... I've heard people talk about this (we've taked with the > >Reefedge folks about their product, which we liked) but I don't know of > >any practical applications. How would you use this? (Probably obvious > >but I haven't thought it through.) > > > > > Here's an example: if we would like faculty to have access to the > wireless network 24 X 7 but we don't want student to use wireless laptop > surfing unrelated webpage during class hours in classrooms , we can use > those fine-grained control feature of bluesocket to implement that. > All we have to do is to define different objects ( roles, users, > locations, destinations, schedules etc) and apply rule/policy with them. I can see that this feature would be useful in implementing such policies. The problem, then, is how to establish those policies and how to ensure that the enforcement of the policies is properly contained. It would be hard for us to implement the example policy you describe because we have many APs that serve two classrooms and/or hallways etc. Some APs leak signal through several floors in some buildings (it all depends on construction) so we would have to be fine-grained enough to know which students are in which classes at which hours. That's way too much fussing for a campus our size. Chris -)----- -- Christopher R. Hertel -)----- University of Minnesota [EMAIL PROTECTED] Networking and Telecommunications Services "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/cg/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
