<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shorewall and ipp2p</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id257523"></a>Shorewall and ipp2p</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2004, 2005, 2006 Thomas M. Eastep</p></div><div><div class="legalnotice"><a id="id257914"></a><p>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
“<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Intro">Introduction</a></span></dt><dt><span class="section"><a href="#Scope">Scope</a></span></dt><dt><span class="section"><a href="#Example">Example:</a></span></dt></dl></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span class="bold"><strong>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.</strong></span></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Intro"></a>Introduction</h2></div></div></div><p>Shorewall versions 2.2.0 and later include support for the ipp2p
match facility. This is a departure from my usual policy in that the ipp2p
match facility is included in Patch-O-Matic-ENG and is unlikely to ever be
included in the kernel.org source tree. Questions about how to install the
patch or how to build your kernel and/or iptables should not be posted on
the Shorewall mailing lists but should rather be referred to the Netfilter
Mailing List.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Scope"></a>Scope</h2></div></div></div><p>In the following files, the "PROTO" or "PROTOCOL" column may contain
"ipp2p":</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="ulink" href="traffic_shaping.htm" target="_self">/etc/shorewall/tcrules</a></td></tr><tr><td><a class="ulink" href="Accounting.html" target="_self">/etc/shorewall/accounting</a></td></tr><tr><td><a class="ulink" href="Shorewall_and_Routing.html" target="_self">/etc/shorewall/rules</a> (Recommend
that you place the rules in the ESTABLISHED section of that
file).</td></tr></table><p>When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a
list of the options and their meaning, at a root prompt type:</p><pre class="programlisting"><span class="command"><strong>iptables -m ipp2p --help</strong></span></pre><p>You must not include the leading "--" on the option; Shorewall will
supply those characters for you. If you do not include an option then
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Example"></a>Example:</h2></div></div></div><p>Example 2 in the ipp2p documentation recommends the following
iptables rules:</p><pre class="programlisting">01# iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark
02# iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT
03# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK --set-mark 1
04# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark
05# iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:12
06# iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 1 -j CLASSIFY --set-class 2:12</pre><p>Let's examine the above rules more carefully.</p><p>The individual packets of a P2P data stream do not all carry
tell-tale signs that are identifiable as being a particular P2P
application. So simply asking the ipp2p match code to mark each individual
packet isn't enough because only those packets that carry these tell-tale
signs will be marked. Fortunately, Netfilter provides a different type of
mark -- the <em class="firstterm">Connection Mark</em> which is associated
with the entry in the conntrack table rather that with the individual
packet. You can see connection mark values with the <span class="command"><strong>shorewall
show connections</strong></span> command:</p><pre class="programlisting">gateway:/etc/test# shorewall show connections
Shorewall-2.5.6 Connections at gateway - Tue Oct 4 15:45:11 PDT 2005
tcp 6 269712 ESTABLISHED src=192.168.3.8 dst=206.124.146.177 sport=50584 dport=993 packets=4899
bytes=302282 src=206.124.146.177 dst=192.168.3.8 sport=993 dport=50584 packets=7760 bytes=10032928 [ASSURED] <span class="bold"><strong>mark=0</strong></span> use=1
...</pre><p>Connection marks are persistent -- that is, once a connection mark
is set it retains its value until the connection is terminated.</p><p>Netfilter provides features to:</p><div class="orderedlist"><ol type="1"><li><p>Mark individual packets with a numeric value.</p></li><li><p>Save the current packet mark value in the connection
mark.</p></li><li><p>Restore the value in the connection mark to the current
packet.</p></li></ol></div><p>The strategy employed in the above rules is to mark the connection
of each P2P session with a mark value of 1. That way, each packet that is
part of the session can be marked using the 'Restore' function and can be
classified accordingly.</p><div class="orderedlist"><ol type="1"><li><p>Rule 01# restores the connection mark into the current
packet.</p></li><li><p>Rule 02# tests that restored mark and if it is not equal to
zero, the packet is ACCEPTed (no further processing).</p></li><li><p>Rule 03# asks the ipp2p match module to examine the packet and
if it is identifiable as part of a P2P session, mark the packet with
value 1.</p></li><li><p>Rule 04# saves the current packet mark in the conntrack table if
the current mark value is 1 (in other words, if it was marked by rule
03#).</p></li><li><p>Rule 05# classifies the packet to traffic shaping class 1:12 if
it is going out of eth0 and has mark value 1<sup>[<a id="id258271" href="#ftn.id258271" class="footnote">1</a>]</sup>.</p></li><li><p>Rule 06# classifies the packet to traffic shaping class 2:12 if
it is going out of eth1 and has mark value 1.</p></li></ol></div><p>These are implemented in the /etc/shorewall/tcrules file as
follows:</p><pre class="programlisting">#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST
# PORT(S)
RESTORE:P - - tcp
CONTINUE:P - - tcp - - - !0
1:P - - ipp2p ipp2p
SAVE:P - - tcp - - - 1
1:12 - eth0 - - - - 1
2:12 - eth1 - - - - 1 </pre><p>These rules do exactly the same thing as their counterparts
described above.</p><p>One change that I recommend --do your marking in the FORWARD chain
rather than in the PREROUTING chain:</p><pre class="programlisting">#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST
# PORT(S)
RESTORE:F - - tcp
CONTINUE:F - - tcp - - - !0
1:F - - ipp2p ipp2p
SAVE:F - - tcp - - - 1
1:12 - eth0 - - - - 1
2:12 - eth1 - - - - 1 </pre><p>It will work the same and will work with a <a class="ulink" href="MultiISP.html" target="_self">Multi-ISP setup</a>.</p></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id258271" href="#id258271" class="para">1</a>] </sup>There are two ways that Netfilter/iptables can classify
traffic. It can be classified directly (which is what this example
does) by specifying a <em class="firstterm">classid</em> of the form
<number>:<number> in the MARK column. That is the
preferred method. A classid is specified when a traffic shaping
class is defined. tc4shorewall assigns a classid of <device
number>:1<mark value>. The first device in
<code class="filename">/etc/shorewall/tcdevices</code> is device number 1,
the second is device number 2, and so on. For the first device,
mark value 1 is classid 1:11, mark value 22 is classid 1:122,
etc.. They may also be classified using an <em class="firstterm">fwmark
classifier</em> which causes the traffic shaping code to
classify the traffic based in the packet mark value. That is done
by the traffic shaping solution using the <span class="command"><strong>tc filter
add</strong></span> command. The built-in tc4shorewall shaper uses this
command so if you are using the built-in traffic shaping solution,
you may use either method.</p></div></div></div></body></html>
