<!doctype linuxdoc system>
<!-- $Id: ipsec-dhcp-howto.sgml,v 1.4 2002/09/02 15:09:24 sri Exp $ -->
<article>
<!-- Header -->
<title>DHCPv4 Configuration of IPsec Tunnel Mode HOWTO
<author>Mario Strasser, <tt>mast@gmx.net</tt>
<date>v0.3.1, 27 August 2002
<abstract>
<nidx>(root)</nidx>
This HOWTO is part of the DHCP-Relay package and describes how
to support the DHCPv4 Configuration of
the IPsec Tunnel Mode with the FreeS/WAN IPSec Stack.
After a short scenario overview, the
installation and configuration of all involved parts
(FreeS/WAN, DHCP-Relay and DHCP-Server) is explained.
To keep things simple, only the needed changes on the IPSec and
DHCP configuration are shown. Thus, it is assumed that FreeS/WAN and
a DHCP-Server are already appropriately configured.
For a installation from scratch the HOWTO includes a number of
references to other documents.
</abstract>
<!-- Table of contents -->
<toc>
<!-- Begin the (main) document -->
<sect>Introduction
<p>
<nidx>(root)!introduction</nidx>
In many remote access scenarios, a mechanism for making the remote host
appear to be present on the local corporate network is quite useful.
This may be accomplished by assigning the host a "virtual" address from
the corporate network, and then tunneling traffic via IPsec from the
host's ISP-assigned address to the corporate security gateway. In IPv4,
the Dynamic Host Configuration Protocol (DHCP) provides for such a remote
host configuration. The Internet-Draft <draft-ietf-ipsec-dhcp-13.txt>
explores the requirements for host
configuration in IPsec tunnel mode, and describes how DHCPv4 may be
leveraged for configuration. This HOWTO describes the needed modifications
of the FreeS/WAN IPSec configuration as well as of further
needed parts, ex. the DHCP-Relay and DHCP-Server.
The latest version of this document can be found at
<url url="http://www.strongsec.com/freeswan/dhcprelay/">.
<sect1>Scenario Overview <label id="overview">
<p>
The configuration examples in the following sections
are based on the following scenario:
<tscreen><verb>
Example LAN
(192.168.0.0/23)
+---------------+ |
| Roadwarrior | +------------+ | +----------------+
| | | Security | | | DHCP-Server |
| +-------+ |-----------| Gateway | |----| |
| |Virtual|<==============>| and |----| | (192.168.0.10) |
| | Host | |-----------| DHCP-Relay | | +----------------+
| +-------+ | IPSec- +------------+ |
+---------------+ Tunnel | +----------------+
| | LAN-Clients |
|----| and |
| | LAN-Servers |
| +----------------+
|
| ...
</verb></tscreen>
<itemize>
<item>Roadwarrior
<itemize>
<item>Gets its <em>real IP</em> address - which is used for Internet connectivity -
from the DHCP-Server of the ISP. This happens independent from the mechanisms
described in this HOWTO.
<item>Gets its <em>virtual IP</em> (VIP) - which is used to access the <em>Example LAN</em>
through the IPSec tunnel - from the DHCP-Server of the <em>Example LAN</em>.
</itemize>
<item>Security Gateway and DHCP-Relay
<itemize>
<item>FreeS/WAN with applied X.509 patch (>= 0.9.14).
<item>DHCP-Relay, forwarding from <tt>ipsec0</tt> to the DHCP-Server over <tt>eth1</tt>.
</itemize>
<item>DHCP-Server
<itemize>
<item>DHCP-Server from the Internet Software Consortium (ISC), issuing
leases to the LAN-Clients as well as to the VPN-Clients.
<item>The address pool for the LAN-Clients is out of the 192.168.0.0/24 subnet
and out of the 192.168.1.0/24 subnet for the VPN-Clients, respectively.
</itemize>
</itemize>
<sect1>Copyright
<p>
Copyright 2002 by Mario Strasser.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
<sect1>Disclaimer
<p>
Use the information in this document at your own risk. I disavow any
potential liability for the contents of this document. Use of the
concepts, examples, and/or other content of this document is entirely
at your own risk.
All copyrights are owned by their owners, unless specifically noted
otherwise. Use of a term in this document should not be regarded as
affecting the validity of any trademark or service mark.
Naming of particular products or brands should not be seen as endorsements.
You are strongly recommended to take a backup of your system before
major installation and backups at regular intervals.
<sect1>Credits
<p>
I would like to thank Dr. Andreas Steffen for proofreading and giving
me support with the configuration files.
<sect>FreeS/WAN with X.509 Patch
<sect1>Installation
<p>
If not already done, download the latest
<url url="http://www.freeswan.org/" name="FreeS/WAN release">
(<em>>= 1.98b</em>) and its dedicated
<url url="http://www.strongsec.com/freeswan/" name ="X.509 patch">
(<em>>= 0.9.14</em>). To apply and install the patch
follow the instructions given in the
<url url="http://www.strongsec.com/freeswan/install.htm"
name="X.509 Patch Installation and Configuration Guide">.
<sect1>Configuration
<p>
In addition to the common transfer tunnels, an additional DHCP tunnel
has to be configured, to transport the initial DHCP Traffic between the
client and the gateway. This tunnel is only needed to negotiate
the DHCP parameters and thus should be setup short-lived. Further,
access should be restricted to protocol <em>udp</em> and ports
<em>bootps (67)</em> and <em>bootpc (68)</em>, respectively.
A sample configuration which should work in most cases is given below
(the gateway is supposed to be <em>on the left</em>):
<code>
conn dhcp
rekey=no
keylife=30s
rekeymargin=15s
leftsubnet=0.0.0.0/0
leftprotoport=udp/bootps
rightprotoport=udp/bootpc
</code>
Some clients do not use this connection to renew their DHCP-lease, but
use the normal data tunnel instead. If so, you have to allow the
client to send its whole traffic over the gateway (leftsubnet=0.0.0.0/0)
as the renew of DHCP-leases has to be done by broadcast under some
circumstances! SSH Sentinel 1.3.X is known to be such a client. As this
is only a internal feature, the client's configuration
must be set to the correct subnet address, not to 0.0.0.0/0!
<code>
conn roadwarrior
leftsubnet=192.168.0.0/23
rightsubnetwithin=192.168.1.0/24
conn roadwarrior-sentinel
leftsubnet=0.0.0.0/0
rightsubnetwithin=192.168.1.0/24
</code>
The whole configuration file, including some general FreeS/WAN options,
can be found in <ref id="ipsec_conf" name="Section 6.1">.
<sect>DHCP-Server
<sect1>Installation
<p>
As DHCPv4 is a well defined standard, almost any DHCP-Server can
be used as long as it supports the <em>DHCP Relay Agent
Information Option</em>. However, I recommend the usage of
the DHCP-Server released by the Internet Software Consortium (ISC):
<url url="http://www.isc.org/products/DHCP/">.
More information can be found in the
<url url="http://www.tldp.org/HOWTO/mini/DHCP/" name="DHCP mini-HOWTO">
or the related <tt>README</tt> file.
<sect1>Configuration
<p>
If the VPN-clients should not be given a IP out of the common
address pool, either the <em>DHCP Relay Agent Information Option</em>
or the <em>Gateway Address</em> can be used,
to distinguish between VPN-clients and normal clients. The first
contains the name of the ipsec device the request came from, the
second is set to the gateway's IP address. The following
sample shows how this may work. See <ref id="dhcpd_conf" name="Section 6.2">
for a complete configuration file.
<code>
# vpn client class
class "vpn-clients" {
match if option agent.circuit-id = "ipsec0";
}
subnet ... {
...
# lan clients
pool {
deny members of "vpn-clients";
...
}
# vpn clients
pool {
allow members of "vpn-clients";
...
}
}
</code>
General information about how to setup a DHCP-Server can be found
either in the <url url="http://www.tldp.org/HOWTO/mini/DHCP/"
name="DHCP mini-HOWTO"> or in the man page of the DHCP-Server
configuration file (<em>dhcpd.conf (5)</em>).
<sect>DHCP-Relay
<sect1>Installation
<p>
Download the source archive from <url url="http://www.strongsec.com/freeswan/dhcprelay/">
then unpack, configure, compile and install it:
<code>
bash# tar -xvzf dhcprelay-X.Y.tar.gz
bash# cd dhcprelay-X.Y
bash# ./configure
bash# make
bash# make install
</code>
In case of troubles, the relay can be compiled in debugging mode
by using the <tt>--enable-debug</tt> argument:
<code>
bash# ./configure --enable-debug
bash# make
bash# make install
</code>
The DHCP-Relay can be started, stopped, restarted and observed using the
<tt>/etc/init.d/dhcprelay</tt> startup script as shown
in the following example:
<code>
bash# /etc/init.d/dhcprelay start
Starting dhcprelay done
bash# /etc/init.d/dhcprelay status
Checking for service dhcprelay: running
bash# /etc/init.d/dhcprelay stop
Shutting down dhcprelay done
</code>
To make the relay starting automatically on start-up, insert
the service with the <tt>insserv</tt> or <tt>chkconfig</tt>tool:
<code>
bash# cd /etc/init.d/
bash# insserv dhcprelay
</code>
Be aware of the fact that FreeS/WAN <em>must</em> already be running
when you start the relay and thus if you restart the FreeS/WAN
service, the DHCP-Relay <em>must</em> be restarted, too!
<sect1>Configuration
<p>
The DHCP-Server configuration file (<tt>/usr/local/etc/dhcprelay.conf</tt>)
contains four items:
<itemize>
<item><tt>LOGFILE</tt> sets the path to log-file of the relay.
<item><tt>DEVICES</tt> is a comma separated list of ipsec
devices the relay should listen on and must contain no spaces!
<item><tt>SERVERDEVICE</tt> the device over which the DHCP-Server
can be reached.
<item><tt>DHCPSERVER</tt> defines the host name or the IP address
of the responsible DHCP-Server. If no server is given, the
packets are forwarded by broadcast.
</itemize>
It follows an example for one ipsec device and a known DHCP-Server,
according to the <ref id="overview" name="overview scenario">.
<code>
# DHCP-Relay configuration file
# Logfile
LOGFILE="/var/log/dhcprelay.log"
# IPSec devices (comma separated list including NO spaces)
DEVICES="ipsec0"
# The device over which the DHCP-Server can be reached
SERVERDEVICE="eth1"
# Hostname or IP Address of the DHCP-Server
DHCPSERVER="192.168.0.10"
</code>
<sect1>Running the DHCP-Server and the DHCP-Relay on the same Host
<p>
Since release 0.3.1 of the DHCP-Relay this can easily be done by
binding both, the relay and the server to the loopback device.
Therefore, set <code>SERVERDEVICE="lo"</code> in the
DHCP-Relay configuration file and add <tt>lo</tt> to the list
of target devices when starting the DHCP-Server. For example:
<code>
bash# dhcpd lo eth1
</code>
Further, the DHCP-Server must be able to reply to request comming over
the <tt>lo</tt> device, which are not out of the dedicated subnet
(127.0.0.0/8). For the ISC DHCP-Server the <tt>subnet</tt> configurations
must therefore be embedded into the <tt>shared-network</tt> statement:
<code>
...
shared-network vpn-networks {
...
subnet 127.0.0.0 netmask 255.0.0.0 {
}
subnet 192.168.0.0 netmask 255.255.255.0 {
...
}
subnet 192.168.1.0 netmask 255.255.255.0 {
...
}
...
}
</code>
See <ref id="dhcpd_conf_2" name="Section 6.3"> for a complete
configuration file.
<sect>Routing Issues
<sect1>Using a Proxy ARP
<p>If you have to use exactly the same subnet for the vpn-clients and the
lan-clients, the vpn-gw must also work as an arp proxy. Therefore you
have to enable arp proxy support in the kernel configuration and activate
it with:
<code>echo 1 > /proc/sys/net/ipv4/conf/ethX/proxy_arp</code>
For further details see the <url name="Linux Advanced Routing and Traffic Control HOWTO"
url="http://lartc.org/howto/lartc.bridging.html">
<sect1>Using a different Subnet for the VPN-Clients
<p>If you have to distinguish between vpn-clients and lan-clients in some
cases, split your network (virtually) in two parts:
<itemize>
<item>use 192.168.0.0/23 for the whole lan
<item>use 192.168.0.0/24 for the vpn-clients
<item>use 192.168.1.0/24 for the lan-clients
<item>if the vpn-gw is not your default gw, add a rule to the default gw
which forwards all 192.168.0.0/24 traffic to the vpn-gw.
<item>use 192.168.0.0/23 for access restrictions where both lan- and
vpn-clients are accepted
<item>use 192.168.0.0/24 for access restrictions where only the vpn-clients
are accepted
<item>use 192.168.1.0/24 for access restrictions where only the lan-clients
are accepted
</itemize>
<sect>Example Configuration Files
<sect1>ipsec.conf <label id="ipsec_conf">
<p>
<code>
# /etc/ipsec.conf - FreeS/WAN IPSEC configuration file
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
dumpdir=/root
conn %default
keyingtries=3
ikelifetime=3h
keylife=1h
disablearrivalcheck=no
# --- RSA authentication using certificates
authby=rsasig
# --- left: this server
left=%defaultroute
leftid=@gw.company.net
leftcert=gwCert.der
leftupdown=/usr/local/lib/ipsec/updown.x509
# --- right: roadwarrior
right=%any
rightrsasigkey=%cert
# --- preferred encryption algorithms
esp=aes128,3des
# --- load connections automatically at startup
auto=add
conn dhcp
rekey=no
keylife=30s
rekeymargin=15s
leftsubnet=0.0.0.0/0
leftprotoport=udp/bootps
rightprotoport=udp/bootpc
conn roadwarrior
leftsubnet=192.168.0.0/23
rightsubnetwithin=192.168.1.0/24
conn roadwarrior-sentinel
leftsubnet=0.0.0.0/0
rightsubnetwithin=192.168.1.0/24
</code>
<sect1>dhcpd.conf <label id="dhcpd_conf">
<p>
<code>
# common server options
ddns-update-style none;
# vpn client class
class "vpn-clients" {
match if option agent.circuit-id = "ipsec0";
}
# example net
subnet 192.168.0.0 netmask 255.255.254.0 {
option domain-name "example.net";
option domain-name-servers ns1.example.net, ns2.example.net;
option routers gw.example.net;
option netbios-name-servers ads.example.net;
# lan clients
pool {
deny members of "vpn-clients";
range 192.168.0.50 192.168.0.254;
default-lease-time 7200;
max-lease-time 14400;
}
# vpn clients
pool {
allow members of "vpn-clients";
range 192.168.1.50 192.168.1.254;
default-lease-time 3600;
max-lease-time 7200;
}
}
</code>
<sect1>dhcpd.conf - DHCP-Server and Relay on the same host<label id="dhcpd_conf_2">
<p>
<code>
# common server options
ddns-update-style none;
# vpn client class
class "vpn-clients" {
match if option agent.circuit-id = "ipsec0";
}
# example net
shared-network vpn-networks {
option domain-name "example.net";
option domain-name-servers ns1.example.net, ns2.example.net;
option routers gw.example.net;
option netbios-name-servers ads.example.net;
# local
subnet 127.0.0.0 netmask 255.0.0.0 { }
# lan clients
subnet 192.168.0.0 netmask 255.255.255.0 {
deny members of "vpn-clients";
range 192.168.0.50 192.168.0.254;
default-lease-time 7200;
max-lease-time 14400;
option subnet-mask 255.255.255.0;
}
# vpn clients
subnet 192.168.1.0 netmask 255.255.255.0 {
allow members of "vpn-clients";
range 192.168.1.50 192.168.1.254;
default-lease-time 3600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
}
}
</code>
<sect1>dhcprelay.conf <label id="dhcprelay_conf">
<p>
<code>
# DHCP-Relay configuration file
# Logfile
LOGFILE="/var/log/dhcprelay.log"
# IPSec devices (comma separated list including NO spaces)
DEVICES="ipsec0"
# The device over which the DHCP-Server can be reached
SERVERDEVICE="eth1"
# Hostname or IP Address of the DHCP-Server
DHCPSERVER="192.168.0.10"
</code>
</article>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
5858dc21eedbfccce934a6003b522bd6
>
files
>
22
