Thursday, April 10, 2014

More slight downloading inconveniences in the digital age

The Netherlands forbids downloading of IP-protected material

Today, the news broke that, as of today, the downloading of IP-protected material has become illegal in The Netherlands. Uploading has been illegal for some time, but now an EU court has ruled that downloading is illegal, too.

How ever so slightly inconvenient.

How utterly useless.

Let's fix it right away.

What is the goal here?

Although I live in Switzerland, where IP laws are a lot saner, and where downloading of music and movies for personal use is allowed, this news annoyed me, so I decided to fix the issue once and for all.
In this post, I show how to route a complete subnet from your home network through a VPN provider, so that its traffic surfaces in a country with poor IP protection. See, e.g., the 2013 IP ranking list (the bottom part, that is) for some suitable countries; there are plenty to choose from.

Step 1: Choose a VPN provider, preferably OpenVPN

There are plenty of alternatives here. I chose HideMyAss for this experiment, mainly because they have servers in many countries, and they accept payment in Bitcoin.

Step 2: Edit the OpenVPN config file, to prevent all of your home-network data from being routed through the VPN

Although you're of course welcome to route all of your data through the VPN, this is not recommended for two reasons:

  1. It will generally be slower than your "open" connection.
  2. It is bad privacy practice to run both your identifiable data (email, etc.) and your file-sharing traffic through the same end point.
I blogged earlier in a lot of detail on how to do this. In my case, I used a default HideMyAss OpenVPN config file, and commented out the "route-metric 1" line. Then, I added a "route-noexec" line to prevent the VPN server from pushing routes on me. I also replaced the "auth-user-pass" line with "auth-user-pass hma.pass", where hma.pass contains my login and password (each on a separate line) to automate the login process. Finally, I replaced the "dev tun" line with "dev tun-hma", so that I have a stable TUN-device name whenever I connect to this VPN.

On my Debian gateway server, I copied this file to /etc/openvpn, so that it starts at boot. If you want to start it right away, issue an /etc/init.d/openvpn restart.

Step 3: Route your outgoing traffic from your file-sharing subnet through the VPN.

In my case, I added a new VLAN to my home network; VLAN #6, which runs network 192.168.6.0/24. I will use Linux Source Routing to route only VLAN6 traffic, and then only outgoing traffic, through device tun-hma.  I added the following rules to my /etc/rc.local file to achieve this:


# Route traffic from the file-sharing network to our own
# network via normal tables.
/sbin/ip rule add from 192.168.6.1/24 to 192.168.1.1/16 lookup main prio 200
# Route all other traffic from the file-sharing network
# through table "3", which, in turn gets routed through HMA.
/sbin/ip rule add from 192.168.6.1/24 lookup 3 prio 201
/sbin/ip route add from 192.168.6.1/24 dev tun-hma table 3
# Traffic via HMA must be NAT'ed.
/sbin/iptables --table nat -A POSTROUTING -o tun-hma -j MASQUERADE

And that's it. The first "prio 200" line is actually fairly critical: it ensures that your filesharing network is able to connect to other machine on your home network through the default routing tables. That is convenient, since you'll possibly want to save files that you download to NFS, or elsewhere on the local network. The "prio 201" line (where 201 means a lower priority than 200) then routes traffic that does not match the "file-sharing net to other local nets" rule through the VPN. The number 3 is arbitrary. 

Step 4: (optional) Add some more plumbing

Im my case, the new VLAN is also sent to my Xen host machine, using 802.1q tagging. Inside the Xen host, I run a software bridge that bridges the VLAN to my main up/downloading machine. And that's it: I now upload and download in another country.