This chapter describes how to configure your LEAF system(s) to build Virtual Private Networks (VPN) with OpenVPN.

The setup described here assumes you are using openvpn 2.x in server/client mode. Furthermore the setup used for this chapter is based on LEAF systems connected to the internet via dynamic IP's. It will be similar, but easier, to build VPN's between LEAF systems with a fixed IP or a mixed environment.

We also had in mind to tunnel the subnets behind the LEAF routers. Connecting one or more road-warriors should be easier again.

Additionally only routing (using the TUN interface) between subnets is described, for bridging (using the TAP interface), the differences to routing and advantages/disadvantages of tunneling or bridging please read the according Openvpn documentation.

In our example OpenVPN setup, openvpn uses lzo compression and the keys (esp.the CA authority) are build and stored on the LEAF router.

OpenVPN is a full-featured SSL VPN solution which can accomodate a wide range of configurations, including road warrior access, home/office/campus telecommuting, WiFi security, secure branch office linking, and enterprise-scale remote access solutions with load balancing, failover, and fine-grained access-controls.

Compared with ipsec implemenations like freeswan/openswan it's easier to setup, supports dynamic IP addresses out of the box and doesn't need any kernel patches.

The package easyrsa.lrp provides you with the necessary scripts to do this part of the configuration. For this demo four steps are necessary:

Edit /etc/easy-rsa/vars and change the settings as needed. You should only need to change the values for KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG and KEY_EMAIL. Optionally you can change the KEY_SIZE to a greater value.

Change directory into /etc/easyrsa and source

. /etc/easyrsa/vars

(this means: dot blank /etc/easyrsa/vars)

to export the new settings to your environment variables and the command clean-all, if you build the keys the first time.

With build-ca the ca.crt and ca.key will be built in your KEY_DIR directory.

This step is necessary for the server end of a SSL/TLS connection. Run build-dh.

The server certificates will be built with the build-key-server script (needs the name as parameter which has to be the same as the common name).

You will be asked to sign the certificate with your ca keys - respond "y".

To save your setup and keys backup openvpnz.lrp.

The last step is to build and sign the client keys.

Therefor run the build-key script with the client name as parameter. This name should also be added if you're asked for the "Common Name" during key generation. Again sign the certificates.

Transfer the generated and signed key (foo.crt, foo.key) plus the generated ca.crt in a secure way to your client(s).

Edit /etc/openvpn/server.conf.

Set the ca, cert and key to the generated root certificate, server certificate and server key.

ca keys/ca.crt
cert keys/Server.crt
key keys/Server.key  # This file should be kept secret

Additionally set the path to the key with the Diffie-Hellman parameters:

dh keys/dh1024.pem

Annouce the routes to the client to allow it to reach other private subnets over the openvpn server with the push statement. Remember that these private subnets will also need to know to route the OpenVPN client address pool (10.8.0.0/255.255.255.0) back to the OpenVPN server:

push "route 192.168.10.0 255.255.255.0" 
push "route 192.168.25.0 255.255.255.0" 
push "route 192.168.23.0 255.255.255.0"

Add the routes to the subnets to the OpenVPN server:

route 192.168.25.0 255.255.255.0 vpn_gateway
route 192.168.23.0 255.255.255.0 vpn_gateway 

To allow machines in the subnets behind the OpenVPN clients to access the vpn as well you need to define the client-config-dir an add the route as well:

client-config-dir ccd 
route 192.168.25.0 255.255.255.0 
route 192.168.23.0 255.255.255.0

Given your client-names are vpn-client1 and vpn-client2 add a file for each client with the clients name ("vpnclient1" and "vpn-client2") in /etc/openvpn/ccd and add a statement like:

iroute 192.168.23.0 255.255.255.0

for the client providing the 192.168.23.0 subnet

and

iroute 192.168.25.0 255.255.255.0

for the client providing the 192.168.25.0 subnet

If you want to have the clients and subnets behind seeing each other, enable client-to-client.

Backup ovpn20z.lrp.

Add a new zone to /etc/shorewall/zones:

#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
vpn

Add the tun interface to /etc/shorewall/interfaces:

vpn tun+

Note that we added a wildcard ("+") to the tun interface so the vpn zone applies to all tun interfaces - important if you want to support more than one openvpn client.

You can either open the traffic between the vpn zone and the local net completly with adding

loc vpn ACCEPT 
vpn loc ACCEPT

to /etc/shorewall/policy - or just add the ports you want to open in /etc/shorewall/rules.

As last step add your vpn to the shorewall tunnel defintions (/etc/shorewall/tunnels)

generic:udp:1194 net 0.0.0.0/0

Note: This is very generic definition: Newer shorewall versions support openvpn as tunnel type. The gateway is defined as "0.0.0.0/0" to support clients with dynamic ip addresses.

Edit /etc/openvpn/client.conf.

Change the remote server to your OpenVPN server:

remote my-server-1 1194

You can choose a dynamic DNS entry like:

remote foo.dyndns.org 1194

Uncomment "user" and "group". You also have to uncomment "nobind" on a OpenVPN server, if you need to start a client as well, to make the net behind the OpenVPN server visible to your clients.

Set the path and key names:

ca keys/ca.crt 
cert keys/vpn-client1.crt 
key keys/vpn-client1.key

Backup your OpenVPN package.

Add a new zone to /etc/shorewall/zones:

vpn VPN Remote Subnet

Add the tun interface to /etc/shorewall/interfaces:

vpn tun0

You can either open the traffic between the vpn zone and the local net completly with adding

loc vpn ACCEPT vpn loc ACCEPT

to /etc/shorewall/policy - or just add the ports you want to open in /etc/shorewall/rules.

As last step add your vpn to the shorewall tunnel defintions (/etc/shorewall/tunnels)

generic:udp:1194 net 0.0.0.0/0

Note: This is very generic definition: Newer shorewall versions support openvpn as tunnel type. The gateway is defined as "0.0.0.0/0" to support an openserver with dynamic ip address.

OpenVPN main page

German OpenVPN forum

A valuable forum for german speaking users- if someone knows a similar forum, please let us know.

This points you to sites with software and documenation team member uses to create their own keys.

OpenSSL main page

xca

A nice graphical interface, works for Windows as well as Linux.

tinyca

TinyCA is a simple graphical userinterface written in Perl/Gtk to manage a small CA (Certification Authority). TinyCA works as a frontend for openssl

Creating Self-Signed Certificate Authority Certificate

For those who run the most important servers without X11