|
||||||||
Rolf > > 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; 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 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) ?! 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 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 > ... 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 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? 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 options. > 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 client? > 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? Peter -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |