[ previous ] [ next ] [ threads ]
 From:  Jim Gifford <jim at giffords dot net>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Statement regarding m0n0wall features
 Date:  Tue, 27 Jan 2004 14:50:17 -0500
On Tue, Jan 27, 2004 at 01:23:18PM -0500, Dany Nativel wrote:
> Manuel,
> I think the "to do / Wishlist" on your website clearly shows the path.
> Bring us OpenVPN and certificates for IPSec and we'll be all set.
> I've tried e-smith, smoothwall and lately IPcop on an old PC. I got 
> tired about noise, size and power consumption. I'm about to receive a 
> 4501 for  monowall and will be using a mini-itx 533MHz board in an 
> ultra-small case for the file server (and maybe IPsec for WLAN if the 
> 4501 is too slow).
> Thank you for this amazing 5MB product.
> Cheers
> Dany

I think I might've been the first one to mention OpenVPN on this list.
I've been using it for about 6 months now, and I have mixed feelings
about it.  I also have been investigating how adding it to m0n0wall might

On FreeBSD 4.8-STABLE the openvpn binary itself is 168624 bytes stripped.
Not a terrible impact on the size of m0n0wall.

Creating configuration files wouldn't be difficult.  The config files are
rather easy to programmatically manage.

It probably wouldn't be that difficult to modify the ip filters to permit
the inbound traffic.

All in all, I think it could be done.  But should it be done?

openvpn runs in userspace, and as such is a nontrivial addition of cpu
usage.  You've got your network traffic being copied back and forth
between kernel space and user space, that's a lot of context switches.

Additionally, the product itself isn't the most stable thing in the
world.  It does recover from network hiccups most of the time.  However,
I've seen many situations where it will just wedge and need to be

Every VPN endpoint requires a separate running binary.  16 tunnels is 16
userspace apps dealing with network traffic.

Considering the target of a net4501, I really don't think openvpn is a
practical product for m0n0wall.

With all that said, both ends of an openvpn tunnel can be behind a
NAT/Firewall device, and still talk to each other.  As a means of doing a
simple connection between two hosts, it does ok.

Also, the existing IPSEC and PPTP support in m0n0wall I think addresses
the two areas where OpenVPN seems targeted.

As Dick said, it's not a standard protocol, and as such only
interoperates with itself.  Granted, it's been ported to most major OSes
which is a major accomplishment in and of itself.

For myself, I've decided that implementing OpenVPN support in m0n0wall
isn't worth the time or effort, so I haven't followed through on it.  If
it were done by someone else, I doubt I would use it.

I think it's a good idea that people are thinking about what features
they would like to see in m0n0wall.