[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] corridor, a Tor traffic whitelisting gateway

14.02.2014 18:29, Rusty Bird:
> Sebastian G. <bastik.tor>:
>> 14.02.2014 15:12, Rusty Bird:
>>> 2. That data gets sent to corridor-helper-update, which atomically
>>> updates a Linux ipset (a list of IP-address:TCP-port entries accessible
>>> in constant time) named tor_relays.
>> Atomically is anatomically acceptable, but automatically appear to be
>> adequate.
> :) It really is "atomically" though: tor_relays contains either the
> complete old consensus or the complete new consensus, never an
> in-between state.
>>> **To be secure, your new gateway needs two separate network
>>> interfaces**, like two Ethernet NICs, or one WiFi radio and one DSL
>>> modem. One is to receive incoming traffic from client computers, the
>>> other one is to pass the filtered traffic towards the global internet,
>>> **and they need to be on different networks**: Clients must not be able
>>> to take a shortcut via DHCP, DNS, ICMP Redirect requests, and who knows
>>> what else.
>> Isn't this the most limiting factor?
>> How many systems have two separate networks?
> Private network address spaces are fine. I think I may be using
> nonstandard networking terminology?

I'm an end user, not familiar what's standard terminology.

> For example, my corridor box has a builtin Ethernet port (
> where the protected client computers connect to, and another cheapo
> Ethernet adapter ( plugged into the USB port, talking to my
> regular modem/router ( The two networks are
> and

I just misunderstood how it was supposed to be.

> How should I rephrase the documentation?

This should not be based on my feedback, alone. I think it was just a
mistake on my side.

> Rusty


tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to