Lets assume that no amount of tips, tricks, and WEP stuff will make 802.11 secure .... Then what do you do?

[Buddha Bart]

I've looked around a lot and everyone seems to agree IPsec is the answer, but exactly how would you get it working?

For instance, if you use a linux machine as a gateway, how would you setup freeswan and the clients? How would you make sure that non-IPsec traffic was not let through?

Perhaps you'd go with a low end cisco or sonicwall applaince?

In any case, would each host on the wireless network be establishing a VPN into the server/appliance, or can you run a IPsec only network without VPNing?

Aren't most of the appliance products that can do this stuff focused on creating a IPsec VPN out the wan port to some central office, not on the lan side of things?

bart

 

[cmetz]

*IX solution: OpenBSD and/or FreeS/WAN as both client and IPsec gateway.

Windows-user solution: Linksys BEFVP41 as gateway and Win2k/WinXP built-in client.

 

[Lord Evermore]

I'm not sure anything is set up to do IPsec networking internally, but it would I think pretty much require a VPN between every client and the host, in order to encrypt the IP traffic before it's transmitted over the wireless. There shouldn't even be any non-IPsec traffic unless you generate it, but I don't know if there's any way to stop it from going out. VPN and encryption is meant to provide protection for specific data you want protected by passing it through the VPN rather than normal transfers, not to control all transfers through the system.

Hardware that does encryption of traffic may be available though. I'm not sure exactly how network cards with onboard encryption work exactly, but it may be that they encrypt all data that passes through them, no matter what the protocol. Don't know if there's anything for wireless though. That's the only way to guarantee that nothing unencrypted goes in or out, and would of course need hardware on both ends.

 

[Lord Evermore]

The BEFVP4 doesn't provide wireless access.

It also isn't intended to be used for an internal VPN/IPsec setup. It's used to allow the internal network's traffic to be sent through a VPN to a remote location without a VPN client on the computer, or allow a remote computer with VPN client software to connect to the network. I don't imagine you can make it so that traffic between clients internally is VPN controlled.

You could make it work by connecting a wireless access point to the WAN port of the router (so that it goes through the VPN server), and then connecting the LAN port to whatever wired network you have so that the now unencrypted traffic goes to the rest of the LAN, but this could result in a bit of a networking mess, with multiple subnets or NAT configurations causing problems.

Thinking about it now, can two computers with VPN client software simply establish a tunnel to each other?

Even if not, you could set up a computer with VPN server software to act as a gateway to the wireless devices and the rest of the network. That'd be similar to using a router with VPN functions, so it might also have the same limitations.

 

[Buddha Bart]

BEFVP41

How would that work? Would I run a cable from one of the switch-ports on the AP to the switch port on that? Then from that run the WAN port into my linux router?

bart

 

[Lord Evermore]

All of these connections will result in NAT IP conversions, which can play hell with your connections when you do it multiple times. You'd also have to check with Linksys on whether the router can actually make a VPN connection between itself and an internal client; its intended use is for translating non-VPN traffic from the network to your WAN connection, not providing internal VPN connections.

 

[cmetz]

Buddha Bart, in the scenario I describe, the wireless LAN becomes the "outside" and the wired LAN to your outside world connection becomes the "inside." So the "WAN" (untrusted) interface of the BEFVP41 would connect to the WAN interface of your wireless AP. Your clients would have an untrusted IP address on the wireless LAN, and a trusted IP address on the wired LAN. You'll need to set up some static routes to make this all work out.

The trick is going to be convincing the Linksys box that its default route is out the "LAN" interface in order to send outside-world traffic somewhere else. I'll have to get my hands on one to see if it can be done with the current firmware. If not, a higher-end VPN widget like a NetScreen should be able to do that, as could a PC running OpenBSD or FreeS/WAN. The Linksys is cheap, has hardware crypto [reasonably fast], and has a web GUI that's relatively easy to use, which is why I suggested trying it.

Lord Evermore, the Win2K and WinXP IPsec implementation is a bit crippled, and I've heard conflicting reports as to whether it can be used as a VPN gateway instead of just a client (that is, some people tell me it can't handle forwarding on). I don't do Windows, so I haven't tried it myself.

 

[Soybomb]

Perhaps it just depends on your application, for example perhaps some of the cisco gear that does leap, etc would be suitable? Seems like less administration overhead to me. If you are limited to run of the mill 802.11b stuff, does everything have to be secure? ssl/ssh/etc can be great to keep everything secure.

 

[Metier]

If you went with a cisco pix 501 firewall you just need to apply the crypto map to the inside interface, install the vpn client then connect with the vpn client then all traffic would be encrypted to the pix, or you can specify what traffic is encrypted and what isn't with the split-tunnel option. so the setup would look like.

dsl <<< pix <<< wireless access-point <<< pc

metier

 

[Buddha Bart]

yea I saw that, wasn't 100% sure if you could reverse it to vpn inside.

still, thats $500, ouch.

bart

 

[cmetz]

Buddha Bart, a BEFVP41 is ca. $110 and if that doesn't work try a cheap Wal-Mart PC for ca $200 and put OpenBSD or Linux on it. (smoothwall.org has a Linux distribution that includes FreeS/WAN VPN software and it tries to be more user-friendly)

 

[Rwalter63]

I personally like Cisco's LEAP technology using a radius server.

Cisco Security Implementations Q&A

 

[cmetz]

802.1x (EAP/LEAP) doesn't provide enough security.

 

[Buddha Bart]

A. A wireless client needs to be authenticated by a RADIUS server, and can only transmit EAP traffic until it is authenticated. After end-user login, mutual authentication between the client and the RADIUS server occurs. A dynamic WEP key is derived during this mutual authentication at the client and the RADIUS server. The RADIUS server sends the dynamic WEP key to the access point via a secure channel. After the access point receives the key, regular network traffic forwarding is enabled at the access point for the authenticated client. The credentials used for authentication, such as a logon password, are never transmitted over the wireless medium without encryption. Upon client logoff, the client association entry in the access point returns to the non-authenticated mode.

cmetz: what about this "doesn't provide enough security"?

So now the question is, which is gonna be less of a pain in the ass to setup, freeswan or a radius server.

 

[n0cmonkey]

Originally posted by: Buddha Bart

So now the question is, which is gonna be less of a pain in the ass to setup, freeswan or a radius server.

Setup both. FreeS/WAN is open source, and there are open source implimentations of Raduis out there.

Personally, I'm thinking of (when I next upgrade) setting up OpenBSD's authpf for authentication and firewalling, and IPSEC for encryption. If I wanted to get slick I would setup LDAP or kerberos authentication to use with AuthPF (RSA keys are probably too expensive for a home network ).

 

[cmetz]

RADIUS is a login authentication solution. EAP is 802.1x's way of discovering and communicating that login information and doing the exchange. So you "log in" to the network and start moving traffic.
Guess what?
EAP doesn't provide any security at all for data traffic. None.
Typically, vendors will do something like set up a MAC filter to allow the MAC addresses who did EAP exchanges to get through. All you need to do in order to defeat this "security" is spoof a MAC address, which isn't rocket science.
It's possible to have per-packet authentication using a key somehow created by the EAP process, but nobody I know of does it, and if you did... you've gone a long way towards reinventing what IPsec already does (just at an Ethernet level).

IPsec is not that hard to set up, really. Do a quick web search and you'll find how-tos for OpenBSD and for Linux FreeS/WAN to connect to Win2K/XP clients (I'm assuming that's what your clients use). They'll walk you through it step by step.