RE: gretap tunnel redirecting 2 different networks on destination host to nics

> > 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.