> > Maybe it is better to simplify the whole problem by taking a closer > > look at how one network is routing/bridging. I have flushed iptables > > rules and put policies on accept. No alterations to the default centos6 os. > > Simplifying the problem while learning something can be a good thing. > Build ontop of it once you have a working example. :-) > > > What I have noticed is that vms with 172.16.1.x (on either tun1 or > > tun2) can ping each other. The br0 having 172.16.1.1 can ping both > > 172.16.1.x and 172.16.1.y ips > > > > +-----------+ > > | BR0 | > > 172.16.1.y | | 172.16.1.x > > --------|ETH2 TUN1|------- > > | | > > | | 172.16.1.x > > | TUN2|------- > > | | > > +-----------+ > > > > Do you have an idea why an 172.16.1.x is not able to ping a 172.16.1.y? > > No, not off hand. > > Can 172.16.1.y ping 172.16.1.x? (Or does traffic from 172.16.1.x show up on 172.16.1.y if you sniff the traffic?) No cannot ping .x but 172.16.1.1 it can. 172.16.1.y has correct arp entry of 172.16.1.x and vice versa (but I only have there a windows vm to test with, so I hope it is not some quirk of windows) With pings from .x to .y tcpdump shows icmp requests on tun1, br0, eth2. With pings from .y to .x tcpdump does not even show icmp requests on eth2. > > I assume that if this is solved, I should be able to add the 2nd > > network in the same way and protect the bridge against the loop with ebtables. > > Very likely. > > > I used these ebtables rules, should these be ok or are these to > > restrictive? > > > > ebtables -A FORWARD -i eth2 -o eth1 -j DROP ebtables -A FORWARD -i > > eth1 -o eth2 -j DROP > > I'm guessing that eth1 is where the 10.11.12.0/24 network is connected. > > That would probably work to prevent the routing loop between eth1 and eht2. > > I would be more likely to block everything by default and explicitly allow the desired traffic. > > ebtables -A FORWARD -o eth1 --ip-source 10.11.12.0/24 -j ACCEPT ebtables -A FORWARD -o eth2 --ip-source 172.16.1.0/24 -j ACCEPT > > Though that might have some complications around DHCP and other protocols (IPv6). What you're doing likely addresses that at in a simpler method. -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
