A secure wireless setup

It is common knowledge that the WEP as built into most wireless cards does not provide for wire-equivalent privacy. You need to take extra pre-cautions to secure data transmission therefore.

Architecture

Because there are to our knowledge no readily-available wireless-gateways which support encryption between the gateway and the client, we used off-the-shelf hardware to build a custom Linux-based gateway. The gateway provides Internet-access over DSL.

Forcing IBSS Ad-Hoc mode

Make sure that your cards use the latest firmware and drivers. For Orinoco/Lucent cards, updates are available from www.wavelan.com. If you want to use IBSS ad-hoc mode which is what we do, you need to change a couple of registry entries, because the Orinoco driver gets it wrong. You can tell that by looking at the LEDs of the wireless-card -- if one is constantly on and the other one is always blinking, you need to change the registry (it is in managed-mode then). Fire up regedit and search for "porttype". If you find an entry with that name and the value is "1", change it to "3". Also make sure to remove the client-manager from the Autostart menu, because it apparently resets the porttype entry (this is an observation, if someone has more information, please let me know).

IPSec Setup

FreeS/WAN works quite well, details follow at a later time.

PPTP Setup

Because there are some Win98 clients on the network which do not include IPSec technology, we chose to also provide PPTP access. This technology is secure enough, if you use 128bit stateless encryption which you can apparently patch into most Windows installations even outside the US/Canada. For an analysis of the PPTP 2 protocol, refer to Counterpane.

Update your Windows client

Important note: I spent a couple of hours searching the Internet for information on protocol errors, only to find out later that I needed to upgrade the Windows clients. It is strongly recommened to install those updates before proceeding. Symptoms in this case were errors of the sort "pppd[5034]: Unsupported protocol 0x722 received" etc. after successful PPP negotiation. The following passage is from the 2.4_KERNEL_PPTPD-HOWTO.txt, another useful resource.

Note that the Win95 routine is similar but requires Dial Up Networking Update 1.3 and 
both the Win95 and Win98 need the vpnupdate (free from Microsoft) to be installed 
first.  You're going to have to hunt around a little for these files as they keep 
moving.  However, here are a couple places to try first:

Windows 95

http://www.microsoft.com/windows95/downloads

Windows 98

http://www.microsoft.com/windows98/downloads/corporate.asp    


        1a. For Win95 machines install the DUN 1.3.

        1b. For Win98 machines use the add-remove programs tool to uninstall the VPN 
software. Some of the OEM's don't install this properly. Re-Install it using the 
add-remove programs tool. Go to windows setup (tab) select communications and press the 
details button.  Scroll down and check the VPN support.

        2. Install the vpupdate for your particular machine (win95/98 not 98SE).    

MPPE support in the Linux kernel

On the gateway-side, I patched the Linux-kernel with the diff found at http://mirror.binarix.com/ppp-mppe/ which also hosts various necessary patches for PPPD. The patch applied cleanly to a non-vanilla kernel (Linux 2.4.10pre8 + ext3 + IPSec). Make sure that you build PPP and the associated stuff as modules -- PPPD claimed that no MPPE support was available when linking PPP support statically into the kernel. Check out the README, it contains useful information.

Building PPPD with MSCHAPv2/MPPE support

Building PPPD is also easy. I used pppd-2.4.1 from here, and applied the appropiate patches from the above site (ppp-2.4.1-MSCHAPv2-fix.patch and ppp-2.4.1-openssl-0.9.6-mppe-patch).

To configure PPPD, create a file /etc/ppp/pptp-options. To get you started, here is an example which works for me:

# Win clients refuse these, so don't negotiate for them
nobsdcomp
nodeflate

# We are the server, don't set a defaultroute to the client
nodefaultroute

# Send information to syslog 
debug

# Tell the Win-Client that there is a nameserver at this IP
ms-dns 10.0.0.1

# Support chapms
+chapms
+chapms-v2

# Require the more secure chapms-v2
require-chapms-v2

# Enable all kind of encryption
+mppe-128
+mppe-40
+mppe-stateless

Now just setup /etc/ppp/chap-secrets. For every user, I put two entries into it:

username * password *
WORKGROUP\\username * password *

There are some problems, if you have multiple workgroups on your network; in that case, Windows seems to use the name of the first workgroup it encounters as a username prefix.

Serving PPTP

Now we need a PPTP-server. I initially gave WM PPTP (wmpptp) a try, but it did not seem to start the PPP daemon and did not claim interoperability with Windows clients. Today I use PoPToP 1.0.1 which worked out of the box. The installation is straight-forward. To configure it, create a file /etc/pptp.conf. Here is my file.

option /etc/ppp/pptp-options
debug

# The IP of the gateway (does not really matter apparently)
localip 10.0.0.1

# Which addresses to assign to the clients
remoteip 10.20.0.50-100

The result

Fire up pptpd and watch /var/log/messages (or whereever syslog sends it to on your installation). You can see how a successful negotiation session looks like here.