Increasing Bandwidth with Wireless Devices

Henry Psenicka and Bob Pocius

Many organizations are faced with the challenge of increasing available WAN bandwidth while controlling costs. Ours is no exception. We work for a local government, serving a municipality of about 40,000 residents. Our network provides services to almost 200 staff members, one third of whom work from satellite offices connected via dedicated WAN links. By 2001, we were outgrowing the capacity of our ISDN-based 128-kbps links and were exploring options for upgrading our network infrastructure. Although we found a number of commercial options for increasing our bandwidth, including leasing 100-Mbps fiber-optic connections from a local utility company, we wanted a more cost-effective solution.

We knew that 802.11b wireless technology was emerging as a viable option to facilitate building-to-building network connections, had the potential to provide the desired bandwidth, and could dramatically reduce or perhaps even eliminate our dependence on traditional data circuits. Some initial field trials and informal site surveys demonstrated that we could establish wireless links over distances of 5 km without significant difficulty.

We also recognized, however, that the security vulnerabilities of wireless technology needed to be addressed before we could consider it appropriate and safe for our organization. For the uninitiated, there is much resource material available that discusses wireless security issues, vulnerabilities, and exploits at great length (see links at end of article). In a nutshell, 802.11b wireless devices commonly use a technique known as WEP (Wired Equivalent Privacy) that is intended to encrypt and protect the data being transmitted over the wireless link. Unfortunately, WEP offers only limited value as a security feature because there are published methods for hacking WEP and exposing the encrypted data. We considered the use of commercial access points and VPN appliances to encrypt all wireless traffic, but decided to look for lower-cost alternatives when we realized the cost of eight VPN devices to secure our four wireless links.

It seemed clear to us that Linux could be a viable platform for this kind of situation, and we developed a concept for a wireless gateway "appliance". Based on previous experiences building and using LEAF (Linux Embedded Application Firewall) router/firewall devices to secure smaller networks, we established the following design objectives:

• Read-only boot media for maximum security (floppy or CD-ROM)
• Uses commodity PC hardware for low cost
• RAM-disk based operation for maximum performance
• Minimalistic Linux package for low memory footprint and high security
• Uses standard Ethernet NIC (we used 3COM 3C905B PCI 10/100)
• Firewall features
• VPN capability using IPsec
• Secure remote manageability using SSH
• SNMP capable for remote monitoring
• QoS support

We chose the Lucent/Orinoco line of 802.11b PCMCIA cards for many reasons (e.g., largest base of open source driver development, external antenna adapters, manufacturer reputation, etc.). The Orinoco cards had three different Linux drivers: wvlan_cs, wavelan2_cs, and orinoco_cs. We chose orinoco_cs because it was open source, actively developing, and supported wireless tools.

Unfortunately, most LEAF distributions were based on 2.2.x kernels, which did not provide adequate support for wireless devices, so we were forced to develop and demonstrate our concept on a Red Hat 7.0 platform. Our first prototype was assembled using a couple of retired PII-266 desktop computers running Red Hat Linux 7.0 (with a custom kernel 2.4.3 -- a requirement of the orinoco_cs driver), and we began routing packets between buildings on an experimental basis.

Because the Red Hat ext3 file system was still experimental, we used ext2, leaving ourselves vulnerable to possible system crashes (due to power failure) that could potentially corrupt the file system and cause extended periods of down time. We needed a better way to deliver this service.

The LEAF project came to the rescue late in 2001 with the appearance of beta versions of a new distribution called Bering, written by Jacques Nilo. Bering interested us because it was based on the 2.4.3 kernel, and was capable of supporting the orinoco_cs driver. Unfortunately, the orinoco_cs package hadn't yet been ported successfully to the LEAF/Bering distribution.

Our goal now shifted to replacing the Red Hat routers with Bering routers, since we could utilize the packet filtering capabilities and enjoy their trouble-free operation of a LEAF platform. After considerable correspondence with the author (Jacques Nilo), we successfully activated and tested the Orinoco wireless cards. Note that Bering, by default, is configured for use as a home gateway, and not as a point-to-point router. Shorewall (the firewall application) is pre-configured to filter traffic originating from eth0, which is the wired interface. We had to change Shorewall to filter traffic originating from eth1 (since eth1 is our wireless interface in almost all cases).

The basic steps involved in building a Bering system, which supports wireless network cards are:

1. Download the latest Bering release from:

http://leaf.sourceforge.net/

3. Rename pcmcia-orinoco.lrp to pcmcia.lrp. This package includes the standalone development of the pcmcia module (which was important at the time because of support for ISA-to-PCMICA adapters), and all the driver modules needed to make your Orinoco card work.

4. Configure syslinux.cfg (a small boot-config file), to load the various packages on boot.

5. Customize the configuration files to match the network environment.

There are several wireless related config files to pay particular attention to:

1.  /etc/pcmcia/wireless.opts

    --------- wireless.opts --------------------
    # Lucent Wavelan IEEE - Ad-Hoc mode for test card
    *,*,*,00:02:2D:*)
        ESSID="TEST"
        MODE="Ad-Hoc"
        FREQ="10"
        RATE="1M"
        KEY="s:[1]test"
        IFCONFIG="nick TEST"
        ;;

In our type of setup, both endpoints of the wireless link must have the same ESSID, MODE, RATE, and FREQUENCY. The ESSID can be any text string. MODE can be set to either MANAGED, or AD-HOC. AD-HOC (IBSS mode) is required to establish a Peer-to-Peer connection. The FREQUENCY can be any whole number from 1 to 11. Each of these "channels" represents a 50-MHz band, ranging from 2.412GHz, to 2.462GHz. RATE can be declared as 11M, 5.5M, 2M, 1M, or AUTO. These are simply representations of the speed of the connection in Mb/s. The KEY parameter is where you can optionally specify a WEP key. The example WEP key above reads "test", however, a 128-bit WEP key would be 13 characters (5 characters for 40-bit WEP). Note that the "s:" indicates that the key is a text string and not hex numbers. The IFCONFIG parameter is used to pass what would normally be command-line instructions to the initial configuration. For example, "nick TEST" would change the nickname of the system to "TEST".

2.  /etc/default/pcmcia
        PCMCIA=yes
        PCIC=i82365.o
        PCIC_OPTS=i365_base=0x3e2
        CORE_OPTS=
        CARDMGR_OPTS=

3. The /etc/network/interfaces file should look something like this:

        auto lo eth0
        iface lo inet loopback
        iface eth0 inet static
        iface eth1 inet static

4. The syslinux.cfg file on the root of the boot device must be modified to reflect the actual packages that you are including in, or removing from, the boot process:

  display syslinux.dpy
  timeout 0
  default linux initrd=initrd.lrp init=/linuxrc root=/dev/ram0 \
    boot=/dev/fd0u1680:msdos PKGPATH=/dev/fd0u1680             \
    LRP=root,etc,local,modules,shorwall,libm,pcmcia,wireless

Hardware Selection

Selecting suitable hardware was a key factor in this project. We wanted to be sure that we were using commodity products that could be easily sourced, and were well supported. Lucent's Orinoco wireless hardware seemed to be a good choice because it is acknowledged to be a reliable, high-quality product. Additionally, Lucent also markets ISA and PCI wireless PCMCIA adapters that allow the PCMCIA cards to be installed in a standard desktop PC. We opted for the ISA version of the adapter primarily because of reports that the PCI adapters were not well supported in Linux.

For a WAN application, selection and installation of antennas is another key consideration. The details of the installation process fill another article, but it is important to note that the wireless adapters selected for this kind of project must support connection of an external antenna. Again, Lucent seemed a good choice because of the availability of a wide range of compatible antenna and cabling products from a variety of suppliers. We chose high-gain 24db directional parabolic grid antennas for any link exceeding 500 meters. We observed that the directional nature of the radio signal reduces the likelihood of external interference, and perhaps offers some small security benefits. Someone would have to place a device almost directly in between the two antennas in order to interfere with our transmission. For shorter distances, we used smaller 15db or 19db parabolic antennas. In all cases, we used high-quality, low-loss antenna cable (LMR-400 or LMR-600) and tried to keep cable length to a minimum.

We now had a wireless router with a built-in firewall that booted from a write-protected floppy disk, and ran completely in RAM (making the file system invulnerable to permanent damage caused by external hacks). Our production deployment was based on Bering v1.0 RC-3, with pcmcia_cs-3.1.31, kernel 2.4.17, and version 0.9b of the Orinoco driver. We immediately experienced some error messages and difficulties with the stability of our link when we tried using the most recent Orinoco firmware (v 8.10), so we flashed our cards back to the previous version (v7.52).

Security Considerations

Conventional approaches to securing wireless infrastructure typically deploy additional layers of security that can be costly. There are a number of basic steps to securing a wireless WAN that should be observed. Maximum security is achieved when all of these methods are used in combination:

1. Implement basic security:

• Change default ESSID.
• Select channels to avoid conflicts and interference with neighboring devices.
• Strategic selection and placement of antennas to minimize the possibility of radio interference.

Although WEP has well-published exploits, they are not trivial for the casual user, and therefore WEP can offer some degree of security. It requires a deliberate and planned attack to penetrate WEP, so casual or accidental connection attempts will be prevented. Even if enabling WEP only makes you a less desirable hacking target than the guy next door who has WEP disabled, you have increased your level of security. We opted for the Orinoco GOLD version, which offered 128-bit RC4 WEP encryption.

3. Implement a VPN to encrypt all wireless traffic.

4. Use firewall filters to block undesirable traffic.

5. Ensure all default passwords are changed.

Our final step in making this an enterprise-class solution was to implement appropriate security. Using existing IPsec packages from the LEAF Web site, we established a tunnel between the two wireless endpoints and filtered all traffic coming from the wireless link that wasn't in the IPsec tunnel. The firewall package supplied with Bering is called Shorewall, and is essentially a collection of scripts that provide a simplified front end for iptables.

Implementing IPsec created a bit of a challenge because didn't have enough room on our floppy disk to include all the packages we needed. To overcome this, we put together a bootable CD-ROM containing all the packages we wanted and stored our dynamic configuration files on the floppy disk. Once we got IPsec installed, we configured it to allow only connections from the router at the other end of the wireless link (we currently use pre-shared key authentication instead of certificates due to ease of administration).

Here is some basic information describing our IPsec configuration:

# /etc/ipsec.conf - FreeS/WAN IPsec configuration file

# More elaborate and more varied sample configurations can be found
# in FreeS/WAN's doc/examples file, and in the HTML documentation.

# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
# this is the route that ipsec assumes it will create the tunnel across
interfaces=%defaultroute
# Debug-logging controls:  "none" for (almost) none, "all" for lots.
klipsdebug=none
plutodebug=none
# Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=yes

# defaults for subsequent connection descriptions
conn %default
# How persistent to be in (re)keying negotiations (0 means very).
keyingtries=0
# RSA authentication with keys from DNS.
authby=rsasig

#  VPN connection
#  Each machine will figure out which side it is on when ipsec is 
#  started for each end of the VPN.

conn left-right
# IP of the LEFT machine (On the interface that the tunnel will be 
# created on) so if the machines are connected on the 192.168.1.0/24 subnet the LEFT IP will
# be in that subnet.
left=l.l.l.l
# The Subnet that is connected to another interface on the LEFT 
# machine and will be accessible across the tunnel defined here.
leftsubnet=x.x.x.x/24

# IP of the RIGHT machine (On the interface that the tunnel will 
# be created on) so if the machines are connected on the 
# 192.168.1.0/24 subnet the RIGHT IP
# will be in that subnet.
right=r.r.r.r
# The Subnet that is connected to another interface on the LEFT 
# machine and will be accessable across the tunnel defined here.
rightsubnet=y.y.y.y/24

# Here we store the 2048-bit RSA public keys of the LEFT and RIGHT machines.
#
# NOTE that the values given here are simply examples and that to 
# create proper keys the instructions below need to be followed.
#
leftrsasigkey=0x6h3f65...
rightrsasigkey=0xfg9862e...
# We authorize the connection when the ipsec service is started on either end.
#
auto=start
To generate the 2048-bit RSA keys for each end point of the tunnel:

1. Use ipsec rsasigkey 2048 > left (or ipsec rsasigkey 2048 >    \
   right, for the right side) to generate the public/private key \
   pairs.

2. Copy the public key from the left file into the leftrsasigkey  \
   field in /etc/ipsec.conf, and the public key from the right   \
   into the rightrsakey field

3. Copy the /etc/ipsec.conf file to both machines.

4. Copy the private key from both files (left and right) into the \
   /etc/ipsec.secrets file on their respective machines

5. Modify each /etc/ipsec.secrets to be in the following format:

LOCAL_IP REMOTE_IP : RSA {

<< contents of the left or right file >>
}

Results

Our project is considered to be a resounding success, and our investment was recovered in the first 6-9 months of operation. The wireless network has performed well under moderately heavy loads, and the wireless links have proven to be reliable and trouble free, even in adverse weather conditions such as thunderstorms and Canadian snow and ice storms.

From a performance perspective, we consistently achieve file transfers through the encrypted VPN in the range of 4 to 6 mbps (which is about the practical limit of an 802.11b device). Network latency is quite low, with ping response times approaching 2ms across a single wireless hop.

The eight gateways have been very reliable, and after almost one full year of operation, the only problem requiring unplanned intervention resulted from the failure of one of the Orinoco pcmcia NICs after eight months of service.

Future Plans

Our future plans include enhancing the manageability of the devices by gathering operational statistics such as signal strength, noise levels, and dropped packets. We also intend to monitor and analyze latency levels over extended periods of time to allow us to evaluate the feasibility of using our wireless links for latency-sensitive applications such as VOIP. Our experience suggests that the wireless links can support VOIP traffic, but we need some tangible data to support our hypothesis and estimate where the breaking points will be.

Postscript

As of the completion of this article (December 2002), Jacques Nilo has just released Bering v1.0-stable., incorporating the 2.4.20 Linux kernel, orinoco_cs v.11b, pcmcia_cs version 3.2.3, Shorewall 1.3.11a, and IPsec 1.99. Support has also been added for Zebra, NTP, booting from M-Systems Disk-On-Chip, and a number of other enhancements. A completely solid-state LEAF device is becoming a realistic option.

We anticipate that by the time this article goes to print, we will have successfully upgraded our gateways to Bering 1.0-stable, and we are excited about exploring and implementing some of the more advanced features such as QoS traffic shaping and prioritization, and dynamic routing.

Credits

The authors would like to thank Michael O'Cleirigh who helped us complete this project by configuring, debugging, and testing our IPSEC VPN links, and assembling a bootable Bering CD-ROM package.

Thanks to all of the members of the LEAF development and user community, especially to Charles Steinkuehler and Jacques Nilo whose efforts made this project possible.

Links of Interest

LEAF project home page -- including Bering: http://leaf.sourceforge.net

Shorewall home page: http://www.shorewall.net/

FreeSWAN site for Linux IPsec development and support: http://www.freeswan.org

Unoffical FreeSWAN download and support site: http://www.freeswan.ca

Orinoco Wireless Hardware: http://www.orinocowireless.com

Wireless LAN resources for Linux: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux

Green Bay Professional Packet Radio -- an excellent technical resource for radio hobbyists and professionals: http://www.gbpprs.org

MRTG network traffic monitoring software: http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

802.11b News and Trends Weblog: http://80211b.weblogger.com

Academic paper discussing 802.11 security and WEP exploits: http://www.cs.umd.edu/~waa/wireless.pdf

The authors will be maintaining a project page at http://wireless.psenicka.ca to document ongoing developments of this project, and other related initiatives.

Henry Psenicka has been building and managing LANS and WANS since 1990, and relishes opportunities to implement effective low-cost alternatives to conventional technical solutions. His current responsibilities include managing network infrastructure design, security, and operations for a local (municipal) government. Henry can be contacted at: henry@psenicka.ca.

Bob Pocius is a network analyst/engineer and MCSE, currently completing his RHCE certification, and has been employed as an IT professional since 1996. Bob can be contact at: bpocius@cogeco.ca.