Bill, we have done this. I recommend: 1) run the public side on completely separate segment of your firewall. We also use the same segment for some in-gallery kiosks and other public stations (learning center, library catalog, etc.--some of these are wired, some wireless), and for staff access to internal resources vis VPN. A 3-for-1 deal! (I don't mean to sound sarcastic--really this was all pretty cheap, considering the return). 2) use some kind of traffic shaping/QOS on your firewall to guarantee the public segment does not eat up more of your bandwidth than your private network needs. Cisco, Netscreen, etc. can all do this. There are great, clever ways to do it so that the public side can get a lot more when the private side is quiet--that is, you're not just setting a limit, you're setting policies. 3) Use the NoCat captive portal (http://nocat.net/) between your public users and the firewall to handle auth. We don't require user accounts and login, but we require anonymous agreement to an acceptable-use policy once every four hours. Our AUP is straight from NYCWireless.net, who had it written for general use by some expensive lawyers. I can't find it now but I'll send it to you when I get a chance to get on the wireless and copy it. 4) limit tcp/udp port access very sparingly. We disallow 25 (SMTP) because the anti-spam blocklists complained, immediately, about all the viro-spam our users were broadcasting. Yuck. We also block the MS-SQL ports because the slammer/blaster worms are still out there and no end-user needs those ports anyway. Apart from that, I think it's all open. Just like their connections at home :-). 5) We wrote very limited end-user instructions available at our front desk, but you know how it goes: if they need the instructions, it's not going to work. Just set it up so it works the most common way (no MAC filtering, no encryption, broadcast SSID--as open as possible), so what they know already will work for them. Once in a great while we get somebody asking a question of our front-desk staff. You might get more users than we do but I doubt this will be a problem. 6) Information capture is possible as part of the NoCat auth. We decided not to do it, except via web logs in the most anonymous way. But I bet you'll get more users than we do, since you have a more central location, so it may be more worthwhile for you (now, if we could just sell coffee in our new entranceway ...). We could collect email addresses, and we should direct people to our email list signup, but we just wanted this to be a gift, ultimately. We might change our minds one day. 7) The only hardware we use that we didn't already have was this little solid-state computer that we run the NoCat portal on. It runs PebbleLinux (a very small distro developed for these applications: http://nycwireless.net/tiki-index.php?page=PebbleLinux) off a CF card, so it's fast, simple, and secure. Ours is just put together from parts, but you can buy them now pre-made at places like acrosser.com and metrix.net. Or you could equally well run Pebble, or whatever other distro, on some surplus PC. NoCat is written in perl so it's pretty portable.
I can get you more detail off-list. Good luck! --Matt On 06/29/2005 12:38 PM, Weinstein, William wrote: >We are considering creating some public hotspots (@ entrances and in >cafeteria) for our visitors to use. We have some evening and other programs >where that kind of access would be seen as a service. Right now we are not >considering a charge but that is still undecided. We have a T-1 that we can >dedicate to this project and we have spare network capacity so we can >connect these areas on their own physical network. We have wireless in some >back office areas and in storage so this is not a quesion on how to set up >wireless access. My questions are aimed at anyone who has done this for >public spaces and if they have suggestions on how that set-up needs to >differ. Do we require logins or registration, what info if any do we >capture? Has anyone developed end user instructions to help visitors >connect? Have there been any issues with staff having to service visitors >attempting to connect? Has anyone developed any disclaimer language on the >use of the service? Does anyone have any recommendations of hardware and >software? > >Thanks to all. > >Bill > > > > > >--- >You are currently subscribed to mcn_mcn-l as: >[email protected] >To unsubscribe send a blank email to >[email protected] > > --- You are currently subscribed to mcn_mcn-l as: [email protected] To unsubscribe send a blank email to [email protected]
