{{Header}} {{Title|title= Multiple {{project_name_gateway_long}} }} {{#seo: |description=Compartmentalization. Managing multiple {{project_name_gateway_short}}. |image=Multiplegateways131231.jpg }} {{multiple-vms-mininav}} [[File:Multiplegateways131231.jpg|thumb]] {{intro| Compartmentalization. Managing multiple {{project_name_gateway_short}}. }} = Introduction = {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = '''Note''': It is far safer and easier to manage multiple {{project_name_gateway_short}} when only one is launched for user activities, rather than running many in parallel. }} Multiple [[Whonix-Gateway|{{project_name_gateway_short}}]] can be used alongside multiple [[Whonix-Workstation|{{project_name_workstation_long}}]], but this has both advantages and disadvantages. One security benefit is the isolation of separate {{project_name_gateway_short}} VM instances. In the event that one {{project_name_gateway_short}} is compromised, it is not certain the other(s) will be similarly compromised. On the downside, newly cloned {{project_name_gateway_short}}(s) will end up with a different set of Tor entry guards unless precautions are taken. Such as manually configuring identical [[Tor_Entry_Guards|Tor entry guards]]. Qube-{{project_name_long}} users can copy the Tor state folder to another instance or use [[Bridges]]. At present, full instructions are not available for every {{non_q_project_name_short}} platform. 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 {{project_name_gateway_short}}, then a different set of Tor entry guards will be used as well (unless by chance the same Tor guards are chosen for different {{project_name_gateway_short}}). When multiple {{project_name_gateway_short}} are run in parallel, the risks explained in the [[Multiple Whonix-Workstation#Safety_Precautions|Multiple {{project_name_workstation_short}}: Safety Precautions]] section equally apply. = How to use Multiple Whonix-Gateway = Platform specific. Select your virtualizer below. {{Tab |type=controller |linkid=link1 |content= {{Tab |title= == VirtualBox == |image=[[File:Virtualbox_logo.png|25px]] |addToClass=info-box |content= In VirtualBox Manager, it is necessary to change the name of the internal network for both {{project_name_gateway_short}} and {{project_name_workstation_short}}. '''1.''' Learn the default {{project_name_short}} internal network name. It is {{project_name_short}}. '''2.''' Pick an alternative internal network name. For the second, third, or nth multiple {{project_name_gateway_short}}, another internal network name is required. Any name can be used, but make sure it is not reused in any other {{project_name_gateway_short}} that should be isolated from this one. The following example will use {{project_name_short}}'''2''', however, it could be something completely different like for-my-onion-web-server. '''3.''' Change {{project_name_gateway_short}} internal network name. * VirtualBox → {{project_name_gateway_short}} → Settings → Network → Adapter '''2''' → Name: → change Whonix to something else such as {{project_name_short}}'''2''' → OK '''4.''' Change {{project_name_workstation_short}} internal network name. * VirtualBox → {{project_name_workstation_short}} → Settings → Network → Adapter '''1''' → Name: → change Whonix to the same internal network name as above → OK '''5.''' Done. }} {{Tab |title= == KVM == |image=[[File:Kvm-new-logo.png|25px]] |addToClass=info-box |content= In this configuration, {{project_name_workstation_short}} will not be able to communicate with one another. This is recommended to keep different Tor activity profiles completely separate. To run multiple {{project_name_gateway_short}}, it is necessary to clone existing VMs; the steps below assume an existing {{project_name_short}} install. {{Box|text= '''1.''' Create clones of the Gateway and Workstation VMs rolled back to clean snapshots. In Virtual Machine Manager: Highlight VM → Open → Virtual Machine → Clone... → Clone '''2.''' Set up different external network interfaces. The {{project_name_gateway_short}} lacks a DHCP client for security hardening reasons and so cannot be attached to the same external network without conflicting with other {{project_name_gateway_short}}s' traffic. {{CodeSelect|code= sudo virsh net-dumpxml Whonix-External > Whonix-External2.xml }} '''3.''' Edit the network configuration to make it unique. {{CodeSelect|code= sudo nano Whonix-External2.xml }} * Change the '''name''' and '''bridge name'''. * Delete the '''mac address''' and '''uuid''' parameters. * Change the '''IP Address''' used Or just replace the configuration with the example below (this assumes the only custom networks are {{project_name_short}}-related). 

  Whonix-External2
Save and exit. 
CTRL-X
y
CTRL-M
'''4.''' Import and start the new network. {{CodeSelect|code= virsh -c qemu:///system net-define Whonix-External2.xml }} {{CodeSelect|code= virsh -c qemu:///system net-autostart Whonix-External2 }} {{CodeSelect|code= virsh -c qemu:///system net-start Whonix-External2 }} Attach the Gateway and Workstation VM NICs to the new network. To edit the VM virtual NIC settings:
Highlight VM → Open → Settings (light bulb) → NIC virtual hardware → Set Network Source to: Virtual network 'Whonix-External2' : NAT [[File:gateway2-1.png|600px]] * Note: virbr1 is assigned to the Whonix-External network (default {{project_name_gateway_short}} external NAT NIC). Therefore, the network name was changed to External2 and the bridge name to virbr4. '''5.''' Export {{project_name_short}} internal network settings. {{CodeSelect|code= sudo virsh net-dumpxml Whonix-Internal > Whonix-Internal2.xml }} '''6.''' Edit the network configuration to make it unique. {{CodeSelect|code= sudo nano Whonix-Internal2.xml }} * Change the '''name''' and '''bridge name'''. * Delete the '''mac address''' and '''uuid''' parameters. Or just replace the configuration with the example below (this assumes the only custom networks are {{project_name_short}}-related). 

  Whonix-Internal2
Save and exit. 
CTRL-X
y
CTRL-M
* Note: virbr2 is assigned to the Whonix-Internal network (default {{project_name_workstation_short}} internal NIC). Therefore, the network name was changed to internal2 and the bridge name to virbr3. '''7.''' Import and start the new network. {{CodeSelect|code= virsh -c qemu:///system net-define Whonix-Internal2.xml }} {{CodeSelect|code= virsh -c qemu:///system net-autostart Whonix-Internal2 }} {{CodeSelect|code= virsh -c qemu:///system net-start Whonix-Internal2 }} '''8.''' Attach the Gateway and Workstation VM NICs to the new network. To edit the VM virtual NIC settings:
Highlight VM → Open → Settings (light bulb) → NIC virtual hardware → Set Network Source to: Virtual network 'Whonix-Internal2' : Isolated network [[File:gateway2-2.png|600px]] * Note: The network is exclusively internal and does not communicate with the host in any way. '''9.''' Now, you need to change the network settings inside the Whonix-Gateway2 machine. While you could modify the 30_non-qubes-whonix file, it's better to avoid editing official Whonix files, as they may be overwritten during updates. Instead, create a new 50_custom-whonix file, which will partially override the settings in 30_non-qubes-whonix. * Boot the Whonix-Gateway2 VM from KVM and create a new file: {{CodeSelect|code= sudo nano /etc/network/interfaces.d/50_custom-whonix }} * Then Copy/Paste: 
# Custom Whonix Gateway overrides (loaded after 30_non-qubes-whonix)
auto eth0
iface eth0 inet static
	pre-up ip addr flush dev eth0
    address 10.0.3.15
    netmask 255.255.255.0
    gateway 10.0.3.2
Save and exit. 
CTRL-X
y
CTRL-M
* Restart network interface (or whole machine): {{CodeSelect|code= sudo ifdown eth0 && sudo ifup eth0 }} Related forum discussion: https://forums.whonix.org/t/do-multiple-whonix-gateways-require-different-whonix-external-virtual-nics/19903 '''10.''' Change the number of pinned CPUs. It is recommended to [[KVM#A)_With_an_Editor|edit]] the cloned workstation's configuration and change the number of pinned CPUs to a different value (3 or 4) compared to the existing gateway and primary workstation. This only works if users have a quad-core system. '''11.''' Done. }} }} {{Tab |title= == {{q_project_name_long}} == |image=[[File:Qubes-logo-icon.png|25px]] |addToClass=info-box |content= It is simple to create additional {{project_name_gateway_short}} ({{project_name_gateway_vm}} instances) in [[Qubes|{{q_project_name_short}}]]. Though the procedure is for advanced users who want the security benefit of separate {{project_name_gateway_short}} instances in {{q_project_name_short}}. While it affords some protection in the event that other {{project_name_gateway_short}} instances are compromised, it will result in a different set of Tor entry guards unless precautions are taken. Please ensure that the newly created {{project_name_gateway_vm}} is based on the {{project_name_gateway_template}} Template and has a distinctive VM name, so it is not confused with other VMs. Additionally, it is recommended not to run multiple {{project_name_gateway_short}} instances in parallel, see [[Multiple {{project_name_gateway_short}}#Introduction|Multiple {{project_name_gateway_short}}]]. To create a [[{{project_name_gateway_short}}|{{project_name_gateway_short}}]] ProxyVM in Qubes: # Qubes VM Manager → Qube → Create new qube # Name and label: Name the ProxyVM. Do not include any personal information; if the ProxyVM is compromised, the attacker could run qubesdb-read /name to reveal its name. Use a generic naming convention, for example: {{project_name_gateway_vm}}-2. # Color: Choose a color label for the {{project_name_gateway_short}} ProxyVM. # Type: Choose the type AppVM. # Template: Choose {{project_name_gateway_short}} Template. For example: {{project_name_gateway_template}}. # Networking: Choose the desired clearnet Service Qube from the list. For example: sys-firewall. # Advanced: Place a check mark in the "provides network" box. This will allow the {{project_name_gateway_short}} ProxyVM to provide networking for other App Qubes. # Press: OK. # See screenshots in footnotes if needed. '''Figure:''' ''Qubes Manager: Create New Qube - Step 1''
[[File:Createproxyvm.png]]
'''Figure:''' ''Qubes Manager: Create New Qube - Step 2''
[[File:Createproxyvm2.png]] # Open a dom0 terminal. # Add qvm-tag anon-gateway to the newly created App Qube. [[Dev/Qubes#qvm-tags|Developer documentation about qvm-tags]] Note: Replace {{project_name_gateway_vm}}-2 with the actual name of the VM. {{CodeSelect|code= qvm-tags sys-whonix-2 add anon-gateway }} 12. Done. }} }} = See Also = {{multiple-vms-mininav}} * [[{{project_name_gateway_short}}|{{project_name_gateway_short}}]] = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]