but would it be possible to open a third netword card, apply some rules, open the 9050 port in the rules of virtualbox and use it to reach the proxy. Like for example to get thunderbird reach tor with torbirdy through your gateway?
I know it’s not supported, I jsut want to know if it’s feasable or if you locked everything to render that impossible?
In that tradition, Whonix doesn’t implement deliberate technical hurdles to prevent what advanced users and/or developers from custom modifications.
Feasible possibly yes.
third interface:
Whonix Firewall contains options to configure multiple interfaces.
Also then Tor config needs to be modified to bind on that IP.
But likely a third interface maybe isn’t even needed. Access Tor running inside Whonix-Gateway from the host was accomplished years ago. On Whonix Advanced Documentation under Esoteric Issues we have this wiki page:
This is very esoteric and you probably don’t need it! Advanced users only!
Not tested since Whonix ™ 0.5.6. May or may not work. Might need changes for later versions.
I can confirm that the solution through the first interface connected to NAT is working still hard and strong on whonix 15.0.0.3.3 but with some modification since virtualbox change a bit or maybe I’m being too obessional.
it would be better to link the VM through a NAT network you created in place of NAT to have the ability to redirect ports. And when you redirect ports, it would be best to put the guest IP. I don’t know we didn’t do it before actually since if not, I don’t see how the process could know where to direct the packet.
I will try later for the third connection, I would find it less messy to pass it through in a third interface.
between the host and the VM-gateway. At least to let the possibility to do that for the user, don’t you think? Because if just NAT is selected then there is no port translation possible.
because I don’t know you but I managed several VM on my workstation and I use port translation a lot, and so since I use translation port a lot, I need to specify the guest IP to make the translation port to work.
And yes yes, I know, this configuration is not supported blablabla… But in the mean time, it’s not like it’s that complciated to activated the possibility.
By the way I wanted to document my experience and ask some quesitons in the mean time if I may.
So what I discover and what was not documented, is that you don’t use only one port for the use of the proxy apparently. Between gateway and workstation I mean.
examples:
hexchat is on 9101
tor browser seems on something else too
swtdate is on another one than 9050 too
etc
so obviously you just opened the range to communicate or maybe you configured it in a specific file?
Another thing is that, since I had to activate the file 50_user.conf by filling it some information. I had’nt only need to put the guest ip adresse from the nat network I created for the VM.
But I also had to put 127.0.0.1:9050 for the gateway itself to be able to connect to apt mirrors for example
also the interface from internal network Whonix for the workstation to let it access TOR for the primary services like nslookup, apt , etc…
The problem now is that since every single one of the processes installed in the workstation has it’s own port number to communicate to the proxy, I can’t add them all to the file in the gateway VM, or it would be a long and heavy task.
So is it possible to open a range in place of “Socksport 10.152.152.10:9101” and put 9000-9200 for example?
And more conceptual question, since without fill the file 50_user.conf with information it works fine, does that mean that because of filling this file, your configuration file got disabled or something like that?
Thanks in advance for all the enlightment you would be able to provide me.
General Tor question as per Self Support First Policy for Whonix
And no, I am not aware of such as Tor feature.
Consider posting a feature request against Tor.
You be able have to auto generate such a config file with a script.
Variables set in lexical lower configuration files will persist if they are not chaned in lexical higher configuration files.
Okey so I4ve seen:
On Whonix-Gateway ™ in /usr/share/tor/tor-service-defaults-torrc are already a lot custom socks ports prepared for custom installed applications:
Without IsolateDestAddr and without IsolateDestPort: SocksPort 10.152.152.10:9153 to 9159
With IsolateDestAddr, but without IsolateDestPort: SocksPort 10.152.152.10:9160 to 9169
Without IsolateDestAddr, but with IsolateDestPort: SocksPort: 10.152.152.10:9170 to 9179
With IsolateDestAddr and with IsolateDestPort: SocksPort: 10.152.152.10:9180 to 9189
If those are not enough, you can add your own.
and indeed in this file there are a lot of custom ports. But so do you mean that I can’t fill anything in 50_user.conf because then the one in /usr/share is not read? So should I put a copy of this conf file into /usr/loca/etc/torc.d/ then?
Because in the end it’s not a firewall problem, or is the file in /usr/local/etc/torrc.d/ linked to the firewall configruation? I was under the impression that it was not since for that there is a part
so my problem is really the proxy not the firewall. IT’s not listening to the ports described in usr/share . it only listens to the one in /usr/local/
So I’m going to make a copy paste from share to local but is this really the proper way? or am I missing something?
One of us is not understanding the point of the other one here.
Because for me you are not seeing what I’m trying to do which is :
→ just add a listening adress which is 10.0.2.15 with the port 9050 for the host to be able to connect to it
Or maybe then I don’t get your point that you are trying to explain to me.
But that need to be in addition of all the others SockPort which are already configured and working when you do a fresh isntall.
As you know when you do a fresh install there is no problem for workstation to contact with hexchat the proxy through 9101 by default, etc…
When I just add the line in the 50_usr.conf file : SockPort 10.0.2.15:9050 then everything else goes to the toilet.
Sorry but I don’t understand the logic here. The common sense would say, since there are all those socksports already configured that means the proxy is meant to be versatile enough. So the basic configuration file shouldn’t be disabled but read after the 50_user.conf and all the rules should be applied unless there is a rule that is already mentioned in 50_user.conf and so this one will be applied in place of the specific one in share folder.
in your link it is well said:
This rule is simple for options that take a single value, but it can become complicated for options that are allowed to occur more than once: if you specify four SOCKSPorts in your configuration file, and one more SOCKSPort on the command line, the option on the command line will replace all of the SOCKSPorts in the configuration file. If this is not what you want, prefix the option name with a plus sign, and it will be appended to the previous set of options instead.
But I’m not using commandline to add my port here, just one line in the 50_user.conf file, so the other lines in the basic file shouldn’t be ignored. That’s what I’m not understanding.
I suggest to simplify the setup. Reproduce what you want outside of Whonix with Debian and Tor only. That way your question becomes a pure, non-Whonix related Debian/Tor question and you can ask Tor Project support about this.
As per Self Support First Policy for Whonix
Otherwise I would re-read here Tor Documentation for Whonix Users and if that doesn’t work produce outside of Whonix (Debian and Tor only) and then contact The Tor Project in case of questions / bugs.
Also extra VMs don’t require new ports so this doesn’t come up either.
in 50_user.conf
to not override completely your config file that you just mentionned, you need to put +SocksPort blablabla in place of SocksPort blablabla
Apparently just SocksPort is only within the same primary basic config file.
Well it depends if you want to isolate the traffic and put the VM on another internal network with other addressing schematics than the basic one you configured. Which yo udon’t do I know but that could be a usecase too.
May I dig a little deeper and take a bit much more of your time (You don’t need to answer it now). but what’s the hierarchy between all your config files in /usr/share/tor ?
Because there is the orig, the instances. I guess the anon is the main config file of the tor project that you modify for the whole whonix project right?
By Debian. Used for running multiple Tor instance which can be enabled using systemd. I haven’t researched that yet. Not used in Whonix currently.
Whonix /usr/share/tor/tor-service-defaults-torrc in the git repository is file /usr/share/tor/tor-service-defaults-torrc.anondist which config-package-dev puts into the right place in a good way.
Check folder /usr/share/tor on Debian vs Whonix.
The other files there such as tor-service-defaults-torrc-instances by Debian make it look more complicated than it ought to be.
Tor upstream doesn’t support “proper” torrc.d/*.conf support yet. See torrc.d is comming
That’s why historically Whonix had to use /usr/share/tor/tor-service-defaults-torrc.
