If I switch the default netVM from sys-firewall to sys-net (for testing), dom0 can use it to update etc. Also any other VM gets internet connection with sys-net as Networking VM.
An update of dom0 from testing-repository did not fix the problem.
Also switching the sys-firewall template from fedora-26 to debian-9 does not help.
I found a similar problem here:
https://github.com/QubesOS/qubes-issues/issues/2141
So I checked the network interfaces and they are like this:
sys-net:
lo
enp0s0
vif2.0
sys-firewall:
eth0
lo
Not sure, but I guess the vif interface is missing in sys-firewall?
How do I fix this problem?
vif interface will appear when a VM connects to it.
Could you clarify the term no internet.
I had a lot of problems solved once sys-net had the service clocksync enabled (as it should).
--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/oN204nGh63I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/46a6952f-6fd5-4aec-93ca-994937a24c5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I did this and restarted everything, no difference.
> Yes probably. For reference, to check (or enable):
> - go to start menu/System Tools/Qube Manager
> - right click sys-net/Qube Settings/Services tab
> - clocksync should be in the list and ticked if not type clocksync and click on +
> - I think a full reboot is required. There are probably ways to avoid it...
clocksync is checked.
> I am confused, did you do this in sys-net or sys-firewall. Because sys-net would have a default route and a route for your Lan. You may have tripped the info which is fine.
In fact I left the default routes away and just focused on the missing one.
When I start sys-firewall a new network interface is added (vifx.0) where x is a number.
"ifconfig -a" displays:
vif3.0: flags=4098<BROADCAST,MULTICAST> mtu 1500
(and also 2 default interfaces: enp0s0 and lo, which are both UP and RUNNING)
I noticed here that "UP" / "RUNNING" is missing for the vif, therefore I have to "up" it myself.
This might be part of the problem, since it has to be running in order to add a new route (which should be done automatically).
So "route" in sys-net displays only the default routes:
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 enp0s0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s0
So if I add the route myself it additionally displays:
10.137.0.6 0.0.0.0 255.255.255.255 U 100 0 0 vif3.0
So far so good, the values in sys-net are looking "ok" to me now. Or am I missing something?
> on sys-firewall, you are probably going to need to ifconfig eth0 up and you should have something like this:
> -bash-4.4# netstat -nr
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 0.0.0.0 10.137.0.14 0.0.0.0 UG 0 0 0 eth0
> 10.137.0.14 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
On sys-firewall eth0 and lo are UP and RUNNING, but "route" takes around 20 seconds to finish and displays:
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 0 0 0 eth0
gateway 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
The long waiting time before "route" finishes makes me wonder...
I deleted the default routes and recreated them. I also restarted the eth0 interface.
When I try to ping 8.8.8.8 from sys-firewall I get:
From 10.137.0.6 icmp_seq=1 Destination Host Unreachable
From 10.137.0.6 icmp_seq=2 Destination Host Unreachable
...
I also switched the templates of sys-net and sys-firewall to debian-9, but the result is the same (vif down in sys-net, no route for vif).
The more I try to fix this, I get a feeling that the root of the problem lies inside sys-net.
It seems like the vif in sys-net does not get "up", which breaks the setup/initialization script (or maybe it breaks earlier, I don't know).
If I knew, which steps have to be done to set up network between a VM, sys-firewall and sys-net correctly, I could try to pinpoint the problem better.
What happens exactly behind the scenes when sys-firewall starts and uses sys-net as netVM?
Also I was thinking if iptables might be involved here?!
Yes looks good.
>
>
> > on sys-firewall, you are probably going to need to ifconfig eth0 up and you should have something like this:
> > -bash-4.4# netstat -nr
> > Kernel IP routing table
> > Destination Gateway Genmask Flags MSS Window irtt Iface
> > 0.0.0.0 10.137.0.14 0.0.0.0 UG 0 0 0 eth0
> > 10.137.0.14 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
>
> On sys-firewall eth0 and lo are UP and RUNNING, but "route" takes around 20 seconds to finish and displays:
>
> Destination Gateway Genmask Flags Metric Ref Use Iface
> default gateway 0.0.0.0 UG 0 0 0 eth0
> gateway 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
>
> The long waiting time before "route" finishes makes me wonder...
This is probably just because it tries to resolve the IPs and DNS times out. if you use netstat -nr, it should be fast.
>
> I deleted the default routes and recreated them. I also restarted the eth0 interface.
>
> When I try to ping 8.8.8.8 from sys-firewall I get:
>
> From 10.137.0.6 icmp_seq=1 Destination Host Unreachable
> From 10.137.0.6 icmp_seq=2 Destination Host Unreachable
> ...
>
>
> I also switched the templates of sys-net and sys-firewall to debian-9, but the result is the same (vif down in sys-net, no route for vif).
>
> The more I try to fix this, I get a feeling that the root of the problem lies inside sys-net.
Or the "physical" link between sys-net and sys-firewall. I believe there is a doc page (or maybe a thread here) on how to reconnect after a disconnection.
could you please do the arp -an after the ping 8.8.8.8
If you have a MAC address for sys-net, then you have "wire" connectivity, otherwise, it is where the pb is.
> This is probably just because it tries to resolve the IPs and DNS times out. if you use netstat -nr, it should be fast.
Yes, using "netstat -nr" I get a result immediately in sys-firewall:
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.137.0.5 0.0.0.0 UG 0 0 0 eth0
10.137.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> could you please do the arp -an after the ping 8.8.8.8
"arp -an" in sys-net displays:
? (192.168.0.2) at xx:xx:xx:xx:xx:xx [ether] on enp0s0
(xx:xx:xx:xx:xx:xx is a valid mac address, I just replaced the actual values with X's)
"arp -an" in sys-firewall displays:
? (10.137.0.5) at <incomplete> on eth0
Yes, so the problem is that you don't have connectivity between the 2 VMs.
Could you try this:
qvm-prefs sys-firewall | grep netvm
it should say sys-net? Y/N
Based on the info in the Qubes Firewall doc page
Even if it states sys-net, let's try to force it again
qvm-prefs sys-firewall -s netvm sys-net
and try the arp -an in sys-firewall again
yes, result is sys-net
> Even if it states sys-net, let's try to force it again
> qvm-prefs sys-firewall -s netvm sys-net
that command did not work due to wrong syntax, so I did:
qvm-prefs --set sys-firewall netvm sys-net
If sys-firewall is shut down, the command works.
If sys-firewall is running, the command fails with the error:
"no such preoperty: 'netvm'", in addition if sys-firewall is running while I do this, the eth0 interface is removed from sys-firewall.
> and try the arp -an in sys-firewall again
Still the same result:
? (10.137.0.5) at <incomplete> on eth0
Maybe I should try to look into the script(s) that are running when using "qvm-prefs --set sys-firewall netvm sys-net"?
Yes good idea. I would need to do so too to be able to help now... I'm not familiar with this part.