holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Running out of steam for man pages..........

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4895 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-11-16 04:17:13 +00:00
parent 6fae8edd28
commit 43df47ffbd
4 changed files with 1099 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

158
manpages/shorewall-routestopped.xml Normal file
View File

@ -0,0 +1,158 @@
<?xml version="1.0" encoding="UTF-8"?>
<refentry>
<refmeta>
<refentrytitle>shorewall-routestopped</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>routestopped</refname>
<refpurpose>The Shorewall file that governs what traffic flows through the
firewall while it is in 'stopped' state.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>/etc/shorewall/routestopped</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>This file is used to define the hosts that are accessible when the
firewall is stopped or when it is in the process of being
[re]started.</para>
<para>The columns in the file are as follows.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">INTERFACE</emphasis></term>
<listitem>
<para>Interface through which host(s) communicate with the
firewall</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">HOST(S)</emphasis> (Optional)</term>
<listitem>
<para>Comma-separated list of IP/subnet addresses. If your kernel
and iptables include iprange match support, IP address ranges are
also allowed.</para>
<para>If left empty or supplied as "-", 0.0.0.0/0 is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">OPTIONS</emphasis> (Optional)</term>
<listitem>
<para>A comma-separated list of options. The order of the options is
not important but the list can contain no embedded whitespace. The
currently-supported options are:</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">routeback</emphasis></term>
<listitem>
<para>Set up a rule to ACCEPT traffic from these hosts back to
themselves.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">source</emphasis></term>
<listitem>
<para>Allow traffic from these hosts to ANY destination.
Without this option or the <emphasis
role="bold">dest</emphasis> option, only traffic from this
host to other listed hosts (and the firewall) is allowed. If
<emphasis role="bold">source</emphasis> is specified then
<emphasis role="bold">routeback</emphasis> is
redundant.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">dest</emphasis></term>
<listitem>
<para>Allow traffic to these hosts from ANY source. Without
this option or the <emphasis role="bold">source</emphasis>
option, only traffic from this host to other listed hosts (and
the firewall) is allowed. If <emphasis
role="bold">dest</emphasis> is specified then <emphasis
role="bold">routeback</emphasis> is redundant.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">critical</emphasis></term>
<listitem>
<para>Allow traffic between the firewall and these hosts
throughout '[re]start', 'stop' and 'clear'. Specifying
<emphasis role="bold">critical</emphasis> on one or more
entries will cause your firewall to be "totally open" for a
brief window during each of those operations.</para>
</listitem>
</varlistentry>
</variablelist>
<note>
<para>The <emphasis role="bold">source</emphasis> and <emphasis
role="bold">dest</emphasis> options work best when used in
conjunction with ADMINISABSENTMINDED=Yes in
shorewall.conf(5).</para>
</note>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Example</title>
<variablelist>
<varlistentry>
<term>Example 1:</term>
<listitem>
<programlisting> #INTERFACE HOST(S) OPTIONS
eth2 192.168.1.0/24
eth0 192.0.2.44
br0 - routeback
eth3 - source</programlisting>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>FILES</title>
<para>/etc/shorewall/routestopped</para>
</refsect1>
<refsect1>
<title>See ALSO</title>
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
shorewall-ipsec(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), shorewall-rules(5), shorewall.conf(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
</refsect1>
</refentry>

337
manpages/shorewall-tcclasses.xml Normal file
View File

@ -0,0 +1,337 @@
<?xml version="1.0" encoding="UTF-8"?>
<refentry>
<refmeta>
<refentrytitle>shorewall-tcclasses</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>tcclasses</refname>
<refpurpose>Shorewall file to define HTB classes</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>/etc/shorewall/tcclasses</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>A note on the rate/bandwidth definitions used in this file:</para>
<itemizedlist>
<listitem>
<para>don't use a space between the integer value and the unit: 30kbit
is valid while 30 kbit is NOT.</para>
</listitem>
<listitem>
<para>you can use one of the following units:</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">kpbs</emphasis></term>
<listitem>
<para>Kilobytes per second.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">mbps</emphasis></term>
<listitem>
<para>Megabytes per second.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">kbit</emphasis></term>
<listitem>
<para>Kilobits per second.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">mbit</emphasis></term>
<listitem>
<para>Megabits per second.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">bps</emphasis> or <emphasis
role="bold">number</emphasis></term>
<listitem>
<para>Bytes per second.</para>
</listitem>
</varlistentry>
</variablelist>
</listitem>
<listitem>
<para>if you want the values to be calculated for you depending on the
output bandwidth setting defined for an interface in tcdevices, you
can use expressions like the following:</para>
<variablelist>
<varlistentry>
<term>full/3</term>
<listitem>
<para>causes the bandwidth to be calculated as 1/3 of the full
outgoing speed that is defined.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>full*9/10</term>
<listitem>
<para>will set this bandwidth to 9/10 of the full
bandwidth</para>
</listitem>
</varlistentry>
</variablelist>
<para>DO NOT add a unit to the rate if it is calculated !</para>
</listitem>
</itemizedlist>
<para>The columns in the file are as follows.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">INTERFACE</emphasis></term>
<listitem>
<para>Name of interface. Each interface may be listed only once in
this file. You may NOT specify the name of an alias (e.g., eth0:0)
here; see http://www.shorewall.net/FAQ.htm#faq18</para>
<para>You may NOT specify wildcards here, e.g. if you have multiple
ppp interfaces, you need to put them all in here!</para>
<para>Please note that you can only use interface names in here that
have a bandwidth defined in the tcdevices file</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">MARK</emphasis></term>
<listitem>
<para>The mark value which is an integer in the range 1-255. You
define this marks in the tcrules file, marking the traffic you want
to fit in the classes defined in here.</para>
<para>You can use the same marks for different interfaces.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">RATE</emphasis></term>
<listitem>
<para>The minimum bandwidth this class should get, when the traffic
load rises. If the sum of the rates in this column exceed the
INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be
honored.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">CEIL</emphasis></term>
<listitem>
<para>The maximum bandwidth this class is allowed to use when the
link is idle. Useful if you have traffic which can get full speed
when more needed services (e.g. ssh) are not used.</para>
<para>You can use the value "full" in here for setting the maximum
bandwidth to the defined output bandwidth of that interface.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">PRIORITY</emphasis></term>
<listitem>
<para>The priority in which classes will be serviced by the packet
shaping scheduler and also the priority in which bandwidth in excess
of the rate will be given to each class.</para>
<para>Higher priority classes will experience less delay since they
are serviced first. Priority values are serviced in ascending order
(e.g. 0 is higher priority than 1).</para>
<para>Classes may be set to the same priority, in which case they
will be serviced as equals.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">OPTIONS</emphasis></term>
<listitem>
<para>A comma-separated list of options including the
following:</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">default</emphasis></term>
<listitem>
<para>This is the default class for that interface where all
traffic should go, that is not classified otherwise.</para>
<note>
<para>You must define <emphasis
role="bold">default</emphasis> for exactly one class per
interface.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">tos=0x</emphasis><emphasis>value</emphasis>[/0x<emphasis>mask</emphasis>]
(mask defaults to 0xff)</term>
<listitem>
<para>This lets you define a classifier for the given
<emphasis>value</emphasis>/<emphasis>mask</emphasis>
combination of the IP packet's TOS/Precedence/DiffSrv octet
(aka the TOS byte). Please note note classifiers override all
mark settings, so if you define a classifer for a class, all
traffic having that mark will go in it regardless of any mark
set on the packet by a firewall/mangle filter.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis
role="bold">tos-</emphasis><emphasis>tosname</emphasis></term>
<listitem>
<para>Aliases for the following TOS octet value and mask
encodings. TOS encodings of the "TOS byte" have been
deprecated in favor of diffserve classes, but programs like
ssh, rlogin, and ftp still use them.</para>
<programlisting> <emphasis role="bold">tos-minimize-delay</emphasis> 0x10/0x10
<emphasis role="bold">tos-maximize-throughput</emphasis> 0x08/0x08
<emphasis role="bold">tos-maximize-reliability</emphasis> 0x04/0x04
<emphasis role="bold">tos-minimize-cost</emphasis> 0x02/0x02
<emphasis role="bold">tos-normal-service</emphasis> 0x00/0x1e</programlisting>
<note>
<para> Each of this options is only valid for ONE class per
interface.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">tcp-ack</emphasis></term>
<listitem>
<para>If defined causes an tc filter to be created that puts
all tcp ack packets on that interface that have an size of
&lt;=64 Bytes to go in this class. This is useful for speeding
up downloads. Please note that the size of the ack packets is
limited to 64 bytes as some applications (p2p for example) use
to make every packet an ack packet which would cause them all
into here. We want only packets WITHOUT payload to match, so
the size limit.</para>
<note>
<para>This option is only valid for ONE class per
interface.</para>
</note>
</listitem>
</varlistentry>
</variablelist>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Examples</title>
<variablelist>
<varlistentry>
<term>Example 1:</term>
<listitem>
<para>Suppose you are using PPP over Ethernet (DSL) and ppp0 is the
interface for this. You have 4 classes here, the first you can use
for voice over IP traffic, the second interactive traffic (e.g.
ssh/telnet but not scp), the third will be for all unclassified
traffic, and the forth is for low priority traffic (e.g.
peer-to-peer).</para>
<para>The voice traffic in the first class will be guaranteed a
minimum of 100kbps and always be serviced first (because of the low
priority number, giving less delay) and will be granted excess
bandwidth (up to 180kbps, the class ceiling) first, before any other
traffic. A single VOIP stream, depending upon codecs, after
encapsulation, can take up to 80kbps on a PPOE/DSL link, so we pad a
little bit just in case. (TOS byte values 0xb8 and 0x68 are DiffServ
classes EF and AFF3-1 respectively and are often used by VOIP
devices).</para>
<para>Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP
echo traffic if you use the example in tcrules) and any packet with
a mark of 2 will be guaranteed 1/4 of the link bandwidth, and may
extend up to full speed of the link.</para>
<para>Unclassified traffic and packets marked as 3 will be
guaranteed 1/4th of the link bandwidth, and may extend to the full
speed of the link.</para>
<para>Packets marked with 4 will be treated as low priority packets.
(The tcrules example marks p2p traffic as such.) If the link is
congested, they're only guaranteed 1/8th of the speed, and even if
the link is empty, can only expand to 80% of link bandwidth just as
a precaution in case there are upstream queues we didn't account
for. This is the last class to get additional bandwidth and the last
to get serviced by the scheduler because of the low priority.</para>
<programlisting> #INTERFACE MARK RATE CEIL MARK OPTIONS
ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc
ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay
ppp0 3 full/4 full 3 default
ppp0 4 full/8 full*8/10 4</programlisting>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>FILES</title>
<para>/etc/shorewall/tcclasses</para>
</refsect1>
<refsect1>
<title>See ALSO</title>
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
shorewall-ipsec(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), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
</refsect1>
</refentry>

126
manpages/shorewall-tcdevices.xml Normal file
View File

@ -0,0 +1,126 @@
<?xml version="1.0" encoding="UTF-8"?>
<refentry>
<refmeta>
<refentrytitle>shorewall-tcdevices</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>tcdevices</refname>
<refpurpose>Shorewall Traffic Shaping Devices file</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>/etc/shorewall/tcdevices</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Entries in this file define the bandwidth for interfaces on which
you want traffic shaping to be enabled.</para>
<para> If you do not plan to use traffic shaping for a device, don't put
it in here as it limits the troughput of that device to the limits you set
here.</para>
<para>The columns in the file are as follows.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">INTERFACES</emphasis></term>
<listitem>
<para>Name of interface. Each interface may be listed only once in
this file. You may NOT specify the name of an alias (e.g., eth0:0)
here; see http://www.shorewall.net/FAQ.htm#faq18</para>
<para>You man NOT specify wildcards here, e.g. if you have multiple
ppp interfaces, you need to put them all in here!</para>
<para>If the device doesn't exist, a warning message will be issued
during "shorewall [re]start" and "shorewall refresh" and traffic
shaping configuration will be skipped for that device.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">IN-BANDWIDTH</emphasis></term>
<listitem>
<para>The incoming Bandwidth of that interface. Please note that you
are not able to do traffic shaping on incoming traffic, as the
traffic is already received before you could do so. But this allows
you to define the maximum traffic allowed for this interface in
total, if the rate is exceeded, the packets are dropped. You want
this mainly if you have a DSL or Cable connection to avoid queuing
at your providers side.</para>
<para>If you don't want any traffic to be dropped, set this to a
value to zero in which case Shorewall will not create an ingress
qdisc.</para>
<para>Use kbit or kbps(for Kilobytes per second) for speed, and make
sure there is NO space between the number and the unit.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">OUT-BANDWIDTH</emphasis></term>
<listitem>
<para>The outgoing Bandwidth of that interface. This is the maximum
speed you connection can handle. It is also the speed you can refer
as "full" if you define the tc classes. Outgoing traffic above this
rate will be dropped.</para>
<para> Use kbit or kbps(for Kilobytes per second) for speed, and
make sure there is NO space between the number and the unit.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Examples</title>
<variablelist>
<varlistentry>
<term>Example 1:</term>
<listitem>
<para>Suppose you are using PPP over Ethernet (DSL) and ppp0 is the
interface for this. The device has an outgoing bandwidth of 500kbit
and an incoming bandwidth of 6000kbit</para>
<programlisting> #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH
ppp0 6000kbit 500kbit
</programlisting>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>FILES</title>
<para>/etc/shorewall/tcdevices</para>
</refsect1>
<refsect1>
<title>See ALSO</title>
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
shorewall-ipsec(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), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
</refsect1>
</refentry>

478
manpages/shorewall-tcrules.xml Normal file
View File

@ -0,0 +1,478 @@
<?xml version="1.0" encoding="UTF-8"?>
<refentry>
<refmeta>
<refentrytitle>shorewall-tcrules</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>tcrules</refname>
<refpurpose>Shorewall Packet Marking rules file</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>/etc/shorewall/</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 shorewall-rules(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/shorewall/providers be sure to read the restrictions at
http://shorewall.net/MultiISP.html.</para>
</important>
<para>The columns in the file are as follows.</para>
<variablelist>
<varlistentry>
<term><emphasis role="bold">MARK/CLASSIFY</emphasis></term>
<listitem>
<orderedlist numeration="loweralpha">
<listitem>
<para>A mark value 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 ("&amp;"), will be logically ANDed with the
current mark value to produce a new mark value.</para>
<para>Both "|" and "&amp;" require Extended MARK Target support
in your kernel and iptables; neither may be used with connection
marks (see below).</para>
<para>If HIGH_ROUTE_MARKS=Yes in shorewall.conf 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">:F</emphasis> or you have set
MARK_IN_FORWARD_CHAIN=Yes in shorewall conf and have not
followed the value with :P) or the OUTPUT chain (SOURCE is
<emphasis role="bold">$FW</emphasis>).</para>
<para>May optionally be followed by <emphasis
role="bold">:P</emphasis> or <emphasis role="bold">:F</emphasis>
where<emphasis role="bold"> :P</emphasis> indicates that marking
should occur in the PREROUTING chain and <emphasis
role="bold">:F</emphasis> indicates that marking should occur in
the FORWARD chain. If neither <emphasis
role="bold">:P</emphasis> nor <emphasis
role="bold">:F</emphasis> follow the mark value then the chain
is determined by the setting of MARK_IN_FORWARD_CHAIN in
shorewall.conf(5).</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 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
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>
</variablelist>
</listitem>
<listitem>
<para>A classification (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 marking occurs in the OUTPUT chain.</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 iptables must include
CONNMARK support.</para>
<para>As in a) above, may be followed by <emphasis
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>
<para>As in a) above, may be followed by <emphasis
role="bold">:P</emphasis> or <emphasis
role="bold">:F</emphasis></para>
</listitem>
<listitem>
<para><emphasis role="bold">CONTINUE</emphasis> Don't process
any more marking rules in the table.</para>
<para>As in a) above, may be followed by <emphasis
role="bold">:P</emphasis> or <emphasis
role="bold">:F</emphasis></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>shorewall
show mangle</command> </para>
<para>To stop the comment from being attached to further rules,
simply include COMMENT on a line by itself.</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">SOURCE</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:192.168.1.0/24). 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 MARK 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>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">DEST</emphasis></term>
<listitem>
<para>Destination of the packet. Comma separated list of IP
addresses and/or subnets. If your kernel and iptables 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:192.168.1.0/24). If the <emphasis
role="bold">MARK</emphasis> column specificies a classification of
the form <emphasis>major</emphasis>:<emphasis>minor</emphasis> then
this column may also contain an interface name. </para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">PROTO</emphasis></term>
<listitem>
<para>Protocol - Must be <emphasis role="bold">tcp</emphasis>,
<emphasis role="bold">udp</emphasis>, <emphasis
role="bold">icmp</emphasis>, <emphasis
role="bold">ipp2p</emphasis>,<emphasis role="bold">
ipp2p:udp</emphasis>, <emphasis role="bold">ipp2p:all</emphasis> a
<emphasis>number</emphasis>, or <emphasis
role="bold">all</emphasis>. <emphasis role="bold">ipp2p</emphasis>
requires ipp2p match support in your kernel and iptables.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">PORT(S)</emphasis></term>
<listitem>
<para> 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">icmp</emphasis>, this column is interpreted as the
destination icmp-type(s).</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>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>
<term><emphasis role="bold">SOURCE PORT(S)</emphasis>
(Optional)</term>
<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>
<term><emphasis role="bold">USER</emphasis></term>
<listitem>
<para>This column may only be non-empty if the SOURCE is the
firewall itself.</para>
<para>The column may contain:</para>
<para>[!][<emphasis>user name or number</emphasis>][:<emphasis>group
name or number</emphasis>][+<emphasis>program
name</emphasis>]</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>
<term>TEST</term>
<listitem>
<para> Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true. Tests have the format
</para>
<para>[<emphasis
role="bold">!</emphasis>]<emphasis>value</emphasis>[/<emphasis>mask</emphasis>][<emphasis
role="bold">:C</emphasis>]</para>
<para>Where:</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>
<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>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">LENGTH</emphasis> (Optional)</term>
<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>
<term><emphasis role="bold">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>
</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>
<para>We assume packet/connection mark 0 to means
unclassified.</para>
<programlisting> #MARK/ SOURCE DEST PROTO PORT(S) SOURCE USER TEST
#CLASSIFY PORT(S)
1 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0
CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0
4 0.0.0.0/0 0.0.0.0/0 ipp2p:all
SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0</programlisting>
<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>
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
shorewall-ipsec(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), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
</refsect1>
</refentry>