[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
> (, 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 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).