Provided by: shorewall-common_4.0.15-1_all bug

NAME

       tcrules - Shorewall Packet Marking rules file

SYNOPSIS

       /etc/shorewall/

DESCRIPTION

       Entries in this file cause packets to be marked as a means of
       classifying them for traffic control or policy routing.

       Important
       Unlike rules in the shorewall-rules[1](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.

       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.

       The columns in the file are as follows.

       MARK/CLASSIFY -
       {value|major:minor|RESTORE[/mask]|SAVE[/mask]|CONTINUE|COMMENT}[:{C|F|P|T|CF|CP|CT}]
           May assume one of the following values.

            1.  A mark value which is an integer in the range 1-255.

               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.

               Both "|" and "&" require Extended MARK Target support in your
               kernel and iptables; neither may be used with connection marks
               (see below).

               May optionally be followed by :P, :F or :T where :P indicates
               that marking should occur in the PREROUTING chain, :F indicates
               that marking should occur in the FORWARD chain and :T indicates
               that marking should occur in the POSTROUTING chain. If neither
               :P, :F nor :T follow the mark value then the chain is
               determined as follows:

               - If the SOURCE is
               $FW[:address-or-range[,address-or-range]...], then the rule is
               inserted into the OUTPUT chain.

               - Otherwise, the chain is determined by the setting of
               MARK_IN_FORWARD_CHAIN in shorewall.conf[2](5).

               If your kernel and iptables include CONNMARK support then you
               can also mark the connection rather than the packet.

               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:+

               C
                   Mark the connection in the chain determined by the setting
                   of MARK_IN_FORWARD_CHAIN

               CF
                   Mark the connection in the FORWARD chain

               CP
                   Mark the connection in the PREROUTING chain.

               CT
                   Mark the connecdtion in the POSTROUTING chain

               Special considerations for If HIGH_ROUTE_MARKS=Yes in
               shorewall.conf[2](5).

               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 :P or you have set MARK_IN_FORWARD_CHAIN=No in
               shorewall.conf[2](5) and have not followed the value with :F)
               or the OUTPUT chain (SOURCE is $FW). With HIGH_ROUTE_MARKS=Yes,
               non-zero mark values less that 256 are not permitted. Shorewall
               4.1 and later versions prohibit 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.

            2.  A classification Id (classid) of the form major:minor where
               major and minor are integers. Corresponds to the ´class´
               specification in these traffic shaping modules:

                          atm
                          cbq
                          dsmark
                          pfifo_fast
                          htb
                          prio
               Classification occurs in the POSTROUTING chain except when the
               SOURCE is $FW[:address] in which case classification occurs in
               the OUTPUT chain.

               When using Shorewall´s built-in traffic shaping tool, the major
               class is the device number (the first device in
               shorewall-tcdevices[3](5) is major class 1, the second device
               is major class 2, and so on) and the minor class is the class´s
               MARK value in shorewall-tcclasses[4](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.).

            3.  RESTORE[/mask] -- restore the packet´s mark from the
               connection´s mark using the supplied mask if any. Your kernel
               and iptables must include CONNMARK support.

               As in 1) above, may be followed by :P or :F

            4.  SAVE[/mask] -- save the packet´s mark to the connection´s mark
               using the supplied mask if any. Your kernel and iptables must
               include CONNMARK support.

               As in 1) above, may be followed by :P or :F

            5.  CONTINUE Don´t process any more marking rules in the table.

               As in 1) above, may be followed by :P or :F. Currently,
               CONTINUE may not be used with exclusion (see the SOURCE and
               DEST columns below); that restriction will be removed when
               iptables/Netfilter provides the necessary support.

            6.  COMMENT -- 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 shorewall show mangle

               To stop the comment from being attached to further rules,
               simply include COMMENT on a line by itself.

       SOURCE -
       {-|{interface|$FW}|[{interface|$FW}:]address-or-range[,address-or-range]...}[exclusion]
           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.

           Accordingly, use $FW in its own separate rule for packets
           originating on the firewall. In such a rule, the MARK column may
           NOT specify either :P or :F because marking for firewall-originated
           packets always occurs in the OUTPUT chain.

           MAC addresses must be prefixed with "~" and use "-" as a separator.

           Example: ~00-A0-C9-15-39-78

           You may exclude certain hosts from the set already defined through
           use of an exclusion (see shorewall-exclusion[5](5)).

       DEST -
       {-|{interface|[interface:]address-or-range[,address-or-range]...}[exclusion]
           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 MARK column specificies a
           classification of the form major:minor then this column may also
           contain an interface name.

           You may exclude certain hosts from the set already defined through
           use of an exclusion (see shorewall-exclusion[5](5)).

       PROTO -
       {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}
           Protocol - ipp2p requires ipp2p match support in your kernel and
           iptables.

       PORT(S) (Optional) -
       [-|port-name-number-or-range[,port-name-number-or-range]...]
           Destination Ports. A comma-separated list of Port names (from
           services(5)), port numbers or port ranges; if the protocol is icmp,
           this column is interpreted as the destination icmp-type(s).

           If the protocol is ipp2p, this column is interpreted as an ipp2p
           option without the leading "--" (example bit for bit-torrent). If
           no PORT is given, ipp2p is assumed.

           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 "-"

       SOURCE PORT(S) (Optional) -
       [-|port-name-number-or-range[,port-name-number-or-range]...]
           Source port(s). If omitted, any source port is acceptable.
           Specified as a comma-separated list of port names, port numbers or
           port ranges.

       USER (Optional) -
       [!][user-name-or-number][:group-name-or-number][+program-name]
           This column may only be non-empty if the SOURCE is the firewall
           itself.

           When this column is non-empty, the rule applies only if the program
           generating the output is running under the effective user and/or
           group specified (or is NOT running under that id if "!" is given).

           Examples:

           joe
               program must be run by joe

           :kids
               program must be run by a member of the ´kids´ group

           !:kids
               program must not be run by a member of the ´kids´ group

           +upnpd
               #program named upnpd

               Important
               The ability to specify a program name was removed from
               Netfilter in kernel version 2.6.14.

       TEST - [!]value[/mask][:C]
           Defines a test on the existing packet or connection mark. The rule
           will match only if the test returns true.

           If you don´t want to define a test but need to specify anything in
           the following columns, place a "-" in this field.

           !
               Inverts the test (not equal)

           value
               Value of the packet or connection mark.

           mask
               A mask to be applied to the mark before testing.

           :C
               Designates a connection mark. If omitted, the packet mark´s
               value is tested.

       LENGTH (Optional) - [length|[min]:[max]]
           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 min:max where either min or max (but not both) may be
           omitted. If min is omitted, then 0 is assumed; if max is omitted,
           than any packet that is min or longer will match.

       TOS - tos
           Type of service. Either a standard name, or a numeric value to
           match.

                        Minimize-Delay (16)
                        Maximize-Throughput (8)
                        Maximize-Reliability (4)
                        Minimize-Cost (2)
                        Normal-Service (0)

EXAMPLE

       Example 1:
           Mark all ICMP echo traffic with packet mark 1. Mark all peer to
           peer traffic with packet mark 4.

           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.

           We assume packet/connection mark 0 means unclassified.

                      #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
           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.

FILES

       /etc/shorewall/tcrules

SEE ALSO

       http://shorewall.net/traffic_shaping.htm

       http://shorewall.net/MultiISP.html

       http://shorewall.net/PacketMarking.html

       shorewall(8), shorewall-accounting(5), shorewall-actions(5),
       shorewall-blacklist(5), shorewall-ecn(5), shorewall-exclusion(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)

NOTES

        1. shorewall-rules
           shorewall-rules.html

        2. shorewall.conf
           shorewall.conf.html

        3. shorewall-tcdevices
           shorewall-tcdevices.html

        4. shorewall-tcclasses
           shorewall-tcclasses.html

        5. shorewall-exclusion
           shorewall-exclusion.html

                                  12/15/2008              SHOREWALL-TCRULES(5)