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.
Thanks,
Rolf
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: 10.0.0.1 route add default gw 10.0.0.29
|
netLocal: 10.0.0.0/24
|
LAN: 10.0.0.29 add route for 10.1.0.0/24 via 10.2.0.6
m0n0local
WAN: 5.5.5.2 10.2.0.1 10.2.0.5
| v v tun0
| |house- |
X crossover Ethernet cable |keeping |IP-over-IP (UDP)
| | |
| ^ ^ tun1
WAN: 5.5.5.3 10.2.0.2 10.2.0.6
m0n0remote
LAN: 10.1.0.129 add route for 10.0.0.0/24 via 10.2.0.5
|
netRemote: 10.1.0.0/24
|
hostRemote: 10.1.0.130 route add default gw 10.1.0.129
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 10.2.0.6 and server uses 10.2.0.5.
b) from m0n0local, pings to 10.2.0.6 are OK;
c) but from m0n0remote, pings to 10.2.0.5 are not OK, however pings to
10.2.0.1 are OK provided that I change the route on m0n0remote for
10.0.0.0/24 from 10.2.0.5 (correct) to 10.2.0.1 (incorrect) ?!
As long as thsis route is via 10.2.0.5, the message log on m0n0remote
reads out as
...
Nov 7 21:05:29 m0n0remote /kernel: arplookup 10.2.0.5 failed: could not
allocate llinfo
Nov 7 21:05:29 m0n0remote /kernel: arpresolve: can't allocate llinfo
for 10.2.0.5rt
Nov 7 21:05:34 m0n0remote /kernel: arplookup 10.2.0.5 failed: could not
allocate llinfo
Nov 7 21:05:34 m0n0remote /kernel: arpresolve: can't allocate llinfo
for 10.2.0.5rt
Nov 7 21:05:44 m0n0remote /kernel: arplookup 10.2.0.5 failed: could not
allocate llinfo
Nov 7 21:05:44 m0n0remote /kernel: arpresolve: can't allocate llinfo
for 10.2.0.5rt
....
d) I did not get any traffic flowing from 10.0.0./24 to 10.1.0.0/24, nor
vice-versa. Despite having configured static routes on m0n0walls and
hosts as shown in figure;
e) observe frequent DNS lookups originating from 10.2.0.6 directed to
the configured DNS server 10.0.0.1/53/udp. What is m0n0remote trying to
achieve?
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
--persist-key?
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 | 