shorewall_code/Shorewall/tcrules
2006-02-10 15:46:19 +00:00

218 lines
7.6 KiB
Plaintext
Executable File

#
# Shorewall version 3.2 - Tcrules File
#
# /etc/shorewall/tcrules
#
# Entries in this file cause packets to be marked as a means of
# classifying them for traffic control or policy routing.
#
# I M P O R T A N T ! ! ! !
#
# Unlike rules in the /etc/shorewall/rules 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/Shorewall_and_Routing.html.
#
# Columns are:
#
#
# MARK/ a) A mark value which is an integer in the range 1-255
# CLASSIFY
# May optionally be followed by ":P" or ":F"
# where ":P" indicates that marking should occur in
# the PREROUTING chain and ":F" indicates that marking
# should occur in the FORWARD chain. If neither
# ":P" nor ":F" follow the mark value then the chain
# is determined by the setting of
# MARK_IN_FORWARD_CHAIN in
# /etc/shorewall/shorewall.conf.
#
# 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.
#
# b) A classification (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
#
# Classify always occurs in the POSTROUTING chain.
#
# c) 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 a) above, may be followed by ":P" or ":F
#
# c) 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 a) above, may be followed by ":P" or ":F
#
# d) CONTINUE -- don't process any more marking rules in
# the table.
#
# As in a) above, may be followed by ":P" or ":F".
#
# SOURCE 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.
# 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
# DEST 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.
#
# If the MARK column specificies a classification of
# the form <major>:<minor> then this column may also
# contain an interface name.
#
# PROTO Protocol - Must be "tcp", "udp", "icmp", "ipp2p",
# "ipp2p:udp", "ipp2p:all" a number, or "all".
# "ipp2p" requires ipp2p match support in your kernel
# and iptables.
#
# PORT(S) Destination Ports. A comma-separated list of Port
# names (from /etc/services), 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) 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 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.
#
# It may contain :
#
# [<user name or number>]:[<group name or number>][+<program name>]
#
# The colon is optionnal when specifying only a user
# or a program name.
# Examples : john: , john , :users , john:users ,
# +mozilla-bin (Support for program names
# was removed from Netfilter in Kernel
# version 2.6.14).
#
# TEST Defines a test on the existing packet or connection
# mark. The rule will match only if the test returns
# true. Tests have the format [!]<value>[/<mask>][:C]
#
# Where:
#
# ! 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.
#
# If you don't want to define a test but need to specify
# anything in the following columns, place a "-" in this
# field.
#
# LENGTH (Optional) 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. If you let
# it empy or place an "-" here, no length match will be
# done.
#
# Examples: 1024, 64:1500
#
# 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 to means unclassified.
#
# 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."
#
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
# For usage in selecting among multiple ISPs, see
# http://shorewall.net/Shorewall_and_Routing.html
###############################################################################
#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH
# PORT(S)
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE