forked from extern/shorewall_code
1048 lines
42 KiB
XML
1048 lines
42 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<article id="IPSEC">
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>IPsec</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
|
|
<author>
|
|
<firstname>Roberto</firstname>
|
|
|
|
<surname>Sanchez</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2004</year>
|
|
|
|
<year>2005</year>
|
|
|
|
<year>2006</year>
|
|
|
|
<year>2009</year>
|
|
|
|
<year>2016</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<copyright>
|
|
<year>2007</year>
|
|
|
|
<holder>Roberto C. Sanchez</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>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
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<caution>
|
|
<para><emphasis role="bold">This article applies to Shorewall 4.3 and
|
|
later. If you are running a version of Shorewall earlier than Shorewall
|
|
4.3.5 then please see the documentation for that
|
|
release.</emphasis></para>
|
|
</caution>
|
|
|
|
<important>
|
|
<para><emphasis role="bold">Shorewall does not configure IPsec for
|
|
you</emphasis> -- it rather configures netfilter to accommodate your IPsec
|
|
configuration.</para>
|
|
</important>
|
|
|
|
<important>
|
|
<para>The information in this article is only applicable if you plan to
|
|
have IPsec end-points on the same system where Shorewall is used.</para>
|
|
</important>
|
|
|
|
<important>
|
|
<para>While this <emphasis role="bold">article shows configuration of
|
|
IPsec using ipsec-tools</emphasis>, <emphasis role="bold">Shorewall
|
|
configuration is exactly the same when using OpenSwan</emphasis> <emphasis
|
|
role="bold">or any of the other Swan derivatives</emphasis>.</para>
|
|
</important>
|
|
|
|
<warning>
|
|
<para>When running a Linux kernel prior to 2.6.20, the Netfilter+IPsec and
|
|
policy match support are broken when used with a bridge device. The
|
|
problem was 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 <ulink url="bridge-Shorewall-perl.html">"<emphasis>Shorewall-perl and
|
|
Bridged Firewalls</emphasis>"</ulink> article.</para>
|
|
</warning>
|
|
|
|
<section id="Overview">
|
|
<title>Shorwall and Kernel 2.6 IPsec</title>
|
|
|
|
<para>This is <emphasis role="bold">not</emphasis> a HOWTO for Kernel 2.6
|
|
IPsec -- for that, please see <ulink
|
|
url="http://www.ipsec-howto.org/">http://www.ipsec-howto.org/</ulink>.</para>
|
|
|
|
<para>The 2.6 Linux Kernel introduced new facilities for defining
|
|
encrypted communication between hosts in a network. The network
|
|
administrator defines a set of <firstterm>Security Policies</firstterm>
|
|
which are stored in the kernel as a <firstterm>Security Policy
|
|
Database</firstterm> (SPD). Security policies determine which traffic is
|
|
subject to encryption. <firstterm>Security Associations</firstterm> 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
|
|
<command>setkey</command>(8) but most often, they are created by a
|
|
cooperative process involving the ISAKMP protocol and daemons such
|
|
as<command> racoon</command> or <command>isakmpd</command>. Incoming
|
|
traffic is verified against the SPD to ensure that no unencrypted traffic
|
|
is accepted in violation of the administrator's policies.</para>
|
|
|
|
<para>There are three ways in which IPsec traffic can interact with
|
|
Shorewall policies and rules:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Traffic that is encrypted on the firewall system. The traffic
|
|
passes through Netfilter twice -- first as unencrypted then
|
|
encrypted.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Traffic that is decrypted on the firewall system. The traffic
|
|
passes through Netfilter twice -- first as encrypted then as
|
|
unencrypted.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Encrypted traffic that is passed through the firewall system.
|
|
The traffic passes through Netfilter once.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>In cases 1 and 2, the encrypted traffic is handled by entries in
|
|
<filename>/etc/shorewall/tunnels</filename> (don't be mislead by the name
|
|
of the file -- <emphasis>transport mode</emphasis> encrypted traffic is
|
|
also handled by entries in that file). The unencrypted traffic is handled
|
|
by normal rules and policies.</para>
|
|
|
|
<para>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 <filename class="devicefile">ipsecN</filename> (e.g.
|
|
<filename class="devicefile">ipsec0</filename>). Outgoing unencrypted
|
|
traffic (case 1.) was sent through an <filename
|
|
class="devicefile">ipsecN</filename> device while incoming unencrypted
|
|
traffic (case 2) arrived from an <filename
|
|
class="devicefile">ipsecN</filename> 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.</para>
|
|
|
|
<para>Shorewall provides support for policy matching in three ways:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>In <filename>/etc/shorewall/masq</filename>
|
|
(<filename>/etc/shorewall/snat</filename> when running Shorewall
|
|
5.0.14 or later), 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 IPSEC column in that
|
|
file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The<filename> </filename><ulink
|
|
url="manpages/shorewall-zones.html"><filename>/etc/shorewall/zones</filename></ulink>
|
|
file allows you to associate zones with traffic that will be encrypted
|
|
or that has been decrypted.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A new option (<emphasis role="bold">ipsec</emphasis>) has been
|
|
provided for entries in <filename>/etc/shorewall/hosts</filename>.
|
|
When an entry has this option specified, traffic to/from the hosts
|
|
described in the entry is assumed to be encrypted.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>In summary, Shorewall provides the facilities to replace the use of
|
|
IPsec pseudo-interfaces in zone and MASQUERADE/SNAT definition.</para>
|
|
|
|
<para>There are two cases to consider:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Encrypted communication is used to/from all hosts in a
|
|
zone.</para>
|
|
|
|
<para>The value <emphasis role="bold">ipsec</emphasis> is placed in
|
|
the TYPE column of the <filename>/etc/shorewall/zones</filename> entry
|
|
for the zone.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>By default, encrypted communication is not used to communicate
|
|
with the hosts in a zone.</para>
|
|
|
|
<para>The value <emphasis role="bold">ipv4</emphasis> is placed in the
|
|
TYPE column of the <filename>/etc/shorewall/zones</filename> entry for
|
|
the zone and the new <emphasis role="bold">ipsec</emphasis> option is
|
|
specified in <filename>/etc/shorewall/hosts</filename> for any hosts
|
|
requiring secure communication.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<note>
|
|
<para>For simple zones such as are shown in the following examples, the
|
|
two techniques are equivalent and are used interchangeably.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>It is redundant to have <emphasis role="bold">ipsec</emphasis> in
|
|
the TYPE column of the <filename>/etc/shorewall/zones</filename> entry
|
|
for a zone and to also have the <emphasis role="bold">ipsec</emphasis>
|
|
option in <filename>/etc/shorewall/hosts</filename> entries for that
|
|
zone.</para>
|
|
</note>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>This article assumes the use of ipsec-tools (<ulink
|
|
url="http://ipsec-tools.sourceforge.net">http://ipsec-tools.sourceforge.net</ulink>).
|
|
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.</para>
|
|
|
|
<para>For more information on IPsec, Kernel 2.6 and Shorewall see <ulink
|
|
url="LinuxFest.pdf">my presentation on the subject given at LinuxFest NW
|
|
2005</ulink>. 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.</para>
|
|
</section>
|
|
|
|
<section id="GwFw">
|
|
<title>IPsec Gateway on the Firewall System</title>
|
|
|
|
<para>Suppose that we have the following situation:</para>
|
|
|
|
<graphic fileref="images/TwoNets1.png"/>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>To make this work, we need to do two things:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Open the firewall so that the IPsec tunnel can be established
|
|
(allow the ESP protocol and UDP Port 500).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Allow traffic through the tunnel.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Opening the firewall for the IPsec tunnel is accomplished by adding
|
|
an entry to the <filename>/etc/shorewall/tunnels</filename> file.</para>
|
|
|
|
<para>In <filename>/etc/shorewall/tunnels</filename> on system A, we need
|
|
the following</para>
|
|
|
|
<blockquote>
|
|
<para><filename><filename>/etc/shorewall/tunnels</filename></filename> —
|
|
System A:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY_ZONE
|
|
ipsec net 134.28.54.2</programlisting>
|
|
|
|
<para><filename><filename>/etc/shorewall/tunnels</filename></filename> —
|
|
System B:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY_ZONE
|
|
ipsec net 206.162.148.9</programlisting>
|
|
</blockquote>
|
|
|
|
<note>
|
|
<para>If either of the endpoints is behind a NAT gateway then the
|
|
tunnels file entry on the <emphasis role="bold">other</emphasis>
|
|
endpoint should specify a tunnel type of ipsecnat rather than ipsec and
|
|
the GATEWAY address should specify the external address of the NAT
|
|
gateway.</para>
|
|
</note>
|
|
|
|
<para>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 <quote>vpn</quote> to represent the remote subnet.</para>
|
|
|
|
<blockquote>
|
|
<para><filename><filename>/etc/shorewall/zones</filename></filename> —
|
|
Systems A and B:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
|
|
net ipv4
|
|
<emphasis role="bold">vpn ipv4</emphasis></programlisting>
|
|
</blockquote>
|
|
|
|
<para>Remember the assumption that both systems A and B have eth0 as their
|
|
Internet interface.</para>
|
|
|
|
<para>You must define the vpn zone using the
|
|
<filename>/etc/shorewall/hosts</filename> 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.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/hosts</filename> — System A</para>
|
|
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn eth0:10.0.0.0/8,134.28.54.2 <emphasis role="bold"> ipsec</emphasis></programlisting>
|
|
|
|
<para><filename>/etc/shorewall/hosts</filename> — System B</para>
|
|
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn eth0:192.168.1.0/24,206.162.148.9 <emphasis role="bold">ipsec</emphasis></programlisting>
|
|
</blockquote>
|
|
|
|
<para>If you want to keep things simple, you can simply not restrict the
|
|
set of addresses in the ipsec zones:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn eth0:0.0.0.0/o <emphasis role="bold">ipsec</emphasis></programlisting>
|
|
</blockquote>
|
|
|
|
<para>Assuming that you want to give each local network free access to the
|
|
remote network and vice versa, you would need the following
|
|
<filename>/etc/shorewall/policy</filename> entries on each system:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#SOURCE DEST POLICY LEVEL BURST:LIMIT
|
|
loc vpn ACCEPT
|
|
vpn loc ACCEPT</programlisting>
|
|
</blockquote>
|
|
|
|
<para>If you need access from each firewall to hosts in the other network,
|
|
then you could add:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#SOURCE DEST POLICY LEVEL BURST:LIMIT
|
|
$FW vpn ACCEPT</programlisting>
|
|
</blockquote>
|
|
|
|
<para>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:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#ACTION SOURCE DEST PROTO POLICY
|
|
ACCEPT vpn:134.28.54.2 $FW</programlisting>
|
|
</blockquote>
|
|
|
|
<para>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).</para>
|
|
|
|
<para>Once you have these entries in place, restart Shorewall (type
|
|
shorewall restart); you are now ready to configure IPsec.</para>
|
|
|
|
<para>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
|
|
<filename>/etc/racoon/setkey.conf</filename>. For example, on gateway
|
|
A:</para>
|
|
|
|
<blockquote>
|
|
<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;</programlisting>
|
|
</blockquote>
|
|
|
|
<para>The <filename>setkey.conf</filename> file on gateway B would be
|
|
similar.</para>
|
|
|
|
<para>A sample <filename>/etc/racoon/racoon.conf</filename> file using
|
|
X.509 certificates might look like:</para>
|
|
|
|
<blockquote>
|
|
<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 ;
|
|
}</programlisting>
|
|
|
|
<warning>
|
|
<para>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
|
|
<filename>/etc/shorewall/zones</filename> file. For example, if hosts
|
|
in the <emphasis role="bold">vpn</emphasis> zone access the Internet
|
|
through an ESP tunnel then the following entry would be
|
|
appropriate:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
|
|
vpn ipsec mode=tunnel <emphasis role="bold">mss=1400</emphasis></programlisting>
|
|
|
|
<para>You should also set FASTACCEPT=No in shorewall.conf to ensure
|
|
that both the SYN and SYN,ACK packets have their MSS field
|
|
adjusted.</para>
|
|
|
|
<para>Note that CLAMPMSS=Yes in <filename>shorewall.conf</filename>
|
|
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.</para>
|
|
</warning>
|
|
</blockquote>
|
|
</section>
|
|
|
|
<section>
|
|
<title>IPCOMP and IPSEC</title>
|
|
|
|
<para>IPSEC can be configured to perform data compression. This is
|
|
accomplished by compressing the original IP packet, then encapsulating it
|
|
in an ipcomp (protocol 108) packet. That packet is then encrypted and
|
|
encapsulated within an ESP packet. Because of the extra protocol header
|
|
required for compression, short IP packets (such as default ping packets)
|
|
are not compressed. The Linux IP stack handles these uncompressed packets
|
|
by creating an IPIP (protocol 4) SA. As a consequence, IPIP packets from
|
|
the remote gateway must be handled in Shorewall. The easiest way to
|
|
accomplish this is to add an ACCEPT rule for protocol 4 from the IPSEC vpn
|
|
zone to the $FW zone:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT ...
|
|
ACCEPT vpn $FW 4</programlisting>
|
|
</blockquote>
|
|
|
|
<para>Note that the source IP address is these IPIP packets is that of the
|
|
remote peer, so the definition of the ipsec zone in <ulink
|
|
url="manpages/shorewall-hosts.html">shorewall-hosts</ulink>(5) must
|
|
include the peer.</para>
|
|
|
|
<para>Finally, when IPCOMP is used, it is recommended that the OPTIONS
|
|
column of the ipsec zone's entry in <ulink
|
|
url="manpages/shorewall-zones.html">shorewall-zones</ulink>(5) be left
|
|
empty.</para>
|
|
</section>
|
|
|
|
<section id="RoadWarrior">
|
|
<title>Mobile System (Road Warrior)</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<graphic fileref="images/Mobile.png"/>
|
|
|
|
<example id="roadWarrior">
|
|
<title>Road Warrior VPN</title>
|
|
|
|
<para>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 <quote>vpn</quote> to represent the remote host.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/zones</filename> — System A</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
|
|
net ipv4
|
|
<emphasis role="bold">vpn ipsec</emphasis>
|
|
loc ipv4
|
|
</programlisting>
|
|
</blockquote>
|
|
|
|
<para>In this instance, the mobile system (B) has IP address 134.28.54.2
|
|
but that cannot be determined in advance. In the
|
|
<filename>/etc/shorewall/tunnels</filename> file on system A, the
|
|
following entry should be made:<blockquote>
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY_ZONE
|
|
ipsec net 0.0.0.0/0 vpn
|
|
</programlisting>
|
|
</blockquote></para>
|
|
|
|
<para><note>
|
|
<para>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.</para>
|
|
</note></para>
|
|
|
|
<para>The VPN zone is defined using the /etc/shorewall/hosts
|
|
file:</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/hosts</filename> — System A:</para>
|
|
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn eth0:0.0.0.0/0</programlisting>
|
|
</blockquote>
|
|
|
|
<para>You will need to configure your <quote>through the tunnel</quote>
|
|
policy as shown under the first example above.</para>
|
|
|
|
<para>On the laptop:</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/zones</filename> - System B:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
|
|
vpn ipsec
|
|
net ipv4
|
|
loc ipv4</programlisting>
|
|
|
|
<para><filename>/etc/shorewall/tunnels</filename> - System B:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY_ZONE
|
|
ipsec net 206.162.148.9 vpn</programlisting>
|
|
|
|
<para><filename>/etc/shorewall/hosts</filename> - System B:</para>
|
|
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn eth0:0.0.0.0/0</programlisting>
|
|
</blockquote>
|
|
|
|
<para>On system A, here are the IPsec files:</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/racoon/racoon.conf</filename> - System A:</para>
|
|
|
|
<programlisting>path certificate "/etc/certs" ;
|
|
|
|
listen
|
|
{
|
|
isakmp 206.162.148.9;
|
|
}
|
|
|
|
remote <emphasis role="bold">anonymous</emphasis>
|
|
{
|
|
exchange_mode main ;
|
|
<emphasis role="bold">generate_policy on</emphasis> ;
|
|
<emphasis role="bold">passive on</emphasis> ;
|
|
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 <emphasis role="bold">anonymous</emphasis>
|
|
{
|
|
pfs_group 2;
|
|
lifetime time 12 hour ;
|
|
encryption_algorithm blowfish ;
|
|
authentication_algorithm hmac_sha1, hmac_md5 ;
|
|
compression_algorithm deflate ;
|
|
}</programlisting>
|
|
|
|
<para><filename>/etc/racoon/setkey.conf</filename> - System A:</para>
|
|
|
|
<programlisting>flush;
|
|
spdflush;</programlisting>
|
|
</blockquote>
|
|
|
|
<para>If system A is running kernel 2.6.10 or later then it must also be
|
|
running ipsec-tools (racoon) 0.5rc1 or later.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>The ipsecvpn script has some variable assignments at the top -- in
|
|
the above case, these would be as follows:</para>
|
|
|
|
<blockquote>
|
|
<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</programlisting>
|
|
</blockquote>
|
|
|
|
<para>The ipsecvpn script can be installed in /etc/init.d/ but it is
|
|
probably best installed in /usr/local/sbin and run manually:</para>
|
|
|
|
<blockquote>
|
|
<para><command>ipsecvpn start </command># Starts the tunnel</para>
|
|
|
|
<para><command>ipsecvpn stop</command> # Stops the tunnel</para>
|
|
</blockquote>
|
|
</example>
|
|
|
|
<warning>
|
|
<para>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.</para>
|
|
</warning>
|
|
</section>
|
|
|
|
<section id="RW-L2TP">
|
|
<title>Mobile System (Road Warrior) with Layer 2 Tunneling Protocol
|
|
(L2TP)</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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):</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>You want to give your road warrior an address that is in the
|
|
same segment as the other hosts on your network.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You like a challenge.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>The first thing that needs to be done is to create a new zone called
|
|
<quote>l2tp</quote> to represent the tunneled layer 2 traffic.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/zones</filename> — System A</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
|
|
et ipv4
|
|
vpn ipsec
|
|
<emphasis role="bold">l2tp ipv4</emphasis>
|
|
loc ipv4</programlisting>
|
|
</blockquote>
|
|
|
|
<para>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.)</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/interfaces</filename>:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
net eth0 detect routefilter
|
|
loc eth1 192.168.1.255
|
|
l2tp ppp+ -</programlisting>
|
|
</blockquote>
|
|
|
|
<para>The next thing that must be done is to adjust the policy so that the
|
|
traffic can go where it needs to go.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/policy</filename>:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOGLEVEL LIMIT
|
|
$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</programlisting>
|
|
</blockquote>
|
|
|
|
<para>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 due to a hole in the way
|
|
that L2TP interacts with UDP connection tracking.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/rules</filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT
|
|
?SECTION ESTABLISHED
|
|
# Prevent IPsec bypass by hosts behind a NAT gateway
|
|
L2TP(REJECT) net $FW
|
|
REJECT $FW net udp - 1701
|
|
?SECTION NEW
|
|
# 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</programlisting>
|
|
</blockquote>
|
|
</section>
|
|
|
|
<section id="Transport">
|
|
<title>Transport Mode</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<para><graphic fileref="images/TransportMode.png"/>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.</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/racoon/racoon.conf</filename>:</para>
|
|
|
|
<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 ;
|
|
}
|
|
</programlisting>
|
|
|
|
<para><filename>/etc/racoon/setkey.conf</filename>:</para>
|
|
|
|
<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;
|
|
</programlisting>
|
|
|
|
<para><filename>/etc/racoon/psk.txt</filename>:</para>
|
|
|
|
<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></programlisting>
|
|
|
|
<para>Note that the <emphasis role="bold">same key</emphasis>must be
|
|
used in both directions.</para>
|
|
</blockquote>
|
|
|
|
<para>Shorewall configuration goes as follows:</para>
|
|
|
|
<blockquote>
|
|
<para><filename>/etc/shorewall/interfaces</filename>:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE OPTIONS
|
|
net eth0 routefilter,dhcp,tcpflags</programlisting>
|
|
|
|
<para><filename>/etc/shorewall/tunnels</filename>:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY
|
|
# ZONE
|
|
ipsec net 192.168.20.0/24 loc</programlisting>
|
|
|
|
<para><filename>/etc/shorewall/zones</filename>:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS IN OUT
|
|
# OPTIONS OPTIONS
|
|
loc ipsec mode=transport
|
|
net ipv4</programlisting>
|
|
|
|
<para><filename><filename>/etc/shorewall/hosts</filename></filename>:</para>
|
|
|
|
<programlisting>#ZONE HOST(S) OPTIONS
|
|
loc eth0:192.168.20.0/24</programlisting>
|
|
|
|
<para>It is worth noting that although <emphasis>loc</emphasis> is a
|
|
sub-zone of <emphasis>net</emphasis>, because <emphasis>loc</emphasis>
|
|
is an IPsec-only zone it does not need to be defined before
|
|
<emphasis>net</emphasis> in
|
|
<emphasis>/etc/shorewall/zones</emphasis>.</para>
|
|
|
|
<para><filename>/etc/shorewall/policy</filename>:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOGLEVEL LIMIT
|
|
$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</programlisting>
|
|
|
|
<para>Since there are no cases where net<->loc traffic should
|
|
occur, NONE policies are used.</para>
|
|
</blockquote>
|
|
</section>
|
|
|
|
<section id="ipcomp">
|
|
<title>IPCOMP</title>
|
|
|
|
<para>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.<programlisting>Feb 18 23:43:52 vpngw kernel: Shorewall:<emphasis
|
|
role="bold">vpn2fw</emphasis>: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 <emphasis
|
|
role="bold">PROTO=4</emphasis></programlisting>The solution is to
|
|
add an IPCOMP tunnel to /etc/shorewall/tunnels as follows:<programlisting>#TYPE ZONE GATEWAY GATEWAY
|
|
# ZONE
|
|
ipip <emphasis role="bold">vpn</emphasis> 0.0.0.0/0</programlisting>The
|
|
above assumes that the name of your IPsec vpn zone is
|
|
<emphasis>vpn</emphasis>.</para>
|
|
</section>
|
|
|
|
<section id="XP">
|
|
<title>IPsec and <trademark>Windows</trademark> XP</title>
|
|
|
|
<para>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
|
|
<ulink
|
|
url="http://ipsec.math.ucla.edu/services/ipsec-windows.html">http://ipsec.math.ucla.edu/services/ipsec-windows.html</ulink>.
|
|
The instructions on that site are directed to students at UCLA but they
|
|
worked fine for me (once I followed them very carefully).</para>
|
|
|
|
<warning>
|
|
<para>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 <ulink
|
|
url="http://www.ipsec-howto.org/">http://www.ipsec-howto.org/</ulink>.</para>
|
|
|
|
<para>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:</para>
|
|
|
|
<programlisting><command>openssl pkcs12 -export -in eastepnc6000.pem -inkey eastepnc6000_key.pem -out eastepnc6000.pfx -name "IPsec Cert for Home Wireless"</command> </programlisting>
|
|
|
|
<para>I was prompted for a password to associate with the certificate.
|
|
This password is entered on the Windows system during import.</para>
|
|
|
|
<para>In the above command:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><filename>eastepnc6000.pem</filename> was the laptop's
|
|
certificate in PEM format.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>eastepnc6000_key.pem</filename> was the laptop's
|
|
private key (actually, it's the original signing request which
|
|
includes the private key).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>eastepnc6000.pfx</filename> is the PKCS#12 output
|
|
file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>"IPsec Cert for Home Wireless" is the friendly name for the
|
|
certificate.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>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!!!</para>
|
|
</warning>
|
|
</section>
|
|
|
|
<section id="More">
|
|
<title>Source of Additional Samples</title>
|
|
|
|
<para>Be sure to check out the <filename
|
|
class="directory">src/racoon/samples</filename> subdirectory in the
|
|
ipsec-tools source tree. It has a wide variety of sample racoon
|
|
configuration files.</para>
|
|
</section>
|
|
</article>
|