[ previous ] [ next ] [ threads ]
 From:  Rolf Sommerhalder <rolf dot sommerhalder at alumni dot ethz dot ch>
 To:  m0n0wall at lists dot m0n0 dot ch
 Cc:  lists at closeconsultants dot com
 Subject:  OpenVPN m0n0 server - m0n0 client
 Date:  Sun, 07 Nov 2004 22:17:28 +0100
Part of this rainy Sunday I spent on replacing an IPSec VPN tunnel 
between two m0n0walls by an OpenVPN SSL/TLS tunnel. I was not fully 
successful yet. Which is not surprising because, according to previous 
posts, there are some open issues with OpenVPN clients on m0n0 v1.2b2.

Below is a summary of how far as I got, with some observations. The 
objective is to be able to bridge at Layer-2 (Ethernet frames via TAP 
and BRidge devices)  the local and remote LAN over an OpenVPN tunnel, 
and not only to IP route via TUN devices.

I can try to do additional tests if this helps developers and other 
testers. Also, I can make available the two config.xml files upon request.


P.S. I had to cut the Appendices with the details because the mail list 
reflector accepts messages only upto 30000 bytes. I propose to forward 
the full message bilaterally on request.

1. My test setup:

hostLocal:   route add default gw
LAN:  add route for via
  |                                v          v tun0
  |                                |house-    |
  X crossover Ethernet cable       |keeping   |IP-over-IP (UDP)
  |                                |          |
  |                                ^          ^ tun1
LAN:  add route for via
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;
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;

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) ?!
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 
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 
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 
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 
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;
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.
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 
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);
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 
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;
c) a clickable menu for /status.php under Diagnostics;
d) Diagnostics menu always expanded, or "pinable";


A. config.xml Files of the Test Setup

A1) m0n0local


A2) m0n0remote


B) Output of /status.php

B1) m0n0local


B2) m0n0remote