[unisog] Campus Wireless deployment models - 3 questions - feeback appreciated
chmorl at wm.edu
Mon Feb 13 15:36:02 GMT 2006
These are good questions. See answers in-line for what we do:
> 1. Do you offer an "open access" wireless lan?
Regarding wireless authentication, currently all of our network is "Open";
i.e. no WEP, no WPA2, etc. However, we do play tricks at our wireless
core to force users to authenticate via a web browser.
By default, we use MAC address authentication to allow every client onto
wireless. First, we assign all unknown MAC addresses to a "registration"
vlan. The only thing you can do on this VLAN is authenticate via a
browser to a Linux-based router/web-server on the subnet egress/ingress
with a valid campus username/password. Once authenticated, we issue a
deauthenticate request to the access point. This forces the client to
reassociate, reauthenticate, and request a new DHCP lease. Since the MAC
is now identified, we can match MAC address to username and determine what
type of VLAN to assign the wireless client. Using the new DHCP lease, the
client is pushed onto whatever VLAN we assign it ; e.g. faculty, staff,
grad student, undergrad, etc.
If the user is being bad, we assign the client to a "penalty box" VLAN.
In the penalty box VLAN, the user has access to a remediation web page.
If the user is really, really, really bad, we can just refuse
authentication for that MAC address.
We employ a similar system in our wired infrastructure. The nice thing
about it is that it gives the user the same look-and-feel whether on
wireless or wired.
It also gives us a pretty easy way to support guest access. If someone
does not have a valid campus username/password, the user can elect "guest"
access when trying to authenticate via the browser. Then the MAC address
is assigned to a guest VLAN with a limited set of privileges. We also
place timeout restrictions on these guest access accounts to cut down on
It helps to use a thin-client architecture, like our Cisco Airespace, that
brings all of the wireless traffic back through centralized controllers.
That way, we can cut down on security incidents on the same VLAN by
forcing all of the traffic through a centralized IPS "gauntlet" to run the
Before we went with Airespace, we also looked at Aruba -- which should be
able to support the same type of architecture.
> 2. If so do you required any sort of device registration and/or
> encryption? If your answer is no, how do you deal with potential legal
> risks from things like filesharing?
Regarding filesharing, on our wireless networks we currently block all P2P
traffic and we also prohibit TCP-based servers that service off-campus
sites. We do this primarily to preserve bandwidth. If anyone has
problems with these types of restrictions, we simply tell them to use the
wired network which has less bandwidth type of restrictions.
Aside from folks who really want convenient Skype access, this hasn't been
a big problem.
> 3. Do you offer varying levels of service on your wireless lan? For
> example - an "open access" wireless lan that offers only web browsing to
> non university resources, and a registration/WPA required wlan for student
> access etc?
We are hoping to implement a shadow SSID that supports WPA2 encryption
starting this summer.
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
More information about the unisog