shorewall_code/Shorewall/releasenotes.txt

Shorewall 4.4.0

----------------------------------------------------------------------------
               R E L E A S E  4 . 4  H I G H L I G H T S
----------------------------------------------------------------------------

1)  Support for Shorewall-shell has been discontinued. Shorewall-perl
    has been combined with Shorewall-common to produce a single
    Shorewall package.

2)  Support for the "Hierarchical Fair Service Curve" (HFSC) queuing
    discipline has been added. HFSC is superior to the "Hierarchical
    Token Bucket" queuing discipline where realtime traffic such as
    VOIP is being used.

3)  Support for the "flow" traffic classifier has been added. This
    classifier can help prevent multi-connection applications such as
    BitTorrent from using an unfair amount of bandwidth.

4)  The Shorewall documentation and man pages have been purged of
    information about earlier Shorewall releases. The documentation
    describes only the behavior of Shorewall 4.4 and later versions.

5)  The interfaces file OPTIONs have been extended to largely remove the
    need for the hosts file.

6)  It is now possible to define PREROUTING and OUTPUT marking rules
    that cause new connections to use the same provider as an existing
    connection of the same kind.

7)  Dynamic Zone support is once again available for IPv4; ipset support is
    required in your kernel and in iptables.

8)  A new AUTOMAKE option has been added to shorewall.conf and
    shorewall6.conf. Setting this option will allow Shorewall to skip
    the compilation phase during start/restart if no configuration
    changes have occurred since the last start/restart.

9)  The LIMIT:BURST column in /etc/shorewall/policy
    (/etc/shorewall6/policy) and the RATE LIMIT column in
    /etc/shorewall/rules (/etc/shorewall6/rules) may now be used to
    limit on a per source IP or per destination IP basis.

10) Support for per-IP traffic shaping classes has been added.

----------------------------------------------------------------------------
                    M I G R A T I O N   I S S U E S
----------------------------------------------------------------------------
1)  If you are currently using Shorewall-shell:

    a) In shorewall.conf, if you have specified
       "SHOREWALL_COMPILER=shell" then you must either:

       -  change that specification to "SHOREWALL_COMPILER=perl"; or
       -  change that specification to "SHOREWALL_COMPILER="; or
       -  delete the specification altogether.

       Failure to do so will result in the following warning:

       WARNING: SHOREWALL_COMPILER=shell ignored. Shorewall-shell
                support has been removed in this release.

    b) Review the incompatibilities between Shorewall-shell and
       Shorewall-perl at
       http://www.shorewall.net/Shorewall-perl.html#Incompatibilities
       and make changes to your configuration as necessary.

2)  The 'shorewall stop', 'shorewall clear', 'shorewall6 stop' and
    'shorewall6 clear' commands no longer read the 'routestopped'
    file. The 'routestopped' file used is the one that was present at
    the last 'start', 'restart' or 'restore' command.

    IMPORTANT: If you modify the routestopped file, you must restart
    Shorewall before the changes to that file take effect.

3)  The old macro parameter syntax (e.g., SSH/ACCEPT) is now deprecated
    in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.4 documentation
    uses the new syntax exclusively, although the old syntax
    continues to be supported.

    The sample configuration also use the new syntax.

4)  Support for the SAME target in /etc/shorewall/masq and
    /etc/shorewall/rules has been removed, following the removal of the
    underlying support in the Linux kernel.

5)  Supplying an interface name in the SOURCE column of
    /etc/shorewall/masq is now deprecated. Entering the name of an
    interface there will result in a compile-time warning:

    WARNING: Using an interface as the masq SOURCE requires the
             interface to be up and configured when Shorewall
             starts/restarts

    To avoid this warning, replace interface names by the corresponding
    network addresses (e.g., 192.168.144.0/24).

6)  Previously, Shorewall has treated traffic shaping class IDs as
    decimal numbers (or pairs of decimal numbers). That worked fine
    until IPMARK was implemented. IPMARK requires Shorewall to generate
    class Ids in numeric sequence. In 4.3.9, that didn't work correctly
    because Shorewall was generating the sequence "..8,9,10,11..." when
    the correct sequence was "...8,9,a,b,...". Shorewall now treats
    class IDs as hex, as do 'tc' and 'iptables'.

    This should only be an issue if you have more than 9 interfaces
    defined in /etc/shorewall/tcdevices and if you use class IDs in
    /etc/shorewall/tcrules or /etc/shorewall/tcfilters. You will need
    to renumber the class IDs for devices 10 and greater.

7)  Support for the 'norfc1918' interface and host option has been
    removed. If 'norfc1918' is specified for an entry in either the
    interfaces or the hosts file, a warning is issued and the option is
    ignored. Simply remove the option to avoid the warning.

    Similarly, if RFC1918_STRICT=Yes or a non-empty RFC1918_LOG_LEVEL
    is given in shorewall.conf, a warning will be issued and the option
    will be ignored.

    You may simply delete the RFC1918-related options from your
    shorewall.conf file if you are seeing warnings regarding them.

    Users who currently use 'norfc1918' are encouraged to consider
    using NULL_ROUTE_RFC1918=Yes instead.

8)  The install.sh scripts in the Shorewall and Shorewall6 packages no
    longer create a backup copy of the existing configuration. If you
    want your configuration backed up prior to upgrading, you will
    need to do that yourself. 

    As part of this change, the fallback.sh scripts are no longer
    released.

9)  In earlier releases, if an ipsec zone was defined as a sub-zone of
    an ipv4 or ipv6 zone using the special <child>:<parent>,... syntax,
    CONTINUE policies for the sub-zone did not work as
    expected. Traffic that was not matched by a sub-zone rule was not
    compared against the parent zone(s) rules.

    In 4.4.0, such traffic IS compared against the parent zone rules.

10) The name 'any' is now reserved and may not be used as a zone name.

----------------------------------------------------------------------------
          P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 0
----------------------------------------------------------------------------

1)  When compiling to standard out, it is no longer necessary to
    specify '-v-1' to suppress the 'Compiling...' progress message 

2)  Previously, Shorewall would generate invalid iptables-restore input
    if all of these conditions were met:

    - a nat rule (DNAT, REDIRECT, DNAT-, etc.) changed the destination
      port number
    - logging was specified on the rule
    - no non-trivial exclusions in the rule (a non-trivial exclusion is
      one whose exclusion list has more than one element)

    Example of rule:

    	    REDIRECT:ULOG   wall    82      tcp     80

    Example of error message:

       iptables v1.3.5: Need TCP or UDP with port specification
        Try `iptables -h' or 'iptables --help' for more information.
	ERROR: Command "/sbin/iptables -A log0 -j REDIRECT --to-port
        82" Failed

3)  Previously, log displays from the 'dump', 'show log' and 'logwatch'
    commands did not properly suppress redundant fields in the records
    (host name, and leading constant part of the LOGPREFIX).

4)  Given that Jozsef Kadlecsik has not yet released ipset 3.1, ipset
    bindings are once again supported.

----------------------------------------------------------------------------
             K N O W N   P R O B L E M S   R E M A I N I N G
----------------------------------------------------------------------------

None.

----------------------------------------------------------------------------
                 N E W   F E A T U R E S   IN   4 . 4
----------------------------------------------------------------------------

1)  The Shorewall packaging has been completely revamped in Shorewall
    4.4.

    The new packages are:

    - Shorewall.   Includes the former Shorewall-common and
                   Shorewall-perl packages. Has everything needed
                   to create an IPv4 firewall.

    - Shorewall6.  Requires Shorewall. Adds the components necessary to
      		   create an IPv6 firewall.

    - Shorewall-lite

		   May be installed on a firewall system to run
		   IPv4 firewall scripts generated by Shorewall.

    - Shorewall6-lite

		   May be installed on a firewall system to run
		   IPv6 firewall scripts generated by Shorewall6.

2)  The interfaces file supports a new 'nets=' option. This option
    allows users to restrict a zone's definition to particular networks
    through an interface without having to use the hosts file.

    Example interfaces file:

    #ZONE	INTERFACE	BROADCAST		OPTIONS
    loc		eth3		detect			dhcp,logmartians=1,routefilter=1,nets=172.20.1.0/24
    dmz     	eth4		detect			logmartians=1,routefilter=1,nets=206.124.146.177
    net		eth0		detect			dhcp,blacklist,tcpflags,optional,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177)
    net		eth2		detect			dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177)
    loc		tun+		detect			nets=172.20.0.0/24
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

    Note that when more than one network address is listed, the list
    must be enclosed in parentheses. Notice also that exclusion may be
    used.

    The first entry in the above interfaces file is equivalent to the
    following:

    interfaces:

    #ZONE	INTERFACE	BROADCAST		OPTIONS
    -		eth0		detect			dhcp,logmartians=1,routefilter=1

    hosts:

    #ZONE	HOST(S)					OPTIONS
    loc		$INT_IF:192.20.1.0/24			broadcast

    Note that the 'broadcast' option is automatically assumed and need
    not be explicitly specified.

3)  Some websites run applications that require multiple connections
    from a client browser. Where multiple 'balanced' providers are
    configured, this can lead to problems when some of the connections
    are routed through one provider and some through another.

    To work around this issue, the SAME target has been added to
    /etc/shorewall/tcrules. SAME may be used in the PREROUTING and
    OUTPUT chains. When used in PREROUTING, it causes matching
    connections from an individual local system to all use the same
    provider.

    For example:

    	SAME:P	192.168.1.0/24	-	tcp	80,443

    If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or
    443 and it has sent a packet on either of those ports in the last
    five minutes then the new connection will use the same provider as
    the connection over which that last packet was sent.

    When used in the OUTPUT chain, it causes all matching connections
    to an individual remote system to all use the same provider.

    For example:

    	SAME	$FW	-	tcp	80,443

    If the firewall attempts a connection on TCP port 80 or
    443 and it has sent a packet on either of those ports in the last
    five minutes to the same remote system then the new connection will
    use the same provider as the connection over which that last packet
    was sent.

    Important note: SAME only works with providers that have the
    'track' option specified in /etc/shorewall/providers.

4)  The file /var/lib/shorewall/.restore has been renamed to
    /var/lib/shorewall/firewall. A similar change has been made in
    Shorewall6.

    When a successful start or restart is completed, the script that
    executed the command copies itself to
    /var/lib/shorewall[6]/firewall.

5)  Dynamic zone support is once again available for IPv4. This support 
    is built on top of ipsets so you must have the xtables-addons
    installed on the firewall system.

    Dynamic zones are available when Shorewall-lite is used as well.

    You define a zone as having dynamic content in one of two ways:

    - By specifying nets=dynamic in the OPTIONS column of an entry for
      the zone in /etc/shorewall/interfaces; or

    - By specifying <interface>:dynamic in the HOST(S) column of an
      entry for the zone in /etc/shorewall/hosts.

    When there are any dynamic zones present in your configuration, 
    Shorewall (Shorewall-lite) will:

    a) Execute the following commands during 'shorewall start' or
       'shorewall-lite start'.

           ipset -U :all: :all:
	   ipset -U :all: :default:
	   ipset -F
	   ipset -X   
	   ipset -R < ${VARDIR}/ipsets.save

       where $VARDIR normally contains /var/lib/shorewall
       (/var/lib/shorewall-lite) but may be modified by
       /etc/shorewall/vardir (/etc/shorewall-lite/vardir).

    b) During 'start', 'restart' and 'restore' processing, Shorewall
       will then attempt to create an ipset named <zone>_<interface>
       for each zone/interface pair that has been specified as
       dynamic. The type of ipset created is 'iphash' so that only
       individual IPv4 addresses may be added to the set.

    c) Execute the following commands during 'shorewall stop' or
       'shorewall-lite stop':

           if ipset -S > ${VARDIR}/ipsets.tmp; then
              mv -f ${VARDIR}/ipsets.tmp ${VARDIR}/ipsets.save
	   fi

    The 'shorewall add' and 'shorewall delete' commands are supported
    with their original syntax:

           add <interface>[:<host-list>] ... <zone>

           delete <interface>[:<host-list>] ... <zone>

    In addition, the 'show dynamic' command is added that lists the dynamic
    content of a zone.

    	    show dynamic <zone>

    These commands are supported by shorewall-lite as well.

6)  The generated program now attempts to detect all dynamic
    information when it first starts. If any of those steps fail, an
    error message is generated and the state of the firewall is not
    changed.

7)  To improve readability of the configuration files, Shorewall now
    allows leading white space in continuation lines when the continued
    line ends in ":" or ",".

    Example (/etc/shorewall/rules):

    #ACTION	SOURCE		DEST		PROTO		DEST
    #                                                           PORT(S)
    ACCEPT	net:\
    		206.124.146.177,\
		206.124.146.178,\
		206.124.146.180\
				dmz		tcp		873

    The leading white space on the lines that contain just an IP
    address is ignored so the SOURCE column effectively contains
    "net:206.124.146.177,206.124.147.178,206.124.146.180".

8)  The generated script now uses iptables[6]-restore to instantiate
    the Netfilter ruleset during processing of the 'stop' command. As a
    consequence, the 'critical' option in /etc/shorewall/route_stopped
    is no longer needed and will result in a warning.

9)  A new AUTOMAKE option has been added to shorewall.conf and
    shorewall6.conf. When set to 'Yes', this option causes new behavior
    during processing of the 'start' and 'restart' commands; if no
    files in /etc/shorewall/ (/etc/shorewall6) have changed since the last
    'start' or 'restart', then the compilation step is skipped and the
    script used during the last 'start' or 'restart' is used to
    start/restart the firewall.

    Note that if a <directory> is specified in the start/restart
    command (e.g., "shorewall restart /etc/shorewall.new") then the
    setting of AUTOMAKE is ignored.

    Note that the 'make' utility must be installed on the firewall
    system in order for AUTOMAKE=Yes to work correctly.

10) The 'compile' command now allows you to omit the <pathname>. When
    you do that, the <pathname> defaults to /var/lib/shorewall/firewall
    (/var/lib/shorewall6/firewall) unless you have overridden VARDIR
    using /etc/shorewall/vardir (/etc/shorewall6/vardir).

    When combined with AUTOMAKE=Yes, it allows the following:

    	 gateway:~ # shorewall compile
    	 Compiling...
    	 Shorewall configuration compiled to /root/shorewall/firewall
    	 gateway:~ #
	 ...
    	 gateway:~ # shorewall restart
    	 Restarting Shorewall....
    	 done.
    	 gateway:~ # 

    In other words, you can compile the current configuration then
    install it at a later time.

11) Thanks to I. Buijs, it is now possible to rate-limit connections by
    source IP or destination IP. The LIMIT:BURST column in
    /etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT
    column /etc/shorewall/rules (/etc/shorewall6/rules) have been
    extended as follows:

    	[{s|d}:[[<name>]:]]<rate>/{sec|min}[:<burst>]

    When s: is specified, the rate is per source IP address.
    When d: is specified, the rate is per destination IP address.
    The <name> specifies the name of a hash table -- you get to choose
    the name. If you don't specify a name, the name 'shorewall' is
    assumed. Rules with the same name have their connection counts
    aggregated and the individual rates are applied to the aggregate.

    Example:

	ACCEPT	net   fw    tcp    22  - - s:ssh:3/min

    This will limit SSH connections from net->fw to 3 per minute.

    	ACCEPT	net   fw    tcp    25   - - s:mail:3/min
    	ACCEPT	net   fw    tcp    587  - - s:mail:3/min

    Since the same hash table name is used in both rules, the above is
    equivalent to this single rule:

    	ACCEPT	net   fw    tcp    25,587  - - s:mail:3/min

12) Rules that specify a log level with a target other than LOG or NFLOG
    are now implemented through a separate chain. While this may increase
    the processing cost slightly for packets that match these rules, it
    is expected to reduce the overall cost of such rules because each
    packet that doesn't match the rules only has to be processed once
    per rule rather than twice.

    Example:

    /etc/shorewall/rules:

	REJECT:info   loc       net      tcp    25

    This previously generated these two rules (long rules folded):

	 -A loc2net -p 6 --dport 25 -j LOG --log-level 6
	    --log-prefix "Shorewall:loc2net:reject:" 
	 -A loc2net -p 6 --dport 25 -j reject 

    It now generates these rules:

       	 :log0 - [0:0]
	 ...
	 -A loc2net -p 6 --dport 25 -g log0
	 ...
	 -A log0 -j LOG --log-level 6
	    --log-prefix "Shorewall:loc2net:REJECT:" 
	 -A log0 -p 6 --dport 25 -j reject 

    Notice that now there is only a single rule generated in the
    'loc2net' chain where before there were two. Packets for other than

    TCP port 25 had to be processed by both rules.

    Notice also that the new LOG rule reflects the original action
    ("REJECT") rather than what Shorewall maps that to ("reject").

13) Shorewall6 has now been tested on kernel 2.6.24 (Ubuntu Hardy) and
    hence will now start successfully when running on that kernel.

14) Three new options (IP, TC and IPSET) have been added to
    shorewall.conf and shorwall6.conf. These options specify the name
    of the executable for the 'ip', 'tc' and 'ipset' utilities
    respectively.

    If not specified, the default values are:

       IP=ip
       TC=tc
       IPSET=ipset

    In other words, the utilities will be located via the current PATH
    setting.

15) There has been a desire in the user community to limit traffic by
    IP address using Shorewall traffic shaping. Heretofore, that has
    required a very inefficient process:

    a) Define a tcclass for each internal host (two, if shaping both in
       and out).
    b) Define a tcrule for each host to mark to classify the packets
       accordingly.

    Beginning with Shorewall 4.4, this process is made easier IF YOU
    ARE WILLING TO INSTALL xtables-addons. The feature requires IPMARK
    support in iptables[6] and your kernel. That support is available
    in xtables-addons.

    Instructions for installing xtables-addons may be found at
    http://www.shorewall.net/Dynamic.html#xtables-addons.

    The new facility has two components:

    a) A new IPMARK MARKing command in /etc/shorewall/tcrules.
    b) A new 'occurs' OPTION in /etc/shorewall/tcclasses.

    The facility is currently only available with IPv4.

    In a sense, the IPMARK target is more like an IPCLASSIFY target in
    that the mark value is later interpreted as a class ID. A packet
    mark is 32 bits wide; so is a class ID. The <major> class occupies
    the high-order 16 bits and the <minor> class occupies the low-order
    16 bits. So the class ID 1:4ff (remember that class IDs are always
    in hex) is equivalent to a mark value of 0x104ff. Remember that
    Shorewall uses the interface number as the <major> number where the
    first interface in tcdevices has <major> number 1, the second has
    <major> number 2, and so on.

    The IPMARK target assigns a mark to each matching packet based on
    the either the source or destination IP address. By default, it
    assigns a mark value equal to the low-order 8 bits of the source
    address.

    The syntax is as follows:

	IPMARK[([{src|dst}][,[<mask1>][,[<mask2>][,[<shift>]]]])]

    Default values are:

	    src
	    <mask1> = 0xFF
	    <mask2> = 0x00
	    <shift> = 0

     'src' and 'dst' specify whether the mark is to be based on the
     source or destination address respectively.

     The selected address is first shifted right by <shift>, then
     LANDed with <mask1> and then LORed with <mask2>. The <shift>
     argument is intended to be used primarily with IPv6 addresses.

     Example:

	IPMARK(src,0xff,0x10100)

        Destination IP address is 192.168.4.3 = 0xc0a80403

	0xc0a80403 >> 0         = 0xc0a80403
	0xc0a80403 LAND 0xFF    = 0x03
	0x03       LOR  0x10100 = 0x10103

	So the mark value is 0x10103 which corresponds to class id
	1:103.

    It is important to realize that, while class IDs are composed of a
    <major> and a <minor> value, the set of <minor> values must be
    unique. You must keep this in mind when deciding how to map IP
    addresses to class IDs. 

    For example, suppose that your internal network is 192.168.1.0/29
    (host IP addresses 192.168.1.1 - 192.168.1.6). Your first notion
    might be to use IPMARK(src,0xFF,0x10000) so as to produce class IDs
    1:1 through 1:6. But 1:1 is the class ID if the base HTB class on
    interface 1. So you might chose instead to use
    IPMARK(src,0xFF,0x10100) as shown in the example above so as to
    avoid minor class 1.

    The 'occurs' option in /etc/shorewall/tcclasses causes the class
    definition to be replicated many times. The synax is:

	 occurs=<number>

    When 'occurs' is used:

	 a) The associated device may not have the 'classify' option.
	 b) The class may not be the default class.
	 c) The class may not have any 'tos=' options (including
	    'tcp-ack').
	 d) The class should not specify a MARK value. Any MARK value
	    given is ignored with a warning.

    The 'RATE' and 'CEIL' parameters apply to each instance of the
    class. So the total RATE represented by an entry with 'occurs' will
    be the listed RATE multiplied by the 'occurs' number.

    Example:

	/etc/shorewall/tcdevices:

	#INTERFACE     IN-BANDWIDTH     OUT-BANDWIDTH
	eth0	       100mbit		100mbit

	/etc/shorewall/tcclasses:

	#DEVICE   MARK  RATE    CEIL    PRIORITY	OPTIONS
	eth0:101  -	1kbit	230kbit	       4	occurs=6

        The above defines 6 classes with class IDs 0x101-0x106. Each
        class has a guaranteed rate of 1kbit/second and a ceiling of
        230kbit.

	/etc/shoreall/tcrules:

	#MARK                      SOURCE              DEST
	IPMARK(src,0xff,0x10100):F 192.168.1.0/29      eth0

    This change also altered the way in which Shorewall generates a
    class number when none is given.

    - Prior to this change, the class number was constructed by concatinating
      the mark value with the either '1' or '10'. '10' is used when
      there are more than 10 devices defined in /etc/shorewall/tcdevices.

    - Beginning with this change, a new method is added; class numbers
      are assigned sequentially beginning with 2.

    The WIDE_TC_MARKS option in shorewall.conf selects which
    construction to use. WIDE_TC_MARKS=No (the default) produces
    pre-4.4 behavior. WIDE_TC_MARKS=Yes produces the new behavior.

    In addition to determining the method of constructing class Ids,
    WIDE_TC_MARKS=Yes provides for larger mark values for traffic
    shaping. Traffic shaping marks may have values up to 16383 (0x3fff)
    with WIDE_TC_MARKS=Yes. This means that when both WIDE_TC_MARKS=Yes and
    HIGH_ROUTE_MARKS=Yes, routing marks (/etc/shorewall/providers MARK
    column) must be >= 65536 (0x10000) and must be a multiple of 65536
    (0x1000, 0x20000, 0x30000, ...).

16) In the 'shorewall compile' command, the filename '-' now causes
    the compiled script to be written to Standard Out. As a side
    effect, the effective VERBOSITY is set to -1 (silent).

    Examples:

	shorewall compile -- -  # Compile the configuration in
                        	# /etc/shorewall and send the
	                        # output to STDOUT
	shorewall compile . -   # Compile the configuration in the
		  	        # current working directory
		  	    	# and send the output to STDOUT

17) Supplying an interface name in the SOURCE column of
    /etc/shorewall/masq is now deprecated. Entering the name of an
    interface there will result in a compile-time warning.

18) Shorewall now supports nested HTB traffic shaping classes.  The
    nested classes within a class can borrow from their parent class in
    the same way as the first level classes can borrow from the root
    class.

    To use nested classes, you must explicitly number your
    classes. That does not imply that you must use the 'classify'
    option.

    Example:

    /etc/shorewall/tcdevices

    #INTERFACE	IN-BANDWITH	OUT-BANDWIDTH	OPTIONS
    eth2	-		100mbps		classify

    /etc/shorewall/tcclasses

    #INTERFACE	MARK	RATE		CEIL	 PRIORITY	OPTIONS
    1:10	-	full/2		full		1
    1:100	-	16mbit		20mbit		2
    1:100:101	-	 8mbit		20mbit		3	default
    1:100:102	-	 8mbit		20mbit		3
     
    /etc/shorewall/tcrules

    #MARK	SOURCE		DEST
    1:102	0.0.0.0/0	eth2:172.20.1.107
    1:10	206.124.146.177	eth2
    1:10	172.20.1.254	eth2

    The above controls download for internal interface eth2. The
    external interface has a download rate of 20mbit so we guarantee
    that to class 1:100. 1:100 has two subclasses, each of which is
    guaranteed half of their parent's bandwidth.

    Local traffic (that coming from the firewall and from the DMZ
    server) is placed in the effectively unrestricted class 1:10. The
    default class is guaranteed half of the download capacity and my
    work system (172.20.1.107) is guarandeed the other half.
	

19) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing
    discipline has been added. HFSC is superior to the "Hierarchical
    Token Bucket" queuing discipline where realtime traffic such as
    VOIP is being used.

    An excellent overview of HFSC on Linux may be found at
    http://linux-ip.net/articles/hfsc.en/.

    To use HFSC, several changes need to be made to your traffic
    shaping configuration:

    	    - To use HFSC on an interface rather than HTB, specify the
              'hfsc' option in the OPTIONS column in the interfaces's
              entry in /etc/shorewall/tcdevices.

	    - Modify the RATE colum  for each 'leaf' class (class with no
              parent class specified) defined for the interface.

	      When using HFSC, the RATE column may specify 1, 2 or 3
	      pieces of information separated by colons (":").

	      1. The Guaranteed bandwidth (as always).
	      2. The Maximum delay (DMAX) that the first queued packet
	         in the class should experience. The delay is expressed
	         in milliseconds and may be followed by 'ms' (e.g.,
	      	 10ms. Note that there may be no white space between the
	      	 number and 'ms'). 
              3. The maximum transmission unit (UMAX) for this class of
	         traffic. If not specified, the MTU of the interface is
		 used. The length is specified in bytes and may be
	         followed by 'b' (e.g., 800b. Note that there may be no
	         white space between the number and 'b').

              DMAX should be specified for each leaf class. The Shorewall
              compiler will issue a warning if DMAX is omitted.

	      Example:

		 full/2:10ms:1500b

                 Guaranteed bandwidth is 1/2 of the devices
                 OUT-BANDWIDTH. Maximum delay is 10ms. Maximum packet
                 size is 1500 bytes.

20) Optional TOS and LENGTH fields have been added to the tcfilters
    file.

    The TOS field may contain any of the following:

    	tos-minimize-delay
	tos-maximuze-throughput
	tos-maximize-reliability
	tos-minimize-cost
	tos-normal-service
	Hex-number
	Hex-number/Hex-number

    The hex numbers must have exactly two digits.

    The LENGTH value must be a numeric power of two between 32 and 8192
    inclusive. Packets with a total length that is strictly less that
    the specified value will match the rule.

21) Support for 'norfc1918' has been removed. See the Migration
    Considerations above.

22) A 'upnpclient' option has been added to
    /etc/shorewall/interfaces. This option is intended for laptop users
    who always run Shorewall on their system yet need to run
    UPnP-enabled client apps such as Transmission (BitTorrent client).

    The option causes Shorewall to detect the default gateway through
    the interface and to accept UDP packets from that gateway. Note
    that, like all aspects of UPnP, this is a security hole so use this
    option at your own risk.

23) 'iptrace' and 'noiptrace' commands have been added to both
    /sbin/shorewall and /sbin/shorewall6.

    These are low-level debugging commands that cause
    iptables/ip6tables TRACE log messages to be generated. See 'man
    iptables' and 'man ip6tables' for details.

    The syntax for the commands is:

    	iptrace <iptables/ip6tables match expression>
    	noiptrace <iptables/ip6tables match expression>

    iptrace starts the trace; noiptrace turns it off.

    The  match expression must be an expression that is legal in both
    the raw table OUTPUT and PREROUTING chains.

    Examaple:

	To trace all packets destinted for IP address 206.124.146.176:

	   shorewall iptrace -d 206.124.146.176

	To turn that trace off:

	   shorewall noiptrace -d 206.124.146.176

24) A USER/GROUP column has been added to /etc/shorewall/masq. The
    column works similarly to USER/GROUP columns in other Shorewall
    configuration files. Only locally-generated traffic is matched.

25) A new extension script, 'lib.private' has been added. This file is
    intended to include declarations of shell functions that will be
    called by the other run-time extension scripts. 

26) Paul Gear has contributed the following macros:

    	 macro.Webcache (originally named macro.DG)
 	 macro.IPPbrd
 	 macro.NTPbi
 	 macro.RIPbi
	 macro.mDNS

27) The default value of DISABLE_IPV6 has been changed from 'Yes' to
    'No' in all sample shorewall.conf files. Shorewall6 should be
    installed to restrict IPv6 traffic.

    As part of this change, the ip6tables program in the directory
    specified by the IPTABLES setting will be used to disable IPv6. If
    the iptables utility is discovered using the PATH setting, then
    ip6tables in the same directory as the discovered iptables will be
    used.