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
Openswan (IPsec)
This material copied directly from http://leaf.sourceforge.net/doc/bucu-openswan.html - needs to be checked/updated for Bering-uClibc 4.x!
Davidmbrooke 20:44, 29 November 2010 (UTC)
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.4.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!
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
(Bering-uClibc-2.2.0 onwards) file and add openswan.lrp, libpthread.lrp
and mawk.lrp
to the list of packages to be loaded at boot. Check the Bering-uClibc Installation Guide to learn how to do that.
Loading the modules
You need to load the tun module ipsec.o
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. 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.32/kernel/net/ipsec/ipsec.o
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.pem
would 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
Prev | Up | Next |