Qubes 3.2 Network failure after update template to fedora-25

[j...@stonequarter.com]

I've been using Qubes 3.2 for about 6 months. I installed it with all the default settings. The template used for sys-net and sys-firewall is the standard fedora-23. I've attempted to update it to fedora-24 and now fedora-25, however each time I change the Template in the vm settings from fedora-23 to fedora-24 or -25, the network fails.

By fails I mean, only from sys-net can I access the internet with a simple ping. sys-firewall fails to communicate with sys-net. All the other templates and user vm's also fail to access the internet.

When I revert sys-net back to fedora-23 but leave sys-firewall at either fedora-24 or fedora-25, the sys-firewall can then begin to ping the internet, but everything behind the sys-firewall cannot.

When I revert sys-firewall back to fedora-23 (sys-net still at fedora-23), then all works again. I am able to update the template for all my other vm's to fedora-24 or 25 and they will work as long as the sys-firewall and sys-net are left at fedora-23. But if either sys-firewall or sys-net are using any template other than fedora-23, the network traffic fails somewhere along the route.

I have noticed that when fedora-23 template is being used, the network setup in sys-net is different than when fedora-24 or 25 templates are being used. It looks like the vif is not being defined.

sys-net with fedora-23 template:
enp0s0: inet 192.168.0.60 netmask 255.255.255.0 broadcast 192.168.0.255
lo: inet 127.0.0.1 netmask 255.0.0.0
vif6.0: inet 10.137.1.1 netmask 255.255.255.255 broadcast 0.0.0.0

sys-net with fedora-25 template:
enp0s0: inet 192.168.0.59 netmask 255.255.255.0 broadcast 192.168.0.255
lo: inet 127.0.0.1 netmask 255.0.0.0
vif12.0: no inet, netmask, or broadcast defined

The only changes I've made is to install the fedora-25 template from the repo and change the template in the sys-net and sys-firewall vm.

Did I miss a step in the update process to migrate from one fedora template to another?

Any thoughts are appreciated.

[j...@stonequarter.com]

I've been doing more digging and came across an FAQ that suggested checking:
systemctl enable NetworkManager-dispatcher.service

In reviewing the fedora-23 and 25 templates, the service is enabled in both.

This morning I shutdown all qubes and brought sys-net up under fedora-25. The network interfaces showed enp0s0 and lo - both properly plumbed and I could ping the external world. But there was no vif interface. NetworkManager-dispatcher.service showed it ran successfully.

I then started sys-firewall (also under fedora-25). When sys-firewall started successfully, I looked at the network interfaces on sys-net and now vif10.0 was added, but it carries no inet or inet6 IP addresses.

I'm not finding any logs in dom0 or sys-net that would tell me why the vif didn't get an IP. Any suggestions on where I might look for the problem?

[Unman]

I've noticed after one of the recent updates, that my Debian qubes
sometimes dont get allocated an IP address on first connection -
particularly if I change netvm. (I dont use Fedora)
What works for me is just running the connection again -
qvm-prefs <qube> -s netvm <netvm>

After the second "bump" the IP address is allocated as expected.
I haven't bothered to debug.

I'd be interested to know if you see this behaviour when using Debian
templates, and if it's particular to sys-net or if it affects any
netvm, including sys-firewall.

NetworkManager-dispatcher is an old service that should trigger on
change in external IP - I dont think it's relevant to your issue.
It's expected that there wont be a vif interface until you attach a qube
downstream.

[j...@stonequarter.com]

Thanks Unman for the info and suggestion.

I switched the template for sys-net to debian-8. This one came along with Qubes 3.2. sys-net had no trouble getting an IP assigned to the vif.

I then switched the template for sys-net back to fedora-25 and the IP assignment to the vif again failed as before.

I then issued:
qvm-prefs sys-net -s netvm none

That didn't resolve the problem - sys-net still didn't get an IP assigned to the vif.

Next I thought maybe it is upstream and ran the qvm-prefs against the sys-firewall:
qvm-prefs sys-firewall -s netvm sys-net

Same problem - no IP assigned to the sys-net vif.

I use debian for some of the qubes but have not used it for the sys-net or sys-firewall. I'm also suspect that since debian-8 came with the qubes 3.2 release, it may be working just like fedora-23 has been working. I'll follow the clone and upgrade instructions to take the debian-8 and transform it into a debian-9 template and try it. If that works, I'll shift the netvm's over to debian and then reevaluate with Qubes 4.0.

[j...@stonequarter.com]

I ran a test after cloning and transforming a debian-8 template to a debian-9 template. The sys-net vm exhibited the same trouble with getting an IP assignment using the debian-9 template as the fedora-24 and 25 templates. So, it looks like I have something fundamentally misconfigured in dom0 (and I try not to touch it) in my installation where it can only use the original templates for sys-net and sys-firewall. I'm able to use the newer templates for all the other qubes.

I tested sys-net and sys-firewall incrementally with different underlying templates and the only ones that would work were fedora-23 or debian-8. I've switched to debian-8 for sys-net and sys-firewall since it works. I'll then start with a fresh install with Qubes 4.0 and migrate my user qubes.

When I have time I'll look into the IP assignment process and the firewall to see what's going on.