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

[Gene Czarcinski]

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.

Gene