forked from extern/shorewall_code
1201 lines
51 KiB
XML
1201 lines
51 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<refentry>
|
|
<refmeta>
|
|
<refentrytitle>shorewall6-tcrules</refentrytitle>
|
|
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>tcrules</refname>
|
|
|
|
<refpurpose>Shorewall6 Packet Marking rules file</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>/etc/shorewall6/tcrules</command>
|
|
</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>
|
|
<para>Unlike rules in the <ulink
|
|
url="shorewall6-rules.html">shorewall6-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>
|
|
|
|
<para>If you use multiple internet providers with the 'track' option, in
|
|
/etc/shorewall6/providers be sure to read the restrictions at <ulink
|
|
url="http://shorewall.net/MultiISP.html">http://shorewall.net/MultiISP.html</ulink>.</para>
|
|
</important>
|
|
|
|
<para>Beginning with Shorewall 4.5.4, the tcrules file supports two
|
|
different formats:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>FORMAT 1 (default - deprecated)</term>
|
|
|
|
<listitem>
|
|
<para>The older limited-function version of TPROXY is
|
|
supported.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>FORMAT 2</term>
|
|
|
|
<listitem>
|
|
<para>The newer version of TPROXY is supported.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>The format is specified by a line as follows:</para>
|
|
|
|
<blockquote>
|
|
<para><emphasis role="bold">[?]FORMAT {1|2}</emphasis></para>
|
|
</blockquote>
|
|
|
|
<para>The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is
|
|
the preferred form; the form without the '?' is deprecated.</para>
|
|
|
|
<para>The columns in the file are as follows (where the column name is
|
|
followed by a different name in parentheses, the different name is used in
|
|
the alternate specification syntax).</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ACTION</emphasis> -
|
|
<replaceable>action</replaceable></term>
|
|
|
|
<listitem>
|
|
<para><replaceable>action</replaceable> may assume one of the
|
|
following values.</para>
|
|
|
|
<orderedlist numeration="arabic">
|
|
<listitem>
|
|
<para>A mark <emphasis>value</emphasis> which is an integer in
|
|
the range 1-255.</para>
|
|
|
|
<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 ip6tables; neither may be used with
|
|
connection marks (see below).</para>
|
|
|
|
<para>May optionally be followed by <emphasis
|
|
role="bold">:P</emphasis>, <emphasis role="bold">:F</emphasis>
|
|
or <emphasis role="bold">:T</emphasis>, <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 role="bold">:P</emphasis>, <emphasis
|
|
role="bold">:F</emphasis> nor <emphasis
|
|
role="bold">:T</emphasis> follow the mark value then the chain
|
|
is determined as follows:</para>
|
|
|
|
<para>- If the SOURCE is <emphasis
|
|
role="bold">$FW</emphasis>[<emphasis
|
|
role="bold">:</emphasis><emphasis>address-or-range</emphasis>[,<emphasis>address-or-range</emphasis>]...],
|
|
then the rule is inserted into the OUTPUT chain. The behavior
|
|
changed in Shorewall6-perl 4.1. Only high mark values may be
|
|
assigned in this case. Packet marking rules for traffic shaping
|
|
of packets originating on the firewall must be coded in the
|
|
POSTROUTING chain (see below).</para>
|
|
|
|
<para>- Otherwise, the chain is determined by the setting of
|
|
MARK_IN_FORWARD_CHAIN in <ulink
|
|
url="shorewall6.conf.html">shorewall6.conf</ulink>(5).</para>
|
|
|
|
<para>Please note that <emphasis role="bold">:I</emphasis> is
|
|
included for completeness and affects neither traffic shaping
|
|
nor policy routing.</para>
|
|
|
|
<para>If your kernel and ip6tables 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). When a mask is specified, the result of
|
|
logically ANDing the mark value with the mask must be the same
|
|
as the mark value.</para>
|
|
|
|
<para>The mark and optional mask are then followed by one
|
|
of:+</para>
|
|
|
|
<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>
|
|
|
|
<varlistentry>
|
|
<term>CT</term>
|
|
|
|
<listitem>
|
|
<para>Mark the connection in the POSTROUTING chain</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<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>
|
|
</variablelist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A mark range which is a pair of integers separated by a
|
|
dash ("-"). Added in Shorewall 4.5.9.</para>
|
|
|
|
<para>May be optionally followed by a slash ("/") and a mask and
|
|
requires the <firstterm>Statistics Match</firstterm> capability
|
|
in iptables and kernel. Marks in the specified range are
|
|
assigned to packets on a round-robin fashion.</para>
|
|
|
|
<para>When a mask is specified, the result of logically ANDing
|
|
each mark value with the mask must be the same as the mark
|
|
value. The least significant bit in the mask is used as an
|
|
increment. For example, if '0x200-0x400/0xff00' is specified,
|
|
then the assigned mark values are 0x200, 0x300 and 0x400 in
|
|
equal proportions. If no mask is specified, then ( 2 **
|
|
MASK_BITS ) - 1 is assumed (MASK_BITS is set in <ulink
|
|
url="shorewall6.conf.html">shorewall6.conf</ulink>(5)).</para>
|
|
|
|
<para>May optionally be followed by <emphasis
|
|
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
|
|
role="bold">:P</emphasis>, <emphasis role="bold">:F</emphasis>
|
|
nor <emphasis role="bold">:T</emphasis> follow the mark value
|
|
then the chain is determined as follows:</para>
|
|
|
|
<para>- If the SOURCE is <emphasis
|
|
role="bold">$FW</emphasis>[<emphasis
|
|
role="bold">:</emphasis><emphasis>address-or-range</emphasis>[,<emphasis>address-or-range</emphasis>]...],
|
|
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>
|
|
|
|
<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>
|
|
|
|
<para>Please note that <emphasis role="bold">:I</emphasis> is
|
|
included for completeness and affects neither traffic shaping
|
|
nor policy routing.</para>
|
|
|
|
<para>If your kernel and iptables include CONNMARK support then
|
|
you can also mark the connection rather than the packet.</para>
|
|
|
|
<para>The mark range may be optionally followed by "/" and a
|
|
mask value (used to determine those bits of the connection mark
|
|
to actually be set). When a mask is specified, the result of
|
|
logically ANDing the mark value with each of the masks must be
|
|
the same as the mark value.</para>
|
|
|
|
<para>The mark range and optional mask may followed by one
|
|
of:</para>
|
|
|
|
<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>
|
|
|
|
<varlistentry>
|
|
<term>CT</term>
|
|
|
|
<listitem>
|
|
<para>Mark the connection in the POSTROUTING chain</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<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>
|
|
</variablelist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A classification Id (classid) of the form
|
|
<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
|
|
which case classification occurs in the OUTPUT chain.</para>
|
|
|
|
<para>When using Shorewall6's built-in traffic shaping tool, the
|
|
<emphasis>major</emphasis> class is the device number (the first
|
|
device in <ulink
|
|
url="shorewall6-tcdevices.html">shorewall6-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="shorewall6-tcclasses.html">shorewall6-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>
|
|
|
|
<para>Beginning with Shorewall 4.4.27, the classid may be
|
|
optionally followed by ':' and a capital letter designating the
|
|
chain where classification is to occur.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>F</term>
|
|
|
|
<listitem>
|
|
<para>FORWARD chain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>T</term>
|
|
|
|
<listitem>
|
|
<para>POSTROUTING chain (default).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">CHECKSUM</emphasis></para>
|
|
|
|
<para>Added in Shorewall 4.5.9. Compute and fill in the checksum
|
|
in a packet that lacks a checksum. This is particularly useful
|
|
if you need to work around old applications, such as dhcp
|
|
clients, that do not work well with checksum offloads, but you
|
|
don't want to disable checksum offload in your device.</para>
|
|
|
|
<para>Requires 'Checksum Target' support in your kernel and
|
|
ip6tables.</para>
|
|
</listitem>
|
|
|
|
<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>shorewall6
|
|
show mangle</command></para>
|
|
|
|
<para>To stop the comment from being attached to further rules,
|
|
simply include COMMENT on a line by itself.</para>
|
|
|
|
<note>
|
|
<para>Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
|
|
for COMMENT and is preferred.</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">CONTINUE</emphasis> Don't process
|
|
any more marking rules in the table.</para>
|
|
|
|
<para>As in 1) above, may be followed by <emphasis
|
|
role="bold">:P</emphasis> or <emphasis
|
|
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
|
|
ip6tables/Netfilter provides the necessary support.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">DIVERT</emphasis></para>
|
|
|
|
<para>Added in Shorewall 4.5.3. Two DIVERT rule should precede
|
|
the TPROXY rule and should select DEST PORT tcp 80 and SOURCE
|
|
PORT tcp 80 respectively (assuming that tcp port 80 is being
|
|
proxied). DIVERT avoids sending packets to the TPROXY target
|
|
once a socket connection to Squid3 has been established by
|
|
TPROXY. DIVERT marks the packet with a unique mark and exempts
|
|
it from any rules that follow.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">DROP</emphasis></para>
|
|
|
|
<para>Added in Shorewall 4.5.21.4. Causes matching packets to be
|
|
discarded.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis
|
|
role="bold">DSCP</emphasis>(<replaceable>dscp</replaceable>)</para>
|
|
|
|
<para>Added in Shorewall 4.5.1. Sets the
|
|
<firstterm>Differentiated Services Code Point</firstterm> field
|
|
in the IP header. The <replaceable>dscp</replaceable> value may
|
|
be given as an even number (hex or decimal) or as the name of a
|
|
DSCP class. Valid class names and their associated hex numeric
|
|
values are:</para>
|
|
|
|
<programlisting> CS0 => 0x00
|
|
CS1 => 0x08
|
|
CS2 => 0x10
|
|
CS3 => 0x18
|
|
CS4 => 0x20
|
|
CS5 => 0x28
|
|
CS6 => 0x30
|
|
CS7 => 0x38
|
|
BE => 0x00
|
|
AF11 => 0x0a
|
|
AF12 => 0x0c
|
|
AF13 => 0x0e
|
|
AF21 => 0x12
|
|
AF22 => 0x14
|
|
AF23 => 0x16
|
|
AF31 => 0x1a
|
|
AF32 => 0x1c
|
|
AF33 => 0x1e
|
|
AF41 => 0x22
|
|
AF42 => 0x24
|
|
AF43 => 0x26
|
|
EF => 0x2e</programlisting>
|
|
|
|
<para>To indicate more than one class, add their hex values
|
|
together and specify the result.</para>
|
|
|
|
<para>May be optionally followed by ':' and a capital letter
|
|
designating the chain where classification is to occur.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>F</term>
|
|
|
|
<listitem>
|
|
<para>FORWARD chain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>T</term>
|
|
|
|
<listitem>
|
|
<para>POSTROUTING chain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">HL</emphasis>([<emphasis
|
|
role="bold">-</emphasis>|<emphasis
|
|
role="bold">+</emphasis>]<replaceable>number</replaceable>)</para>
|
|
|
|
<para>Added in Shorewall 4.4.24.</para>
|
|
|
|
<para>Prior to Shorewall 4.5.7.2, may be optionally followed by
|
|
<emphasis role="bold">:F</emphasis> but the resulting rule is
|
|
always added to the FORWARD chain. Beginning with Shorewall
|
|
4.5.7.s, it may be optionally followed by <emphasis
|
|
role="bold">:P</emphasis>, in which case the rule is added to
|
|
the PREROUTING chain.</para>
|
|
|
|
<para>If <emphasis role="bold">+</emphasis> is included, packets
|
|
matching the rule will have their HL (hop limit) incremented by
|
|
<replaceable>number</replaceable>. Similarly, if <emphasis
|
|
role="bold">-</emphasis> is included, matching packets have
|
|
their HL decremented by <replaceable>number</replaceable>. If
|
|
neither <emphasis role="bold">+</emphasis> nor <emphasis
|
|
role="bold">-</emphasis> is given, the HL of matching packets is
|
|
set to <replaceable>number</replaceable>. The valid range of
|
|
values for <replaceable>number</replaceable> is 1-255.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis
|
|
role="bold">IMQ</emphasis>(<replaceable>number</replaceable>)</para>
|
|
|
|
<para>Added in Shorewall 4.5.1. Specifies that the packet should
|
|
be passed to the IMQ identified by
|
|
<replaceable>number</replaceable>. Requires IMQ Target support
|
|
in your kernel and ip6tables.</para>
|
|
</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 ip6tables must include
|
|
CONNMARK support.</para>
|
|
|
|
<para>As in 1) above, may be followed by <emphasis
|
|
role="bold">:P</emphasis> or <emphasis
|
|
role="bold">:F</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">SAME</emphasis> (Added in Shorewall
|
|
4.3.5) -- 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>#ACTION SOURCE DEST PROTO DEST
|
|
# 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
|
|
last five minutes then the new connection will use the same
|
|
provider as the connection over which that last packet was
|
|
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>#ACTION SOURCE DEST PROTO DEST
|
|
# 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
|
|
packet was sent.</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 ip6tables must include CONNMARK
|
|
support.</para>
|
|
|
|
<para>As in 1) above, may be followed by <emphasis
|
|
role="bold">:P</emphasis> or <emphasis
|
|
role="bold">:F</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">STATE</emphasis> {<emphasis
|
|
role="bold">NEW</emphasis>|<emphasis
|
|
role="bold">RELATED</emphasis>|<emphasis
|
|
role="bold">ESTABLISHED</emphasis>|<emphasis
|
|
role="bold">INVALID</emphasis>} [,...]</para>
|
|
|
|
<para>Added in Shorewall 4.5.9. The rule will only match if the
|
|
packet's connection is in one of the listed states.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis
|
|
role="bold">TOS</emphasis>(<replaceable>tos</replaceable>[/<replaceable>mask</replaceable>])</para>
|
|
|
|
<para>Added in Shorewall 4.5.1. Sets the <firstterm>Type of
|
|
Service</firstterm> field in the IP header. The
|
|
<replaceable>tos</replaceable> value may be given as an number
|
|
(hex or decimal) or as the name of a TOS type. Valid type names
|
|
and their associated hex numeric values are:</para>
|
|
|
|
<programlisting>Minimize-Delay => 0x10,
|
|
Maximize-Throughput => 0x08,
|
|
Maximize-Reliability => 0x04,
|
|
Minimize-Cost => 0x02,
|
|
Normal-Service => 0x00</programlisting>
|
|
|
|
<para>To indicate more than one class, add their hex values
|
|
together and specify the result.</para>
|
|
|
|
<para>When <replaceable>tos</replaceable> is given as a number,
|
|
it may be optionally followed by '/' and a
|
|
<replaceable>mask</replaceable>. When no
|
|
<replaceable>mask</replaceable> is given, the value 0xff is
|
|
assumed. When <replaceable>tos</replaceable> is given as a type
|
|
name, the <replaceable>mask</replaceable> 0x3f is
|
|
assumed.</para>
|
|
|
|
<para>The action performed is to zero out the bits specified by
|
|
the <replaceable>mask</replaceable>, then set the bits specified
|
|
by <replaceable>tos</replaceable>.</para>
|
|
|
|
<para>May be optionally followed by ':' and a capital letter
|
|
designating the chain where classification is to occur.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>F</term>
|
|
|
|
<listitem>
|
|
<para>FORWARD chain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>T</term>
|
|
|
|
<listitem>
|
|
<para>POSTROUTING chain (default).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis
|
|
role="bold">TPROXY</emphasis>(<replaceable>mark</replaceable>[,[<replaceable>port</replaceable>][,[<replaceable>address</replaceable>]]])
|
|
-- FORMAT 1</para>
|
|
|
|
<para>Transparently redirects a packet without altering the IP
|
|
header. Requires a local provider to be defined in <ulink
|
|
url="shorewall6-providers.html">shorewall6-providers</ulink>(5).</para>
|
|
|
|
<para>There are three parameters to TPROXY - only the first
|
|
(mark) is required:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><replaceable>mark</replaceable> - the MARK value
|
|
corresponding to the local provider in <ulink
|
|
url="shorewall6-providers.html">shorewall6-providers</ulink>(5).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><replaceable>port</replaceable> - the port on which
|
|
the proxy server is listening. If omitted, the original
|
|
destination port.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><replaceable>address</replaceable> - a local (to the
|
|
firewall) IP address on which the proxy server is listening.
|
|
If omitted, the IP address of the interface on which the
|
|
request arrives.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis
|
|
role="bold">TPROXY</emphasis>([<replaceable>port</replaceable>][,[<replaceable>address</replaceable>]]])
|
|
-- FORMAT 2</para>
|
|
|
|
<para>Transparently redirects a packet without altering the IP
|
|
header. Requires a local provider to be defined in <ulink
|
|
url="shorewall6-providers.html">shorewall6-providers</ulink>(5).</para>
|
|
|
|
<para>There are three parameters to TPROXY - only the first
|
|
(mark) is required:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><replaceable>port</replaceable> - the port on which
|
|
the proxy server is listening. If omitted, the original
|
|
destination port.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><replaceable>address</replaceable> - a local (to the
|
|
firewall) IP address on which the proxy server is listening.
|
|
If omitted, the IP address of the interface on which the
|
|
request arrives.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SOURCE</emphasis> - {<emphasis
|
|
role="bold">-</emphasis>|{<emphasis>interface</emphasis>|<emphasis
|
|
role="bold">$FW</emphasis>}|[{<emphasis>interface</emphasis>|<emphasis
|
|
role="bold">$FW</emphasis>}:]<<emphasis>address-or-range</emphasis>[<emphasis
|
|
role="bold">,</emphasis><emphasis>address-or-range</emphasis>]...}[<emphasis>exclusion</emphasis>]></term>
|
|
|
|
<listitem>
|
|
<para>Source of the packet. A comma-separated list of interface
|
|
names, IP addresses, MAC addresses and/or subnets for packets being
|
|
routed through a common path. List elements may also consist of an
|
|
interface name followed by ":" and an address (e.g.,
|
|
eth1:<2002:ce7c:92b4::/48>). For example, all packets for
|
|
connections masqueraded to eth0 from other interfaces can be matched
|
|
in a single rule with several alternative SOURCE criteria. However,
|
|
a connection whose packets gets to eth0 in a different way, e.g.,
|
|
direct from the firewall itself, needs a different rule.</para>
|
|
|
|
<para>Accordingly, use $<emphasis role="bold">FW</emphasis> in its
|
|
own separate rule for packets originating on the firewall. In such a
|
|
rule, the ACTION column may NOT specify either <emphasis
|
|
role="bold">:P</emphasis> or <emphasis role="bold">:F</emphasis>
|
|
because marking for firewall-originated packets always occurs in the
|
|
OUTPUT chain.</para>
|
|
|
|
<para>MAC addresses must be prefixed with "~" and use "-" as a
|
|
separator.</para>
|
|
|
|
<para>Example: ~00-A0-C9-15-39-78</para>
|
|
|
|
<para>When an interface is not specified, the angled brackets
|
|
('<' and '>') surrounding the address(es) may be
|
|
omitted.</para>
|
|
|
|
<para>You may exclude certain hosts from the set already defined
|
|
through use of an <emphasis>exclusion</emphasis> (see <ulink
|
|
url="shorewall6-exclusion.html">shorewall6-exclusion</ulink>(5)).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DEST</emphasis> - {<emphasis
|
|
role="bold">-</emphasis>|{<emphasis>interface</emphasis>|$FW}[{<emphasis>interface</emphasis>|$FW}:]<<emphasis>address-or-range</emphasis>[<emphasis
|
|
role="bold">,</emphasis><emphasis>address-or-range</emphasis>]...}[<emphasis>exclusion</emphasis>]></term>
|
|
|
|
<listitem>
|
|
<para>Destination of the packet. Comma separated list of IP
|
|
addresses and/or subnets. If your kernel and ip6tables include
|
|
iprange match support, IP address ranges are also allowed. List
|
|
elements may also consist of an interface name followed by ":" and
|
|
an address (e.g., eth1:<2002:ce7c:92b4::/48>). If the
|
|
<emphasis role="bold">ACTION</emphasis> column specifies a
|
|
classification of the form
|
|
<emphasis>major</emphasis>:<emphasis>minor</emphasis> then this
|
|
column may also contain an interface name.</para>
|
|
|
|
<para>When an interface is not specified, the angled brackets
|
|
('<' and '>') surrounding the address(es) may be
|
|
omitted.</para>
|
|
|
|
<para>Beginning with Shorewall 4.4.13, $FW may be given by itself or
|
|
qualified by an address list. This causes marking to occur in the
|
|
INPUT chain.</para>
|
|
|
|
<para>You may exclude certain hosts from the set already defined
|
|
through use of an <emphasis>exclusion</emphasis> (see <ulink
|
|
url="shorewall6-exclusion.html">shorewall6-exclusion</ulink>(5)).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">PROTO</emphasis> - {<emphasis
|
|
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>
|
|
|
|
<listitem>
|
|
<para>Protocol - <emphasis role="bold">ipp2p</emphasis> requires
|
|
ipp2p match support in your kernel and ip6tables.</para>
|
|
|
|
<para>Beginning with Shorewall 4.5.12, this column can accept a
|
|
comma-separated list of protocols.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">PORT(S)</emphasis> (dport) - [<emphasis
|
|
role="bold">-</emphasis>|<emphasis>port-name-number-or-range</emphasis>[<emphasis
|
|
role="bold">,</emphasis><emphasis>port-name-number-or-range</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>Optional destination Ports. A comma-separated list of Port
|
|
names (from services(5)), <emphasis>port number</emphasis>s or
|
|
<emphasis>port range</emphasis>s; if the protocol is <emphasis
|
|
role="bold">ipv6-icmp</emphasis>, this column is interpreted as the
|
|
destination icmp-type(s). ICMP types may be specified as a numeric
|
|
type, a numeric 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>
|
|
|
|
<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>An entry in this field requires that the PROTO column specify
|
|
tcp (6), udp (17), ipv6-icmp (58), sctp (132) or udplite (136). Use
|
|
'-' if any of the following field is supplied.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SOURCE PORT(S)</emphasis> (sport) -
|
|
[<emphasis
|
|
role="bold">-</emphasis>|<emphasis>port-name-number-or-range</emphasis>[<emphasis
|
|
role="bold">,</emphasis><emphasis>port-name-number-or-range</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>Optional 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>
|
|
|
|
<para>An entry in this field requires that the PROTO column specify
|
|
tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of
|
|
the following fields is supplied.</para>
|
|
|
|
<para>Beginning with Shorewall 4.5.15, you may place '=' in this
|
|
column, provided that the DEST PORT(S) column is non-empty. This
|
|
causes the rule to match when either the source port or the
|
|
destination port in a packet matches one of the ports specified in
|
|
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
|
|
and kernel.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">USER</emphasis> - [<emphasis
|
|
role="bold">!</emphasis>][<emphasis>user-name-or-number</emphasis>][<emphasis
|
|
role="bold">:</emphasis><emphasis>group-name-or-number</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This optional 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>
|
|
</variablelist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TEST</emphasis> - [<emphasis
|
|
role="bold">!</emphasis>]<emphasis>value</emphasis>[/<emphasis>mask</emphasis>][<emphasis
|
|
role="bold">:C</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Optional. Defines a test on the existing packet or connection
|
|
mark. The rule will match only if the test returns true.</para>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
<term><emphasis role="bold">LENGTH</emphasis> -
|
|
[<emphasis>length</emphasis>|[<emphasis>min</emphasis>]<emphasis
|
|
role="bold">:</emphasis>[<emphasis>max</emphasis>]]</term>
|
|
|
|
<listitem>
|
|
<para>Optional - packet payload length. This field, if present allow
|
|
you to match the length of a packet payload (Layer 4 data ) 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>
|
|
<term><emphasis role="bold">TOS</emphasis> (Optional) -
|
|
<emphasis>tos</emphasis></term>
|
|
|
|
<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>
|
|
|
|
<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
|
|
role="bold">A</emphasis>}]]]</term>
|
|
|
|
<listitem>
|
|
<para>Optional connection Bytes; defines a byte or packet range that
|
|
the connection must fall within in order for the rule to
|
|
match.</para>
|
|
|
|
<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>
|
|
|
|
<para><emphasis role="bold">R</emphasis> - The opposite
|
|
direction from the original connection.</para>
|
|
|
|
<para><emphasis role="bold">B</emphasis> - The total of both
|
|
directions.</para>
|
|
</blockquote></para>
|
|
|
|
<para>If omitted, <emphasis role="bold">B</emphasis> is
|
|
assumed.</para>
|
|
|
|
<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>
|
|
</blockquote>If omitted, <emphasis role="bold">B</emphasis> is
|
|
assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">HELPER -
|
|
</emphasis><emphasis>helper</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Optional. Names a Netfilter 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.</para>
|
|
|
|
<para>Example: Mark all FTP data connections with mark
|
|
4:<programlisting>#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST LENGTH TOS CONNBYTES HELPER
|
|
# PORT(S)
|
|
4 ::/0 ::/0 TCP - - - - - - - ftp</programlisting></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">HEADERS -
|
|
[!][any:|exactly:]</emphasis><replaceable>header-list
|
|
</replaceable>(Optional - Added in Shorewall 4.4.15)</term>
|
|
|
|
<listitem>
|
|
<para>The <replaceable>header-list</replaceable> consists of a
|
|
comma-separated list of headers from the following list.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">auth</emphasis>, <emphasis
|
|
role="bold">ah</emphasis>, or <emphasis
|
|
role="bold">51</emphasis></term>
|
|
|
|
<listitem>
|
|
<para><firstterm>Authentication Headers</firstterm> extension
|
|
header.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">esp</emphasis>, or <emphasis
|
|
role="bold">50</emphasis></term>
|
|
|
|
<listitem>
|
|
<para><firstterm>Encrypted Security Payload</firstterm>
|
|
extension header.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">hop</emphasis>, <emphasis
|
|
role="bold">hop-by-hop</emphasis> or <emphasis
|
|
role="bold">0</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Hop-by-hop options extension header.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">route</emphasis>, <emphasis
|
|
role="bold">ipv6-route</emphasis> or <emphasis
|
|
role="bold">41</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>IPv6 Route extension header.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">frag</emphasis>, <emphasis
|
|
role="bold">ipv6-frag</emphasis> or <emphasis
|
|
role="bold">44</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>IPv6 fragmentation extension header.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">none</emphasis>, <emphasis
|
|
role="bold">ipv6-nonxt</emphasis> or <emphasis
|
|
role="bold">59</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>No next header</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">proto</emphasis>, <emphasis
|
|
role="bold">protocol</emphasis> or <emphasis
|
|
role="bold">255</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Any protocol header.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>If <emphasis role="bold">any:</emphasis> is specified, the
|
|
rule will match if any of the listed headers are present. If
|
|
<emphasis role="bold">exactly:</emphasis> is specified, the will
|
|
match packets that exactly include all specified headers. If neither
|
|
is given, <emphasis role="bold">any:</emphasis> is assumed.</para>
|
|
|
|
<para>If <emphasis role="bold">!</emphasis> is entered, the rule
|
|
will match those packets which would not be matched when <emphasis
|
|
role="bold">!</emphasis> is omitted.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">PROBABILITY</emphasis> -
|
|
[probability]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.0. When non-empty, requires the
|
|
<firstterm>Statistics Match</firstterm> capability in your kernel
|
|
and ip6tables and causes the rule to match randomly but with the
|
|
given <replaceable>probability</replaceable>. The
|
|
<replaceable>probability</replaceable> is a number 0 <
|
|
<replaceable>probability</replaceable> <= 1 and may be expressed
|
|
at up to 8 decimal points of precision.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Example</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Example 1:</term>
|
|
|
|
<listitem>
|
|
<para>Mark all forwarded ICMP echo traffic with packet mark 1. Mark
|
|
all forwarded 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>
|
|
|
|
<para>We assume packet/connection mark 0 means unclassified.</para>
|
|
|
|
<programlisting> #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST
|
|
# PORT(S)
|
|
1 ::/0 ::/0 icmp echo-request
|
|
1 ::/0 ::/0 icmp echo-reply
|
|
RESTORE ::/0 ::/0 all - - - 0
|
|
CONTINUE ::/0 ::/0 all - - - !0
|
|
4 ::/0 ::/0 ipp2p:all
|
|
SAVE ::/0 ::/0 all - - - !0</programlisting>
|
|
|
|
<para>If a packet hasn't been classified (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/shorewall6/tcrules</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See ALSO</title>
|
|
|
|
<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>
|
|
|
|
<para><ulink
|
|
url="http://shorewall.net/configuration_file_basics.htm#Pairs">http://shorewall.net/configuration_file_basics.htm#Pairs</ulink></para>
|
|
|
|
<para>shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
|
|
shorewall6-blacklist(5), shorewall6-ecn(5), shorewall6-exclusion(5),
|
|
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
|
|
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
|
|
shorewall6-providers(5), shorewall6-rtrules(5),
|
|
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
|
|
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
|
|
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)</para>
|
|
</refsect1>
|
|
</refentry>
|