First Things First

There are many providers of VPN services on the internet, both free and commercial. This page describes setting up a VPN with a commercial provider.

It is important to realize that these providers are commercial entities, operating legally in their jurisdictions. As such, they can help to provide the kind of privacy that's being taken away from you. But if you're a journalist reporting on a hostile regime, say, or someone who lives in a hostile regime, this level of privacy will not provide you the protection you need. If your adversary is a nation-state (and not just a smarmy ISP), you really need to be using something like Tor.

Secondly, the instructions presented are for a specific VPN provider, Private Internet Access (PIA). They often rank highly on VPN provider comparisons, and their service has been reliable, but I don't really know enough about them to make a formal recommendation. For all I know they could be a front for Comcast. Yes, this seems unlikely, but the point stands: unless you have access to a third-party audit of your VPN provider (and I don't know any that provide that), there needs to be some level of trust between you and your provider.

PIA has exhibited behaviors that suggest they may be trustworthy. For example, from what I've read they pulled out of Russia when regulatory changes there would have required them to log data in a way that they felt compromised the privacy of their customers. This is encouraging, but ultimately the choice of who you trust is up to you.

IPv4 and IPv6

Despite them both being "Internet Protocol," there are real differences between IP version 4 and IP version 6. And there are real differences in the way that different platforms handle them. On some platforms the implementation of IPv6 is pretty broken.

Because of this, the provider I chose, PIA, does not support IPv6. Thus the first thing I had to do was to disable IPv6.

There are several ways to disable IPv6 on Arch (and in Linux in general): kernel boot parameters; entries in /etc/sysctl.d; etc. I decided to let my computer boot with IPv6, and to disable it at run-time when I need to bring the VPN up. This is done via sysctl.

There is a gotcha with this though. According to the documentation, the following command should disable IPv6 on all interfaces:

sysctl net.ipv6.conf.all.disable_ipv6=1

The devil is in the details, though, and if you read the fine print, this does not work on an interface that has already been enabled. Thus you'll need to disable IPv6 on the specific interface you're using for your internet connection. On my laptop this is wlp4s0, so the command I use is:

sysctl net.ipv6.conf.wlp4s0.disable_ipv6=1

(Also note that these commands need root access.)

If you're trying to disabling IPv6, you should verify that you have done so successfully. Probably the easiest way of doing this is to type in the query "what's my ip address" into a Google search; Google defaults to IPv6 connections if they are available.

In the above you see that Google reports an IPv6 address. When you've successfully disabled IPv6 you will see the version 4 address assigned by your ISP.

PIA also has a webpage, ipv6leak.com, set up for evaluating this.

Lastly, one should probably remove IPv6 references to localhost in /etc/hosts. Such an entry will typically be for ::1:

::1         localhost.localdomain   localhost

This line can be commented out. [Full disclosure: this probably isn't absolutely necessary. But out of an over-abundance of caution...]

Once IPv6 is successfully disabled, domain name resolution needs to be addressed.

DNS

Some ISPs -- mine included -- do not run public DNS servers, so when your traffic appears to come from a different IP address, they will not answer your queries. In these cases it is better to use a DNS server that your VPN provider provides, or to use an open one, such as Google's 8.8.8.8. I chose to use the server provided by PIA.

systemd-based systems (like Arch) are kind of annoying, though, when it comes to actually editing a configuration file. In the golden age of UNIX-like computing, one had only to identify a configuration file -- such as /etc/resolv.conf -- and edit it by hand. This worked well for everything I ever had to do, but perhaps it didn't address enough rare cusp cases of strange dependencies, so today many configuration files are opaquely auto-generated from other configuration files that are very poorly documented, so sometimes it's hard to even figure out where a given file came from, and if you do decide to edit it by hand, usually your edits will not be persisted across boots. Sometimes they will not even persist within a session...

... which is a long-winded way of saying that I found a way to change my DNS configuration, but who knows which systemd service created yours? You may need to play around a bit.

On my machine the /etc/resolv.conf file is created by systemd-resolved.service. So, in order to change my DNS server, I stopped that service and then re-created the file with the VPN provider's DNS server. In code:

systemctl stop systemd-resolved.service
cp /etc/resolv.conf /etc/resolv.conf-back
echo "nameserver 209.222.18.222" > /etc/resolv.conf

Note that I create a backup of resolv.conf before I overwrite it. This way I can restore it after a VPN session, should I need to.

Once you have your VPN up and running, you'll need to check this (but we'll come back to it).

Configuring OpenVPN Proper

One of the nice things about PIA is that OpenVPN is their recommended solution (although they provide other options for platforms that can't run it), and they provide OpenVPN configuration files that only need minor hand-edits to use.

The first thing one needs to do is to download their OpenVPN files:

curl https://www.privateinternetaccess.com/openvpn/openvpn.zip -o openvp.zip

You will need three files from this zip archive:

• The CA Certificate (ca.rsa.2048.crt).
• The provider's pubic key (crl.rsa.2048.pem).
• The OpenVPN end-point file for the tunnel exit of your choice (*.ovpn).

For the purposes of this page, I'll use Sweden.ovpn as an example, which will direct the traffic to a VPN exit point in Sweden.

A directory to hold your configuration files should be made. I chose /opt/pia, but this directory choice is arbitrary.

First the certificates and keys and configuration files should be copied to the directory you have chosen:

cp ca.rsa.2048.crt /opt/pia/
cp crl.rsa.2048.pem /opt/pia/
cp Sweden.ovpn /opt/pia/

Next you should create a file that holds your authentication credentials. When you sign up for a VPN provider, they should give you a username and password. This file contains those two data, one per line (the first line of the file should be your username, and the next should be your password). This file, which could be called something like password.pia, should have restrictive access rights (ie: chown root:root password.pia && chmod 600 password.pia):

mark@lucid:/opt/pia$ ls -ltr
total 20
-rw-r--r-- 1 mark mark  869 Apr  5 11:29 crl.rsa.2048.pem
-rw-r--r-- 1 mark mark 2025 Apr  5 11:29 ca.rsa.2048.crt
-rw------- 1 root root   21 Apr  5 11:29 password.pia
-rw-r--r-- 1 mark mark  328 Apr  5 12:09 Sweden.ovpn

Lastly, the OVPN file will need to be edited so that the certificate, key, and password credentials are referenced. Following the convention of placing these files in /opt/pia, my Sweden.ovpn file looks like:

client
dev tun
proto udp
remote sweden.privateinternetaccess.com 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass /opt/pia/password.pia
comp-lzo
verb 1
reneg-sec 0
crl-verify /opt/pia/crl.rsa.2048.pem
ca /opt/pia/ca.rsa.2048.crt
disable-occ

The three entries in question are auth-user-pass, crl-verify, and ca. As you can see, these all point to the fully-qualified files that we copied in the step above.

(One thing to note: if your provider does support IPv6, you could tell OpenVPN to protect that traffic by changing the proto entry to:

proto udp6

... or so I've read. I have not verified this.)

Please note that these are the OpenVPN configuration options needed by/suggested by my provider. I am not an OpenVPN expert, so I can't assert that these are "the best," or really even "good." They are what they are, and you may want to spend some time with the OpenVPN documentation should you decide to go down a similar path.

Starting OpenVPN

What remains is to actually start OpenVPN:

openvpn --config /opt/pia/Sweden.ovpn

I control all of this with a bash file, which looks something like:

#!/bin/bash
##############################################################
#
##############################################################

config="Sweden.ovpn"
interface="wlp4s0"

# Set up DNS resolution
systemctl stop systemd-resolved.service
cp /etc/resolv.conf /etc/resolv.conf-back
echo "nameserver 209.222.18.222" > /etc/resolv.conf

# Disable IPV6
sysctl net.ipv6.conf.all.disable_ipv6=1
sysctl net.ipv6.conf.${interface}.disable_ipv6=1

# Establish tunnel
openvpn --config /opt/pia/${config}

When executed, the script produces output like:

Thu Apr 20 21:10:24 2017 OpenVPN 2.4.1 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2017
Thu Apr 20 21:10:24 2017 library versions: OpenSSL 1.0.2k  26 Jan 2017, LZO 2.10
Thu Apr 20 21:10:24 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]5.153.234.82:1198
Thu Apr 20 21:10:24 2017 UDP link local: (not bound)
Thu Apr 20 21:10:24 2017 UDP link remote: [AF_INET]5.153.234.82:1198
Thu Apr 20 21:10:24 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Apr 20 21:10:25 2017 [c77ea6898de50aa7a00403cd8e69ace2] Peer Connection Initiated with [AF_INET]5.153.234.82:1198
Thu Apr 20 21:10:26 2017 TUN/TAP device tun0 opened
Thu Apr 20 21:10:26 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Apr 20 21:10:26 2017 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Apr 20 21:10:26 2017 /usr/bin/ip addr add dev tun0 local 10.52.10.6 peer 10.52.10.5
Thu Apr 20 21:10:26 2017 Initialization Sequence Completed

Testing

A VPN that doesn't work doesn't provide privacy protection, so you should verify that everything is working as planned.

If things are working, opening up a web browser and pointing it to google.com gives us our first hint. When we bring it up, we will be redirected to google.se:

Next we can perform a Geolocation on our IP address, which is provided by many services. As an example:

We should also verify that our IPv6 is disabled:

Lastly, we can/should verify that our DNS isn't leaking any information. PIA provides a site for this too, dnsleak.com. (Sometimes the test doesn't return an answer; it's a difficult test to perform, and sometimes you'll need to try a few times. Results can take a minute or so to complete.) If your DNS IP matches your IP, you're good to go:

Summary

As more and more of life is mediated (and sometimes controlled) by commercial interests, protecting your privacy becomes an important civil -- and even political -- action. Increasingly, politicians assert that "free markets" will solve our problems, and the roll back of your right to privacy was probably accompanied by such rumblings (if any thought other than pleasing the corporate overlords crossed congressional minds). But free markets don't exist, so the point is at best arguable. The Koch brother may work tirelessly to roll back financial incentives given to alternative energies, for example, but they are strangely silent on the billions in incentives that their industry -- coal -- receives. Kindred spirits in congress repeat their talking points, trying to roll back alternative energy incentives, complaining about "level playing fields," again strangely silent on the billions going to fossil fuels.

It's a good bet that whenever politicians talk about "level playing fields" and "free market solutions," what in fact is happening is misdirection, and whatever action they are taking really benefits ensconced (and contributing) interests.

[I have nothing against free markets. Having founded and run a few companies, I think entrepreneurial capitalism can work. But it's not a panacea; it won't solve all of our problems. Governments have valid regulatory responsibilities, and handing them over to commercial interests does society no good.]

So think seriously about protecting your privacy. After all, it's yours. It can be your "free market solution" to the problem of an ineffectual, powerless, and (increasingly) corrupt FCC.