[unisog] Campus Wireless deployment models - 3 questions - feeback appreciated

Clarke Morledge 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 
abuse.

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 
packets through.

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.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187


More information about the unisog mailing list