Using Whonix-Workstation with a Gateway Other Than Whonix-Gateway.
Potential Issues When using A Custom Gateway
- Gateway IP Change required? See chapter below.
- Tor Control Protocol Access. See chapter below.
- Custom gateway might not provide all the Tor
SocksPorts that Whonix-Gateway provides. Fixable by adjusting Tor configuration of the custom gateway.
- Custom gateway might not provide transparent proxying. This might be intended if the user prefers an IsolatingProxy setup.
Gateway IP Change
grep the Whonix source code for the following search term.
For example. (Creation of the
mygrep script is documented in above link.)
mygrep -r "IP HARDCODED"
Perhaps IP change can be avoided with some iptables trick?
Tor Control Protocol Access
Two options. Either:
- Allow filtered Tor control protocol access through onion-grater.
- unfiltered Tor control protocol access. A compromised workstation with unfiltered Tor control protocol access can acquire the real external cleranet IP. 
- No Tor control protocol access. This would break some functionality.
Which applications require Tor control protocol access?
- Tor Browser new identity feature
- A list of applications which are currently require Tor control protocol access can be found here: Special:WhatLinksHere/Template:Control_Port_Filter_Python_Profile_Add
- onion-grater example profiles
- sdwdate 
- systemcheck 
Filtered Access using onion-grater
Unfiltered Access not using onion-grater
This setting comes from Debian system Tor upstream package default file
The file location for this file is non-ideal since it will change at every boot. By re-configuring Tor on the other gateway to use a different file location the contents of this file might be constant. Untested.
On the Whonix-Workstation package anon-ws-disable-stacked-tor script
/usr/lib/anon-ws-disable-stacked-tor/state-files copies at boot
/usr/share/anon-ws-disable-stacked-tor/control.authcookie to the right places.
By copying the
control.authcookie file from the gateway to Whonix-Workstation
/usr/share/anon-ws-disable-stacked-tor/control.authcookie one might be able to have Tor cookie authentication. Contents of
/usr/share/anon-ws-disable-stacked-tor/control.authcookie will be overwritten when package anon-ws-disable-stacked-tor is upgraded.
Therefore this exercise might be a bit pointless. A better solution might be to use Tor Browser control protocol authentication using a Tor control password rather than Tor control auth cookie.
/etc/X11/Xsession.d/50user in an editor with root rights.
NOTE: When using Qubes-Whonix, this needs to be done inside the Template.
Others and Alternatives
- This is just an example. Other tools could achieve the same goal.
- If this example does not work for you or if you are not using Whonix, please refer to this link.
Paste the following contents.
## see also /usr/lib/anon-ws-disable-stacked-tor/torbrowser.sh ## See workstation file ~/.tb/tor-browser/Browser/start-tor-browser ## or Tor Browser file Browser/start-tor-browser script for comment ## why quoting looks weird. export TOR_CONTROL_PASSWD='"password"' ## Overwrite what /usr/lib/anon-ws-disable-stacked-tor/torbrowser.sh / ## /etc/X11/Xsession.d/20torbrowser is doing. export TOR_CONTROL_IPC_PATH="/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock"
This would have to be combined with Tor setting
HashedControlPassword on the other gateway. Untested.
Tor control protocol command