Qubes R4.0 - no internet working in appVM

[niepo...@gmail.com]

Fresh install of Qubes R4.0 and there is no internet connection in appVM - firefox just not load websites.

Internet connection actually is ok as I'm able to make update for template VM.

What can be reason of this not working internet in app VM and how resolve this?

[Qubes Guy]

Is this still a problem? Did you give your AppVM access to the net VM (set "Networking" to sys-firewall (preferably) or sys-net in the settings dialog for the AppVM)?

[niepo...@gmail.com]

Yes, problem still exist.

There was sys-firewall connected to appVM as well sys-net and no connection.
I have also tried changing template from fedora to debian -internet not working.
I have also install chromium browser and connection not working.

Very frustrating situation...

[Qubes Guy]

Open a terminal in your sys-net VM and type "ping wwww.google.com" (without quotes). If you get no response, you need to figure out why you have no network connectivity in that VM. (It should say something like "64 bytes from .... time=18.5ms" or something like that.) Let me know if you have network access there. I'm hitting the road for a little while. I'll respond as soon as I can...

[Qubes Guy]

And, of course, I meant "www.google.com". Try that. If you don't get a response, let me know how you're getting your Internet (Wireless or Ethernet) and the name and model of the network card/controller

[niepo...@gmail.com]

netVM has ok ping to google.com
firewallVM has no pings
appVM has also no pings

Maybe it's worth to mention: update template VM was done with success (which is a bit odd as update actually was done with success as firewallVM has no pings).

[Sergio Matta]

Em sábado, 12 de maio de 2018 16:08:11 UTC-3, niepo...@gmail.com escreveu:
> netVM has ok ping to google.com
> firewallVM has no pings
> appVM has also no pings

1) do you ping by ip, ex. ping 8.8.8.8?
if yes set dns

if not
2) in a dom0 terminal, qvm-ls sys-net shows virt_mode hvm, qvm-ls sys-firewall shows virt_mode pvh and qvm-ls personal (or whatever you a using) shows virt_mode pvh?
3) in a sys-net terminal, ifconfig -a shows vif3.0, and in sys-firewall terminal ifconfig -a shows vif4.0?

[Qubes Guy]

Set the "Networking" setting in your AppVM settings dialog to point to sys-firewall, set the "Networking" setting in sys-firewall to point to sys-net, and if your network connection is coming via an Ethernet-to-USB adapter, set the "Networking" setting in sys-net to point to sys-usb. (A sidenote regarding the latter: If you don't already have a separate VM to handle USB services, you really should create it, even if you're not using an Ethernet-to-USB adapter. Note that only one VM should be responsible for providing network services (which would either be sys-net or sys-usb, depending on the card/adapter you're using to provide Internet. If you *do* have an Ethernet-to-USB adapter, you'll want to set the "Provides network services" checkbox when you go to create the sys-usb VM.) You also need to add "qubes-updates-proxy" (without quotes) to the list of services in the sys-net settings dialog. After you do all this, you should be able to use "sudo apt-get update" in a terminal in your template VM to install or update packages (which AppVMs inherit, of course). One thing I've discovered is that you often need to restart VMs to get them to recognize changes you've made, so if you don't get what you expect, restart the VM in question. Let me know what happens...

[Qubes Guy]

One thing I forgot to mention: Do NOT set the "Networking" setting in your template VMs (set it to "None"). Giving network access to your templates is considered a major security threat (since all AppVMs you base on them inherit any malware/corruption). If you put "qubes-updates-proxy" in the services tab of sys-net, you won't need to do this. If you absolutely need to do this anyway, turn it off as soon as possible...

[awokd]

Are you using the default templates and AppVMs, or ones you've restored?
Try doing a reinstall and testing with the default ones only.

[niepo...@gmail.com]

On Sunday, May 13, 2018 at 11:59:16 AM UTC-4, awokd wrote:

> On Sat, May 12, 2018 7:08 pm, wrote:
> > netVM has ok ping to google.com
> > firewallVM has no pings
> > appVM has also no pings
> >
> > Maybe it's worth to mention: update template VM was done with success
> > (which is a bit odd as update actually was done with success as firewallVM
> > has no pings).
>
> Are you using the default templates and AppVMs, or ones you've restored?
> Try doing a reinstall and testing with the default ones only.

appVM's are not restored. All is default except I changed to pv mode netVM and firewallVM (in hvm and pvh do not started).

Looks like i will back to R3.2 as R4.0 is useless for me with no internet in appVM's.

[Sergio Matta]

sorry about write qvm-ls, is qvm-prefs, I was sleeping. Now you need to:
1-keep them PV;
2-chmod +x /rw/config/rc.local in sys-firewall and sys-net;
3-In sys-net /rw/config/rc.local insert:
ip link set vif3.0 up
ip addr add [sys-net ip, something like 10.137.0.5]/255.255.255.255 dev vif3.0
ip route add [sys-firewall ip, something like 10.137.0.6]/255.255.255.255 dev vif3.0
4-In sys-firewall /rw/config/rc.local insert:
ip link set vif4.0 up
ip addr add [sys-firewall ip, something like 10.137.0.6]/255.255.255.255 dev vif4.0
ip route add [vm to route ip, something like 10.137.0.9]/255.255.255.255 dev vif4.0
you should repeat the item 4 increasing the vif and changing the ip to support other vms.
It will run, not easy. You may consider buy a iommu motherboard.

[Qubes Guy]

I don't know if this is helpful, but I get Internet via a USB-to-Ethernet adapter. I have that (and all of my other USB devices) connected to a single internal USB controller connected to the sys-usb VM. sys-usb is an HVM (with network-manager in the Services tab). sys-net is connected to sys-usb, and it's a PVH (with meminfo-writer, clocksync and qubes-updates-proxy in its Services tab). sys-firewall is connected to sys-net, and it's also a PVH (with no services in the Services tab). Of course, sys-usb was flagged as providing networks services when it was created. Hope that helps...

[john]

On 05/12/18 19:46, Qubes Guy wrote:

> On Saturday, May 12, 2018 at 4:28:56 AM UTC-4, niepo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>> On Friday, May 11, 2018 at 3:17:05 PM UTC-4, Qubes Guy wrote:

>>> On Friday, May 11, 2018 at 1:17:24 PM UTC, niepo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>>>> Fresh install of Qubes R4.0 and there is no internet connection in appVM - firefox just not load websites.
>>>>
>>>> Internet connection actually is ok as I'm able to make update for template VM.
>>>>
>>>> What can be reason of this not working internet in app VM and how resolve this?
>>>
>>> Is this still a problem? Did you give your AppVM access to the net VM (set "Networking" to sys-firewall (preferably) or sys-net in the settings dialog for the AppVM)?
>>
>> Yes, problem still exist.
>>
>> There was sys-firewall connected to appVM as well sys-net and no connection.
>> I have also tried changing template from fedora to debian -internet not working.
>> I have also install chromium browser and connection not working.
>>
>> Very frustrating situation...
>
> One thing I forgot to mention: Do NOT set the "Networking" setting in your template VMs (set it to "None"). Giving network access to your templates is considered a major security threat (since all AppVMs you base on them inherit any malware/corruption). If you put "qubes-updates-proxy" in the services tab of sys-net, you won't need to do this. If you absolutely need to do this anyway, turn it off as soon as possible...
>

When I look at the qubes settings -> services in sys-net I see nothing
, would adding qubes-updates-proxy allow me to install manually
software I want to be AppVM-wide , in the Fedora Template?

or exactly how is one Supposed to ever add software to a Template if
there is no networking except for updates ?

Or lets say I add the qubes-updates-proxy to sys-net , then in the
Template can I just sudo dnf install <package> or there more to it ?

[Qubes Guy]

I couldn't get any template VMs to update (or be able to install software in them) until I put qubes-updates-proxy in sys-net. Apparently, that's how template VMs gain network access securely. The documentation implies says that this is already enabled by default (meaning I shouldn't have had to add it myself), but that wasn't the case, at least for me. The minute I put it in, the floodgates opened and I've been able to use Qubes ever since. The only downside to this is that this doesn't work for Firefox unless you install it through the standard repository. I couldn't get Quantum that way, so I had to manually install it in the template. And every time Firefox auto-updates itself, it's in the AppVM and the update disappears every time I restart the AppVM. So I'm currently enabling network access in the template VM only long enough to allow Firefox to update itself. I shouldn't, but I am. I understand that Mozilla is now calling Quantum "Firefox ESR" now (Extended Support Release). ESR version 52 was the only version in the Debian repository at the time, so I didn't want it. But if the Debian folks put Quantum in the repository, I'll switch over. If you can get Quantum from Fedora's repository (or however), then just ignore all that :)

[awokd]

On Mon, May 14, 2018 7:43 pm, Sergio Matta wrote:
> Em segunda-feira, 14 de maio de 2018 13:55:51 UTC-3, niepo...@gmail.com
> escreveu:

>> appVM's are not restored. All is default except I changed to pv mode
>> netVM and firewallVM (in hvm and pvh do not started).
>>
>> Looks like i will back to R3.2 as R4.0 is useless for me with no
>> internet in appVM's.
>
> sorry about write qvm-ls, is qvm-prefs, I was sleeping. Now you need to:
> 1-keep them PV;
> 2-chmod +x /rw/config/rc.local in sys-firewall and sys-net;
> 3-In sys-net /rw/config/rc.local insert:
> ip link set vif3.0 up
> ip addr add [sys-net ip, something like 10.137.0.5]/255.255.255.255 dev
> vif3.0
> ip route add [sys-firewall ip, something like 10.137.0.6]/255.255.255.255
> dev vif3.0
> 4-In sys-firewall /rw/config/rc.local insert:
> ip link set vif4.0 up
> ip addr add [sys-firewall ip, something like 10.137.0.6]/255.255.255.255
> dev vif4.0
> ip route add [vm to route ip, something like 10.137.0.9]/255.255.255.255
> dev vif4.0
> you should repeat the item 4 increasing the vif and changing the ip to
> support other vms.
> It will run, not easy. You may consider buy a iommu motherboard.

Sergio, are you saying if you change sys-net and sys-firewall to PV mode,
it breaks the network configuration so you have to set up manually? That
doesn't sound intentional, I wonder if there's a bug (but R4.0 really
requires the ability to run HVM/PVH mode to be safest).

[Sergio Matta]

Yes. I don't think it as a bug. Qubes V4 demands iommu. Without it you can use only PV or HVM. So PV was abandoned, PVH is programmed.
The little I read about Xen says Xen creates virtual connections, when needed. With "ifconfig -a" he can see the correct vif and create the route. Some programming can be done, but I think is better change the motherboard. :-)

[awokd]

I know PV is not recommended, but thought it was still supported under
R4.0 and Xen? If so, networking should work too, but you're right- it
won't be a priority.

[Sergio Matta]

> I know PV is not recommended, but thought it was still supported under
> R4.0 and Xen? If so, networking should work too, but you're right- it
> won't be a priority.

PV is still supported by Xen. It will works fine after he create the routes. I agree there is not enough people using PV to be prioritized.