|
|
Marco Fretz schrieb: > hello > > i think this may has something to do with the "client-to-client" > option from openvpn. I don´t think so, because client-to-client only affects only the internal routing of one openvpn process > but im not sure cause u are running 2 openvpn servers. did u verify > that the firewall is not blocking traffic over br0? As far as I can br0 is not blocked. The ARP request and response goes from client 1 to 2 and return without any problem. Is the traffic from tap0 to tap1 filtered by iptables? The routing process is affected only when the traffic leaves br0. regards, Michael > > regards > marco > > > Michael Jürgens schrieb: >> Hi, >> >> is it possible to bridge two tap interfaces? >> >> I´ve tried the following: >> >> Server: >> - br0 bridges tap0 and tap1 >> >> >>> brctl show br0 >>> >> bridge name bridge id STP enabled interfaces >> br0 8000.965a950332fc no tap1 >> tap0 >> >> >>> ifconfig (eth0 and lo0 removed) >>> >> br0 Link encap:Ethernet HWaddr 96:5A:95:03:32:FC >> inet addr:192.168.210.1 Bcast:192.168.210.255 Mask:255.255.255.0 >> inet6 addr: fe80::c496:faff:fe5b:232/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:31825 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:31413 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:2620884 (2.4 MiB) TX bytes:3025770 (2.8 MiB) >> >> tap0 Link encap:Ethernet HWaddr C6:96:FA:5B:02:32 >> inet6 addr: fe80::c496:faff:fe5b:232/64 Scope:Link >> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 >> RX packets:33208 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:21452 errors:0 dropped:8 overruns:0 carrier:0 >> collisions:0 txqueuelen:100 >> RX bytes:3220056 (3.0 MiB) TX bytes:2067128 (1.9 MiB) >> >> tap1 Link encap:Ethernet HWaddr 96:5A:95:03:32:FC >> inet6 addr: fe80::945a:95ff:fe03:32fc/64 Scope:Link >> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 >> RX packets:9991 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:9981 errors:0 dropped:19 overruns:0 carrier:0 >> collisions:0 txqueuelen:100 >> RX bytes:960302 (937.7 KiB) TX bytes:959266 (936.7 KiB) >> >> >> Clients: >> client1 connects to tap0 and client2 connects to tap1 >> >> Client1 gets ip 192.168.210.100 >> Client2 gets ip 192.168.210.90 >> >> ping from client 1 to 192.168.210.1 is ok >> ping from client 2 to 192.168.210.1 is ok >> >> ping from client 1 to 192.168.210.90 (client 2) is not ok >> >> >> >>> brctl showmacs br0 >>> >> port no mac addr is local? ageing timer >> 1 74:61:70:bc:53:00 no 0.77 >> 2 96:5a:95:03:32:fc yes 0.00 >> 1 c6:96:fa:5b:02:32 yes 0.00 >> 2 de:7e:7d:ca:ff:ac no 183.74 >> >> >> tcpdump sees ping requests on tap0 and br0 but not on tap1 >> >> The arp table on client 1 knows mac address from client 2, so broadcasts >> The arp request from client 1 about client 2 can be seen by tcpdum on >> tap1, so broadcasts will be forwarded. >> >> >> >> Why br0 will not forward the packets from client1 to client2 ? >> >> Any help? >> regards, >> >> Michael >> >> >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Openvpn-users mailing list >> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx >> https://lists.sourceforge.net/lists/listinfo/openvpn-users >> > ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |