no network between domains and netvm after fresh R2.0 installation + default upgrades

60 views
Skip to first unread message

si...@tutanota.com

unread,
Oct 17, 2015, 6:12:28 AM10/17/15
to Qubes Users
I installed a fresh R2.0 (after fighting R3.0 for 2 weeks now), and out of the box, everything worked fine (e.g. browsed using disp1 firefox).
Upgraded dom0 and the fedora template, reboot, and then no network from disp vm.

Checking further, I can confirm that netvm sees the internet (ping).
firewallvm sees netvm (10.137.1.1, as well as the dhcp address) and other vms (10.137.2.8), but not the internet nor my local router that runs the dhcpd.
other vm (10.137.2.8) see only firewallvm (10.137.1.5), but not netvm (10.137.1.1) nor the internet.

iptables --list in firewallvm looks OK (e.g. on chain FORWARD there is also ACCEPT for all ports from other vm to anywhere).
/proc/sys/net/ipv4/ip_forward is 1 both in netvm and firewallvm.
 
where should I look next?

--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

si...@tutanota.com

unread,
Oct 17, 2015, 6:44:15 AM10/17/15
to Qubes Users
Maybe this helps to debug the issue (is this normal to have nothing on netvm):
$ xl network-list firewallvm
Idx BE Mac Addr.                  handle state evt-ch    tx-/rx-ring-ref BE-path
0     1    00:16: .. :03                          0        4         -1    316/317            /local/domain/1/backend/vif/2/0
$ xl network-list netvm
Idx BE Mac Addr.                  handle state evt-ch    tx-/rx-ring-ref BE-path


--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

17. Oct 2015 12:12 by si...@tutanota.com:

Victor L.

unread,
Oct 25, 2015, 6:17:13 AM10/25/15
to qubes-users, si...@tutanota.com

I installed a fresh R2.0 (after fighting R3.0 for 2 weeks now), and out of the box, everything worked fine (e.g. browsed using disp1 firefox).
Upgraded dom0 and the fedora template, reboot, and then no network from disp vm.

Checking further, I can confirm that netvm sees the internet (ping).
firewallvm sees netvm (10.137.1.1, as well as the dhcp address) and other vms (10.137.2.8), but not the internet nor my local router that runs the dhcpd.
other vm (10.137.2.8) see only firewallvm (10.137.1.5), but not netvm (10.137.1.1) nor the internet.

Same happening to me with my Qubes R2 setup that's been working for months. Since the last template and dom0 updates I lost all connectivity from AppVMs.
If I do: ping google.com
it only works from netvm. I tried creating new netvm and firewallvm, but same problem.
When I do qvm-prefs firewallvm -s netvm netvm it usually complains about iptables-restore
If I manually call in netvm: qubes-setup-dnat-to-ns it complains with:
"iptables: No chain/target/match by that name.
iptables-restore: line 2 failed"

If I do iptables-save I get no PR-QBS chain in the "*nat" table

That is my main work machine, and no internet is a heavy blow, please help!



 

Victor L.

unread,
Oct 25, 2015, 6:28:58 AM10/25/15
to qubes-users, si...@tutanota.com


On Sunday, October 25, 2015 at 11:17:13 AM UTC+1, Victor L. wrote:

I installed a fresh R2.0 (after fighting R3.0 for 2 weeks now), and out of the box, everything worked fine (e.g. browsed using disp1 firefox).
Upgraded dom0 and the fedora template, reboot, and then no network from disp vm.

Checking further, I can confirm that netvm sees the internet (ping).
firewallvm sees netvm (10.137.1.1, as well as the dhcp address) and other vms (10.137.2.8), but not the internet nor my local router that runs the dhcpd.
other vm (10.137.2.8) see only firewallvm (10.137.1.5), but not netvm (10.137.1.1) nor the internet.

Same happening to me with my Qubes R2 setup that's been working for months. Since the last template and dom0 updates I lost all connectivity from AppVMs.
If I do: ping google.com
it only works from netvm. I tried creating new netvm and firewallvm, but same problem.
When I do qvm-prefs firewallvm -s netvm netvm it usually complains about iptables-restore
If I manually call in netvm: qubes-setup-dnat-to-ns it complains with:
"iptables: No chain/target/match by that name.
iptables-restore: line 2 failed"

If I do iptables-save I get no PR-QBS chain in the "*nat" table


I just tried copying the *nat section (doing "iptables-save") from another PC's Qubes R3 installation and restored it into the Qubes R2 machine's netvm.
Now I can ping IPs from firewallvm, but still can't ping a name (i.e. google.com)

So I believe the latest updates may have screwed the default iptables
 

Victor L.

unread,
Oct 25, 2015, 7:02:14 AM10/25/15
to qubes-users, si...@tutanota.com

In line with all this, if I do this in netvm and also in firewallvm:
sudo su-
iptables-restore < /etc/sysconfig/iptables.qubes

Then I can now ping an IP and a webname from firewallvm.
From AppVMs I can now ping an IP, but not a webname.

I happen to have one TemplateVM that I did not update, and there the file in /etc/sysconfig is named "iptables", instead of "iptables.qubes" as in the update TemplateVM.
Maybe there is some script (qvm-prefs?) expecting the previous name?


By the way, when I do in firewallvm this:
    sudo service qubes-firewall status -l
These are the two last lines:
.... systemd[1]: Started Qubes firewall updater.
.... qubes-firewall[706]: xenstore-list: could not list path qubes-iptables-domainrules

This all really looks like name mismatches...



Victor L.

unread,
Oct 25, 2015, 8:02:15 AM10/25/15
to qubes-users, si...@tutanota.com
Temporary solution after booting up the computer, do on netvm and then in firewallvm this:

sudo su -
iptables-restore < /etc/sysconfig/iptables.qubes
systemctl restart iptables
/usr/lib/qubes/qubes-setup-dnat-to-ns

I recover all connectivity on all AppVMs (including ones with non-updated TemplateVM)

si...@tutanota.com

unread,
Oct 27, 2015, 6:52:49 PM10/27/15
to Victor L., qubes-users
My solution was to skip some packages during the upgrade:
on dom0, I added to /etc/yum.conf
exclude=qubes-core-dom0 yum
on fedora-20, I added to /etc/yum.conf
exclude=qubes-core-vm

Once this is done, everything works smoothly.
I hope this doesn't have any security consequences, but I don't expect it.
I managed to get to this solution by reinstall, and slowly upgrade until network broke.

Maybe with this information, it would be easier to fix the problem...


--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

25. Oct 2015 13:02 by gall...@gmail.com:
Reply all
Reply to author
Forward
0 new messages