extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-25 17:13:11 +01:00
Code Issues Packages Projects Releases Wiki Activity
0a8905f25b
shorewall_code/docs/IPSEC.xml
Tom Eastep 9f9d9fd8d1 Eradicate usage of an interface name in the SOURCE column of the masq file 
Signed-off-by: Tom Eastep <teastep@shorewall.net>
2014-06-02 07:35:02 -07:00

442 lines
16 KiB
XML
Raw Blame History

<?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 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 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 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 eliminate 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 SOURCE ADDRESS
eth0:!10.0.0.0/8 192.168.1.0/24</programlisting>
<para>/etc/shorewall/masq - System B</para>
<programlisting>#INTERFACE SOURCE 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 diagram.</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 &amp; 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>.<important>
<para>DYNAMIC_ZONES=Yes is not supported by Shorewall-perl 4.2.0 or
later versions. Use <ulink url="ipsets.html#Dynamic">dynamic zones
defined by ipsets</ulink> instead.</para>
</important></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 connections 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>
Reference in New Issue View Git Blame Copy Permalink