[ previous ] [ next ] [ threads ]
 
 From:  Ole Barnkob Kaas <obk at tet dot dk>
 To:  Peter Allgeyer <allgeyer at web dot de>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] $1000 prize for fully working OpenVPN on m0n0wall CANCELLED
 Date:  Wed, 04 Oct 2006 18:28:21 +0200
Peter Allgeyer wrote:
> Hi Ole!

Hi Peter,
> 
> Am Dienstag, den 03.10.2006, 13:55 +0200 schrieb Ole Barnkob Kaas:
>> We are currently using m0n0wall to glue together our voip network with 
>> OpenVPN tunnels. We are using th net4801 platform with the 
>> net48xx-1.2-ovpn2.img image made available by Peter Allgeyer. We are 
>> using that specific image because later images seems to mess up PPTP 
>> when enabling OpenVPN.
> Sorry, can you be more specific on that? In what way do they mess up
> PPTP?
> 

I'm unable to connect to the pptp server after configuring an OpenVPN 
client connection. I suspect that it something to do with the network 
interfaces.

>>  I've described the problems with OpenVPN earlier. 
> I'll search for it.
> 
>> 1. The OpenVPN proces causes a kernel panic on the m0n0wall if and only 
>> if the sip proxy for some reason is unavailable.
> SIP proxy? Are you sure that OpenVPN is the cause? OpenVPN fully runs in
> user space. It IMHO can't bring down the kernel. Isn't it the
> tun-driver?
>

The fault page displays the openvpn process as the offending one. But 
then again it could be the tun interface that causes openvpn to die with 
a page fault. BTW the later images crashes too.


>> 2. Packets that should go through the tunnel are sent to WAN if the 
>> tunnel comes up after the first packet have been sent. Flushing the 
>> statetables "solves" this. Advanced outbound nat is enabled.
> Try that with the latest images from my website. If the failure resists,
> provide me with the error log and an output of status.php.
> 
>> 3. From a fresh boot where the tunnel comes up it is not possible to 
>> access the m0n0wall from the far end af the tunnel. Logging in from a 
>> local pc and hitting "save" in advanced outbound nat "solves" this. 
>> Also, it is not possible to access local equipment from the far end of 
>> the tunnel before the local equipment have initiated a connection.
> See above. Firstly try the latest images.
> 
>> It is our hope that with a prize on this, these problems can be solved 
>> within a month - maybe two.
> I can't promise anything, because my spare time is precious little at
> the moment. Have you ever tried to run pfsense? They have adapted my
> code, but I don't know, how well.

You got spare time! ;-) I was in the process of giving this a stab 
myself - but I'm out of time.

Assumptions is the mother of all f***ups. Reading the feature page of 
pfSense I ASSUMED that it didn't support OpenVPN and wrote it off - DOH!!

I've now tried pfSense and it seems that it doesn't have any of the 
problems mentioned. I'll have to test it for a couple of weeks to see 
how it performs or if there are any other problems. Comparing pfSense 
with m0n0 (quick):

pros:
+ OpenVPN that works ;-)
+ Separate log page OpenVPN
+ DHCP client on OPTx interface
+ Automatic certificate on webgui ssl
+ Temperature monitor

cons:
- Slooow - it all comes at a price (ugh)
- OpenVPN eats more CPU power
- Requires 128MB flash

There is of course a lot of other advantages in pfSense, but they don't 
belong in m0n0.

Now that it seems that my problems with OpenVPN is solved, I have to 
cancel the prize. Sorry. I would of course love to see a working OpenVPN 
in m0n0 in the future.

Regards,

Ole Kaas