Setting up a Tor private network

[George Shaffer]

On Wed, 2006-10-04 at 11:38, Jim Spring wrote:
> I'm in the process of playing around with Tor (beyond just using it  
> as a client -- using it as a client has been no problem).  In so  
> doing, I am attempting to first set up a "tor private network" on a  
> system and see how things work when running a couple of tor server  
> processes.  I am using the make-private-tor-network.py (I've also  
> ried hand configuring) but things do not appear to work.

I haven't gone very far with this but, yesterday I did get a private Tor
network to work, and I think the documentation makes it confusing and
difficult when it was very easy. Getting the client setup to work was
much harder. 

Once I had Tor and Privoxy working as a simple client on the computer I
intended to be the Tor server, I only had to change one line in the
Privoxy config. All I did was change listen-address from 127.0.0.1 to
the real IP address of the computer (in this case a NATed private
address). I tried two listen-address lines but that did not work.

Of course to get the local client application to work, I had to switch
it from 127.0.0.1 (or localhost) to the real IP.

Client setup on the remote computer was the same as on a local computer,
except everywhere where you would have 127.0.0.1 (or localhost) you need
to enter the real IP of the computer running Tor and Privoxy. This works
for web browsing with http and https. If you set up a socks client the
port should be 9100 instead of 9050 for a local client.

According to the documentation, for remote access (networking) the Tor
SocksListenAddress should also be set to an external address. I realized
that when I set up tor, I'd included both the localhost and real IP in
two SocksListenAddress lines, as it was my plan from the beginning to
network them.

Anyhow, you need to set up a chain of communication. Starting with a
client application (web browser). The web browser has to send its http
and https requests to Privoxy's listen-address (including port), and if
any client will be on a remote computer then the Privoxy's listen
address must be the computers real IP address (whether it's a public or
NAT address). Privoxy needs to talk to Tor so Privoxy's forward-socks4a
address must match one of Tor's SocksListenAddress. Since Tor allows
multiple SocksListenAddress(es) no changes need to be made to the
default Privoxy forward-socks4a address (unless they are different
computers which does not make much sense).

I have no idea what make-private-tor-network.py does.

> In the debug log, I am consistently seeing the following debug  
> statement:
> Oct 04 01:12:50.107 [info] router_have_minimum_dir_info(): We have 0  
> of 1 network statuses, and we want more than 0.

This is an info level message and may not be be important in itself,
even though it may be caused by whatever misconfiguration is preventing
your Tor network to not work.

There are some security things you may want to consider. If you are
behind a strong firewall with NAT, you may feel that further measures
are not necessary. If you want a bit of extra security you can control
access to Privoxy and Tor. If for example you are on a NAT network
198.162.111.0, netmask 255.255.255.0 (or approximately 255 potential
hosts), you could add a line in Privoxy config "permit-access
198.162.111.0/24", which would allow all computers on your network to
access Privoxy and no others. If Tor and Privoxy are not on your
(dedicated) firewall (which may be the best place for them) and your
firewall is 198.162.111.1 then deny-access 198.162.111.1/31 (I think 31
is right) would prevent the firewall from accessing Privoxy. This would
be somewhat pointless if your firewall could ssh to the machine Privoxy
was on. On the other hand if your firewall had a web browser (bad idea)
any intruder on your firewall could make anonymous web connections as
you (and retrieve all his tools from his private website). Tor has a
similar but somewhat different scheme for controlling socks access,
documented in the torrc sample file.  Never set any security like this
until you have a system working; then if it breaks when you enable
security, you know you have the security wrong.

> And for the record, this is on both OS X and Linux -- the behaviour  
> is consistent.

Mine is OpenBSD and Linux. The principles should be the same regardless
of system type, though sometimes of course the mechanics can be
maddeningly different. When I'm done, this new OpenBSD machine will be
my firewall, NAT router, and Tor/Privoxy server.

George Shaffer