After some help, I have set it to remember my account number, device name and connection status with the Mullvad App autolaunching at startup.
My objective is to have a mullvad-i, mullvad-ii and mullvad-iii, each with the same account number but different exit points, serving different qubes (e.g. workVM → mullvad-ii exiting in e.g. New York → sys-firewall → sys-net → world).
(Eventually I want the mullvad-x qubes to be named disposables, but it looks like I need to tackle this step-by-step).
Within mullvad-i, Mullvad Browser works fine. Its not quick, but it works.
However, even though the provides network to other qubes option is definitely checked in Settings, it lists in Q menu > Service and I can set another AppVM to use it as network, its not working:
There is no connectivity in the AppVM Firefox
ping 8.8.8.8 works
I have had problems with MTU before, but setting MTU to other values (as per here) has no effect, although it is currently working for other qubes using the original sys-mullvad.
I joined another qube (personal) to the mullvad-i. It fails to work.
Normally that qube uses the original sys-mullvad for netVM, as per unman’s design. It already has MTU=1380 set.
I rejoined personal to sys-mullvad, and it still failed. Turns out Mullvad had logged out the sys-mullvad app. I had to log it in again. Then pages loaded.
Then tried personal again on mullvad-i. It failed. Ranged up and down MTU values, from 500-1380. Nothing works.
Meanwhile, the AppVM I have just got working (above) with mullvad-i continues to work fine.
It seems really inconsistent. There’s another process that must be going on.
What’s odd is that I dont have these issues. Have you logged out and
logged back in to Mullvad to create a new device?
Cloning sys-mullvad seems to work for me, and I dont have reports from
other users of the issues you see.
It could be selection of endpoint, protocol, or effects of MTU.
If you create a new device on the clone and attach to the same
endpoint, do you have issues then?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Definitely created new devices on Mullvad. That’s quite transparent on the app (e.g. Awkward Aardvark, etc)
I am going to have to step away from the machine for several hours soon, but here are a couple of ‘niggling thoughts’ about how this machine might be a bit different.
its second hand hardware, and it was treated harshly. I refurbished it as best I could, but I have always wondered if something somewhere on the motherboard was slightly damaged.
I have had strange issues/glitches with earlier versions of Qubes (years ago and I can’t remember the details). Each new version - and a new SSD - brought less of that kind of weirdness.
my internet is a cellular hotspot. I think that’s why I need to adjust the MTU.
Recently I booted this machine into other live distros, including a couple of rescue systems. In subsequent Qubes-boots, I’ve noticed that I have at least one corrupted qube (I get a message about not reaching the kernel or something). I suspect one of the rescue distros made changes on the SSD.
my computing knowledge remains fairly low, so that’s always been the more likely explanation for divergent system behavior.
After a reboot, there is significantly better behavior from mullvad-i, i.e. it just works.
However, a clone of mullvad-i, mullvad-ii, doesn’t seem to work with a fresh dispVM set netVM->mullvad-ii’. It logs in (I think I logged it out in a different VM), but connectivity fails in the client dispVM. Playing with MTU values doesn’t work.