Setting up OpenVPN on your Debian-based Linux Server

I’ve written extensively about using SSH to to create a “poor man” proxy to protect your data when connecting to an untrusted network (for example in a Starbucks cafe or a hotel). Using an SSH connection with a SOCKS5 proxy is often cumbersome and not all applications natively support the SOCKS protocol.

A simpler method from the client side (although more complicated to set up on the server end) would be to configure your home Linux server to serve as an OpenVPN server. You would then configure your laptop or Android-based mobile device (or any Apple devices) to use the OpenVPN client. An OpenVPN client will force all traffic (including DNS requests) through the home Linux computer and force all Internet-based traffic out of your home Internet connection.

Below are the steps to configure your OpenVPN server and an overview of using the OpenVPN client. It’s important that these steps be done in order.

This HowTo assumes you’re running a variation of a debian-based operating system such as Ubuntu or Linux Mint. Setting up an OpenVPN server requires a moderate level of understanding of the Linux operating system. I don’t recommend this for users new to Linux as it may be difficult to troubleshoot problems.

For these commands, it’s best to just switch to root using the “su” command. Once you’re root, you’ll initially want to update your repositories:

apt-get update

Next, you’ll want to install OpenVPN and easy-rsa.

Once installed the sample OpenVPN configuration file needs to be extracted to /etc/openvpn so it can then be edited for our specific installation.

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

Once extracted, you’ll want to edit this file.

pico /etc/openvpn/server.conf

The server.conf file will look something like this:

# Diffie hellman parameters.

# Generate your own with:

# openssl dhparam -out dh1024.pem 1024

# Substitute 2048 for 1024 if you are using

# 2048 bit keys.

dh dh1024.pem

You will want to edit the last line and change it from dh dh1024.pem to …

dh dh2048.pem

This will double the key length of the key that is generated, increasing security.

Next, you’ll want to look for this section:

# If enabled, this directive will configure

# all clients to redirect their default

# network gateway through the VPN, causing

# all IP traffic such as web browsing and

# and DNS lookups to go through the VPN

# (The OpenVPN server machine may need to NAT

# or bridge the TUN/TAP interface to the internet

# in order for this to work properly).

;push “redirect-gateway def1 bypass-dhcp”

Remove the semicolon from the last line “redirect-gateway def1 bypass-dhcp” so the VPN server passes on clients’ web traffic to its destination.

push “redirect-gateway def1 bypass-dhcp”

The next section you’ll want to edit will look like this:

# Certain Windows-specific network settings

# can be pushed to clients, such as DNS

# or WINS server addresses. CAVEAT:

# http://openvpn.net/faq.html#dhcpcaveats

# The addresses below refer to the public

# DNS servers provided by opendns.com.

;push “dhcp-option DNS”

;push “dhcp-option DNS”

Here, you’ll remove the semicolons as well for the last two lines so it looks like the 2 lines below:

push “dhcp-option DNS”

push “dhcp-option DNS”

The above 2 lines will instruct OpenVPN to use OpenDNS to handle all DNS requests. This is important so that any DNS requests do not leak outside of the encrypted tunnel.

The next area to modify in server.conf is here:

# You can uncomment this out on

# non-Windows systems.

;user nobody

;group nogroup

Remove the semicolons from the last 2 lines so it looks like this:

user nobody

group nogroup

By default, OpenVPN runs as the root user and thus has full access to the system. The above modification will confine OpenVPN to the user nobody and group nogroup. This is an unprivileged user with no default login capabilities and is an appropriate method to secure your OpenVPN server from any abuses from an OpenVPN client.

Save your changes and exit pico.

The line belowis a sysctl setting which tells the server’s kernel to forward traffic from client devices out to the Internet. Otherwise, the traffic will stop at the server. From your command prompt as root, enter this command:

echo 1 > /proc/sys/net/ipv4/ip_forward

We need to make this permanent so the server still forwards traffic after rebooting. To accomplish this you will edit the following file:

pico /etc/sysctl.conf

Near the top of the sysctl file, you will see:

# Uncomment the next line to enable packet forwarding for IPv4


Remove the # from net.ipv4.ip_forward. It should look like this when done:


Save your changes and exit pico.

Now, you’ll need some special settings in your Firewall. By default Ubuntu and Linux Mint come with UFW (Uncomplicated Firewall). If you do not have this already installed, install it. Furthermore you may want to install gUFW or the graphical front-end to Uncomplicated Firewall so you can more easily manage your firewall in the future.

First set ufw to allow SSH. In the command prompt, ENTER:

ufw allow ssh

We use OpenVPN over UDP, so ufw must also allow UDP traffic over port 1194.

ufw allow 1194/udp

The ufw forwarding policy needs to be set as well. We’ll do this in ufw’s primary configuration file.

pico /etc/default/ufw

Look for DEFAULT_FORWARD_POLICY=”DROP”. This must be changed from DROP to ACCEPT. It should look like this when done:


Next we will add additional ufw rules for network address translation and IP masquerading of connected clients.

pico /etc/ufw/before.rules

Make the top of your before.rules file look like below. The area in bold for OPENVPN RULES must be added:


# rules.before


# Rules that should be run before the ufw command line added rules. Custom

# rules should be added to one of these chains:

# ufw-before-input

# ufw-before-output

# ufw-before-forward



# NAT table rules



# Allow traffic from OpenVPN client to eth0




# Don’t delete these required lines, otherwise there will be errors


Save your changes and now enable UFW with the following command:

ufw enable

Enabling ufw will return the following prompt:

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Answer y. The result will be this output:

Firewall is active and enabled on system startup

To check ufw’s primary firewall rules:

ufw status

The status command should return these entries:

Status: active

To Action From

— —— —-

22 ALLOW Anywhere

1194/udp ALLOW Anywhere

22 (v6) ALLOW Anywhere (v6)

1194/udp (v6) ALLOW Anywhere (v6)

It is important to add port 1194, UDP protocol to your home router. That port and protocol will have to be forwarded to the internal IP address of your Linux server. This is a critical step otherwise you will not be able to reach your OpenVPN Linux computer from outside your home.

Creating a Certificate Authority and Server-Side Certificate & Key:

It is now time to set up our own Certificate Authority (CA) and generate a certificate and key for the OpenVPN server. OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established. We will use Easy RSA’s scripts we copied earlier to do this.

First copy over the Easy-RSA generation scripts.

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

Then make the key storage directory.

mkdir /etc/openvpn/easy-rsa/keys

Easy-RSA has a variables file we can edit to create certificates exclusive to our person, business, or whatever entity we choose. This information is copied to the certificates and keys, and will help identify the keys later.

pico /etc/openvpn/easy-rsa/vars

The variables below marked in bold should be changed according to your preference.


export KEY_PROVINCE=”Any state or province

export KEY_CITY=”Any city

export KEY_ORG=”Any company name or make something up

export KEY_EMAIL=”someone@somewhere.com

export KEY_OU=”SomeOrganizationalUnitOrMakeUpAName

In the same vars file, also edit this one line shown below. For simplicity, we will use server as the key name. If you want to use a different name, you would also need to update the OpenVPN configuration files that reference server.key and server.crt.

export KEY_NAME=”server”

We need to generate the Diffie-Hellman parameters; this can take several minutes.

openssl dhparam -out /etc/openvpn/dh2048.pem 2048

Now let’s change directories so that we’re working directly out of where we moved Easy-RSA’s scripts to earlier in Step 2.

cd /etc/openvpn/easy-rsa

(This step below is important!!) Initialize the PKI (Public Key Infrastructure). Pay attention to the dot (.) and space in front of ./vars command. That signifies the current working directory (source). Please note the SPACE between each of the dots below!

. ./vars

The output from the above command is shown below. Since we haven’t generated anything in the keys directory yet, the warning is nothing to be concerned about.

NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys

Now we’ll clear the working directory of any possible old or example keys to make way for our new ones.


This final command below builds the certificate authority (CA) by invoking an interactive OpenSSL command. The output will prompt you to confirm the Distinguished Name variables that were entered earlier into the Easy-RSA’s variable file (country name, organization, etc.).


Simply press ENTER to pass through each prompt. If something must be changed, you can do that from within the prompt.

Generate a Certificate and Key for the Server

Still working from /etc/openvpn/easy-rsa, now enter the command to build the server’s key. Where you see server marked in red is the export KEY_NAME variable we set in Easy-RSA’s vars file earlier.

./build-key-server server

Similar output is generated as when we ran ./build-ca, and you can again press ENTER to confirm each line of the Distinguished Name. However, this time there are two additional prompts:

Please enter the following ‘extra’ attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Both should be left blank, so just press ENTER to pass through each one.

Two additional queries at the end require a positive (y) response:

Sign the certificate? [y/n]

1 out of 1 certificate requests certified, commit? [y/n]

The last prompt above should complete with:

Write out database with 1 new entries

Data Base Updated

Move the Server Certificates and Keys

OpenVPN expects to see the server’s CA, certificate and key in /etc/openvpn. Let’s copy them into the proper location.

cp /etc/openvpn/easy-rsa/keys/{server.crt,server.key,ca.crt} /etc/openvpn

You can verify the copy was successful with:

ls /etc/openvpn

You should see the certificate and key files for the server.

At this point, the OpenVPN server is ready to go. Start it and check the status.

service openvpn start

service openvpn status

The status command should return:

VPN ‘server’ is running

Congratulations! Your OpenVPN server is operational. If the status message says the VPN is not running, then take a look at the /var/log/syslog file for errors such as:

Options error: –key fails with ‘server.key’: No such file or directory

That error indicates server.key was not copied to /etc/openvpn correctly. Re-copy the file and try again.

Generate Certificates and Keys for Clients

So far we’ve installed and configured the OpenVPN server, created a Certificate Authority (CA), and created the server’s own certificate and key. Here we use the server’s CA to generate certificates and keys for each client device which will be connecting to the VPN. These files will later be installed onto the client devices such as a laptop or smartphone.

Key and Certificate Building

It’s ideal for each client connecting to the VPN to have its own unique certificate and key. This is preferable to generating one general certificate and key to use among all client devices.

Note: By default, OpenVPN does not allow simultaneous connections to the server from clients using the same certificate and key. (See duplicate-cn in /etc/openvpn/server.conf.)

To create separate authentication credentials for each device you intend to connect to the VPN, you should complete this step for each device, but change the name client1 below to something different such as MyTablet1 or Laptop1 or any other unique name you prefer. With separate credentials per device, they can later be deactivated at the server individually, if need be. The remaining examples in this tutorial will use client1 as our example client device’s name.

As we did with the server’s key, now we build one for our client1 example. You should still be working out of /etc/openvpn/easy-rsa.

./build-key client1

Once again, you’ll be asked to change or confirm the Distinguished Name variables and these two prompts which should be left blank. Press ENTER to accept the defaults.

Please enter the following ‘extra’ attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

As before, these two confirmations at the end of the build process require a (y) response:

Sign the certificate? [y/n]

1 out of 1 certificate requests certified, commit? [y/n]

If the key build was successful, the output will again be:

Write out database with 1 new entries

Data Base Updated

The example client configuration file should be copied to the Easy-RSA key directory too. We’ll use it as a template which will be downloaded to client devices for editing. In the copy process, we are changing the name of the example file from client.conf to client.ovpn because the .ovpn file extension is what the clients will expect to use in the OpenVPN client program.

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/keys/client.ovpn

You can repeat this section again for each client, replacing client1 with the appropriate client name throughout.

At this point, we need to unify the client’s certificate and keys to a singular OpenVPN file for transfer to the client device.

There are several methods for managing the client files but the easiest uses a unified profile. This is created by modifying the client.ovpn template file to include the server’s Certificate Authority, and the client’s certificate and its key. Once merged, only the single client.ovpn profile needs to be imported into the client’s OpenVPN application.

We will create a single profile for our client1 device on the local computer we downloaded all the client files to. This local computer could itself be an intended client or just a temporary work area to merge the authentication files. The original client.ovpn template file should be duplicated and renamed. How you do this will depend on the operating system of your local computer.

Note: The name of your duplicated client.ovpn doesn’t need to be related to the client device. The client-side OpenVPN application will use the file name as an identifier for the VPN connection itself. Instead, you should duplicate client.ovpn to whatever you want the VPN’s nametag to be in your operating system. For example: work.ovpn will be identified as work, school.ovpn as school, etc.

In this tutorial, we’ll name the VPN connection home so home.ovpn will be the file name referenced from this point on. Once named, we then must open home.ovpn in a text editor; you can use whichever editor you prefer.

The first area of attention will be for the public IP address of your home connection. If your public IP address changes often, you ought to purchase a fully qualified domain name (FQDN) and place that (instead of your constantly-hanging IP) near the top of the file, change my-server-1 to reflect your home OpenVPN server’s public IP (e.g. the IP of your home cable-modem connection or the fully qualified domain name attached to your public IP).

# The hostname/IP and port of the server.

# You can have multiple remote entries

# to load balance between the servers.

remote my-server-1 1194

Next, find the area shown below and uncomment (remove the # symbol) user nobody and group nogroup, just like we did in server.conf in Step 1.

# Downgrade privileges after initialization

user nobody

group nogroup

The area given below needs the three lines shown to be commented out so we can instead include the certificate and key directly in the home.ovpn file. It should look like this when done:

# SSL/TLS parms.

# . . .

#ca ca.crt

#cert client.crt

#key client.key

To merge the individual files into the one unified profile, the contents of the ca.crt, client1.crt, and client1.key files are pasted directly into the .ovpn profile using a basic XML-like syntax. The XML at the end of the file should take this form:

(insert ca.crt here)
(insert client1.crt here)
(insert client1.key here)

When finished, the end of the file should be similar to this abbreviated example:

. . .

. . .
. . .

. . .

The client1.crt file has some extra information in it; it’s fine to just include the whole file.

Save the changes and exit. We now have a unified OpenVPN client profile (.ovpn file) to configure our client1.

Once you’ve merged & saved your certificate and key files into your master .ovpn file, you need to copy this .ovpn file to your client device (e.g. laptop, smartphone or tablet).

Once copied, you would simply install the OpenVPN software and IMPORT the .ovpn file. Once imported you should be able to activate the VPN tunnel. To be sure you’re using the VPN tunnel for your traffic, all you really need to do is visit any WhatIsMyIP webpage to check your public IP. Assuming you’re outside your home Internet connection, you’d visit any WhatIsMyIP web page (such as https://www.whatismyip.com/) and check your public IP. Activate your OpenVPN client using your .ovpn file and then re-visit the https://www.whatismyip.com/ page. Your IP ought to now be the same IP as your home IP address.

Furthermore, to check if your DNS lookups are leaking or not, you’ll want to check out https://www.dnsleaktest.com/ and run a standard test. The test will tell you out of which IP your DNS requests are being routed. They ought to be the same IP as your home Internet connection where your OpenVPN server resides.

If there’s any questions on installing your OpenVPN client on any of your devices, a Google Search should provide plenty of instructional material on how to install the OpenVPN client on your particular device.

On Android for example, it should be as easy as visiting the Android market, installing the OpenVPN app and running it. Once opened, import the .ovpn file you have just created and activate it.

It’s important to understand that the exact same .ovpn file cannot be used on more than one device at the same time. You’ll need to create new keys and certificates (while also copying the ca.crt which never changes) into new & unique .ovpn files for each new device you want to connect with a VPN. So long as each device has its own unique .ovpn file, they can all connect concurrently.