Mullvad Browser has released package repos for Debian and Fedora

Source: Mullvad Browser 13.5 released with letterboxing improvements and new installation options

Source Tor: http://o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiad.onion/en/blog/2024/6/26/mullvad-browser-135-released-with-letterboxing-improvements-and-new-installation-options

By adding their debian repo to your apt-sources, you can manage the installation of mullvad browser on the debian/fedora template. Easily install and easily upgrade to the latest version. And have mullvad browser become available on the disposable templates. This new installation option for mullvad should simplify the myriad of threads we had on “how to run mullvad browser in disposable qubes?”

EDIT: Find my installation guide here: Mullvad Browser has released package repos for Debian and Fedora - #5 by tanky0u

10 Likes

I tried following their instructions in Debian and got

curl: (6) could not resolve host: repository.mullvad.net

1 Like

I suppose you’re trying to download the signing key?

You can use curl --proxy http://127.0.0.1:8082/ ... instead, download the file with a disposable and copy it to your template, etc.

2 Likes

That’s what i waited for. Hopefully this works flawlessly with AppVMs.

1 Like

Here’s my notes on installation:

Mullvad Browser Install Guide

1. Start a new whonix disposable qube, and open the terminal in there:

scurl-download https://repository.mullvad.net/deb/mullvad-keyring.asc

2. Move the signing key to the debian-12-xfce

qvm-move-to-vm debian-12-xfce mullvad-keyring.asc

3. Open the debian-12-xfce terminal

Move the mullvad-keyring.asc file to its proper place:

sudo mv ~/QubesIncoming/disp*/mullvad-keyring.asc /usr/share/keyrings/

Fix the user:group of the keyring file:

sudo chown root:root /usr/share/keyrings/mullvad-keyring.asc

Add the mullvad’s apt repo link to your apt sources:

echo "deb [signed-by=/usr/share/keyrings/mullvad-keyring.asc arch=$( dpkg --print-architecture )] https://repository.mullvad.net/deb/stable $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mullvad.list

Now install the mullvad-browser:

sudo apt update
sudo apt install mullvad-browser

Shutdown the debian-12-xfce qube. This completes the mullvad-browser
installation part. You will have mullvad-browser in your Application
shortcuts window in the qubes settings for your individual qubes.

4. Setup mullvad-browser for debian-12-xfce disposableVM

In its current default settings, mullvad-browser.desktop file contains
on its Exec lines, the flag --detach, which causes the shell
process that spawns the mullvad-browser to exit. This causes
mullvad-browser to fail stay opened inside dispXXXX qubes, as the
shell process exiting causes the dispXXXX qube to also shut itself
down. So, you need to remove the --detach flag from the
mullvad-browser.desktop file.

OR, you can copy the existing file, and rename it to
mullvad-browser-disposable.desktop file, and add THAT to your
disposable qubes’ application list, spawn it with the keypress, etc.

Open the debian-12-xfce qube. On its terminal:

sudo cp /usr/share/applications/mullvad-browser.desktop /usr/share/applications/mullvad-browser-disposable.desktop
sudoedit /usr/share/applications/mullvad-browser-disposable.desktop

Remove the --detach flag from Exec and
X-MullvadBrowser-ExecShell lines. Add a %u to the Exec lines, so
you have the followings:

Exec=/usr/lib/mullvad-browser/start-mullvad-browser %u
X-MullvadBrowser-ExecShell=/usr/lib/mullvad-browser/start-mullvad-browser %u

The start-mullvad-browser script should be able to pass the URL
arguments that might come with %u correctly to the mullvad-browser
executable.

Also, change the Name and GenericName lines on the same file, so that
you can distinguish between normal mullvad browser and the disposable one:

Name=Mullvad Browser (Disposable)
GenericName=Web Browser (Disposable)

Save the file and exit. Shut down the debian-12-xfce qube.

Open the Qube Manager window. Find the default-dvm qube, and press
Settings. Go to Applications tab, and press Refresh applications button. Then, you should see the Mullvad Browser (Disposable) option on the All Available Applications column. Move
that to the right hand column. Apply and OK. From now on, you can
run the Qubes Applications Menu > default-dvm > Mullvad Browser
(Disposable) and you will have a new Mullvad Browser inside the
disposable qube.


If this was helpful, send me some tip!

xmr:85BsYQLX9RZGWrhXjErQg9VNpwCq7tpi4eSjR2MAbywBNKVxEd1aUEyHpZ5pFjfNaHie5xdLF5XbdjSTDuPDRESZ42V7CMC
6 Likes

This doesnt work, followed all the commands and getting errors

Why don’t you post the error message? It’s like you don’t want help or something.

Apologies I hadn’t finished writing and accidentally submitted when I reattempted again.

The issue I think im facing is that there is no Debian Disposable AppVM on my Qubes, I can get all this working on debian-12-xfce which the the TemplateVM but what am I using the the Debian disposable VM?

Thanks heaps

Do you have fedora as the default VM choice? I have never enabled fedora VMs in my QubesOS installs, so I don’t understand why you might not have a debian-12-xfce disposableVM.

Yes thats correct, Fedora is the default VM choice for this setup. I have a debian-12-xfce which is a templateVM however not a debian-12-xfce-disposableVM.

Do you know how I can achieve this either by installing on fedora or installing a new debian-12-xfce-disposableVM cube?

Thanks

You should mirror my instructions for debian to fedora template. I am not familiar with how fedora does package repo stuff, so, I hope someone else helps you. OR, copy-paste my guide into chatgpt and ask it to rewrite it for a fedora template.

Okay sounds good man, thanks heaps.

Was wondering if there is a way to install mullvad browser inside a disposable whonix workstation, not entire sure how that would work though as it gets through Tor or if it would de-anonymize you

I don’t think you should do that. Just use Tor Browser inside Whonix qubes.

Thanks for the guide, imho way better than the method on the mullvad page regardings updates… Buy I think the guide is a bit misleading… I wouldn’t modify the standard template and instead clone it first to lets call it debian-12-xfce-mullvad-browser, then install Mullvad Browser there, create a AppVM from it and make it a disposable template… But anyway great tutorial, using it right now!

1 Like

I can’t find my application folder in fedora 41…
/home/user/.local/share/
I don’t have an folder named application in this folder so i can’t find the .desktop to change the Exec line.
I had made this with fedora 40 in the past but i don’t get it this time…

Thx for your help.

Create the directory applications (plural) in /home/user/.local/share/

So i have to create the .desktop myself ?
I don’t remember any of that when i setup it the first time so sorry i am a bit lost.

EDIT: Forget what i say

Form Fedora 41 users

In 4. Setup mullvad-browser for debian-12-xfce disposableVM

Open the Fedora-41-disposable-Template :

sudo cp /usr/share/applications/mullvad-browser.desktop /usr/local/share/applications
sudoedit /usr/local/share/applications/mullvad-browser.desktop

You just have to remove the --detach flag form the Exec line, so you have the following:

sudo cp /usr/share/applications/mullvad-browser.desktop /usr/local/share/applications

The following is more or less the same as the debian version.

Feel free to correct me.

1 Like

It appears I have a perplexing issue where my Mullvad VPN disposable and template qubes function flawlessly on my Kaby Lake Qubes 4.2 installation, yet utterly refuse to respond to ARP requests on my Raptor Lake 4.2 setup. After thoroughly testing with backup (from Kaby Lake), copy, and restore (to Raptor Lake) operations, the problem persists, crippling the VPN qube’s network connections upon executing the mullvad connect command. The peculiarity here lies in the identical configuration of both systems’ dom0 environments - a situation that might necessitate reinstalling Qubes on a USB drive to isolate the issue.

On my Kaby Lake setup, VPN qubes only sporadically generate or receive ARP requests from their immediate neighbors, whereas on the Raptor Lake system, these qubes are flooded with unanswered ARPs from both end-neighboring nodes and VPN tunnels collapse almost instantly after establishment. It’s as if I’ve encountered a situation where the very same setup works one moment, and then fails catastrophically when transferred to another machine - a Kaby Lake working, backed up, copied, restored on Raptor Lake now not functioning at all.

Apologies for my self-reply faux pas;

Here is the problem as succinctly stated: my Mullvad VPN disposable and template qubes function flawlessly on my Kaby Lake (20TK) Qubes 4.2 setup, whereas they utterly refuse to respond to ARP requests on my Raptor Lake (21FA) 4.2 installation. This debilitating misbehavior manifests itself even after a complete backup, copy, and restoration of the system, thereby ruling out any possibility of user error or configuration discrepancies.

The two systems in question share identical dom0 environments, which I shall reconfirm with a fresh install on a USB drive if necessary. However, there exists a stark contrast between their behaviors: Kaby Lake VPN qubes exhibit a paucity of ARP requests to and from neighboring devices, whereas Raptor Lake VPN qubes are beset by an avalanche of unanswered ARPs from both ends, resulting in the collapse of VPN tunnels mere seconds after establishment.

Needless to say, this conundrum has me stumped: my VPN scheme behaves perfectly on the Kaby Lake, until I perform a backup, copy, and restore operation to the Raptor Lake, at which point it suddenly ceases to function. Why does this phenomenon occur? What hidden factor could be contributing to this discrepancy?

1 Like