Show by Label

Thursday, March 17, 2016

(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 hma-openvpn.sh 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 (https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html) 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=
me@myhost.mydomain
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.

./clean-all

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.

./build-ca

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

./build-dh

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: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

NOTE:
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) :

exit

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:
/usr/share/doc/openvpn/examples/sample-config-files/

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 10.8.0.0 255.255.255.0) to tailor the server to our accesspoint setup:

# tunnel adapter parameters
# 10.8.0.1 is local VPN endpoint, 10.8.0.2 is client remote endpoint
ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.1 255.255.255.255"
push "dhcp-option DNS 185.37.37.37"
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, 8.8.8.8 will do too
The last “push” instructs the client about the new Gateway situation.

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

;comp-lzo

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:
Change:
 
remote my-server-1 1194

To the wireless access server IP router address :

remote 192.168.200.1 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:

mute-replay-warnings

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).

exit

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 MakeOVPN.sh 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
nano MakeOVPN.sh

Copy and paste the following script into the open editor:

#!/bin/bash
# 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
KEYLOC="keys/"
TEMPLATE="template.txt"
FILEEXT=".ovpn"
CRT=".crt"
KEY=".3des.key"
CA="ca.crt"
TA="ta.key"
# Ask for a Client name
# Show a list of clients to select from (includes the server too)
cd $KEYLOC
ls *.key | sed 's/\.[^.]*$//'
echo -n "Enter a Client Name from this list: "
read NAME
cd ..
# Create new .ovpn file name
FILE=$KEYLOC$NAME$FILEEXT

# 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."
fi

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"
   exit
fi

# Verify that client’s Public Key Exists
if [ ! -f $KEYLOC$NAME$CRT ]; then
   echo "[ERROR]: Client Public Key Certificate not found: $NAME$CRT"
   exit
fi
#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"
   exit
fi
#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"
   exit
fi
#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"
   exit
fi
#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 ..."
cat $TEMPLATE > $FILE

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

# Append the client Public Cert
echo "<cert>" >> $FILE
cat $KEYLOC$NAME$CRT | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >> $FILE
echo "</cert>" >> $FILE

# Append the client Private Key
echo "<key>" >> $FILE
cat $KEYLOC$NAME$KEY >> $FILE
echo "</key>" >> $FILE

# Append the TA Private Key
echo "<tls-auth>" >> $FILE
cat $KEYLOC$TA >> $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
fi
# 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 MakeOVPN.sh

You can now start the script with:

./MakeOVPN.sh

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:

exit

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/start-ovpn.sh

Copy and paste this into the open editor:

#!/bin/sh
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 start-ovpn.sh

Run the first test:

./start-ovpn.sh

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:

ping 10.8.0.1

And look at the interfaces:

ifconfig

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 192.168.200.1, 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 192.168.200.1/ipad, 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:

./start-ovpn.sh

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]192.168.200.10:60570

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.

No comments:

Post a Comment