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 [archive] 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 [archive]
- sdwdate 
- whonixcheck 
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.
(Qubes-Whonix ™: In TemplateVM)
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
- https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/etc/onion-grater-merger.d/30_whonix-default.yml [archive]