HI,
after successfully flashing and configuring openwrt on my WRT54GL to work as routed client for an outdoor Alvarion DS11 access point, I'm having a look on the ways to secure the wireless network. At now, the access point I'm using doesn't support WPA/802.1x and my company have some customers asking about an extra security more than wep.

What do you suggest me to use ?
At the moment I would prefer more performance than more security.

I'm doing some tests with openvpn, it works, but I haven't already done perfomance tests.

What kind of VPN shall I try to secure my network ?

Actually I think openvpn should be the one with the best encryption/lightweight ratio ... Is that right ?

Any suggestion will be useful

Thanks.

OpenVPN has pretty good performance. They use UDP for the underlying transport.

Quite a few more primitive protocols use TCP. Having TCP layered onto TCP has penalties.

I recommend using 2,048 or 4,096-bit keys. It takes a bit longer for the initial connection, but for the session itself a different key is used anyway so the only place you notice it is during initial key exchange. Since my client locations all automatically connect to the server on boot, a few extra seconds then is not a big issue.

Use easy-rsa or tinyca to generate certificates with. Once you get it going, from then on it's as simple as:
./build-key client30
to build certificates for a new client

I've had IPSEC tunnels working between a pair of OpenWRT boxes with OpenS/WAN [*]. Again, haven't had a chance to test the performance. You might want to choose it because your customers may feel more comfortable hearing "IPSEC" rather than "proprietary VPN solution" which is what OpenVPN or TINC would give you.

If you have a lot of customer-to-customer direct traffic, TINC has the advantage that it can automatically set up a full mesh, without having to manually configure n^2 tunnels. But then again, the traffic is going to have to traverse the air twice at layer 2 anyway, to go cust1->AP->cust2.

Make sure you choose a solution which lets you use AES or Blowfish rather than 3DES as the session cipher - it will run a lot faster.

Regards,

Brian.

[*] Having learned the KAME / ipsec-tools implementation on both Linux and FreeBSD, I was disappointed to find that it only exists in 2.6 Linux kernels - and since OpenWRT uses 2.4, I had to learn a completely new set of IPSEC tools and configuration files. Ugh.

I love the idea of IPSec.

OTOH it's taken 10 years, and STILL not quite finished.  If you are just using it for internal purposes like CPE to your gateway to protect traffic, then keep it simple.  If the customer will never interact directly with the VPN pipe other than pushing bits over it, use whatever works.

There is also *gack*.... PPTP.

(Last edited by vincentfox on 16 Feb 2006, 22:02)

Yeah, but he said he wanted "extra security" - PPP encryption is pretty insecure.

Yeah, well if you are going to toss around language about IPSec being a recognized standard, so is PPTP.

While MS track record with it stinks generally, if used with EAP-TLS I'm told it offers good security. Most of the times it's deployed in a "Windows for Dummies" fashion using CHAP and is not very good. I think this probably has a lot more to do with the Windows-jockies who deploy it than the protocol per-se.

It's kind like if you took OpenVPN or IPSec and set it to it's simplest shared-secret mode, and used the shared key "secret". A surprising number of installs are about that bad.

(Last edited by vincentfox on 16 Feb 2006, 23:22)

OpenVPN can use either UDP or TCP.

I've done some performance testing with OpenVPN running on a WRT54GS, and found that the WRT's CPU limited the throughput of the VPN to around 300kbytes/sec, compared to ~600kbytes/sec for a non-VPNed 802.11b wireless link.

Cheers,
Martin.

Well. thanks for every aswer.
My situation is that we have an existing infrastructure made with alvarion AP and clients and using zyxel firewall for VPN. This network is now used by public administration only, but we're up to resell internet access to private citizens and companies through that network.

The idea is to use WRT54GL as client, with a Linux firewall conneted to a shared HDSL for internet access.
VPN will be from WRTs to the linux firewall. I have already ipsec (openswan) installed on the linux firewall so I woild preffer that ...
I exclude pptp because is not too different from wep , as security level I mean.
However if openvpn is more lightweight I give it a try.

Thanks.

Debian ships two patches to backport 2.6 IPSec to 2.4 kernels. I opened ticket https://dev.openwrt.org/ticket/311 some days ago to support this combination in OpenWRT, as well. As an addon, i expect the ipsec-tools stuff to have lower flash usage than OpenS/WAN.

I didn't say it wasn't a standard - I said it was insecure. But don't take my word for it. RFC3193 says of L2TP (which is closely related to PPTP):

It goes on to propose L2TP running over IPSEC transport mode, which is also implemented in Windows clients (2K and XP at least, I think there are downloads for older versions). But this is more suited to 'road warriors' on dynamic IP addresses. If you're building a security gateway to protect a fixed subnet, it's probably simpler to use IPSEC native tunnel mode than to use L2TP over IPSEC transport mode.

For now I have done just tests with openvpn and I have a troughut of about 400 kbit sec dowloading a file on the WLAN.
Removing the tunnel I go at about 430/450 , it doesnt change too much. I don't know if I've done something wrong (tcpdump says me that packets were router through tun0 so I think the tunnel is working).
While dowloading openvpn process on the wrt was at about 95% cpu.

Well, I don't know what my customer would like to do, but when I deal with end users I'm always thinking the worst.

Would be dangerous for the wrt working often at about 100% cpu ?
Does ipsec takes less cpu ?

I haven't any experience of ipsec on "low cpu" devices, always used x86 machiens with more than 600 mhz cpu or dedicated firewalls.

The high CPU usage indicates the traffic is going through the VPN, as OpenVPN needs to handle the encryption and decryption.

However, I'd expect higher speeds without the VPN, as 430/450 is pretty low.  802.11b is capable of ~600kbytes/sec, with 802.11g being capable of faster speeds.

However, your speeds may be limited to ~450kbytes/sec due to distance / signal strength.

Cheers,
Martin.

This depends very much on the symmetric encryption algorithm used. Look into your OpenVPN configuration and see what it uses. 3DES is slow; Blowfish was specially designed for running on 32-bit microprocessors and so should be fast. AES is supposed to be pretty efficient too. I'd expect IPSEC using the same algorithm to have similar performance, although it will depend on the actual implementations.

If you do IPSEC using Openswan, the packet processing takes places in the kernel, which means it doesn't have to go through a tun device into a userland process. I suspect this overhead is small compared to the actual encryption though.

I believe Blowfish is the default unless you specify otherwise, but check the config. It would be interesting to see a benchmark of Blowfish versus AES.

I guess it all depends on is that fast enough for you.

Many people are willing to make the trade. It may be a little hard on the CPE end, but my OpenVPN server is a PIII-850 and the load is negligible there.
There's also the option of installing the OpenVPN client directly on the end-user PC and leaving the WRT alone.

Personally I'd really like to try out one of these new Nano-ITX boards, the lower-clocked versions. Via is supposed to have one hell of an
integrated encryption engine on their CPU. The review I saw at mini-itx.com had it showing encryption speeds much higher than
P-IV CPU with much higher clock speeds. Maybe overkill for CPE, but would be a neat little router at a micro-PoP.

(Last edited by vincentfox on 17 Feb 2006, 18:36)

PPTP also takes a great deal of CPU - the max throughput I've found is about 300K per second out, although that can get about 50-100KB per second better when transfering large files.  In, the service seems to run better for some reason, and you get perhaps double or triple the throughput.

Even though the CPU hangs at about 90 percent, the rest of the clients connected to the VPN network/internet through the router don't see any noticable reduction in speed of resolution of dns sites or transfer rates outside the PPTP connection (IE locally or over the traditional WAN link).  It's actually quite solid.

PPTP got a bad name because of an early flaw that was quickly corrected way back when it was released.  If you're half paying attention to other security, you shouldn't have a problem using PPTP for encryption.

Jim

Any experience using vpn only with validation?

The primary reason that I don't want encryption is to save cpu-power, but would it be possible?