No Security

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.

Requirements

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 192.168.1.1 with the IP address of your router in the wireless VLAN):

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):

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

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 = 192.168.1.1;
        local_port = 12345;
        ip = 192.168.1.1;
        port = 9050;
        type = socks4;
}

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

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:

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

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:

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 0.0.0.0 to 255.255.255.255 or from the server IP (192.168.1.1) to the client (192.168.1.0/24). So the rules are:

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

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

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

Testing

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