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

hbbs at attbi.com hbbs at attbi.com
Thu Mar 27 13:34:38 EST 2003


Joe -

Yours is a great response (as have been the rest of y'all's) and I really
appreciate your taking the time to go in to such detail.  I have a few questions:

> 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.

Whence the "custom IPsec service" and why?

I also have a more general question.  When it comes to people being able to muck
about with other people's wireless LANs, does it take a Bob Toxen / Kevin
Mitnick or can fairly average shmoes find, download, and run "133t H4x0r" apps
that do all the heavy lifting once they've got a laptop, wireless card, and
"cantenna" in hand?  Furthermore, to what extent is the use of such tools taking
place in the real world?

- Jeff
> 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
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale





More information about the Ale mailing list