<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>IPSEC using Linux Kernel 2.6</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="IPSEC"></a>IPSEC using Linux Kernel 2.6</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Roberto</span> <span class="surname">Sanchez</span></h3></div></div></div><div><p class="copyright">Copyright © 2004, 2005, 2006 Thomas M. Eastep</p></div><div><p class="copyright">Copyright © 2007 Roberto C. Sanchez</p></div><div><div class="legalnotice"><a id="id284283"></a><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Overview">Shorewall 3.0 and Kernel 2.6 IPSEC</a></span></dt><dt><span class="section"><a href="#GwFw">IPSec Gateway on the Firewall System</a></span></dt><dt><span class="section"><a href="#RoadWarrior">Mobile System (Road Warrior)</a></span></dt><dt><span class="section"><a href="#RW-L2TP">Mobile System (Road Warrior) with Layer 2 Tunneling Protocol
(L2TP)</a></span></dt><dt><span class="section"><a href="#Transport">Transport Mode</a></span></dt><dt><span class="section"><a href="#ipcomp">IPCOMP</a></span></dt><dt><span class="section"><a href="#XP">IPSEC and <span class="trademark">Windows</span>™ XP</a></span></dt><dt><span class="section"><a href="#More">Source of Additional Samples</a></span></dt></dl></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span class="bold"><strong>This article applies to Shorewall 3.0 and
later. If you are running a version of Shorewall earlier than Shorewall
3.0.0 then please see the documentation for that
release.</strong></span></p></div><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>The information in this article is only applicable if you plan to
have IPSEC end-points on the same system where Shorewall is used.</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>To use the features described in this article, your kernel must be
2.6.16 or later <span class="bold"><strong>or</strong></span> your kernel and
iptables must include the Netfilter+ipsec patches and policy match
support. The Netfilter patches are available from Netfilter
Patch-O-Matic-NG and are also included in some commercial distributions
(most notably <span class="trademark">SUSE</span>™ 9.1 through 10.0).</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>As of this writing, the Netfilter+ipsec and policy match support are
broken when used with a bridge device. The problem has been reported to
the responsible Netfilter developer who has confirmed the problem. The
problem was presumably corrected in Kernel 2.6.20 as a result of the
removal of deferred FORWARD/OUTPUT processing of traffic destined for a
bridge. See the <a class="ulink" href="bridge-Shorewall-perl.html" target="_self">"<span class="emphasis"><em>Shorewall-perl and Bridged
Firewalls</em></span>"</a> article.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Overview"></a>Shorewall 3.0 and Kernel 2.6 IPSEC</h2></div></div></div><p>This is <span class="bold"><strong>not</strong></span> a HOWTO for Kernel 2.6
IPSEC -- for that, please see <a class="ulink" href="http://www.ipsec-howto.org/" target="_self">http://www.ipsec-howto.org/</a>.</p><p>The 2.6 Linux Kernel introduces new facilities for defining
encrypted communication between hosts in a network. The network
administrator defines a set of <em class="firstterm">Security Policies</em>
which are stored in the kernel as a <em class="firstterm">Security Policy
Database</em> (SPD). Security policies determine which traffic is
subject to encryption. <em class="firstterm">Security Associations</em> are
created between pairs of hosts in the network (one SA for traffic in each
direction); these SAs define how traffic is to be encrypted. Outgoing
traffic that is to be encrypted according to the contents of the SPD
requires an appropriate SA to exist. SAs may be created manually using
<span class="command"><strong>setkey</strong></span>(8) but most often, they are created by a
cooperative process involving the ISAKMP protocol and daemons such
as<span class="command"><strong> racoon</strong></span> or <span class="command"><strong>isakmpd</strong></span>. Incoming
traffic is verified against the SPD to ensure that no unencrypted traffic
is accepted in violation of the administrator's policies.</p><p>There are three ways in which IPSEC traffic can interact with
Shorewall policies and rules:</p><div class="orderedlist"><ol type="1"><li><p>Traffic that is encrypted on the firewall system. The traffic
passes through Netfilter twice -- first as unencrypted then
encrypted.</p></li><li><p>Traffic that is decrypted on the firewall system. The traffic
passes through Netfilter twice -- first as encrypted then as
unencrypted.</p></li><li><p>Encrypted traffic that is passed through the firewall system.
The traffic passes through Netfilter once.</p></li></ol></div><p>In cases 1 and 2, the encrypted traffic is handled by entries in
<code class="filename">/etc/shorewall/tunnels</code> (don't be mislead by the name
of the file -- <span class="emphasis"><em>transport mode</em></span> encrypted traffic is
also handled by entries in that file). The unencrypted traffic is handled
by normal rules and policies.</p><p>Under the 2.4 Linux Kernel, the association of unencrypted traffic
and zones was made easy by the presence of IPSEC pseudo-interfaces with
names of the form <code class="filename">ipsecn</code> (e.g.
<code class="filename">ipsec0</code>). Outgoing unencrypted
traffic (case 1.) was send through an <code class="filename">ipsecn</code> device while incoming unencrypted
traffic (case 2) arrived from an <code class="filename">ipsecn</code> device. The 2.6 kernel-based
implementation does away with these pseudo-interfaces. Outgoing traffic
that is going to be encrypted and incoming traffic that has been decrypted
must be matched against policies in the SPD and/or the appropriate
SA.</p><p>Shorewall provides support for policy matching in three ways:</p><div class="orderedlist"><ol type="1"><li><p>In <code class="filename">/etc/shorewall/masq</code>, traffic that will
later be encrypted is exempted from MASQUERADE/SNAT using existing
entries. If you want to MASQUERADE/SNAT outgoing traffic that will
later be encrypted, you must include the appropriate indication in the
new IPSEC column in that file.</p></li><li><p>The<code class="filename"> </code><a class="ulink" href="manpages/shorewall-zones.html" target="_self"><code class="filename">/etc/shorewall/zones</code></a>
file allows you to associate zones with traffic that will be encrypted
or that has been decrypted.</p></li><li><p>A new option (<span class="bold"><strong>ipsec</strong></span>) has been
provided for entries in <code class="filename">/etc/shorewall/hosts</code>.
When an entry has this option specified, traffic to/from the hosts
described in the entry is assumed to be encrypted.</p></li></ol></div><p>In summary, Shorewall provides the facilities to replace the use of
ipsec pseudo-interfaces in zone and MASQUERADE/SNAT definition.</p><p>There are two cases to consider:</p><div class="orderedlist"><ol type="1"><li><p>Encrypted communication is used to/from all hosts in a
zone.</p><p>The value <span class="bold"><strong>ipsec</strong></span> is placed in
the TYPE column of the <code class="filename">/etc/shorewall/zones</code> entry
for the zone.</p></li><li><p>By default, encrypted communication is not used to communicate
with the hosts in a zone.</p><p>The value <span class="bold"><strong>ipv4</strong></span> is placed in the
TYPE column of the <code class="filename">/etc/shorewall/zones</code> entry for
the zone and the new <span class="bold"><strong>ipsec</strong></span> option is
specified in <code class="filename">/etc/shorewall/hosts</code> for any hosts
requiring secure communication.</p></li></ol></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>For simple zones such as are shown in the following examples, the
two techniques are equivalent and are used interchangeably.</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>It is redundant to have <span class="bold"><strong>ipsec</strong></span> in
the TYPE column of the <code class="filename">/etc/shorewall/zones</code> entry
for a zone and to also have the <span class="bold"><strong>ipsec</strong></span>
option in <code class="filename">/etc/shorewall/hosts</code> entries for that
zone.</p></div><p>Finally, the OPTIONS, IN OPTIONS and OUT OPTIONS columns in
/etc/shorewall/zones can be used to match the zone to a particular (set
of) SA(s) used to encrypt and decrypt traffic to/from the zone and the
security policies that select which traffic to encrypt/decrypt.</p><p>This article assumes the use of ipsec-tools (<a class="ulink" href="http://ipsec-tools.sourceforge.net" target="_self">http://ipsec-tools.sourceforge.net</a>).
As of this writing, I recommend that you run at least version 0.5.2.
Debian users, please note that there are separate Debian packages for
ipsec-tools and racoon although the ipsec-tools project releases them as a
single package.</p><p>For more information on IPSEC, Kernel 2.6 and Shorewall see <a class="ulink" href="LinuxFest.pdf" target="_self">my presentation on the subject given at LinuxFest NW
2005</a>. Be warned though that the presentation is based on Shorewall
2.2 and there are some differences in the details of how IPSEC is
configured.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="GwFw"></a>IPSec Gateway on the Firewall System</h2></div></div></div><p>Suppose that we have the following situation:</p><div><img src="images/TwoNets1.png" /></div><p>We want systems in the 192.168.1.0/24 sub-network to be able to
communicate with systems in the 10.0.0.0/8 network. We assume that on both
systems A and B, eth0 is the Internet interface.</p><p>To make this work, we need to do two things:</p><div class="orderedlist"><ol type="a"><li><p>Open the firewall so that the IPSEC tunnel can be established
(allow the ESP and AH protocols and UDP Port 500).</p></li><li><p>Allow traffic through the tunnel.</p></li></ol></div><p>Opening the firewall for the IPSEC tunnel is accomplished by adding
an entry to the <code class="filename">/etc/shorewall/tunnels</code> file.</p><p>In <code class="filename">/etc/shorewall/tunnels</code> on system A, we need
the following</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename"><code class="filename">/etc/shorewall/tunnels</code></code> —
System A:</p><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 134.28.54.2
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre><p><code class="filename"><code class="filename">/etc/shorewall/tunnels</code></code> —
System B:</p><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 206.162.148.9
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If either of the endpoints is behind a NAT gateway then the
tunnels file entry on the <span class="bold"><strong>other</strong></span>
endpoint should specify a tunnel type of ipsecnat rather than ipsec and
the GATEWAY address should specify the external address of the NAT
gateway.</p></div><p>You need to define a zone for the remote subnet or include it in
your local zone. In this example, we'll assume that you have created a
zone called “<span class="quote">vpn</span>” to represent the remote subnet.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename"><code class="filename">/etc/shorewall/zones</code></code> —
Systems A and B:</p><pre class="programlisting">#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
vpn ipv4
net ipv4
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><p>Remember the assumption that both systems A and B have eth0 as their
Internet interface.</p><p>You must define the vpn zone using the
<code class="filename">/etc/shorewall/hosts</code> file. The hosts file entries
below assume that you want the remote gateway to be part of the vpn zone —
If you don't wish the remote gateway included, simply omit its IP address
from the HOSTS column.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/hosts</code> — System A</p><pre class="programlisting">#ZONE HOSTS OPTIONS
vpn eth0:10.0.0.0/8,134.28.54.2 <span class="bold"><strong> ipsec</strong></span>
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre><p><code class="filename">/etc/shorewall/hosts</code> — System B</p><pre class="programlisting">#ZONE HOSTS OPTIONS
vpn eth0:192.168.1.0/24,206.162.148.9 <span class="bold"><strong>ipsec</strong></span>
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><p>Assuming that you want to give each local network free access to the
remote network and vice versa, you would need the following
<code class="filename">/etc/shorewall/policy</code> entries on each system:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#SOURCE DESTINATION POLICY LEVEL BURST:LIMIT
loc vpn ACCEPT
vpn loc ACCEPT</pre></blockquote></div><p>If you need access from each firewall to hosts in the other network,
then you could add:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#SOURCE DESTINATION POLICY LEVEL BURST:LIMIT
$FW vpn ACCEPT</pre></blockquote></div><p>If you need access between the firewall's, you should describe the
access in your /etc/shorewall/rules file. For example, to allow SSH access
from System B, add this rule on system A:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO POLICY
ACCEPT vpn:134.28.54.2 $FW</pre></blockquote></div><p>Note that your Security Policies must also be set up to send traffic
between 134.28.54.2 and 206.162.148.9 through the tunnel (see
below).</p><p>Once you have these entries in place, restart Shorewall (type
shorewall restart); you are now ready to configure IPSEC.</p><p>For full encrypted connectivity in this configuration (between the
subnets, between each subnet and the opposite gateway, and between the
gateways), you will need eight policies in
<code class="filename">/etc/racoon/setkey.conf</code>. For example, on gateway
A:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting"># First of all flush the SPD and SAD databases
spdflush;
flush;
# Add some SPD rules
spdadd 192.168.1.0/24 10.0.0.0/8 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require;
spdadd 192.168.1.0/24 134.28.54.2/32 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require;
spdadd 206.162.148.9/32 134.28.54.2/32 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require;
spdadd 206.162.148.9/32 10.0.0.0/8 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require;
spdadd 10.0.0.0/8 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require;
spdadd 10.0.0.0/8 206.162.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require;
spdadd 134.28.54.2/32 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require;
spdadd 134.28.54.2/32 206.162.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require;</pre></blockquote></div><p>The <code class="filename">setkey.conf</code> file on gateway B would be
similar.</p><p>A sample <code class="filename">/etc/racoon/racoon.conf</code> file using
X.509 certificates might look like:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">path certificates "/etc/certs" ;
listen
{
isakmp 206.162.148.9;
}
remote 134.28.54.2
{
exchange_mode main ;
certificate_type x509 "GatewayA.pem" "GatewayA_key.pem" ;
verify_cert on;
my_identifier asn1dn ;
peers_identifier asn1dn ;
verify_identifier on ;
lifetime time 24 hour ;
proposal {
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method rsasig ;
dh_group 2 ;
}
}
sainfo address 192.168.1.0/24 any address 10.0.0.0/8 any
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm blowfish ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
sainfo address 206.162.148.9/32 any address 10.0.0.0/8 any
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm blowfish ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
sainfo address 206.162.148.9/32 any address 134.28.54.2/32 any
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm blowfish ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
sainfo address 192.168.1.0/24 any address 134.28.54.2/32 any
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm blowfish ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}</pre><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you have hosts that access the Internet through an IPSEC
tunnel, then it is a good idea to set the MSS value for traffic from
those hosts explicitly in the
<code class="filename">/etc/shorewall/zones</code> file. For example, if hosts
in the <span class="bold"><strong>sec</strong></span> zone access the Internet
through an ESP tunnel then the following entry would be
appropriate:</p><pre class="programlisting">#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
sec ipsec mode=tunnel <span class="bold"><strong>mss=1400</strong></span></pre><p>You should also set FASTACCEPT=No in shorewall.conf to ensure
that both the SYN and SYN,ACK packets have their MSS field
adjusted.</p><p>Note that CLAMPMSS=Yes in <code class="filename">shorewall.conf</code>
isn't effective with the 2.6 native IPSEC implementation because there
is no separate ipsec device with a lower mtu as there was under the
2.4 and earlier kernels.</p></div></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="RoadWarrior"></a>Mobile System (Road Warrior)</h2></div></div></div><p>Suppose that you have a laptop system (B) that you take with you
when you travel and you want to be able to establish a secure connection
back to your local network.</p><div><img src="images/Mobile.png" /></div><div class="example"><a id="roadWarrior"></a><p class="title"><b>Example 1. Road Warrior VPN</b></p><div class="example-contents"><p>You need to define a zone for the laptop or include it in your
local zone. In this example, we'll assume that you have created a zone
called “<span class="quote">vpn</span>” to represent the remote host.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/zones</code> — System A</p><pre class="programlisting">#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
vpn ipsec
net ipv4
loc ipv4
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><p>In this instance, the mobile system (B) has IP address 134.28.54.2
but that cannot be determined in advance. In the
<code class="filename">/etc/shorewall/tunnels</code> file on system A, the
following entry should be made:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 0.0.0.0/0 vpn
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>the GATEWAY ZONE column contains the name of the zone
corresponding to peer subnetworks. This indicates that the gateway
system itself comprises the peer subnetwork; in other words, the
remote gateway is a standalone system.</p></div><p>The VPN zone is defined using the /etc/shorewall/hosts
file:</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/hosts</code> — System A:</p><pre class="programlisting">#ZONE HOSTS OPTIONS
vpn eth0:0.0.0.0/0
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><p>You will need to configure your “<span class="quote">through the tunnel</span>”
policy as shown under the first example above.</p><p>On the laptop:</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/zones</code> - System B:</p><pre class="programlisting">#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
vpn ipsec
net ipv4
loc ipv4
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre><p><code class="filename">/etc/shorewall/tunnels</code> - System B:</p><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 206.162.148.9 vpn
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre><p><code class="filename">/etc/shorewall/hosts</code> - System B:</p><pre class="programlisting">#ZONE HOSTS OPTIONS
vpn eth0:0.0.0.0/0
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><p>On system A, here are the IPSEC files:</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/racoon/racoon.conf</code> - System A:</p><pre class="programlisting">path certificate "/etc/certs" ;
listen
{
isakmp 206.162.148.9;
}
remote <span class="bold"><strong>anonymous</strong></span>
{
exchange_mode main ;
<span class="bold"><strong>generate_policy on</strong></span> ;
<span class="bold"><strong>passive on</strong></span> ;
certificate_type x509 "GatewayA.pem" "GatewayA_key.pem" ;
verify_cert on;
my_identifier asn1dn ;
peers_identifier asn1dn ;
verify_identifier on ;
lifetime time 24 hour ;
proposal {
encryption_algorithm blowfish ;
hash_algorithm sha1;
authentication_method rsasig ;
dh_group 2 ;
}
}
sainfo <span class="bold"><strong>anonymous</strong></span>
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm blowfish ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}</pre><p><code class="filename">/etc/racoon/setkey.conf</code> - System A:</p><pre class="programlisting">flush;
spdflush;</pre></blockquote></div><p>If system A is running kernel 2.6.10 or later then it must also be
running ipsec-tools (racoon) 0.5rc1 or later.</p><p>On the mobile system (system B), it is not possible to create a
static IPSEC configuration because the IP address of the laptop's
Internet connection isn't static. I have created an 'ipsecvpn' script
and included in the tarball and in the RPM's documentation directory;
this script can be used to start and stop the connection.</p><p>The ipsecvpn script has some variable assignments at the top -- in
the above case, these would be as follows:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#
# External Interface
#
INTERFACE=eth0
#
# Remote IPSEC Gateway
#
GATEWAY=206.162.148.9
#
# Networks behind the remote gateway
#
NETWORKS="192.168.1.0/24"
#
# Directory where X.509 certificates are stored.
#
CERTS=/etc/certs
#
# Certificate to be used for this connection. The cert
# directory must contain:
#
# ${CERT}.pem - the certificate
# ${CERT}_key.pem - the certificates's key
#
CERT=roadwarrior
#
# The setkey binary
#
SETKEY=/usr/sbin/setkey
#
# The racoon binary
#
RACOON=/usr/sbin/racoon</pre></blockquote></div><p>The ipsecvpn script can be installed in /etc/init.d/ but it is
probably best installed in /usr/local/sbin and run manually:</p><div class="blockquote"><blockquote class="blockquote"><p><span class="command"><strong>ipsecvpn start </strong></span># Starts the tunnel</p><p><span class="command"><strong>ipsecvpn stop</strong></span> # Stops the tunnel</p></blockquote></div></div></div><br class="example-break" /><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Although the ipsecvpn script allows you to specify multiple remote
NETWORKS as a space-separated list, SAs are created on the gateway only
during ISAKMP negotiation. So in practice, only the first remote network
accessed will be accessible from the roadwarrior.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="RW-L2TP"></a>Mobile System (Road Warrior) with Layer 2 Tunneling Protocol
(L2TP)</h2></div></div></div><p>This section is based on the previous section. Please make sure that
you read it thoroughly and understand it. The setup described in this
section is more complex because you are including an additional layer of
tunneling. Again, make sure that you have read the previous section and it
is highly recommended to have the IPSEC-only configuration working
first.</p><p>Additionally, this section assumes that you are running IPSEC,
xl2tpd and pppd on the same system that is running shorewall. However,
configuration of these additional services is beyond the scope of this
document.</p><p>Getting layer 2 tunneling to work is an endeavour unto itself.
However, if you succeed it can be very convenient. Reasons why you might
want configure layer 2 tunneling protocol (L2TP):</p><div class="orderedlist"><ol type="1"><li><p>You want to give your road warrior an address that is in the
same segment as the other hosts on your network.</p></li><li><p>Your road warriors are using a legacy operating system (such as
MS Windows or Mac OS X) and you do not want them to have to install
third party software in order to connect to the VPN (both MS Windows
and Mac OS X include VPN clients which natively support L2TP over
IPSEC, but not plain IPSEC).</p></li><li><p>You like a challenge.</p></li></ol></div><p>Since the target for a VPN including L2TP will (almost) never be a
road warrior running Linux, I will not include the client side of the
configuration.</p><p>The first thing that needs to be done is to create a new zone called
“<span class="quote">l2tp</span>” to represent the tunneled layer 2 traffic.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/zones</code> — System A</p><pre class="programlisting">#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
vpn ipsec
l2tp ipv4
net ipv4
loc ipv4
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><p>Since the L2TP will require the use of pppd, you will end up with
one or more ppp interfaces (each representing an individual road warrior
connection) for which you will need to account. This can be done by
modifying the interfaces file. (Modify with additional options as
needed.)</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/interfaces</code>:</p><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect routefilter
loc eth1 192.168.1.255
l2tp ppp+ -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></blockquote></div><p>The next thing that must be done is to adjust the policy so that the
traffic can go where it needs to go.</p><p>First, you need to decide if you want for hosts in your local zone
to be able to connect to your road warriors. You may or may not want to
allow this. For example, one reason you might want to allow this is so
that your support personnel can use ssh, VNC or remote desktop to fix a
problem on the road warrior's laptop.</p><p>Second, you need to decide if you want the road warrior to have
access to hosts on the local network. You generally want to allow this.
For example, if you have DNS servers on your local network that you want
the road warrior to use. Or perhaps the road warrior needs to mount NFS
shares or needs to access intranet sites which are not visible from the
public Internet.</p><p>Finally, you need to decide if you want the road warriors to be able
to access the public Internet. You probably want to do this, unless you
are trying to create a situation where when the road warrior connects to
the VPN, it is no longer possible to send traffic from the road warrior's
machine to the public Internet. Please note that this not really a strong
security measure. The road warrior could trivially modify the routing
table on the remote machine to have only traffic destined for systems on
the VPN local network go through the secure channel. The rest of the
traffic would simply travel over an Ethernet or wireless interface
directly to the public Internet. In fact, this latter situation is
dangerous, as a simple mistake could easily create a situation where the
road warrior's machine is acting as a router between your local network
and the public Internet, which you certainly do not want to happen. In
short, it is best to allow the road warrior to connect to the public
Internet by default.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/policy</code>:</p><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
$FW all ACCEPT
loc net ACCEPT
loc l2tp ACCEPT # Allows local machines to connect to road warriors
l2tp loc ACCEPT # Allows road warriors to connect to local machines
l2tp net ACCEPT # Allows road warriors to connect to the Internet
net all DROP info
# The FOLLOWING POLICY MUST BE LAST
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div><p>The final step is to modify your rules file. There are three
important components. First, you must allow the l2tp traffic to reach the
xl2tpd process running on the firewall machine. Second, you must add rules
to open up ports on the firewall to the road warrior for services which
are running on the firewall. For example, if you are running a webserver
on the firewall that must be accessible to road warriors. The reason for
the second step is that the policy does not by default allow unrestricted
access to the firewall itself. Finally, you should protect an exploit
where an attacker can exploit your LT2P server do to a hole in the way
that L2TP interacts with UDP connection tracking.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/rules</code>:</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(S)
SECTION ESTABLISHED
# Prevent IPSEC bypass by hosts behind a NAT gateway
L2TP/REJECT net $FW
REJECT $FW net udp - 1701
# l2tp over the IPsec VPN
ACCEPT vpn $FW udp 1701
# webserver that can only be accessed internally
HTTP/ACCEPT loc $FW
HTTP/ACCEPT l2tp $FW
HTTPS/ACCEPT loc $FW
HTTPS/ACCEPT l2tp $FW
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Transport"></a>Transport Mode</h2></div></div></div><p>In today's wireless world, it is often the case that individual
hosts in a network need to establish secure connections with the other
hosts in that network. In that case, IPSEC transport mode is an
appropriate solution.</p><div><img src="images/TransportMode.png" /></div><p>Here's an example
using the ipsec-tools package. The files shown are from host
192.168.20.10; the configuration of the other nodes is similar.</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/racoon/racoon.conf</code>:</p><pre class="programlisting">path pre_shared_key "/etc/racoon/psk.txt" ;
remote anonymous
{
exchange_mode main ;
my_identifier address ;
lifetime time 24 hour ;
proposal {
encryption_algorithm blowfish ;
hash_algorithm sha1;
authentication_method pre_shared_key ;
dh_group 2 ;
}
}
sainfo anonymous
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm blowfish ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
</pre><p><code class="filename">/etc/racoon/setkey.conf</code>:</p><pre class="programlisting"># First of all flush the SPD database
spdflush;
# Add some SPD rules
spdadd 192.168.20.10/32 192.168.20.20/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.20/require;
spdadd 192.168.20.20/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.20-192.168.20.10/require;
spdadd 192.168.20.10/32 192.168.20.30/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.30/require;
spdadd 192.168.20.30/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.30-192.168.20.10/require;
spdadd 192.168.20.10/32 192.168.20.40/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.40/require;
spdadd 192.168.20.40/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.40-192.168.20.10/require;
</pre><p><code class="filename">/etc/racoon/psk.txt</code>:</p><pre class="programlisting">192.168.20.20 <key for 192.168.20.10<->192.168.20.20>
192.168.20.30 <key for 192.168.20.10<->192.168.20.30>
192.168.20.40 <key for 192.168.20.10<->192.168.20.40></pre><p>Note that the <span class="bold"><strong>same key</strong></span>must be
used in both directions.</p></blockquote></div><p>Shorewall configuration goes as follows:</p><div class="blockquote"><blockquote class="blockquote"><p><code class="filename">/etc/shorewall/interfaces</code>:</p><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect routefilter,dhcp,tcpflags
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre><p><code class="filename">/etc/shorewall/tunnels</code>:</p><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY
# ZONE
ipsec:noah net 192.168.20.0/24 loc</pre><p><code class="filename">/etc/shorewall/zones</code>:</p><pre class="programlisting">#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
loc ipsec mode=transport
net ipv4</pre><p><code class="filename"><code class="filename">/etc/shorewall/hosts</code></code>:</p><pre class="programlisting">#ZONE HOST(S) OPTIONS
loc eth0:192.168.20.0/24
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE</pre><p>It is worth noting that although <span class="emphasis"><em>loc</em></span> is a
sub-zone of <span class="emphasis"><em>net</em></span>, because <span class="emphasis"><em>loc</em></span>
is an IPSEC-only zone it does not need to be defined before
<span class="emphasis"><em>net</em></span> in
<span class="emphasis"><em>/etc/shorewall/zones</em></span>.</p><p><code class="filename">/etc/shorewall/policy</code>:</p><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
$FW all ACCEPT
loc $FW ACCEPT
net loc NONE
loc net NONE
net all DROP info
# The FOLLOWING POLICY MUST BE LAST
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre><p>Since there are no cases where net<->loc traffic should
occur, NONE policies are used.</p></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ipcomp"></a>IPCOMP</h2></div></div></div><p>If your IPSEC tunnel or transport mode connection fails to work with
Shorewall started and you see log messages like the following when you try
to use the connection, the problem is that ip compression is being
used.</p><pre class="programlisting">Feb 18 23:43:52 vpngw kernel: Shorewall:<span class="bold"><strong>vpn2fw</strong></span>:REJECT:IN=eth2 OUT= MAC=00:e0:81:32:b3:5e:00:18:de:12:e5:15:08:00
SRC=172.29.59.58 DST=172.29.59.254 LEN=85 TOS=0x00 PREC=0x00 TTL=64 ID=25600 DF <span class="bold"><strong>PROTO=4</strong></span></pre><p>The solution is to
add an IPCOMP tunnel to /etc/shorewall/tunnels as follows:</p><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY
# ZONE
ipip <span class="bold"><strong>vpn</strong></span> 0.0.0.0/0</pre><p>The
above assumes that the name of your IPSEC vpn zone is
<span class="emphasis"><em>vpn</em></span>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="XP"></a>IPSEC and <span class="trademark">Windows</span>™ XP</h2></div></div></div><p>I have successfully configured my work laptop to use IPSEC with
X.509 certificates for wireless IP communication when it is undocked at
home. I looked at dozens of sites and the one I found most helpful was
<a class="ulink" href="http://ipsec.math.ucla.edu/services/ipsec-windows.html" target="_self">http://ipsec.math.ucla.edu/services/ipsec-windows.html</a>.
The instructions on that site are directed to students at UCLA but they
worked fine for me (once I followed them very carefully).</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>The instructions found on the UCLA site are complex and do not
include any information on the generation of X.509 certificates. There
are lots of sites however that can tell you how to generate
certificates, including <a class="ulink" href="http://www.ipsec-howto.org/" target="_self">http://www.ipsec-howto.org/</a>.</p><p>One piece of information that may not be so easy to find is "How
do I generate a PKCS#12 certificate to import into Windows?". Here's the
openssl command that I used:</p><pre class="programlisting"><span class="command"><strong>openssl pkcs12 -export -in eastepnc6000.pem -inkey eastepnc6000_key.pem -out eastepnc6000.pfx -name "IPSEC Cert for Home Wireless"</strong></span> </pre><p>I was prompted for a password to associate with the certificate.
This password is entered on the Windows system during import.</p><p>In the above command:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="filename">eastepnc6000.pem</code> was the laptop's
certificate in PEM format.</p></li><li><p><code class="filename">eastepnc6000_key.pem</code> was the laptop's
private key (actually, it's the original signing request which
includes the private key).</p></li><li><p><code class="filename">eastepnc6000.pfx</code> is the PKCS#12 output
file.</p></li><li><p>"IPSEC Cert for Home Wireless" is the friendly name for the
certificate.</p></li></ul></div><p>I started to write an article about how to do this, complete with
graphics captured from my laptop. I gave up. I had captured 12 images
and hadn't really started yet. The Windows interface for configuring
IPSEC is the worst GUI that I have ever used. What can be displayed on
one split Emacs screen (racoon.conf plus setkey.conf) takes 20+
different dialog boxes on Windows XP!!!</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="More"></a>Source of Additional Samples</h2></div></div></div><p>Be sure to check out the <code class="filename">src/racoon/samples</code> subdirectory in the
ipsec-tools source tree. It has a wide variety of sample racoon
configuration files.</p></div></div></body></html>
