Description of problem: Starting libvirtd with its default configuration creates a bridge interface virbr0 with IP 192.168.122.1. It also adds iptables rules to the nat table to allow VMs connected to this bridge to access the external network. These rules catch any incoming packet whose destination is not on the 192.168.122.0/24 subnet, even multicast packets. As a result, the host sees mDNS datagrams from its guests coming from its own IP address with a (more or less) random source port, whereas avahi expects them to come from port 5353. The obvious workaround (add a static nat rule like "iptables -t nat -A POSTROUTING -d 224.0.0.0/4 -j RETURN" to /etc/sysconfig/iptables) does not work, as libvirt inserts its rules before the existing ones. Version-Release number of selected component (if applicable): libvirt-0.8.2-1.fc13.x86_64 How reproducible: Always. Steps to Reproduce: 1. service libvirtd start 2. virsh start myguest (here myguest is a guest VM with avahi-daemon enabled) 3. getent hosts myguest.local Actual results: The last command times out. Here is the relevant line from /var/log/messages: Nov 28 12:11:51 carrosse avahi-daemon[22764]: Received response from host 192.168.122.1 with invalid source port 1025 on interface 'virbr0.0' Expected results: % getent hosts myguest.local 192.168.122.157 myguest.local
If one's willing to use hand-written iptables to accomplish NAT, is there a way of making libvirtd not try running iptables at all? I don't see documentation for the /etc/libvirt/libvirtd.conf file, should that hold the magic door.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Sounds like this is something libvirt could handle itself? Moving to rawhide
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Stefan Berger has been working on related code in the nwfilter components, with several improvements for 0.9.8. I have no idea if those improvements meet your need, or if there is still more to go to the point that you want; I suggest bringing this topic up on libvir-list (Stefan is more likely to see this on-list than by finding this BZ).
With nwfilter we may be able to prevent a VM from sending multicast traffic, but cannot influence what happens to it in case of NATing. We could add the above mentioned rule iptables -t nat -A POSTROUTING -d 224.0.0.0/4 -j RETURN via utils/iptables.c to the list of 3 rules that libvirt automatically creates in the iptables nat POSTROUTING chain. HOWEVER: Typically the multicast traffic would have to go onto the wire to get as many responses as possible. In this case I don't see it going onto the wire at all. I see them on the VM's tap interface but not on the physical interface anymore and while pinging from the VM into the network works and shows a counter increase on the respective masquerading rule I don't see any counter increase for the above rule if it is first in the list of rules. Some logic maybe already discards multicast traffic from entering the iptables NAT table? Adding the rule there at least doesn't make sense considering what I am seeing.
For my use case, mDNS is link-local anyway, so if the host acts as a router, the guest won't get to talk with the outside world and it is perfectly fine. OTOH the host should definitely get to see mDNS announcements from the guest. Note multicast routing is quite complicated anyway (needs dedicated protocols, on a LAN this probably means PIM), so I wouldn't expect it to work out of the box with a Linux host as a router.
Following my observations in comment 12 of the above iptables rule applied to the NAT table, I don't think that any changes are required to the iptables setup to the host's NAT table. However, I cannot confirm that an application running on the host gets the packets, but for sure I did not see them going on the wire in this network setup.
As I wrote earlier, the issue is that the packets get rewritten even if they are destined to the host, so the host sees them coming from the wrong UDP port (mDNS relies on source port). I guess my point is the iptables setup should be configurable, not hardcoded in libvirt.
I had done the following test: iptables -t nat -I POSTROUTING 1 -d 224.0.0.0/4 -s 129.168.122.0/24 -j ACCEPT This adds a rule that presumably intercepts all multicast traffic from VMs and simply accepts it. A VM is started and receives the IP address 192.168.122.239, which is in the above source subnet 129.168.122.0/24. This VM now starts pinging for example 8.8.8.8. iptables -t nat -L POSTROUTING -n -v Chain POSTROUTING (policy ACCEPT 64 packets, 4057 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 129.168.122.0/24 224.0.0.0/4 0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 1 84 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24 Above shows a counter of '1' indicating the masquerading of the ICMP traffic. Stopping and restarting the ping puts the counter to '2'. (due to connection tracking the rule is only needed once per ICMP stream) I started a 'tcpdump -i vnet0 -n' to monitor traffic from that VM. Inside the VM I did service avahi-daemon restart which then shows a flood of multicast messages on vnet0. One would think that that traffic now gets 'ACCEPT'ed due to the 1st rule above, but this is not the case. The output of iptables -t nat -L POSTROUTING -n -v still shows the same as above -- no counter change in the 1st ryule. The kernel was 2.6.35.14-97.fc14.x86_64. Changing above first rule to '-j MASQUERADE' or '-j RETURN' doesn't change a anything. The counter remains on '0'. My conclusion is that adding a rule here (for this kernel version at least) for multicast traffic makes no sense since it doesn't get invoked. Also see comment 12.
Moving this to the upstream tracker, since there's been some discussion and it's not really fedora specific (or a high impact bug)
What is the upstream tracker so that we can follow that?
(In reply to comment #18) > What is the upstream tracker so that we can follow that? This BZ is the upstream tracker; Cole is just pointing out that he changed the Product field from Fedora to 'Virtualization Tools'.
(In reply to comment #19) > > This BZ is the upstream tracker; Cole is just pointing out that he changed > the Product field from Fedora to 'Virtualization Tools'. Ahhh. Got it. Any action on this item? It seems like pretty low hanging fruit. I think I even had a libvirt that had a hack in place to do this, since I am seeing this issue resurfacing after upgrading to FC18.
(In reply to comment #16) > > iptables -t nat -I POSTROUTING 1 -d 224.0.0.0/4 -s 129.168.122.0/24 -j ACCEPT Surely you wanted to do s/129/192/ didn't you? > iptables -t nat -L POSTROUTING -n -v > > Chain POSTROUTING (policy ACCEPT 64 packets, 4057 bytes) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT all -- * * 129.168.122.0/24 224.0.0.0/4 > 0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 > 0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 > 1 84 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24 > ... > My conclusion is that adding a rule here (for this kernel version at least) > for multicast traffic makes no sense since it doesn't get invoked. Also see > comment 12. It probably would if the address in the rule were correct. It works here. It should be noted that you probably want to add 226.0.0.0/8 to your ACCEPT list.
Created attachment 661710 [details] Exempt multicast networks (224.0.0.0/4) from NATting How about this patch? It compiles here and has worked in previous versions of libvirt. I don't have occasion to test it right at this moment (to much other work with VMs still in progress) but I'm fairly confident that it should still work.
Can you please also post this patch upstream to libvir-list? You'll get a faster review, as not all list readers pay attention to BZ attachments.
I think this was eventually fixed by: commit 51e184e9821c3740ac9b52055860d683f27b0ab6 Author: Laszlo Ersek <lersek> Date: Wed Sep 25 12:45:26 2013 +0200 bridge driver: don't masquerade local subnet broadcast/multicast packets