Hi, Thanks for your reply. The end-goal is to be able to selectively route some traffic down a tapX interface. Step #1 was to be able to route something without the tapX interface. My goal is similar to this: http://ebtables.sourceforge.net/examples/real.html#example3 ... but that didn't work for me. (note: I'm using OpenVPN instead of Freeswan) Since my email yesterday I have been able to broute traffic thanks to this: http://ebtables.sourceforge.net/examples/basic.html#ex_brouter However, I don't want my bridged interfaces to have addresses. I only want the bridge to have a single address which is accessible from either side of the bridge. -Peter On Thu, Jan 10, 2013 at 5:52 PM, 叶雨飞 <sunyucong@xxxxxxxxx> wrote: > maybe you can add some log in your iptables INPUT/OUTPUT/FORWARD chain > to see where the packet goes. > > But I'm confused about what you are trying to do here, is it for doing > transparent filtering? > > On Thu, Jan 10, 2013 at 11:28 AM, Peter McAlpine <peter@xxxxxxx> wrote: >> Hello, >> >> I am attempting to route bridged ipv4 traffic via ebtables & iproute2, >> but am experiencing problems. >> >> [client 10.8.7.101] ---- eth2 (no addr)[brouter (br0: 10.8.7.10)] eth3 >> (no addr)---- [gateway 10.8.7.99] >> >> I have flushed all iptables and ebtables rules. All policies are "ACCEPT". >> >> At this point, pinging 'gateway' from 'client' is successful. >> >> Then I add an ebtables rule on 'brouter' to route traffic destined to >> 'gateway' via the routing table: >> ebtables -t broute -A BROUTING -p ipv4 --ip-dst 10.8.7.99 --log-ip -j >> redirect --redirect-target DROP >> For good measure I also enable ip_forward: >> echo '1' > /proc/sys/net/ipv4/ip_forward >> >> What I expect to happen: >> 1) The packet comes in on eth2 on 'brouter' >> 2) The ebtables rule matches the traffic and sends it to the routing >> table (via the DROP target) >> 3) The packet (destined for 10.8.7.99) matches the default route and >> is sent to 'gateway' >> 4) The packet is sent out eth3 to 'gateway' >> >> What is actually happening: >> 1) The packet comes in on eth2 on 'brouter' - CONFIRMED via 'tcpdump -i eth2' >> 2) The ebtables rule matches the traffic - CONFIRMED via syslog >> message due to '--log-ip' option in ebtables rule >> 3) ... The packet vanishes. >> >> Can anyone help me figure out why this is happening? >> >> -Peter >> -- >> To unsubscribe from this list: send the line "unsubscribe netfilter" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
