On 04/06/2018 10:31 AM, Marc Roos wrote:
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?)
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 ACCEPTThough that might have some complications around DHCP and other protocols (IPv6). What you're doing likely addresses that at in a simpler method.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
