Re: guest A from virbr0 can talk to guest B in virbr1 but not vice versa

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 20, 2017 at 10:05:19AM +0200, Martin Kletzander wrote:
On Tue, Jun 20, 2017 at 02:26:59AM -0400, Travis S. Johnson wrote:
Hello,

I came across an interesting problem in my home lab a few weeks ago as I'm
prepping for my RHCE exam using Michael Jang study guide. I've been at this
for days now, and I still can't wrap my head around how two or more virtual
networks in default NAT configuration are even allowed to communicate with
each other despite what the libvirt documentation said.


Here's the excerpt I'm referring to in the wiki link here:
http://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections:

By default, guests that are connected via a virtual network with <forward
mode='nat'/> can make any outgoing network connection they like. Incoming
connections are allowed from the host, and from other guests connected to
the same libvirt network, but all other incoming connections are blocked by
iptables rules.


I did not read this properly...


Also here's another assertion from 'The virtual network driver' section in
http://libvirt.org/firewall.html:

type=nat

Allow inbound related to an established connection. Allow outbound, but
only from our expected subnet. Allow traffic between guests. Deny all other

I would expect the 'traffic between guests' to mean only guests on the
same network.  Also that lines up with what's written above.

inbound. Deny all other outbound.


[...]


Thanks for reporting this.  It's clearly a bug in libvirt.  The rules
are in this order:

 all rules for virbr0
 all rules for virbr1
 all rules for virbr2

But what we should do instead is:

 input rules for all networks
 local rules for all networks
 output rules for all networks
 reject rules for all networks

The problem is that we do not know how other rules look like.  So what
we might need to do is create chains where rules for the first network
are, then only append network rules into those chains.

Would you mind filing a bug for this issue, so we can properly track it
and don't forget about it?  I'll have a look at it in the meantime, but
don't promise anything since I'm not that familiar with that part of the
codebase.


Actually, now that I'm thinking about it, the problem is not that we
disallow the communication from virbr1 to virbr0, but the problem is
that we allow the connection from virbr0 to everywhere.

Maybe the solution would be: for each network, insert the rules on top
of the forward chain and for each started network, explicitly reject
that one.  So that after one network starts it would look like this (I'm
writing this from memory just to illustrate the idea, not actually
looking up how stuff looks):

 ACCEPT any virbr0 RELATED,ESTABLISHED
 ACCEPT virbr0 virbr0
 ACCEPT virbr0 any src:192.168.122.0/24
 REJECT any virbr0
 REJECT virbr0 any

And after second network is started, we'd have:

 # This one is new:
 REJECT virbr1 virbr0
 # These ones would be normally at the end, IIRC:
 ACCEPT any virbr1 RELATED,ESTABLISHED
 ACCEPT virbr1 virbr1
 ACCEPT virbr1 any src:192.168.122.0/24
 REJECT any virbr1
 REJECT virbr1 any
 # These are left as they were:
 ACCEPT any virbr0 RELATED,ESTABLISHED
 ACCEPT virbr0 virbr0
 ACCEPT virbr0 any src:192.168.122.0/24
 REJECT any virbr0
 REJECT virbr0 any

Cc'ing Laine so that he can weigh in as he has way more knowledge of
this part of the code =)

Thanks,

Travis Johnson

_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users



_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users

Attachment: signature.asc
Description: Digital signature

_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux