Changing netVM while appVM running disables networking

[flamsmark]

Qubes OS version (e.g., R3.1):

R3.2

---

Expected behavior:

Changing an appVM's netVM while the appVM is running results in the appVM's traffic passing through the new netVM. If an appVM's netVM cannot be changed while the appVM is running, the options in the Qubes VM Manager are marked with a red asterisk and greyed out.

Actual behavior:

After changing an appVM's netVM, the appVM can no longer access the network.

Steps to reproduce the behavior:

Change an appVM's netVM while the appVM is running, either through the Qubes VM Manager or qvm-prefs.

General notes:

The documentation generally seems to indicate that this should work without the need for any user configuration or tweaking, but both @micahflee experience it.

[entr0py]

Sounds to me like this might be a template-specific issue. Which template was your appVM based on?

This works as expected for me when using Whonix-Workstation. Oops, I'm on 3.1 so can't speak for 3.2.

[entr0py]

Sounds to me like this might be a template-specific issue. Which template was your appVM based on?

This works as expected for me when using Whonix-Workstation. Oops, I'm on 3.1 so can't speak for 3.2.

[andrewdavidwong]

Yes, details about the type of TemplateVM and also the kinds of NetVMs would help. (For example, you might encounter problems switching to/from VPN and Tor ProxyVMs that you wouldn't experience when switching to/from ordinary clearnet ProxyVMs.)

[andrewdavidwong]

Yes, details about the type of TemplateVM and also the kinds of NetVMs would help. (For example, you might encounter problems switching to/from VPN and Tor ProxyVMs that you wouldn't experience when switching to/from ordinary clearnet ProxyVMs.)

[unman]

3.2 vanilla. Various templates - Debian8, Debian-9, fed23 - don't observe this behaviour. Simply works with new netvm without reconfiguration

[unman]

3.2 vanilla. Various templates - Debian8, Debian-9, fed23 - don't observe this behaviour. Simply works with new netvm without reconfiguration

[andrewdavidwong]

I suspect this might be a VPN or Tor ProxyVM. Can you confirm or deny my suspicion, @flamsmark?

[andrewdavidwong]

I suspect this might be a VPN or Tor ProxyVM. Can you confirm or deny my suspicion, @flamsmark?

[flamsmark]

This issue happens for every combination of AppVM (Fedora 23, Debian 8 & 9) and NetVM (directly using the Firewall VM, a VPN VM a Tor proxy VM…). There is no combination which works for me — even if my nextVM crashes and I try to reconnect it, no dice.

[flamsmark]

This issue happens for every combination of AppVM (Fedora 23, Debian 8 & 9) and NetVM (directly using the Firewall VM, a VPN VM a Tor proxy VM…). There is no combination which works for me — even if my nextVM crashes and I try to reconnect it, no dice.

[unman]

@flamsmark Can you use default netvm sys-firewall and one connected template based qube,(preferably both on 3.2 vanilla templates.)

It would be helpful if you could gather some output on the netvm and qube about iptables, ip information and routing. Then make the change to another standard netvm, and gather the same information on qube and new netvm: don't forget to include nat and raw tables on the netvm.
Then post the results.

[unman]

@flamsmark Can you use default netvm sys-firewall and one connected template based qube,(preferably both on 3.2 vanilla templates.)

It would be helpful if you could gather some output on the netvm and qube about iptables, ip information and routing. Then make the change to another standard netvm, and gather the same information on qube and new netvm: don't forget to include nat and raw tables on the netvm.
Then post the results.

[unman]

@flamsmark Have you been able to perform those tests? Can you confirm you still see the problem and post the outputs I requested?

[unman]

@flamsmark Have you been able to perform those tests? Can you confirm you still see the problem and post the outputs I requested?

[andrewdavidwong]

Closing due to lack of response.

[andrewdavidwong]

Closing due to lack of response.