Real Security

Given the insecurity of WEP and the authentication system built upon it, a more robust privacy and authentication mechanism is needed. There are at least two good systems, both of which I have used. Note that I do not have facilities to snoop on the actual data packets as they fly across the air, so this is a description of steps which I expect to provide the desired authentication (both of the access point and the client) and privacy.

A good overview describing encrypting network traffic is available. It's somewhat dated, presently showing a date of October 2000.


This was the first method I used. CIPE has been developed by Olaf Titz, and is a standard part of the RedHat kernel. However, it is only available as a kernel module, and this is unacceptable (to me) for any machine exposed to the outside world. I might live with it for a wireless access point, though,

CIPE uses a shared key which is used to exchange working keys. As each end needs the key, this also provides authentication, in that only users with the key can make an effective connection. The encrypted channel across the wireless link uses UDP protocol. There is no official port allocated, so I chose 501, one above the standard IPSEC UDP port. Both ends need to agree upon this!

There is a simple configuration file at each end, and I found it really easy to get this up and running.


This is the official IETF tunneling protocol. Originally intended for use with IPv6, it has been adapted to IPv4 and provides encrypted connections between individual machines or networks. IPSEC is not a regular part of the linux kernel, however the FreeS/WAN project installs easily into the kernel. Note that it does require that you configure and build a kernel of your own. The nice part is that it is hard wired into the kernel - no modules!

IPSEC uses public/private keys for key exchange; the exchanged keys are for encrypting traffic on the link, and are changed at regular intervals, thus requiring that snoopers break the encryption regularly. And since each end needs the public key of the other, there is also authentication of the other end.

Network Topology

Since the wireless hardware is not capable of providing the required degree of privacy, the access point can no longer be placed on an existing network segment, but needs its own interface to a router/firewall machine. My network layout is thus:

The wireless network is essentially a DMZ all on its own. This allows a firewall to be established on the eth0 interface. The firewall rules are quite simple - allow IPSEC (or CIPE) traffic in! CIPE uses a UDP port which you can select; IPSEC uses two protocols (ah, esp) and UDP port 500. I also allow DHCP requests, and currently DNS. The need for DNS is not obvious, but is probably benign. DHCP is currently out of use, as IPSEC and DHCP do not play well together - at least until I figure out how to route DHCP traffic to the wireless net around the IPSEC channel.

Operational Considerations

Both methods create a new network device - ipsec0 in the case of FreeS/WAN, and cipcb0 for CIPE. However, while FreeS/WAN changes the routing table to make it the automatic link, CIPE does not, and thus requires fiddling with routing tables when the link comes up, and when it goes down.

DHCP causes problems for both methods. The FreeS/WAN problem is a routing one on the server. Specifically, the client asks for an address, but the reply will attempt to go over the IPSEC channel. I believe this can be worked around, but have not done so yet. For now, the solution is static addresses on the client.

The ultimate decision was to use IPSEC for the link. Either method appears to be acceptable, but IPSEC does more of the route fixing steps when started up. And secondly, IPSEC on the client means I can establish an IPSEC channel to my network when travelling, as the code is already in the kernel.

Making DHCP and IPSEC operate together is a little tricky, and is described in detail on the DHCP and IPSEC page.

Getting Serious
Sundry Other Stuff

Version: $Revision: 1.6 $; Updated at 15:47 EST on Tue Apr 11, 2006
Copyright (C) 2002 - 2006, Lindsay Harris