mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-14 11:44:01 +01:00
fe5978edd7
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6776 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
437 lines
16 KiB
XML
437 lines
16 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<article id="IPSEC">
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>IPSEC Tunnels</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2001-2005</year>
|
|
|
|
<holder>Thomas M. Eastep</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 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.</emphasis></para>
|
|
</caution>
|
|
|
|
<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>
|
|
|
|
<warning>
|
|
<para>This documentation is incomplete regarding using IPSEC and the 2.6
|
|
Kernel. Netfilter currently lacks full support for the 2.6 kernel's
|
|
implementation of IPSEC. Until that implementation is complete, only a
|
|
simple network-network tunnel is described for 2.6.</para>
|
|
|
|
<para>UPDATE: Some distributions such as <trademark>SUSE</trademark> are
|
|
now shipping Kernels and iptables with the IPSEC-Netfilter patches and
|
|
policy match support. Check <ulink url="IPSEC-2.6.html">this
|
|
article</ulink> for information concerning this support and
|
|
Shorewall.</para>
|
|
</warning>
|
|
|
|
<section id="Prelim">
|
|
<title>Preliminary Reading</title>
|
|
|
|
<para>I recommend reading the <ulink url="VPNBasics.html">VPN
|
|
Basics</ulink> article if you plan to implement any type of VPN.</para>
|
|
</section>
|
|
|
|
<section id="Swans">
|
|
<title>Configuring FreeS/Wan and Derivatives Such as OpenS/Wan</title>
|
|
|
|
<para>There is an excellent guide to configuring IPSEC tunnels at <ulink
|
|
url="http://jixen.tripod.com/">http://jixen.tripod.com/</ulink>. I highly
|
|
recommend that you consult that site for information about configuring
|
|
FreeS/Wan.</para>
|
|
|
|
<important>
|
|
<para>The documentation below assumes that you have disabled
|
|
opportunistic encryption feature in FreeS/Wan 2.0 using the following
|
|
additional entries in ipsec.conf:</para>
|
|
|
|
<programlisting>conn block
|
|
auto=ignore
|
|
|
|
conn private
|
|
auto=ignore
|
|
|
|
conn private-or-clear
|
|
auto=ignore
|
|
|
|
conn clear-or-private
|
|
auto=ignore
|
|
|
|
conn clear
|
|
auto=ignore
|
|
|
|
conn packetdefault
|
|
auto=ignore</programlisting>
|
|
|
|
<para>For further information see <ulink
|
|
url="http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html">http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html</ulink>.</para>
|
|
</important>
|
|
</section>
|
|
|
|
<section id="GwFw">
|
|
<title>IPSec Gateway on the Firewall System</title>
|
|
|
|
<para>Suppose that we have the following sutuation:</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 and AH protocols 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 /etc/shorewall/tunnels file.</para>
|
|
|
|
<para>In /etc/shorewall/tunnels on system A, we need the following</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
ipsec net 134.28.54.2</programlisting>
|
|
|
|
<para>In /etc/shorewall/tunnels on system B, we would have:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
ipsec net 206.161.148.9</programlisting>
|
|
|
|
<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. Note that
|
|
you should define the vpn zone before the net zone.</para>
|
|
|
|
<para>/etc/shorewall/zones (both systems):</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS
|
|
vpn ipv4
|
|
net ipv4</programlisting>
|
|
|
|
<para><emphasis role="bold">If you are running kernel
|
|
2.4:</emphasis><blockquote>
|
|
<para>At both systems, ipsec0 would be included in
|
|
/etc/shorewall/interfaces as a <quote>vpn</quote> interface:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
vpn ipsec0</programlisting>
|
|
</blockquote></para>
|
|
|
|
<para><emphasis role="bold">If you are running kernel
|
|
2.6:</emphasis></para>
|
|
|
|
<blockquote>
|
|
<para><emphasis role="bold">It is essential that the
|
|
<emphasis>vpn</emphasis> zone be declared before the
|
|
<emphasis>net</emphasis> zone in
|
|
<filename>/etc/shorewall/zones</filename>.</emphasis></para>
|
|
|
|
<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 /etc/shorewall/hosts
|
|
file.</para>
|
|
|
|
<para>/etc/shorewall/hosts - System A</para>
|
|
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn eth0:10.0.0.0/8</programlisting>
|
|
|
|
<para>/etc/shorewall/hots - System B</para>
|
|
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn eth0:192.168.1.0/24</programlisting>
|
|
|
|
<para>In addition, <emphasis role="bold">if you are using Masquerading
|
|
or SNAT</emphasis> on your firewalls, you need to elmiinate the remote
|
|
network from Masquerade/SNAT. These entries <emphasis
|
|
role="bold">replace</emphasis> your current masquerade/SNAT entries for
|
|
the local networks.</para>
|
|
|
|
<para>/etc/shorewall/masq - System A</para>
|
|
|
|
<programlisting>#INTERFACE SUBNET ADDRESS
|
|
eth0:!10.0.0.0/8 192.168.1.0/24</programlisting>
|
|
|
|
<para>/etc/shorewall/masq - System B</para>
|
|
|
|
<programlisting>#INTERFACE SUBNET ADDRESS
|
|
eth0:!192.168.1.0/24 10.0.0.0/8</programlisting>
|
|
</blockquote>
|
|
|
|
<para>You will need to allow traffic between the <quote>vpn</quote> zone
|
|
and the <quote>loc</quote> zone -- if you simply want to admit all traffic
|
|
in both directions, you can use the policy file:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOG LEVEL
|
|
loc vpn ACCEPT
|
|
vpn loc ACCEPT</programlisting>
|
|
|
|
<para></para>
|
|
|
|
<para>Once you have these entries in place, restart Shorewall (type
|
|
shorewall restart); you are now ready to configure the tunnel in <ulink
|
|
url="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="Hub">
|
|
<title>VPN Hub using Kernel 2.4</title>
|
|
|
|
<para>Shorewall can be used in a VPN Hub environment where multiple remote
|
|
networks are connected to a gateway running Shorewall. This environment is
|
|
shown in this diatram.</para>
|
|
|
|
<graphic fileref="images/ThreeNets.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/16 and 10.1.0.0/16 networks and
|
|
we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to
|
|
communicate.</para>
|
|
|
|
<para>To make this work, we need to do several things:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Open the firewall so that two IPSEC tunnels can be established
|
|
(allow the ESP and AH protocols and UDP Port 500).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Allow traffic through the tunnels two/from the local zone
|
|
(192.168.1.0/24).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Deny traffic through the tunnels between the two remote
|
|
networks.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Opening the firewall for the IPSEC tunnels is accomplished by adding
|
|
two entries to the /etc/shorewall/tunnels file.</para>
|
|
|
|
<para>In /etc/shorewall/tunnels on system A, we need the following</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
ipsec net 134.28.54.2
|
|
ipsec net 130.252.100.14</programlisting>
|
|
|
|
<para>In /etc/shorewall/tunnels on systems B and C, we would have:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
ipsec net 206.161.148.9</programlisting>
|
|
|
|
<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 <emphasis>ipsecnat</emphasis>
|
|
rather than ipsec and the GATEWAY address should specify the external
|
|
address of the NAT gateway.</para>
|
|
</note>
|
|
|
|
<para>On each system, we will create a zone to represent the remote
|
|
networks. On System A:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS
|
|
vpn1 ipv4
|
|
vp2 ipv4</programlisting>
|
|
|
|
<para>On systems B and C:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS
|
|
vpn ipv4</programlisting>
|
|
|
|
<para>At system A, ipsec0 represents two zones so we have the following in
|
|
/etc/shorewall/interfaces:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
- ipsec0</programlisting>
|
|
|
|
<para>The /etc/shorewall/hosts file on system A defines the two VPN
|
|
zones:</para>
|
|
|
|
<programlisting>#ZONE HOSTS OPTIONS
|
|
vpn1 ipsec0:10.0.0.0/16
|
|
vpn2 ipsec0:10.1.0.0/16</programlisting>
|
|
|
|
<para>At systems B and C, ipsec0 represents a single zone so we have the
|
|
following in /etc/shorewall/interfaces:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
vpn ipsec0</programlisting>
|
|
|
|
<para>On systems A, you will need to allow traffic between the
|
|
<quote>vpn1</quote> zone and the <quote>loc</quote> zone as well as
|
|
between <quote>vpn2</quote> and the <quote>loc</quote> zone -- if you
|
|
simply want to admit all traffic in both directions, you can use the
|
|
following policy file entries on all three gateways:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOG LEVEL
|
|
loc vpn1 ACCEPT
|
|
vpn1 loc ACCEPT
|
|
loc vpn2 ACCEPT
|
|
vpn2 loc ACCEPT</programlisting>
|
|
|
|
<para>On systems B and C, you will need to allow traffic between the
|
|
<quote>vpn</quote> zone and the <quote>loc</quote> zone -- if you simply
|
|
want to admit all traffic in both directions, you can use the following
|
|
policy file entries on all three gateways:</para>
|
|
|
|
<para>/etc/shorewall/policy -- Systems B & C</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOG LEVEL
|
|
loc vpn ACCEPT
|
|
vpn loc ACCEPT</programlisting>
|
|
|
|
<para>Once you have the Shorewall entries added, restart Shorewall on each
|
|
gateway (type shorewall restart); you are now ready to configure the
|
|
tunnels in <ulink
|
|
url="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</ulink>.</para>
|
|
|
|
<note>
|
|
<para>to allow traffic between the networks attached to systems B and C,
|
|
it is necessary to simply add two additional entries to the
|
|
/etc/shorewall/policy file on system A.</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOG LEVEL
|
|
vpn1 vpn2 ACCEPT
|
|
vpn2 vpn1 ACCEPT</programlisting>
|
|
</note>
|
|
|
|
<note>
|
|
<para>If you find traffic being rejected/dropped in the OUTPUT chain,
|
|
place the names of the remote VPN zones as a comma-separated list in the
|
|
GATEWAY ZONE column of the /etc/shorewall/tunnels file entry.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="RoadWarrior">
|
|
<title>Mobile System (Road Warrior) Using Kernel 2.4</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>
|
|
|
|
<para>/etc/shorewall/zones - System A</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS
|
|
vpn ipv4</programlisting>
|
|
|
|
<para>In this instance, the mobile system (B) has IP address 134.28.54.2
|
|
but that cannot be determined in advance. In the /etc/shorewall/tunnels
|
|
file on system A, the following entry should be made:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
ipsec net 0.0.0.0/0</programlisting>
|
|
|
|
<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>You will need to configure /etc/shorewall/interfaces and establish
|
|
your <quote>through the tunnel</quote> policy as shown under the first
|
|
example above.</para>
|
|
</example>
|
|
</section>
|
|
|
|
<section id="Dynamic">
|
|
<title>Dynamic RoadWarrior Zones</title>
|
|
|
|
<para>Beginning with Shorewall release 1.3.10, you can define multiple VPN
|
|
zones and add and delete remote endpoints dynamically using
|
|
/sbin/shorewall. With Shorewall 2.0.2 Beta 1 and later versions, this
|
|
capability must be enabled by setting DYNAMIC_ZONES=Yes in <ulink
|
|
url="manpages/shorewall.conf.html">shorewall.conf</ulink>.</para>
|
|
|
|
<para>In /etc/shorewall/zones:</para>
|
|
|
|
<programlisting>#ZONE TYPE OPTIONS
|
|
vpn1 ipv4
|
|
vpn2 ipv4
|
|
vpn3 ipv4</programlisting>
|
|
|
|
<para>In /etc/shorewall/tunnels:</para>
|
|
|
|
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
|
|
ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3</programlisting>
|
|
|
|
<para>When Shorewall is started, the zones vpn[1-3] will all be empty and
|
|
Shorewall will issue warnings to that effect. These warnings may be safely
|
|
ignored. FreeS/Wan may now be configured to have three different Road
|
|
Warrior connections with the choice of connection being based on X-509
|
|
certificates or some other means. Each of these connectioins will utilize
|
|
a different updown script that adds the remote station to the appropriate
|
|
zone when the connection comes up and that deletes the remote station when
|
|
the connection comes down. For example, when 134.28.54.2 connects for the
|
|
vpn2 zone the <quote>up</quote> part of the script will issue the
|
|
command:</para>
|
|
|
|
<programlisting>/sbin/shorewall add ipsec0:134.28.54.2 vpn2</programlisting>
|
|
|
|
<para>and the <quote>down</quote> part will:</para>
|
|
|
|
<programlisting>/sbin/shorewall delete ipsec0:134.28.54.2 vpn2</programlisting>
|
|
</section>
|
|
</article> |