On 07/31/2013 11:01 AM, Jorge Fábregas wrote: > That is, the first network can reach all other networks (just because it > happens to be the first one defined). Is this the intention (only > default can talk to the others but not the other way around)? *Bump* I found this excellent post by Daniel Berrange: http://www.redhat.com/archives/libvir-list/2010-June/msg00762.html ...which explains all the firewall rules that libvirt creates based on the type of network you choose. Reading this I get the idea that, the intention for NAT virtual-networks, is to allow them to communicate with ANY other virtual-network on your system (since there's an allow rule for traffic coming out of it). In a nutshell, the problem is that there's a lack of consistency on how NAT virtual-networks communicate between each other. I think the traffic between these subnets should be either allowed or denied. Right now we have a mixed scenario where the decision to allow or deny the traffic is merely based on what position, of the firewall rules, your virtual-network happens to be. Here's what I mean: http://fpaste.org/30485/ Network 0 can reach any network due to line #3 Network 1 can only reach the networks defined below it (due to line #10) Network 1 can't reach Network 0 due to line #5 Network 2 can't reach any of the above networks due to #line 5 & 12 (reach = "initiate new connections") Summary: (Based on the order of firewall rules): virtual-networks can successfully initiate new connections to the networks defined below it but can't with networks defined above it.

Comments are welcome. Thanks! Jorge _______________________________________________ libvirt-users mailing list libvirt-users(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users

On 08/13/2013 06:31 AM, Laine Stump wrote: > Correct. That is a known problem since 2008: > > https://bugzilla.redhat.com/show_bug.cgi?id=453580 Thanks Laine for confirming it is a known issue. I googled it a lot but couldn't find that bugzilla entry. Do you know if this is still the case with the upcoming Fedora 20 & firewalld? (these rules are still being created)?

> Due to the large amount of work required to fix it relative to the > apparent demand for a fix, it has remained unchanged. I'm wondering if it really takes a lot of work. I think that by just changing the order of the rules everything gets fixed. If we group the rules *by functionality* instead of *by virtual-network* we can accomplish a particular goal (drop communication between virtual-networks or allow them):

(Notice that I did not insert or delete any rule; just changed the order): - Allow communication between virtual-networks (regardless of direction): http://fpaste.org/31729/ - Block communication between virtual-networks (except for the LAN): http://fpaste.org/31731/ > Note that if you want to have multiple virtual networks that can > communicate with each other, you can define all the networks as <forward > mode='route'/> (which gives them iptables rulesets that allow all access > in both directions), then add in appropriate "blanket" NAT rules > yourself in the host's iptables config. Right, that's what I'm using now: just had to add a static route to my home router in order for them to be able to use the net.