[ale] Practical Office Wireless (was Feedback on Wireless Standards)

Joe jknapka at earthlink.net
Thu Mar 27 11:03:34 EST 2003


hbbs at attbi.com writes:

> Given an office setting in a typical office building, what is a typical *proper*
> setup for the use of wireless to handle Windows laptops?  I'm particularly
> concerned about security and Linux-friendliness on both the WAP and laptop ends.
> 
> We currently have a D-Link DWL-1000 11Mbps WAP and as far as I can tell, the
> only real control that is placed on it is that the community string is set,
> although I don't know if it has been changed from the default (I assume that
> this "community string" also gets set somehow on the client side and acts as a
> kind of password).   
> 
> We also have a couple of D-Link DWl520+ PCI wireless adapters on hand but I'm
> unsure as to their usability under Linux.
> 
> Two things concern me:  RF "sniffability" (i.e., being able to capture and
> understand wireless network traffic) and "freeloading" (i.e., providing Internet
> and file server access to people upstairs, downstairs, in the parking lot, etc.  
> 
> Can anyone here clue me in or do I just need to go buy Bob's book? :)

I'm working on this very issue now. My wireless clients are a mix of
Linux and WinXP/Me/98. I have everything working for both Windows and
Linux clients, but all is not completely smooth.

Here's what I'm doing and why:

(1) WEP is *disabled*. It's useless and a pain to configure when adding
new machines to the network. That means that anyone can associate with
my AP (all they need to do is stiff the SSID). However, that does them
no good; the measures below prevent intruders from taking any advantage
of my open AP.

(2) I've got a firewall box sitting between the AP and my LAN. That
box's only job is to protect me from wireless interlopers. It also
ensures that untrusted machines on the wireless net can't see machines
on the wired LAN.

(3) All traffic between the wireless clients and the firewall box is
encrypted using IPsec. The firewall is a Slack 8.1 box running
SuperFreeS/WAN and RoaringPenquin L2TPD. On the WinXP side, I'm using
the native Windows IPsec+L2TP+PPP client, which is a pain in the ass
to configure, but which works. It's also possible to convince WinXP
and Win2K to do plain IPsec without L2TP, but I haven't tried it.
On the WinME/98 boxes I'll use the Microsoft VPN adapter, available
"for free" from M$ (I actually haven't set this up yet). Linux clients
use FreeS/WAN to talk to the firewall.

The reason for this is so that snoopers can see only IPsec
Encapsulated Security Payload packets on my wireless segment; that's
much harder to break (when properly configured) than WEP.

(4) The firewall is configured to accept IP packets on the wireless
interface (eth1) only on port 500 (ISAKMP). That means that all you
can do on the wireless side is establish an IPsec tunnel; no
in-the-clear traffic can get into or through the firewall. (Once a
client establishes an IPsec tunnel, they can pass any traffic they
like across it.)

(5) Except for a couple of trusted wireless clients, the firewall
prohibits packets from the wireless side from going anywhere
except to the Internet gateway on my wired LAN; wireless clients
can't talk to any machine on the wired network unless I
explicitly allow them to do so. That means that even in the
unlikely event that an interloper manages to establish an
IPsec tunnel with my firewall, they still can't touch any
of the critical stuff on my wired LAN; all they can do is
steal Internet access.

Note that without the IPsec tunnels, an intruder would still
be able to talk to the other wireless clients. The presence
of the IPsec tunnels prevents that, as well as providing
strong encryption for all the wireless traffic.

To figure all this out, I started with the FreeS/WAN page
(http://www.freeswan.ca), and this nice page (pointed out to me by
another ALEr) about Windows and FreeS/WAN:
http://www.jacco2.dds.nl/networking/msl2tp.html.  The Linux FreeS/WAN
stuff was easy to set up on both the client and the server. Getting
the Windog clients working was more of a challenge, and involved lots
of network sniffing and debug-log analysis to figure out what the heck
was going on; but invariably the problem turned out to be that I
hadn't read the instructions and manpages carefully enough.

I do have some lingering problems with the wireless clients.  First,
sometimes I have to shutdown ipsec on the firewall and then bring it
back up in order to get the XP client to make a VPN connection. That's
a real pain, and would likely be a showstopper in a corporate
environment.

Second, the protocol overhead is a bugger. Anything that's going to
talk to the Windows wireless clients has to have its MTU set to 1000
or less, because of the many layers of protocol encapsulation that
happen between the firewall and the Windows clients
(PPP-in-L2TP-in-IPsec). I'd like to handle the MTU issue in one single
place (like on the firewall), but I haven't figured out how yet.  So
some stuff (mainly VNC) won't work on the Windows wireless clients at
the moment, unless I take special pains to set the MTU on the box on
the wired LAN (or on the Internet) that I want to talk to.

Finally, I have a Cisco VPN client that I need to use to access my
employer's corporate net. Since that client relies on a custom
IPsec service on Windows, it can't co-exist with the Windows
IPsec stuff; which means that when I want to get to the
corporate net, I have to plug my XP laptop into my wired LAN,
disable Windows IPsec services, and enable the Cisco ones.
Bleh.

Cheers,

-- Joe Knapka
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale





More information about the Ale mailing list