2006-11-16 05:17:13 +01:00
|
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
2008-10-06 16:51:25 +02:00
|
|
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
|
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
2006-11-16 05:17:13 +01:00
|
|
|
|
<refentry>
|
|
|
|
|
<refmeta>
|
|
|
|
|
<refentrytitle>shorewall-tcrules</refentrytitle>
|
|
|
|
|
|
|
|
|
|
<manvolnum>5</manvolnum>
|
|
|
|
|
</refmeta>
|
|
|
|
|
|
|
|
|
|
<refnamediv>
|
|
|
|
|
<refname>tcrules</refname>
|
|
|
|
|
|
|
|
|
|
<refpurpose>Shorewall Packet Marking rules file</refpurpose>
|
|
|
|
|
</refnamediv>
|
|
|
|
|
|
|
|
|
|
<refsynopsisdiv>
|
|
|
|
|
<cmdsynopsis>
|
2010-05-26 15:42:37 +02:00
|
|
|
|
<command>/etc/shorewall/tcrules</command>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</cmdsynopsis>
|
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
|
|
<para>Entries in this file cause packets to be marked as a means of
|
|
|
|
|
classifying them for traffic control or policy routing.</para>
|
|
|
|
|
|
|
|
|
|
<important>
|
2007-01-14 23:34:51 +01:00
|
|
|
|
<para>Unlike rules in the <ulink
|
|
|
|
|
url="shorewall-rules.html">shorewall-rules</ulink>(5) file, evaluation
|
|
|
|
|
of rules in this file will continue after a match. So the final mark for
|
|
|
|
|
each packet will be the one assigned by the LAST tcrule that
|
|
|
|
|
matches.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<para>If you use multiple internet providers with the 'track' option, in
|
2007-01-18 17:35:59 +01:00
|
|
|
|
/etc/shorewall/providers be sure to read the restrictions at <ulink
|
|
|
|
|
url="http://shorewall.net/MultiISP.html">http://shorewall.net/MultiISP.html</ulink>.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</important>
|
|
|
|
|
|
|
|
|
|
<para>The columns in the file are as follows.</para>
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">MARK/CLASSIFY</emphasis> -
|
2006-11-23 17:40:10 +01:00
|
|
|
|
{<emphasis>value</emphasis>|<emphasis>major</emphasis><emphasis
|
|
|
|
|
role="bold">:</emphasis><emphasis>minor</emphasis>|<emphasis
|
|
|
|
|
role="bold">RESTORE</emphasis>[<emphasis
|
|
|
|
|
role="bold">/</emphasis><emphasis>mask</emphasis>]|<emphasis
|
|
|
|
|
role="bold">SAVE</emphasis>[<emphasis
|
|
|
|
|
role="bold">/</emphasis><emphasis>mask</emphasis>]|<emphasis
|
2009-04-20 02:33:55 +02:00
|
|
|
|
role="bold">CONTINUE</emphasis>|<emphasis
|
|
|
|
|
role="bold">SAME</emphasis>|<emphasis
|
2009-05-03 18:56:13 +02:00
|
|
|
|
role="bold">COMMENT</emphasis>|<emphasis
|
|
|
|
|
role="bold">IPMARK</emphasis>[([(<emphasis
|
|
|
|
|
role="bold">src</emphasis>|<emphasis
|
|
|
|
|
role="bold">dst</emphasis>}][,[<emphasis>mask1</emphasis>][,[<emphasis>mask2</emphasis>][,[<emphasis>shift</emphasis>]]]]])]}[<emphasis
|
2006-11-23 17:40:10 +01:00
|
|
|
|
role="bold">:</emphasis>{<emphasis role="bold">C</emphasis>|<emphasis
|
|
|
|
|
role="bold">F</emphasis>|<emphasis role="bold">P</emphasis>|<emphasis
|
2006-12-09 00:17:25 +01:00
|
|
|
|
role="bold">T</emphasis>|<emphasis role="bold">CF</emphasis>|<emphasis
|
2010-09-05 01:08:29 +02:00
|
|
|
|
role="bold">CP</emphasis>|<emphasis
|
|
|
|
|
role="bold">CT</emphasis>|I:CI}]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
2007-07-24 21:05:51 +02:00
|
|
|
|
<para>May assume one of the following values.</para>
|
|
|
|
|
|
2006-12-09 00:17:25 +01:00
|
|
|
|
<orderedlist numeration="arabic">
|
2006-11-16 05:17:13 +01:00
|
|
|
|
<listitem>
|
2006-11-23 17:40:10 +01:00
|
|
|
|
<para>A mark <emphasis>value</emphasis> which is an integer in
|
|
|
|
|
the range 1-255.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<para>Normally will set the mark value. If preceded by a
|
|
|
|
|
vertical bar ("|"), the mark value will be logically ORed with
|
|
|
|
|
the current mark value to produce a new mark value. If preceded
|
|
|
|
|
by an ampersand ("&"), will be logically ANDed with the
|
|
|
|
|
current mark value to produce a new mark value.</para>
|
|
|
|
|
|
|
|
|
|
<para>Both "|" and "&" require Extended MARK Target support
|
|
|
|
|
in your kernel and iptables; neither may be used with connection
|
|
|
|
|
marks (see below).</para>
|
|
|
|
|
|
|
|
|
|
<para>May optionally be followed by <emphasis
|
2011-05-01 06:52:32 +02:00
|
|
|
|
role="bold">:P</emphasis>, <emphasis
|
|
|
|
|
role="bold">:F</emphasis>,<emphasis role="bold">:T</emphasis> or
|
|
|
|
|
<emphasis role="bold">:I</emphasis> where<emphasis role="bold">
|
|
|
|
|
:P</emphasis> indicates that marking should occur in the
|
|
|
|
|
PREROUTING chain, <emphasis role="bold">:F</emphasis> indicates
|
|
|
|
|
that marking should occur in the FORWARD chain, <emphasis
|
|
|
|
|
role="bold">:I </emphasis>indicates that marking should occur in
|
|
|
|
|
the INPUT chain (added in Shorewall 4.4.13), and <emphasis
|
|
|
|
|
role="bold">:T</emphasis> indicates that marking should occur in
|
|
|
|
|
the POSTROUTING chain. If neither <emphasis
|
2006-12-08 23:43:46 +01:00
|
|
|
|
role="bold">:P</emphasis>, <emphasis role="bold">:F</emphasis>
|
2011-05-01 06:52:32 +02:00
|
|
|
|
nor <emphasis role="bold">:T</emphasis> follow the mark value
|
|
|
|
|
then the chain is determined as follows:</para>
|
2006-12-08 23:43:46 +01:00
|
|
|
|
|
2007-09-10 17:38:01 +02:00
|
|
|
|
<para>- If the SOURCE is <emphasis
|
|
|
|
|
role="bold">$FW</emphasis>[<emphasis
|
|
|
|
|
role="bold">:</emphasis><emphasis>address-or-range</emphasis>[,<emphasis>address-or-range</emphasis>]...],
|
2009-07-16 02:50:55 +02:00
|
|
|
|
then the rule is inserted into the OUTPUT chain. When
|
|
|
|
|
HIGH_ROUTE_MARKS=Yes, only high mark values may be assigned
|
|
|
|
|
there. Packet marking rules for traffic shaping of packets
|
|
|
|
|
originating on the firewall must be coded in the POSTROUTING
|
|
|
|
|
chain (see below).</para>
|
2007-09-10 17:38:01 +02:00
|
|
|
|
|
|
|
|
|
<para>- Otherwise, the chain is determined by the setting of
|
|
|
|
|
MARK_IN_FORWARD_CHAIN in <ulink
|
|
|
|
|
url="shorewall.conf.html">shorewall.conf</ulink>(5).</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
2011-05-01 06:52:32 +02:00
|
|
|
|
<para>Please note that <emphasis role="bold">:I</emphasis> is
|
|
|
|
|
included for completeness and affects neither traffic shaping
|
|
|
|
|
nor policy routing.</para>
|
|
|
|
|
|
2006-11-16 05:17:13 +01:00
|
|
|
|
<para>If your kernel and iptables include CONNMARK support then
|
|
|
|
|
you can also mark the connection rather than the packet.</para>
|
|
|
|
|
|
|
|
|
|
<para>The mark value may be optionally followed by "/" and a
|
|
|
|
|
mask value (used to determine those bits of the connection mark
|
|
|
|
|
to actually be set). The mark and optional mask are then
|
2011-05-01 06:52:32 +02:00
|
|
|
|
followed by one of:</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><emphasis role="bold">C</emphasis></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Mark the connection in the chain determined by the
|
|
|
|
|
setting of MARK_IN_FORWARD_CHAIN</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><emphasis role="bold">CF</emphasis></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Mark the connection in the FORWARD chain</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><emphasis role="bold">CP</emphasis></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Mark the connection in the PREROUTING chain.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2006-12-08 23:43:46 +01:00
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>CT</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Mark the connecdtion in the POSTROUTING chain</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2011-05-01 06:52:32 +02:00
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>CI</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Mark the connection in the INPUT chain. This option
|
|
|
|
|
is included for completeness and has no applicability to
|
|
|
|
|
traffic shaping or policy routing.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</variablelist>
|
2007-12-04 23:19:40 +01:00
|
|
|
|
|
|
|
|
|
<para><emphasis role="bold">Special considerations for If
|
|
|
|
|
HIGH_ROUTE_MARKS=Yes in <ulink
|
|
|
|
|
url="shorewall.conf.html">shorewall.conf</ulink>(5</emphasis>).</para>
|
|
|
|
|
|
|
|
|
|
<para>If HIGH_ROUTE_MARKS=Yes, then you may also specify a value
|
|
|
|
|
in the range 0x0100-0xFF00 with the low-order byte being zero.
|
|
|
|
|
Such values may only be used in the PREROUTING chain (value
|
|
|
|
|
followed by <emphasis role="bold">:P</emphasis> or you have set
|
|
|
|
|
MARK_IN_FORWARD_CHAIN=No in <ulink
|
|
|
|
|
url="shorewall.conf.html">shorewall.conf</ulink>(5) and have not
|
|
|
|
|
followed the value with <option>:F</option>) or the OUTPUT chain
|
|
|
|
|
(SOURCE is <emphasis role="bold">$FW</emphasis>). With
|
|
|
|
|
HIGH_ROUTE_MARKS=Yes, non-zero mark values less that 256 are not
|
2009-07-16 02:50:55 +02:00
|
|
|
|
permitted. Shorewall prohibits non-zero mark values less that
|
|
|
|
|
256 in the OUTPUT chain when HIGH_ROUTE_MARKS=Yes. While earlier
|
|
|
|
|
versions allow such values in the OUTPUT chain, it is strongly
|
|
|
|
|
recommended that with HIGH_ROUTE_MARKS=Yes, you use the
|
|
|
|
|
POSTROUTING chain to apply traffic shaping
|
|
|
|
|
marks/classification.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
2007-07-24 21:05:51 +02:00
|
|
|
|
<para>A classification Id (classid) of the form
|
2006-11-16 05:17:13 +01:00
|
|
|
|
<emphasis>major</emphasis>:<emphasis>minor</emphasis> where
|
|
|
|
|
<emphasis>major</emphasis> and <emphasis>minor</emphasis> are
|
|
|
|
|
integers. Corresponds to the 'class' specification in these
|
|
|
|
|
traffic shaping modules:</para>
|
|
|
|
|
|
|
|
|
|
<programlisting> atm
|
|
|
|
|
cbq
|
|
|
|
|
dsmark
|
|
|
|
|
pfifo_fast
|
|
|
|
|
htb
|
|
|
|
|
prio</programlisting>
|
|
|
|
|
|
|
|
|
|
<para>Classification occurs in the POSTROUTING chain except when
|
|
|
|
|
the <emphasis role="bold">SOURCE</emphasis> is <emphasis
|
|
|
|
|
role="bold">$FW</emphasis>[:<emphasis>address</emphasis>] in
|
2007-07-24 21:05:51 +02:00
|
|
|
|
which case classification occurs in the OUTPUT chain.</para>
|
2006-11-28 17:14:07 +01:00
|
|
|
|
|
2007-12-04 23:19:40 +01:00
|
|
|
|
<para>When using Shorewall's built-in traffic shaping tool, the
|
2006-11-28 17:14:07 +01:00
|
|
|
|
<emphasis>major</emphasis> class is the device number (the first
|
2007-01-14 23:34:51 +01:00
|
|
|
|
device in <ulink
|
|
|
|
|
url="shorewall-tcdevices.html">shorewall-tcdevices</ulink>(5) is
|
|
|
|
|
major class 1, the second device is major class 2, and so on)
|
|
|
|
|
and the <emphasis>minor</emphasis> class is the class's MARK
|
|
|
|
|
value in <ulink
|
|
|
|
|
url="shorewall-tcclasses.html">shorewall-tcclasses</ulink>(5)
|
|
|
|
|
preceded by the number 1 (MARK 1 corresponds to minor class 11,
|
|
|
|
|
MARK 5 corresponds to minor class 15, MARK 22 corresponds to
|
|
|
|
|
minor class 122, etc.).</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para><emphasis
|
|
|
|
|
role="bold">RESTORE</emphasis>[/<emphasis>mask</emphasis>] --
|
|
|
|
|
restore the packet's mark from the connection's mark using the
|
|
|
|
|
supplied mask if any. Your kernel and iptables must include
|
|
|
|
|
CONNMARK support.</para>
|
|
|
|
|
|
2006-12-09 00:17:25 +01:00
|
|
|
|
<para>As in 1) above, may be followed by <emphasis
|
2006-11-16 05:17:13 +01:00
|
|
|
|
role="bold">:P</emphasis> or <emphasis
|
|
|
|
|
role="bold">:F</emphasis></para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para><emphasis
|
|
|
|
|
role="bold">SAVE</emphasis>[/<emphasis>mask</emphasis>] -- save
|
|
|
|
|
the packet's mark to the connection's mark using the supplied
|
|
|
|
|
mask if any. Your kernel and iptables must include CONNMARK
|
|
|
|
|
support.</para>
|
|
|
|
|
|
2006-12-09 00:17:25 +01:00
|
|
|
|
<para>As in 1) above, may be followed by <emphasis
|
2006-11-16 05:17:13 +01:00
|
|
|
|
role="bold">:P</emphasis> or <emphasis
|
|
|
|
|
role="bold">:F</emphasis></para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para><emphasis role="bold">CONTINUE</emphasis> Don't process
|
2009-04-19 22:41:46 +02:00
|
|
|
|
any more marking rules ‒in the table.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
2006-12-09 00:17:25 +01:00
|
|
|
|
<para>As in 1) above, may be followed by <emphasis
|
2006-11-16 05:17:13 +01:00
|
|
|
|
role="bold">:P</emphasis> or <emphasis
|
2007-01-15 19:27:34 +01:00
|
|
|
|
role="bold">:F</emphasis>. Currently, CONTINUE may not be used
|
|
|
|
|
with <emphasis>exclusion</emphasis> (see the SOURCE and DEST
|
|
|
|
|
columns below); that restriction will be removed when
|
|
|
|
|
iptables/Netfilter provides the necessary support.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</listitem>
|
|
|
|
|
|
2009-02-25 20:27:51 +01:00
|
|
|
|
<listitem>
|
2009-07-16 02:50:55 +02:00
|
|
|
|
<para><emphasis role="bold">SAME</emphasis> Some websites run
|
|
|
|
|
applications that require multiple connections from a client
|
|
|
|
|
browser. Where multiple 'balanced' providers are configured,
|
|
|
|
|
this can lead to problems when some of the connections are
|
|
|
|
|
routed through one provider and some through another. The SAME
|
|
|
|
|
target allows you to work around that problem. SAME may be used
|
|
|
|
|
in the PREROUTING and OUTPUT chains. When used in PREROUTING, it
|
|
|
|
|
causes matching connections from an individual local system to
|
|
|
|
|
all use the same provider. For example: <programlisting>#MARK/ SOURCE DEST PROTO DEST
|
2009-02-25 20:27:51 +01:00
|
|
|
|
#CLASSIFY PORT(S)
|
|
|
|
|
SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443</programlisting>
|
|
|
|
|
If a host in 192.168.1.0/24 attempts a connection on TCP port 80
|
|
|
|
|
or 443 and it has sent a packet on either of those ports in the
|
2009-02-25 22:04:17 +01:00
|
|
|
|
last five minutes then the new connection will use the same
|
2009-06-02 15:32:42 +02:00
|
|
|
|
provider as the connection over which that last packet was
|
2009-02-25 22:04:17 +01:00
|
|
|
|
sent.</para>
|
|
|
|
|
|
|
|
|
|
<para>When used in the OUTPUT chain, it causes all matching
|
|
|
|
|
connections to an individual remote system to all use the same
|
|
|
|
|
provider. For example:<programlisting>#MARK/ SOURCE DEST PROTO DEST
|
|
|
|
|
#CLASSIFY PORT(S)
|
|
|
|
|
SAME $FW 0.0.0.0/0 tcp 80,443</programlisting>
|
|
|
|
|
If the firewall attempts a connection on TCP port 80 or 443 and
|
|
|
|
|
it has sent a packet on either of those ports in the last five
|
|
|
|
|
minutes to the same remote system then the new connection will
|
|
|
|
|
use the same provider as the connection over which that last
|
2009-04-19 22:41:46 +02:00
|
|
|
|
packet was sent.</para>
|
2009-02-25 20:27:51 +01:00
|
|
|
|
</listitem>
|
|
|
|
|
|
2006-11-16 05:17:13 +01:00
|
|
|
|
<listitem>
|
|
|
|
|
<para><emphasis role="bold">COMMENT</emphasis> -- the rest of
|
|
|
|
|
the line will be attached as a comment to the Netfilter rule(s)
|
|
|
|
|
generated by the following entries. The comment will appear
|
|
|
|
|
delimited by "/* ... */" in the output of <command>shorewall
|
2006-11-21 17:45:57 +01:00
|
|
|
|
show mangle</command></para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<para>To stop the comment from being attached to further rules,
|
|
|
|
|
simply include COMMENT on a line by itself.</para>
|
|
|
|
|
</listitem>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para><emphasis role="bold">IPMARK</emphasis> ‒ Assigns a mark
|
|
|
|
|
to each matching packet based on the either the source or
|
|
|
|
|
destination IP address. By default, it assigns a mark value
|
|
|
|
|
equal to the low-order 8 bits of the source address. Default
|
|
|
|
|
values are:</para>
|
|
|
|
|
|
|
|
|
|
<simplelist>
|
|
|
|
|
<member>src</member>
|
|
|
|
|
|
|
|
|
|
<member><emphasis>mask1</emphasis> = 0xFF</member>
|
|
|
|
|
|
|
|
|
|
<member><emphasis>mask2</emphasis> = 0x00</member>
|
|
|
|
|
|
|
|
|
|
<member><emphasis>shift</emphasis> = 0</member>
|
|
|
|
|
</simplelist>
|
|
|
|
|
|
|
|
|
|
<para>'src' and 'dst' specify whether the mark is to be based on
|
|
|
|
|
the source or destination address respectively. The selected
|
2009-05-04 22:14:25 +02:00
|
|
|
|
address is first shifted to the right by
|
|
|
|
|
<emphasis>shift</emphasis> bits. The result is then LANDed with
|
|
|
|
|
<emphasis>mask1</emphasis> then LORed with
|
|
|
|
|
<emphasis>ma<emphasis>s</emphasis>k2</emphasis>.</para>
|
|
|
|
|
|
|
|
|
|
<para>In a sense, the IPMARK target is more like an IPCLASSIFY
|
|
|
|
|
target in that the mark value is later interpreted as a class
|
|
|
|
|
ID. A packet mark is 32 bits wide; so is a class ID. The
|
|
|
|
|
<major> class occupies the high-order 16 bits and the
|
|
|
|
|
<minor> class occupies the low-order 16 bits. So the class
|
|
|
|
|
ID 1:4ff (remember that class IDs are always in hex) is
|
|
|
|
|
equivalent to a mark value of 0x104ff. Remember that Shorewall
|
|
|
|
|
uses the interface number as the <major> number where the
|
|
|
|
|
first interface in tcdevices has <major> number 1, the
|
|
|
|
|
second has <major> number 2, and so on.</para>
|
|
|
|
|
|
|
|
|
|
<para>The IPMARK target assigns a mark to each matching packet
|
|
|
|
|
based on the either the source or destination IP address. By
|
|
|
|
|
default, it assigns a mark value equal to the low-order 8 bits
|
|
|
|
|
of the source address. The syntax is as follows:</para>
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
<para><option>IPMARK</option>[([{<option>src</option>|<option>dst</option>}][,[<replaceable>mask1</replaceable>][,[<replaceable>mask2</replaceable>][,[<replaceable>shift</replaceable>]]]])]</para>
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
<para>Default values are:</para>
|
|
|
|
|
|
|
|
|
|
<simplelist>
|
|
|
|
|
<member><option>src</option></member>
|
|
|
|
|
|
|
|
|
|
<member><replaceable>mask1</replaceable> = 0xFF</member>
|
|
|
|
|
|
|
|
|
|
<member><replaceable>mask2</replaceable> = 0x00</member>
|
|
|
|
|
|
|
|
|
|
<member><replaceable>shift</replaceable> = 0</member>
|
|
|
|
|
</simplelist>
|
|
|
|
|
|
2009-06-02 15:32:42 +02:00
|
|
|
|
<para><option>src</option> and <option>dst</option> specify
|
2009-05-04 22:14:25 +02:00
|
|
|
|
whether the mark is to be based on the source or destination
|
|
|
|
|
address respectively. The selected address is first shifted
|
|
|
|
|
right by <replaceable>shift</replaceable>, then LANDed with
|
|
|
|
|
<replaceable>mask1</replaceable> and then LORed with
|
|
|
|
|
<replaceable>mask2</replaceable>. The
|
|
|
|
|
<replaceable>shift</replaceable> argument is intended to be used
|
|
|
|
|
primarily with IPv6 addresses.</para>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
|
|
|
|
|
<para>Example:</para>
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
2009-06-02 15:32:42 +02:00
|
|
|
|
<para>IPMARK(src,0xff,0x10100)</para>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
|
|
|
|
|
<simplelist>
|
2009-05-04 22:14:25 +02:00
|
|
|
|
<member>Suppose that the source IP address is 192.168.4.3 =
|
|
|
|
|
0xc0a80403; then</member>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
|
2009-05-04 22:14:25 +02:00
|
|
|
|
<member>0xc0a80403 >> 0 = 0xc0a80403</member>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
|
2009-05-04 22:14:25 +02:00
|
|
|
|
<member>0xc0a80403 LAND 0xFF = 0x03</member>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
|
2009-05-04 22:14:25 +02:00
|
|
|
|
<member>0x03 LOR 0x0x10100 = 0x10103 or class ID
|
|
|
|
|
1:103</member>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
</simplelist>
|
|
|
|
|
</blockquote>
|
2009-05-04 22:14:25 +02:00
|
|
|
|
|
|
|
|
|
<para>It is important to realize that, while class IDs are
|
|
|
|
|
composed of a <replaceable>major</replaceable> and a
|
|
|
|
|
<replaceable>minor</replaceable> value, the set of values must
|
|
|
|
|
be unique. That is, the same numeric value cannot be used as
|
2009-11-15 16:46:49 +01:00
|
|
|
|
both a <replaceable>major</replaceable> and a
|
|
|
|
|
<replaceable>minor</replaceable> number for the same interface
|
|
|
|
|
unless class nesting occurs (which is not currently possible
|
|
|
|
|
with Shorewall). You should keep this in mind when deciding how
|
|
|
|
|
to map IP addresses to class IDs.</para>
|
2009-05-04 22:14:25 +02:00
|
|
|
|
|
|
|
|
|
<para>For example, suppose that your internal network is
|
|
|
|
|
192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6).
|
|
|
|
|
Your first notion might be to use IPMARK(src,0xFF,0x10000) so as
|
|
|
|
|
to produce class IDs 1:1 through 1:6. But 1:1 is an invalid
|
|
|
|
|
class ID since the <replaceable>major</replaceable> and
|
|
|
|
|
<replaceable>minor</replaceable> classes are equal. So you might
|
|
|
|
|
chose instent to use IPMARK(src,0xFF,0x10100) as in the example
|
|
|
|
|
above so that all of your <replaceable>minor</replaceable>
|
|
|
|
|
classes will have a value > 256.</para>
|
2009-05-03 18:56:13 +02:00
|
|
|
|
</listitem>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</orderedlist>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">SOURCE</emphasis> - {<emphasis
|
2006-11-23 17:40:10 +01:00
|
|
|
|
role="bold">-</emphasis>|{<emphasis>interface</emphasis>|<emphasis
|
2007-03-03 19:17:06 +01:00
|
|
|
|
role="bold">$FW</emphasis>}|[{<emphasis>interface</emphasis>|<emphasis
|
2006-11-23 17:40:10 +01:00
|
|
|
|
role="bold">$FW</emphasis>}:]<emphasis>address-or-range</emphasis>[<emphasis
|
2006-11-25 19:06:11 +01:00
|
|
|
|
role="bold">,</emphasis><emphasis>address-or-range</emphasis>]...}[<emphasis>exclusion</emphasis>]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
2009-02-04 00:56:17 +01:00
|
|
|
|
<para>May be:</para>
|
|
|
|
|
|
|
|
|
|
<orderedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>An interface name - matches traffic entering the firewall
|
|
|
|
|
on the specified interface. May not be used in classify rules or
|
|
|
|
|
in rules using the :T chain qualifier.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>A comma-separated list of host or network IP addresses or
|
|
|
|
|
MAC addresses. <emphasis role="bold">This form will not match
|
|
|
|
|
traffic that originates on the firewall itself unless either
|
|
|
|
|
<major><minor> or the :T chain qualifier is used in
|
|
|
|
|
the MARK column.</emphasis></para>
|
|
|
|
|
|
|
|
|
|
<para>Examples:<simplelist>
|
|
|
|
|
<member>0.0.0.0/0</member>
|
|
|
|
|
</simplelist></para>
|
|
|
|
|
|
|
|
|
|
<para><simplelist>
|
|
|
|
|
<member>192.168.1.0/24, 172.20.4.0/24</member>
|
|
|
|
|
</simplelist></para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>An interface name followed by a colon (":") followed by a
|
|
|
|
|
comma-separated list of host or network IP addresses or MAC
|
|
|
|
|
addresses. May not be used in classify rules or in rules using
|
|
|
|
|
the :T chain qualifier.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>$FW optionally followed by a colon (":") and a
|
|
|
|
|
comma-separated list of host or network IP addresses. Matches
|
|
|
|
|
packets originating on the firewall. May not be used with a
|
|
|
|
|
chain qualifier (:P, :F, etc.) in the MARK column.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</orderedlist>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<para>MAC addresses must be prefixed with "~" and use "-" as a
|
|
|
|
|
separator.</para>
|
|
|
|
|
|
|
|
|
|
<para>Example: ~00-A0-C9-15-39-78</para>
|
2006-11-25 19:06:11 +01:00
|
|
|
|
|
|
|
|
|
<para>You may exclude certain hosts from the set already defined
|
2007-01-14 23:34:51 +01:00
|
|
|
|
through use of an <emphasis>exclusion</emphasis> (see <ulink
|
|
|
|
|
url="shorewall-exclusion.html">shorewall-exclusion</ulink>(5)).</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">DEST</emphasis> - {<emphasis
|
2010-09-11 21:47:32 +02:00
|
|
|
|
role="bold">-</emphasis>|{<emphasis>interface</emphasis>|$FW}|[<emphasis>{interface</emphasis>|$FW}:]<emphasis>address-or-range</emphasis>[<emphasis
|
2006-11-25 19:06:11 +01:00
|
|
|
|
role="bold">,</emphasis><emphasis>address-or-range</emphasis>]...}[<emphasis>exclusion</emphasis>]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
2009-02-04 00:56:17 +01:00
|
|
|
|
<para>May be:</para>
|
|
|
|
|
|
|
|
|
|
<orderedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>An interface name. May not be used in the PREROUTING chain
|
|
|
|
|
(:P in the mark column or no chain qualifier and
|
|
|
|
|
MARK_IN_FORWARD_CHAIN=No in <ulink
|
|
|
|
|
url="manpages/shorewall.conf">shorewall.conf</ulink> (5)). The
|
|
|
|
|
interface name may be optionally followed by a colon (":") and
|
|
|
|
|
an IP address list.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>A comma-separated list of host or network IP addresses.
|
|
|
|
|
The list may include ip address ranges if your kernel and
|
|
|
|
|
iptables include iprange support.</para>
|
|
|
|
|
</listitem>
|
2010-09-11 21:47:32 +02:00
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Beginning with Shorewall 4.4.13, $FW may be specified by
|
|
|
|
|
itself or qualified by an address list. This causes marking to
|
|
|
|
|
occur in the INPUT chain.</para>
|
|
|
|
|
</listitem>
|
2009-02-04 00:56:17 +01:00
|
|
|
|
</orderedlist>
|
2006-11-25 19:06:11 +01:00
|
|
|
|
|
|
|
|
|
<para>You may exclude certain hosts from the set already defined
|
2007-01-14 23:34:51 +01:00
|
|
|
|
through use of an <emphasis>exclusion</emphasis> (see <ulink
|
|
|
|
|
url="shorewall-exclusion.html">shorewall-exclusion</ulink>(5)).</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">PROTO</emphasis> - {<emphasis
|
2006-11-23 17:40:10 +01:00
|
|
|
|
role="bold">-</emphasis>|<emphasis
|
|
|
|
|
role="bold">tcp:syn</emphasis>|<emphasis
|
|
|
|
|
role="bold">ipp2p</emphasis>|<emphasis
|
|
|
|
|
role="bold">ipp2p:udp</emphasis>|<emphasis
|
|
|
|
|
role="bold">ipp2p:all</emphasis>|<emphasis>protocol-number</emphasis>|<emphasis>protocol-name</emphasis>|<emphasis
|
|
|
|
|
role="bold">all}</emphasis></term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
2006-11-23 17:40:10 +01:00
|
|
|
|
<para>Protocol - <emphasis role="bold">ipp2p</emphasis> requires
|
|
|
|
|
ipp2p match support in your kernel and iptables.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">PORT(S)</emphasis> (Optional) - [<emphasis
|
2006-11-23 17:40:10 +01:00
|
|
|
|
role="bold">-</emphasis>|<emphasis>port-name-number-or-range</emphasis>[<emphasis
|
|
|
|
|
role="bold">,</emphasis><emphasis>port-name-number-or-range</emphasis>]...]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
2006-11-21 17:45:57 +01:00
|
|
|
|
<para>Destination Ports. A comma-separated list of Port names (from
|
2006-11-16 05:17:13 +01:00
|
|
|
|
services(5)), <emphasis>port number</emphasis>s or <emphasis>port
|
|
|
|
|
range</emphasis>s; if the protocol is <emphasis
|
|
|
|
|
role="bold">icmp</emphasis>, this column is interpreted as the
|
2009-11-05 20:58:54 +01:00
|
|
|
|
destination icmp-type(s). ICMP types may be specified as a numeric
|
|
|
|
|
type, a numberic type and code separated by a slash (e.g., 3/4), or
|
|
|
|
|
a typename. See <ulink
|
|
|
|
|
url="http://www.shorewall.net/configuration_file_basics.htm#ICMP">http://www.shorewall.net/configuration_file_basics.htm#ICMP</ulink>.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<para>If the protocol is <emphasis role="bold">ipp2p</emphasis>,
|
|
|
|
|
this column is interpreted as an ipp2p option without the leading
|
|
|
|
|
"--" (example <emphasis role="bold">bit</emphasis> for bit-torrent).
|
|
|
|
|
If no PORT is given, <emphasis role="bold">ipp2p</emphasis> is
|
|
|
|
|
assumed.</para>
|
|
|
|
|
|
|
|
|
|
<para>This column is ignored if PROTOCOL = all but must be entered
|
|
|
|
|
if any of the following field is supplied. In that case, it is
|
|
|
|
|
suggested that this field contain "-"</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">SOURCE PORT(S)</emphasis> (Optional) -
|
2006-11-23 17:40:10 +01:00
|
|
|
|
[<emphasis
|
|
|
|
|
role="bold">-</emphasis>|<emphasis>port-name-number-or-range</emphasis>[<emphasis
|
|
|
|
|
role="bold">,</emphasis><emphasis>port-name-number-or-range</emphasis>]...]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Source port(s). If omitted, any source port is acceptable.
|
|
|
|
|
Specified as a comma-separated list of port names, port numbers or
|
|
|
|
|
port ranges.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">USER</emphasis> (Optional) - [<emphasis
|
2006-11-23 17:40:10 +01:00
|
|
|
|
role="bold">!</emphasis>][<emphasis>user-name-or-number</emphasis>][<emphasis
|
|
|
|
|
role="bold">:</emphasis><emphasis>group-name-or-number</emphasis>][<emphasis
|
|
|
|
|
role="bold">+</emphasis><emphasis>program-name</emphasis>]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>This column may only be non-empty if the SOURCE is the
|
|
|
|
|
firewall itself.</para>
|
|
|
|
|
|
|
|
|
|
<para>When this column is non-empty, the rule applies only if the
|
|
|
|
|
program generating the output is running under the effective
|
|
|
|
|
<emphasis>user</emphasis> and/or <emphasis>group</emphasis>
|
|
|
|
|
specified (or is NOT running under that id if "!" is given).</para>
|
|
|
|
|
|
|
|
|
|
<para>Examples:</para>
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>joe</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>program must be run by joe</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>:kids</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>program must be run by a member of the 'kids'
|
|
|
|
|
group</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>!:kids</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>program must not be run by a member of the 'kids'
|
|
|
|
|
group</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>+upnpd</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>#program named upnpd</para>
|
|
|
|
|
|
|
|
|
|
<important>
|
|
|
|
|
<para>The ability to specify a program name was removed from
|
|
|
|
|
Netfilter in kernel version 2.6.14.</para>
|
|
|
|
|
</important>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
</variablelist>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">TEST</emphasis> - [<emphasis
|
2006-11-23 17:40:10 +01:00
|
|
|
|
role="bold">!</emphasis>]<emphasis>value</emphasis>[/<emphasis>mask</emphasis>][<emphasis
|
|
|
|
|
role="bold">:C</emphasis>]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
2006-11-21 17:45:57 +01:00
|
|
|
|
<para>Defines a test on the existing packet or connection mark. The
|
2007-05-08 21:05:25 +02:00
|
|
|
|
rule will match only if the test returns true.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
2006-11-23 17:40:10 +01:00
|
|
|
|
<para>If you don't want to define a test but need to specify
|
|
|
|
|
anything in the following columns, place a "-" in this field.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>!</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Inverts the test (not equal)</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><emphasis>value</emphasis></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Value of the packet or connection mark.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><emphasis>mask</emphasis></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>A mask to be applied to the mark before testing.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><emphasis role="bold">:C</emphasis></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Designates a connection mark. If omitted, the packet
|
|
|
|
|
mark's value is tested.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
</variablelist>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2006-11-23 17:40:10 +01:00
|
|
|
|
<term><emphasis role="bold">LENGTH</emphasis> (Optional) -
|
|
|
|
|
[<emphasis>length</emphasis>|[<emphasis>min</emphasis>]<emphasis
|
|
|
|
|
role="bold">:</emphasis>[<emphasis>max</emphasis>]]</term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Packet Length. This field, if present allow you to match the
|
|
|
|
|
length of a packet against a specific value or range of values. You
|
|
|
|
|
must have iptables length support for this to work. A range is
|
|
|
|
|
specified in the form
|
|
|
|
|
<emphasis>min</emphasis>:<emphasis>max</emphasis> where either
|
|
|
|
|
<emphasis>min</emphasis> or <emphasis>max</emphasis> (but not both)
|
|
|
|
|
may be omitted. If <emphasis>min</emphasis> is omitted, then 0 is
|
|
|
|
|
assumed; if <emphasis>max</emphasis> is omitted, than any packet
|
|
|
|
|
that is <emphasis>min</emphasis> or longer will match.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">TOS</emphasis> -
|
2006-11-23 17:40:10 +01:00
|
|
|
|
<emphasis>tos</emphasis></term>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Type of service. Either a standard name, or a numeric value to
|
|
|
|
|
match.</para>
|
|
|
|
|
|
|
|
|
|
<programlisting> <emphasis role="bold">Minimize-Delay</emphasis> (16)
|
|
|
|
|
<emphasis role="bold">Maximize-Throughput</emphasis> (8)
|
|
|
|
|
<emphasis role="bold">Maximize-Reliability</emphasis> (4)
|
|
|
|
|
<emphasis role="bold">Minimize-Cost</emphasis> (2)
|
|
|
|
|
<emphasis role="bold">Normal-Service</emphasis> (0)</programlisting>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2008-06-05 22:39:05 +02:00
|
|
|
|
|
2008-10-06 16:51:25 +02:00
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><emphasis role="bold">CONNBYTES</emphasis> -
|
|
|
|
|
[!]<emphasis>min</emphasis>:[<emphasis>max</emphasis>[:{<emphasis
|
|
|
|
|
role="bold">O</emphasis>|<emphasis role="bold">R</emphasis>|<emphasis
|
|
|
|
|
role="bold">B</emphasis>}[:{<emphasis
|
|
|
|
|
role="bold">B</emphasis>|<emphasis role="bold">P</emphasis>|<emphasis
|
2009-02-04 00:56:17 +01:00
|
|
|
|
role="bold">A</emphasis>}]]]</term>
|
2008-10-06 16:51:25 +02:00
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Connection Bytes; defines a byte or packet range that the
|
2009-07-16 02:50:55 +02:00
|
|
|
|
connection must fall within in order for the rule to match.</para>
|
2008-10-06 16:51:25 +02:00
|
|
|
|
|
|
|
|
|
<para>A packet matches if the the packet/byte count is within the
|
|
|
|
|
range defined by <emphasis>min</emphasis> and
|
|
|
|
|
<emphasis>max</emphasis> (unless ! is given in which case, a packet
|
|
|
|
|
matches if the packet/byte count is not within the range).
|
|
|
|
|
<emphasis>min</emphasis> is an integer which defines the beginning
|
|
|
|
|
of the byte/packet range. <emphasis>max</emphasis> is an integer
|
|
|
|
|
which defines the end of the byte/packet range; if omitted, only the
|
|
|
|
|
beginning of the range is checked. The first letter gives the
|
|
|
|
|
direction which the range refers to:<blockquote>
|
|
|
|
|
<para><emphasis role="bold">O</emphasis> - The original
|
|
|
|
|
direction of the connection.</para>
|
|
|
|
|
|
2009-07-16 02:50:55 +02:00
|
|
|
|
<para>- The opposite direction from the original
|
|
|
|
|
connection.</para>
|
2008-10-06 16:51:25 +02:00
|
|
|
|
|
|
|
|
|
<para><emphasis role="bold">B</emphasis> - The total of both
|
|
|
|
|
directions.</para>
|
|
|
|
|
</blockquote></para>
|
|
|
|
|
|
2009-02-04 00:56:17 +01:00
|
|
|
|
<para>If omitted, <emphasis role="bold">B</emphasis> is
|
|
|
|
|
assumed.</para>
|
2008-10-06 16:51:25 +02:00
|
|
|
|
|
|
|
|
|
<para>The second letter determines what the range refers
|
|
|
|
|
to.<blockquote>
|
|
|
|
|
<para><emphasis role="bold">B</emphasis> - Bytes</para>
|
|
|
|
|
|
|
|
|
|
<para><emphasis role="bold">P</emphasis> - Packets</para>
|
|
|
|
|
|
|
|
|
|
<para><emphasis role="bold">A</emphasis> - Average packet
|
|
|
|
|
size.</para>
|
2008-10-06 16:54:24 +02:00
|
|
|
|
</blockquote>If omitted, <emphasis role="bold">B</emphasis> is
|
2009-02-04 00:56:17 +01:00
|
|
|
|
assumed.</para>
|
2008-10-06 16:51:25 +02:00
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2008-06-05 22:39:05 +02:00
|
|
|
|
<varlistentry>
|
2008-07-10 15:33:54 +02:00
|
|
|
|
<term><emphasis role="bold">HELPER -
|
2008-10-06 22:19:17 +02:00
|
|
|
|
</emphasis><emphasis>helper</emphasis></term>
|
2008-06-05 22:39:05 +02:00
|
|
|
|
|
|
|
|
|
<listitem>
|
2009-07-16 02:50:55 +02:00
|
|
|
|
<para>Names a Netfiler protocol <firstterm>helper</firstterm> module
|
|
|
|
|
such as <option>ftp</option>, <option>sip</option>,
|
|
|
|
|
<option>amanda</option>, etc. A packet will match if it was accepted
|
|
|
|
|
by the named helper module. You can also append "-" and a port
|
|
|
|
|
number to the helper module name (e.g., <emphasis
|
|
|
|
|
role="bold">ftp-21</emphasis>) to specify the port number that the
|
|
|
|
|
original connection was made on.</para>
|
2008-10-06 21:52:59 +02:00
|
|
|
|
|
|
|
|
|
<para>Example: Mark all FTP data connections with mark
|
|
|
|
|
4:<programlisting>#MARK/ SOURCE DEST PROTO PORT(S) SOURCE USER TEST LENGTH TOS CONNBYTES HELPER
|
|
|
|
|
#CLASSIFY PORT(S)
|
2009-02-04 00:56:17 +01:00
|
|
|
|
4:T 0.0.0.0/0 0.0.0.0/0 TCP - - - - - - - ftp</programlisting></para>
|
2008-06-05 22:39:05 +02:00
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</variablelist>
|
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Example</title>
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>Example 1:</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Mark all ICMP echo traffic with packet mark 1. Mark all peer
|
|
|
|
|
to peer traffic with packet mark 4.</para>
|
|
|
|
|
|
|
|
|
|
<para>This is a little more complex than otherwise expected. Since
|
|
|
|
|
the ipp2p module is unable to determine all packets in a connection
|
|
|
|
|
are P2P packets, we mark the entire connection as P2P if any of the
|
|
|
|
|
packets are determined to match.</para>
|
|
|
|
|
|
2006-11-21 17:45:57 +01:00
|
|
|
|
<para>We assume packet/connection mark 0 means unclassified.</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
2009-02-04 00:56:17 +01:00
|
|
|
|
<programlisting> #MARK/ SOURCE DEST PROTO PORT(S) SOURCE USER TEST
|
|
|
|
|
#CLASSIFY PORT(S)
|
|
|
|
|
1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-request
|
|
|
|
|
1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
|
|
|
|
|
RESTORE:T 0.0.0.0/0 0.0.0.0/0 all - - - 0
|
|
|
|
|
CONTINUE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0
|
|
|
|
|
4:T 0.0.0.0/0 0.0.0.0/0 ipp2p:all
|
|
|
|
|
SAVE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0</programlisting>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
|
|
|
|
|
<para>If a packet hasn't been classifed (packet mark is 0), copy the
|
|
|
|
|
connection mark to the packet mark. If the packet mark is set, we're
|
|
|
|
|
done. If the packet is P2P, set the packet mark to 4. If the packet
|
|
|
|
|
mark has been set, save it to the connection mark.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
</variablelist>
|
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>FILES</title>
|
|
|
|
|
|
|
|
|
|
<para>/etc/shorewall/tcrules</para>
|
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>See ALSO</title>
|
|
|
|
|
|
2006-11-22 04:51:39 +01:00
|
|
|
|
<para><ulink
|
|
|
|
|
url="http://shorewall.net/traffic_shaping.htm">http://shorewall.net/traffic_shaping.htm</ulink></para>
|
|
|
|
|
|
|
|
|
|
<para><ulink
|
|
|
|
|
url="http://shorewall.net/MultiISP.html">http://shorewall.net/MultiISP.html</ulink></para>
|
|
|
|
|
|
|
|
|
|
<para><ulink
|
|
|
|
|
url="http://shorewall.net/PacketMarking.html">http://shorewall.net/PacketMarking.html</ulink></para>
|
|
|
|
|
|
2006-11-16 05:17:13 +01:00
|
|
|
|
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
|
2006-11-25 19:06:11 +01:00
|
|
|
|
shorewall-blacklist(5), shorewall-ecn(5), shorewall-exclusion(5),
|
2011-05-01 06:52:32 +02:00
|
|
|
|
shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
|
|
|
|
|
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
|
|
|
|
|
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
|
|
|
|
|
shorewall-providers(5), shorewall-proxyarp(5), shorewall-route_rules(5),
|
2010-09-11 21:47:32 +02:00
|
|
|
|
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
|
|
|
|
|
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
|
|
|
|
|
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
|
2006-11-16 05:17:13 +01:00
|
|
|
|
</refsect1>
|
2008-10-06 16:51:25 +02:00
|
|
|
|
</refentry>
|