[tor-relays] How to use our own TOR relay as entry node for local network hosts

[Tor User]

Great points raised there with your post.  Thanks for the reply.

I definitely don't understand everything about Tor but I'm gradually 
getting there.  The public Tor entry guard relay ran great for over a 
year but we ended up taking it down for a while once I realized 
something was wrong with how we were trying to use it as our configured 
EntryNode from clients on the local network. We put it back up a couple 
few months ago with an updated version and I started twiddling again 
with the network clients.

I knew something was wrong but couldn't quite put my finger on it until 
s7r's post - it made sense.  For what we were trying to do - use a 
public Tor relay we know and trust (ours!!! <g>) as our tor client 
EntryGuard, and also help contribute to the cause, it works great.  Our 
Tor relay is the first node in our circuits now.  I just had to stop 
pointing my clients at the polipo proxy and configure the fingerprint of 
our public EntryGuard/node in torrc on the clients.

And yea, I am our network admin too. Totally small-time. :)

Thanks again.

On 05/23/2015 06:47 PM, Zenaan Harkness wrote:
> On 5/20/15, s7r <s7r at sky-ip.org> wrote:
>> On 5/20/2015 12:07 PM, Tor User wrote:
>>> If I'm wrong about this, that's great - I'd love to see some
>>> documentation to explain it better if you have any links handy.
>>> But if I'm right, how can I configure our TBB clients to actually
>>> MAKE them use our TOR proxy as their entry node?
>> I do not see any benefits in using a Guard on your local network, I
>> just don't see the point of it. You can do the following:
>>
>> 1. The centralized Tor server, as explained above, means you have to
>> run only one Tor instance for all the computers in your network. This
>> means you don't need Tor on all of the other computers in your
>> network, and the entry point (Guard) needs to be defined on the Tor
> I think the OP wants to treat their "centralized Tor server" as though
> it is a guard, which is why the term "centralized Tor server" perhaps
> clarifies the OP's thinking.
>
> As you highlight, with a "centralized Tor server", a separate (local
> LAN) "entry guard server" doesn't make sense.
>
>> centralized server (in your case relay) only, and it will affect all
>> the clients in the network using it. You will not be able to see
>> circuit info (such as path) on the computers using this centralized
>> Tor server because they won't have access to the Tor control port,
>> which is totally normal.
> The thought still lingers though - if one were to run TBB or a Tor
> node on each computer in a LAN, and treat the "centralized Tor server"
> as an "entry guard" by some manual configuration:
>
> a) This should be doable, workable, and be just fine/ok or in fact
> even better than having all local/LAN computers access Tor/internet
> through the SOCKS proxy of the "centralized Tor server",
>
> b) It should be possible to set up such a configuration manually -
> force the "centralized Tor server" to be "my" (random LAN PC with tor
> instance eg TBB) entry guard to the Tor network, even though it does
> NOT have the guard relay, assuming I am the LAN admin, or that I trust
> the LAN admin,
>
> c) It should be better for security of each LAN PC - since they are
> sort of participating natively in the Tor network, since they begin
> their own hop in/at their local PC, and so don't have to rely nearly
> so much on the LAN admin and the SOCKS proxy running on that
> "centralized Tor server" - is getting from my PC to a SOCKS proxy on
> some other PC even secure at all, or is some other security layer now
> needed to protect/hide agains LAN eavesdroppers?,
>
> d) Because each LAN PC has its own tor node (eg TBB with manual
> config), they can see their full circuits in the wider Tor network -
> with all circuits always beginning at the (manually configured)
> "centralized Tor server configured as my permanent Tor network entry
> guard node",
>
> e) TBB "just works" from a "all the various Tor project customizations
> for Firefox are baked in, it's much harder for me to f*** it up
> somehow" - and I think this is one of the most critically important
> benefits that should not be so readily discarded with:
>
>> On the computers in your network you can just use Firefox with some
>> privacy plugins and route all traffic (including DNS) through the
>> polipo proxy, running on the Tor centralized server / relay.
> since "just install some privacy plugins and route DNS through
> SOCKS/polipo" can so easily fail big time!
>
> If there's any chance of adversarial eavesdropping or browser attacks,
> surely you want to start from a "just works as far as most Tor devs
> are aware within the known limits etc" position, and add the minimal
> browser config/ manual Tor config on top of that?
>
> What happens when a TBB security fix comes out - does one assume that
> normal firefox does not need that? Does one assume that a normal
> firefox upgrade, in the face of the full set of manual "TBB like"
> customizations (assuming you even implemented them all, and
> implemented them all correctly) and that you do -not- need to do a
> full firefox reinstall?
>
> There are SO many unanswered security questions for an end user (or
> LAN admin trying to be responsible on behalf of their LAN PC users)
> that I feel it is dangerous to suggest something other than "use TBB,
> with absolute minimal manual config on top, e.g. disable Javascript
> :)"!
>
> ...
>> Want a centralized Tor server and a Guard relay at the same time? Just
>> run the relay someplace else, and use StrictNodes and EntryNode on
>> that server. I doubt this is what you want since you installed Tor
>> Browser on the computers in the network as well.
> TBB, albeit with some (hopefully minimal) manual customizations, ought
> be "the recommended way" by my reasoning... the only question is how
> to achieve a sane setup, optimizing for a particular scenario - in
> this case, the OP is optimizing for a LAN environment in which it
> appears that the OP may be the admin, and therefore that the OP has a
> certain trust in him/her self :)
>
> It might, just possibly, also be the case that other individuals who
> use that LAN environment, place some level of trust in their LAN admin
> too.
>
> In the face of even a minimal level of additional trust which is not
> ordinarily available to Joe Random Home User, surely it is sensible to
> try to leverage that additional trust in order to maximise "security
> (by some definition)"?
>
> And here, I feel, is the crux of both a dilemma, and an opportunity,
> which is highlighted by the OP, and which Tor network has failed to
> confront or take advantage of - actual available trust in a particular
> node operator (in this case the OP's "centralized Tor server").
>
> Perhaps the old vidalia (?) setup where there was a separate gui for
> TBB's Tor networking side did provide a mechanism for end users to
> take advantage of such "additional available trust"? Before my time
> sorry.
>
> ...
>> You can run a centralized Tor server with polipo and a Tor relay on
>> the same server, but that Tor client
> "that Tor client" is ambiguous to me and I can't figure out what you
> mean - if you think it's useful, please clarify what you meant by
> "that Tor client".
>
>> cannot use its relay
>> functionality running on the same machine as the first hop.
>>
>> 2. Disable the polipo proxy on your Tor relay, you do not need that.
> I agree with this. Tor server (relay/"centralized Tor server"/"faux
> Tor entry guard") provides a SOCKS proxy built in - I see only
> disadvantages to adding an unnecessary additional proxy layer.
>
>> Use Tor Browser on every computer in your network with normal
>> settings, no proxy setup, just direct connection
> By "direct connection" do you mean "direct/normal automatic connection
> to the Tor network"?
>
>> and StrictNodes and
>> EntryNode $fingerprint-of-your-relay.
> Ahah! This sounds like what the OP is after - what I term above as
> "faux Tor entry guard".
>
>> For this, your relay needs the
>> Guard flag.
> Oh. Dang.
>
> So what's wrong with having:
> EntryNode $cntrlzd-faux-guard-relay-fingerprint
> ForceEntryNodeIfNoGuardFlag true
>
> ???
>
>> If you are behind NAT, it will use the public IP to
>> connect to the relay on your network since that is what your Tor
>> client(s) will understand from the consensus data file.
> What's wrong with the fingerprint? Surely this is some sort of public
> key verifiable fingerprint, crypto 101 right?
>
> In other words:
>
> EntryNode $cntrlzd-faux-guard-relay-fingerprint
> ForceEntryNodeIfNoGuardFlag true
> EntryNodeAddress 192.168.1.207
>
> ???
>
> (I'm not asking why doesn't it work now, since these additional
> options probably don't exist in Tor yet - I'm asking -why- such
> options are not a good idea in these circumstances and why this ought
> not be permitted at all.)
>
>
>> 3. Disable the polipo proxy on the Tor relay in your network,  you do
>> not need that. Run a bridge instead of a relay. Make it a non public
>> bride (PublishServerDescriptor 0) and run Tor Browser on all the
>> computers in your network with UseBridges 1 and define the ip:port of
>> your bridge and connect it directly, no proxy setting. This way other
>> 'strangers' won't be able to use your bridge and you will also not
>> need the Guard flag or uptime and bandwidth requirements.
> Sounds like another "ahah!" moment - perhaps this is finally the
> answer to OP's need.
>
>> Hope this helps.
> That last bit (UseBridges 1, configure bridge IP), looks like it does
> the job needed here, no new Tor config options required.
>
>
>> If you don't understand something, please ask again,
>> it's important for you to understand what you are doing not just
>> follow instructions.
> ACK. I too want to understand, which makes at least 2 people :)
>
> Regards,
> Zenaan
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>