[ 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:39:58 +0000
Rolf

Thanks a lot for your posts (this and the last).  I have tried to answer some 
of your questions below:

FYI I have had a limited bridging scenario working just fine for some weeks, 
using m0n0 on the server side with the tap0 interface bridged to LAN and 
Win2k clients connecting in.

> 2. Configuration
>
> a) Changed OpenVPN from tunX to tapX devices as required for briding;
>
> b) Added firewall rules for interfaces LAN & OVPN to allow "any" traffic
> from "any "to "any"; (on the OpenVPN client the OVPN interface shows
> only as blank " ").
>
Perhaps you omitted to configure the name for this interface when you 
configured the client.  When the client is defined the description you 
provide is used to populate the OPT interface entry, including the 
description field which is what you see in the firewall, routing, etc. pages.

If you do not provide a description the system should insert a default 
description like 'OVPN Client 1'.  If this is not happening then there must 
be a bug somewhere, I will test to see if I can reproduce the problem.

> c) inserted lines into config.xml to the <system> section at OpenVPN
> server (fxp0 are the LAN interfaces):
>   <shellcmd>/sbin/sysctl net.link.ether.bridge_cfg=fxp0,tap0</shellcmd>
>   <shellcmd>/sbin/sysctl net.link.ether.bridge_ipf=1</shellcmd>
>   <shellcmd>/sbin/sysctl net.link.ether.bridge=1</shellcmd>
>
Why did you not simply go into the interface definition and use the GUI to 
create the bridge between the two interfaces?

> and at OpenVPN client:
>   <shellcmd>/sbin/sysctl net.link.ether.bridge_cfg=fxp0,tap1</shellcmd>
>   <shellcmd>/sbin/sysctl net.link.ether.bridge_ipf=1</shellcmd>
>   <shellcmd>/sbin/sysctl net.link.ether.bridge=1</shellcmd>
>
> Note on the server side it's tap0 (zero), whereas on the client it's
> tap1 (one)!  Why, is this a 0/1 index programming bug when tun/tap
> devices get created on the OpenVPNclient?
>

This is not a bug.  The OVPN support was originally designed to be server-side 
only.  Quite late on the client side was added (hence the problems as it was 
not properly tested).  The server uses either tun0 or tap0, clients use tun/
tap1 upwards.  This is not a big deal and is not normally visible anyway as 
the interfaces are describled using the description field.

>
> 3. Findings
>
> a) hostLocal can ping hostRemote ok, provided that (any) firewall rule
> on m0n0remote is edited-saved after every reboot (without changing
> anything in the edited rule). This somehow chages the firewall rules,
> although I can not see any difference in ipfstat display of /status.php
> before and after this edit-save cycle.
> 64 bytes from 10.0.0.130: icmp_seq=4853 ttl=64 time=1.76 ms
> 64 bytes from 10.0.0.130: icmp_seq=4854 ttl=64 time=1.73 ms
> 64 bytes from 10.0.0.130: icmp_seq=4855 ttl=64 time=1.68 ms
>

I think this is caused by the execution order of the various components during 
startup.  I have a fix for this so it should go away shortly.

> b) Unfortunately, this is not the case for hostRemote which can not ping
>   hostLocal. I tried plenty of tricks, such as the one with edit-save of
> firewall rules, rebooting, enabling the filtered bridge option.
>
> c) Enabling the Filtering Bridge option in System - Advanced functions
> on the OpenVPN server and/or client apparently does not change anything.
>
> d) When pinging hostLocal from hostRemote, the firewall log on m0n0Local
> shows
> Act  	Time  	If  	Source  	Destination  	Proto
> x  13:16:52.383115 OVPN server 	10.0.0.130 	10.0.0.3 	ICMP
> x  13:16:51.383314 OVPN server 	10.0.0.130 	10.0.0.3 	ICMP
> x  13:16:50.382507 OVPN server 	10.0.0.130 	10.0.0.3 	ICMP
> x  13:16:49.382805 OVPN server 	10.0.0.130 	10.0.0.3 	ICMP
> despite the firewall rule OVPN any any any...
> The firewall edit-save trick does not resolve this on the server side,
> unlike on the client side.
> Observing local using tcpdump, I can see ARP Requests are coming in from
> Remote via tap0. Sniffing the remote network, I verified that the ARP
> replies get back through the tunnel ok.
>
> So it looks like the is something wrong with the (implicitely generated)
> firewall rules, with and without bridging, on the server as well as on
> the client sides. But I was unable so far to figure out what exactly is
> wrong.
>

I am working on this at the moment.  So far I have not found anything obvious 
but I can reproduce this tyoe of problem.

Peter


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