shorewall_code/Shorewall/tcrules

#
# 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".
#
#                       e) 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		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