Multiple Whonix-Workstations


Whonix is a secure operating system comprised of two virtual machines which are isolated both from each other and the host. This configuration averts many threats posed by malware, misbehaving applications, and user error. While Whonix protects against real world threats, [1] it still possible for skilled adversaries to compromise Whonix-Workstation (Qubes-Whonix: anon-whonix).

If only one Whonix-Workstation is used for anonymous activities and is exploited, the attacker gains access to available data and can monitor all online activity. To minimize the impact of a compromise, users are encouraged to use multiple Whonix-Workstations to compartmentalize different identities and/or additional software. Depending on the user's preference and requirements, a second, third ... nth Whonix-Workstation VM can be created.

Multiple Whonix-Workstation Rationale[edit]

Different torifed clients can be used in a completely isolated manner with Multiple Whonix-Workstations. By compartmentalizing each different identity or client, an attacker can only read the data in the compromised VM. For example, if Tor Browser in VM-1 was compromised it could not read a user's IRC identity in VM-2. [2]

One downside of this approach is that if the host Internet connection goes offline or Tor on Whonix-Gateway (sys-whonix) suddenly fails, then all Whonix-Workstations will go offline simultaneously. If multiple Tor clients were running and abruptly stop in unison, a network observer could link these activities to the same person. For instance, a strong correlation is formed if two Tor users in one IRC channel go offline at exactly the same time.

Qubes-Whonix vs Non-Qubes-Whonix[edit]

When using multiple Whonix-Workstations, Qubes-Whonix is the recommended choice. This is because Qubes-Whonix is specifically designed for compartmentalization (a.k.a. sandboxing) of multiple running VMs. This provides a significant advantage in both speed and security compared to the traditional Type 2 hypervisor model, where two (or more) Whonix VMs are run inside programs like VirtualBox on top of the host OS. For more information, see: Type 1 vs Type 2 Hypervisors and Why use Qubes over other Virtualizers.

Qubes-Whonix also has a TemplateBased filesystem which saves time and provides much better usability compared to Non-Qubes-Whonix:

  • Centralized Updates: AppVMs are based on a TemplateVM. This means their root filesystem is based on the root filesystem of the corresponding template. Users need only update the TemplateVM and those updates will be reflected in the root filesystem of every TemplateBasedVM. Non-Qubes-Whonix users must spend more time in updating each VM individually.
  • Minimal Disk Usage: TemplateBasedVMs require far less disk space than traditional VMs, since the AppVM's root filesystem is based the corresponding template. The AppVM only requires enough disk space to hold user files in the /home directory.
  • VM Management: Cloning VMs is a simple two-step process which can be done in Qubes Manager. Non-Qubes-Whonix users must spend more time with a multi-step process to clone and configure each VM.

Safety Precautions[edit]

It is far safer to only use one Whonix-Workstation at any given time and for a single activity.

Leaving multiple Whonix-Workstations running at the same time introduces new risks. If one of the Whonix-Workstation VMs was compromised, it can perform various attacks and not all of them can be defeated. Depending on the activities a user was performing in other Whonix-Workstations, a skilled adversary could correlate the various running Whonix-Workstations to the same pseudonym.

Distributed Denial of Service (DDOS) Attack

  • Other Whonix-Workstations can be DDOSed, and there is no current defense.
  • Other Whonix-Gateways can be DDOSed, and there is no current defense.


  • Reduce the risk of exploits by following the recommendations found in the System Hardening Checklist.
  • The adversary could try to exploit the Whonix-Gateway.
  • The adversary could try to exploit other Whonix-Workstations.
    • Non-Qubes-Whonix: At risk.
    • Qubes-Whonix: Safe, unless Whonix-Gateway is compromised first. [3]

Identity Correlation through Circuit Sharing [4]

  • Non-Qubes-Whonix: This is not a threat so long as the Whonix-Workstations are not compromised. Multiple Whonix-Workstations using different internal IPs (as recommended in the instructions below) are automatically using Stream Isolation. [5]
  • Qubes-Whonix: No further action is necessary; see details in chapter #Firewall.


System Stressing

  • An adversary could stress any system, network or software components like CPU, HDD, RAM, network connection and other Whonix-Workstations. It is possible the host could be negatively affected as well.

How to use more than one Whonix-Workstation - EASY[edit]


Setting up additional Whonix-Workstations with Qubes-Whonix

Using multiple Whonix-Workstations within Qubes-Whonix is a simple process. To do this users can create an additional AppVM based upon the Whonix-Workstation template (commonly called whonix-ws-14) with its own distinctive name. After the new AppVM is created ensure that it uses sys-whonix as its NetVM.

To create new AppVM users need only follow this link for step-by-step instructions: Create Whonix Workstation AppVMs.


If you are interested in this with Non-Qubes-Whonix, please press on expand on the right.

Setting up additional Whonix-Workstations with download/default Whonix-Workstations

Non-Qubes-Whonix means all Whonix platforms except Qubes-Whonix. This includes KVM, VirtualBox and Physical Isolation. Only!

Each additional Whonix-Workstation VM that is set up requires its own MAC address and internal LAN IP address.

1. Clone a fresh Whonix-Workstation VM.


In VirtualBox Manager clone a clean Whonix-Workstation.


In Virtual Machine Manager clone a clean Whonix-Workstation.

Highlight Whonix-Workstation -> Open -> Virtual Machine -> Clone

2. Assign a new MAC address to the cloned VM.


In VirtualBox Manager assign a new MAC address:

VirtualBox -> Settings -> Network -> Adapter 1 -> Advanced -> Mac Address ->
Create a new MAC address (press the green round arrow icon) -> Ok.


To change the internal network in KVM. See: Creating Multiple Internal Networks

3. In Whonix-Workstation. Open /etc/network/interfaces.d/30_non-qubes-whonix in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /etc/network/interfaces.d/30_non-qubes-whonix

If you are using a terminal-only Whonix, run.

sudo nano /etc/network/interfaces.d/30_non-qubes-whonix

Change the last octet. For example to

4. Save and Exit.

5. In Whonix-Workstation, reboot. Or alternately restart the network.

sudo service networking restart

6. Done.

How to use more than one Whonix-Workstation - More Security[edit]

Multiple Whonix-Gateways[edit]


Advanced users only.

Multiple Whonix-Gateways can be used along side multiple Whonix-Workstations, however this has both advantages and disadvantages. This setup is more secure since the Whonix-Gateway VMs are isolated from each other. In the event that one Whonix-Gateway is compromised, it is not certain the other(s) will be compromised as well. However, the newly cloned Whonix-Gateway(s) will end up with a different set of Tor entry guards unless precautions are taken. [8] [9]

Be aware that in this configuration ISPs can likely guess that two different Tor data folders are in use, but this is not necessarily an anonymity threat. Similarly, if multiple Tor Browsers are used with distinct Whonix-Gateways, the user will end up with different sets of Tor entry guards as well (unless the same Tor guards are chosen for different Whonix-Gateways by chance).


Setting up additional Whonix-Gateways (commonly called sys-whonix) with Qubes-Whonix

The only requirement for a newly created sys-whonix is it must be based on whonix-gw-14 TemplateVM and given a distinctive VM name.

1. Create a new sys-whonix VM.

Users can create a new sys-whonix ProxyVM by following the step-by-step directions: Create Gateway ProxyVMs.


If you are interested in this with Non-Qubes-Whonix, please press on expand on the right.


When using multiple Whonix-Gateway VMs at the same time, the risks explained in the introduction chapter on this page apply.

Setting up additional Whonix-Workstations with download/default Whonix-Workstations

Non-Qubes-Whonix means all Whonix platforms except Qubes-Whonix. This includes KVM, VirtualBox and Physical Isolation.


In this case, you also have to change Whonix-Gateway network interface2 and Whonix-Workstation network interface1 from internal network "Whonix" to something else.


See Multiple Whonix-Gateways.

Multiple Qubes-Whonix TemplateVMs[edit]

Multiple Qubes-Whonix TemplateVMs provides much greater flexibility over a single template when choosing software packages. The additional cloned templates can be customized with software to meet specific requirements which would not be possible if a single TemplateVM was used.[10]

  • Packages from a later release - Installing packages from a later release could end up breaking the system. For example, mixing packages from Debian Stable with those from a later release like Debian Testing can lead to a destabilized system due to associated software dependencies required for full functionality.[11][12]Prior to installing Debian packages from a later release, first read #Install from Debian testing.
  • Custom software - With additional cloned templates users can install custom software used for a specific application. For example, users can Tunnel UDP over Tor by configuring whonix-ws-14 to route all applications through a VPN tunnel. However, this method has the disadvantage of increasing the risk of identity correlation. To limit this risk, the AppVM based on this template should only be used for the particular application that a users needs to route through the tunnel-link. Before installing custom software users are encouraged to read Install Software General Advice
  • Untrusted packages - Users should not install untrusted packages in a template used for sensitive activities. With multiple cloned TemplateVMs, a single template can be designated as a less trusted domain in which to install those packages.[13] Read Notes on trusting your TemplateVM(s) prior to installing untrusted packages.

Cloning TemplateVMs[edit]

Cloning templates in Qubes-Whonix is a simple and process that can be accomplished by using Qubes Manager. However, care should be excersized when choosing names for both TemplateVMs and the AppVM based on those templates. The newly cloned TemplateVMs should be given names that are not easily confused for other TemplatesVMs. This will minimize the chances of a user basing an AppVM on the wrong template.[15] When creating AppVMs based on cloned TemplateVMs, a purpose-based naming convention should be used so there is no ambiguity as to the intended use of an AppVM. For example, if an AppVM is created to tunnel UDP over Tor, users would append tunnel-udp (the purpose) to the end of anon-whonix which would create the name anon-whonix-tunnel-udp.

Users can clone Qubes-Whonix TemplateVMs by following the instructions to: Clone Qubes VMs


  1. Read Security in the Real World to see how Whonix protects against real world attacks.
  2. Without using an additional exploit to successfully break out of the infected VM, which is a difficult task.
  3. For details, see #Firewall.
  4. See the Stream Isolation page for a definition.
  5. Because IsolateClientAddr is Tor's default.
  6. Like a man-in-the-middle attack or malicious gateway
  7. Because by Qubes default, AppVMs behind the same ProxyVM [or NetVM] are prevented from connecting to each other.
  8. Such as manually sharing your entry guards. Qube-Whonix users can copy the Tor state folder to another sys-whonix or use the same Bridges.
  9. Full instructions for all Non-Qubes-Whonix platforms is not available at present.
  10. Users may also wish to clone the default template and use the clone as default template for AppVMS. This ensures availability of a “known-good” backup template.
  11. Using packages from different repositories can lead to Dependence Hell
  12. This problem can be avoided by cloning additional Whonix templates and preferring packages from a single repository in each TemplateVM.
  13. Users are strongly encouraged to install only signed packages from a trusted source.
  14. This applies to all TemplateVMs regardless if they were cloned.
  15. There could be serious security concerns if a user based a trusted AppVM on the wrong template such as a TemplateVM with untrusted packages.

Random News:

Did you know that anyone can edit the Whonix wiki to improve it?

https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)