[tor-relays] High speed Relays/Exit nodes

[Dennis Ljungmark]

Excellent!
Right now it seems they procured an (as of yet, for me) unknown piece of
Juniper hardware for this case. It may be that I'll simply have to have
that on the office net and route the Tor nodes outside it, if it cannot
keep up with the load.
Currently I don't know the version/kind of hardware, looks like I'll find
that out on Monday when I get back to the office.

Regards,
  D.S.

On Thu, Aug 2, 2012 at 8:57 PM, Pascal <Pascal666 at users.sourceforge.net>wrote:

> The specs manufacturers publish for firewalls are typically best case and
> combined throughput.  So if the specs say 1.2 Gbps throughput, this means
> 600mbps each way, best case (max MTU packets, etc.).  In order to guarantee
> 1Gbps each direction real world, you should look for a firewall rated for
> at least 4Gbps.  I'm a bit of a Cisco bigot, which means the ASA 5555 or
> ASA 5585 would be my recommendation.
>
> Even though you only have "a single fiber incoming", you still should be
> able to split the tor nodes from your corporate network.  Simply put a
> switch on the fiber and connect your existing firewall and Tor nodes
> directly to it.  If you really want a hardware firewall in front of your
> Tor nodes as well, you can use a less expensive firewall just for them.  A
> Cisco PIX 535 can be picked up off of eBay for around $300, and is rated at
> 1.7Gbps (850mbps each way, real world maybe 5-600mbps).  As your Tor nodes
> should not be talking to each other, only to Tor nodes not in your family,
> you could easily put a separate cheap firewall in front of each node rather
> than having one big firewall for everything.
>
> -Pascal
>
>
>
> On 7/26/2012 1:08 PM, Dennis Ljungmark wrote:
>
>> Dennis Ljungmark:
>>> > Hi,
>>> >   We're currently running 6 different 100-200Mbit relay/guard nodes,
>>> and
>>> > are looking at some issues moving on towards high performant exit
>>> nodes.
>>> >
>>> >  Right now, with iptables modifications ( raw tables hacks to disable
>>> > conntrack, bucket increases, following the general best practices ) our
>>> > firewall is running at high amounts of CPU, but coping.  However, once
>>> we
>>> > start introducing Exit Nodes into this equation, things turn sour.
>>> >
>>> > So, since we do not want to trust only routing level separation between
>>> > Exit Nodes and internal networks, we're going to have to invest into
>>> new
>>> > hardware that can cope with this.  Before this, we tried Ingate
>>> firewalls,
>>> > and they weren't capable of coping with the load of guard nodes.
>>> >
>>> >   ( The traditional "linux box in front" doesn't quite cut it due to
>>> > networking hardware in most cases. )
>>> >
>>> > So,
>>> >   in summary,  when you get to the point of actively dealing with
>>> 8-900Mbps
>>> > of Tor traffic ( on top of normal users and others) what hardware is
>>> needed
>>> > to cope with firewalling?
>>> >
>>>
>> Note here that the tor nodes
>>
>> are not our current bottleneck, so SSL Decoding/OpenSSL isn't part of the
>> problems here. We're getting 200Mbps without trouble, but the network
>> cards
>> in the current firewall   (separate from the Tor nodes) is capping out at
>> ~800Mbps.  ( Not good enough imo, but another issue )
>>
>> The problem that I have is that the current i686 (32bit) firewall  cannot
>> cope with the connections once we move into exit node land.
>>
>> Due to other network issues, we cannot "carte blanche" disable connection
>> tracking ( Fex. Traffic from Tor exit nodes to other corporate networks
>> need to be tracked,  as well as corp net / public wifi need tracking and
>> tracing )
>> ( Since it's all on a single fiber incoming, we don't have the option of
>> physically separating them. )
>>
>> //D.S.
>>
>
> ______________________________**_________________
> tor-relays mailing list
> tor-relays at lists.torproject.**org <tor-relays at lists.torproject.org>
> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**relays<https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20120803/5c91d27f/attachment.html>