forked from extern/shorewall_code
2617133c03
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4630 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
261 lines
9.4 KiB
Plaintext
261 lines
9.4 KiB
Plaintext
#
|
|
# Shorewall version 3.3 - 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/MultiISP.html.
|
|
#
|
|
# Columns are:
|
|
#
|
|
#
|
|
# MARK/ a) A mark value which is an integer in the range 1-255.
|
|
# CLASSIFY
|
|
# 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).
|
|
#
|
|
# 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 :F 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 $FW).
|
|
#
|
|
# 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
|
|
#
|
|
# Classification occurs in the POSTROUTING chain except
|
|
# when the SOURCE is $FW[:<address>] in which case
|
|
# marking occurs in the OUTPUT 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.
|
|
# 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
|
|
#
|
|
# 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. 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.
|
|
#
|
|
# 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.
|
|
# 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.
|
|
#
|
|
# Examples: 1024, 64:1500, :100 (packet of length
|
|
# 100 bytes or less)
|
|
#
|
|
# If you don't want to define a test but need to specify
|
|
# anything in the following columns, place a "-" in this
|
|
# field.
|
|
#
|
|
# 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 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/MultiISP.html
|
|
###############################################################################
|
|
#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH TOS
|
|
# PORT(S)
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
|