[ 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:  Re: [m0n0wall] OpenVPN m0n0 server - m0n0 client
 Date:  Mon, 08 Nov 2004 13:38:18 +0100
Got layer-2 bridging over an OpenVPN SSL/TLS tunnel almost working, 
after getting inspired by the posting
  From:   	Guy Brand <gb at isis dot u dash strasbg dot fr>
  Subject:  	Re: [m0n0wall] A strange Problem ( Bridgeing needed? )
  Date:  	Sun, 22 Aug 2004 16:30:23 +0200

1. Test setup:

LAN:  no static routes added
  |                                v          v tap0
  |                                |house-    |
  X crossover Ethernet cable       |keeping   |bridge via (UDP) tunnel
  |                                |          |
  |                                ^          ^ tap1
LAN:   no static routes added

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 " ").

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>

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?

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 icmp_seq=4853 ttl=64 time=1.76 ms
64 bytes from icmp_seq=4854 ttl=64 time=1.73 ms
64 bytes from icmp_seq=4855 ttl=64 time=1.68 ms

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 
Act  	Time  	If  	Source  	Destination  	Proto
x  13:16:52.383115 OVPN server 	ICMP
x  13:16:51.383314 OVPN server 	ICMP
x  13:16:50.382507 OVPN server 	ICMP
x  13:16:49.382805 OVPN server 	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 

One potential lead could be the posting
  From:   	Kolia <nika at hotmail dot ge>
  Subject:  	Re: [m0n0wall-dev] Transparent bridge
  Date:  	Thu, 15 Jul 2004 17:00:53+0400

Also, why is the OpenVPN client generating a tun/tap1 device, and not 

Thanks for any feedback & ideas,