Table of Contents
This chapter describes how to configure your LEAF system(s) to build Virtual Private Networks (VPN) with Openswan.
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!
Example
Setup
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.
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.
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
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.pemeast-cert.pemtestca-cert.pemwest-key.pemeast-key.pemcrl.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!
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 "}"
/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.confThe %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.1For 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.confYou 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.
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.
To test the server configuration you can manually start Openswan with the command
# /etc/init.d/ipsec start
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.