shorewall_code/docs/IPSEC.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>2005-09-30</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>
    <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>
    <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>
    <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>
    <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 &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>
    <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>
      <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>
    <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="Documentation.htm#Conf">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>
      <title>Limitations of Dynamic Zones</title>

      <para>If you include a dynamic zone in the exclude list of a DNAT rule,
      the dynamically-added hosts are not excluded from the rule.</para>

      <programlisting>#ACTION      SOURCE        DEST            PROTO     DEST PORT(S)
DNAT         z!dyn         loc:192.168.1.3 tcp       80</programlisting>

      <example>
        <title>dyn=dynamic zone</title>

        <para>Dynamic changes to the zone <emphasis role="bold">dyn</emphasis>
        will have no effect on the above rule.</para>
      </example>
    </section>
  </section>
</article>