Bug 21927 - gnome-boxes guest operating system is not able to connect to internet
Summary: gnome-boxes guest operating system is not able to connect to internet
Status: UNCONFIRMED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal major
Target Milestone: Mageia 8
Assignee: GNOME maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 27258
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-24 17:43 CEST by Cyril Levet
Modified: 2022-04-15 19:31 CEST (History)
4 users (show)

See Also:
Source RPM: gnome-boxes-3.24.0-1.mga6.src.rpm
CVE:
Status comment:


Attachments
Troubleshooting Log of Mageia 7 guest (22.80 KB, text/plain)
2019-09-15 11:49 CEST, Cyril Levet
Details

Description Cyril Levet 2017-10-24 17:43:45 CEST
Description of problem:

Mageia 6 guest operating system is not able to connect to internet. The host operating system is Mageia 6. Gnome network manager and MCC indicate that the guest is connected but it is impossible to connect to internet or to download updates (urpmi or MCC). When deactivate the Mageia 6 host firewall, sometimes the guest connexion works. However, often, deactivate the host firewall has no effect.
Same problem is noted with Fedora 26 guest.


Version-Release number of selected component : gnome-boxes-3.24.0-1.mga6


How reproducible: always with host firewall is activated, often when host firewall is off.


Steps to Reproduce:
1. Create a Mageia 6 guest on gnome-boxes
2. Try to open a wab-site or download mirrorlist with MCC
Marja Van Waes 2017-10-25 09:50:36 CEST

CC: (none) => marja11
Assignee: bugsquad => gnome

Comment 1 Marja Van Waes 2017-10-27 19:58:56 CEST
Mass-change status to NEW for all bugs that were filed as UNCONFIRMED between October 9 and now, and that still have that status now.

From now on all newly filed bugs will have the NEW status again, like before, regardless of who files the report.

Status: UNCONFIRMED => NEW
Ever confirmed: 0 => 1

Comment 2 Cyril Levet 2018-07-01 16:15:55 CEST
I don't know why but this bug seems to happen less often than before with Mageia 6 host and Mageia Cauldron guest. But it still happen sometimes.
Comment 3 Cyril Levet 2019-09-15 11:47:52 CEST
The bug is still present in Mageia 7 with boxes 3.32.1-stable. 
I have uninstalled gnome-boxes, deleted all orphans and reinstalled Boxes. 
I have created a Mageia 7 guest machine and a Fedora 30 Workstation (which is one of the default choice in Boxes). Connection to network does not work. I join the internal log of the VM.
Comment 4 Cyril Levet 2019-09-15 11:49:59 CEST
Created attachment 11281 [details]
Troubleshooting Log of Mageia 7 guest
Cyril Levet 2019-11-04 23:49:29 CET

Version: 6 => 7

Aurelien Oudelet 2020-09-04 23:13:39 CEST

Target Milestone: --- => Mageia 8

Aurelien Oudelet 2020-09-04 23:14:14 CEST

Keywords: (none) => NEEDTEST

Comment 5 Martin Whitaker 2020-09-04 23:32:20 CEST
Try restarting the libvirtd service on the host machine before starting the guest.

CC: (none) => mageia

Comment 6 Cyril Levet 2020-09-05 13:53:40 CEST
(In reply to Martin Whitaker from comment #5)
> Try restarting the libvirtd service on the host machine before starting the
> guest.

Restarting libvirtd service does not fix the problem.

I have this behaviour on two different computers with Mageia 7. One is an upgrade from Mageia 6, the other is a fresh install of Mageia 7. Both using only Gnome since installation. They have different processors, different motherboard and different graphic cards so it seems not be material related.

After restarted libvritd the log is :

● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-09-05 13:47:00 CEST; 2s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 15970 (libvirtd)
    Tasks: 19 (limit: 32768)
   Memory: 132.8M
   CGroup: /system.slice/libvirtd.service
           ├─ 1609 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           ├─ 1610 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           └─15970 /usr/sbin/libvirtd

sept. 05 13:47:00 mageia systemd[1]: Starting Virtualization daemon...
sept. 05 13:47:00 mageia libvirtd[15970]: libvirt version: 5.5.0
sept. 05 13:47:00 mageia libvirtd[15970]: hostname: mageia
sept. 05 13:47:00 mageia libvirtd[15970]: Libvirt doesn't support VirtualBox API version 6000024
sept. 05 13:47:00 mageia systemd[1]: Started Virtualization daemon.
sept. 05 13:47:00 mageia dnsmasq[1609]: read /etc/hosts - 2 addresses
sept. 05 13:47:00 mageia dnsmasq[1609]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
sept. 05 13:47:00 mageia dnsmasq-dhcp[1609]: read /var/lib/libvirt/dnsmasq/default.hostsfile
sept. 05 13:47:00 mageia libvirtd[15970]: cannot open directory '/home/cyril/Logiciels/Mageia-6-x86_64-DVD': Aucun fichier ou dossier de ce type
sept. 05 13:47:00 mageia libvirtd[15970]: internal error: Failed to autostart storage pool 'Mageia-6-x86_64-DVD': cannot open directory '/home/cyril/Logiciels/Mageia-6-x86_64-DVD': Aucun fichier ou dossier de ce type

The two errors are related with non existent files and VM. It is not important.

Running Fedora 30 server in gnome-boxes has no internet connection. Status of libvirtd after closing gnome-boxes is :

systemctl status libvirtd.service
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-09-05 13:47:00 CEST; 3min 9s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 15970 (libvirtd)
    Tasks: 19 (limit: 32768)
   Memory: 132.9M
   CGroup: /system.slice/libvirtd.service
           ├─ 1609 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           ├─ 1610 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
           └─15970 /usr/sbin/libvirtd

sept. 05 13:49:29 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:34 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:39 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:39 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:44 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:49:44 mageia dnsmasq[1609]: failed to send packet: Operation not permitted
sept. 05 13:50:05 mageia libvirtd[15970]: End of file while reading data: Erreur d'entrée/sortie
Comment 7 Martin Whitaker 2020-09-05 22:34:34 CEST
With the guest running, what is the output from the following commands, run as root on the Mageia 7 host?

  virsh net-list --all
  brctl show
  iptables -S | grep LIBVIRT
  iptables -S | grep virbr
Comment 8 Cyril Levet 2020-09-06 01:41:27 CEST
virsh net-list --all
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

brctl show
bridge name	bridge id		STP enabled	interfaces
virbr0		8000.525400e47d2b	yes		tap0
							virbr0-nic

iptables -S | grep LIBVIRT
-N LIBVIRT_FWI
-N LIBVIRT_FWO
-N LIBVIRT_FWX
-N LIBVIRT_INP
-N LIBVIRT_OUT
-A INPUT -j LIBVIRT_INP
-A FORWARD -j LIBVIRT_FWX
-A FORWARD -j LIBVIRT_FWI
-A FORWARD -j LIBVIRT_FWO
-A OUTPUT -j LIBVIRT_OUT
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT

iptables -S | grep virbr
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
Comment 9 Martin Whitaker 2020-09-06 11:52:49 CEST
You need to reconfigure the host firewall to include the virbr0 interface. Once you have done that (and any subsequent time you run drakfirewall) you will need to restart the libvirtd service (because the firewall rules it added will have been removed).
Comment 10 Cyril Levet 2020-09-06 12:36:54 CEST
Thank you it's work.

However I don't understand. Is it a bug because firewall and libvirtd.service are not properly configured when installing gnome-boxes ? Or did I make a mistake ?

Is it possible to force libvirtd restarting after using drakfirewall in order to avoid manual operation ?
Comment 11 Martin Whitaker 2020-09-07 21:45:20 CEST
Not really a bug, more a lack of integration. shorewall expects to be in sole control of the iptables rules, and doesn't allow for them being changed behind its back. And from what I can find on the web, it seems the developers of libvirt use firewalld, not shorewall.

You could try putting in an enhancement request to make drakfirewall aware of libvirt, but I don't know that it would get any attention.

I did find this:

  https://wiki.mageia.org/en/Virt-Manager

which suggests a way of manually configuring shorewall to handle the libvirtd connections, but haven't tried it, and don't know if drakfirewall would recognise and retain those settings.

Keywords: NEEDTEST => (none)

Comment 12 Cyril Levet 2020-09-08 00:09:26 CEST
Thanks. I will create the enhancement request for reference even if it will never get attention.

I try the manual configuration. Restarted shorewall works. But when I run drakfirewall after that, I always need to restart libvirtd.
Cyril Levet 2020-09-08 00:32:37 CEST

Depends on: (none) => 27258

Comment 13 Aurelien Oudelet 2021-07-06 13:15:59 CEST
Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.
Comment 14 Aurelien Oudelet 2021-07-06 20:20:52 CEST Comment hidden (obsolete)

CC: (none) => ouaurelien
Version: 7 => 8

Comment 15 Cyril Levet 2021-07-06 20:44:17 CEST
I have just tested. Internet connection works on Mageia 8.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 16 Mika Laitio 2022-04-15 19:19:02 CEST
This bug should proably be preopened as it occurs for me with freshly installed  Mageia 8/gnome installation. Only configuration I have made to host computer is to update all mageia 8 rpm's to latest one with urpmi and then install gnome-boxes also with urpmi.

When I use gnome-boxes to create the Mageia 8 virtual machine from iso image, the client virtual machine fails to connect to internet. I believe this happens because gnome-bboxes host has created virbr0 to be used for the network communication with the vm-client but the shorewall is blocking the virbr0.

One possible fix would be to make gnome-boxes and virt-manager to add the virbr0 to /etc/shorewall/interfaces but maybe some better method wouyld also exist by creating some kind of file like /usr/share/shorewall/macro.QEMU

Resolution: FIXED => (none)
CC: (none) => lamikr
Status: RESOLVED => UNCONFIRMED
Ever confirmed: 1 => 0

Comment 17 Mika Laitio 2022-04-15 19:22:15 CEST
Here is some info gathered from my system:

1) dmesg is full of these

30744.798232] OUTPUT REJECT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.140 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=56846 DF PROTO=UDP SPT=53 DPT=34632 LEN=102 
[30744.798303] OUTPUT REJECT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.140 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=56847 DF PROTO=UDP SPT=53 DPT=34632 LEN=38

2) virsh net-list --all

 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

3) brctl show

bridge name	bridge id		STP enabled	interfaces
virbr0		8000.5254005091cc	yes		tap0

4) iptables -S | grep LIBVIRT


-N LIBVIRT_FWI
-N LIBVIRT_FWO
-N LIBVIRT_FWX
-N LIBVIRT_INP
-N LIBVIRT_OUT
-A INPUT -j LIBVIRT_INP
-A FORWARD -j LIBVIRT_FWX
-A FORWARD -j LIBVIRT_FWI
-A FORWARD -j LIBVIRT_FWO
-A OUTPUT -j LIBVIRT_OUT
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT
Comment 18 Mika Laitio 2022-04-15 19:31:22 CEST
Execution of following commands on virtual machine host system fixes the problem and Mageia running on virtual machine quest that has been created by gnome-boxes can access the internet.

# echo "net   virbr0  detect" | tee -a /etc/shorewall/interfaces 
# echo "net   virbr0  detect" | tee -a /etc/shorewall6/interfaces
# systemctl restart shorewall.service
# systemctl restart shorewall6.service
# systemctl restart libvirtd.service

Note You need to log in before you can comment on or make changes to this bug.