Display Raspberry Pi Metrics using AWS CloudWatch

Background

I am all for cloud computing, however there are some things, in my view, that still need an on-premises presence. One such is devices that allow you to securely connect to your home network. For this, I use a Raspberry Pi running OpenVPN server. OpenVPN is an awesome tool and apart from securely connecting to my home network, it also allows me to securely tunnel my network traffic via my home network when I am connected to an unsecured network.

However, over the last few days, I have been having issues with my vpn connections. It would intermittently disconnect, and at times I will have to try a few times before the connection was re-established. At first it was a nuisance, however lately it has become a bigger issue. Finally, I decided to fix the issue!

After spending some time on it, guess what the problem turned out to be? A few weeks back I had installed a software on my Raspberry Pi for testing purposes. I forgot to uninstall it and now for some reason it was hogging the CPU! As I didn’t need this software, the quick fix was to simply uninstall it.

This got me thinking. There must be a better way to monitor the CPU/Memory/Disk space usage on my Raspberry PI instead of logging onto it every now and then, or worse, when things broke. I could install monitoring tools on it which could notify me when certain thresholds were breached. However, this meant adding more workloads to my Raspberry Pi, something which I wasn’t too keen on doing. I finally decided to publish the metrics to AWS CloudWatch and create some alarms in it.

In this blog, I will list the steps that I followed, to publish my Raspberry Pi metrics to AWS CloudWatch. Without taking much more time, let’s get started.

Create an AWS user for the AWS CloudWatch agent

The AWS CloudWatch agent that will run on our Raspberry Pi needs to be able to authenticate with our AWS account, before it can upload any metrics.

To enable this, create an IAM user with programmatic access and assign the CloudWatchAgentServerPolicy directly to it. When you are creating this IAM user, keep a note of the secret access key that is displayed at the end of the user creation process. If you lose these keys, there is no way to recover them, the only option will be to regenerate it.

For detailed instructions on creating this IAM user, visit https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent-commandline.html

Downloading and installing the AWS CloudWatch agent

With the IAM user done, let’s proceed to installing the AWS CloudWatch agent on the Raspberry Pi. The available agents can be downloaded from https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html

Knowing that my Raspberry Pi runs Raspbian as the operating system, which is a variant of Debian, I proceeded to download the ARM64 version of the .deb file. This is when the fun started!

Running the command

dpkg -I -E ./amazon-cloudwatch-agent.deb

gave me the following error

package architecture (arm64) does not match system (armhf)

Interesting, according to the error, it seemed that my Raspberry Pi has an armhf (arm hard float) architecture, which is not supported by the standard AWS CloudWatch agents. For those interested in the various Debian ports, this webpage lists all of them https://www.debian.org/ports/#portlist-released

This latest discovery put my planning into a tailspin!

After spending some time searching, I came across https://github.com/awslabs/collectd-cloudwatch . This described a plugin for collectd, which would allow me to publish the Raspberry Pi metrics to AWS CloudWatch!

Horary! I was back on track again! Below is a record of what I did next.

  1. On my Raspberry Pi, I installed collectd using
    sudo apt-get install collectd
  2. I then downloaded the installation script for the AWS CloudWatch plugin using the following command
    wget https://github.com/awslabs/collectd-cloudwatch/blob/master/src/setup.py
  3. Once downloaded, I used chmod to make the script executable using the following command
    chmod u+x setup.py
  4. If you look through the script, you will notice that it tries to detect the linux distribution for the system it is running on, and then uses the respective installer commands to install the plugin. Digging abit further, I found that the way it detects the linux distribution is by looking through the files matching the pattern /etc/*-release.

    When I looked at all files fitting the name pattern /etc/*release, the only file I found was /etc/os-release which was a symbolic link to /usr/lib/os-release

    Opening the file /usr/lib/os-release, I noticed that the name of the distribution that was installed on my Raspberry Pi was “Raspbian GNU/Linux

    Comparing this to the script setup.py, I found that it wasn’t one of the supported distributions. Fear not because this is easily remedied!

    So here is what you do.

    Open setup.py in your favorite editor and scroll down to where the following section is

    DISTRIBUTION_TO_INSTALLER = {
      "Ubuntu": APT_INSTALL_COMMAND,
      "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
      "Amazon Linux AMI": YUM_INSTALL_COMMAND,
      "Amazon Linux": YUM_INSTALL_COMMAND,
      "CentOS Linux": YUM_INSTALL_COMMAND,
    }

    Add the line

    "Raspbian GNU": APT_INSTALL_COMMAND,

    after

    "CentOS Linux": YUM_INSTALL_COMMAND

    You should now have the following

    DISTRIBUTION_TO_INSTALLER = {
      "Ubuntu": APT_INSTALL_COMMAND,
      "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
      "Amazon Linux AMI": YUM_INSTALL_COMMAND,
      "Amazon Linux": YUM_INSTALL_COMMAND,
      "CentOS Linux": YUM_INSTALL_COMMAND,
      "Raspbian GNU": APT_INSTALL_COMMAND,
    }
  5. Run setup.py. The script seems to be customised to run within an Amazon EC2 instance because it tries to gather information by querying the instance metadata urls. Ignore these errors and enter the information that is requested. Below are the questions that will be asked

    When asked for your region, enter your AWS region. For me, this is ap-southeast-2
    When asked, enter the hostname of the Raspberry Pi
    Next, you will be asked about the AWS credentials to connect to AWS CloudWatch. Enter the credentials for the user that was created above
    Unless you are using a proxy server, answer none to "Enter a proxy server name" and "Enter a proxy server port"
    At the next prompt for "Include the Auto-Scaling Group name as a metric dimension" choose No
    For "Include the Fixed Dimension as a metric dimension" prompt choose No
    At the next prompt for "Enable high resolution" choose No
    For "Enable flush internal", leave this at "Default 60s"
    The last question asks how to install the CloudWatch plugin. Choose "Add plugin to existing configuration"
  6. Now that all the questions have been answered, you must select the metrics that have to be published to AWS CloudWatch. To check which metrics can be published, open the file

    /opt/collectd-plugins/cloudwatch/config/blocked-metrics.

    From the above file, select the metrics that you want to be published to AWS CloudWatch, and copy them into the file

     /opt/collectd-plugins/cloudwatch/config/whitelist.conf
  7. After the whitelist has been populated, restart the collectd agent so that it can read the updated settings. To do this, issue the following commandt
    sudo service collectd restart
  8. Thats it! Give it approximately five minutes and the Raspberry Pi metrics should be populated inside AWS CloudWatch. To check, login to AWS CloudWatch and under Metrics, you should see a custom namespace for collectd. This is the metrics that were sent from your Raspberry Pi.

Here is a screenshot of the CPU metrics that my Raspberry Pi uploaded to AWS CloudWatch

AWS CloudWatch Raspberry Pi Metrics

 

If you want to be alerted when a certain metric reaches a particular threshold, you can create an alarm within AWS CloudWatch, that notifies you when it happens.

Thats it folks! Till the next time, Enjoy!

Using Amazon Alexa to drive a radio-controlled car – Part 1

Introduction

Over the Easter holidays, while watching my son play with his radio-controlled toy car, I had a strange thought pop into my head. Instead of using the sticks on the remote control, won’t it be cool to control the car by using just your voice? You could tell the car to move forward, backward, left or right. What if you could save all the moves you have asked the car to take so far and then at a later time, get the car to replay all those moves?

Now, that would be a car I would love to play with!

In this blog, I will introduce the high-level design for accomplishing the above-mentioned goal. Then over the next few blogs I will take you through the steps to transform the high-level design into a working prototype.

Hardware Requirements

For this prototype, I settled on using the following hardware devices

  • Amazon Echo Dot – this will be used to process my voice commands
  • Raspberry Pi 3 with a GPIO expansion Breadboard
  • A set of four 5v Relay Board Module
  • A radio-controlled race car
  • A soldering iron, solder wire and a digital multimeter

Design considerations

To make the prototype work, I decided to create an Amazon Alexa Skill called race car. This will be used to process my voice commands.

Challenge #1: How would I control the radio-controlled car?

I found two options for this

1. Completely bypass the remote control and send the radio frequency instructions directly to the race car

2. Emulate the button presses on the remote control so that it “thinks” someone is pressing those buttons and then it sends the appropriate radio frequency instructions to the race car

Option Chosen: I chose option 2 because it required the least amount of work. For this option, the only thing I needed to figure out was what happened when a button was pressed. After some experimentation, I found the contacts on the printed circuit board (PCB) of the remote control which I could open and close the contacts on, to emulate the button presses.

Challenge #2: I will use a python script running on a Raspberry Pi 3 within my home network to emulate the button presses on the remote control. How will I get the Amazon Alexa Skill to connect to my Raspberry Pi 3 which is running on my internal home network?

Solution: I found a neat trick at https://developer.amazon.com/blogs/post/Tx14R0IYYGH3SKT/flask-ask-a-new-python-framework-for-rapid-alexa-skills-kit-development . To expose my internal Raspberry Pi 3 python script to the Amazon Alexa Skill, I will use ngrok (https://ngrok.com) to create a secure tunnel between my Raspberry Pi 3 and the ngrok service. This provides me with an HTTPS endpoint within ngrok’s domain, which forwards any requests directed at the ngrok endpoint to the python script running on my internal Raspberry Pi 3 using the secure tunnel.

High Level Design for the prototype

Using the above-mentioned design considerations, the below schematic was developed to create the prototype.

Let’s go through each of the steps (denoted by the numbers) to better understand the design.

1. The user will invoke the race car Amazon Alexa Skill and ask to either move the car in a certain direction, save all the movements that have been requested so far, or run a previously saved set of movements.

2. The Alexa device (Amazon Echo Dot) will record the audio from the user and send it to the Alexa Cloud for processing. Alexa Cloud converts the audio into JSON using Natural Language Processing (NLP). Based on the invocation name, it will pass the JSON file to the race car Amazon Alexa Skill.

3. The race car Amazon Alexa Skill will check to ensure that the intent supplied by the user is valid. Once confirmed, the race car Amazon Alexa Skill will pass the JSON to the endpoint defined for the skill. In our case, this is an endpoint that is hosted at ngrok (https://ngrok.com)

4. The ngrok endpoint will receive the JSON file from the race car Amazon Alexa Skill and then forward it using the secure tunnel to the python script running on the Raspberry Pi 3 within the home network. The python script will use the Flask-Ask framework to process the intents from the Alexa Skills Kit (more information for Flask-Ask can be obtained from https://flask-ask.readthedocs.io/en/latest/)

5. If the user requested to save all the car movements carried out so far, then the python script will write the movements to a table within Amazon DynamoDB.

6. If the user requested to load a previously saved set of movements, then the python script will read the movements from the table within Amazon DynamoDB.

7. If the use requested to either load a previously saved set of movements or to move the car in a certain direction, the python script will emulate the appropriate button presses on the remote control.

8. The remote control will translate the emulated button presses into radio frequency instructions and send them to the car. The car will receive these instructions and move accordingly.

To give you a sneak peek of the prototype, checkout the video at https://youtu.be/4SMYDhuri0Q (there are some minor bugs with the car movement which I intend on getting fixed as soon as possible).

In the next blog in this series, we will go through the process of “hacking” the remote control and also setting up the Raspberry Pi 3 ancillary hardware.

I hope to see you then.

Till then, enjoy!

Building a VPN Solution using OpenVPN Server on a Raspberry Pi – Part 1 Configuring the Server

Background

Recently I got asked by a friend to recommend a good router/modem that will allow him to vpn into his home network. He was concerned about his internet traffic being eavesdropped on when he connected to a network he didn’t know much about (ah yes, he could just NOT connect to these dodgy networks I hear you say 🙂 )

Well being the good friend that I am, I pointed him to some good routers/modems however it got me thinking. Why not use a Raspberry Pi to accomplish this feat? After a bit of salesmanship, I got my friend convinced that a OpenVPN server running on a  Raspberry Pi was the best solution 🙂

After placing our order for the Raspberry Pi (and the case, power adapter, sd card etc), I started researching on how I would get OpenVPN installed and configured. A quick google search revealed a lot of articles, so I felt quite confident that this task wasn’t too difficult. Well, lets just say that my opinion changed once I started the configuration! I couldn’t find any ONE blog that told me exactly what had to be done. There was always something missing and I had to do my own research to fill in that gap. And that my friend, is essentially the motivation for this blog, to provide a one stop shop for anyone trying to install/configure a OpenVPN server on a Raspberry Pi.

Below are the list of websites I consulted for my configuration

http://itblogsec.com/build-own-openvpn-server-by-using-raspberry-pi-12/

https://jacobsalmela.com/2013/08/11/setting-up-an-openvpn-server-on-the-raspberry-pi/

https://readwrite.com/2014/04/10/raspberry-pi-vpn-tutorial-server-secure-web-browsing/

https://openvpn.net/index.php/open-source/documentation/howto.html

In this part, I will show you how to install and then configure openvpn on a Raspberry Pi. In the next blog post, I will show you how to configure the clients, so that they can connect to the openvpn server.

Pre-requisites

Before we begin, the following are required

  1. Raspberry Pi (obviously 😀 )
  2. Raspbian (for those that are not aware, Raspbian is the operating system that runs on Raspberry Pis. Instructions on how to install it can be found at https://www.raspberrypi.org/downloads/raspbian/ )
  3. a static internal ip address for the Raspberry Pi. This can be easily done by reserving an ip address on your router for the Raspberry Pi
  4. create a port forwarding rule on your router to forward all udp 1194 traffic it receives from the internet to your Raspberry Pi.
  5. an internet routable domain name. If you don’t already own a public DNS hostname, you can use services like https://www.noip.com to get a free domain.
  6. some means of accessing your Raspberry Pi. Initially you will need a usb keyboard and mouse and a tv screen to access it, however the latest builds of Raspbian include RealVNC server by default, so you can configure and then remotely connect to the Raspberry Pi from another computer.
  7. OpenVPN Server comes with 2 free client connection licenses for testing. If you are going to use it for anything other than testing, please visit https://openvpn.net/index.php/access-server/pricing.html to purchase the licenses.

Server Implementation Steps

  1. First and foremost, we need to secure the Raspberry Pi. By default it comes with a username pi and the password for this account is set to raspberry. You can either change the default password by using sudo passwd or create a new account with the same privileges as pi and then lock/delete the pi account. The article at https://www.madirish.net/566 shows how you can create a new account and then lock pi.
  2. Next, start a terminal session and run the following to install openvpn
   sudo apt-get update
   sudo apt-get upgrade
   sudo apt-get install openvpn -y

3.    Open /etc/sysctl.conf using your favorite text editor (I am using nano)

   sudo nano /etc/sysctl.conf

4.     Uncomment (remove the # prefix) the following line and save the changes

   net.ipv4.ip_forward=1

5.    Run the following command to make the change persistent over reboots

   sudo sysctl -p

6.    Next, we will setup a Certificate Authority (CA) and generate certificates and                 keys for the OpenVPN server and clients. For the CA, we will use easy-rsa, a PKI  solution that comes bundled with OpenVPN 2.3.4.

In the terminal window, elevate the session to root privileges using the following

  sudo -s

7.   Then copy the easy-rsa folder to a subfolder under the openvpn folder

  cp -r /usr/share/easy-rsa /etc/openvpn/easy-rsa

8.   Next, modify the vars file included with easy-rsa (I am using nano to modify the file)

  cd /etc/openvpn/easy-rsa
  nano vars

9.   Since we have copied easy-rsa to a new location, change the following line from

  export EASY_RSA="`pwd`" to  export EASY_RSA="/etc/openvpn/easy-rsa"

10.   Scroll down and change KEY_SIZE to 2048 (if different)

   export KEY_SIZE=2048

11.   Going down a few more lines, you will see the default fields that will be used for the certificates. Change these to the appropriate values so that you don’t have to change it each time a certificate is generated

   # These are the default values for fields
   # which will be placed in the certificate.
   # Don't leave any of these fields blank.
   export KEY_COUNTRY="US"
   export KEY_PROVINCE="CA"
   export KEY_CITY="SanFrancisco"
   export KEY_ORG="Fort-Funston"
   export KEY_EMAIL="me@myhost.mydomain"
   export KEY_OU="MyOrganizationalUnit"

12.   Save the changes and exit the text editor

13.   All the prep work has now been done. Lets start with the certificate generation process. Run the following command to build the vars file

   source ./vars

14.   Next, remove any previously generated keys by running the following command (this will delete all contents of /etc/openvpn/easy-rsa/keys folder)

   ./clean-all

15.   Create a Certificate Authority by running the following command and filling in the appropriate values. Press enter to accept the default values or “.” to leave them as blank. For Common Name you can enter OpenVPN-CA

   ./build-ca

(screenshot from http://itblogsec.com/build-own-openvpn-server-by-using-raspberry-pi-12/)

16.   Next, generate a server certificate and key using the following command ( For each of the requested fields, either accept the defaults by pressing Enter or leave them blank by entering “.”  Also, note down the following as well

  • Common Name – enter the public DNS record to your server.
  • when asked for “A challenge password []:” enter “.” to leave it blank.
  • when asked for “An optional company name []:” enter “.” to leave it blank.
  • when asked “Sign the certificate (y/n):” enter y
  • when asked “1 out of 1 certificate requests certified, commit? [y/n]” enter y

{servername} refers to a name for your server (you can use your public DNS name)

   ./build-key-server {servername}

(screenshot from http://itblogsec.com/build-own-openvpn-server-by-using-raspberry-pi-12/)

17.   Next, run the following command to generate a certificate for {client1} where client1 is the name of a user who will be able to use openvpn.

For each of the requested fields, either accept the defaults by pressing enter or leave them blank by entering “.” The most important field is the PEM pass phrase. This is the password that the user will enter every time they establish a vpn session.

Also, when requested for

  • A challenge password []:” – leave this field blank by entering “.”
  • An optional company name []:” – leave this field blank by entering “.”

The command to run isc

   ./build-key-pass {client1}

(screenshot from http://itblogsec.com/build-own-openvpn-server-by-using-raspberry-pi-12/)

18.  AES-256-CBC will be used as the key encryption scheme, so firstly, run the following command and check the output to ensure that your version of OpenVPN supports it

   openvpn --show-ciphers

19.   Next, generate an AES 256 key for {client1} using the following command (replace client1 with the name you gave your user above). You will be asked for “Enter pass phrase for {Client1}.key” – for simplicity, you can make this the same as what you had in step 17 above. Enter the same password when asked for PEM pass phrase 

   cd keys
   openssl rsa -in {client1}.key -aes256 -out {client1}.aes256.key

(screenshot from http://itblogsec.com/build-own-openvpn-server-by-using-raspberry-pi-12/)

20.   Repeat steps 17 – 19 for any additional users that you want to enable for VPN access

21.   Next, we will generate the Diffie-Hellman keys. Use the following commands to do this (be warned that it can take at least 15 minutes for the dh keys to get generated!)

   cd ..
   ./build-dh

 

22.   Ahem, this is turning out to be a long blog. Bear with me, we are not too far away from completing the OpenVPN setup 😉

Since our OpenVPN server will be open to the big bad internet, we need to ensure it is properly secured. To do this, we will be using tls-auth

From https://openvpn.net/index.php/open-source/documentation/howto.html#redirect

“The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

  • DoS attacks or port flooding on the OpenVPN UDP port.
  • Port scanning to determine which server UDP ports are in a listening state.
  • Buffer overflow vulnerabilities in the SSL/TLS implementation.
  • SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).”

Using tls-auth requires the generation of a shared secret key that is used in addition to the standard RSA certificate/key. Run the following command to generate this (ensure you are in the /etc/openvpn/easy-rsa/keys folder)

  openvpn --genkey --secret keys/ta.key

23.   Next, we will create a customised OpenVPN server configuration file. A sample server.conf file is already present. Use the following commands to copy it to /etc/openvpn folder (ensure you are already in the /etc/openvpn folder)

  cp -v /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz  /etc/openvpn
  gunzip -v /etc/openvpn/server.conf.gz

After unzipping the file, server.conf will be placed in /etc/openvpn

24.   It is good practise to rename server.conf file to your servername. This differentiates it from the standard template file. In my case, I have renamed it to servername.conf. Open the servername.conf file using a text editor (I am using nano)

   nano servername.conf

25.  We will go through the file servername.conf and change the following items. If the items are commented out using a prefix of # or ; then uncomment them

I have read numerous places that the line ;local a.b.c.d needs to be uncommented and a.b.c.d needs to be changed to the OpenVPN server’s ip address. However, when I did that, my OpenVPN server would always error when the Raspberry Pi boots/reboots with the following error

“TCP/UDP: Socket bind failed on local address [AF_INET]{ipaddress}:1194: Cannot assign requested address”

To fix this issue, I left the line ;local a.b.c.d commented out

port 1194
proto udp
dev tun

The key locations need to be updated to the following. These will correspond to the keys that were generated above

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/{servername}.crt
key /etc/openvpn/easy-rsa/keys/{servername}.key
dh  /etc/openvpn/easy-rsa/keys/dh2048.pem

the following should remain as they are

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

the following lines push settings to the clients that connect to the vpn. These values override what the client already has

push "route 10.8.0.0 255.255.255.0"
push "route {raspberry pi ip address} 255.255.255.255
push "dhcp-option DNS {your home router's internal ip address}"

the next line makes sure that all of the client’s traffic passes through the OpenVPN server. We will setup the OpenVPN server to handle this traffic via NAT a bit further down in this blog

push "redirect-gateway def1"

Uncomment the following line if you want the connected clients to reach each other. By default, the clients can only reach to the server

client-to-client

It is not recommended, however if you are going to have multiple clients connect to the OpenVPN server using the same certificate/key files or common names then uncomment the following. IT IS HIGHLY RECOMMENDED THAT EACH CLIENT HAVE THEIR OWN CERTIFICATE/KEY and COMMON NAME.

duplicate-cn

Update the location of the tls-auth key with the following line

tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0

ensure the cryptographic cipher is setup to the following

cipher AES-256-CBC

Next, we need to strip all permissions and privileges from the openvpn process when it runs, so that in case it gets compromised, there is no permission leak. This is done by uncommenting the following lines

user nobody
group nobody

Scroll down a few more lines and check that the following are listed in the config file

persist-key
persist-tun

Lets enable logging and ensure they are all output to /var/log folder. Change the status log line as below

status /var/log/openvpn-status.log

for the actual log file, you can either enable the log file to get rewritten every time openvpn starts or you can append to the existing log file. I personally prefer log-append. So, based on your selection, uncomment one of the following and change appropriately

log /var/log/openvpn.log
log-append  /var/log/openvpn.log

Lastly, make sure the following lines are present in the config file

verb 3
explicit-exit-notify 1

save the configuration file

26.   Next on the list is configuring NAT on the Raspberry Pi interface that is being used by the openvpn server. For the sake of portability, I am using wlan0 however you can use the ethernet interface (now be careful when you use the ethernet interface, on Raspberry Pi 3, it is not named something simple as eth0 but it is enx{mac-address} where mac-address is the mac-address of the interface)

Use the following line to enable NAT on the wireless interface

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o wlan0 -j MASQUERADE

save the updated rules using the following to make it persistent

iptables-save > /etc/iptables/rules.v4

27.   Let’s test that openvpn is happy with the configuration file. To do this, run the following command

openvpn servername.conf

check the logs at /var/log/openvpn.log to ensure you see something similar to below

Sun Feb 6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 5 2005
Sun Feb 6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key
Sun Feb 6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Feb 6 20:46:38 2005 TUN/TAP device tun1 opened
Sun Feb 6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Sun Feb 6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Sun Feb 6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
Sun Feb 6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194
Sun Feb 6 20:46:38 2005 UDPv4 link remote: [undef]
Sun Feb 6 20:46:38 2005 MULTI: multi_init called, r=256 v=256
Sun Feb 6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62
Sun Feb 6 20:46:38 2005 IFCONFIG POOL LIST
Sun Feb 6 20:46:38 2005 Initialization Sequence Completed

 

28.   Now that we have confirmation that the configuration is successful, the only task left is to ensure that openvpn server starts automatically every time Raspberry Pi starts. To do this, open /etc/defaults/openvpn using a text editor and add the following underneath the bunch of lines starting with AUTOSTART

AUTOSTART="servername.conf"

So, essentially, below is what you should see (the text in orange is what was added)

#AUTOSTART="all"
#AUTOSTART="none"
#AUTOSTART="home office"
AUTOSTART="servername.conf"

Woo hoo! Give your self a pat on the back for a job well done! The openvpn server configuration is now complete. I am mindful that this blog has grown to a mammoth size. I will detail the client configuration in the next blog. So off you go, have a break, a refreshing beverage if you must and come back for the client configuration 🙂

The client configuration settings are found at https://nivleshc.wordpress.com/2017/08/31/building-a-vpn-solution-using-openvpn-server-on-a-raspberry-pi-part2-configuring-the-clients/