Launching Mullvad Browser from mullvad-dvm → dispVM launches → enter account number in app → update required on Browser → download and restart Browser → qube shutdown, does not restart.
Update in template, all good. Stupid of me. (Update Mullvad extension too). Still manual re-entry of account number, still creation of new device on Mullvad app (that will have to be deleted later). Are my expectations simply too high?
Qubes question: Surprised actually that the template has what seems to be full access to the web. I thought templates were special and restricted? Is that different here in this setup specifically or is that because its a named dvm template?
You havent yet told me what version of the 3isec package you have installed.
I cant replicate your inability to run the browser.
Can you confirm that you have the Mullvad browser installed in the
disposable template?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Here’s notes for future readers and some questions:
Update by Qubes Updater immediately post-install
for mullvad-dvm disposable
Update browser in mullvad-dvm template. Update Mullvad extension too.
Account number and settings (<- ?) will not be recalled for each instance of mullvad-dvm dispVM.
Each login creates a new device on your Mullvad account. They build up, so they will have to be deleted/logged out of later (easy in the app, apparently not so in the cli). Tip - learn the names of your other existing devices so you don’t accidentally log them out.
For sys-mullvad service as netVM
Currently, I cannot get this to work on my system. Tried several approaches, using Mullvad cli and the app.
sys-mullvad has no memory of previous settings, no autostart of app.
template-mullvad > $ /opt/'Mullvad VPN/mullvad-gui launches app, but can’t log in so no settings are available (autostart). Didn’t bother trying with cli.
even when app or cli used to manually log in to Mullvad on sys-mullvad, client AppVMs aren’t connecting to anything.
I thought of perhaps putting something in rc.local, but I see there are issues there that I do not understand and don’t want to screw with.
If there are instructions for this, can I suggest they are placed in the description for this package in Qubes Task Manager? Right now, I don’t know where to look.
Notes on user experience
After a couple of hours of experimentation, I’ve had to kill the mullvad-vpn dispVM a few times now. The browser seems to place a really high CPU and memory demand and freezes. Are the default settings adequate for this qube?
Video playback is a challenge (although may be a problem with NoScript and uBlockOrigin settings), but e.g. youtube has no sound. I think this is currently the same in TorBrowser in Qubes (known issue).
Qubes question: Surprised actually that the template has what seems to be full access to the web. I thought templates were special and restricted? Is that different here in this setup specifically or is that because its a named dvm template?
Thanks - other users dont report your issues with that package.
I’ll push an updated version shortly with increased memory and an
updated Browser version.
This is to be expected, because the browser is installed from a tar
archive, not from a deb package.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
That is because they are disposables - any settings you put here
will be lost when you close the disposable. That’s how disposables work.
This is called out in the package description.
The lack of autostart is by design, and at user request.
I could change this.
I cant replicate the failure to connect from client qubes.
Can you confirm how you installed the package?
If you set the netvm of a qube to sys-mullvad, can you access a site by
IP? https://195.10.223.181 should redirect to https://qubes.3isec.org
If you see the redirect but the page doesnt load then you have DNS
issue. If you dont see the redirect then there is general connectivity
issue.
You might want to use it in AppVMs rather than the template.
Perhaps not, although other users havent reported this. I’ll push up the
maxmem in the next version.
I expected to find evidence of extracted files from the tar archive in /home/user/mullvad-browser/ and /etc/skel/Downloads/, but neither folder exists. Is there a discrepancy in the browser.sls minion file that could be causing this? The tar file names differ between lines 4 and 12 (below copied from updated file on github):
You are looking in the wrong place. mullvad/browser.sls is used to copy the browser tar file to /etc/skel/Downloads/ in the template, and extract it to /etc/skel.
(The name change is not a typo - it was user request.)
This happens automatically when the package is installed, because the
post install commands include: qubesctl --skip-dom0 --targets=template-mullvad state.apply mullvad.browser
When a qube is created using that template the file is in /home/user/Downloads, and the mullvad-browser directory is in /home/user.
Both sys-mullvad and the mullvad disposable template are created after
the template configuration, so will inherit those files.
Check in template-mullvad - are the files present in /etc/skel/?
Create a new qube using template-mullvad as template - does it have
the files in /home/user?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
/etc/skel/ in template-mullvad is empty aside from the hidden files and folders. In particular, the Downloads folder is missing from there.
Likewise in the new qube formed from template-mullvad. /home/user/Dowloads/ is empty and /home/user/mullvad-browser does not exist.
If it’s not in /etc/skel in the template it wont appear in /home/user in
newly created qubes.
I’m still not clear why this did not work for you, when it has worked
for other users.
Can you confirm what template is used by default-mgmt-dvm qube?
Could you also run this command in dom0: sudo qubesctl --skip-dom0 --show-output --targets=template-mullvad state.apply mullvad.browser
This is the salt that should be run to copy the browser tarfile in to the
template, and extract the files. Running with --show-output will help
identify what is going wrong in your case.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
indeed, my mistake, thanks for your patience. out of 7 states run, only the first 2 failed:
ID: /etc/skel/Downloads/mullvad_browser-linux-x86_64-13.0.10.tar.xz
Function: file.managed
Result: False
Comment: Unable to manage file: none of the specified sources were found
ID: mullvad-browser-linux-x86_64-13.0.10.tar.xz
Function: archive.extracted
Name: /etc/skel
Result: False
Comment: Source file '/etc/skel/Downloads/mullvad_browser-linux-x86_64-13.0.10.tar.xz' does not exist
Note that the tar archive was downloaded into /srv/salt/mullvad/, not into /etc/skel/
Definitely a general connectivity issue, then - data not passing between qubes? IP doesn’t resolve in browser either. Can’t ping your IP or sitename (by design?) but can ping 8.8.8.8 and google.com. I had problems with other ways of connecting to Mullvad too - maybe that MTU thing. Have to investigate.
Secondly, a script that ran to logout automatically as part of qube shutdown procedures would be nice. Not sure if possible.
I’m not sure what the logic is there. With my use case, I want as minimal interaction with the qube as possible - I want it to launch and sit there doing its thing (connectivity) just like sys-firewall does, without input.
What I want is the disposable sys-mullvad remember my account settings. It would either remember device identity (for Mullvad’s count) or, more sanitarily, that auto-logout feature ^ would ensure it closes cleanly and doesn’t clog up Mullvad’s system.
Multiple accounts or location settings could be managed by cloning the qube and altering them individulally (e.g. personal-vm automatically launches a disposable Sweden-sys-mullvad, work-vm launches a disposable London-sys-mullvad and so-on).
I can’t play around with this until I solve that basic connectivity issue and my skills are limited anyway. At the moment I have some high work demands, but I remain interested.
Here’s a Qubes question: how can I tell if a running qube is a named disposable or a regular ‘remembered’ qube? (e.g. I can’t tell by looking at Qubes Domains that sys-firewall is disposable, but it is because that’s how I installed it).
I have had to close a qube without logging out of Mullvad - so I will have to delete an extra device later - because I couldn’t figure out which icon it was.
To be clear:
launch 2+ disp-mullvad or sys-mullvad qubes with Mullvad app run in each of them
minimize app windows to icon in system tray.
attempt to close one disp-mullvad instance
try to figure out which green padlock is which in system tray and fail
There is the problem.
There should be a file: /srv/salt/mullvad/mullvad-browser-linux-x86_64-13.0.10.tar.xz
It is included in the rpm file, and is extracted to /srv/salt/mullvad/
It seems that your download of the rpm file failed. I suggest that you
remove the package and reinstall.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I havent had reports of this - I could set the MTU by default, but it’s
better at high values. It’s only necessary to change it for some mobile
networks, and it is called out in the Mullvad docs.
5 it is.
I’ll look at the possibility of a logout script.
Different use cases. I understand yours. But the spec was for the VPN to not start automatically, but require user login. (Many users have
sys-net not starting automatically, and require manual login.)
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.