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 ip6tables -I FORWARD 1 -i virbr18 -o virbr18 -j ACCEPT If a user wants a "very private network", the user has to run the above commands. The proposal simply does this automatically.

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 > > ip6tables -I FORWARD 1 -i virbr18 -o virbr18 -j ACCEPT

> > If a user wants a "very private network", the user has to run the > above commands. The proposal simply does this automatically. It appears that this patch is not necessary since I can do this now using nwfilters. Question: I see little discussed or anything about nwfilters. Is nwfilters an active concept or is it still included because of legacy? Will this still work with firewalld?

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

ip6tables -I FORWARD 1 -i virbr18 -o virbr18 -j ACCEPT

If a user wants a "very private network", the user has to run the above commands. The proposal simply does this automatically.

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

On 11/07/2012 04:25 PM, Gene Czarcinski wrote: > On 11/06/2012 11:23 AM, Gene Czarcinski wrote: >>>> 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. > "ping" Sorry, I've been overwhelmed and am churning. > OK, I have not heard a plain yes or no on this. > > IPv4 and IPv6 networks are suppose to have the same (more or less) > functionality so why isn't this OK. "Maintaining backward compatibility", both API and operational. In the past it wasn't the case that we simply did nothing about ipv6 on libvirt's networks, instead we explicitly set a sysctl to *disable* it. That must have been done for some reason. That reason may no longer be valid, but we don't know that yet (it happened before I was around). If the reason is no longer valid, we can go ahead as you suggest (and I would say we don't even need an option to not have ip6tables, just force people to build the full iptables package as God intended :-P). If the reason *is* still valid, then we need to only enable the ipv6 sysctl and add the ip6tables rule in response to some new flag attribute in the network config. > If you do want to give someone the option of running without > ip6tables, fine make it a compile-time option. Actually I want to hear some historical info about why ipv6 was explicitly *disabled* with sysctl on libvirt's networks in the past. Maybe it's time to change that default, but I don't want to do it lightly - it may even have been done in response to a CVE. (danpb or DV would probably have the best insight about this. I'll point them at this thread.) New functionality is great, but you can't upset working systems. (I know I'm very tedious and am sounding like a broken record, but this is a topic that libvirt takes *very* seriously; the API must always be 100% backward compatible, and consciously programmed behavior should always remain the same.)

On Thu, Nov 08, 2012 at 02:41:29PM -0500, Laine Stump wrote: > On 11/07/2012 04:25 PM, Gene Czarcinski wrote: >> IPv4 and IPv6 networks are suppose to have the same (more or less) >> functionality so why isn't this OK. > "Maintaining backward compatibility", both API and operational. In the > past it wasn't the case that we simply did nothing about ipv6 on > libvirt's networks, instead we explicitly set a sysctl to *disable* it. > That must have been done for some reason. That reason may no longer be > valid, but we don't know that yet (it happened before I was around). If > the reason is no longer valid, we can go ahead as you suggest (and I > would say we don't even need an option to not have ip6tables, just force > people to build the full iptables package as God intended :-P). If the > reason *is* still valid, then we need to only enable the ipv6 sysctl and > add the ip6tables rule in response to some new flag attribute in the > network config. If you don't disable IPv6 on the bridge device, then when starting the network device, the kernel will auto-assign an IPv6 link local address, which the guest can then use to communicate with the host. In the IPv4 case, if you don't specify any <ip> address, there is no "link local" like address present, so there's no connectivity between guest and host. So explicitly disabling IPv6 is in fact required in order to give consistent behaviour between IPv6 and IPv4. I've no objections to anyone adding a new 'ipv6=on|off' attribute to the network XML so that admins can explicitly choosen whether to allow IPv6, indepedently of whether any <ip> element is set with an IPv6 address.

On Thu, Nov 08, 2012 at 02:41:29PM -0500, Laine Stump wrote: > On 11/07/2012 04:25 PM, Gene Czarcinski wrote: >> IPv4 and IPv6 networks are suppose to have the same (more or less) >> functionality so why isn't this OK. > "Maintaining backward compatibility", both API and operational. In the > past it wasn't the case that we simply did nothing about ipv6 on > libvirt's networks, instead we explicitly set a sysctl to *disable* it. > That must have been done for some reason. That reason may no longer be > valid, but we don't know that yet (it happened before I was around). If > the reason is no longer valid, we can go ahead as you suggest (and I > would say we don't even need an option to not have ip6tables, just force > people to build the full iptables package as God intended :-P). If the > reason *is* still valid, then we need to only enable the ipv6 sysctl and > add the ip6tables rule in response to some new flag attribute in the > network config. If you don't disable IPv6 on the bridge device, then when starting the network device, the kernel will auto-assign an IPv6 link local address, which the guest can then use to communicate with the host. In the IPv4 case, if you don't specify any <ip> address, there is no "link local" like address present, so there's no connectivity between guest and host. So explicitly disabling IPv6 is in fact required in order to give consistent behaviour between IPv6 and IPv4.

I've no objections to anyone adding a new 'ipv6=on|off' attribute to the network XML so that admins can explicitly choosen whether to allow IPv6, indepedently of whether any <ip> element is set with an IPv6 address.