[libvirt] Proposed: always allow packets internal to an interface
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. Gene
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? Gene
On 11/04/2012 12:18 PM, Gene Czarcinski 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
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? Well, it was a nice idea anyway. It seems to not work for ipv6.
1. I defined a network with no IPv4 or IPv6 addresses specified. 2. Took one of my guests and put attached that new network. 3. Edited the domain for the guest and added a <filterref name='allow-ipv4'/> 4. Started things up and got what I wanted in iptables. [that is when I wrote the previous message] 5. Using allow-ipv4 as my guide, created a new filter allow-ipv6. 6. Edited the domain again to use allow-ipv6. 7. Started things again ... ip6tables shows nothing! I seem to have stumbled across another bug. More later. Gene
On 11/04/2012 10:18 AM, Gene Czarcinski 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
ip6tables -I FORWARD 1 -i virbr18 -o virbr18 -j ACCEPT
I'm not as familiar with this as others, so I'll defer on whether this makes sense.
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?
But this I can answer. Yes, nwfilters is still an actively maintained concept, and yes, it is supposed to work with firewalld. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 11/04/2012 12:18 PM, Gene Czarcinski 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
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.
Are you sure of that? nwfilter rules are applied to the tap device that connects the guest's interface to the bridge, while these other rules you're talking about are on the bridge itself. (BTW, note that all FORWARD rules that involve a bridge interface become irrelevant if you have net.bridge.bridge-nf-call-iptables = 0 in /etc/sysctl.conf.)
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?
Still active. Works with firewalld. If you encounter a problem, you can look for stefanb in IRC - we all hang out in #virt on irc.oftc.net. As much as you're messing around with this code, you should be there too :-)
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.
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). 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".
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
On 11/05/2012 12:35 PM, Laine Stump wrote: 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
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"
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. If you do want to give someone the option of running without ip6tables, fine make it a compile-time option. Gene
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 11/08/2012 02:41 PM, Laine Stump wrote:
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.)
I believe it is time for someone who has the project memory to chime in on this. It also might be a good idea, if individuals who are knowledgeable in distributions other than Fedora and RHEL, to add their perspective On the other hand, while there may have been valid reasons to do this originally, it may be continuing because "this is the way we always did it." Gene
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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 11/08/2012 04:44 PM, Daniel P. Berrange 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
On 11/07/2012 04:25 PM, Gene Czarcinski wrote: 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"
On Thu, Nov 08, 2012 at 02:41:29PM -0500, Laine Stump wrote: 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.
I hear what you are saying but I am not sure I understand it because some simple testing I did resulted in exactly what I wanted. 1. Configure and start ad virtual network interface such as: <network> <name>nogw</name> <uuid>7a3b7497-1ec7-8aef-6d5c-38dff9109e93</uuid> <bridge name='virbr19' stp='on' delay='0' /> <mac address='52:54:00:08:10:43'/> </network> ip addr shows the following: 44: virbr19: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN link/ether 52:54:00:08:10:43 brd ff:ff:ff:ff:ff:ff 45: virbr19-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr19 state DOWN qlen 500 link/ether 52:54:00:08:10:43 brd ff:ff:ff:ff:ff:ff and I added a rule to ip6tables resulting in: -A FORWARD -i virbr19 -o virbr19 -j ACCEPT 2. Take two F17 virtual guest systems and configure them with "nogw" on a network interface. 3. Start them up and manually configure the NIC with the "nogw" network for fd00:1:1:1::2/64 and fd00:1:1:1::3/64 4. try doing a ping6 between the two ... works fine. Now, all I am asking for is to have the above ip6table rule added automatically (along with the standard rejects). The reult is a very private IPv6 network between the virtual guest systems. BTW, for "sysctl -a | grep virbr19 | grep "disable_ipv6"", the result is: net.ipv6.conf.virbr19.disable_ipv6 = 1 net.ipv6.conf.virbr19-nic.disable_ipv6 = 0 Just for info, this is all F17 with libvirt-1.0.0+ my bunch of patches. Now, what am I missing? What do I not understand? Gene
The reult is a very private IPv6 network between the virtual guest systems. A bit of clarification on why I would want such a capability (and, in
On 11/08/2012 05:41 PM, Gene Czarcinski wrote: truth, I have it today but I wanted to make it more automatic and available to anyone else). Lets say that (hypothetically) we want to set up a firewall, dmz, whatever so that we can (hypothetically)do some attack testing against the systems. To say the least (at least in the USA) this is very much frond upon on the real Internet. So, set up a real heardware network ... this gets expensive real fast. So, virtualization to the rescue. Set up your network configuration on some very private networks (yes, they will need their own dns, dhcp, RA, etc., etc. services). I can do it (and have) but I thought this might be useful to others. Obviously, this update should be accompanied by some documentation updates which explain what can be done. Gene
On 11/08/2012 04:44 PM, Daniel P. Berrange 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
On 11/07/2012 04:25 PM, Gene Czarcinski wrote: 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"
On Thu, Nov 08, 2012 at 02:41:29PM -0500, Laine Stump wrote: 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.
Okay, so there's the straight dope :-)
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.
Hmm - would it maybe be okay to always add the ip6tables rule to allow ipv6 traffic between interfaces on the bridge, while still setting disable_ipv6=1 (unless there is an <ip> with an ipv6 address)? The guests could then do IPv6 among themselves if they wanted, but there would be no way to get to the host via IPv6.
On 11/08/2012 09:01 PM, Laine Stump wrote:
Hmm - would it maybe be okay to always add the ip6tables rule to allow ipv6 traffic between interfaces on the bridge, while still setting disable_ipv6=1 (unless there is an <ip> with an ipv6 address)? The guests could then do IPv6 among themselves if they wanted, but there would be no way to get to the host via IPv6. All I can say is that it seems to work ... at least my definition of work.
Obviously (I hope) the virtualization host sees nothing of the communications between the virtual systems on the "very private" virtual network. Take a look at my message which describes what I did. Give it a try for your self and tell us what you see. I do not know how things are suppose to work, I can only report on how they do work. Now, that is not to say that if you call some function to do something, that, in addition to performing what you want, it also does some other "stuff." That is, if I have ip6tables do something, is it also doing something else? Gene
participants (4)
-
Daniel P. Berrange -
Eric Blake -
Gene Czarcinski -
Laine Stump