Installing a Wireless Network for University Members

Oliver Gorwits, Roger Treweek

Oxford University Computing Services

<wireless@oucs.ox.ac.uk>

Since Last Year…

OUCS pilot completed

A better idea of service requirements

Members and Visitors

A better idea of user requirements

Public or Shared spaces

Six co-operative deployments of OWL-VPN

Tracking new vendors and initiatives (LIN)

Technology and Issues

Why Wireless?

There are some obvious locations

Lecture rooms

Libraries, Study areas

Hard-to-wire areas

Or for specific reasons

Conferences

Meetings

Mobility

Wireless Problems

Security – products are not secure enough

Privacy – snooping passwords, data

‘Hub’ style operation – anyone can see all traffic

Hacker tools readily available

Performance

Propagation / Attenuation

Wireless Technology

802.11b

2.4GHz, 11Mbps – basic common standard

802.11g

2.4GHz, 54Mbps – popular but not without flaws

802.11a

5GHz, 54Mbps – ideal, but not yet common

Site Survey

Site survey is still recommended

Use same make/model as it is intended to deploy

Consider main coverage areas

Number of access points and location

Interference issues

Channel settings

Power settings

Security

Three areas to consider:

Authorized users only

Encrypted transmissions

Accountability of usage

A Service for University Members

Cisco VPN

3000 series “concentrator”

Redundant hardware

>1000 concurrent users, 100 Mbit/s

Special VPN IP address pool

Client program for users, multi platform

VPN-assisted Wireless

Satisfies our requirements:

Authorization:

Remote Access accounts

Encrypted transmissions

Accounting: RADIUS and logs

Site Requirements

Separation from the main data network

For the clients:

DHCP – unregistered

DNS lookup  VPN concentrator

On the network:

IP filter Clients  VPN concentrator

Wireless Settings

Infrastructure (not Ad Hoc)

Network Type

192.76.27.246

Concentrator IP

UDP 500, 1500 both directions

VPN IP Filters

Open (not Shared)

WEP Authentication

Disabled

Static WEP

OWL-VPN

SSID (Network Name)

Value

Option

Access Points

Cisco 1200 series AP

Combined 802.11b/g with 802.11a add-on module

IP Filters, DHCP server

Power over Ethernet (injector)

~330GBP in 2004

Alternatives from 3Com, etc

Or use an integrated solution (Trapeze…)

Use Case 1

Little additional equipment

Access Point and Power Injector

No NAT

Small IP pool from unit for DHCP

Simple configuration

Web Tool for Cisco 1200AP admin

Use Case 1

University

backbone

network

PC

PC

PC

Access

Point

DHCP & IP Filter

Use Case 2

Less accommodating environment

Access Point and NAT Appliance

NAT

IP filter on either appliance

More hardware to configure

But mostly default configuration

Use Case 2

University

backbone

network

PC

PC

PC

Access

Point

NAT

Appliance

IP Filter

DHCP & NAT

Use Case 3

More substantial deployment

Fully switched network

Redundant cabling

or, VLAN-capable

Access Points are bridging

Single Appliance to IP Filter, DHCP, NAT

Most flexible and future-proof

Use Case 3 - cabled

University

backbone

network

PC

PC

PC

Access

Point

Bridging

Appliance

Access

Point

Bridging

DHCP & IP Filter

Use Case 3 - VLANs

University

backbone

network

Office distribution network

PC

PC

PC

Access

Point

Bridging

Appliance

Access

Point

Bridging

DHCP & IP Filter

VLAN

Use Case 3

University

backbone

network

Office distribution network

PC

PC

PC

Access

Point

Bridging

Access

Point

Bridging

DHCP &

IP Filter

Alternatives

Bluesocket

Wireless / Wired “Captive Portal” appliances

Available from BTSkynet Systems

Trapeze and Vernier

Full Integration solutions – edge to core

Available from QolCom

Networking Futures

FroDo

A proposed upgrade to backbone connections

Single fibre becomes managed 24-port switch

UPS and Cabinet

One FroDo at main unit site

Multiple services and Quality of Service

Already deployed in a few locations

Around 2kGBP depending on fibre work

FroDo (2)

Many opportunities:

Shared occupancy

Simpler annexe management

Single Firewall

Bulk transit

“Dirty Network”

Wireless handoff…

Guest Access

Difficult to cater for

Various periods of attendance

Not University members

Might arrive at short notice

Use a Gateway or “Captive Portal”

HTTP redirect to HTTPS login page

Successful login opens an IP Filter

Allow basic services, including visitor’s VPN

Deployment Requirements

A FroDo

Separation of your wireless network

Layer 1 : separate cabling

Layer 2 : VLANs

Access Points that support multiple services

MBSSID

VLANs

Guest Access

University

backbone

network

PC

PC

PC

Access

Point

Bridging

FroDo

Offices Network

Multiple Services

Account Management

Centrally organized, devolved administration

Running from servers in OUCS

Webauth’d

Nominated users login with Oxford Username

Create accounts singly or in bulk

Set an expiry

Set the sponsoring user or group

User Experience

Connect to an open, zero-config network

Attempt to browse web; redirected

Login with credentials

Cookie placed in their browser

Rapid reauthentication

IP Filter opened until account expiry or disassociation

Current Status

Sadly no FroDo box at St. Catz, yet

Will be running for a 200 delegate conference here in September 2005

Login and network parts are complete

Account Management nearing completion

Still evaluating commercial alternatives

No suitable candidate so far

Q & A

Last year we looked at the broad scope of wireless technologies, and what would be required of services for the university.

oucs has now completed its pilot and begun to co-operate with some units on wireless installations, and I wanted to share with you our findings and forecasts.

The workshop today will be split into three main areas. Firstly I’ll review the wireless technologies we’re talking about, and identify the difficulties we face in oxford, but also the benefits that wireless can bring.

Then I’ll cover installing a vpn-based service for university members; rather than go through configuration files our experience has shown the network topology proves to be the key to a deployment, so I’ll take you through three use cases, which I hope will map onto something like your own network. Finally, I’ll move onto some of the broader networking futures in store for the collegiate university

since last year we’ve completed a pilot study in the oucs buildings in which we sought blanket coverage of the building including offices, public areas and lecture rooms. For the most part I’m glad to say it’s been a success, and we’re now using that network for all our development as well, but there have been some areas where it’s performed less than spectacularly

Through the pilot and also our co-operation with other units we now have a good understanding of the demand for wireless within the collegiate university. In the main it comes from the members rather than it staff such as yourself, which isnt surprising given the marketing. They demand it for themselves as well as their guests, and mostly want it in public areas, as it soon dawns that a fast wired connection is preferable if available.

We have six compatible deployments of the OWL-VPN service underway, which I think isn’t bad going considering each one is implemented in quite a different fashion but is perceived in an identical way by the user, which is exactly what we want.

At oucs we’ve also been tracking new vendors, some of the black box appliance houses that are pushing hard into the education sector – I’ll touch on that later. LIN is a UKERNA initiative to provide location independent networking whereby your home institution’s network logon credentials (this might be the remote access account to an oxford user) are valid at other participating LIN HE sites; quite interesting and exciting.

we were pretty much on the money last year when we identified these areas as those that would receive wireless as a priority.

We’ve seen the bodleian law library, which due to its listed status cannot have any more ethernet ports, so OWL-VPN was a good candidate there. We’ve also seen a couple of MCR areas setup as well, for a bit of ad hoc studying.

Conference business is very important to some units, and clearly wireless is an attractor there. We have a system coming online here at st catz over the next month or two for their conference delegates.

The problems havent really changed much in the past year, in fact they’ve got a little more serious as the hacker tools become even more widespread and flaws are more widely understood.

We’ve learnt a lot about the propagation and attenuation problems of wireless, in particular how the three standards work together, and work against each other.

B is of course the old faithful, and you’ll find few users without this available on their systems at the moment. G seemed like a fantastic solution to the poor speed of B, but in fact has proved to possess as many flaws as its little brother. The propagation of G is lower than B, and when there are B users on your network, the G users can forget about getting anything like the full bandwidth out of their connection, as there are all kinds of compatibility issues.

A really is going to be the way forward, I feel, at least. It has none of the domestic interference issues of B and G (e.g. DECT phones) and is a more reliable service. However it does not propagate nearly as well as the other two standards. Now this wouldn’t seem to be a problem as you have plenty more channels with A and can just throw a few more access points at the problem. However when those APs are running all three networks, the differing propagations are a nightmare when attempting blanket coverage.

This is why we strongly recommend some kind of site survey, even if it’s borrowing some kit from your vendor to play with yourself. There are simple meters included with operating systems that should give you a rough idea whether your’re designing things along the right lines. You can always commission a professional report; we had one at oucs and it wasn’t really worthwhile, but I’ve seen others where they do your floor plans and they look impressive.

And finally in this review, here are the three pillars of wireless networks that we ask you to consider in every deployment.

Authorized users in this context means people you’ve planned to give access to your network to. For wireless networks, I think there’s a distinction to be made between those that use your radio space, and even associate to your access points, and those users that send traffic over your unit’s network. With OWL-VPN we’re happy to have anyone connect to the access point – an IP filter prevents them doing anything nasty to the local network. It’s not worth, really, protecting the associations, as a malicious user can still sniff traffic and DoS the service without associating.

Naturally, we must have strong encryption over the air, and preferably over the wire too.

Accounting comes through logs, as we do need to know who’s been logging on to your network. Keeping track of MAC addresses, DHCP logs and VPN usernames has been sufficient for our purposes.

Now lets look at how we can satisfy those requirements for university members.

With the OWL-VPN service, you can easily deliver secure wireless networking to your users. To help you with this, if you use the common broadcast network ID you can point users to our online help pages, and we also provide posters that you can place in hotspots.

Just to give you an overview of the University VPN service, in case you’re not too familiar, especially with its recent upgrade.

The appliance is called a concentrator, and handles the encryption in redundant hardware, and since the upgrade by Andy in my team in 2004 supports over 1000 users (actually upto 5000) sharing a 100mbit throughput.

The VPN service serves the three security pillars I described earlier.

We get authorization as a byproduct of the users needing an OUCS Remote Access account; this means they automatically need a University ID Card and are therefore accountable to our IT statutes. There are a great many users already familiar with the VPN so it’s nice to be able to leverge it onto wireless.

Naturally the VPN is an encrypted service, with these protocols being forced by the concentrator – they’re not under user control; the alternative way of looking at this is that users do not have to configure tricky windows dialogs, nor does their Operating System or network driver need to support particular crypto.

The Concentrator takes care of accounting via the OUCS RADIUS servers and central logging servers.

Now onto the nitty grittty. What is requred of YOU?! What does your network have to provide to a wireless user. Well for OWL-VPN it’s only three things, which is nice and simple.

The client needs to be able to get a DHCP lease to get on the network, naturally. Here we come to a sticking point for many over an interpretation of the regulations. They say you must maintain network separation, and the logical way of doing this might be through NAT. but really I think it’s fine to reply on IP filters and give the clients a lease from your unit’s main ip pool. They’re going to get reallocated a public univeristy ip anyway by the vpn concentrator.

the third item is the real network separation. Make sure that the only thing the client can do is hammer on the door of the vpn concentrator.

This is just a table of settings you can refer back to after this workshop.

Here’s an example of what you might use for a wireless access point – the same ones that a few sites including OUCS use already.

They’re quite well featured, we’ve not had trouble with them at all. Cisco devices aren’t that scary to configure, even if you’re used to 3Com, although there’s no problem with using equivalents from 3Com as well, as I believe are installed here in St Catz. Just make sure you go for an enterprise model, not the domestic stuff, otherwise you’ll have no scope in the future for further services whatsoever.

Power over Ethernet for those that arent familiar uses the spare cores in a regular ethernet cable to send 48v dc to power devices, therfore you can inject power at the location where you also inject the network, back at your distribution cabinet – it’s much neater.

Trapeze and the like make access points that need a head unit or black box appliance installed in a server room somewhere to manage them. The idea is that they’re easily replaceable and there’s less configuration by having them centrally managed. Not quite appropriate for the collegiate university environment, but certainly an option within a sinle management domain such as your unit.

This option lays out the basic design for OWL-VPN. All you need at a minimum is an access point that supports the requirements I laid down earlier about ip filters and dhcp.

You need to borrow a small ip pool from your main site network. For those buying a cisco device I’ve made the process even simpler by putting together a web tool that writes Cisco configuration files for you, so you hardly have to bother with the device’s own web management interface.

SHOW CONFIG TOOL…

As you can see, there’s not a lot to it.

The access point takes care of everything for you; you can connect it straight into your site’s network as shown here. We’ve managed to satisfy the security requirements; you can point users at the oucs help pages for VPN and wireless tips, and as I say we give you posters to place around the hotspot.

This case has also cropped up: the site in question didn’t actually have any spare IP addresses for a separate wireless dhcp pool.

In this case we need to NAT the clients onto a single IP address, but that’s okay because the VPN works through NAT and from the University network they’ll all appear to have University IP addresses from the VPN pool.

As the Cisco access points don’t have NAT support, we need a second appliance that will do this for us, so as you can see the network diagram is slightly different:

The access point in this case is configured through its web management interface; mostly with the sensible defaults but locking it down a bit and adding the all important IP filters.

The NAT appliance handles the DHCP and NAT, and perhaps is a DNS resolver as well. In this use case you’ll have to investigate the configuration yourself, depending on the NAT appliance, as I’m not overly familiar with such boxes.

When you have more than a couple of access points, it makes sense to chose a different strategy, as we have done in OUCS.

If you have a more modern network, one that is fully switched with managed devices you can go for something that’s a little more future proof.

In this case the access points are dumb bridges, and all the filtering DHCP and NAT takes place on a single, central appliance, as you can see here:

So at this site they have plenty of spare cabling around the building, so they could run cables to all the access points from one appliance, that then allows filtered traffic onto your site network. There can be NAT involved if you wish, but it’s not necessay.

This is the same use case, but in another site’s network where they use VLANs rather than cabling for network segregation. Here they’re trunking a special Wireless Vlan over the main site network down to the appliance. Once the traffic is laundered it’s allowed back out onto the distribution network outside of the special wireless vlan.

This of course saves cabling, but is a little more complicated to manage. Only a little, mind you, and it provides the greatest flexibility.

But what you might really want to do is dispense with that appliance alltogether, and punt the scary wireless traffic off to OUCS to worry about.

This hypothetical network does just that, splitting the VLAN out and somehow offloading it to the backbone nework independently of their main site connection. This isn’t actually completely make believe, as we’ll see in just a minute.

Just to finish off this section, here are some alternative technologies to the OWL-VPN solution. I’ve spoken a little about these earlier, but they’re the vendors currently pushing into our sector. No small beer, by the way.

Lets turn now to what’s becoming available in 2005 from OUCS in terms of networking and wireless networking in particular.

Most of you probably haven’t heard about this project. One problem my team deals with is that the single connection to each unit is sometimes inappropriate for that site, for instance at University buildings inhabited by multiple departments.

FroDo stands for Front Door. Whereas currently we lay a fibre to, quotes, your front door, FroDo is an advancement to that design.

FroDo is, to you, simply no more than an upgrade to your backbone connection, from a single fibre to 24 copper ethernet ports. We do this by installing a small cabinet, with a single switch and a UPS in a convenient location. Rather than messing about with fibres and media converters you just get a regular copper ethernet cable for your data network. Where it becomes really interesting is in the possibilities for the other 23 ports!

This isn’t vapourware by the way, it’s already installed in a few sites, as there are real problems that this has helped us overcome:

In particular it helps with shared occupancy buildings. Rather than take the biggest occuopant’s network and divvy out odd chunks to the other lodgers, we can bring five, six, seven different unit networks into a building and straight to the offices or desks.

Coupled with this is the elegant handling of annexes. With a FroDo box installed at your main site, we can present your annexes on the additional switch ports, rather than letting them access the backbone and Internet directly. This means you can run a single firewall for all of your sites; the annexes can also use your main site DHCP, and see network services with ease.

Other uses for FroDo include potential for eScience and GRID computing transfers – bulk data at low priority, we could have a dedicated port for that. We’re also looking at supporting a Dirty Network port where you can plug infected or unpatched machines for online downloading of patches and updates with security. This is still very much in development, but I hope you get an impression of the capabilities of FroDo.

And last but not least, that thing that I hinted about eariler is Wireless Handoff – letting OUCS deal with the service centrally, and this is key to a collegiate univeristy-wide wireless network for visitors.

So lets come back to wireless again, and look at the profile of our visiting users.

We’re talking about anything from a vendor who might be here to sell you some equipment for an hour, to a week long conference delegate. Clearly they’re strangers to the University, and we need to manage that, and we need to be able to get them access to the network without delay.

They don’t need a terribly broad service, just the basics of email and web, ssh, and most likely VPN to their home site.

At OUCS we’ve already been developing an OWL-VISITOR system, as its called.

For this service you’ll definitely need a FroDo box, as it’s only sensible to have the guest account management in a central place, otherwise there’d be huge duplication of effort and support as you ran servers locally.

You really do need to separate the wireless network this time – properly. No getting around it because these are strangers to the University and we don’t want them to be associated with your network.

You also need relatively smart access points that can run multiple networks, preferably broadcasting multiple network IDs. This is why all along we’ve been pushing really good access points and network designs, as we don’t want anyone to be saddled with ageing kit that’s uncompetitive.

Just to show this in another way; you can see that now none of the wireless traffic goes over your site network.

Although the servers might be at OUCS, of course it makes sense to have a devolved service, as, say, we do for sections of the DNS.

In our design there’s a web management service available to staff in your unit; they can login and create accounts that are instantly available on the wireless network. As it’s a webauth service it’s quite secure; we can control who is able to generate these accounts if we wish, and we have accountability to track who did what.

A key feature of the design is that each account has a sponsor – the person or group that are hosting their visit at Oxford. We then have a contact within the University should the security alarm bells ring, for instance.

The user experience is much like that at any coffee shop or airport. They are free to associate with the access point, again it’s not worth bothering with complicated setups when there are a myriad of platforms operating systems and drivers out there to confuse the user and ourselves.

Their web browsing is redirected and they are forced to enter their login credentials in order to have an ip filter opened for their host.

A nice feature of our system is that a cookie is placed in the browser upon login. Should they leave the area for some time and their ip filter times out (as it will for security reasons), the redirecting login page will see this cookie when they return and not ask for the username and password again.

Most of the system is complete and working in OUCS; I’m just working on the account management – the part that is devolved to your units – at the moment.

I’m also not taking my eye off the other alternatives out there. I’m happy to accept that something better might well come along; but as it stands there’s no black box appliance or open source product that really fits the bill for our loose federation here. Something like I’ve described and developed hopefully does, but I’m happy to hear feedback from you to steer that development.

Installing a Wireless Network for University Members

Oliver Gorwits

2005-06-20T21:46:31