Raspberry Pi: Creating a secure torrent client

Recently, I was made a gift of a Raspberry Pi project computer, and I’ve been going nuts ever since doing numerous projects with it. None of them are particularly unique, because this is basically a Linux computer, so I could do any of these projects on a regular computer. However, the fun thing about the Raspberry Pi is that it can be a small device that is focused on doing one thing, with a small physical and energy footprint. (This particular project could also be applied to a regular Linux-based desktop computer, but this tutorial will be Pi-focused in some of it’s aspects.)

Covering Your Tracks

The key element of this tutorial is creating a “secure” presence on the Internet for file sharing. In my case, I will be relying on a commercial organization to provide me with that security (i.e., a Virtual Private Network) and I will be configuring my Pi to use that VPN. There are other methods of securing your Internet presence, but I will not be covering them here. Google is your friend. (Well, Google used to be your friend before the NSA.)

It’s also possible to use an established VPN as your primary interface to the Internet, and cover all your presence for more than just file sharing (for example, for your Web browsing activities as well). I will also not be going into this, and would probably not recommend using a Raspberry Pi as your primary gateway in this case, since it likely won’t have the horsepower (even being overclocked) to deal with the heavy encryption/decryption activities required. A full sized desktop-level machine would serve that action much more smoothly.

For my VPN, I will be using a service provided by http://www.privateinternetaccess.com, and will be configuring my Pi for that service’s requirements. If you choose some other avenue for your VPN solution, you’ll need to make the appropriate adjustments to what will be presented here.

The Ingredients For Your Pi

I assume that you have a Raspberry Pi (I think mine is a first-gen, 256MB board), and that you’ve taken all the necessary steps to get an operating system up and running on your board, and to get its base install current. For this tutorial, I will be using a Raspbian “wheezy” build from May 25th 2013 (as of this writing, there is a build available from July 26th). In addition, your board should have some kind of access to your local network, which itself has access to the Internet. This can either be wired (preferred if you intend to use some kind of shared network storage), or wireless via a dongle.

Updating your Pi’s operating system is fairly easy once you have established network access. These two commands will make sure your Pi is current and ready to go:

pi@torrentpi ~ $ sudo apt-get update
pi@torrentpi ~ $ sudo apt-get dist-upgrade

Be aware that this may take a while. The “dist-upgrade” can take quite a while with an older release of Raspbian (my May 25th 2013 release took more than 18 minutes as of this writing); a newer release may not take as much time to update.

Once your base system is ready, you’ll need to add a few more tools to your system. We’ll be using “OpenVPN” to establish our secure Internet connection, and “transmission-daemon” as our torrent client. These can be installed with apt-get:

pi@torrentpi ~ $ sudo apt-get install openvpn resolvconf transmission-daemon

You’ll notice an additional package in there (“resolvconf”). This was added because it a suggested additional package for the “openvpn” install.

Once you’ve installed these additional packages, a reboot will start up these new tools. However, the default install will leave you vulnerable. We’ll see why in a bit. First, though, let’s get the OpenVPN configured and tested.

Establishing Your Torrent Client

The Transmission daemon provides its own web server, making it wonderfully accessible from any Web-capable device. However, before you can bring it up, some default settings will have to be modified. By default, it’s only configured to allow access from the local machine where it runs. We need to change that for easier access within our home network.

First, you will need to shutdown your transmission-daemon process (it was started automatically by the install). If you don’t, it will overwrite any changes you make to its settings file when it stops later:

pi@torrentpi ~ $ sudo /etc/init.d/transmission-daemon stop

Open the file “/etc/transmission-daemon/settings.json” for editing, and change the line identified by “rpc-authentication-required” from “true” to “false”:

"rpc-authentication-required": false,

Additionally, change the line that establishes an “rpc-whitelist” from its default of “127.0.0.1” and add the subnet for your local home network. For example, if your home network is using the subnet “192.168.1.*” to assign IP addresses (e.g., “192.168.1.100”), then add this to the setting, preceded by a comma:

"rpc-whitelist": "127.0.0.1, 192.168.1.*",

And then restart your transmission-daemon process:

pi@torrentpi ~ $ sudo /etc/init.d/transmission-daemon start

This should be enough to make the Transmission client interface accessible to your Web browser using the URL “http://<device>/transmission/web/”, like so:

Transmission Client Interface

Establishing Your Tunnel

If you following the steps above, your OpenVPN system is now installed, but it is not running properly until you configure it. As I mentioned previously, I’ll be using a commercial VPN service provider. What I’ve not mentioned previously is that I am by no means an expert on VPNs. They can be some scary things to create and maintain, and I am not here to masquerade (pun intended) as somebody who knows them intimately. However, drawing upon many sources, you can establish one with little-to-no pain at all.

The OpenVPN configuration files (will) exist in the /etc/openvpn folder. This folder is created for you when you install OpenVPN, and its default state is virtually empty:

OpenVPN folder after install

This means that you have no VPN active, even though the install attempts to start it. We will need to populate this folder with files and settings before the VPN will be active on your Pi. We will be creating many, the OpenVPN daemon will be searching this folder for files that end with the “.conf” extension. It will assume that each one it finds is a configuration for a specific VPN connection. So, our first (and only) VPN configuration will be called “pia.conf” (for “privateinternetaccess”), and will have the following contents:

client
auth-user-pass userpass.data
management 127.0.0.1 5001
management-log-cache 50
dev tun
proto udp
comp-lzo
fast-io
script-security 2
mtu-disc yes
verb 4
mute 5
cipher bf-cbc
auth sha1
tun-mtu 1500
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
remote-cert-tls server
log-append /var/log/piavpn.log
ca ca.crt
status-version 3
status status
daemon
route-up route-up.sh
down down.sh
remote nl.privateinternetaccess.com 1194

I will not go over each individual entry; you can research the meaning of each by Googling “OpenVPN configuration files.” Instead, I will address the entries that are most salient to our discussion.

The “auth-user-pass” entry indicates an external text file that contains the username and password required to log into the VPN server (listed later in the configuration file). This text file contains the username on the first line, and the password on the second, and should be the values required by your VPN service provider. Note: this account information is stored in clear text form, so make sure you set permissions on the file such that it is only readable by the owner. (See the populated directory listing below.)

In my case, my VPN service provides an SSL certificate for further authentication on their network. This certificate is placed into the /etc/openvpn folder, and is referenced by the “ca” line of the OpenVPN configuration file.

The “remote” directive (last line of the configuration file) tells OpenVPN where it can find the VPN server for this connection. This is a resolvable DNS name along with a port number. This should be provided to you (in some form) by your VPN service provider.

The last two directives, “route-up” and “down,” we’ll examine in a bit more depth. These directives designate actions to perform at strategic points when the state of the VPN connection changes. In this case, we have the OpenVPN system execute shell scripts on these state changes.

In both cases, we want to re-route all network traffic on the device through the new VPN tunnel. We use these state-change opportunities to perform this channeling. In the case of “route-up”, which is executed by OpenVPN, the authentication with the VPN server has been successful, and the tunnel interface has been established, but there has not yet been any binding of routes to it. At this point, we take the opportunity to divert all network traffic to the new tunnel interface:

#!/bin/sh
iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE

The “down” action is simply a reverse of the diversion performed by the “route-up” action:

#!/bin/sh
iptables -t nat -D POSTROUTING -o tun0 -j MASQUERADE

This makes sure that diversion of the traffic on the device only happens while the VPN tunnel is active.

After establishing some appropriate permissions on the new OpenVPN configuration files, the /etc/openvpn folder now looks a bit more populated:

OpenVPN folder with setttings

You can now start your VPN to ensure that all your settings are correct:

pi@torrentpi ~ $ sudo /etc/init.d/openvpn start

In the OpenVPN configuration file, the log output for this connection was routed to /var/log/piavpn.log. Examine that file to make sure your connection was successful. You should see something like this as the last line:

Sun Jul 28 12:50:41 2013 us=897679 Initialization Sequence Completed

You should also have a new interface device for the tunnel, which is reported by the /sbin/ifconfig utility:

ifconfig shows the new tunneling interface

Take That Sucker For A Spin

Now we will test our VPN configuration using a free service called CheckMyTorrentIP. This site will generate a torrent seed that uniquely identifies your torrent client, and will report the detected source of your device.

First, we generate the torrent, and save it locally on the PC:

Generating a torrent for testing

Next, we upload the new torrent to the Transmission client interface running on your Pi. This is done using the the URL “http://<device>/transmission/web/”, where “<device>” is either the IP address or resolvable hostname of your Raspberry Pi (see the “Finishing Touches” section regarding using a resolvable hostname for your device). Once the torrent is loaded and running, you should get a notification about the IP address that CheckMyTorrentIP detected in the Transmission web page. The CheckMyTorrentIP web page will also report on the address it discovered, and provide an educated guess about where that IP address originated:

Where the world thinks we are

If all went well, you should see an IP address and source country that is nowhere near where your device is actually sitting on the planet. Success!

Just To Be Sure

For the utmost in security, we want to make sure that no sharing activity takes place unless it is through the VPN. We don’t want the Transmission client to accept and share data when the VPN tunnel is not active, as that would expose our origin. So, we will take the life cycle of the Transmission process out of the hands of the operating system’s startup mechanism, and give it over to OpenVPN to manage instead to ensure that file sharing only happens when there is an established VPN connection.

First, we need to remove all references to the “transmission-daemon” from the various run-state service folders (found in /etc/rc?.d). We can do this manually by hunting down and destroying every symbolic link in each folder, or we can employ a utility to do it for us. If you are not expert on the Linux command line (or even if you are), I’d recommend the utility approach.

The standard Debian utility for managing services is called “update-rc.d” (a name not nearly as easy to remember as the Redhat “chkconfig” command, which I highlight later).  Using this command, we remove all references to the “transmission-daemon” process from the service database of every run state:

pi@torrentpi ~ $ sudo update-rc.d -f transmission-daemon remove

If you would like to use an alternative command that is a bit more comfortable, the “chkconfig” can be installed on your system.  Install “chkconfig” using apt-get:

pi@torrentpi ~ $ sudo apt-get install chkconfig

After it has installed, you can quickly check the membership of the “transmission-daemon” in the various system states using chkconfig:

chkconfig reporting on transmission-daemon

We can remove it from all states using the “–del” option:

chkconfig removing transmission-daemon

After execution of either of these commands, the running state of the “transmission-daemon” process will no longer be managed as a service automatically by the system.

Finally, we give OpenVPN control over the starting and stopping of the “transmission-daemon” process by modifying our existing state scripts, “route-up.sh”:

#!/bin/sh
iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE
/etc/init.d/transmission-daemon start

and “down.sh”:

#!/bin/sh
/etc/init.d/transmission-daemon stop
iptables -t nat -D POSTROUTING -o tun0 -j MASQUERADE

This ensures that the Transmission client is only running if the tunnel interface has been established, and network traffic has been routed through it. If you check your /var/log/piavpn.log file, you should now see the Transmission client system coming up and going down along with the tunnel:


Starting bittorrent daemon: transmission-daemon.
Sun Jul 28 14:31:16 2013 us=435758 Initialization Sequence Completed

Sun Jul 28 14:32:06 2013 us=230477 /etc/openvpn/down.sh tun0 1500 1542 X.X.X.X X.X.X.X init
Stopping bittorrent daemon: transmission-daemon.

However, the “down” action is currently being performed after the tunnel has been closed. This leaves things a bit awkward for the Transmission client, who, for a short period of time, is still running even though the tunnel has stopped. We can mitigate this situation by adding the “down-pre” option to the /etc/openvpn/pia.conf file:


daemon
route-up route-up.sh
down-pre
down down.sh

This will instruct OpenVPN system to execute the “down” action before the tunnel is actually closed, allowing us to terminate the “transmission-daemon” process, and remove the forced-routing, before the tunnel is finally dismantled.

Some Finishing Touches

  • If you plan to access your device using its hostname (instead of its IP address), Apple hardware seems to be able to find the Raspberry Pi just fine using its hostname. However, Windows systems appear to require a NetBIOS identity in order to reference the Pi in that fashion. This is readily addressed by installing Samba and creating a minimal configuration that just exposes the machine via this network mechanism. For example, after installing Samba on my Pi, I created the following simple /etc/samba/smb.conf file and restarted the Samba system. This made my machine visible to Windows as “torrentpi”:[global]
    workgroup = @home
    netbios name = torrentpi
    security = share
    hosts allow = 192.168.1. 127.
    follow symlinks = yes
    wide links = yes
    unix extensions = no
  • It’s important to keep your operating system updated. The “apt-get update” and “apt-get upgrade” commands do this nicely, and should be run periodically. However, you will find that they will fail to function while your VPN is active. For this reason, you should bring down your VPN before you try to do any updating:pi@torrentpi ~ $ sudo /etc/init.d/openvpn stop
    pi@torrentpi ~ $ sudo apt-get update
    pi@torrentpi ~ $ sudo apt-get upgrade
    pi@torrentpi ~ $ sudo /etc/init.d/openvpn start
    Note that, since we have given life-cycle control of the transmission-daemon process over to OpenVPN, all active torrents will be suspended when you stop the “openvpn” process, and will remain suspended until you once again activate and successfully re-establish your VPN connection.
  • We also did not touch on the Transmission system in this tutorial, and its settings. That would be the stuff of an entire tutorial unto itself. However, one thing you should determine before actively using Transmission (or any torrent client, for that matter) is where you plan to store the files that are shared. Bear in mind that you are operating from a microSD card, and even the largest one available on the market has an amount of space that will be quickly consumed by any serious sharing usage. I highly recommend that you reconfigure Transmission to use storage that is outside of the device – for example, attached to the USB port of the device, or (my personal preference) a network attached storage (NAS) device, or perhaps a read-write Samba share, mounted locally on the Raspberry Pi’s file system.

I do hope you found this tutorial useful, and let’s give a shout out to the hard-working folk of the NSA:

Thanks for your diligent and illegal work in making the world a more Orwellian place: You’ve set the example for us all.

Advertisements

40 thoughts on “Raspberry Pi: Creating a secure torrent client

  1. Serafin Guardino says:

    Thanks for writing this post. I have a quick follow up question: is there any distinct NAT required in order for BT to handle incoming as well as outgoing connections correctly? I’m using the Transmission Remote GUI client (http://code.google.com/p/transmisson-remote-gui/) to monitor the daemon and am seeing slower downloads than on other machines connected to the same network. If I go into the preferences for the Transmission GUI it gives the ability to test the port connection, it says “Incoming Port Closed, Check Your Firewall Connection”. AFAIK the Pi doesn’t have a built-in firewall, so it should be going straight to the router (Airport Extreme) so no firewall should be at play. Any suggestions?

    Irrespective of whether you can answer this, thanks again for writing this up. I just re-read a bunch of it and it is hands down the best Raspberry Pi tutorial I’ve come across. An ambitious project, which a bunch of distinct parts, well written with a good balance of detailed instructions and example results. I wish more tutorials and online documentation was written like this!

    • bobhood says:

      Hello, Serafin.

      I have no explicit NAT settings in my router for the Transmission BT client, and it functions normally. I also have UPnP disabled in my router, so it cannot automatically configure port forwarding if it needed it. However, the Transmission web site actually has a page dedicated to port-forwarding modifications, if you happen to need them. You’ll find it at https://trac.transmissionbt.com/wiki/PortForwardingGuide.

      The Pi actually does have a firewall available, but if memory serves, it is disabled by default. You can configure a firewall using either iptables or the ufw (Uncomplicated FireWall) utility. Unless you’ve fiddled with it, though, I doubt it’s interfering with your transfers.

      Bear in mind that the Raspberry Pi is not a desktop equivalent (nor, for that matter, is it really even a laptop equivalent). It’s more of a smartphone equivalent, and it takes some CPU cycles to handle the encryption of the VPN. You’d probably not even notice the overhead on a full-powered desktop machine, but the Pi might be a bit out of breath trying to perform the processing. This would likely manifest in the transfer speeds. I’d recommend doing some simple tests with your VPN on and off, even something as a ping to given endpoint would show you any delays occurring with the VPN in place.

      And thanks for the kind words. 🙂

  2. John says:

    This is an amazing post. I’ve been trying to set up something (pi, torrents, PIA) similar for about a week, and just couldn’t get it to work. Turns out I wasn’t a million miles away, but your guide just pushed me over the finish line.

    Thanks so much for taking the time to write this up so well.

  3. Virtual Private Networker says:

    Could you perhaps explain a little bit why your openvpn config files are a lot more extensive than the ones that PIA supplies and why apt-get update/upgrade don’t work over the VPN connection?

  4. Many thanks for this. I have followed your instructions to the letter but after getting the Tunnel up and running CheckMyTorrentIP does not work. Furthermore if I enter the command:

    curl http://ipecho.net/plain

    I get the error

    curl: (6) Couldn’t resolve host ‘ipecho.net’

    traceroute google.com also fails with

    Cannot handle “host” cmdline arg `253.256.12.12′ on position 1 (argc 1)

    However running torrents through Transmission web interface works but I don’t know which IP address is being exposed.

    Doing ifconfig shows the tun0 entry and all looks fine.

    Any help on this would be greatly appreciated because I have been trying to get this to work for over two weeks now.

    Gauss4

    • bobhood says:

      On my tunnel-enabled Pi, I can ping ‘ipecho.net’ with a successful result, and a traceroute to ‘google.com’ gives me a full listing. Not really sure what your primary issue is, Gauss4, but clearly your DNS resolution is not functioning.

      I’d recommend you check your network settings on your primary adapter (e.g., ‘eth0’) and make sure you’re using valid DNS servers. If they are servers configured by your VPN service provider, you’ll probably want to contact them. You might also try using the DNS server IPs in, for example, your Windows machine (outside of your tunnel), and see if they work there. If they do, then your tunnel may not be configured properly. If they don’t, then the DNS servers themselves are probably not configured properly.

  5. Benny says:

    Thank you for writing this, very useful and easy to follow.

    I was wondering if there’s a way to specify the handshake encryption in the OpenVPN config, or if the encryption type is embedded in the cert?

    • bobhood says:

      Hi, Benny.

      I’m not really an expert on OpenVPN (or SSL, for that matter), but an educated guess would be that the certificate issuer has configured a specific security configuration (e.g., 4096-bit key lengths) on their secured servers, and that knowledge is encoded in the certificate itself. If you were to select a different configuration external to that used by the servers, then communication might not be possible (not to mention possibly introducing a security hole).

      However, you might want to look at the “–tls-cipher” OpenVPN option, which provides a list of the acceptable TLS ciphers that the handshake can use. This is used to enforce a minimum level of security, and prevent any kind of automated rollback to a lowest-common-denominator (used by a common attack technique).

  6. Martin says:

    Thank you so much for this!!! This scratched an itch that had been festering for about a year now. So many guides and fresh OSs. This was kind of my rosetta stone for Linux that made everything click.

  7. Bob, I was wondering if you could help me out with a vexing issue. I am not an expert on networking (just know enough to get by.) I am using the pi as described, but would like to be able to ssh in to the pi from outside my LAN. I have the port forward set on my router and it works when the vpn is down, but not when it is up. I believe this to be due to the masquerade setup interfering with the routing. The packet comes in on the nonvpn ip address and is picked up by the ssh daemon and the outgoing packets from sshd are routing to the vpn ip address so the packets get dropped. Does this make sense and do you know a way around it. Basically would like the exact setup you describe, but allow ssh connections from outside my LAN to my ISP provided IP address.

    Thanks, Greg

    • I found an answer to my own question. Funny how that works if you are persistent.
      I add the following lines in route-up.sh before the iptables command:

      ip rule add from x.x.x.x table 10
      ip route add default via y.y.y.y table 10

      (where x.x.x.x is the ip of my network interface wlan0 in my case)
      (where y.y.y.y is the ip of my lan gateway)

      This allows the ssh connection to be made and packets to route properly back out on the wlan0 interface through the gateway, not the tunnel.

      • Helend says:

        Thanks you very for your tips. I have successfully connected ssh from outside my LAN. However, I would like to connect transmission web interface from outside LAN. Is it possible to use similar configuration?

        Thanks in advance

      • Helend, the route and rules I posted will allow any traffic that gets routed to your local IP to route back out over the normal gateway rather than the VPN route. It is a simple way to create a split routing table. If you want to access your transmission web admin from outside your LAN that is quite possible. You already have the necessary routing rules on the pi. You simply need to enable the port forward on your router to port 9091 on your pi (I assume you know how to do this since you probably forwarded port 22) This may be all you need to do. If this does not work, your RPC settings in transmission need to be modified. We already enabled RPC whitelist above which is preventing connections from outside addresses. You can add specific IPs here that you will be connecting from, or just use *.*.*.* BE CAREFUL if you use wildcards, since that will allow connections from any IP. Be sure to have a strong username/password and look into iptables rules to prevent brute force attacks.

        One other tip if you are forwarding ports to your pi. Using random/nonstandard ports for ssh and rpc seems to help quite a bit with the various nefarious scripts/bots on the internet that try connecting to open ports 22, 80, 8080, etc. Please let me know if this works for you.

      • Helend, one other suggestion just came to mind. The web admin for transmission is nice, but pretty much identical to the ncurses remote control. The difference being the ncurses one runs in a terminal and has more keybindings for things rather than mouse clicks. I would suggest just opening up ssh to the outside and using transmission-remote-cli (this is the package name in debian)

        Also, with ssh:
        1. Use a different port other than 22
        2. Use iptable rules to prevent brute force attacks
        3. Use key authentication and disable passwords

    • Helend says:

      Hi Greg,

      Thank you very much for your tips. It is just what I want. Now I can connect transmission web from my office.

      I have followed your other suggestions.

      Cheers,
      Helend

  8. Helend says:

    Thanks for your post. Everything is working for me except the high cpu usage of openvpn. The CPU usage is about 40% always in my Raspperry Pi. Is this normal for Pi or do you know how to fix it?

    Thanks,
    Helend.

    • bobhood says:

      Hi, Helend.

      I’d say that 40% is high, yes. However, I watched my “openvpn” process for about 60 seconds via top, and it never went above 2.3% on my Pi (with my torrent client coming in second while it seeds). I could see such high CPU usage if your VPN was encoding/decoding a heavy amount of traffic, but for an almost idle tunnel, 40% would seem to me unusual.

      If it’s not a matter of large traffic volume, something that may also be the case is that your VPN provider is doing something in the protocol itself which is requiring your active connection to utilize an excessive amount of CPU power. That’s just a guess, though.

      Sorry I couldn’t provide more insight here.

  9. Helend, I think 40% is not out of order. When I am using transmission without speed limits, nearly all the pi’s CPU is utilized. About 60/40 split with the openvpn and transmission processes. If I use my normal 50k/50k limits (turtle mode defaults, iirc) the CPU is about 30% utilized with roughly the same ratio between openvpn and transmission processes.

    I agree with Bob, you are probably just using a fair amount of bandwidth and the openvpn has a lot of work to do.

    • bobhood says:

      And since I use upload limits (20Kbs), my seeding activities will not be hammering the CPU. I suspect you are spot on, Greg.

  10. Helend says:

    Hi bobhood and Greg,

    Thanks for your reply. It seems the cpu usage is related with the download and upload speed of bt.

    PS: I am using the private internet access now.

    Cheers,
    Helend

  11. Bangyou says:

    Hi bobhood,

    Thank you very much for your post. It is very useful for me. I have used the exact same method in your post including the VPN provider (PIA with Netherlands server).

    Everything is working for me except port forwarding. Did you figure out how to set up port forwarding?

    Thanks in advance.

    Cheers,
    Bangyou

    • bobhood says:

      Hi, Bangyou.

      If you are referring to port forwarding for Transmission, read back in the comments to my post on 9.17.13. As mentioned there, I have no explicit port-forwarding configured on my router for my Pi and Transmission. In that comment, I do provide a link to the Transmission page that talks about port forwarding for its BitTorrent client if that is what you are wondering about.

      If you are talking about some other port forwarding need, you will likely need to be more explicit about your intent, and somebody else watching this entry might be able to provide more focused help for you. I personally have not done (or required) any port forwarding to get this configuration, i.e. Raspberry Pi as a secure BitTorent client using PIA, to work.

  12. Thomas says:

    Thank you for the wonderful post. I’ve followed it nearly to the tee and it’s working well for a few weeks. Since then, however, I’ve been reading about DNS leaks. Do these instructions solve any of that? Sorry, I’m a bit of a newbie.

    • bobhood says:

      Excellent question, Thomas.

      No, I did not address DNS leakage in this post. Since the Pi is a Linux-based system, it’s not quite as problematic with regard to DNS leaking as Windows. However, there are several ways you can go about adding your VPN provider’s specific DNS servers to your Pi’s configuration at the global level.

      The first is to directly edit your /etc/resolv.conf file. Now this is one of those last-resort, frowned-upon practices, because the file is generate by other settings. Modifications you make to this file will not survive a reboot, but it can be used for a quick-and-dirty change to the DNS hosts used by your Pi. You specify DNS servers in this file by adding one per line in the format “nameserver x.x.x.x”. You can also disable any existing entries in this file by prefacing them with a pound sign (#). Again, as I said, this is only a temporary fix that will last only until your next reboot of the device.

      Another method is to edit your /etc/dhcp/dhclient.conf file. You can add a line in that file that looks like “prepend domain-name-servers x.x.x.x, y.y.y.y;” that use your provider’s DNS server addresses (in fact, in the default configuration, there’s probably already a disabled line in there that references your loop back address). Placing them here will cause your /etc/resolv.conf file to be populated correctly with the values each time your Pi starts up. This is the approach I recommend.

      Lastly, you may also modify your /etc/network/interfaces file and place an entry that looks like “dns-nameservers x.x.x.x y.y.y.y” into a section that references your tunnel interface (e.g., tun0). However, in my case, that interface is not static, so there is no existing entry for it. I’d not recommend this approach unless you really know what your doing.

      With regard to DNS servers, if you cannot find those configured by your VPN provider, of you simply don’t trust them for some reason, you can use Google’s DNS servers, which can be found at “8.8.8.8” and “8.8.4.4”, for your private DNS needs. While this doesn’t hide your DNS activities from Google, it does keep your DNS requests from leaking to your ISP.

      Hope this helped.

      • Thomas says:

        Thanks so much for your reply. I’m did some additional reading and experimentation over the weekend. I’m using PIA well and, as best I can tell, when using OpenVPN you don’t automatically get their DNS servers pushed to you. It sounds like you do if using their Mac or Windows client but maybe this isn’t supported in OpenVPN(?). That’s my guess.

        I verified this by dig-ing some URLs (for example: dig http://www.google.com). Even when connected to the VPN, it was using my home router’s configured DNS (in my case, I was using OpenDNS’s).

        I tried what you recommended and added “prepend domain-name-servers 209.222.18.222, 209.222.18.218;” to dhclient.conf (these are PIA’s advertised DNS servers) and after doing that, a similar ‘dig’ command told me that I was using PIA’s servers.

  13. Agurzil says:

    Thank you very much for your detailed tutorial.

    My log and ifconfig indicate that the VPN seems to connect to pia (Initialization Sequence Completed). This is also confirmed through ifconfig (see below).

    However, no application seems to be able to connect to the internet: transmission doesn’t connect nor can i ping (ping ipecho.net). When i stop the process (sudo /etc/init.d/openvpn stop), the connections work again.

    Any idea’s on what to do next? Thank you in advance.

    Ifconfig dump
    eth0 Link encap:Ethernet HWaddr xxxx
    inet addr:xxxx Bcast:xxxx Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:17298 errors:0 dropped:0 overruns:0 frame:0
    TX packets:11495 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:4974196 (4.7 MiB) TX bytes:2694190 (2.5 MiB)

    lo Link encap:Local Loopback
    inet addr:xxxx Mask:255.0.0.0
    UP LOOPBACK RUNNING MTU:65536 Metric:1
    RX packets:4 errors:0 dropped:0 overruns:0 frame:0
    TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:272 (272.0 B) TX bytes:272 (272.0 B)

    tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
    inet addr:xxxx P-t-P:xxxx Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
    RX packets:84 errors:0 dropped:0 overruns:0 frame:0
    TX packets:86 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:6688 (6.5 KiB) TX bytes:8197 (8.0 KiB)

    • Agurzil says:

      It seemed to be a dns problem, solved by using Google’s dns server. I changed my ip from dhcp to static using the following instructions.

      Copied from http://www.techsneeze.com/configuring-static-ip-raspberry-pi-running-raspbian

      You’ll need to open the config file for editing.

      nano /etc/network/interfaces

      Change the line with “iface eth0 inet dhcp” and add the lines similar to:

      iface eth0 inet static
      address 192.168.2.31
      netmask 255.255.255.0
      gateway 192.168.2.1
      dns-domain yourdomain.com
      dns-nameservers 192.168.2.1 8.8.8.8 4.2.2.1

      This sets your desired static IP, and the appropriate settings for your resolv.conf You’ll notice it uses your local DNS, a Google DNS (8.8.8.8), and one of the Level 3 DNS servers commonly used (4.2.2.1).

  14. BobHood,
    This is a wonderful tutorial — well done. A few problems… I have PIA, and I followed your instructions to the T, but it gives a SIGTERM and kills the VPN every time I try to enable it. When I remove the auth-user-pass part, it works until it hits the route-up and down shell scripts, then it kills… Any ideas? Any help would be appreciated.

    • bobhood says:

      Not sure what I can do to help here, Chris. The only thing I might be able to suggest it to check your logs — /var/log/piavpn.log (if you used the configure I provided), /var/log/message.log, /var/log/syslog.log, etc. — to see if there are any clues there as to what might be wrong.

      Could also be a problem with the version of OpenVPN you’re using.

  15. GoGo says:

    Hi Bob, thanks for your guide!
    I would lke to use my torrent client in active mode – how can I do that?

    Thanks for help

    • bobhood says:

      Hey, GoGo.

      If I understand your question correctly, switching your torrent client (which I assume is Transmission) into “active” mode is simply a matter of exposing it’s port(s) through your router/firewall. Without doing that, your client can only operate in “passive” mode, limiting some of your options.

      The obvious change that you need to make is to expose your machine IP and Transmission port(s) through your router. This assumes you don’t have UPnP enabled on your router (which you should NOT due to security issues). Check the settings on your Transmission client to see which port it is using to “listen” (or your Transmission config under the “peer-port” entry), and then expose that through your router’s port-forwarding section (this varies wildly between firmwares, so you’ll have to figure out where it is on your particular manufacturer/model).

      A non-obvious change might be a requirement to also allow your Transmission client’s “listening” port through the software firewall on your Linux distro. Some distributions have the firewall disabled by default, others have it enabled (for example, Ubuntu disables it by default, Red Hat Enterprise enables it). If you have to go this far, then a command line something like the following will temporarily open the Transmission port through the Linux firewall . You’ll want to make this permanent, however, if it solves your problem (replace “” with the Transmission port number in the following command):

      sudo iptables -I INPUT -p tcp –dport -j ACCEPT

      A review of this might also be helpful: https://trac.transmissionbt.com/wiki/PortForwardingGuide

      Also, if you’ve enabled “random” ports in your Transmission config, you’ll have to enable a range of ports to match those used with this setting.

  16. Ronald says:

    Hey Bob,
    many thx for this wonderful tutorial. One Question though. My VPN Provider recommends to shut off everything ipV6 related. Would you follow that advice and if, you know how?

    cheers

    • bobhood says:

      Hi, Ronald.

      I don’t know of a specific reason they are recommending that. However, if you aren’t actually using IPv6, then basic security concerns state that you should disable it, as it could be one more way to get into your system. Whether or not that is a valid security concern in this case is debatable, though it doesn’t hurt you to heed their advice just to ensure you have a smoother experience with them. Unless the network where you Pi resides is 100% IPv6, your routine network traffic will likely be IPv4 anyway.

      To disable IPv6 on your Pi in a way that keeps it off across reboots, add the following to the bottom of your /etc/sysctl.conf file, and then reboot:

      net.ipv6.conf.all.disable_ipv6 = 1
      net.ipv6.conf.default.disable_ipv6 = 1
      net.ipv6.conf.lo.disable_ipv6 = 1

      You can of course re-enable it later by removing or commenting these lines, and rebooting.

  17. JB says:

    I spent weeks trying to get this working. This is what fixed it for me:

    In /etc/default/ifplugd change the line:
    HOTPLUG_INTERFACES=”all”

    to:
    HOTPLUG_INTERFACES=”eth0 wlan0″

    Hope that helps someone

    • bobhood says:

      Hmm.. My file has the “all” setting for HOTPLUG_INTERFACES. However, I’m also using the “2013-07-26″ build of Raspbian (has to do with video MPEG2 playback issues in newer versions). If you’re using a newer build, that may have some bearing.

      In any case, thanks for the tip, JB!

Comments are closed.