Mon Jul 30 02:09:32 CEST 2012

Running your own Tor wireless network

Sometimes you just want to provide a completely open wireless network for poor lost souls passing by your neighborhood in search of a way back home. Or for guests you don't necessarily want to give direct access to your internal network, since you cannot fully trust them to still respect a code of conduct at the end of your party.

In some legislations, it's completely acceptable to operate an open wireless network which everybody can access. However, in other legislations, it may not be legal to do so. Germany, for example, will hold you liable for any illegal activity performed from your open wireless network.

Legally, there's not much you can do there. The procedure outlined in this blog entry will make it less likely that abusers of your wireless networks can be traced back to you. So this is not a legal advise to use this procedure, in fact it is strongly discouraged. But in case you're curious, this is how it works.


To implement such an anonymized wireless network, you will need a few things:

  • A wireless access point which supports 802.11 networking
  • A router behind your access point
  • The following software packages:
    • tor — Anonymizing overlay network for TCP
    • privoxy (optional) — Web proxy with advanced filtering capabilities
    • redsocks — Redirect any TCP connection to a SOCKS or HTTPS proxy server
    • ISC DHCP server — ISC DHCP server for automatic IP address assignment

Setting up Tor with transparent DNS

As a first step, you will of course need to set up Tor on your router. The important settings are (replace with the IP address of your router in the wireless VLAN):

SocksPort 9050 # Start a socks4a proxy on port 9050
SocksListenAddress # Listen only on the wireless interface
SocksPolicy accept # Permit only connections from the local network
SocksPolicy reject * # Reject everything else
RunAsDaemon 1 # Run detached and continuously
DNSPort 9053 # Relay DNS queries through the Tor network on port 9053
DNSListenAddress # … and open it only to the wireless network
AutomapHostsOnResolve 1 # Use local addresses to map .onion or .exit destinations in DNS
AutomapHostsSuffixes .exit,.onion # Send .exit and .onion to the mapped addresses

# The following line is very important. Since we're using Tor separately # for DNS, we'll get swamped in error messages saying we're connecting to # an IP, not a name, and that we may leak DNS queries. We clearly won't, # since we're using Tor for DNS.
WarnUnsafeSocks 0

[… Regular Tor configuration …]

Once this is done, you should be able to connect to port 9050 on your router and send traffic through the Tor network. Now you need to redirect all incoming DNS traffic to port 9053. Under Linux, the corresponding iptables rule is (replace eth6 with your wireless network interface):

% iptables -t nat -A PREROUTING -i eth6 -p udp -m udp --dport 53 -j REDIRECT --to-ports 9053

You will only need to permit traffic to port 9053 then:

% iptables -A INPUT -d -i eth6 -p udp -m udp --dport 9053 -j ACCEPT
% iptables -A INPUT -i eth6 -j REJECT --reject-with icmp-admin-prohibited
% iptables -A OUTPUT -s -o eth6 -p udp -m udp --sport 9053 -j ACCEPT
% iptables -A OUTPUT -o eth6 -j REJECT --reject-with icmp-admin-prohibited

Now you'll only be able to send traffic to port 53 of your router and nowhere else in the world. We'll fix that in the next section.

Sending TCP traffic to Tor transparently

Now you need to play some tricks so your network traffic is actually going to Tor without using Socks explicitly. The redsocks package provides such functionality: it's a transparent network listener which redirects traffic to a Socks proxy.

The setup is relatively straightforward, but you can only redirect the capture for TCP because Tor doesn't support UDP traffic. So in a nutshell, the configuration looks like this:

base {
        log_debug = off;
        log_info = on;
        log = "syslog:daemon";
        daemon = on;
        user = redsocks;
        group = redsocks;
        redirector = iptables; // If not Linux, use something else.

redsocks {
        local_ip =;
        local_port = 12345;
        ip =;
        port = 9050;
        type = socks4;

Now we need to use our firewalls again to get all traffic to flow through redsocks:

% iptables -t nat -A PREROUTING -i eth6 ! -d -p tcp -j REDIRECT --to-ports 12345
% iptables -I INPUT -d -i eth6 -p tcp -m tcp --dport 12345 -j ACCEPT
% iptables -I OUTPUT -s -o eth6 -p tcp -m tcp --sport 12345 -j ACCEPT

It's very important that you exempt traffic going to your router from this so we can still make connections to the services sensibly. All the other traffic is now going to flow through your Tor router.

Optional: clean HTTP traffic of requester patterns

You may want to purge all kinds of information about the original requester from any HTTP traffic going through your wireless as well. HTTP is one of the most important protocols nowadays, and every request has the potential of leaking information about you and your users. privoxy is an HTTP proxy especially designed for this.

The gain is only partial, as you obviously cannot filter HTTPS requests. But it's a start. The config for privoxy must contain:

forward-socks4a / .
accept-intercepted-requests 1 # Very important: do transparent filtering
connection-sharing 1 # We don't want to put more load on Tor as necessary

Now take the traffic to port 80 and send it to privoxy:

% iptables -I PREROUTING -i eth6 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8118
% iptables -I INPUT -d -i eth6 -p tcp -m tcp --dport 8118 -j ACCEPT
% iptables -I OUTPUT -s -o eth6 -p tcp -m tcp --sport 8118 -j ACCEPT

Now you cannot have non-HTTP connections to port 80 anymore, but your HTTP traffic gets cleaned from information you wouldn't want to leak.

Client configuration using DHCP

Now you need to automatically configure clients on your Tor network. Typically, Route Advertisements would be used for that nowadays, but Tor doesn't support IPv6 yet (which you may have noticed when you tried to resolve AAAA records through Tor). So, you're back to good old DHCP.

The important parts of the DHCP configuration:

default-lease-time 600;
max-lease-time 7200;


subnet netmask {
  option routers;
  option domain-name "";
  option domain-search "", "";
  option domain-name-servers;

The piece that's missing here now is the access from the Tor network to the DHCP server, and that's easy: DHCP always sends requests from the bootpc port to the bootps port, either from to or from the server IP ( to the client ( So the rules are:

% iptables -I INPUT -p udp -m udp -s --sport 68 -d --dport 67 -j ACCEPT
% iptables -I INPUT -p udp -m udp -s --sport 68 -d --dport 67 -j ACCEPT
% iptables -I OUTPUT -p udp -m udp -s --sport 67 -d --dport 68 -j ACCEPT
% iptables -I OUTPUT -p udp -m udp -s --sport 67 -d --dport 68 -j ACCEPT

Make the configuration permanent

The last thing you'll need to do is to save the configuration to disk so it can be loaded again on the next reboot. There are different ways to do that on different operating systems and distributions. Under BSD, you will already have the configuration in your pf.conf.

If you're using Linux and iptables, one way would be to attempt

% /etc/init.d/iptables save

Debian doesn't have this facility, but you can write the rules file directly:

% iptables-save > /etc/iptables/rules

Most distributions have some kind of rules file like this. Find it, write it, be done with it. There's your transparent Tor wireless!


The only thing that's left now is testing: take your laptop, join the Tor wireless network, and navigate your browser to or something like that. You should see an IP which is completely different from your own one.

Posted by Tonnerre | Permanent link | File under: wireless, howto