Last update: March 17, 2019. This website uses cookies. By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. More information


Multiple Whonix-Workstations

About this Multiple Whonix-Workstations Page
Support Status stable
Difficulty easy
Maintainer 0brand
Support Support


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 many real world threats, [1] it is still possible for skilled adversaries to compromise Whonix-Workstation (Qubes-Whonix: anon-whonix).

If a single Whonix-Workstation is used for all 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, it is recommended to utilize multiple Whonix-Workstations to compartmentalize different identities and/or additional software. Depending on individual preferences 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 disadvantage of this configuration 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]

Qubes-Whonix is the recommended choice for multiple Whonix-Workstations because it is specifically designed for compartmentalization (a.k.a. sandboxing) of multiple running VMs. This provides significant speed and security advantages relative 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 further 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 improves usability compared to Non-Qubes-Whonix:

  • Centralized Updates: AppVMs are based on the corresponding TemplateVM's root filesystem. After updating the TemplateVM, those same 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 on 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 Qube Manager. Non-Qubes-Whonix requires a multi-step process to clone and configure each VM.

Safety Precautions[edit]

It is safest to only use one Whonix-Workstation at a time and for a single activity. New risks are introduced by running multiple Whonix-Workstations at the same time. For instance, if a single Whonix-Workstation was compromised, it could potentially perform various side channel attacks to learn about running processes in other VMs, and not all of these can be defeated. Depending on user activities, a skilled adversary might be able to correlate multiple Whonix-Workstations to the same pseudonym.

Distributed Denial of Service (DDOS) Attack[edit]

If a Distributed Denial of Service (DDOS) Attack is launched from an infected Whonix VM, then:

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


Following infection, an adversary could try to exploit the Whonix-Gateway or other Whonix-Workstations:

  • Non-Qubes-Whonix: At risk.
  • Qubes-Whonix: Users are safe, unless Whonix-Gateway is compromised first. [3]

To minimize the threat of exploits it is recommended to apply relevant instructions found in the System Hardening Checklist.

Identity Correlation through Circuit Sharing[edit]

When different applications use the same Tor circuit and exit relay, these activities can be linked to the same pseudonym (see Stream Isolation for further details):

  • Non-Qubes-Whonix: This is not a threat so long as the Whonix-Workstations were not compromised. Multiple Whonix-Workstations which have different internal IPs configured (see the instructions further below) are automatically stream-isolated. [4]
  • Qubes-Whonix: No further action is necessary; see Firewall.


System Stressing[edit]

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

How-to: Use more than One Whonix-Workstation - EASY[edit]


Using multiple Whonix-Workstations is simple in Qubes-Whonix:

  1. Create an additional AppVM based on the Whonix-Workstation template (whonix-ws-14) and give it a distinctive name.
  2. Confirm the new AppVM is using sys-whonix as its NetVM.

If creating a new AppVM is unfamiliar, follow this link for step-by-step instructions: Create Whonix Workstation AppVMs.


If you are interested in this configuration, please press on Expand on the right.

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

1. Clone a fresh Whonix-Workstation VM.

  • VirtualBox: In VirtualBox Manager, clone a clean Whonix-Workstation.
  • KVM: 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.

  • VirtualBox: 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
  • KVM: To change the internal network in KVM, see: Creating Multiple Internal Networks.

3. Edit the network interfaces file 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 with KDE, run.

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

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

kdesudo mousepad /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, change to

Save and exit.

4. Reboot.

Reboot the Whonix-Workstation or alternately restart the network.

sudo service networking restart


How-to: Use more than One Whonix-Workstation - More Security[edit]

Multiple Whonix-Gateways[edit]


Multiple Whonix-Gateways can be used alongside multiple Whonix-Workstations, but this has both advantages and disadvantages. One security benefit is the isolation of separate Whonix-Gateway VM instances. In the event that one Whonix-Gateway is compromised, it is not certain the other(s) will be similarly compromised. On the downside, newly cloned Whonix-Gateway(s) will end up with a different set of Tor entry guards unless precautions are taken. [7] [8]

In this configuration ISPs are probably capable of detecting 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, then a different set of Tor entry guards will be used as well (unless by chance the same Tor guards are chosen for different Whonix-Gateways).


It is simple to create additional Whonix-Gateways (sys-whonix instances) in Qubes-Whonix; see Create Gateway ProxyVMs.

The only requirement is that the newly created sys-whonix is based on the whonix-gw-14 TemplateVM and has a distinctive VM name, so it is not confused with other VMs.


If you are interested in this configuration, please press on Expand on the right.


When multiple Whonix-Gateways are run in paralell, the risks explained in the Safety Precautions section equally apply.

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


In this case, it is necessary to change the 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; something impossible to achieve with a single TemplateVM. [9]

  • 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 of a later release like Debian Testing can lead to an unstable system because of associated software dependencies required for full functionality. [10] [11] Prior to installing Debian packages from a later release, first read Install from Debian testing.
  • Custom software: Additional cloned templates makes it easy to install custom software used for a specific application. For example, users could Tunnel UDP over Tor by configuring whonix-ws-14 to route all applications through a VPN tunnel. However, this method also increases the risk of identity correlation. To mitigate this risk, the AppVM based on this template should only be used for the particular application that must be routed through the tunnel-link. Before installing custom software it is recommended to first read Install Software General Advice.
  • Untrusted packages: It is unwise to 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 for that purpose. [12] Read Notes on trusting your TemplateVM(s) prior to installing untrusted packages.

Cloning TemplateVMs[edit]

Cloning templates in Qubes-Whonix is easily accomplished via Qube Manager. Be careful with naming conventions for both TemplateVMs and AppVMs (based on those templates) so they are not confused with each other. This will minimize the chance of basing an AppVM on the wrong template.

When creating AppVMs based on cloned TemplateVMs, a purpose-based naming convention is sensible so there is no ambiguity regarding the intended function of an AppVM. For example, if an AppVM is created to tunnel UDP over Tor, appending tunnel-udp (the purpose) to the end of anon-whonix would lead to the name anon-whonix-tunnel-udp.

To clone Qubes-Whonix TemplateVMs, follow the instructions below.

Cloning Qubes VMs is a simple process in Qube Manager:

Qube Manager -> VM to be Cloned -> Clone qube -> Enter name for Qube clone

Figure: Cloning Whonix qubes

When prompted, give the newly cloned VM a name that is not easily confused with other VMs. This minimizes the chances of basing an AppVM on the wrong template; there could be serious security concerns if a "trusted" AppVM was based on the wrong TemplateVM with untrusted packages.

Figure: Clone Re-naming
Screenshot Qubes-clone-vm add-name.png



If you like to change the UpdatesProxy setting for any TemplateVM, apply the following steps.

In dom0. Open /etc/qubes-rpc/policy/qubes.UpdatesProxy with root rights.

sudo nano /etc/qubes-rpc/policy/qubes.UpdatesProxy

TODO: the following requires testing

Add at the very top of that file.


name-of-template-vm $default allow,target=name-of-proxy-vm

For example:

whonix-ws-14-clone-1 $default allow,target=sys-whonix-cloned


<Ctrl-X> --> press Y --> <Enter>

The procedure is now complete


  1. See: Protection 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. Since IsolateClientAddr is the Tor default.
  5. Like a man-in-the-middle attack or malicious gateway.
  6. By default, AppVMs which are behind the same ProxyVM (or NetVM) are prevented from connecting to each other in Qubes.
  7. Such as manually configuring identical Tor entry guards. Qube-Whonix users can copy the Tor state folder to another sys-whonix instance or use the same Bridges.
  8. At present, full instructions are not available for every Non-Qubes-Whonix platform.
  9. Optionally, the default template can be cloned and used as the default template for AppVMs. Having a “known-good” backup template available at all times is best practice.
  10. Using packages from different repositories can lead to Dependency Hell.
  11. This problem can be avoided by cloning additional Whonix templates and preferring packages from a single repository in each TemplateVM.
  12. It is strongly encouraged to only install signed packages from a trusted source.
  13. This applies to all TemplateVMs, even if they were cloned.
  14. Since TemplateVMs in Qubes R4 and above are supposed to be upgraded through qrexec based Qubes updates proxy.
  15. Because /etc/qubes-rpc/policy/qubes.UpdatesProxy contains:
    $tag:whonix-updatevm $default allow,target=sys-whonix

    Note that policy parsing stops at the first match, [...]

No user support in comments. See Support.

Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.

Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.

Random News:

Check out the Whonix blog.

https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix is a trademark. Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix itself. (Why?)

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix is provided by ENCRYPTED SUPPORT LP. See Imprint.