shorewall_code/docs/IPSEC-2.6.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 a daemon included in
    your IPSEC package (StrongSwan, LibreSwan, ipsec-tools/Racoon, etc.) .
    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>

    <important>
      <para>This article provides guidance regarding configuring Shorewall to
      use with IPSEC. For configuring IPSEC itself, consult your IPSEC
      product's documentation.</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 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>

    <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>
  </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>
    </example>
  </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"/></para>

    <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&lt;-&gt;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>

    <important>
      <para>Note that this protocol 4 (IPIP) traffic appears to originate in
      the vpn zone, but it's source IP address is that of the remote gateway.
      As a consequence, that address must be included in the definition of the
      remote zone. If you haven't done that, the traffic will be dropped in
      the INPUT chain.</para>
    </important>
  </section>
</article>