Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up a Virtual Private Network

From bering-uClibc
Jump to: navigation, search
Advanced Topics - Setting Up a Virtual Private Network
Prev Bering-uClibc 5.x - User Guide Next


OpenVPN

This material copied directly from http://leaf.sourceforge.net/doc/bucu-openvpn.html - needs to be checked/updated for Bering-uClibc 5.x!

Introduction

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

Overview of the setup described here

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 built and stored on the LEAF router.

Note: Following the description about creating keys may impose security risks! It's only useful to help you to start with openvpn, in no way it's meant to be used in a production environment.

About openvpn

OpenVPN is a full-featured SSL VPN solution which can accommodate 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 implementations like freeswan/openswan it's easier to setup, supports dynamic IP addresses out of the box and doesn't need any kernel patches.

Loading the packages

Edit the leaf.cfg file and add openvpnz.lrp, easyrsa.lrp and openssl.lrp to the list of Packages to be loaded at boot. Check Basic Configuration - LEAF Packages to learn how to do that.

You don't need liblzo.lrp if you choose the OpenVPN package without lzo support (openvpn.lrp).

The Packages openssl.lrp and easyrsa.lrp are only needed on your OpenVPN server to create the keys. You don't need it on an OpenVPN client and you don't need to load it on your OpenVPN server, once you have created the keys.

Loading the modules

You need to load the tun module tun.ko.gz to have a virtual tunnel interface.

To accomplish this, you need the appropriate modules tarball for your LEAF Bering-uClibc.

Unpack the modules tarball and copy /kernel/drivers/net/tun.ko.gz to /lib/modules on your router.

Add "tun" to your /etc/modules.

Save modules.lrp

Generating keys

To start with OpenVPN 2.x in server/client mode, you'll have to generate SSL keys and certificate those keys. The table below shows which keys and certificates are necessary on which system:

OpenVPN Server OpenVPN Client
CA certificate CA certificate
Server key Client key
Server certificate Client certificate

If you don't have your own CA the next sections describe how to make one and generate the necessary keys and certificates.

If you have your own existing key generation and CA environment you can use that to generate keys and certificates for the server and client(s) and install them manually into the directory defined in the configuration file. The only step that you still need to make with the tools described below is the generation of the Diffie-Hellman parameters.

Setup for key generation on your Bering-uClibc box

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

  1. Configure key generation
  2. Build your own Root Certificate Authority (CA) key and certificate
  3. Build the server key and certificate
  4. Build the client key(s) and certificate(s)

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.

Build your own Root Certification Authority (CA) certificate/key

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

Build Diffie-Hellmann parameters

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

Build the server key

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.

Build the client key(s)

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

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

OpenVPN server side

OpenVPN server configuration

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

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

Configure shorewall on the openvpn server

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

Starting the OpenVPN server

Manual

To test the server configuration you can manually start the OpenVPN server with the command

# openvpn /etc/openvpn/server.conf

Automatic

After a (re)boot the /etc/init.d/openvpn script starts all tunnels that have a definition file in /etc/openvpn. The definition files for VPN's are all files with the extension .conf.

Beginning with openvpn v2.0.9 you can edit the Autostart value in /etc/default/openvpn to explicitely declare the VPN's that shall be started.. Allowed values are "all", "none" or a space separated list of names of the VPNs - to start only the newly created server.conf set "Autostart=server". If Autostart is empty, "all" is assumed. This setting is default in Bering-uClibc's openvpn packages.

Checking

Check /var/log/openvpn-status for the status of your openvpn tunnels

In case of problems /var/log/daemon.log may give some hints for troubleshooting

OpenVPN clients

OpenVPN client configuration

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.

Configure shorewall on an OpenVPN client

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.

Starting the OpenVPN client

Manual

To test the client configuration you can manually start the OpenVPN client with the command

# openvpn /etc/openvpn/client.conf

Automatic

After a (re)boot the /etc/init.d/openvpn script starts all tunnels that have a definition file in /etc/openvpn. The definition files for VPN's are all files with the extension .conf.

Beginning with openvpn v2.0.9 you can change the Autostart value in /etc/default/openvpn to explicitely declare the VPN's that shall be started. Allowed values are "all", "none" or a space separated list of names of the VPNs - to start only the newly created client.conf set "Autostart=client". If Autostart is empty, "all" is assumed. This setting is default in Bering-uClibc's openvpn Packages.

Links

OpenVPN links

OpenVPN main page

German OpenVPN forum

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

OpenSSL tools and hints to how to create your own Certificates

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


Openswan (IPsec)

This material copied directly from http://leaf.sourceforge.net/doc/bucu-openswan.html - needs to be checked/updated for Bering-uClibc 5.x!

Introduction

Objectives

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

Overview of the setup described here

The setup described here assumes you are using openswan 2.6.x with KLIPS (virtual interface support) Furthermore the setup used for this chapter is based on LEAF systems connected to the internet via static IP's. If you don't have a fixed ip, use the ezipupd.lrp Package and a dynamic DNS service like www.dyndns.org.

In the following sections we describe a setup for connecting subnets behind 2 LEAF systems. For the example, these systems are called west and east, and both have a DNS name like west.dyndns.org and east.dyndns.org. Please remember that these names are only examples, use real ones instead!

Example Setup
Example Setup

About openswan

Openswan implements the IPSec Internet Standard for Linux. It is not the only solution but it is based on the oldest implementation of IPSec for Linux called FreeSwan. The FreeSwan project ended some years ago and their code base was used to create openswan. The feature list includes X.509 Certificates, support for nat-t and aggressive mode. It might be a good idea to take a look at the openswan Homepage for a brief description of the features of this software.

Loading the packages

Edit the leaf.cfg file and add openswan.lrp to the list of Packages to be loaded at boot. Check Basic Configuration - LEAF Packages to learn how to do that.

Loading the modules

You need to load the tun Module ipsec.ko.gz to have a virtual tunnel interface and kernel support for ipsec.

To accomplish this, you need the appropriate modules tarball for your LEAF Bering-uClibc. Unpack the modules tarball and copy /kernel/net/ipsec/ipsec.ko.gz to /lib/modules on your router.

You don't need to put it in /etc/modules as the ipsec init script loads and unloads the module on demand.

Save modules.lrp

Generating keys

To start with you will need to generate the necessary certificates, keys and a crl file. The easiest way to do this is to use a frontend like tinyca.

For this example we would need the following files (remember that our systems are called west and east):

  • west-cert.pem
  • east-cert.pem
  • testca-cert.pem
  • west-key.pem
  • east-key.pem
  • crl.pem

The first two files contain the public keys for the leaf systems. copy them to /etc/ipsec.d/certs/ on both machines. testca-cert.pem is the public key of the CA. This file goes onto both machines into /etc/ipsec.d/cacerts/. crl.pem is the certificate revoke list for the CA, which contains a list of disabled certificates. It is normally empty, you would add a cert to this list in case it is stolen, or otherwise compromised. The key files need only to be present on the router they belong to, so west-key.pemwould only go to /etc/ipsec.d/private/ on router west.

These keys are sensitive information, you should NOT put them all on all machines as breaking into this one would compromise them all!

Configuration

ipsec.secrets

Edit /etc/ipsec.secrets.

Change it to look like this (of course use the real password for this key and not "password".

 # This file holds shared secrets or RSA private keys for inter-Pluto
 # authentication.  See ipsec_pluto(8) manpage, and HTML documentation.

 # RSA private key for this host, authenticating it to any other host
 # which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
 # or configuration of other implementations, can be extracted conveniently
 # with "ipsec showhostkey".
 : west-key.pem "password"
 # do not change the indenting of that "}"

ipsec.conf

/etc/ipsec.conf is the main configuration file for openswan ipsec. For our example, it would look like this for router west:

# /etc/ipsec.conf - Openswan IPSec configuration file
 # RCSID $Id: bucu-openswan.xml,v 1.2 2005/11/29 17:13:32 mhnoyes Exp $

 # This file:  /usr/share/doc/openswan/ipsec.conf-sample
 #
 # Manual:     ipsec.conf.5


 version 2.0     # conforms to second version of ipsec.conf specification

 # basic configuration
 config setup
         # plutodebug / klipsdebug = "all", "none" or a combation from below:
         # "raw crypt parsing emitting control klips pfkey natt x509 private"
         # eg:
         # plutodebug="control parsing"
         #
         # Only enable klipsdebug=all if you are a developer
         #
         # NAT-TRAVERSAL support, see README.NAT-Traversal
         # nat_traversal=yes
         # virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
        interfaces=%defaultroute

 # Add connections here

 # sample VPN connection
 conn sample
         # Left security gateway, subnet behind it, nexthop toward right.
         left=%defaultroute
         leftsubnet=192.168.1.0/24
         leftcert=west-cert.pem
         # Right security gateway, subnet behind it, nexthop toward left.
         right=east.dyndns.org
         rightsubnet=192.168.2.0/24
         rightcert=east-cert.pem
         # To authorize this connection, but not actually start it,
         # at startup, uncomment this.
         auto=start

 #Disable Opportunistic Encryption
 include /etc/ipsec.d/examples/no_oe.conf

The %defaultroute entry in interfaces and as left causes openswan to get the corresponding entries by looking at which interface the default route of the system is on. This is normally ok for dynamic connections (DSL, Cable, DHCP). If you have a static IP and are connected to a router via eth1 the interfaces and left entries might look like this (172.16.0.1 is the IP of this router, 172.16.0.2 the IP of router west. Please note that in this case the leftnexthop entry is mandatory!.

       interfaces="ipsec0=eth1"
        left=172.16.0.2
       leftnexthop=172.16.0.1

For router east, you take the same file, put it onto that machine and exchange the left and right values, to look like:

# /etc/ipsec.conf - Openswan IPSec configuration file
 # RCSID $Id: bucu-openswan.xml,v 1.2 2005/11/29 17:13:32 mhnoyes Exp $

 # This file:  /usr/share/doc/openswan/ipsec.conf-sample
 #
 # Manual:     ipsec.conf.5


 version 2.0     # conforms to second version of ipsec.conf specification

 # basic configuration
 config setup
         # plutodebug / klipsdebug = "all", "none" or a combation from below:
         # "raw crypt parsing emitting control klips pfkey natt x509 private"
         # eg:
         # plutodebug="control parsing"
         #
         # Only enable klipsdebug=all if you are a developer
         #
         # NAT-TRAVERSAL support, see README.NAT-Traversal
         # nat_traversal=yes
         # virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
        interfaces=%defaultroute

 # Add connections here

 # sample VPN connection
 conn sample
         # Left security gateway, subnet behind it, nexthop toward right.
         left=west.dyndns.org
         leftsubnet=192.168.1.0/24
         leftcert=west-cert.pem
         # Right security gateway, subnet behind it, nexthop toward left.
         right=%defaultroute
         rightsubnet=192.168.2.0/24
         rightcert=east-cert.pem
         # To authorize this connection, but not actually start it,
         # at startup, uncomment this.
         auto=start

 #Disable Opportunistic Encryption
 include /etc/ipsec.d/examples/no_oe.conf

You do not need to be consistent in what you call left and right at both machines. But it makes things a lot easier if you do keep that naming.

Configure shorewall

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

vpn VPN Remote Subnet

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

vpn ipsec+

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 IPSec enabled interface.

You can either open the traffic between the vpn zone and the local net completely 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 definitions (/etc/shorewall/tunnels)

ipsec net 0.0.0.0/0

Note: The gateway is defined as "0.0.0.0/0" to support remote hosts with dynamic ip addresses.

Starting Openswan

Manual

To test the server configuration you can manually start Openswan with the command

# /etc/init.d/ipsec start

Automatic

After a (re)boot the /etc/init.d/ipsec script starts all tunnels that have a definition file in /etc/ipsec.conf and are marked with a

auto=start

in the definition of the connection.

Checking

Check /var/log/daemon.log and /var/log/auth.log for the status of your ipsec tunnels. You can also use ipsec auto --status

Links

Openswan links

Openswan main page



Prev Up Next