How does Tor transparent proxying work?

Question

I would like to configure my wireless router as an "anonymizing middlebox" for guests. I have read the directions here.

The tutorial, as I understand:

• Creates a wireless network and assigns it to a firewall zone named 'transtor'.
• It then adds rules to REJECT all incoming and forwarding traffic.
• ACCEPTs incoming traffic to UDP port 67 for DHCP.
• ACCEPTs incoming TCP traffic to Tor's transparent proxying port and DNS proxy port.
• Then configures PREROUTING redirections (using firewall.user) to REDIRECT all DNS requests to Tor and all TCP traffic to Tor's transparent proxying port.

The thing I don't understand is in the last bullet. As far as I understand:

1. The client wants to connect, say, to google.com:80, therefore it looks the address up. The DNS request gets redirected to Tor's DNS port, which then returns Google's IP.
2. The client then tries to connect (IP of Google):80, which the firewall REDIRECTs to (IP of Google):9040. The SYN packet then gets rejected by the router, because it would be forwarding traffic.
3. If (by some miracle or DNS trickery) Tor would actually get the packet, how would it know to what port the packet was originally destined to? Or to what host, for that matter; the packet now has (router's IP):9040 as its destination.

I don't ask for a solution to a problem, I just want an explanation on how this particular setup is supposed to work and what I am missing. In the 3rd point I considered the case in which Tor's DNS always returns its own IP, but then how does it know what host:port the new incoming SYN is for?

Thanks in advance for answers. Also, I have already asked this question on Network engineering, where it was closed as off-topic. If this is also not the right place to ask this question, please kindly tell me so before closing and offer an alternate place if possible.

Answer 1

I have solved this question. Source; an extensive iptables manual.

The REDIRECT target puts the stream into the conntrack table, and rewrites the destination host to that of the machine itself. That was one thing I was missing. This circumvents the firewall; so even if normally no packages would reach the machine at the defined port, the packet/stream matched by this rule will.

The rule iptables -t nat -A PREROUTING -i wlan0 -p udp --dport 53 -j REDIRECT --to-ports 9053 matches all DNS requests, no matter if they were destined to this machine or not. It routes them to the tor daemon, which answers them with the real DNS record (or, for .onion domains, it maps them to an arbitrary IP).

The other rule; iptables -t nat -A PREROUTING -i wlan0 -p tcp --syn -j REDIRECT --to-ports 9040 catches all SYN packets of forwarding TCP traffic, then REDIRECTs them into the transparent proxy port of the tor daemon. Then the daemon - I only suspect, but really there isn't another way I know of - checks the conntrack table, so it knows where this particular stream was headed and makes the connection. The rest of the packages are in the ESTABLISHED state, so they follow the route which has been built. This was the other thing I was missing.

Answer 2

ok I think I see what your questions are. The scenario with following the directions above will actually work, although they are a bit outdated as the directions state. I think what you are missing is in step 2 of your 'last bullet' section of the question; after dns resolution through tor the packets are not forwarded but directed to tors local ip on port 9040. In the example in the documentation this is 10.192.0.1:9040 which then takes googles ip and port 80 and requests that information over tor, not (IP of Google):9040

Thats why the iptables rules in the tutorial begin with the PREROUTING switch, the packets are not modified, but encapsulated. Thats why its called a transparent proxy, the browser dosen't even know the packets are being forwarded over tor.

That may not be the best explanation of how it works, but I can attest to the fact that it does work as I have personally tested.

Answer 3

If you are properly resolving dns thats not the source of the problem. Have you added rules to the iptables to forward dns requests coming from the wifi network to port 9053 instead of 53? If not you could be leaking dns requests over the clearnet. Not all versions of openwrt allow port forwarding by iptables by default, usually you will need to install a few packages like iptables-mod-nat and iptables-mod-nat extra, but not if you are using a version of openwrt newer than 12 as its built in.

The first thing I'd do to test is make an example firewall rule to forward another port, if you are using 22 for ssh for example add a rule that redirects tcp traffic from the wifi to port 99. Restart the firewall and then see if you cn ssh in using that port. If it dosent work, you know it is a firewall issue and iptables is probably not forwarding the other ports properly either.

If that is wokring properly the next thing you would test is tor, try a telnet conenction from the wifi to port 9040 to see if that is responding.

Honestly I have found it is usually easier to torify the whole LAN, since it is by default a bridge to the wifi. Shut off the routers native dns server in dnsmasq and then just configure your torrc to listen on port 53 instead. That saves you one firewall rule and guarantees there is no dns leaks.