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