<?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$--> <articleinfo> <title>Packet Handling</title> <authorgroup> <author> <firstname>Tom</firstname> <surname>Eastep</surname> </author> </authorgroup> <pubdate><?dbtimestamp format="Y/m/d"?></pubdate> <copyright> <year>2004</year> <year>2005</year> <year>2009</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> <section id="Intro"> <title>Introduction</title> <para>This article will try to help you understand how packets pass through a firewall configured by Shorewall. You may find it useful to have a copy of the <ulink url="NetfilterOverview.html">Netfilter Overview</ulink> handy to refer to.</para> <para>The discussion that follows assumes that you are running a current kernel (2.6.20 or later) with the <ulink url="kernel.htm">recommended options </ulink>included. Otherwise processing may be somewhat different from described below depending on the features supported by your kernel.</para> <para>Where a packet is covered by steps in more than one of the following sections, processing occurs in the order in which the sections appear.</para> </section> <section id="Incoming"> <title>Packets Entering the Firewall from Outside</title> <para>Certain processing occurs on packets entering the firewall from the outside that don't occur for packets that originate on the firewall itself.</para> <itemizedlist> <listitem> <para>The TOS field in the packet is conditionally altered based on the contents of your <filename>/etc/shorewall/tos</filename> file. This occurs in the <emphasis role="bold">pretos</emphasis> chain of the <emphasis>mangle</emphasis> table.</para> </listitem> <listitem> <para>Packets are marked based on the contents of your <filename>/etc/shorewall/mangle</filename> (<filename>/etc/shorewall/tcrules</filename>) file and the setting of MARK_IN_FORWARD_CHAIN in <filename>/etc/shorewall/shorewall.conf</filename>. This occurs in the <emphasis role="bold">tcpre</emphasis> chain of the <emphasis>mangle</emphasis> table.</para> </listitem> <listitem> <para>The destination IP address and/or port number are rewritten according to DNAT[-] and REDIRECT[-] rules in <filename>/etc/shorewall/rules</filename>. For new connection requests, this occurs in a chain in the <emphasis>nat</emphasis> table called <emphasis role="bold"><emphasis>zone</emphasis>_dnat</emphasis> where <emphasis>zone</emphasis> is the zone where the request originated. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule.</para> </listitem> <listitem> <para>If the destination was not rewritten in the previous step then it may be rewritten based on entries in /etc/shorewall/nat. For new connection requests, this occurs in a <emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>interface</emphasis>_in</emphasis> where <emphasis>interface</emphasis> is the interface on which the packet entered the firewall. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule.</para> </listitem> <listitem> <para>The packet passes through the accounting rules defined in <filename>/etc/shorewall/accounting</filename>.</para> </listitem> <listitem> <para>If FASTACCEPT=Yes in <filename>shorewall.conf</filename> and the packet is part of or related to an existing connection, it is accepted.</para> </listitem> <listitem> <para>The packet is processed according to your <ulink url="blacklisting_support.htm">Blacklisting configuration</ulink> (dynamic blacklist first). If BLACKLISTNEWONLY=Yes in <filename>/etc/shorewall/shorewall.conf</filename> then only new connection requests are processed. Processing occurs in the dynamic and blacklst</para> </listitem> <listitem> <para>If the interface on which the packet entered the firewall has the <emphasis>nosmurfs</emphasis> option specified in <filename>/etc/shorewall/interfaces</filename>, then if the packet is a new connection request is checked for being a smurf in the <emphasis>filter</emphasis> table's <emphasis role="bold">smurfs</emphasis> chain.</para> </listitem> <listitem> <para>If:</para> <itemizedlist> <listitem> <para>the packet will be processed by the firewall itself</para> </listitem> <listitem> <para>the interface on which the packet arrived has the <emphasis>dhcp</emphasis> option in <filename>/etc/shorewall/interfaces</filename>.</para> </listitem> <listitem> <para>packet's protocol is UDP with destination port 67 or 68.</para> </listitem> </itemizedlist> <para>then the packet is ACCEPTed in the <emphasis>filter</emphasis> table's <emphasis role="bold"><emphasis>interface</emphasis>_in</emphasis> chain (for example, eth0_in). Note that if the interface is its associated zones only interface, then the <emphasis role="bold"><emphasis>interface</emphasis>_in</emphasis> chain is optimized away and its rules are transferred to another chain.</para> </listitem> <listitem> <para>If the interface on which the packet entered the firewall has the <emphasis>tcpflags</emphasis> option specified in <filename>/etc/shorewall/interfaces</filename> and the packet's protocol is TCP then the TCP flags are checked by the <emphasis role="bold">tcpflags</emphasis> chain (<emphasis>filter</emphasis> table).</para> </listitem> </itemizedlist> </section> <section id="All"> <title>All Packets</title> <para>Regardless of whether the packet originated on the firewall or came from outside, certain processing steps are common.</para> <itemizedlist> <listitem> <para>Packets are marked based on the contents of your <filename>/etc/shorewall/tcrules</filename> file and the setting of MARK_IN_FORWARD_CHAIN in <filename>/etc/shorewall/shorewall.conf</filename>. This occurs in the <emphasis role="bold">tcfor</emphasis> chain of the <emphasis>mangle</emphasis> table.</para> <para>The remaining processing in this list occurs in the <emphasis>filter</emphasis> table.</para> </listitem> <listitem> <para>If either the host sending the packet or the host to which the packet is addressed is not in any defined zone then the all->all policy is applied to the packet (including logging). This can occur in the INPUT, FORWARD or OUTPUT chains.</para> </listitem> <listitem> <para>If the packet is part of an established connection or is part of a related connection then no further processing takes place in the filter table (<emphasis><emphasis>zone1</emphasis>2<emphasis>zone2</emphasis></emphasis> chain where <emphasis>zone1</emphasis> is the source zone and <emphasis>zone2</emphasis> is the destination zone).</para> </listitem> <listitem> <para>The packet is processed according to your <filename>/etc/shorewall/rules</filename> file. This happens in chains named <emphasis><emphasis role="bold"><emphasis>zone1</emphasis>2<emphasis>zone2</emphasis></emphasis></emphasis> chain where <emphasis>zone1</emphasis> is the source zone and <emphasis>zone2</emphasis> is the destination zone. Note that in the presence of <ulink url="manpages/shorewall-nested.html">nested or overlapping zones</ulink> and CONTINUE policies, a packet may go through more than one of these chains.</para> </listitem> <listitem> <para>Note: If the packet gets to this step, it did not match any rule.</para> <para>If the applicable policy has a <ulink url="Actions.html">common action</ulink> then that action is applied (chain has the same name as the action).</para> </listitem> <listitem> <para>If the applicable policy has logging specified, the packet is logged.</para> </listitem> <listitem> <para>The policy is applied (the packet is accepted, dropped or rejected).</para> </listitem> </itemizedlist> </section> <section id="Local"> <title>Packets Originating on the Firewall</title> <para>Packets that originate on the firewall itself undergo additional processing.</para> <itemizedlist> <listitem> <para>The TOS field in the packet is conditionally altered based on the contents of your <filename>/etc/shorewall/tos</filename> file. This occurs in the <emphasis role="bold">outtos</emphasis> chain of the <emphasis>mangle</emphasis> table.</para> </listitem> <listitem> <para>Packets are marked based on the contents of your <filename>/etc/shorewall/tcrules</filename> file. This occurs in the <emphasis role="bold">tcout</emphasis> chain of the <emphasis>mangle</emphasis> table.</para> </listitem> </itemizedlist> </section> <section id="Egress"> <title>Packets Leaving the Firewall</title> <para>Packets being sent to another host undergo additional processing.</para> <note> <para>The source IP address only gets rewritten by the first matching rule below.</para> </note> <itemizedlist> <listitem> <para>The source IP address may be rewritten according to DNAT rules that specify SNAT. If this is a new connection request, then the rewriting occurs in a <emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>zone</emphasis>_snat</emphasis> where <emphasis>zone</emphasis> is the destination zone. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule.</para> </listitem> <listitem> <para>If FASTACCEPT=Yes in <filename>shorewall.conf</filename> and the packet is part of or related to an existing connection, it is accepted.</para> </listitem> <listitem> <para>The source IP address may be rewritten according to an entry in the <filename>/etc/shorewall/nat</filename> file. If this is a new connection request, then the rewriting occurs in a <emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>interface</emphasis>_snat</emphasis> where <emphasis>interface</emphasis> is the interface on which the packet will be sent. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule.</para> </listitem> <listitem> <para>The source IP address may be rewritten according to an entry in the <filename>/etc/shorewall/masq</filename> file. If this is a new connection request, then the rewriting occurs in a <emphasis>nat</emphasis> table chain called <emphasis role="bold"><emphasis>interface</emphasis>_masq</emphasis> where <emphasis>interface</emphasis> is the interface on which the packet will be sent. For packets that are part of an already established connection, the destination rewriting takes place without any involvement of a Netfilter rule.</para> </listitem> </itemizedlist> </section> </article>