Description of problem: I'm using VirtualBox with a host-only virtual network. The consequences of that are that when I start a VM, a new network interface shows up (vboxnet0). I used firewall-config to set my default zone to trusted. However, firewall-cmd doesn't show vboxnet0 as belonging to the trusted zone, and firewalld is blocking mDNS traffic from that interface. I used Wireshark to confirm that the mDNS packets are sent and received. Version-Release number of selected component (if applicable): 0.2.9-1.fc18 How reproducible: Always Steps to Reproduce: 1. Set up a VirtualBox VM with host-only networking, and configure the VM to have a mDNS server. My VM happens to use avahi-daemon on an Ubuntu 12.10 server with a tweaked configuration, but any mDNS server works. Exact steps for setting up the VM: https://github.com/csail/mit6470-vm/blob/master/building/01-vm-setup.md 2. Start the VM. 3. On the Fedora host, install wireshark-gnome and avahi-tools. 4. On the Fedora host, run Wireshark and start a capture on vboxnet0. 5. On the Fedora host, run avahi-resolve-host-name webdev.local (replace webdev.local with the VM hostname) 6. In Wireshark, observe the mDNS queries and responses. 7. On the Fedora host, run firewall-cmd --list-all Actual results: 1. avahi-resolve-host-name displays the error message below. Failed to resolve host name 'webdev.local': Timeout reached 2. vboxnet0 does not show up in the firewall-cmd output. Expected results: 1. avahi-resolve-host-name should return the IP of the VM's host-only network interface. 2. vboxnet0 is included under trusted > interfaces: in the firewall-cmd output. Additional info: The avahi-related steps work on Fedora 17 with the firewall set to "Disabled", so I'm guessing it's a firewalld issue. I have some mDNS servers on my real Ethernet network (which is listed under trusted > interfaces), and I can resolve them with avahi-resolve-host-name from the Fedora host, so I really think it's firewalld not putting the VirtualBox network interface in the right bucket.
Does manual adding of vboxnet0 to a (default) zone change anything ? # firewall-cmd --add-interface=vboxnet0
@Jiri: Yes. "firewall-cmd --list-all" shows vboxnet0 under trusted > interfaces, mDNS traffic goes through.
@Jiri: I checked to see if the fix persists across reboots, and that doesn't seem to be the case. Should firewalld do something along the lines of what you suggested whenever it gets a packet from an interface that it doesn't know about?
(In reply to comment #4) > @Jiri: I checked to see if the fix persists across reboots, and that doesn't > seem to be the case. That's right. It's a NetworkManager that tells firewalld what interface needs to be added to which zone. NM doesn't manage vboxnet0, therefore doesn't tell firewalld about it. > Should firewalld do something along the lines of what you suggested whenever > it gets a packet from an interface that it doesn't know about? AFAIR, Thomas was talking about changing the 'default zone' concept so all interfaces will be in default zone (unless told otherwise) regardless whether managed by NM or not. That should fix this problem too.
This will be fixed as a 0-day update for F-18. Please have a look at #888288.
Fixed in GIT: http://git.fedorahosted.org/cgit/firewalld.git/commit/?id=4ec98e390102b5c065f7b2855204e01c08af88c1
firewalld-0.2.12-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/firewalld-0.2.12-1.fc18
Package firewalld-0.2.12-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firewalld-0.2.12-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0810/firewalld-0.2.12-1.fc18 then log in and leave karma (feedback).
The update fixed the bug for me. Thank you!
firewalld-0.2.12-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.