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

Re: [libvirt] Proposed: always allow packets internal to an interface

On 11/05/2012 12:35 PM, Laine Stump wrote:
On 11/02/2012 07:46 AM, Gene Czarcinski wrote:
Currently, when an interface (virtual network) is started, if no ip
address is defined, then no rule is added to bemit "internal" network
traffic.  However, virtual guests can use such a network to
communicate if a rule is added to the iptables/ip6tables rule set.
This will work even if no ip address is defined on an interface (which
is valid).

I propose that rules of the following forms be added when an interface
is started and removed when it is destroyed:

iptables -I FORWARD 1 -i  virbr18 -o  virbr18  -j  ACCEPT
This rule is already added - see the call to
iptablesAddForwardAllowCross towards the end of
networkAddGeneralIptablesRules. An isolated network with no <ip>
elements should work with no problems for IPv4 traffic between the guests.
I pretty much figured out that nwfilters were not involved and that there was some code doing this.

ip6tables -I FORWARD 1 -i  virbr18 -o  virbr18  -j  ACCEPT
This one currently isn't getting added, because
networkAddGeneralIp6tablesRules() returns immediately if there are no
ipv6 addresses defined for the network.

Note that up until now, unless someone had an ipv6 address defined for a
network, ip6tables was never called, so theoretically you could run
libvirtd without having ip6tables installed on your machine, but with
this change *all* networks would fail to start if the ip6tables binary
was missing. That *shouldn't* be a problem because (at least on
Fedora/RHEL/CentOS) it is a part of the same package as iptables, but
I've seen strange setups in the last few years - in particular I recall
one Gentoo user whose networks were mysteriously failing, and it was
because he had built the iproute package with some sort of "minimal"
configuration that's available on Gentoo, causing something or other to
fail in a mysterious way (compounded in troubleshooting by the fact that
none of us would ever have expected such a thing).
How about a configure/compile time option for those systems which may not have ip6tables ... the default being that ip6tables is assumed.

Beyond that, the sysctl setting net.ipv6.conf.virbrX.disable_ipv6 is
always set to 1 UNLESS there is at least one ipv6 address on the
network. This was in the code for quite awhile before IPv6 support was
added. I wasn't around when that was put in, but it was consciously put
in by "somebody" who didn't want that allowed on an IPv4-only network.
danpb may be able to offer more insight on what prompted it, since he's
been involved from the beginning.

If a user wants a "very private network", the user has to run the
above commands.  The proposal simply does this automatically.
When IPv6 support was added, one of the goals was that operation of the
networks would be 100% identical for existing configurations. So if we
want anything to change, either we need to discuss if it's okay to
change the default behavior, or we need to add an attribute somewhere
that indicates "allow IPv6 traffic even if I don't have any IPv6 addresses".
If the goal is to make both networks identical for existing configurations, then this implies to me that the ip6tables rules, similar to the ones for IPv4, should be added. (see above about compile-time option).

It took me a while to get back to this ... I have been dancing as fast as I can to get my dnsmasq conf-file and DHCPv6 support reworked from v1.0.0 to the current master/origin. I had to do some hand-merging of some of the updating ... "meld" is a really useful tool.


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