Configure Public Key Infrastructure Variables

Before we can generate the public key infrastructure for OpenVPN we must configure a few variables that the easy-rsa scripts will use to generate the scripts. These variables are set near the end of the/etc/openvpn/easy-rsa/2.0/vars file. Here is an example of the relevant values:

File:/etc/openvpn/easy-rsa/2.0/vars

export KEY_COUNTRY="US"
export KEY_PROVINCE="OH"
export KEY_CITY="Oxford"
export KEY_ORG="My Company"
export KEY_EMAIL="[email protected]"

Alter the examples to reflect your configuration. This information will be included in certificates you create and it is important that the information be accurate, particularly the KEY_ORG and KEY_EMAIL values.

Initialize the Public Key Infrastructure (PKI)

Issue the following three commands in sequence to initialize the certificate authority and the public key infrastructure:

cd /etc/openvpn/easy-rsa/2.0/ 
. /etc/openvpn/easy-rsa/2.0/vars 
. /etc/openvpn/easy-rsa/2.0/clean-all 
. /etc/openvpn/easy-rsa/2.0/build-ca

These scripts will prompt you to enter a number of values. By configuring the vars you can be sure that your PKI is configured properly. If you set the correct values in vars, you will be able to press return at each prompt.

Generate Certificates and Private Keys

With the certificate authority generated you can generate the private key for the server. To accomplish this, issue the following command:

. /etc/openvpn/easy-rsa/2.0/build-key-server server

This script will also prompt you for additional information. By default, the Common Name for this key will be “server”. You can change these values in cases where it makes sense to use alternate values. The challenge password and company names are optional and can be left blank. When you’ve completed the question section you can confirm the signing of the certificate and the “certificate requests certified” by answering “yes” to these questions.

With the private keys generated, we can create certificates for all of the VPN clients. Issue the following command:

. /etc/openvpn/easy-rsa/2.0/build-key client1

Replace the client1 parameter with a relevant identifier for each client. You will want to generate a unique key for every user of the VPN. Each key should have it’s own unique identifier. All other information can remain the same. If you need to add users to your OpenVPN at any time, repeat this step to create additional keys.

Generate Diffie Hellman Parameters

The “Diffie Hellman Parameters” govern the method of key exchange and authentication used by the OpenVPN server. Issue the following command to generate these parameters:

. /etc/openvpn/easy-rsa/2.0/build-dh

This should produce the following output:

Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time

This will be followed by a quantity of seemingly random output. The task has succeeded.

Relocate Secure Keys

The /etc/openvpn/easy-rsa/2.0/keys/ directory contains all of the keys that you have generated using the easy-rsa tools.

In order to authenticate to the VPN, you’ll need to copy a number of certificate and key files to the remote client machines. They are:

• ca.crt
• client1.crt
• client1.key

You can use the scp tool, or any other means of transferring. Be advised, these keys should transferred with the utmost attention to security. Anyone who has the key or is able to intercept an unencrypted copy of the key will be able to gain full access to your virtual private network.

Typically we recommend that you encrypt the keys for transfer, either by using a protocol like SSH, or by encrypting them with the PGP tool.

The keys and certificates for the server need to be relocated to the /etc/openvpn directory so the OpenVPN server process can access them. These files are:

• ca.crt
• ca.key
• dh1024.pem
• server.crt
• server.key

Issue the following commands:

cd /etc/openvpn/easy-rsa/2.0/keys 
cp ca.crt ca.key dh1024.pem server.crt server.key /etc/openvpn

These files need not leave your server. Maintaining integrity and control over these files is of the utmost importance to the integrity of your server. If you ever need to move or back up these keys, ensure that they’re encrypted and secured. If these files are compromised, they will need to be recreated along with all client keys.

Revoking Client Certificates

If you need to remove a user’s access to the VPN server, issue the following command sequence.

. /etc/openvpn/easy-rsa/2.0/vars
. /etc/openvpn/easy-rsa/2.0/revoke-full client1

This will revoke the ability of users who have the client1 certificate to access the VPN. For this reason, keeping track of which users are in possession of which certificates is crucial.

# The hostname/IP and port of the server. # You can have multiple remote entries # to load balance between the servers.

remote example.com 1194

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
cert client1.crt
key client1.key

Connect Remote Networks Securely With the VPN

Once configured, the OpenVPN server allows you to encrypt traffic between your local computer and your Linode’s local network. While all other traffic is handled in the conventional manner, the VPN allows traffic on non-public interfaces to be securely passed through your Linode. This will also allow you to connect to the local area network in your Linode’s data center if you are using the LAN to connect to multiple Linodes in the same datacenter. Using OpenVPN in this manner is supported by the default configuration, and if you connect to the OpenVPN you have configured at this point, you will have access to this functionality.

Tunnel All Connections through the VPN

By deploying the following configuration, you will be able to forward all traffic from client machines through your Linode, and encrypt it with transport layer security (TLS/SSL) between the client machine and the Linode. Begin by adding the following parameter to the /etc/openvpn/server.conf file to enable “full tunneling”:

File excerpt:/etc/openvpn/server.conf

push "redirect-gateway def1"

Now edit the /etc/sysctl.conf file to modify the following line to ensure that your system is able to forward IPv4 traffic:

File excerpt:/etc/sysctl.conf

net.ipv4.ip_forward = 1

Issue the following command to set this variable for the current session:

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

Issue the following commands to configure iptables to properly forward traffic through the VPN:

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Before continuing, insert these iptables rules into your system’s /etc/rc.local file to ensure that theses iptables rules will be recreated following your next reboot cycle:

File excerpt:/etc/rc.local

#!/bin/sh
#
# [...]
#

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

touch /var/lock/subsys/local

This will enable all client traffic except DNS queries to be forwarded through the VPN. To forward DNS traffic through the VPN you will need to install the dnsmasq package and modify the/etc/openvpn/server.conf package, or if you are using BIND you need to allow-recursion. 

To allow-recursion in Bind:

To allow Bind to process DNS queries for the VPN clients we need to allow-recursions.

vim <em>/etc/named.conf</em>

make sure the recursion line is set to yes, or that it is NOT present as it Defaults to yes;

recursion yes;

Then make sure that only the subnets you want to allow to use your Bind to process DNS queries is listed and that the OpenVPN subnet range is listed as well:

allow-recursion {
localnets;
127.0.0.1;
10.8.0.0/24;
10.20.0.0/24;
};

 Add the following directive to the /etc/openvpn/server.conf file:

vim /etc/openvpn/server.conf

push "dhcp-option DNS 10.8.0.1"

Finally, before attempting to connect to the VPN in any configuration, restart the OpenVPN server. You will also need to restart bind.

/etc/init.d/openvpn restart

/etc/init.d/named restart

If you do not use Bind on your server you need to setup something small to process the DNS queries for the VPN clients – use dnsmasq:

Begin by issuing the following command to install the service:

yum install dnsmasq

After completing the installation the configuration will need to be modified so that dnsmasq is not listening on a public interface. You will need to find the following lines in the configuration file and make sure the lines are uncommented and have the appropriate values:

File excerpt:/etc/dnsmasq.conf

listen-address=127.0.0.1,10.8.0.1

bind-interfaces

This will configure dnsmasq to listen on localhost and the gateway IP address of your OpenVPN’s tun device.

When your system boots, dnsmasq will try to start prior to the OpenVPN tun device being enabled. This will cause dnsmasq to fail at boot. To ensure that dnsmasq is properly started at boot, you’ll need to modify your /etc/rc.local file once again. By adding the following line, dnsmasq will start after all the init scripts have finished. You should place the restart command below your iptables rules:

File excerpt:/etc/rc.local

/etc/init.d/dnsmasq restart

touch /var/lock/subsys/local

Add the following directive to the /etc/openvpn/server.conf file:

File excerpt:/etc/openvpn/server.conf

push "dhcp-option DNS 10.8.0.1"

Finally, before attempting to connect to the VPN in any configuration, restart the OpenVPN server. You will also need to start dnsmasq and configure it to start at boot by issuing the following commands:

/etc/init.d/openvpn restart
/etc/init.d/dnsmasq restart
chkconfig dnsmasq on

Once these configuration options have been implemented, you can test the VPN connection by connecting to the VPN from your local machine, and access one of the many websites that will display your IP address. If the IP address displayed matches the IP address of your Linode, all network traffic from your local machine will be filtered through your Linode and encrypted over the VPN between your Linode and your local machine. If, however, your apparent public IP address is different from your Linode’s IP address, your traffic is not being filtered through your Linode or encrypted by the VPN.