[ previous ] [ next ] [ threads ]
 From:  Peter Curran <lists at closeconsultants dot com>
 To:  Rolf Sommerhalder <rolf dot sommerhalder at alumni dot ethz dot ch>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] OpenVPN m0n0 server - m0n0 client
 Date:  Mon, 8 Nov 2004 15:59:07 +0000

> 1. My test setup:
> hostLocal:   route add default gw
> netLocal:
> LAN:  add route for via
> m0n0local
> WAN:        
>   |                                v          v tun0
>   |
>   |                                |house-    |
>   X crossover Ethernet cable       |keeping   |IP-over-IP (UDP)
>   |                                ^          ^ tun1
> WAN:        
> m0n0remote
> LAN:  add route for via
> netRemote:
> hostRemote:   route add default gw
> 2. Configuration
> a) see details in config.xml files attached in Appendix A.
> b) uses test certificates from OpenVPN distribution;
> c) in menu OpenVPN-server-Client push options activated only Ping with
> 10 s, and Ping-restart with 60 s. Left all other options selected. This
> corresponds to the "-keepalive 10 60" macro option in OpenVPN to make
> sure that the OpenVPN server and client tasks don't die;

We do not currently use the macro, but the expansion of it.

> d) firewall rules for interfaces LAN, WAN and OpenVPN completely opened up;
> e) added static routes to m0n0local and m0n0remote on the OpenVPN/tunX:
> interfaces as indicated in the figure above;

Not sure why you did this.  On the server side the OpenVPN software does this 
itself when configured with the --server macro (which we use).

On the client side it is best to select the appropriate push option and let 
the client add the route when the tunnel comes up.

> 3. Findings
> a) SSL tunnel establishes successfully, client gets assigned end point
> address and server uses
> b) from m0n0local, pings to are OK;
> c) but from m0n0remote, pings to are not OK, however pings to
> are OK provided that I change the route on m0n0remote for
> from (correct) to (incorrect) ?!

Dunno what this is caused by, but it sounds like you are confusing the system 
a little by setting the routes manually.  It is possible the some later 
process is changing the routes back again, so I will check this.  There are 
some related problems that are caused by execution order, so it may be a side 
effect of this.

> As long as thsis route is via, the message log on m0n0remote
> reads out as
> ...
> Nov  7 21:05:29 m0n0remote /kernel: arplookup failed: could not
> allocate llinfo
> Nov  7 21:05:29 m0n0remote /kernel: arpresolve: can't allocate llinfo
> for
> Nov  7 21:05:34 m0n0remote /kernel: arplookup failed: could not
> allocate llinfo
> Nov  7 21:05:34 m0n0remote /kernel: arpresolve: can't allocate llinfo
> for
> Nov  7 21:05:44 m0n0remote /kernel: arplookup failed: could not
> allocate llinfo
> Nov  7 21:05:44 m0n0remote /kernel: arpresolve: can't allocate llinfo
> for
> ...

Well that confuses me!!!  You are using a tun tunnel aren't you?  There should 
not be any use of ARP as it is a point-to-point interface.  I have seen this 
sort of error before, but not related to OpenVPN.

> d) I did not get any traffic flowing from 10.0.0./24 to, nor
> vice-versa. Despite having configured static routes on m0n0walls and
> hosts as shown in figure;
> e) observe frequent DNS lookups originating from directed to
> the configured DNS server What is m0n0remote trying to
> achieve?

Beats me.  I will try and reproduce your setup and see what happens.

> f) in menue OpenVPN-server-"Client push options" options Ping-exit and
> Ping-restart: only one or the other should be selectable, because they
> are  mutually exclusive according to OpenVPN man page;

Yes - this needs a bit of javascript to disable the opposite option once one 
has been selected.

> g) further, also under OpenVPN-server-"Client push options", it is
> impossible to deactivate the Ping, Ping-exit and Ping-restart options
> once they have been selected and saved. The only way to deactivate them
> again was back, edit the config.xml, and restore.

Oops.  This is a silly bug :-(  I changed the way the option where parsed to 
simplify the script and forgot to include the special handling for these 

> h) Added bottom blocking firewall rules with logging active to make sure
> we catch in the log all cases where a rule would be too restrictive. It
> seems that the menu option Diagnostics - System logs - Settings - "Log
> packets blocked by the default rule" does not really catch everything.
> i) both server and client OpenVPN tasks drop priviledges to user
> "nobody". Question: would it be overly defensive to set options such as
>   --persist-key?

I will look at this.

> k) on the client's menu Firewall - Rules the OpenVPN interface OVPN
> appears as blank field (" interface"), instead of someting like "OVPN
> client interface". The same blank field " " can be observed in the menu
> tabs of Services - DHCP server, and Services - DHCP relay, just adjacent
> to the right of the tab "LAN" (this blank tab is clickable);

Did you provide some information for this field when you configured the 

> l) the command line options produced on the fly for both the OpenVPN
> server and client sides look reasonable. Still have yet to analyse in
> more detail the routing tables, ipfw and ipnat (see Appendix B).
> 4. Wishlist
> a) configuration options to put selected interfaces into a group of
> bridged interface (brctl), e.g. support of Ethernet briding in addition

This is already there (and working on the server side at least).

> to IP routing through SSL (& IPSec) VPN tunnels;
> b) support of --server-bridge, at the place of --server, when including
> a OVPN interface into a group of bridged interfaces;

This may not be the best way of doing this - this is a macro and simply 
assignes a subset of the address space for assignment to clients.  The thing 
works without this option and there may be a more elegant way of interfacing 
with the existing bridge logic elesewhere in m0n0.

> c) a clickable menu for /status.php under Diagnostics;
> d) Diagnostics menu always expanded, or "pinable";

I thought it was in 1.2beta?


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