|About this Multiple Whonix-Workstations Page|
- 1 Introduction
- 2 Safety Precautions
- 3 How-to: Use more than One Whonix-Workstation - EASY
- 4 Multiple Whonix-Gateways
- 5 Multiple Qubes-Whonix TemplateVMs
- 6 Footnotes
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,  it is still possible for skilled adversaries to compromise Whonix-Workstation (Qubes-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
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. 
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
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
- 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.
While multiple Whonix-Workstations are recommended, this is not an endorsement for using them simultaneously!
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
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. 
To minimize the threat of exploits it is recommended to apply relevant instructions found in the System Hardening Checklist.
Identity Correlation through Circuit Sharing
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. 
- Qubes-Whonix: No further action is necessary; see Firewall.
- Non-Qubes-Whonix: A defense against impersonation  of other Whonix-Workstations or the Whonix-Gateway can be implemented via authentication. This is outlined in the #How to use more than one Whonix-Workstation - More Security section below.
- Qubes-Whonix: No further defenses are required; see Firewall.
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
Using multiple Whonix-Workstations is simple in Qubes-Whonix:
- Create an additional AppVM based on the Whonix-Workstation template (
whonix-ws-14) and give it a distinctive name.
- Confirm the new AppVM is using
sys-whonixas 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.
Note: The following instructions only apply to Download/Default-Whonix-Workstations or Whonix VMs built from source code. To use another operating system like Windows, other GNU/Linux, BSD etc. please see the Other Operating Systems chapter instead.
Each additional Whonix-Workstation VM must have its own MAC address and internal LAN IP address.
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:
2. Assign a new MAC address to the cloned VM.
Note: A new MAC address is necessary if an additional VirtualBox VM is imported.
- VirtualBox: In VirtualBox Manager, assign a new MAC address:
Create a new MAC address (press the green round arrow icon)->
- 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.
Change the last octet. For example, change
Save and exit.
Reboot the Whonix-Workstation or alternately restart the network.
sudo service networking restart
How-to: Use more than One Whonix-Workstation - More Security
- Qubes-Whonix: This step can be skipped. 
- Non-Qubes-Whonix: See: Connections between Whonix-Gateway and Whonix-Workstation.
Advanced users only.
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.  
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).
Note: It is far safer and easier to manage multiple Whonix-Gateways when only one is launched for user activities, rather than running many in parallel.
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.
Note: These instructions only apply to Download/Default-Whonix-Workstations.
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.
Multiple Qubes-Whonix TemplateVMs
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. 
- 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.   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-14to 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.  Read Notes on trusting your TemplateVM(s) prior to installing untrusted packages.
Note: Each TemplatesVM's root filesystem runs independently from all other TemplateVMs.  Therefore, each individual TemplateVM must be updated separately.
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
To clone Qubes-Whonix TemplateVMs, follow the instructions below.
- See: Protection Against Real World Attacks.
- Without using an additional exploit to successfully break out of the infected VM, which is a difficult task.
- For details, see Firewall.
- Since IsolateClientAddr is the Tor default.
- Like a man-in-the-middle attack or malicious gateway.
- By default, AppVMs which are behind the same ProxyVM (or NetVM) are prevented from connecting to each other in Qubes.
- Such as manually configuring identical Tor entry guards. Qube-Whonix users can copy the Tor state folder to another
sys-whonixinstance or use the same Bridges.
- At present, full instructions are not available for every Non-Qubes-Whonix platform.
- 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.
- Using packages from different repositories can lead to Dependency Hell.
- This problem can be avoided by cloning additional Whonix templates and preferring packages from a single repository in each TemplateVM.
- It is strongly encouraged to only install signed packages from a trusted source.
- This applies to all TemplateVMs, even if they were cloned.
- Since TemplateVMs in Qubes R4 and above are supposed to be upgraded through qrexec based Qubes updates proxy.
$tag:whonix-updatevm $default allow,target=sys-whonix
Note that policy parsing stops at the first match, [...]
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.