|
||||||||||
Got layer-2 bridging over an OpenVPN SSL/TLS tunnel almost working, after getting inspired by the posting http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=81&actionargs[]=23 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: hostLocal: 10.0.0.3 | netLocal: 10.0.0.0/24 | LAN: 10.0.0.29 no static routes added m0n0local WAN: 5.5.5.2 10.5.0.1 10.5.0.5:5000 | v v tap0 | |house- | X crossover Ethernet cable |keeping |bridge via (UDP) tunnel | | | | ^ ^ tap1 WAN: 5.5.5.3 10.5.0.2 10.5.0.6:5001 m0n0remote LAN: 10.0.0.129 no static routes added | netRemote: 10.0.0.0/24 | hostRemote: 10.0.0.130 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 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 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. One potential lead could be the posting http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=71&actionargs[]=54 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 tun/tap0? Thanks for any feedback & ideas, Rolf |