Turnkey Torrents and Swedish Internets

A few months ago, I wrote about using a Turnkey Linux OpenVPN appliance to route network traffic thru Sweden. Since that time I have gotten my BitTorrent machine running. The other post was mostly about getting the VPN tunneling and routing to work. This post will mostly be about setting up the torrent server.

The Turnkey Torrent Server is neat because it’s a minimal Debian machine with a pre-configured Transmission BitTorrent Client, a web interface for managing BitTorrent, a working Samba server, and a webDAV client so you can use a browser to download files. Basically, you use the web interface to grab things, the Samba server to makes them accessible to your media players on your internal network, and webDAV makes the files accessible to the rest of the world, assuming you have the right ports forwarded. My preferred method for watching torrented videos is on a PC plugged into a TV running VLC Media player controlled with a wireless keyboard. I know I should be using Plex and shit like that, but I’m old school.

The Swedish Connection
For some of my friends who aren’t pirates (especially the friends that are into British TV) I am like their coke dealer except I deal in movies and TV shows. That means that sometimes I get asked to find things when I’m not at home. Like a third of my remote access shenanigans, A.K.A. reverse telecommuting, is so that I can pull up BitTorrent and snarf shit for friends and relatives when I’m not at home. Being able to expose the uTorrent remote interface to the web was great for letting my more technical non-hacker friends grab torrents without any assistance from me.

My VPN provider gives me the option of forwarding ports. When I was running uTorrent on a dedicated Windows machine, those forwarded ports were easy to configure. I would just set them up on the VPN site and map them to the ports I configured in uTorrent. One was for BitTorrent transfers to make sure that my ratios reported correctly on private trackers. The other was for the uTorrent web interface. For a long time I ran Windows for torrenting because I used PeerBlock to help me fly under the radar. Times change tho. Real time block lists is old and busted. VPNs is the new hotness. Unfortunately, with this VPN router setup it messes up forwarding ports. When I set up port forwarding on the VPN provider side, the forwarded ports hit the doorway server rather than the torrent server, so that has to be fixed with more IPTables kung fu on the doorway server.

I know I said that I wasn’t going to write anymore about the doorway server, but I lied. I needed to configure the doorway server to open those ports and then forward them to the torrent server. Let’s assume that my internal network is a subnet (a class A block, a range of addresses from to with a default gateway of All of my traffic goes through my local router and hits the Internet from my ISP, in the US. If a device asks for an IP via DHCP, this is the network configuration that it will receive, along with red-blooded American Internets. Here is an awful network diagram because why not?

The doorway server has a static IP of and it’s configured to route all of its traffic through the VPN tunnel to Sweden. Any device that is configured to have a default gateway of will also hit the Internet via the tunnel to Sweden. At this point, all the configuration is done, and your torrent server will work, but there won’t be any ports forwarded to it, which is lame. Now, you could just open a port on your firewall for the web interface on the American side, but that’s also pretty lame. If you want to use your torrent server, you should strictly be using Swedish Internets.

Welcome to Swedish Internet
To forward those ports, first set them up in Transmission, then with your VPN provider. The web interface port [12322] is already configured for you by Turnkey Linux. You can set the other port in the Preferences->Network->Listening Port blank. Once the entry points and the end points are configured, it’s time to do more iptables kung fu.

The web interface is port 12322. Let’s also assume that you set the listening port in Transmission to 9000. Let’s further assume that the static IP for your torrent server is and that the doorway server IP is What needs to happen is for the VPN tunnel interface (tun0) to listen on ports 9000 and 12322, then forward that traffic to Then, you want any traffic on those same ports that comes from the doorway’s internal network interface (eth0) to be modified so that it doesn’t look like it came from the tunnel interface. This is super important for TCP handshakes.

First create your rules for the listening port 9000:

iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 9000 -j DNAT --to-destination
iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 9000 -d -j SNAT --to-source

You can check the port in Transmission and via the web. Just remember your’re scanning the VPN external IP and not your ISP’s external IP. If you can see that port 9000 is open, then you can repeat the process for the web interface:

iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 12322 -j DNAT --to-destination
iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 12322 -d -j SNAT --to-source

Test the ports again, and if it’s working, point your browser to https://the-ip-address-of-your-vpn-server:12322 and you should be prompted to log in to the web interface. If you want to use a port number that is easier to remember, set that on the vpn provider side. If it’s all good, then it’s time to save your working iptables config:

iptables-save | tee /etc/iptables.up.rules

You can skip having to remember the IP by registering it as a subdomain somewhere, either with a dynamic DNS service, or with the registrar for a domain that you own.

In the unlikely event that I made this, or any other technical thing look easy, rest assured that it took me at least a couple hours. Also, I had it working a months ago, but I forgot to update my snapshot and had to redo it again because I am not a smart man. Then during this second go around I had to restore the VM from a backup because iptables just isn’t my bag. Thankfully BitTorrent is my bag. Happy pirating!


Additional Remote Access Shenannegans

In my previous post, I expanded on my preferred methods for gaining remote access to my home network. Since then, I have decided to quit using Hyper-V because it’s awful.

I have now decided to move to ProxMox on my server. Proxmox is pretty cool, although the documentation sucks. I recently started using Linux containers for my remote access servers instead of VMs, which ProxMox supports out of the box. A truly compelling feature of Proxmox is its integration with Turnkey Linux. You can download Turnkey Linux Container Templates directly in Proxmox and spin them up quickly. I used the Turnkey OpenVPN template to rebuild GATE, my OpenVPN server.

The performance improvement is remarkable. On Hyper-V, each Linux VM ate 512MB of RAM just to sit idle 99.9% of the time. So far I have 3 containers configured with 512MB of ram each, but they use roughly 25-50MB each and they leave the rest for the server. PORTAL, my Windows VM, still takes his share of the RAM and doesn’t give it back, but that’s nothing new.

Moar RAM == moar servers!
On the plus side, efficient use of memory means that I can feel better about running a dedicated Linux box (container) for each application. Dedicated boxes mean that when I inevitably screw something up, it doesn’t affect the other applications that are running (that I haven’t screwed up yet.) Also, with pre-built containers and snapshots, you can toss machines that you screwed up without losing much time. I know, I know, rebuilding a Linux box instead of fixing it is sacrilege… but I got other shit to do.

On the minus side, containers don’t really act like VMs, especially when it comes to alternative network configurations. In particular, a Linux Container that uses a TUN or TAP interface needs some extra configuring. The TUN interface is how OpenVPN does its thing, so getting my GATE machine, the OpenVPN server that allows access to the DMZ on my internal network took a lot of fiddling with to get right. I did a bunch of Googling and I ended up with this forum post that recommends rebuilding the TUN interface at boot time with a script.

Here is the TUN script that I have graciously stolen so that I don’t have to Google it again (I didn’t even bother to change the German comments):

#! /bin/sh
# Provides:          tun
# Required-Start:    $network
# Required-Stop:     $openvpn
# Default-Start:     S 1 2
# Default-Stop:      0 6
# Short-Description: Make a tun device.
# Description:       Create a tundev for openvpn

# Aktionen
case "$1" in
        mkdir /dev/net
        mknod /dev/net/tun c 10 200
        chmod 666 /dev/net/tun
        rm /dev/net/tun
        rmdir /dev/net
        #do nothing!

exit 0

Then you enable the script and turn it on:
chmod 755 /etc/init.d/tun
update-rc.d tun defaults

With this script, I was able to stand up a real OpenVPN server (not just an Access Server appliance) for unlimited concurrent connections! Not that I need them. I’m the only one that uses the VPN and most of the time I just use SSH tunnels anyway.

Since OpenVPN container templates make standing up servers so easy, I thought I’d build another one that works in reverse. In addition to GATE that lets OpenVPN clients route in to the DMZ, I thought I would use an OpenVPN client to route traffic from some DMZ hosts out to the Internet via Sweden. In the past, I used a VPN service to dump my Bittorrent box’s traffic this way, but I would like to extend that service to multiple machines. EVERYBODY GETS A VPN!

Öppna dörr. Getönda flörr.
I couldn’t figure out what a machine that does this kind of thing is called. It’s a server, but it serves up its client connection to other clients. It’s a router, but it just has the one network interface (eth0) that connects to a tunnel (tun0). It’s basically setting up a site-to-site VPN, but the other site is actually a secure gateway. This identity crisis led to a terminology problem that made finding documentation pretty tough. Fortunately, I found another pirate looking to do the same thing and stole his scripts 🙂

Since it’s a doorway to a VPN gateway to Sweden, I decided to call the box DÖRR, which is Swedish for “door”. I did this to maintain my trans-dimensional gateway theme (HUB, GATE, PORTAL, etc.)

Also, I would like to apologize to the entire region of Scandinavia for what I did you your languages to make the pun above.

The Turnkey Linux OpenVPN template sets up in one of 3 modes: “Server”, “Gateway”, or “Client”. “Server” is the option I went with for GATE, which allows OVPN clients the option of accessing local subnets. This is the “Server” portion of a Site-to-Site VPN or a corporate VPN. “Gateway” forces all OVPN clients to route all traffic through it, this is the config for secure VPN services like NordVPN or AirVPN. “Client” makes a client connection to another OVPN server. If you connect a “Client” to a “Server” you get the full Site-to-Site solution, but there is no documentation on Turnkey about setting up a “Site-to-Site Client” to route traffic from its internal subnet to the “Site-to-Site Server”.

What I am looking to do is configure a “Site-to-Site Client” but point it to a “Gateway”. Another important consideration when setting this up was that I didn’t want to do any meddling with the setup of my DMZ network. I just want to manually configure a host to use DÖRR as its default gateway. No need for proxies, DNSMasq, DHCP or anything like that. Just static IP’s, the way God intended it 🙂

Step 1 – The Site-to-Site Client
Once I got the container running, I had to fix the /dev/tun problem (the script above) and then make some config changes to OpenVPN.

Because this is a VPN client, and not a server, you need to get the OpenVPN client profile loaded. The bulk of my experience with OpenVPN clients is on Windows where you start the client when you need it. For this application you need to automatically run the OpenVPN connect process at boot and keep it running indefinitely.

First, you need to obtain a client config. I downloaded my ‘client.ovpn’ file from my VPN provider, and I copied it to /etc/openvpn/client.conf as root. You can name the files whatever you want, just remember what you named them because it’s important later.

cp /root/client.ovpn /etc/openvpn/client.conf

Now test the connection to make sure everything worked

openvpn --config /etc/openvpn/client.conf &

The & is important because it puts the OpenVPN process into the background, so that you get your command prompt back by pressing ENTER a couple of times. You can then test your Internet connection to see what your IP is a few different ways. You can use SSH with a dynamic port and tunnel your web traffic thru it with a SOCKs proxy. You could use curl or lynx to view a page that will display your IP. Or you could just use wget. I like to use ifconfig.co like so:

wget -qO- ifconfig.co

If all goes well, you should see your VPN provider’s IP and not your ISP’s.

Once you get the VPN client working, you then want it to start up and connect at boot time. You do this by setting the ‘autostart’ option in /etc/default/openvpn.

nano /etc/default/openvpn

If you changed your ‘/etc/openvpn/client.conf’ filename, you change the name here. The AUTOSTART value is the name of that file minus the ‘.conf’

Now reboot your server and do your wget test again to make sure that the VPN connection is starting automatically.

Once that is working, you have to route traffic. This means IPTables, because OpenVPN and IPTables go together like pizza and beer.

Step 2 – De Routningen

Normally to route traffic between interfaces on Linux, you have to add IP forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward etc.) In this case, the Turnkey OpenVPN template has already done that for you. All you have to do add a few forwarding rules:

iptables -A FORWARD -o tun0 -i eth0 -s -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE

Now it’s time to test them. For this you need a client computer with a static IP. For the default gateway you want to use the static IP that you assigned to eth0 on your VPN doorway server. I used for DÖRR. If your test box also shows your VPN provider’s IP when you access a site like ipleak.net then it’s time to make those rules permanent. By saving them to /etc/iptables.up.rules. It is important to save them to that specific file because the Turnkey template calls that file when setting up the eth0 interface in /etc/network/interfaces.

iptables-save | tee /etc/iptables.up.rules

I don’t know why it’s set up that way. I’m just here to make awful jokes about Germanic languages.

Once that’s done, reboot the doorway server one last time and test with your client computer with the alternate default gateway.

Now that the my VPN client is working again, I need to rebuild my BitTorrent machine. I am going to try to save some more RAM by going with another Turnkey Linux container template.

EDIT: In my elation over getting something to work, I forgot to change the default gateway back. Unfortunately my test machine was PORTAL, which happens to control my dynamic DNS. So currently all of my hostnames are pointed at Sweden, LÖL.

Using Lubuntu as an HTPC

lubuntu.sh-600x600I recently switched my Home Theater PC from Windows 7 to Lubuntu. For several years, I have had a box plugged into my TV to play videos downloaded via BitTorrent. 10 years ago, that box was an original XBox, modded to run XBox media center. After that, it was a small Atom powered PC running Windows XP and playing videos via VLC. In the shift from XBMC to Windows, the HTPC evolved from an AVI player into a machine that performs the following functions:

  1. Playing video and music downloaded from BitTorrent
  2. Playing video and music from streaming services like Netflix, Pandora, and Amazon Prime
  3. Playing random videos from sites like Youtube
  4. Rudimentary video conferencing via Skype and a webcam
  5. Rudimentary VOIP via microsip and the mic from the webcam

When I switched from the XBox to a PC, I quit using a media center front end. The family is competent and comfortable using Windows, so using a wireless keyboard with a built in trackball was “good enough”. Most of the functions could be performed with either VLC or Google Chrome. The HTPC also worked consistently and predictably, which is important. We lived together in harmony. Then, everything changed when the Fire Nation attacked Microsoft ended support for Windows XP.

When I reloaded the HTPC with Windows 7 32 bit, the PC’s hardware was no longer up to snuff. It hard drive paged constantly, and streaming media playback was very choppy. I even let the box upgrade to Windows 10 because it’s supposed to be faster. I was reluctant to switch from Windows because I had grown accustomed to DRM’ed streams from Netflix and Amazon via Silverlight. Fortunately, Google Chrome has it’s own dark sorcery built into it that lets Netflix… well, Netflix.

over9000There are over9000! lightweight Linux distributions, and I am sure there are plenty of great arguments for your favorite flavor, but I went with Lubuntu because LXDE is kind of like Windows XP in terms of look and feel. You can put icons on the desktop, which simplifies just about everything, so Lubu and Google Chrome give me most of what I want from my HTPC. I don’t know if Chromium has the dark sorcery rolled into it to enable Netflix, so I went with Google Chrome. Installing Lubuntu was straight forward, I was fortunate in that the PC was really basic, so there was no hardware drama. VLC was a breeze to setup thanks to Lubuntu Software center, but it turns out that Gnome Movie player is fairly capable on its own. One caveat: you might be tempted to use the alternate install, because it fits on a regular CD rom, DON’T. If you want your HTPC to log in automatically, the option to enable that is in the graphical installer, not in the alternate installer. I am sure there is some sort of Config File Fuckery(tm) that makes all Linux things possible, but I could not find it. So do yourself a favor and burn a DVD or make a thumb drive and use the graphical installer.

The wireless keyboard is fine for occasional use, but it’s not great for fast and accurate typing. So the first thing I did was install SSH on the TV box so I could use my laptop to type the rest of the commands necessary. In Lubuntu, you can press Ctrl+Alt+T to bring up a terminal window. In the terminal I typed the following:
sudo apt-get install openssh-server

The first step was getting Google Chrome installed. Downloading the .deb package from Google didn’t work, so I went with this handy bit of wisdom from the AskUbuntu Forums:
sudo wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
sudo apt-get update
sudo apt-get install google-chrome-stable

Google_Chrome_for_Android-_Android_5.0_LogoWith Chrome set up, the box plays streams from Netflix, Amazon, and YouTube smoothly. Now it was time to make file copying to the HTPC simple. I have a dedicated Windows box running UTorrent and Peer Block for downloading torrents. I should switch to Linux, rTorrent, and Moblock, but the Windows setup works, and keeps me out of trouble with my ISP, so I stick with what works.

Sharing files between Windows and Linux is best done with Samba:
sudo apt-get install samba
sudo smbpasswd -a myuser // where myuser is your Linux username

Now, it’s time to edit the Samba config and export the home directory. I chose to do this so that on the HTPC I can put videos in the Videos folder and music in the Music folder, and so on:
sudo nano /etc/samba/smb.conf

Locate the Share Definitions section and un-comment the following lines:
# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares. This will share each
# user's home directory as \\server\username
comment = Home Directories
browseable = yes

# By default, the home directories are exported read-only. Change the
# next parameter to ‘no’ if you want to be able to write to them.
read only = no

# File creation mask is set to 0700 for security reasons. If you want to
# create files with group=rw permissions, set next parameter to 0775.
create mask = 0775

# Directory creation mask is set to 0700 for security reasons. If you want to
# create dirs. with group=rw permissions, set next parameter to 0775.
directory mask = 0775

When you are done editing, restart the Samba service:
sudo service smbd restart

What this does is allow me to map a drive in Windows to \\htpc\htpc-user and see the folders in the home directory for my HTPC user. It also disables a fair amount of the file system security for the sake of convenience. I do not recommend doing this with a file server that has multiple users, or that does anything other than share stupid files like videos and music that you need to add and delete on a regular basis. Some day I will get my torrent box moved to Linux, and use NFS to mount the video folders so BitTorrent can put them directly on the TV box, but for now, Samba makes it easy to do with Windows.

I connect to the torrent machine with Team Viewer to do all my downloading and uploading. This way I can connect from work, school, or where ever. I have LAN connections enabled so that connections and file transfers are faster between machines on my home network.

The last step is to install Unified Remote so that I can use my tablet or smartphone to control the HTPC. This comes in handy when the batteries in the wireless keyboard are dead, or when my 3 year old daughter has hidden the it at the bottom of her toy box. It also can lead to fun battles for control over the TV. I use my phone to troll my 14 year old as she tries to navigate to her Korean boy band videos on YouTube.

Unified Remote works best when your “servers” (the boxes you want to control) have IP’s that don’t change. There are two ways to achieve this: first is to set a static IP for your HTPC, the other is to set up a DHCP reservation on your router, where your HTPC always gets the same IP when it requests one. Setting a static IP using the Lubuntu network manager is probably straight forward, but I went with the DHCP reservation route. I use reservations for my laptops so I can get a static IP when I’m at home, but I don’t have to mess with my IP settings when I leave home.

easy-peasy-8To install Unified remote do the following:
wget -O urserver.deb http://www.unifiedremote.com/d/linux-x86-deb
sudo dpkg -i urserver.deb
sudo /opt/urserver/urserver-start

This downloads the software installer, installs it, and then starts the Unified Remote Server Service. Easy peasy lemon squeezy.

And that kids, is how I met your mother set up your HTPC.