Actions

Connections between Whonix-Gateway ™ and Whonix-Workstation ™

From Whonix



Binary-503583640.jpg

Introduction[edit]

TODO: document that an open port in Whonix-Workstation can be accessed by other Whonix-Workstation in Non-Qubes-Whonix which is often unwanted.

Essentials[edit]

By default, Whonix ™ assumes that Whonix-Gateway ™ and Whonix-Workstation ™ are connected by (virtual) LAN cable. Wireless technologies are not recommended as a malware compromised Whonix-Workstation ™ could access (other) wireless access points and subsequently connect without Tor or find user's location based on WiFi SSIDs. Using a (virtual) cable enforces that Whonix-Workstation ™ can only connect through Whonix-Gateway ™. For the same reason, connections to Whonix-Gateway ™ over the internet are also not recommended.

By default, connections between Whonix-Workstation ™ and Whonix-Gateway ™ are neither authenticated nor encrypted. The above (virtual) LAN connection between Whonix-Workstation ™ and Whonix-Gateway ™ is assumed to be secure.[2] Adding authentication and/or encryption by default would further increase the complexity of Whonix ™, which is to be avoided as explained in earlier chapters.

If you want to run Multiple Whonix-Workstation ™ at the same time inside the same (virtual) isolated LAN, authentication should be added:

  • Inside virtual LANs:
    • Authentication is enough.
    • Encryption is not required. (When machines cannot be impersonated, MITM attacks are not possible from within the virtual LAN.)
  • Inside physical LANs:
    • If your threat model includes the possibility of a MITM attack, encryption is needed .

If you want to connect to a Whonix-Gateway ™ over insecure, untrusted, or unknown foreign networks (internet):

  • Both authentication and encryption should be added.
    • Encryption is required to deny MITM eavesdropping.
    • Authentication validates the identity of the connecting machine.
      • Encryption solutions such as OpenVPN and ssh also provide authentication.

Motivation for secure Whonix-Gateway ™ / Whonix-Workstation ™ connections[edit]

Only applies to non-stock configurations: If you run Multiple Whonix-Workstation ™ simultaneously or want to connect to Whonix-Gateway ™ over insecure or untrusted networks (internet):

A compromised Whonix-Workstation ™ can impersonate the Whonix-Gateway ™, or any other Whonix-Workstation ™, within the same (virtual) LAN, perform active MITM attacks, or passively eavesdrop.

Libvirt Isolated Ports[edit]

Isolated ports are a Libvirt feature supported since 6.1.0.[3]

The port element property isolated, when set to yes (default setting is no) is used to isolate this interface's network traffic from that of other guest interfaces connected to the same network that also have <port isolated='yes'/>. This setting is only supported for emulated interface devices that use a standard tap device to connect to the network via a Linux host bridge. This property can be inherited from a libvirt network, so if all guests that will be connected to the network should be isolated, it is better to put the setting in the network configuration. (NB: this only prevents guests that have isolated='yes' from communicating with each other; if there is a guest on the same bridge that doesn't have isolated='yes', even the isolated guests will be able to communicate with it.)

<devices>
  <interface type='network'>
    <source network='default'/>
    <port isolated='yes'/>
  </interface>
</devices>

OpenVPN vs SSH[edit]

Encryption can be added using OpenVPN or SSH. SSH, but not OpenVPN, has the advantage of being able to still easily tunnel a VPN through Tor, later. If you don't plan to do so, OpenVPN is probably easier. SSH has the disadvantage of increased setup complexity in this use case - you are probably better off using OpenVPN.

Authenticated connections between Whonix-Gateway ™ and Whonix-Workstation ™[edit]

ARP spoofing defense[edit]

This has only been quickly researched: From the Wikipedia article about ARP spoofing [archive], it appears that Static ARP entries could be used to authenticate connections between Whonix-Gateway ™ and Whonix-Workstation ™.

Using additional (isolated) network interfaces[edit]

Theoretical[edit]

(This chapter is actually not authentication, but solves the threat nonetheless.)

A workaround, when running all vm's on the same VirtualBox host:

  • One can enable additional Virtual Network Adapters with uniquely named internal virtual networks, inherently isolating up to 7 Whonix-Workstation ™ per Whonix-Gateway ™, [4]

A workaround, for Whonix ™ with Physical Isolation, where all possible connecting machines are trusted:

  • Whonix-Gateway ™ inherently requires two network interfaces - external and internal. Additional physical and/or virtual LAN interfaces could be added. (Ensure no bridging takes place.)

Instructions[edit]

DRAFT! UNFINISHED!

If you would like to see the unfinished documentation, please press on expand on the right.

These instructions explain how to do it using VirtualBox.

For basic setup, see this forum thread:
https://forums.whonix.org/t/running-2-isolated-workstations-on-a-single-gateway/835 [archive]

The original poster is on a good track already. Some more changes required.

On Whonix-Workstation ™ in an additional isolated network.

Modify the Whonix ™ Network Configuration.

If you are using Qubes-Whonix ™, complete the following steps.

Undocumented

If you are using a graphical Whonix-Gateway ™, complete the following steps.

lxsudo kate /etc/network/interfaces.d/30_non-qubes-whonix

If you are using a terminal-only Whonix-Gateway ™, complete the following steps.

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

Use these settings.

address 10.152.152.17
netmask 255.255.192.0
gateway 10.152.152.13

On Whonix-Gateway ™.

Modify the Whonix ™ Network Configuration.

If you are using Qubes-Whonix ™, complete the following steps.

Undocumented

If you are using a graphical Whonix-Gateway ™, complete the following steps.

lxsudo kate /etc/network/interfaces.d/30_non-qubes-whonix

If you are using a terminal-only Whonix-Gateway ™, complete the following steps.

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

Add this.

auto eth2
iface eth2 inet static
       address 10.152.152.13
       netmask 255.255.192.0

Modify Whonix-Gateway ™ User Firewall Settings.

Note: If no changes have yet been made to Whonix ™ Firewall Settings, then the Whonix ™ User Firewall Settings File /usr/local/etc/whonix_firewall.d/50_user.conf appears empty (because it does not exist). This is expected.

If using Qubes-Whonix ™, complete these steps.
In Whonix-Gateway ™ App Qube. Make sure folder /usr/local/etc/whonix_firewall.d exists.

sudo mkdir -p /usr/local/etc/whonix_firewall.d

Qubes App Launcher (blue/grey "Q")Whonix-Gateway ™ App Qube (commonly called sys-whonix)Whonix ™ User Firewall Settings

If using a graphical Whonix-Gateway ™, complete these steps.

Start MenuApplicationsSettingsUser Firewall Settings

If using a terminal-only Whonix-Gateway ™, complete these steps.

In Whonix-Gateway ™, open the whonix_firewall configuration file in an editor.

sudoedit /usr/local/etc/whonix_firewall.d/50_user.conf

For more help, press on Expand on the right.

Note: This is for informational purposes only! Do not edit /etc/whonix_firewall.d/30_whonix_gateway_default.conf.

Note: The Whonix ™ Global Firewall Settings File /etc/whonix_firewall.d/30_whonix_gateway_default.conf contains default settings and explanatory comments about their purpose. By default, the file is opened read-only and is not meant to be directly edited. Below, it is recommended to open the file without root rights. The file contains an explanatory comment on how to change firewall settings.

## Please use "/etc/whonix_firewall.d/50_user.conf" for your custom configuration,
## which will override the defaults found here. When {{project_name}} is updated, this
## file may be overwritten.

See also Whonix modular flexible .d style configuration folders.

To view the file, follow these instructions.

If using Qubes-Whonix ™, complete these steps.

Qubes App Launcher (blue/grey "Q")Template: whonix-gw-16Whonix Global Firewall Settings

If using a graphical Whonix-Gateway ™, complete these steps.

Start MenuApplicationsSettingsGlobal Firewall Settings

If using a terminal-only Whonix-Gateway ™, complete these steps.

In Whonix-Gateway ™, open the whonix_firewall configuration file in an editor.

nano /etc/whonix_firewall.d/30_whonix_gateway_default.conf

And add additional interfaces to the firewall config.

INT_IF="\
eth1
eth2"

INT_TIF="$INT_IF"

Reload Whonix ™ firewall (or reboot).

sudo whonix_firewall

Restart networking.

sudo service networking restart

Perhaps NetworkManager is interfering and must be disabled.

Also the file /usr/share/tor/tor-service-defaults-torrc needs some changes. Tor needs to listen on the additional interfaces.

Open file /usr/share/tor/tor-service-defaults-torrc in an editor with root rights.

This box uses sudoedit for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.

sudoedit /usr/share/tor/tor-service-defaults-torrc

Use this file:
https://github.com/Whonix/anon-gw-anonymizer-config/blob/tor_listen_on_all_interfaces/usr/share/tor/tor-service-defaults-torrc.anondist [archive]

[5]

Restart Tor.

sudo service tor@default restart

It will now loudly complain, that Tor is listening on all IPs that that may not be what you want. You can ignore this, because the external network interface is firewalled.

TODO: Explain what happens during upgrades.

Whonix-Workstation ™ whonixcheck / timesync / Tor Browser won't work. (Would need updated IP of the other gateway internal interface.) TODO: Expand.

Whonix-Workstation ™ TransPort access should be functional though. I.e. nslookup check.torproject.org and/or Firefox should work.

Whonix-Custom-Workstation ™ should work.


Encrypted and authenticated connections between Whonix-Gateway ™ and Whonix-Workstation ™[edit]

Using SSH (not tested/recommended)[edit]

* DO NOT ALLOW SSH LOGINS![6]

Each Gateway and Workstation should have its own SSH account and certificate distributed to each machine to which it will connect.[7] Each Gateway and Workstations will need ssh installed and the service started. Workstations need to be configured to automatically reconnect - in case Whonix-Workstation ™ starts before the Gateway, or restarts.[8] Workstations need to use the tunnel IP to connect to the Gateway. The Whonix-Gateway ™ should only accept certificate authentication, and only forward or answer to Tor over the SSH tunnel. All Workstations must use the established SSH tunnel to the Gateway, redirect such network access to socks via tranSOCKS_ev or similar. The Whonix-Gateway ™ firewall may need corresponding changes. Not impossible to use SSH for this - but intricate.

You may be better off using OpenVPN. However - OpenVPN is a full machine to machine connection, while ssh is easily port restricted.

Using OpenVPN[edit]

DRAFT! UNFINISHED!

If you would like to see the unfinished documentation, please press on expand on the right.

Right now only supports two modes/security domains:

  • Whonix-Workstation ™ with the secret key (=trusted) and
  • other workstation with no key/vpn configured.

NOTE:

  • Transparent proxying doesn't seem to work at all, therefore you need to configure all applications to use socks ports.

On the gateway:

{{mbox | image = [[File:Ambox_warning_pn.svg.png|40px|alt=Whonix first time users warning] | text = The following information only applies to the deprecated version of Whonix ™ 0.5.6. It requires updating for more recent versions of Whonix ™. Nowadays using wireguard instead of openvpn? Please help. }}

sudo -i

apt --yes install openvpn

Create a new symmetric key

sudo -u user openvpn --genkey --secret /home/user/static.key

Copy key to workstation (Firewall needs to be disabled and openssh-server installed on Whonix-Workstation ™ for this to work).

sudo -u user scp /home/user/static.key user@10.152.152.10:/home/user/static.key

mv /home/user/static.key /etc/openvpn/static.key

chown root:root /etc/openvpn/static.key

chmod 700 /etc/openvpn/static.key

Create server configuration.

echo "
user nobody
group nogroup
daemon
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret /etc/openvpn/static.key" > /etc/openvpn/server.conf

service openvpn restart

Edit torrc.
TODO: only selectively change listening addresses. TransPort and optionally other SocksPorts have to remain available, if unauthenticated workstations are to be used. NOTE: we are using a hardcoded default IP here, if you are using non standard settings this will have to be edited.

ed -s /usr/local/etc/torrc.d/50_user.conf <<< $',s/10.152.152.10/10.8.0.1/g\nw'

Edit /usr/local/bin/whonix_firewall.
TODO: Put this automatically where it actually belongs

echo '
# Allow openvpn in on port 1194
iptables -A INPUT -i $INT_IF -p udp --dport 1194 -j ACCEPT' >> /usr/local/bin/whonix_firewall
# TODO: replace hardcoded "eth1" with a wildcard

ed -s /usr/local/bin/whonix_firewall<<< $',s/INT_TIF=eth1/INT_TIF=tun0/g\nw'

/usr/local/bin/whonix_firewall

On the Workstation(s):

TODO: Disable/tweak the new firewall

sudo -i

mv /home/user/static.key /etc/openvpn/static.key

chown root:root /etc/openvpn/static.key

chmod 700 /etc/openvpn/static.key

Should be in the default installation.

apt --yes install --no-install-recommends torsocks

echo "
user nobody
group nogroup
daemon
remote 10.152.152.10
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret /etc/openvpn/static.key" > /etc/openvpn/server.conf

Edit resolv.conf.

chattr -i /etc/resolv.conf

echo "nameserver 10.8.0.1" > /etc/resolv.conf

chattr +i /etc/resolv.conf

See Also[edit]

Footnotes / References[edit]

  1. Because by Qubes default, AppVMs behind the same ProxyVM [or NetVM] are prevented from connecting to each other.
  2. Here, secure is an assumption that nothing within your (virtual) LAN will MITM attack anything else.
  3. https://libvirt.org/formatdomain.html#isolating-guests-s-network-traffic-from-each-other [archive]
  4. "Four of the network cards can be configured in the "Network" section of the settings dialog in the graphical user interface of VirtualBox. You can configure all eight network cards on the command line via VBoxManage modifyvm [archive]"
  5. This likely should not be made the default version. Because... TODO: Explain.
  6. See: ssh login [archive]
  7. Internet search How to set up ssh keys, for example, for instructions.
  8. Consider: autossh


Fosshost is sponsors Kicksecure ™ stage server 100px
Fosshost About Advertisements

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki


Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: Discourse logo.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contribute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Twitter-share-button.png Facebook-share-button.png Telegram-share.png link=mailto:?subject=Connections between Gateway and Workstation&body=./Connections_between_Gateway_and_Workstation link=https://reddit.com/submit?url=./Connections_between_Gateway_and_Workstation&title=Connections between Gateway and Workstation link=https://news.ycombinator.com/submitlink?u=./Connections_between_Gateway_and_Workstation&t=Connections between Gateway and Workstation link=https://mastodon.technology/share?message=Connections between Gateway and Workstation%20./Connections_between_Gateway_and_Workstation&t=Connections between Gateway and Workstation

Did you know that Whonix ™ could provide protection against backdoors? See Verifiable Builds. Help is wanted and welcomed.

https link onion link Priority Support | Investors | Professional Support

Whonix | © ENCRYPTED SUPPORT LP | Heckert gnu.big.png Freedom Software / Osi standard logo 0.png Open Source (Why?)

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.

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.