<?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>