# # 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 # : where and 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. # 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 : 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 : # # []:[][+] # # 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 [!][/][:C] # # Where: # # ! Inverts the test (not equal) # Value of the packet or connection mark. # 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/MultiISP.html ############################################################################### #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH # PORT(S) #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE