Show by Label

Sunday, March 20, 2016

One Button to Halt and Restart the Pi

I published a post on the Raspberry Pi forum that shows how to do this with only a button, two resistors and 1 capacitor.


Thursday, March 17, 2016

(2)Installing and Configuring the OpenVPN package

This is a follow-up and continuation on the first post in this series, "how-To: Un-geoblock Netflix and cast movies from a tablet to a TV

9.b Installing and Configuring the OpenVPN package

Time to install the OpenVPN package.

sudo apt-get install openvpn

At this point I’m going to show you how to use a commercial VPN service provider and setup an OpenVPN connection to a location in a country of your choice. I’m going to do this later when I will connect to my own router and network, and setup everything by myselves, but there is a lot we can learn from this process.

If you don’t have a VPN service already lined-up, or don’t want to sign-up for one, just read the following two chapters for background and to learn.

When I searched for a VPN service provider myself, I had several selection criteria. After researching several candidates, I selected HideMyAss! ( or HMA! in short, for a number of reasons. 

Their name is not one of them though. Butt(!) in case you didn’t know, an ass is a hoofed mammal of the horse family with a braying call, typically smaller than a horse and with longer ears. It can also mean a foolish or stupid person. Lastly, it is a common description for the body part you sit on. HMA! uses the hoofed version as their company mascot.

A couple of keys factors in my selection criteria was that they are an English company and therefore more outside the fangs of the US NSA. They also have multiple servers in the countries of interest to me. They have good chat support and are very up-front with how they work, what data they store from you etc. Lastly they accept Paypal so you don’t need to send them credit card information.

For my initial Netflix viewing of the content in my home country while on vacation in another one, I used them until they got in the cross-hairs from the Netflix geo-police which disabled this geo-unblocking method for me. 

That caused me to investigate other means and led to these posts.

10.Installing the HideMyAss VPN Service

My assumption is that you already have a subscription with HMA!, or you can go to their website and sign on. You can do this for a one month period ($11,52 incl. VAT) if you want to try them out. 

If you have plans to go down that route, I suggest you get a one month trial subscription with HMA!. It will be money well spent in the learning process, and even if you decide later to use another VPN supplier, you will know a lot more to get a VPN to work in your environment.

Like most of their colleagues’, HMA! support several VPN protocols, one of them is OpenVPN, although that is not well publicized on the website. In any case, as you can see on their website, they have clients for just about every OS flavor or device. Linux is one of them although again I don’t think that it is prominently  “advertised” on the main website.

Go here to get a selection of installation instructions for the OS’s they support.
Select Linux from the list. After some searching, I eventually came to this page:

Unfortunately, downloading the zip file to my PC, unzipping and then cutting & pasting the script to the Pi caused a weird script execution error that I couldn’t fix quickly. Embedded in the script however is a link that I used to download the script file directly on my Pi.

To get the script, run this from within your home directory (/home/pi), and as user pi:

makedir hma
cd hma
curl -s -k >
chmod +x

This is a complete installation script that will install the required packages on your Pi, setup the environment for OpenVPN and start a VPN connection to a server in a country/city you select.

The required packages that will be installed if they are not on your system yet, are dialog and fping
Dialog displays nice looking dialog boxes with scrollbars etc. from shell scripts. Dialog is a package like whiptail. Fping is like ping, but differs because you can feed it a list of IP addresses to ping. It sends a ping to every IP address on the list and then moves on to the next. The script uses that feature to find the fastest servers by doing a latency test.

Before you start to run the script, I suggest you edit two places to fix a display issue caused by dialog. The script tries to display nice dialog boxes with the graphic characters for double lines, but on my Pi, running it headless, it reverts to incorrect ascii characters and that messes up the display. To fix that, open the file for editing:


Find the two instances where dialog is called (in line 279 and 306). In those two places, you need to add one more option to the dialog command line. (--ascii-lines)

You can do that as follows by changing the second line around line 279 from this:

dialog --backtitle "HMA! OpenVPN Script" \
--title "Select a server" \
--menu "Select a server" 17 90 15 $LINES 2>/tmp/server

into this:

dialog --backtitle "HMA! OpenVPN Script" \
--ascii-lines --title "Select a server" \
--menu "Select a server" 17 90 15 $LINES 2>/tmp/server

And this around line 306:

dialog --backtitle "HMA! OpenVPN Script" \
--title "Select OpenVPN protocol to use" \
--yes-label "UDP" --no-label "TCP" --yesno "Which protocol do you want to use?" 6 40

Into this:

dialog --backtitle "HMA! OpenVPN Script" \
--ascii-lines  --title "Select OpenVPN protocol to use" \
--yes-label "UDP" --no-label "TCP" --yesno "Which protocol do you want to use?" 6 40

Save the file and exit the editor.

Run the script and let it install the two needed packages.

sudo ./

Let it run, and from the dialog box, select a country and city. You can type the first letter from a country to jump there. I had to do that twice to get to the full selection of cities in my home country, the Netherlands (NL). After you selected the server you wanted, you get asked which protocol you want. Select UDP, because that is what we will be using later ourselves too.

If packages are missing from your installation, it will tell you and ask permission to install them.
Eventually you get to a fresh screen with the HMA! Logo, and the scripts now downloads your personalized OpenVPN setup file from the server. We’ll get to that when we will start to build our own setup files. The script also displays the current public IP address of the router and it starts to build the connection to the server in the city/country you selected.

For security and authorization, it also wants your HMA! account username and password to log you in.
It then shows a lot of details about the building of the connection, and after showing this:

Initialization Sequence Completed

It waits…because it is running in the foreground.

Look at the screen and try to interpret what is has done.

Basically, in a nut-shell, it has installed a tunnel interface from the Pi to the selected HMA! server by establishing a TUN/TAP device called a tun0 interface. It also created a connection from the IP address of the server to a sub-net on the Pi. 

This is a snippet from that portion:

/sbin/ip addr add dev tun0 broadcast
/sbin/ip route add via
/sbin/ip route add via
/sbin/ip route add via

Line 1: added a tun0 interface with IP with mask /22 ( to broadcast at the end of the sub-net
Line 2: Added a route from the IP address of the HMA! server to the eth0 gateway of the Pi
Line 3 & 4: some juggling to setup the client with a subnet address of

A Ctrl-c will abort the script and terminate the connection. 

OK, we know it works this far. Now we need to make it “really” work so we can fit this in with our wireless access point.

11.Testing OpenVPN with HideMyAss

As you have seen, the HMA! script sets up a tunnel from one of their servers to the tun0 interface at the Pi end, but there is no connection from there to anywhere else yet. It dead-ends at the Pi at the moment.

Earlier, to make the access point work, we used iptables to create a link from the wlan0 interface to the eth0 interface to allow connected clients access to the internet. We now need to do the same, but instead of linking to the internet where we currently are, we want to link through the tunnel to access the internet in the country we want to be.

This is simply a matter of using the previous iptables rules, but replacing all references from eth0 to the tunnel interface tun0.

To do that, we first flush all the current rules in the iptables memory.

sudo iptables -F
sudo iptables -t nat -F
sudo iptables -X

Now install the new iptables with the tun0 interface instead of the eth0 interface. Remember that the second line is one line, without a break.

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
sudo iptables -A FORWARD -i tun0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o tun0 -j ACCEPT

And save them into the rules file so they get loaded at the next (re)boot.

sudo sh -c "iptables-save > /etc/iptables/rules.v4"

Let’s try that out completely.  The new iptables are already installed at the moment, so there is no need for a reboot yet.

Go to your iPAD or any other wireless device, and connect the wireless interface to the local access point of the Pi. Open Safari or any other browser and go to the website. It will show you the local public IP address of the router, in the country you are in at the moment. The website also shows you a little map with the geo-location of the server you are currently connecting to, and from there to the internet cloud.

Keep your fingers crossed and start the HMA! setup program, but now run it as a daemon ( with the –d) option:

sudo ./ –d

Select a server in your “want to be in” country and city, enter your account name and password to get access to the HMA! server.

When the setup has finished, you will get the Pi prompt back again.

Now go back to your iPAD and update or refresh the website.

If all went well, it should now show you the IP address of the server in your “want to be in” country and city and show that geo-location on the little map. Yeah!

The HMA! tunnel connection protects you from man-in-the-middle (MitM) attacks, which are today’s robbers and thieves out of the medieval forests, because the data is encrypted. It also provides a safe connection method from the Pi to the HMA! servers by using certificates and keys in the authentication process.

With the tunnel I am going to build to my router at home, I will also add protection to the local server/router for denial of service (DoS) attacks. 

More about that in the next post, although the final ones will take a few weeks. I need to get home first. In the meantime, I’m going to enjoy the nice weather while I’m still here.

Stay tuned!

(3)OpenVPN Proof of Concept Test

Setting up an OpenVPN Client/Server Proof of Concept

In another post ( Installing and Configuring the OpenVPN package) we saw a working OpenVPN connection from an iPAD client to a wireless accesspoint running on a Pi, that was also running an OpenVPN client connecting to a server of commercial VPN provider HMA!

The next step in our project is to replace the provider with our own OpenVPN server, running on a router at home. This means that we will no longer have the luxury of a complete and rather simple setup of the client, because we now also need to install the OpenVPN server and everything around that.

The majority of the work in the setup for such a client/server combination is for a large part the configuration of both the client and the server, and most importantly, the security of the link. 

Because I am planning initially to use the setup to only view Netflix movies, I’m not overly concerned with the Man-in-the-Middle attacks, requiring encryption of the data. What I am concerned about is the connection to my router and the access to the tunnel from other clients. The certificates and keys that are used to fend off such attacks are non-trivial to setup and execute. This suite of certificates and keys is also called the X.509 Public Key Infrastructure (PKI) model.

My plan was to work on a proof of concept for the whole chain, and see what needs to be done and what can be learned in the process. The plan is to use the already functioning wireless access point on the Pi and my iPAD as a client and add an OpenVPN tunnel from the wireless interface to the Ethernet interface. It will help me to configure the client setup, the server setup and the PKI model. 

There should be no significant difference between an OpenVPN server running on the Pi or my router, I hope.

1.   OpenVPN Client/Server Configuration Files

We will now start to work on the three main elements of configuration files that will be used to setup the VPN connections between the server and the clients. Basically, all the information the script asked from us before, together with the system information it collected itself, went into a file called the .ovpn client configuration file.

This client configuration file has all the parameters the OpenVPN program needs, in order to set up a connection from a client to a server. This file contains configuration details, the certificates and keys used in the authentication process and the encryption keys. 

Most VPN providers will give you access to an .ovpn file tailored to their service or send you one. HMA! keeps their version under wraps a bit, and their setup script downloads a configuration template to your client to construct this .opvn file on the fly every time you start a connection.

So, every OpenVPN client needs to have an .ovpn file to tell OpenVPN what to do, and how to do it. Every server needs to have a configuration file (.conf) that is specific for the particulars of that server. 
We will now start to build the different elements of the .ovpn file for the client(s) and the .conf file for the server.

On the OpenVPN website ( there is a setup for a very simple client-server VPN connection, that does not use any of the complex encryption and authorizations. It is intended for one server and only one client, using one static key. That looked tempting, because that is exactly the configuration I want to have. 

Unfortunately, the clients that I wanted to test this with (W10 PC and iPAD) use OpenVPN apps that insist on having a full-blown .ovpn file. The above setup is apparently only possibly between Linux to Linux systems. 
That is what I’ll have later on, but not now. This means no short-cuts, so we have to go the full stretch.

2.   Creating the X.509 PKI Model

We’ll start with the generation of the certificates and the various keys in a X.509 Public Key Infrastructure (PKI) model. The resulting keys and certificates will then get added to the server .conf and the client .opvn files. This is the most important step in the whole security and privacy process, to get the protection we want/need.

When we installed the OpenVPN package, we also got a set of tools and templates that will help us with that process. It’s in the /usr/share/easy-rsa directory.  We’re going to use those tools and templates without disturbing the original data,  so we’ll setup links and copy the files we need to the OpenVPN directory and start to work from there. OpenVPN comes with a little script that does that for us:

make-cadir /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa

At this point, we’re going to switch to root administration rights so we don’t have to “sudo” all the time.

sudo -s
We will now start to generate certificates and keys. To largely automate this process, we need to add some standard information that is contained in a “vars” file which is located in the easy-rsa directory. 

nano vars

The first question you need to ask yourself is : “are you paranoid?” If the answer is no, we can suffice with a very good encryption solution. If you answered paranoid, you can switch to a higher encryption level, but in that case you need to know that there will be two penalties to pay, since nothing is free in this world. If you go for the paranoid setting, the generation of keys will go from about 5-10 minutes to 3-4 hours on a Pi Model (1) B. On top of that, every connection from a client to a server will be a bit slower due to this extra encryption.

Look in the file for :

export KEY_SIZE=1024

And double the key size from 1024 to 2048 when you classified yourself to be paranoid.

In my case, the main purpose of the VPN connection is to get around the geo-blocking of Netflix, so my main concern is speed, not super encryption of the movies that travel through the tunnel. A secondary application is to get access to my photo’s and music on the home server. This is also not worth the extra complexion and speed penalty a 2048 bit key would cause.

The following information is normally used for official certificates that you request (for money) from a Certification Authority (CA). The CA verifies certificate requests by using a certificate identifier, which is called a Distinguished Name (DN), to match the request to the party that already established a master CA certificate. The DN needs to be specified precisely, and should be unique of course, to correctly identify the (server/client) parties. If you want to know more, or more precisely, Google for “X.509 PKI”.

In our situation, we’re going to act like a CA and in that case we know who-is-who and it does not really matter what you put in, as long as there is something in every field.

export KEY_COUNTRY="Your country abbreviation like NL"
export KEY_PROVINCE="Your province/county/state abbreviation"
export KEY_CITY="Your City"
export KEY_ORG="Your Organization, whatever"
export KEY_EMAIL=
export KEY_OU="Your Organizational Division/Unit/Your Name..."

Even if we “just” put something in the fields above, there still should be one unique identifier that “matches” the server and client parties. This is why there is a Common Name (CN) identifier.  To activate that, remove the “#” in front of the KEY_CN declaration. 

Write down the name, we need it again in a moment.

export KEY_CN="raspi-vpn"

And lastly, add this line to avoid a weird error in the build process. You can leave “something” as it is.

export KEY_ALTNAMES="something"

Leave the rest of the file unchanged for now. Save and close the editor.

Generating the certificates and keys:

Normally, when you already have your OpenVPN server up and running on your local installation, you would have already generated the master certificate and the server certificate and keys, and will only need to generate the client keys. However, we are going to use this Pi installation to do everything on it so we can run some simple tests while we’re learning and experimenting.

There are a number of scripts in the easy-rsa directory that we will now execute one after the other to generate the certificates and keys for the server and the clients. 

Here we go.
Tell the generation processes to use the now updated vars file:

source ./vars

You will see a warning because the next command will wipe-out the directory where we’re going to put our keys and certificates in. So be careful if you want to preserve keys and certificates that are still there and not moved to someplace else already.


Now build the Certification Authority (CA) files. This will generate a master certificate (ca.crt) and a secret private key (ca.key) for the master certificate. The ca.key must be kept secret and stored in a safe place! The program will give you the chance to override the information you just added in the vars file, or you can just hit Enter to accept the proposed values.


Next, we will generate a certificate (called a public key : server.crt)  and an encrypted secret private key (server.key) for the server. The server certificate is signed by the master CA’s private key. The server.key file must be kept secret and in a safe place!  Remember that I asked you to write down the server name because you must give it as a parameter to this process. 

./build-key-server raspi-vpn
During the build key generation process, you get asked again to acknowledge the information you added in the vars file, you can change it or just hit return to acknowledge. However, when it comes to this line:

A challenge password []:

Do not enter anything,  just hit return. You do need to acknowledge the signature of the certificates twice.

After this process, we have a certificate (raspi-vpn.crt) and a private key (raspi-vpn.key) for the server.  The private key is secret, so keep it that way. 

When we are going to do this for real, these files will eventually be installed on the router I will use as the OpenVPN server, or you can use any other OpenVPN server “back home”.

Re-iterating my Scope for the “Ultimate” Solution
Before we get to the clients, and before you get carried away with the possibilities or get confused at this point, let me reiterate at that in my “ultimate” solution to solve the Netflix and Chromecast2 geo-blocks, the Pi wireless access point server will be the only OpenVPN client for the OpenVPN server on the router. The Pi will act as the middle-man for the iPAD that runs the Netflix app, and the Chromecast2 that casts the iPAD screen to the TV. There will be no OpenVPN app needed on the iPAD, and there can be no client on the Chromecast2.

But because I can, at a later point in time, I could also grant my other wireless devices (iPhones, notebook, another iPAD) secure and private access to the router, to get access to my photo’s, music and other data on my fileserver at home. There are two choices. They either go through the access point and directly through the tunnel, not needing a OpenVPN client app, or I need to make them a separate OpenVPN client, that can find their own way to the router. They don’t need to use the VPN to do email and web browsing though. The choice is mine. If this will all work out as I just sketched out, I don’t know yet. We’ll see what the possibilities are when we get there. For now, we’ll stick to the original geo-unblocking plan.

Generating Certificates and Keys for the client(s)
We’re now going to create the certificates and keys for the client(s). In my learning and testing phase, I want to test the VPN configuration with an Apple iPAD as an OpenVPN client. Eventually, in a next step, we’ll setup the Pi as a client. Being creative, I called the client simply “ipad”. 

We’ll start to generate the keys for each client. We need a public certificate (.crt) and a secret private key (.key) and we’ll normally do that one client after the other. The certificate for each client is signed by the master CA’s private key. The secret private key for the client must be kept secret, and stored in a safe place!

./build-key ipad

So after this we have certificate (ipad.crt) and a private (secret) key (ipad.key).

For the following (optional) step, we’re going to create the encryption key. Initially I’m not going to use that, but it’s here for completeness in case we need it later on.

Execute this line for line. You will move to the keys directory and generate the SSL encryption key using DES-EDE3-CBC encryption, also called “triple DES” or client.3des.key for every client. There are other encryption models, just look in the documentation if you want to use them instead of the 3des one.
You will be asked for a password, enter one for each client, you can use the same password for all the clients you have/own. If you generate clients later on for other people you want to give access to, you should give them individual passwords that will unlock the keys.

cd keys
openssl rsa -in ipad.key -des3 -out ipad.3des.key
cd ..

After this step, we are going to generate the Diffie-Hellman(-Merkel) keys.

Up until now, we have created individual certificates for the master, server and client and public/secret keys for the master, server and the client. The following process will “link” them such that the secret keys can be transferred using insecure methods. This “linking” is a process that can take about 2-10 min. (it varies a lot) on a classic Model (1) B with the 1024 key length size, and it can take up to 3-4 hrs(!) if you selected the key length size of 2048. 

I tried, and had lunch and played tennis for two hours with a beer afterwards before it finished. So, run this only when it can run to completion.  The resulting file is called dh1024.pem or dh2048.pem


While this is running, take some time to read a bit more about this interesting process.

Google has this to say about it:
The Diffie–Hellman key exchange (D–H)  is a specific method of securely exchanging cryptographic keys over a public channel and was one of the first public-key protocols as originally conceptualized by Ralph Merkle and named after Whitfield Diffie and Martin Hellman.

So I suggest you take a look at the black-art that is happening at the moment on your Pi:

If it takes too long, and the build-dh is still running, open-up another SSH connection so you can continue the setup. If you do, don’t forget to go to the directory  cd /etc/openvpn/easy-rsa”, and give yourself root permission by executing “sudo –s”. It allows you to watch the process of the d-h key generation in the first window at the same time.

As a last step we’re going to generate the (optional) Denial of Service (DoS) attack protection.   
A DoS attack is where a hacker sends such large numbers of access requests (typically from a large number of hacked PC’s) to a server that it gets overwhelmed to a point where is gets slowed down or even grinds to a halt and can no long allow access to legitimate clients, and “ultimately” this can even crash the server.

OpenVPN has a built-in way to prevent DoS attacks by generating a static pre-shared Hash-based Message Authentication Code (HMAC) key. (look it up on Google) 

With this code in place, the server will only accept client access requests if the client presents this key, if not, the request is simply rejected before serious processing will take place.
The static HMAC key (2048 bit) or ta.key will be generated as follows: 

openvpn --genkey --secret keys/ta.key
At this moment, we have all the private and public keys and certificates for the Pi server and the iPAD client.

Do not forget at this moment that the d-h key generation may still be running. 
Don’t exit the PuTTY session that runs it, or reboot the Pi!

When the dh process has finished, we will now copy the certificate and key files the server needs to the /etc/openvpn directory. So the openvpn program can find them.

cd /etc/openvpn/easy-rsa/keys
cp ca.crt raspi-vpn.crt raspi-vpn.key dh*.pem ta.key /etc/openvpn

Exit the administration root level to bring you back to user level (pi) :


And that concludes the certificate and key generation part.

3. Creating OpenVPN Config & Template Files

We need two configuration files to make an OpenVPN connection work. One for the server and one for the client(s).

There are samples that came with the OpenVPN package installation, and they can be found here:

Server Config File
We’ll start with the server. We’re going to create a new server configuration file for our specific use and put that in the openvpn directory:

sudo –s
cd /etc/openvpn
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .
gzip -d server.conf.gz
nano /etc/openvpn/server.conf

There are a lot of comments and explanations, so take your time to read through them and familiarize yourself with the information on your way to find the certification and key references.
 Change the following three lines with the server name, and the size of the dh key (1024 or 2048) and add the full path names.

ca /etc/openvpn/ca.crt
cert /etc/openvpn/raspi-vpn.crt
key /etc/openvpn/raspi-vpn.key  # This file should be kept secret
dh /etc/openvpn/dh1024.pem

While you’re at it, find and correct the path also with the following line, just in case, but leave the semicolon in place to keep it inactive:

;tls-auth /etc/openvpn/ta.key 0 # This file is secret

Add this section after the server definition (server to tailor the server to our accesspoint setup:

# tunnel adapter parameters
# is local VPN endpoint, is client remote endpoint
push "route"
push "dhcp-option DNS"
push "redirect-gateway def1"

The “ifconfig” defines the server IP and the client IP for the tunnel
The “push route” sends the server IP to the client, so it knows where to send stuff.
The “push dhcp” send the DHCP IP to the client. I used the special DNS, will do too
The last “push” instructs the client about the new Gateway situation.

Disable compression for now by putting a “;”in front.


During testing, change the “verbosity” of status reporting to 4:

verb 4

Set the muting of consecutive errors to 10:

mute 10

Save the file and exit the editor.
Client Template File
Now we’ll start to create the client configuration file. This will actually become a template that we’ll use in a next step. The template will be the base for every client, and we’ll add the specific keys and certificates that are unique for each client to the end of the template file. The completed template will then become a client .opvn file.

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .
nano /etc/openvpn/client.conf

Make the following changes:
remote my-server-1 1194

To the wireless access server IP router address :

remote 1194

Make the following two lines inactive (they are only for Linux clients):

;user nobody
;group nogroup

Remove the “;” to make the muting of consecutive errors active:


Make the following lines inactive by putting the “;” in front of them or delete them. We’re going to embed the keys in the .ovpn file itself.

;ca ca.crt
;cert client.crt
;key client.key

Here is a funny problem that I found when you want to enable the DoS support. This is what is in the supplied client.conf file that came with the installation:

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

If you remove the semi-colon to make it active, it does not work! You can leave the semicolon in place, but need to add this line just below it:

;key-direction 1

Activating the DoS support will be done when you remove the semi-colon from the key-direction line. The 1 means client. 

The same line, with tls-auth ta.key 0 (for server) does work in the server.conf file. Go figure!

Save the file and exit the editor then switch back to user level (pi).


We’re done with the basic server configuration and the basic client template file.

4.   Generating Client Configuration Files

We will now start to work on creating the .ovpn client configuration file that is used to allow the VPN service to work. 

Basically, we’ll use the template information file we just created, which is common for every client, and then embed the specific and unique master certificate, the client certificate, the client secret key and the dh1024/2048.pem key to it.

The HMAC ta.key is optional, and so is the cryptography, but if used, they need to be referenced in both the server and client configuration files as well, and added to the .ovpn file. 

We’ll start without them for this test.

Because we may have several clients, and there are several steps involved, we are going to use a script that does most the work for us.

The shell script is called and has originally been designed and published by Eric Jodoin but has been changed by me. Eric wrote a white paper about setting up OpenVPN on a Pi. It’s one of the many sources I used to learn about VPN’s, and I adjusted the information for my application, and also made it work with Jessie-lite. Here is a link to that white paper.

Switch to administrator (root) level and open the editor with the new filename:

sudo -s
cd /etc/openvpn/easy-rsa

Copy and paste the following script into the open editor:

# Generate a client OpenVPN configuration file (.ovpn)
# with the certificates and keys.
# This shell script must be located in the /etc/openvpn/easy-rsa
# directory for the paths to work.
# Original script written by Eric Jodoin.
# modified by paulv.
# Default Variable Declarations
# Ask for a Client name
# Show a list of clients to select from (includes the server too)
ls *.key | sed 's/\.[^.]*$//'
echo -n "Enter a Client Name from this list: "
read NAME
cd ..
# Create new .ovpn file name

# Check to see if we have the template file from /etc/openvpn/client.conf
if [ ! -f $TEMPLATE ]; then
   cp /etc/openvpn/client.conf template.txt
   echo "Client template file created."

if [ -f $FILE ]; then
   echo "[ERROR]: This Client already has an .ovpn file"
   echo "Delete it from $KEYLOC and try again if you want to generate a new file"

# Verify that client’s Public Key Exists
if [ ! -f $KEYLOC$NAME$CRT ]; then
   echo "[ERROR]: Client Public Key Certificate not found: $NAME$CRT"
#echo "Client’s cert found: $NAME$CR"

# Then, verify that there is a private key for that client
if [ ! -f $KEYLOC$NAME$KEY ]; then
   echo "[ERROR]: Client 3des Private Key not found: $NAME$KEY"
#echo "Client’s Private Key found: $NAME$KEY"

# Confirm the CA public key exists
if [ ! -f $KEYLOC$CA ]; then
   echo "[ERROR]: CA Public Key not found: $CA"
#echo "CA public Key found: $CA"

# Confirm the tls-auth ta key file exists
if [ ! -f $KEYLOC$TA ]; then
   echo "[ERROR]: tls-auth Key not found: $TA"
#echo "tls-auth Private Key found: $TA"

# OK everything is present, start the .ovpn generation
# Start by populating a fresh copy of the template file
echo "Processing $FILE ..."

# Append the CA Public Cert
echo "<ca>" >> $FILE
echo "</ca>" >> $FILE

# Append the client Public Cert
echo "<cert>" >> $FILE
echo "</cert>" >> $FILE

# Append the client Private Key
echo "<key>" >> $FILE
echo "</key>" >> $FILE

# Append the TA Private Key
echo "<tls-auth>" >> $FILE
echo "</tls-auth>" >> $FILE
echo "Done! $NAME$FILEEXT Successfully Created."

# if not there, create the ovpn key directory in the home directory
if [ ! -d /home/pi/openvpn-keys ]; then
   echo "creating /home/pi/openvpn-keys directory"
   mkdir /home/pi/openvpn-keys
# Copy the .ovpn profile to the home directory for convenient remote access
cp /etc/openvpn/easy-rsa/$FILE /home/pi/openvpn-keys/$NAME$FILEEXT
echo "$FILE copied to /home/pi directory openvpn-keys"
# Set permissions to owner(root)rw to protect the files
sudo chmod 600 -R /etc/openvpn/easy-rsa/keys
echo "OpenVPN configuration file generated - done"

Save the file and close the editor. 

Make the shell script executable:

chmod +x

You can now start the script with:


You normally run it once for every client. I just ran it once for the iPAD client.

When you’re done, exit from the root level:


And this is the end of the client .ovpn file generation.

5.   Setting up a Simple Proof of Concept VPN

From the Pi, you now need to get the .ovpn file to your client(s). 

The easiest method, and probably the safest, is to use a USB memory stick to get the .ovpn file to your PC. You then use iTunes to move the ipad.ovpn to the OpenVPN app on the iPAD. (Google it if you don’t know how to do that, below is only a quick run-down)

Because the .ovpn files are safe to transport through public methods, you could also send them by email to other people, or use any other method of file transportation. Up to you.

Before we start our test, we need to undo the settings for the test we ran with HMA!
Flush the current rules in iptables:

sudo iptables -F
sudo iptables -t nat -F
sudo iptables -X

We need yet another set of rules for iptables. In this particular test, the VPN tunnel is going to “sit” between the wireless interface and the Ethernet interface. So in this case, the wlan0 interface will be replaced by the tun0 interface.

Load the new wireless accespoint rules that connect the VPN tunnel (tun0) to the Ethernet interface (eth0):

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

and save them:

sudo sh -c "iptables-save > /etc/iptables/rules.v4"

Create an openvpn test start-up script:

nano /home/pi/

Copy and paste this into the open editor:

sudo openvpn --config /etc/openvpn/server.conf

Save the file and exit the editor. 

This script allows us to easily start the server manually without the daemon option so we can see the reporting on the console. 

Make the file executable:

chmod +x

Run the first test:


Study the details of what is reported on the console. 

Because openvpn server runs in the foreground, start another PuTTY session and log in to look at some other things.
See if you can ping the server:


And look at the interfaces:


Hit Ctrl-c in the other session to stop the OpenVPN server.

We’re now going the activate the OpenVPN client on the iPAD and run the connection test.

Obviously that app needs to be installed on the iPAD. 
If not, install it from the Apple app store. Search for OpenVPN. 

The setup on your iPAD (under Settings, OpenVPN) is straightforward. 
Raise keyboard=OK, Seamless Tunnel =OK, Connect via Wi-Fi only, Reconnect on wakeup=OK, Protocol=UDP, Compression=No (for this test), Connection timeout=30sec. Skip advanced settings. Proxy settings: Host, Port 1194, Allow Basic Auth=OK.

When I tried the connection, it didn’t work the first, second or third time. Actually, I lost track. So eventually, I ended up using a quick-and-dirty method to try things out and change things while I was testing.

I had generated the ipad.ovpn file on the Pi, but needed it on my iPAD. To fix that, I connected my iPAD to my W10 notebook through the special USB cable. I had iTunes open, in the iPAD device “window”. 

In the sidebar on the left (you may have to activate that), under settings, I selected Apps (the ones installed on the iPAD), and in that window, you can see all the apps that are installed on your device. You can scroll down further until you see a new heading appearing called File Sharing. Beneath that is a list of apps on your iPAD that will accept files through iTunes and the Windows file system.

Before I selected that option, I first opened an editor. I like Notepad++, Notepad works too. I opened the editor with a new file. On the Pi, as user pi, I went to the /home/pi/openvpn-keys directory and used “cat ipad.ovpn” to get the file to the console. I then selected the complete contends of the file with the mouse, which acts as “copy”. Then I went to the Notepad++ editor and pasted everything in that open editor. I then saved the file to C:\temp\ipad.ovpn to get easy access. 

If you use Notepad, the file will get saved with the .txt suffix, so you need to use the command interface to rename the file back to ipad.ovpn. You only need to do that once, as long as you don’t change the file name.

So, the ipad.ovpn file is now saved on the PC. 

Now go to iTunes and select the OpenVPN app in the File Sharing section. A new window appears, called OpenVPN Documents. Down below, select the “Add file…” button and go to C:\temp to select ipad.ovpn. The file is now loaded on the iPAD, in an area OpenVPN has access to.

Now go to the iPAD, and open the OpenVPN app. In the top of the window, it tells you that there is a new OpenVPN profile available for import. Below that line you see three buttons. Use the “+” sign button, to load it. As Profile, it should now show, Autologin profile. 
Enter your PK Password and save it. 

The setup is now finished.

Run the test.
Go to the iPAD Settings and select the Open Access Point for the wireless connection, and log in. Then open the OpenVPN app.
Go to your Pi, and start the openvpn server with:


Go back to your iPAD again and start the VPN Connection by clicking on that button.

If all went well, the iPAD will show connected in the Status field. 

You can see what is happening by clicking the “>” on the right of the Status field. 

Now go to Safari on the iPAD and open up a new URL, if all went well, you’ll see that we have a connection to the internet!

So basically at this moment, we have created a VPN tunnel from an iPAD running a VPN client through the air (small cloud) to a wireless access point running on a Pi, that is also running the VPN server application. Not very useful at the moment, but the proof of concept succeeded!

You can now experiment to your heart’s delight with other elements and configuration details.
I’ll do one with you. 
Because we are going to punch a port hole into the firewall of the router back home, we will open ourselves to DoS attacks. OpenVPN has the protection for it, so let’s test that.

We already generated the ta.key, so tell the server to use it by making the tls-auth line active:

sudo nano /etc/openconfig/server.conf
tls-auth /etc/openvpn/ta.key 0 # This file is secret

Save the file and exit the editor. Start the VPN server again and you’ll see on the console that this protection has been added. Now go to your iPAD, and open a connection. It will not succeed, and on the server console, you’ll see this “intruder alert” :

TLS Error: cannot locate HMAC in incoming packet from [AF_INET]

Now add the ta.key to the client. 
Two ways. You can generate a full .ovpn file, and transfer that to the iPAD, or use the quick-and-dirty way I described earlier by editing the file directly on the PC with notepad and save the file on the PC. Then use iTunes to upload the file into the updated OpenVPN client. The ta.key is already in the ipad.ovpn file. All you need to do is to activate the key in the ipad.ovpn file. Edit the file and scroll to find and take away the semi-colon from this line : ;key-direction 1

Save the file to disk. 

Go to iTunes and use the OpenVPN app to add the file. It’s actually the same one with new content. If you have the OpenVPN app open already, you’ll get a message on your iPAD that there is a new profile available for import. Tap on the “+” to do that and re-apply the password and save it.

Connect to the VPN, and this time we’re allowed access again. 
We passed yet another test! Yeah!

We now know how to create configuration files for the OpenVPN server and the client, and we have learned how to create a X.509 Public Key Infrastructure (PKI) model for the encryption and authorization of the VPN and applied protection for DoS attacks.

If you think you need encryption, you can add and test that yourself using this test-bed setup.

Next step will deal with the installation of OpenVPN as a server on my router, and turning the Pi back into a wireless accesspoint with an OpenVPN client setup.

Stay tuned for more steps.