[tor-relays] firewalled relays

Mike Perry mikeperry at fscked.org
Sat Jun 4 08:31:10 UTC 2011

Thus spake Jesus Cea (jcea at jcea.es):

> On 03/06/11 16:13, tagnaq wrote:
> > If one out of 1000 circuits through your relay are failing because you
> > filter 443 while relaying 50Mbit/s I would find it acceptable,
> > but I fear it are far more. Do you have any stats? (I'm not sure how to
> > gather them.)
> > Mikes opinion is also be very valuable on such topics.
> If somebody can tell me where to look...

You likely need to taylor your iptables rules to also log when you
reject these connections:

(Paste your current 443-blocking firewall rules to the list if you need
some help creating log lines for them.)

Note, this is not a great metric, because each circuit attempt will
cause a connection attempt, but if a connection already exists, it
will be re-used.. So it is hard to use this to get a baseline of the
percentag of circuits your node tends to fail from clients...

On the flip side, it will still be an interesting thing to measure,
because Tor relay TLS connections are actually bi-directional, meaning
that if a relay successfully connects *to* you, you will use that
connection for circuits destined for that relay as opposed to trying
to make a new connection. With time, you may actually end up connected
to most/all of the 443 relays anyway. It would be interesting to see
if you are actually blocking any connection attempts at all after
being up for a long time. You should end up connected to most/all
relays at some point.

P.S. Not sure what your rules are, but you should really be using the
REJECT target, not the DROP target for satisfying your crazy ISPs
policy. DROP will force clients to wait to register a timeout for
their circuit, where a REJECT will cause them to get a fail reason
back. THe REJECT is thus way better for performance of clients:

P.P.S. Your ISP is really crazy. Have you thought about giving them a
link to a torstatus directory of Tor IPs so they can feed it to their
stupid IDS to whitelist for purposes of outgoing connections? We can
probably induce torstatus to produce a csv of this IP set if would

Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20110604/2688c4a6/attachment.pgp>

More information about the tor-relays mailing list