Bering-uClibc 4.x - User Guide - Advanced Topics - Setting Up a Virtual Private Network
| Advanced Topics - Setting Up a Virtual Private Network | ||
|---|---|---|
| Prev | Bering-uClibc 4.x - User Guide | Next |
Contents
OpenVPN
This material copied directly from http://leaf.sourceforge.net/doc/bucu-openvpn.html - needs to be checked/updated for Bering-uClibc 4.x!
Davidmbrooke 20:31, 29 November 2010 (UTC)
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 implemenations 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, liblzo.lrp, libssl.lrp, openssl.lrp and libcrpto.lrp to the list of packages to be loaded at boot. Check the Bering-uClibc Installation Guide to learn how to do that.
You don't need liblzo.lrp if you choose the OpenVPN package without lzo support (openvpn.lrp).
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.o to have a virtual tunnel interface.
To accomplish this, you need the appropriate modules tarball for your LEAF Bering-uClibc. It's usually available for download in our FRS, older versions are available in our cvs repository.
Unpack the modules tarball and copy 2.4.26/kernel/drivers/net/tun.o 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:
- Configure key generation
- Build your own Root Certificate Authority (CA) key and certificate
- Build the server key and certificate
- 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
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.
A nice graphical interface, works for Windows as well as Linux.
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
| Prev | Up | Next |
