[ previous ] [ next ] [ threads ]
 
 From:  "Peter Curran" <peter at closeconsultants dot com>
 To:  <m0n0wall at lists dot m0n0 dot ch>, "Jan Walzer" <j dot walzer at itcampus dot de>
 Subject:  Re: [m0n0wall] OpenVPN ...
 Date:  Mon, 26 Jul 2004 20:08:39 -0400
Jan

Thanks  for your feedback.

> OK, after some fiddling, and setting up FreeBSD in a VMware, to build
> customized ISOs, I managed to get a version of
1.1b15+OpenVPN(m0n0-ovpn0.3)
>
> Booting went fine, and after reading, how to create a CA and own certs,
> I managed that m0n0-ovpn and another Client can authorize themselfes...
>

Thats good (I use the test certs that come with OpenVPN to avoid the messing
around here).  The next version will allow you to generate the certs inside
the WebGUI for both client and server.


> Nevertheless, there are some buggies, that still stop me from getting
> it successful working. Mostly because of the integration (or the lack of)
> into the webinterface and a missing shell (yes, I know exec.php)
>
> Major problem is, that I can't assign any rules to the tun/tap interfaces,
> as they don't appear as a valid option in the rules-form
> So, there won't get any traffic through the tunnel, as these packets will
> get dropped. Another thing with this is, that I can't do bridging of the
> tap0 and LAN.
>

This is a problem I have been working on for a week or so now.  It does
actually work, but only in some scenarios.  I think that I will have to do
some 'behind the scenes' magic to configure the interface as OPTn so that it
is properly visible to the webGUI.

The tap0/LAN bridge is a slightly different problem, but I hope the same
solution.  If you create a tunnel using tap0 and then try to define this via
Interface Assignment it seems to work, however when you bridge it falls
over.  The problem lies in the reinitialisation of the interface that
happens when you assign it,  I think I have fixed this without having to
change m0n0 (the best solution).

> Also the OpenVPN-Dialog itself has some minor issues. After having set
> some of the options (--push-ping-exit, push-route-delay come to mind)
> I can't unset them again, without editing the config.xml directly. (maybe
> some typos in the php?)
>

Sorry - there are a bunch of dumb typos in there that I have now fixed.

> Also, while using tun it appeared to me multiple times, that the "old"
> ptp device wasn't destroyed after reconfiguring the server, so the "new"
> config came up with wrong values (different IP) or didn't came up at
> all (when changing from tun to tap, it couldn't assign the IP, because
> the IP was already given to tun0, and the service died)
>

Yes this happens - thats why we need testing :-)  I just need to tweak the
script to destroy the old state before creating a new one.  I really wanted
to keep the feature where OpenVPN just picks the first unused tun/tap so
that it would not interfere with anybody else using tun/tap anywhere else.
This means that every time you recreate the interface settings it skips over
the existing and you get an IP conflict.

The next version enforces a reboot if you change the tunnel type (this
prevents the problem you experienced).

> Another thing I'm unsure about, is the usage of the lzo-comp option.
> Is the binary compiled with this option?
>
The binary does not have lzo-comp.  I was bothered about space (or lack of
it) and decided to do without this feature as it makes OpenVPN a few bytes
bigger but requires a further shared library.  In fact, Manuel increased the
size of the 1.1 mfsroot image so that there is now plenty of room and the
next version will have the feature in.

I hope to have the new version this weekend - this will have proper support
for tap in it, plus a tutorial on using a tap-based virtual-lan over a wifi
network.

Thanks for your time in providing feedback - please do let me know how the
new stuff works.

Regards,
Peter



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.