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

Re: funneling a wireless net's outbound connections through tor



On 9/28/07, Scott Bennett <bennett@xxxxxxxxxx> wrote:
>      I'm trying to set up a free wireless service for those of my neighbors
> within range of a little wireless router I have.  To keep things safe for
> me and at least somewhat safer for them, I want to route all the outbound
> connections from that router through tor using pf under FreeBSD 6.2-STABLE
> (i386).  In order to keep such traffic distinguishable from my own local
> traffic, I intend to route it to tor on a second loopback interface (lo1).
> I've looked at instructions for doing something like this at
>
>         http://wiki.noreply.org/noreply/TheOnionRouter/TransparentProxy

The second loopback interface is simply a kludge I found that allows
pf to apply rdr rules to locally-originated traffic. You don't need it if
you're only trying to redirect others' traffic; see section 3.2 in that
wiki page.

>      dns-proxy-tor apparently uses the MAPADDRESS command via the tor
> control port, so it is also necessary to specify a VirtualAddrNetwork in
> torrc for dns-proxy-tor's use, so those instructions include an example of
> VirtualAddrNetwork.
>      However, I had been hoping to use DNSPort in torrc instead of running
> dns-proxy-tor.  Am I correct in thinking that I will not neet to specify a
> VirtualAddrNetwork?

You'll still want to set VirtualAddrNetwork to an unused, private
address space so that .onion and .exit names will resolve to routable
addresses when you specify 'AutomapHostsOnResolve 1'.

>      A second question for someone who uses or has used pf under FreeBSD
> or OpenBSD involves the use of rdr commands to redirect the TCP connections
> from the interface connected to the wireless router's "WAN" port.  If the
> rdr changes the TCP or UDP packets' destination addresses to lo1's address
> (127.0.0.2), how does tor know what the original destination is supposed
> to be?  I didn't find anything in the tor documentation or elsewhere to
> explain this.

This is a platform-specific implementation detail, which explains why
it's not documented. What happens is that the route-to rule routes
traffic to lo1, where the rdr rule actually rewrites the destination
address and port to 127.0.0.1:9040. The original destination is kept
around in the connection state table, so it can be looked up by Tor
with the right ioctl(2) command on /dev/pf; see pf(4).

tup