shorewall_code/Shorewall/releasenotes.txt

----------------------------------------------------------------------------
                      S H O R E W A L L  4 . 4 . 1 9
                                R C  1
----------------------------------------------------------------------------

I.    PROBLEMS CORRECTED IN THIS RELEASE
II.   KNOWN PROBLEMS REMAINING
III.  NEW FEATURES IN THIS RELEASE
IV.   RELEASE 4.4 HIGHLIGHTS
V.    MIGRATION ISSUES
VI.   PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES

----------------------------------------------------------------------------
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E
----------------------------------------------------------------------------

RC 1

None.

Beta 5

1)  Correct a problem whereby incorrect Netfilter rules were generated
    when a bridge with ports was given a logical name.

Beta 4

1)  If a bridge interface had subordinate ports defined in
    /etc/shorewall/interface, then an ipsec entry (either ipsec zone or
    the 'ipsec' option specified) in /etc/shorewall/hosts resulted in
    the compiler generating an incorrect Netfilter configuration.

Beta 3

None.

Beta 2

1)  A correction to the Beta 1 fix for params processing has been
    included.

2)  Editing of ICMP type lists has been improved.

Beta 1

1)  Previously /var/log/shorewall*-init.log was created in the wrong
    Selinux context. The rpm's have been modified to correct that
    issue.

2)  An issue with params processing on RHEL6 has been corrected. The
    problem manifested as the following type of warning:

       WARNING: Param line (export OLDPWD) ignored at 
                /usr/share/shorewall/Shorewall/Config.pm line 2993.

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

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

----------------------------------------------------------------------------
      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E
----------------------------------------------------------------------------

1)  When TC_ENABLED=Simple, ACK packets are now placed in the highest
    priority class. An ACK packet is a TCP packet with the ACK flag set
    and no data payload.

    Rationale: Entries in /etc/shorewall[6]/tcpri affect both incoming
    and outgoing connections. If a particular application, SMTP for
    example, is placed in priority class 3, then outgoing ACK packets
    for incoming email were previously placed in priority class 3 as
    well. This could have the effect of slowing down incoming mail when
    the goal was to give outgoing mail a lower priority. By
    unconditionally placing ACK packets in priority class 1, this issue
    is avoided.

2)  Up to this point, the Perl-based rules compiler has not accepted
    ICMP type lists. This is in contrast to the shell-based compiler
    which did support such lists. 

    Support for ICMP (and ICMPv6) type lists has now been restored.

3)  Distributions have different philosophies about the proper file
    hierarchy. Two issures are particularly contentious:

    - Executable files in /usr/share/shorewall*. These include;

      getparams
      compiler.pl
      wait4ifup
      shorecap
      ifupdown

    - Perl Modules in /usr/share/shorewall/Shorewall.

    To allow distributions to designate alternate locations for these
    files, the installers (install.sh) now support the following
    environmental variables:

    LIBEXEC -- determines where in /usr getparams, compiler.pl,
    wait4ifup, shorecap and ifupdown are installed. Shorewall and
    Shorewall6 must be installed with the same value of LIBEXEC. The
    listed executables are installed in /usr/${LIBEXEC}/shorewall*. The
    default value of LIBEXEC is 'share'. LIBEXEC is recognized by all
    installers and uninstallers.

    PERLLIB -- determines where in /usr the Shorewall perl modules are
    installed. Shorewall and Shorewall6 must be installed with the same
    value of PERLLIB. The modules are installed in
    /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is
    'share/shorewall'. PERLLIB is only recognized by the Shorewall and
    Shorewall6 installers and the same value must be passed to both
    installers.

4)  Bridge/ports handling has been significantly improved, resulting in
    packets to/from bridges traversing fewer rules.

5)  A list of protocols is now permitted in the PROTO column of the
    rules file.

6)  The contents of the Netfilter mangle table are now included in the
    output from 'shorewall show tc'.

7)  When simple traffic shaping is configured, the postrouting marking
    chain 'tcpost' is now exited early if the connection was previously
    marked.

    Note: tcpost is usually deleted by optimization level 4 and its
    rules appear in the POSTROUTING chain.

----------------------------------------------------------------------------
             I V.  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.

    HTB remains the default queuing discipline.

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.

11) Support for netfilter's TRACE facility has been added. TRACE allows
    you to trace selected packets through Netfilter, including marking
    by tcrules.

12) You may now preview the generated ruleset by using the '-r' option
    to the 'check' command (e.g., "shorewall check -r").

13) A new simplified Traffic Shaping facility is now available.

14) Additional ruleset optimization options are available.

15) TPROXY support has been added.

16) Explicit support for Linux-vserver has been added. It is now
    possible to define sub-zones of $FW.

17) A 'Universal' sample configuration is now availale for a
    'plug-and-play' firewall.

----------------------------------------------------------------------------
                   V.  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 migration issues at
       http://www.shorewall.net/LennyToSqueeze.html and make changes as
       required.

    We strongly recommend that you migrate to Shorewall-perl on your
    current Shorewall version before upgrading to Shorewall 4.4.0. That
    way, you can have both Shorewall-shell and Shorewall-perl available
    until you are certain that Shorewall-perl is working correctly for
    you.

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 refresh or
    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 configurations 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(s) in CIDR format (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.

11) Perl module initialization has changed in Shorewall
    4.4.1. Previously, each Shorewall Perl package would initialize its
    global variables for IPv4 in an INIT block. Then, if the
    compilation turned out to be for IPv6,
    Shorewall::Compiler::compiler() would reinitialize them for IPv6.

    Beginning in Shorewall 4.4.1, the modules do not initialize
    themselves in an INIT block. So if you use Shorewall modules
    outside of the Shorewall compilation environment, then you must
    explicitly call the module's 'initialize' function after the module
    has been loaded.

12) Checking for zone membership has been tighened up. Previously,
    a zone could contain <interface>:0.0.0.0/0 along with other hosts;
    now, if the zone has <interface>:0.0.0.0/0 (even with exclusions),
    then it may have no additional members in /etc/shorewall/hosts.

13) ADD_IP_ALIASES=No is now the setting in the released shorewall.conf
    and in all of the samples. This will not affect you during upgrade
    unless you choose to replace your current shorewall.conf with the
    one from the release (not recommended).

14) The names of interface configuration variables in generated scripts
    have been changed to insure uniqueness. These names now begin with
    SW_.

    This change will only affect you if your extension scripts are
    using one or more of these variables.

          Old Variable Name                   New Variable Name
          -----------------------------------------------------
	  iface_ADDRESS                        SW_iface_ADDRESS
	  iface_BCASTS                         SW_iface_BCASTS
	  iface_ACASTS                         SW_iface_ACASTS
	  iface_GATEWAY                        SW_iface_GATEWAY
	  iface_ADDRESSES                      SW_iface_ADDRESSES
	  iface_NETWORKS                       SW_iface_NETWORKS
	  iface_MAC                            SW_iface_MAC

	  provider_IS_USABLE                   SW_provider_IS_USABLE

    where 'iface' is a capitalized interface name (e.g., ETH0) and
    'provider' is the capitalized name of a provider.

15) Support for the OPTIONS column in /etc/shorewall/blacklist
    (/etc/shorewall6/blacklist) has been removed. Blacklisting by
    destination IP address will be included in a later Shorewall
    release.

16) If your /etc/shorewall/params (or /etc/shorewall6/params) file
    sends output to Standard Output, you need to be aware that the
    output will be redirected to Standard Error beginning with
    Shorewall 4.4.16.

17) Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
    deprecated. With EXPORTPARAMS=No, the variables set by
    /etc/shorewall/params (/etc/shorewall6/params) at compile time are
    now available in the compiled firewall script.

----------------------------------------------------------------------------
V I.  P R O B L E M S  C O R R E C T E D  A N D  N E W   F E A T U R E S
      I N   P R I O R  R E L E A S E S
----------------------------------------------------------------------------
         P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 1 8
----------------------------------------------------------------------------

4.4.18 Final

1)  Previously, if an IPv6 host address (no "/<vlsm>") was used in a
    context where a network address is allowed, the compiler failed to
    supply the default <vlsm> of 128. This could lead to startup errors
    and/or Perl errors such as:

    	   Use of uninitialized value $mask in concatenation (.) or
    	   string at /usr/share/shorewall/Shorewall/Tc.pm line 979,
    	   <$currentfile> line 11.

2)  The <burst> option for the IN-BANDWIDTH column of tcdevices was
    previously not recognized. That functionality has been restored.

3)  If an interface mentioned in the tcfilters file was not up when
    Shorewall was started or restarted, then the command would fail
    at run-time with a 'tc' error message.

4.4.18 RC 1

1)  None.

4.4.18 Beta 4

1)  Edting of the MARK column has been tighened to catch errors at
    compile time rather than at run time.

2)  The MODULE_SUFFIX default has been changed to "ko ko.gz o o.gz gz"
    to get the most common suffixes at the front of the list. It is
    still recommended that you modify this setting to include only the
    suffix(es) used on your system. Current distributions use 'ko'
    almost exclusively.

4.4.18 Beta 2

1)  Previously, the 'local' option in /etc/shorewall6/providers would
    produce an 'ip route add' command containing an IPv4 address. It now
    correctly uses the equivalent IPv6 address. Note that this option
    is still undocumented for use with IPv6.

2)  When optimize level 4 was set, the optimizer mis-handled rules of the
    form:

	-A <chain1> -j <chain2> -m comment ...

    when such a rule was the only rule in a chain.

4.4.18 Beta 1

None.

----------------------------------------------------------------------------
               N E W   F E A T U R E S   I N   4 . 4 . 1 8
----------------------------------------------------------------------------

1)  The modules files are now just a driver that INCLUDEs several new
    files and one old file:

    - /usr/share/shorewall[6]/modules.essential  # Essential modules
    - /usr/share/shorewall[6]/modules.xtables    # xt_ modules
    - /usr/share/shorewall[6]/helpers            # Existing file
    - /usr/share/shorewall/ipset                 # ipset modules
    - /usr/share/shorewall[6]/modules.tc         # Traffic Shaping
    - /usr/share/shorewall[6]/modules.extensions # Other extensions

    This should make it easier to configure your own
    /etc/shorewall[6]/modules file that won't be obsolete when you
    upgrade your Shorewall/Shorewall6 installation.

    For example, if you don't use traffic shaping or ipsets, you can
    remove those from your copy of the modules file (copy in
    /etc/shorewall/).

2)  Traditionally, the root of the Shorewall accounting rules has been
    the 'accounting' chain. Having a single root chain has drawbacks:

    - Many rules are traversed needlessly (they could not possibly
      match traffic).
    - At any time, the Netfilter team could begin generating errors
      when loading those same rules.
    - MAC addresses may not be used in the accounting rules.
    - The 'accounting' chain cannot be optimized when
      OPTIMIZE_ACCOUNTING=Yes.

    In addition, currently the rules may be defined in any order so the
    rules compiler must post-process the ruleset to alert the user to
    unreferenced chains.

    Beginning with Shorewall 4.4.18, the accounting structure can be
    created with three root chains:

    - accountin:  Rules that are valid in the INPUT chain (may not
      specify an output interface). 
    - accountout: Rules that are valid in the OUTPUT chain (may not
      specify an input interface or a MAC address).
    - accountfwd: Other rules.

    The new structure is enabled by sectioning the accounting file in a
    manner similar to the rules file.  

    The sections are INPUT, OUTPUT and FORWARD and must appear in that
    order (although any of them may be omitted). The first
    non-commentary record in the accounting file must be a section
    header when sectioning is used.

    When sections are enabled:

    - You must jump to a user-defined accounting chain before you can
      add rules to that chain. This eliminates the possibility of
      unreferenced chains.
    - You may not specify an output interface in the INPUT section.
    - In the OUTPUT section:
      - You may not specify an input interface
      - You may not jump to a chain defined in the INPUT section that
        specifies an input interface
      - You may not specify a MAC address
      - You may not jump to a chain defined in the INPUT section that
        specifies specifies a MAC address.
    - The default value of the CHAIN column is:
      - 'accountin' in the INPUT section
      - 'accountout' in the OUTPUT section
      - 'accountfwd' in the FORWARD section
    - Traffic addressed to the firewall goes through the rules defined
      in the INPUT section.
    - Traffic originating on the firewall goes through the rules
      defined in the OUTPUT section.
    - Traffic being forwarded through the firewall goes through the
      rules defined in the FORWARD section.

    As part of this change, the USER/GROUP column must now be empty
    except in the OUTPUT section. This is consistent with recent
    Netfilter releases which disallow the owner match in rules
    reachable from the INPUT and FORWARD hooks.

3)  Internals Change: The Policy.pm module has been merged into the
    Rules.pm module.

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

1)  Previously, Shorewall did not check the length of the names of
    accounting chains and manual chains. This could result in 
    errors when loading the resulting ruleset. Now, the compiler issues
    an error for chain names longer than 29 characters.

    Additionally, the compiler now ensures that these chain names are
    composed only of letters, digits, underscores ('_') and dashes
    ("-"). This eliminates Perl runtime errors or other failures when a
    chain name is embedded within a regular expression.

2)  Several issues with complex traffic shaping have been resolved:

    a) Specifying IPv6 network addresses in the SOURCE or DEST columns
       of /etc/shorewall6/tcfilters now works correctly. Previously,
       Perl runtime warnings occurred and an invalid tc command was
       generated.

    b) Previously, if flow= was specified on a parent class, a perl
       runtime warning occurred and an invalid tc command was
       generated. This combination is now flagged as an error at
       compile time.

    c) There is now an ipv6 tcfilters skeleton included with
       Shorewall6.

3)  Several issues with accounting are corrected.

    a)  If an accounting rule of the form:

    	   chain1		 chain2

	was configured and neither chain was referenced again in the
	configuration, then an internal error was generated when
	optimize level 4 was selected and OPTIMIZE_ACCOUNTING=Yes.

    b)  If there was only a single accounting rule and that rule
    	specified an interface in the SOURCE or DEST columns, then the
    	generated ruleset would fail to load when
    	OPTIMIZE_ACCOUNTING=Yes.

    c)  If a per-IP accounting table name appeared in more than one
    	rule and the specified network was not the same in all
    	occurrences, then the generated ruleset would fail to load.

	This is now flagged as an error at compile time.

4)  Two defects in compiler module loading have been corrected:

    a) Previously, the kernel/net/ipv6/netfilter/ directory was not
       searched.
       
    b) A Perl diagnostic was issued when running on a monolithic kernel
       when the modutils package was installed.

5)  A line containing only 'INCLUDE' appearing in an extension script
    now generates a compile-time diagnostic rather than a run-time
    diagnostic.

6)  Previously, the uninstall.sh scripts used insserv (if installed) on
    Debian-based systems. These scripts now use the preferred tool
    (updaterc.d).

7)  Beginning with 4.4.16, compilation would fail if an empty shell
    variable was referenced in a config file on a system where /bin/sh
    is the Bourne Again Shell (bash).

8)  In earlier versions. if OPTIMIZE=8 then the ruleset displayed by
    'check -r' was the same as when OPTIMIZE=0
    (unoptimized). Similarly, if OPTIMIZE=9 then the ruleset displayed
    was the same as when OPTIMIZE=1.

9)  Startup could previously fail on a system where kernel module
    autoloading was not available and where TC_ENABLED=Simple was
    specified in shorewall.conf or shorewall6.conf.

10) Previously, a 'done.' message could be printed at the end of
    command processing even when the command had failed. Now, such a
    message only appears if the command completed successfully.

----------------------------------------------------------------------------
               N E W   F E A T U R E S   I N   4 . 4 . 1 7
----------------------------------------------------------------------------

1)  This release adds support for per-IP accounting using the ACCOUNT
    target. That target is only available when xtables-addons is
    installed. This support has been successfully tested with
    xtables-addons 1.32 on:

    - Fedora 14
    - Debian Squeeze
    - OpenSuSE 11.3

    It has also been tested with xtables-addons 1.21 on:

    - Debian Lenny

    Information about xtables-addons installation may be found at
    http://www.shorewall.net/Dynamic.html#xtables-addons

    This feature required addition of the "ACCOUNT Target" capability
    so if you use a capabilities file, you will want to refresh it
    after installing this release.

    Per-IP accounting is configured in /etc/shorewall/accounting (it is
    not currently supported in IPv6). In the ACTION column, enter:

       ACCOUNT(<table>,<network>)

    where:

       <table> is the name of an accounting table (you choose the
       	       name). Rules specifying the same table will have their
       	       per-IP counters accumulated in that table.

       <network> is an IPv4 in CIDR format. May be as large as a /8.

    Example: Suppose your WAN interface is eth0 and your LAN interface
    	     is eth1 with network 172.20.1.0/24. To account for all
    	     traffic between the WAN and LAN interfaces:

	#ACTION                        TABLE     SOURCE        DEST ...
	ACCOUNT(net-loc,172.20.1.0/24) -         eth0          eth1
	ACCOUNT(net-loc,172.20.1.0/24) -         eth0          eth1

    This will create a net-loc table for counting packets and
    bytes for traffic between the two interfaces. The table is dumped
    using the iptaccount utility:

    	iptaccount [-f] -l net-loc

    Example (output folded):

	gateway:~# iptaccount -l loc-net

	libxt_ACCOUNT_cl userspace accounting tool v1.3

	Showing table: loc-net
	Run #0 - 3 items found
	IP: 172.20.1.105 SRC packets: 115 bytes: 131107
                         DST packets: 68 bytes: 20045
	IP: 172.20.1.131 SRC packets: 47 bytes: 12729
                         DST packets: 38 bytes: 25304
	IP: 172.20.1.145 SRC packets: 20747 bytes: 2779676
                         DST packets: 27050 bytes: 32286071
	Finished.
	gateway:~#
    
    For each local IP address with non-zero counters, the packet and
    byte count for both incoming traffic (IP is DST) and outgoing
    traffic (IP is SRC) are listed. The -f option causes the table to
    be flushed (reset all counters to zero).

    For a command synopsis, type:

    	iptaccount --help 

    One nice feature of per-IP accounting is that the counters survive
    'shorewall restart'. This has a downside, however. If you change
    the <network> associated with an accounting table, then you must
    "shorewall stop; shorewall start" to have a successful restart
    (counters will be cleared).

2)  A 'show ipa' command has been added to /sbin/shorewall. It
    displays each per-IP accounting table.  

3)  Traditionally, the -lite products have used the modules (or
    helpers) file on the firewall system unless there is a modules (or
    helpers) file in the configuration directory on the administrative
    system. This release introduces the EXPORTMODULES option in
    shorewall[6].conf.

    When EXPORTMODULES=Yes, the modules (helpers) file on the
    administrative system will be used to determine the set of modules
    loaded.

    As part of this change, the modules and helpers files are now
    secured for read access by non-root users.

4)  Given that shell variables are expanded at compile time, there was
    previously no way to cause such variables to be expanded at run
    time. This made it difficult (to impossible) to include dynamic IP
    addresses in a Shorewall-lite configuration.

    This release implements "Run-time address variables". In
    configuration files, these variables are expressed using an
    apersand ('&') followed by the name of an interface defined in
    /etc/shorewall/interfaces. Wild-card interfaces (those whose names
    end in '+') are not allowed to be used in this way.
    
    Example: 

    	     &eth0 would represent the primary IP address of eth0.

    Run-time address variables may be used in the SOURCE and DEST
    column of the following configuration files:

    	   accounting
	   action files
	   blacklist
	   macro files
	   rules
	   tcrules
	   tos

    They may also appear in the ORIGINAL DEST column of

    	   action files
	   macro files
	   rules

    They may also be used in the SOURCE and ADDRESS columns of the masq
    file.

    For optional interfaces, if the interface is not usable at the time
    that the firewall starts, the resulting Netfilter rule(s)
    containing the interface address are not added.

5)  The shell variables set in /etc/shorewall/params
    (/etc/shorewall6/params) are now available in the compiled script
    at run-time with EXPORTPARAMS=No. The EXPORTPARAMS option is now
    deprecated and the released /etc/shorewall/shorewall.conf and
    /etc/shorewall/shorewall6.conf have been modified to specify
    EXPORTPARAMS=No.

6)  The INCLUDE directive may now be used in the following extension
    scripts:

	clear
	findgw
	init
	isusable
	refresh
	refreshed
	restored
	start
	started
	stop
	stopped
	tcclear

    The directive is executed during compilation so that the INCLUDEd
    file(s) is(are) copied into the generated script. This same
    technique is also now used for INCLUDE directives in the params
    file when EXPORTPARAMS=Yes. Previously, INCLUDE directives in that
    file were strongly discouraged with EXPORTPARAMS=Yes because the
    INCLUDE was performed on the firewall system rather than on the
    administrative system.

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

1)  If the output of 'env' contained a multi-line value, then
    compilation failed with an Internal Error. The code has been
    changed so that the compiler now handles multi-line values
    correctly.

2)  In 4.4.15, output to Standard Out (FD 1) generated by
    /etc/shorewall/params (/etc/shorewall6/params) was redirected to
    /dev/null. It is now redirected to Standard Error (FD 2).

3)  2)  If a params file did not appear in the CONFIG_PATH, compilation
    failed with the error:

    	   .: 31: Can't open /etc/shorewall6/params 
	   ERROR: Processing of /etc/shorewall6/params failed

4)  Compilation no longer fails when /bin/sh is an older (e.g.,
    RHEL5.x) bash.

5)  Previously, proxy ARP with logical interface names did not
    work. Symptoms included numerous Perl runtime error messages. 

6)  Previously, the root of a wildcard name erroneously matched that
    name. For example 'eth' matched 'eth+'. Now there must be at least
    one additional character (e.g., 'eth4').

7)  Use of logical interface names in the notrack and ecn files
    resulted in perl runtime warning messages.

8)  The use of wildcard-matching names in certain contexts would result
    in anomalous behavior. Among the symptoms were:

     - Perl run-time messages similar to this one:

       Use of uninitialized value in numeric comparison (<=>) 
       at /usr/share/shorewall/Shorewall/Zones.pm line 1334.

     - Failure to treat the interface as optional or required.

9)  Where two ISPs share the same interface, if one of the ISPs was not
    reachable, an iptables-restore error such as this occurred:

      iptables-restore v1.4.10: Bad mac address "-j"

10) Previously, under very rare circumstances, a chain would be
    optimized away while there were still jumps to the chain. This caused
    Shorewall start/restart to fail during iptables-restore.

11) Previously, the setting of BLACKLIST_DISPOSITION was not
    validated. Now, an error is raised unless the value is DROP or REJECT.

----------------------------------------------------------------------------
               N E W   F E A T U R E S   I N   4 . 4 . 1 6
----------------------------------------------------------------------------

1)  Shorewall-init now handles ppp devices.

2)  To support proxy NDP in a manner similar to Proxy ARP, an
    /etc/shorewall6/proxyndp file has been added. It should be noted
    that IPv6 implements a "strong host model" whereas Linux IPv4
    implements a "weak host model". In the strong model, IP addresses
    are associated with interfaces; in the weak model, they are
    associated with the host. This is relevant with respect to Proxy
    NDP in that a multi-homed Linux IPv6 host will only respond to
    neighbor discoverey requests for IPv6 addresses configured on the
    interface receiving the request. So if eth0 has address
    2001:470:b:227::44/128 and eth1 has address 2001:470:b:227::1/64
    then in order for eth1 to respond to neighbor discovery requests
    for 2001:470:b:227::44, the following entry in
    /etc/shorewall6/proxyndp is required:

    #ADDRESS	       INTERFACE    EXTERNAL	HAVEROUTE	PERSISTENT
    2001:470:b:227::44 -            eth1        Yes

    As part of this change, the INTERFACE column in
    /etc/shorewall/proxyarp is now optional and is only required when
    HAVEROUTE=No (the default).

3)  Shorewall 4.4.16 introduces format-2 Actions. Based on the similar
    feature of macros, format-2 actions allow the same column layout
    for macros, actions and rules.

    In the action.xxx file, simply make the first non-commentary line:

       FORMAT 2

    This allows the lines which follow to have the same columns as
    those in the rules file.

    As part of this change, the earlier kludgy restrictions regarding
    Macros and Actions have been eliminated. For example, DNAT, DNAT-,
    REDIRECT, REDIRECT- and ACCEPT+ rules are now allowed in Actions
    and in macros invoked from Actions. Additionally, Macros used in
    Actions are now free to invoke other actions.

4)  Action processing has been largely re-implemented in this release.
    The prior implementation contained a lot of duplicated code which
    made maintainance difficult. The old implementation pre-processed
    all action files early in the compilation process and then
    post-processed the ones that had been actionally used after the
    rules file had been read. The new algorithm generates the chain for
    each unique action invocation at the time that the invocation is
    encountered in the rules file.

    Consideration was given to eliminating the
    /usr/share/shorewall/actions.std and /etc/shorewall/actions files,
    since it is possible to discover actions "on the fly" in the same
    way as macros are discovered. That change was ultimately rejected
    because it could cause migration issues for users with macros and
    actions with the same name (e.g., action.xxx and macro.xxx). If a
    new major release of Shorewall (e.g., 4.6) is created, that change
    will be reconsidered for inclusion at that time.

    Action names are now verified to be composed of alphanumeric
    characters, '_' and '-'.

    There is now support for parameterized actions. The parameters are
    a comma-separated list enclosed in parentheses following the
    action name (e.g., ACT(REDIRECT,192.168.1.4)). Within the action
    body, the parameter values are available in $1, $2, etc.

    You can 'omit' a parameter in the list by using '-' (e,g,
    REDIRECT,-.info) would omit the second parameter (within the action
    body, $2 would expand to nothing). If you want to specify '-' as a
    parameter value, use '--'.
    
    Parameter values are also available to extensions scripts. See
    http://www.shorewall.net/Actions.html#Extension for more
    information.

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

1)  Previously, if 

    a) syn flood protection was enabled in a policy that
       specified 'all' for the SOURCE or DEST, and
    b) there was only one pair of zones matching that policy, and
    c) PROPAGATE_POLICIES=Yes in shorewall.conf, and
    d) logging was specified on the policy

    then the chain implementing the chain had "all" in its name while
    the logging rule did not.

    Example

	On a simple standalone configuration, /etc/shorewall/policy
	has:

	     #SOURCE	DEST	POLICY	LOGGING
    	     net	all	DROP	info

	then the chain implementing syn flood protection would be named
	@net2all while the logging rule would indicate net2fw.

    Now, the chain will be named @net2fw.

2)  If the current environment exported the VERBOSE variable with a
    non-zero value, then startup would fail.

3)  If a route existed for an entire RFC1918 subnet (10.0.0.0/8,
    172.20.0.0/12 or 192.168.0.0/16), then setting
    NULL_ROUTE_RFC1918=Yes would cause the route to be replaced with an
    'unreachable' one.

4)  Shorewall6 failed to start correctly if all the following were true:

    - Shorewall was installed using the tarball. It may have
      subsequently been installed using a distribution-specific package
      or the rpm from shorewall.net without first unstalling the
      tarball components.

    - Shorewall6 was installed using a distribution-specific package or
      the rpm from shorewall.net.

    - The file /etc/shorewall6/init was not created.

5)  If an interface with physical='+' is given the 'optional' or
    'required' option, then invalid shell variables names were
    generated by the compiler.

6)  The contributed macro macro.JAP generated a fatal error when used.
    The root cause was a defect in parameter processing in nested
    macros (if 'PARAM' was passed to an nested macro invocation, it was
    not expanded to the current parameter value).

7)  Previously, if find_first_interface_address() failed when running
    shorewall-lite or shoreawll6-lite, the following unhelpful message
    was issued:

    	/usr/share/shorewall-lite/lib.common: line 449: startup_error: command
                                              not found

----------------------------------------------------------------------------
               N E W   F E A T U R E S   I N   4 . 4 . 1 5
----------------------------------------------------------------------------

1)   Munin and Squid macros have been contributed by Tuomo Soini.

2)   The Shorewall6 accounting, tcrules and rules files now include a
     HEADERS column which allows matching based on the IPv6 extension and
     protocol headers included in a packet.

     The contents of the column are:

     	 [any:|exactly:]<header list>

     where <header list> is a comma-separated list of headers from the
     following:

	Long Name	Short Name	Number
        --------------------------------------
	auth   		ah    		51
	esp		esp		50
	hop-by-hop	hop		0
	route		ipv6-route	41
	frag		ipv6-frag	44
	none		ipv6-nonxt	59	
	protocol	proto		255

     If 'any:' is specified, the rule will match if any of the listed
     headers are present. If 'exactly:' is specified, the will match
     packets that exactly include all specified headers. If neither is
     given, 'any:' is assumed.

     This change adds a new capability (Header Match) so if you use a
     capabilities file, you will need to regenerate using this release.

3)  It is now possible to add explicit routes to individual provider
    routing tables using the /etc/shorewall/routes (/etc/shorewall6/routes)
    file.

    See the shorewall-routes (5) and/or the shorewall6-routes (5)  manpage.

4)  Previously, /usr/share/shorewall/compiler.pl expected the contents
    of the params file to be passed in the environment. Now, the
    compiler invokes a small shell program
    (/usr/share/shorewall/getparams) to process the file and to pass
    the (variable,value) pairs back to the compiler.

    Shell variable expansion uses the value from the params file if the
    parameter was set in that file. Otherwise the current environment
    is used. If the variable does not appear in either place, an error
    message is generated.

5)  Shared IPv4/IPv6 traffic shaping configuraiton is now
    available. The device and class configuration can be included in
    either the Shorewall or the Shorewall6 configuration. To place it
    in the Shorewall configuration:

    a) Set TC_ENABLED=Internal in shorewall.conf
    b) Set TC_ENABLED=Shared in shorewall6.conf
    c) Create symbolic link /etc/shorewall6/tcdevices pointing to
       /etc/shorewall/tcdevices.
    d) Create symbolic link /etc/shorewall6/tcclasses pointing to
       /etc/shorewall/tcclasses.
    e) Entries for both IPv4 and IPv6 can be included in
       /etc/shorewall/tcfilters. This file has been extended to allow
       both IPv4 and IPv6 entries to be included in a single file.
    f) Packet marking rules are included in both configurations'
       tcrules file as needed. CLASSIFY rules in
       /etc/shorewall6/tcrules are validated against the Shorewall TC
       configuration.
  
    In this setup, the tcdevices and tcclasses will only be updated
    when Shorewall is restarted. The IPv6 marking rules are updated
    when Shorewall6 is restarted.

    The above configuration may be reversed to allow Shorewall6 to
    control the TC configuration.

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

1)  Previously, messages to the STARTUP_LOG had inconsistent date formats.

2)  The blacklisting change in 4.4.13 was broken in some simple
    configurations with the effect that blacklisting was not enabled.

3)  Previously, Shorewall6 produced an untidy sequence of error
    messages when an attempt was made to start it on a system running a
    kernel older than 2.6.24:

       [root@localhost shorewall6]# shorewall6 start
       Compiling...
       Processing /etc/shorewall6/shorewall6.conf...
       Loading Modules...
       Compiling /etc/shorewall6/zones...
       ...
       Shorewall configuration compiled to /var/lib/shorewall6/.start
          ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
       /usr/share/shorewall6/lib.common: line 73:
             [: -lt: unary operator expected
          ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
       [root@localhost shorewall6]#

    This has been corrected so that a single ERROR message is
    generated.

4)  Previously, an ipset name appearing in the /etc/shorewall/hosts
    file could be qualified with a list of 'src' and/or 'dst' enclosed
    in quotes. This was virtually guaranteed not to work since the set
    must match when used to verify both a packet source and a
    packet destination. Now, the following error is raised:

    	   ERROR: ipset name qualification is disallowed in this file

    As part of this change, the ipset name is now verified to begin
    with a letter and be composed of letters, digits, underscores ("_")
    and hyphens ("-").

5)  The Shorewall-lite and Shorewall6-lite Debian init scripts contained a
    syntax error.

6)  If the -v or -q options were used in /sbin/shorewall-lite or
    /sbin/shorewall6-lite commands that involve the compiled firewall
    script and the resulting effective VERBOSITY was > 2 or < -1, then
    the command would fail.

7)  The log reading commands (show log, logwatch, and dump) returned no
    log records when run on one of the -lite products.

8)  To avoid future confusion, the following obsolete options have been
    deleted from the sample shorewall.conf files:

    	    BRIDGING
    	    DELAYBLACKLISTLOAD
	    PKTTYPE

    They will still be recognized by the rules compiler.

9)  All sample .conf files have been changed to specify

    	FORWARD_CLEAR_MARK=

    rather than

    	FORWARD_CLEAR_MARK=Yes

    That way, systems without MARK support will still be able to
    install the sample configurations and FORWARD_CLEAR_MARK will
    default to Yes on systems with MARK support.

10) The install scripts in the tarballs now correctly create init
    symlinks on recent Ubuntu releases.

11) Previously, this entry in the OPTIONS column of
    /etc/shorewall/interfaces incorrectly generated a syntax error.

    	nets=(1.2.3.0/24)

    The error was:

    	ERROR: Invalid VLSM (24))

12) Previously, if 10 or more interfaces were configured in Complex
    Traffic Shaping (/etc/shorewall/tcdevices), the following
    compilation diagnostic was generated:

        Argument "a" isn't numeric in sprintf at
	/usr/share/shorewall/Shorewall/Config.pm line 893.
 
    and an invalid TC configuration was generated.

13) If the current environment exported the VERBOSITY variable with a
    non-zero value, startup would fail.

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

1)  Multiple source or destination ipset matches can be generated by
    enclosing the ipset list in +[...].

    Example (/etc/shorewall/rules):

        ACCEPT $FW net:+[dest-ip-map,dest-port-map]

2)  Shorewall now uses the 'conntrack' utility for 'show connections'
    if that utility is installed. Going forward, the Netfilter team
    will be enhancing this interface rather than the /proc interface.

3)  The CPU time required for optimization has been reduced by 2/3.

4)  An 'scfilter' extension script has been added. This extension
    script differs from other such scripts in that it is invoked by the
    command line tools (/sbin/shorewall, /sbin/shorewall6,
    /sbin/shorewall-lite and /sbin/shorewall6-lite).

    The script acts as a filter for the output of the 'show
    connections' command. Each connection is piped through the filter
    which can modify and/or drop information as desired.

    Example:

	#!/bin/sh
 	sed 's/secmark=0 //'

    That script will remove 'secmark=0 ' from each line.

    The default script is:

    	#!/bin/sh
	cat -

    which passes the output through unmodified.

    If you are using Shorewall-lite and/or Shorewall6-lite, the
    scfilter file is kept on the administrative system. The compiler
    encapsulates the script into a shell function that is copied
    into the generated auxillary configuration file
    (firewall.conf). That function is then invoked by the 'show
    connections' command.

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

1)  Under rare circumstances where COMMENT is used to attach comments
    to rules, OPTIMIZE 8 through 15 could result in invalid
    iptables-restore (ip6tables-restore) input.

2)  Under rare circumstances involving exclusion, OPTIMIZE 8 through 15
    could result in invalid iptables-restore (ip6tables-restore) input.

3)  The change in 4.4.12 to detect and use the new ipset match syntax
    broke the ability to detect the old ipset match capability. Now,
    both versions of the capability can be correctly detected.

4)  Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail
    if the last optional interface tested was not available.

5)  Exclusion in the blacklist file was correctly validated but was then
    ignored when generating iptables (ip6tables) rules.

6)  Previously, non-trivial exclusion (more than one excluded
    address/net) in CONTINUE, NONAT and ACCEPT+ rules generated
    valid but incorrect iptables input. This has been corrected but
    requires that your iptables/kernel support marking rules in any
    Netfilter table (CONTINUE in the tcrules file does not require this
    support).

    This fix implements a new 'Mark in any table' capability; those
    who utilize a capabilities file should re-generate the file using
    this release.

7)  Interface handling has been extensively modified in this release
    to correct a number of problems with the earlier
    implementation. Among those problems:

    - Invalid shell variable names could be generated in the firewall
      script. The generated firewall script uses shell variables to
      track the availability of optional and required interfaces and
      to record detected gateways, detected addresses, etc.

    - The same shell variable name could be generated by two different
      interface names.

    - Entries in the interfaces file with a wildcard physical name
      (physical name ends with "+") and with the 'optional' option were
      handled strangely.

      o If there were references to specific interfaces that matched
        the wildcard, those entries were handled as if they had been
        defined as optional in the interfaces file.

      o If there were no references matching the wildcard, then the
        'optional' option was effectively ignored.

    The new implementation:

    - Insures valid shell variable names.

    - Insures that shell variable names are unique.

    - Handles interface names appearing in the INTERFACE column of the
      providers file as a special case for 'optional'. If the name
      matches a wildcard entry in the interfaces file then the
      usability of the specific interface is tracked individually.

    - Handles the availabilty of other interfaces matching a wildcard
      as a group; if there is one useable interface in the group then
      the wildcard itself is considered usable.

      The following example illustrates this use case:

      /etc/shorewall/interfaces

	net	ppp+	-	optional

      /etc/shorewall/shorewall.conf

	REQUIRE_INTERFACE=Yes

      If there is any usable PPP interface then the firewall will be
      allowed to start. Previously, the firewall would never be allowed
      to start.

8)  When a comma-separated list of 'src' and/or 'dst' was specified in
    an ipset invocation (e.g., "+fooset[src,src]), all but the first 'src'
    or 'dst' was previously ignored when generating the resulting
    iptables rule.

9)  Beginning with Shorewall 4.4.9, the SAME target in tcrules has
    generated invalid iptables (ip6tables) input. That target now
    generates correct input.

10) Ipsets associated with 'dynamic' zones were being created during
    'restart' but not during 'start'.

11) To work around an issue in Netfilter/iptables, Shorewall now uses
    state match rather than conntrack match for UNTRACKED state
    matching.

12) If the routestopped files contains NOTRACK rules, 'shorewall* clear'
    did not clear the raw table.

13) An error message was incorrectly generated if a port range of the
    form :<port> (e.g., :22) appeared.

14) An error message is now generated when '*' appears in an interface
    name.

----------------------------------------------------------------------------
               N E W   F E A T U R E S   I N   4 . 4 . 1 3
----------------------------------------------------------------------------

1)  Entries in the rules file (both Shorewall and Shorewall6) may now
    contain zone lists in the SOURCE and DEST column. A zone list is a
    comma-separated list of zone names where each name appears in the
    zones file. A zone list may be optionally followed by a plus sign
    ("+") to indicate that the rule should apply to intra-zone traffic
    as well as to inter-zone traffic.

    Zone lists behave like 'all' and 'any' with respect to Optimization
    1. If the rule matches the applicable policy for a given (source
    zone, dest zone), then the rule will be suppessed for that pair of
    zones unless overridden by the '!' suffix on the target in the
    ACTION column (e.g., ACCEPT!, DROP!:info, etc.).

    Additionally, 'any', 'all' and zone lists may be qualified in the
    same way as a single zone.

    Examples:

	fw,dmz:90.90.191.120/29
	all:+blacklist

    The 'all' and 'any' keywords now support exclusion in the form of a
    comma-separated list of excluded zones.

    Examples:

    	     all!fw         (same as all-).
	     any+!dmz,loc   (All zones except 'dmz' and 'loc' and
	     		     include intra-zone rules).

2)  An IPSEC column has been added to the accounting file, allowing you
    to segregate IPSEC traffic from non-IPSEC traffic. See 'man
    shorewall-accounting' (man shorewall6-accounting) for details.

    With this change, there are now three trees of accounting chains:

    - The one rooted in the 'accounting' chain.
    - The one rooted in the 'accipsecin' chain. This tree handles
      traffic that has been decrypted on the firewall. Rules in this
      tree cannot specify an interface name in the DEST column.
    - The one rooted in the 'accipsecout' chain. This tree handles
      traffic that will be encrypted on the firewall. Rules in this
      tree cannot specify an interface name in the SOURCE column.

    In reality, when there are bridges defined in the configuration,
    there is a fourth tree rooted in the 'accountout' chain. That chain
    handles traffic that originates on the firewall (both IPSEC and
    non-IPSEC).

    This change also implements a couple of new warnings:

    - WARNING: Adding rule to unreferenced accounting chain <name>

      The first reference to user-defined accounting chain <name> is
      not a JUMP or COUNT from an already-defined chain.

    - WARNING: Accounting chain <name> has o references

      The named chain contains accounting rules but no JUMP or COUNT
      specifies that chain as the target.

3)  Shorewall now supports the SECMARK and CONNSECMARK targets for
    manipulating the SELinux context of packets.

    See the shorewall-secmarks and shorewall6-secmarks manpages for
    details.

    As part of this change, the tcrules file now accepts $FW in the
    DEST column for marking packets in the INPUT chain.

4)  Blacklisting has undergone considerable change in Shorewall 4.4.13.

    a) Blacklisting is now based on zones rather than on interfaces and
       host groups.

    b) Near compatibility with earlier releases is maintained.

    c) The keywords 'src' and 'dst' are now preferred in the OPTIONS
       column in /etc/shoreawll/blacklist, replacing 'from' and 'to'
       respectively. The old keywords are still supported.

    d) The 'blacklist' keyword may now appear in the OPTIONS,
       IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones.

       i)  In the IN_OPTIONS column, it indicates that packets received
           on the interface are checked against the 'src' entries in
           /etc/shorewall/blacklist.

       ii) In the OUT_OPTIONS column, it indicates that packets being
           sent to the interface are checked against the 'dst' entries.

       iii) Placing 'blacklist' in the OPTIONS column is equivalent to
           placing in in both the IN_OPTIONS and OUT_OPTIONS columns.

    e) The 'blacklist' option in the OPTIONS column of
       /etc/shorewall/interfaces or /etc/shorewall/hosts is now
       equivalent to placing it in the IN_OPTIONS column of the
       associates record in /etc/shorewall/zones. If no zone is given
       in the ZONE column of /etc/shorewall/interfaces, the 'blacklist'
       option is ignored with a warning (it was previously ignored
       silently).

    f) The 'blacklist' option in the /etc/shorewall/interfaces and
       /etc/shorewall/hosts files is now deprecated but will continue
       to be supported for several releases. A warning will be added at
       least one release before support is removed.

5)  There is now an OUT-BANDWIDTH column in
    /etc/shorewall/tcinterfaces.

    The format of this column is:

    	<rate>[:[<burst>][:[<latency>][:[<peak>][:[<minburst>]]]]]

    These terms are described in tc-tbf(8). Shorewall supplies default
    values as follows:

    	   <burst>   = 10kb
	   <latency> = 200ms

    The remaining options are defaulted by tc.

6)  The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
    /etc/shorewall/tcinterfaces now accepts an optional burst parameter.

        <rate>[:<burst>]

    The default <burst> is 10kb. A larger <burst> can help make the
    <rate> more accurate; often for fast lines, the enforced rate is
    well below the specified <rate>.

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

1)  Previously, the Shorewall6-lite version of shorecap was using
    iptables rather than ip6tables, with the result that many capabilities
    that are only available in IPv4 were being reported as available.

2)  In a number of cases, Shorewall6 generated incorrect rules
    involving the IPv6 multicast network. The rules specified
    ff00::/10 where they should have specified ff00::/8. Also, rules
    instantiated when the firewall was stopped used ff80::/10 rather
    than fe80::/10 (IPv6 Link Local network).

3)  Previously, using a destination port-range with :random produced a
    fatal compilation error in REDIRECT rules.

4)  A number of problems associated with Shorewall-init and Upstart
    have been corrected.

    If you use Shorewall-init, then when upgrading to this version, be
    sure to recompile all firewall scripts before you take interfaces
    down or reboot.

5)  Previously, the Shorewall installer (install.sh) failed to install
    /usr/share/shorewall/configfiles/Makefile and rather issued the
    following message:

    	      install-file: command not found

    This caused the Makefile to be omitted from RPMs as well.

6)  When 'any' was used in the SOURCE column, a duplicate rule was
    generated in all "fw2*" ("fw-* if ZONE2ZONE="-"). If 'any' was used
    in the DEST column, then a duplicate rule appeared in all "*2fw"
    (*-fw) chains.

7)  A port range that omitted the first port number (e.g., ":80") was
    rejected with the following error:

    	 ERROR: Invalid/Unknown tcp port/service (0) : ......

8)  AUTOMAKE=Yes has been broken for some time. It is now working
    correctly.

----------------------------------------------------------------------------
               N E W   F E A T U R E S   I N   4 . 4 . 1 2
----------------------------------------------------------------------------

1)  Support has been added for ADD and DEL rules in
    /etc/shorewall/rules. ADD allows either the SOURCE or DESTINATION
    IP address to be added to an ipset; DEL deletes an address
    previously added.

2)  Per-ip log rate limiting has been added in the form of the LOGLIMIT
    option in shorewall.conf. When LOGLIMIT is specified, LOGRATE and
    LOGBURST are ignored.

    LOGRATE and LOGBURST are now deprecated.

    LOGLIMIT value format is [{s|d}:]<rate>[/<unit>][:<burst>]

    If the value starts with 's:' then logging is limited per source
    IP. If the value starts with 'd:', then logging is limited per
    destination IP. Otherwise, the overall logging rate is limited.

    <unit> is one of sec, min, hour, day.

    If <burst> is not specified, then a value of 5 is assumed.

3)  The sample configurations now include a 'Universal' configuration
    that will start on any system and protect that system while
    allowing the system to forward traffic.

    As part of this change, several additional features were added:

    - You may now specify "physical=+" in the interfaces file.
    - A 'COMPLETE' option is added to shorewall.conf and
      shorewall6.conf. When you set this option to Yes, you are
      asserting that the configuration is complete so that your set of
      zones encompasses any hosts that can send or receive traffic
      to/from/through the firewall. This causes Shorewall to omit the
      rules that catch packets in which the source or destination IP
      address is outside of any of your zones. Default is No.  It is
      recommended that this option only be set to Yes if:

      o You have defined an interface whose effective physical setting
        is '+'
      o That interface is assigned to a zone.
      o You have no CONTINUE policies or rules.

4)  'icmp' is now accepted as a synonym for 'ipv6-icmp' in IPv6
    compilations.

5)  Shorewall now detects the presence of a recent ipset iptables
    module and uses its new syntax. This avoids a warning on iptables
    1.4.9. This change involves a new capabilities file version so if
    you use a capabilities file, be sure to regenerate it with 4.4.12
    shorewall-lite or shorewall6-lite.

6)  Blacklisting can now be done by destination IP address as well as
    by source address.

    The /etc/shorewall/blacklist and /etc/shorewall6/blacklist files
    now have an optional OPTIONS column. Initially, this column can
    contain either 'from' (the default) or 'to'; the latter causes the
    address(es) in the ADDRESS/SUBNET column to be interpreted as a
    DESTINATION address rather than a source address.

    Note that static blacklisting is still restricted to traffic
    ARRIVING on an interface that has the 'blacklist' option set. So to
    block traffic from your local network to an internet host, you must
    specify 'blacklist' on your internal interface.

    Similarly, dynamic blacklisting has been enhanced to recognize the
    'from' and 'to' keywords.

    Example:

	shorewall drop to 1.2.3.4

    This command will silently drop connection requests to1.2.3.4.

    The reciprocal of that command would be:

    	shorewall allow to 1.2.3.4

7)  The status command now displays the directory containing the .conf
    file (shorewall.conf or shorewall6.conf) when the running
    configuration was compiled.

    Example:

        gateway:/etc/shorewall# shorewall status
	Shorewall-4.4.12-RC1 Status at gateway - Thu Aug 12 19:41:51 PDT 2010

	Shorewall is running
	State:Started (Thu Aug 12 19:41:48 PDT 2010) from /etc/shorewall/

	gateway:/etc/shorewall#

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

1)  The IPv6 allowBcast action generated an invalid rule.

2)  If IPSET=<pathname> was specified in shorewall.conf, then when an
    ipset was used in a configuration file entry, the following
    fatal compilation error occurred:

    ERROR: ipset names in Shorewall configuration files require Ipset
    Match in your kernel and iptables : /etc/shorewall/rules (line nn)

    If you applied the workaround given in the "Known Problems", then
    you should remove /etc/shorewall/capabilities after installing
    this fix.

3)  The start priority of shorewall-init on Debian and Debian-based
    distributions was previously too low, making it start too late.

4)  The log output from IPv6 logs was almost unreadable due to display
    of IPv6 addresses in uncompressed format. A similar problem
    occurred with 'shorewall6 show connections'. This update makes the
    displays much clearer at the expense of opening the slight
    possibility of two '::' sequences being incorrectly shown in the
    same address.

5)  The new REQUIRE_INTERFACE was inadvertently omitted from
    shorewall.conf and shorewall6.conf. It has been added.

6)  Under some versions of Perl, a Perl run-time diagnostic was produced
    when options were omitted from shorewall.conf or shorewall6.conf.

7) If the following options were specified in /etc/shorewall/interfaces
   for an interface with '-' in the ZONE column, then these options
   would be ignored if there was an entry in the hosts file for the
   interface with an explicit or implicit 0.0.0.0/0 (0.0.0.0/0 is
   implied when the host list begins with '!').

   	blacklist
	maclist
	nosmurfs
	tcpflags

   Note: for IPv6, the network is ::/0 rather than 0.0.0.0/0.

8) The generated script was missing a closing quote when
   REQUIRE_INTERFACE=Yes.

9) Previously, if nets= was specified under Shorewall6, this error
   would result:

   	 ERROR: Invalid IPv6 address (224.0.0.0) :
                /etc/shorewall6/interfaces (line 16)

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

1)  Beginning with this release, Shorewall supports a 'vserver'
    zone type. This zone type is used with Shorewall running on a
    Linux-vserver host system and allows you to define zones that
    represent a set of Linux-vserver hosts.

    See http://www.shorewall.net/Vserver.html for details.

2)  A new FORWARD_CLEAR_MARK option has been added to shorewall.conf
    and shorewall6.conf.

    Traditionally, Shorewall has cleared the packet mark in the first
    rule in the mangle FORWARD chain. This behavior is maintained with
    the default setting (FORWARD_CLEAR_MARK=Yes). If the new option is
    set to No, packet marks set in the PREROUTING chain are retained in
    the FORWARD chains.

    As part of this change, a new "fwmark route mask" capability has
    been added. If your version of iproute2 supports this capability,
    fwmark routing rules may specify a mask to be applied to the mark
    prior to comparison with the mark value in the rule. The presence
    of this capability allows Shorewall to relax the restriction that
    small mark values may not be set in the PREROUTING chain when
    HIGH_ROUTE_MARKS is in effect. If you take advantage of this
    capability, be sure that you logically OR mark values in PREROUTING
    makring rules rather then simply setting them unless you are able
    to set both the high and low bits in the mark in a single rule.

    As always when a new capability has been introduced, be sure to
    regenerate your capabilities file(s) after installing this release.

3)  A new column (NET3) has been added to the /etc/shorewall/netmap
    file. This new column can qualify the INTERFACE column by
    specifying a SOURCE network (DNAT rule) or DEST network (SNAT rule)
    associated with the interface.

4)  To accomodate systems with more than one version of Perl installed,
    the shorewall.conf and shorewall6.conf files now support a PERL
    option. If the program specified by that option does not exist or
    is not executable, Shorewall (and Shorewall6) fall back to
    /usr/bin/perl.

----------------------------------------------------------------------------
         P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 1 0
----------------------------------------------------------------------------
1)  Startup Errors (those that are detected before the state of the
    system has been altered), were previously not sent to the
    STARTUP_LOG.

2)  A regression of sorts occurred in Shorewall 4.4.9. Previously, a
    Perl extension script could end with a call to add_rule(). Such a
    script fails under Shorewall 4.4.9 unless the 'trace' option is
    specified on the run line.

    While this issue has been corrected, users are advised to always
    end their Perl extension scripts with the following line to insure
    that the script returns a 'true' value:

    	 1;

3)  Under rare circumstances involving a complex configuration,
    OPTIMIZE=13 and OPTIMIZE=15 could cause invalid iptables-restore
    input to be generated.

    Sample error message:

        iptables-restore v1.4.8: Couldn't load target
        `sys2sys':/usr/local/libexec/xtables/libipt_sys2sys.so:
	cannot open shared object file: No such file or directory

4)  Previously, if the 'optional' option was given to an interface with
    a wildcard physical name, specific instances of the interface were
    never considered usable.

    Example:

    /etc/shorewall/interfaces:

    #ZONE	INTERFACE	BROADCAST	OPTIONS
    net		ppp+		-		optional

    /etc/shorewall/providers:

    #PROVIDER	NUMBER	MARK	DUPLICATE	INTERFACE	...
    XYZTEL	1	-	main		ppp0

    The XYZTEL provider was never usable.

    This configuration now works correctly.

----------------------------------------------------------------------------
               N E W   F E A T U R E S   I N   4 . 4 . 1 0
----------------------------------------------------------------------------

1)  Shorewall 4.4.10 includes a new 'Shorewall Init' package. This new
    package provides two related features:

    a)  It allows the firewall to be closed prior to bringing up
        network devices. This insures that unwanted connections are not
        allowed between the time that the network comes up and when the
        firewall is started.

    b)  It integrates with NetworkManager and distribution ifup/ifdown
        systems to allow for 'event-driven' startup and shutdown.

    The two facilities can be enabled separately.

    When Shorewall-init is first installed, it does nothing until you
    configure it.

    The configuration file is /etc/default/shorewall-init on
    Debian-based systems and /etc/sysconfig/shorewall-init otherwise.

    There are two settings in the file:

    	  PRODUCTS    - lists the Shorewall packages that you want to
    	                integrate with Shorewall-init. Example:

			    PRODUCTS="shorewall shorewall6"

          IFUPDOWN      When set to 1, enables integration with
                        NetworkManager and the ifup/ifdown scripts.

    To close your firewall before networking starts:

    a)  in the Shorewall-init configuration file, set PRODUCTS to the
        firewall products installed on your system.

    b)  be sure that your current firewall script(s) (normally in
        /var/lib/<product>/firewall) is(are) compiled with the 4.4.10
        compiler.

	Shorewall and Shorewall6 users can execute these commands:

	    shorewall compile
            shorewall6 compile

        Shorewall-lite and Shorewall6-lite users can execute these
        commands on the administrative system.

	    shorewall export <firewall-name-or-ip-address>
	    shorewall6 export <firewall-name-or-ip-address>

    That's all that is required.

    To integrate with NetworkManager and ifup/ifdown, additional steps
    are required. You probably don't want to enable this feature if you
    run a link status monitor like swping or LSM.

    a)  In the Shorewall-init configuration file, set IFUPDOWN=1.

    b)  In your Shorewall interfaces file(s), set the 'required' option
        on any interfaces that must be up in order for the firewall to
        start. At least one interface must have the 'required' or
        'optional' option if you perform the next optional step. If
	'required' is specified on an interface with a wildcard name
        (the physical name ends with '+'), then at least one interface
        that matches the name must be in a usable state for the
        firewall to start successfully.

    c)  (Optional) -- If you have specified at least one 'required'
        or 'optional interface, you can then disable automatic firewall
        startup at boot time.

	On Debian-based systems, set startup=0 in /etc/default/<product>.

	On other systems, use your service startup configuration tool
	(chkconfig, insserv, ...) to disable startup.

    The following actions occur when an interface comes up:

    	FIREWALL      INTERFACE     ACTION
	STATE
	----------------------------------
	Any           Required      start
        stopped       Optional      start
        started	         -          restart

    The following actions occur when an interface goes down:

    In the INTERFACE column, '-' indicates neither required nor
    optional

    	FIREWALL      INTERFACE     ACTION
	STATE
	----------------------------------
	Any           Required      stop
        stopped       Optional      start
	started	         -          restart

    For optional interfaces, the /var/lib/<product>/<interface>.state
    files are maintained to reflect the state of the interface.

    Please note that the action is carried out using the current
    compiled script; the configuration is not recompiled.

    A new option has been added to shorewall.conf and
    shorewall6.conf. The REQUIRE_INTERFACE option determines the
    outcome when an attempt to start/restart/restore/refresh the
    firewall is made and none of the optional interfaces are available.
    With REQUIRE_INTERFACE=No (the default), the operation is
    performed. If REQUIRE_INTERFACE=Yes, then the operation fails and
    the firewall is placed in the stopped state. This option is
    suitable for a laptop with both ethernet and wireless
    interfaces. If either come up, the firewall starts. If neither
    comes up, the firewall remains in the stopped state. Similarly, if
    an optional interface goes down and there are no optional
    interfaces remaining in the up state, then the firewall is stopped.

    Shorewall-init may be installed on Debian-based systems, SuSE-based
    systems and RedHat-based systems.

    On Debian-based systems, during system shutdown the firewall is
    opened prior to network shutdown (/etc/init.d/shorewall stop
    performs a 'clear' operation rather than a 'stop'). This is
    required by Debian standards. You can change this default behavior
    by setting SAFESTOP=1 in /etc/default/shorewall
    (/etc/default/shorewall6, ...).

2)  All of the CLIs now support the -a option of the 'version' command.

    Example:

	gateway:~# shorewall6 version -a
	4.4.10-RC1
	shorewall: 4.4.10-RC1
	shorewall-lite: 4.4.10-RC1
	shorewall6-lite: 4.4.10-RC1
	shorewall-init: 4.4.10-RC1
	gateway:~#

----------------------------------------------------------------------------
         P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 9
----------------------------------------------------------------------------
1)  Logical interface names in the EXTERNAL column of
    /etc/shorewall/proxyarp were previously not mapped to their
    corresponding physical interface names. This could cause 'start' or
    'restart' to fail.

2)  If find_first_interface_address() was unable to detect an address,
    then Shorewall 4.4.8 would issue an obscure message
    (startup_error: command not found) and continue.

    Now, a meaningful error message is produced and the calling process
    stops.

3)  If LOG_VERBOSITY=0 in shorewall.conf, then when the compiled script
    was executed, messages such as the following would be issued:

       /var/lib/shorewall6/.restart: line 65: [: -gt: unary operator
                                              expected

4)  With optimize 4, if an unnecessary NONAT rule was included in
    /etc/shorewall/rules (there was no DNAT or REDIRECT rule with the
    same source zone), then 'shorewall start' and/or 'shorewall restart'
    could fail with invalid iptables-restore input.

5)  The tarball installers now check for the presence of the CLI
    program (/sbin/shorewall, /sbin/shorewall6, etc) to determine if a
    fresh install or an upgrade should be performed. Previously, the
    installers used the presense of the configuration directory
    (/etc/shorewall, /etc/shorewall6, etc.) which led to incomplete
    installations where there was an existing configuration directory.

6)  The fallback.sh scripts have been removed from Shorewall-lite,
    Shorewall6, and Shorewall6-lite. These scripts no longer work and
    should have been removed in 4.4.0.

7)  The -lite products previously were inconsistent in how they
    referred to their startup log. Some references included '-lite'
    where some did not. This was particularly bad in the case of the
    Shorewall-lite logrotate file which duplicated the name used by the
    Shorewall package. This inconsistency could cause logrotate to
    fail if both packages were installed.

8)  Two additional problems with optimize 4 have been corrected. One
    manifested as invalid iptables-restore input involving the 'tcpre'
    mangle chain. The other involved wildcard interface names (those
    ending in '+') and would likely also result in invalid
    iptables-restore input.

9)  Previously, Shorewall would set up infrastructure to handle traffic
    from the firewall to bport zones. Such infrastructure could never
    be used. Now, Shorewall avoids setting up these unneeded chains
    and/or rules.

10) If optimization level 2 and there were no OUTPUT rules and the only
    effective output policy was $FW->all ACCEPT, then the OUTPUT chain
    was empty and no packets could be sent.

11) If find_first_interface_address() was called in the params file, a
    fatal error occured on start/restart.

12) The following valid configuration produced invalid
    iptables-restore input with optimization level 4.

    /etc/shorewall/interfaces:

    #ZONE      INTERFACE       BROADCAST      OPTIONS
    vpn	       tun+	       -

    /etc/shorewall/masq:

    #INTERFACE	SOURCE		ADDRESS		PROTO	PORT
    tun0	192.168.1.0/24

    Use of tunN in the nat and netmap files also produced invalid
    iptables-restore input.

2)  '/sbin/shorewall version -a' now shows the versions of all installed
    Shorewall packages.

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

1)  The compiler now auto-detects bridges for the purpose of setting
    the 'routeback' option. Auto-detection is disabled when compiling
    for export (-e option); note that -e is implicit in the 'load' and
    'reload' commands.

2)  When 'trace' is specified on a command that involves the compiler
    (e.g., shorewall trace check), the compiler now creates a trace to
    standard output.

    Trace entries are of three types:

    Input  --- begin with IN===>.     Input read from configuration
                                      files. Comments have been
                                      stripped, continuation lines
                                      combined and shell variables
                                      expanded.

    Output --- begin with GS----->.   Text written to the generated
                                      script.

    Netfilter -- begin with NF-(x)->. Updates to the compiler's chain
                                      table, where 'x' is one of the
                                      following:

        N - Create a chain.
	A - Append a rule to a chain.
	R - Replace a rule in a chain.
	I - Inserted a rule into a chain.
	T - Shell source text appended/inserted into a chain --
            converted into rules at run-time.
	D - Deleted Rule from a chain; note that this causes the
	    following rules to be renumbered.
	X - Deleted a chain
	P - Change a built-in chains policy. Chains in the filter table
	    are created with a DROP policy. All other builtin chains
	    have policy ACCEPT.
	!   Followed by one or more of the following to indicate that
            the operation is not allowed on the chain.

	    O - Optimize
	    D - Delete
	    M - Move rules

    Netfilter trace records indicate the table and chain being
    changed. If the change involves a particular rule, then the rule
    number is also included.

    Example (append the first rule to the filter FORWARD chain):

	NF-(A)-> filter:FORWARD:1 ...

    If the trace record involves the chain itself, then no rule number
    is present.

    Example (Delete the mangle tcpost chain):

	NF-(X)-> mangle:tcpost

3)  Thanks to Vincent Smeets, there is now an IPv6 mDNS macro.

4)  Optimize 8 has been added. This optimization level eliminates
    duplicate chains. So to set all possible optimizations, specify
    OPTIMIZE=15.

5)  The command-line tools now support 'show log <regex>' where <regex>
    is a regular expression to search for in the LOGFILE. The command
    searches the current LOGFILE for Netfilter messages matching the
    supplied regex.

6)  There are some instances where a bridge with no IP address is
    configured. Prior to Shorewall 4.4.9, this required the following:

    /etc/shorewall/interfaces:
    #ZONE	INTERFACE	BROADCAST	OPTIONS
    dummy	br0		-		routeback

    /etc/shorewall/policy:
    #SOURCE	DEST		POLICY
    dummy	all		DROP
    all		dummy		DROP

    Beginning in this release, a single entry will suffice:

    /etc/shorewall/interfaces:
    #ZONE	INTERFACE	BROADCAST	OPTIONS
    -		br0		-		bridge

7)  The generated ruleset now uses conntrack match for state matching,
    if it is available.

8)  In /etc/shorewall/routestopped, the 'routeback' option is assumed
    if the interface has 'routeback' specified (either explicitly or
    detected).

9)  Apple Macs running OS X may now be used as a Shorewall
    administrative system. Simply install using the tarball installer.

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

1)  A CONTINUE rule specifying a log level would cause the compiler to
    generate an incorrect rule sequence. The packet would be logged
    but the CONTINUE action would not occur.

2)  If multiple entries were present in /etc/shorewall/tcdevices and
    globally unique class numbers were not explicitly specified in
    /etc/shorewall/tcclasses, then 'shorewall start' would fail with a
    diagnostic such as:

    Setting up Traffic Control...
    RTNETLINK answers: File exists
      ERROR: Command "tc qdisc add dev eth1 parent 2:2 handle 2: sfq quantum
             1500 limit 127 perturb 10" Failed
    Processing /etc/shorewall/stop ...

3)  Previously, when a low per-IP rate limit (such as 1/hour) was
    specified, the effective enforced rate was much higher
    (approximately 6/min). The Shorewall compiler now configures the
    hashlimit table idle timeout based on the rate units (min, hour,
    ...) so that the rate is more accurately enforced.

    As part of this change, a unique hash table name is assigned to
    each per-IP rate limiting rule that does not specify a table name
    in the rule. The assigned names are of the form 'shorewallN' where
    N is an integer. Previously, all such rules shared a single
    'shorewall' table which lead to unexpected results.

4)  All versions of Shorewall-perl mishandle per-IP rate limiting in
    REDIRECT, DNAT and ACCEPT+ rules. The effective rate and burst are
    1/2 of the values given in the rule.

5)  Detection of the 'Old hashlimit match' capability was broken in
    /sbin/shorewall, /sbin/shorewall-lite and in the IPv4 version of
    shorecap.

6)  On older distributions such as RHEL5 and derivatives, Shorewall
    would fail to start if a TYPE was specified in
    /etc/shorewall/tcinterfaces and LOAD_HELPERS_ONLY had been
    specified in /etc/shorewall/shorewall.conf.

7)  The Debian init scripts are modified to include $remote_fs in the
    Required-start and Required-stop specifications.

8)  Previously, when a supported command failed, the Debian Shorewall
    init script would still return a success (zero) exit status. It now
    returns a failure status (1) when the command fails.

9)  Previously, if a queue number was specified in an NFQUEUE policy
    (e.g., NFQUEUE(0)), invalid iptables-restore input would be
    generated.

10) Previously, with optimization 4, users of ipsec on older releases
    such as RHEL5 and CentOS, could encounter an error similar to this
    one:

    Running /sbin/iptables-restore...
    iptables-restore v1.3.5: Unknown arg `out'
    Error occurred at line: 93
    Try `iptables-restore -h' or 'iptables-restore --help' for more
        information.
    	ERROR: iptables-restore Failed. Input is in
               /var/lib/shorewall/.iptables-restore-input

11) Previously, with optimization 4, the 'blacklst' chain could be
    optimized away. If the blacklist file was then changed and a
    'shorewall refresh' executed, those new changes would not be included
    in the active ruleset.

12) In 4.4.7, it was documented that setting the 'bridge' option in an
    interfaces file entry also set 'routeback'. That feature was
    incomplete with the result that 'routeback' still needed to be
    specified.

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

1)  To avoid variable name collisions, a number of shell variable names
    that Shorewall uses and that are in all capital letters have been
    changed. The following variables are now safe to use in your
    /etc/shorewall/params file and in your extension scripts:

        DEBUG
	ECHO_E
	ECHO_N
	EXPORT
	FAST
	HOSTNAME
	IPT_OPTIONS
	NOROUTES
	PREVIEW
	PRODUCT
	PROFILE
	PURGE
	RECOVERING
	RESTOREPATH
	RING_BELL
	STOPPING
	TEST
	TIMESTAMP
	USE_VERBOSITY
	VERBOSE
	VERBOSE_OFFSET
	VERSION

    See Migration Issue 14 above for additional information.

2)  The Shorewall and Shorewall6 installers now accept a '-s' (sparse)
    option. That option causes only shorewall.conf to be installed in
    /etc/shorewall/.

3)  An OpenPGP HTTP Keyserver Protocol (HKP) macro (macro.HKP) has been
    contributed.

4)  In an attempt to help those who don't read the documentation, the
    compiler now flags apparent use of '-' as a port range separator
    with an error message.

    Example:

    /etc/shorewall/rules

       #ACTION    SOURCE     DEST      PROTO    DEST
       #                                        PORT(S)
       ACCEPT	  net        fw        tcp      21-22

    Resulting error message

       ERROR: The separator for a port range is ':', not '-' (21-22) :
              /etc/shorewall/rules (line 3)

5)  Support has been added for UDPLITE (proto 136) in that DEST PORT(S)
    and SOURCE PORT(S) may now be specified for that protocol.

6)  If a runtime error occurs during a 'start' or 'restart' operation
    but a saved configuration is successfully restored, a subsequent
    'status' command now gives the detailed status as 'Restored from
    <filename>' rather than 'Started'; <filename> is the saved script
    used to restore the configuration.

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

1)  The tcinterfaces and tcpri files are now installed by the
    installer and are included in the rpm.

2)  An invalid octal number (e.g., 080) appearing in a port list
    resulted in a perl error message.

    As part of this fix, both hex and octal numbers are now accepted
    for protocol and port numbers.

3)  In 4.4.6, if a system:

    a) Had mangle table support.
    b) Had a FORWARD chain in the mangle table.
    c) Did not have MARK Target support.

    then 'shorewall start' would fail.

4)  Previously, the 'nosmurfs' option was ignored in IPv6
    compilations. As part of this fix, 'nosmurfs' handling when
    SMURF_LOG_LEVEL is specified has been improved for both IPv4 and
    IPv6.

5)  Previously, specifying a TYPE in /etc/shorewall/tcinterfaces would
    cause start/restart to fail on systems lacking 'flow' classifier
    support. In Shorewall 4.4.7, we detect the ability of the 'tc'
    utility to support that classifier.

    There are two caveats:

    - 'tc' may support 'flow' but the kernel does not. In that case,
      start/restart will still fail.

    - If you use a capabilities file, you will need to regenerate the
      file using shorewall-lite 4.4.7 in order for 'flow' to be
      accurately detected. If you do not regenerate the file, the
      compiler will use other hints to try to determine if 'flow' is
      available.

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

1)  The OPTIMIZE option value is now a bit-map with each bit
    controlling a separate set of optimizations.

    - The low-order bit (value 1) controls optimizations available in
      earlier releases. We refer to this optimization as "optimization
      1".

    - The next bit (value 2) suppresses superfluous ACCEPT rules in a
      policy chain that implements an ACCEPT policy. Any ACCEPT rules
      that immediately preceed the final blanket ACCEPT rule in the
      chain are now omitted. We refer to this optimization as
      "optimization 2".

    - The next bit (value 4 or "optimization 4") enables the following
      additional optimizations:

      a) Empty chains are optimized away.
      b) Chains with one rule are optimized away.
      c) If a built-in chain has a single rule that branches to a
         second chain, then the rules from the second chain are moved
         to the built-in chain and the target chain is omitted.
      d) Chains with no references are deleted.
      e) Accounting chains are subject to optimization if the new
         OPTIMIZE_ACCOUNTING option is set to 'Yes' (default is 'No').
      f) If a chain ends with an unconditional branch to a second chain
         (other than to 'reject'), then the branch is deleted from the
         first chain and the rules from the second chain are appended
         to it.

      The following chains are exempted from optimization 4:

    	  action chains (user-created).
    	  accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
    	  dynamic
	  forwardUPnP
	  logdrop
	  logreject
	  rules chains (those of the form zonea2zoneb or zonea-zoneb).
	  UPnP (nat table).

    To enable all possible optimizations, set OPTIMIZE to 7 (1 + 2 +
    4).

2)  Shorewall now combines identical logging chains. Previously, a
    separate chain was created for each logging rule.

3)  Beginning with Shorewall 4.4.7, accounting can be disabled by
    setting ACCOUNTING=No in shorewall.conf. This allows you to keep a
    set of accounting rules configured in /etc/shorewall/accounting and
    to then enable and disable them by simply toggling the setting of
    ACCOUNTING.

    Similarly, dynamic blacklisting can be disabled by setting
    DYNAMIC_BLACKLIST=No. This saves a jump rule in the INPUT
    and FORWARD filter chains..

4)  Shorewall can now automatically assign mark values to providers in
    cases where 'track' is specified (or TRACK_PROVIDERS=Yes) but
    packet marking is otherwise not used for directing connections to a
    particular provider. Simply specify '-' in the MARK column and
    Shorewall will automatically assign a mark value.

5)  Support for TPROXY has been added. See
    http://www.shorewall.net/Shorewall_Squid_Usage.html#TPROXY.

6)  Traditionally, Shorewall has loaded all modules that could possibly
    be needed twice; once in the compiler, and once when the generated
    script is initialized. The latter can be a time-consuming process
    on slow hardware.

    Beginning with 4.4.7, there is a LOAD_HELPERS_ONLY option in
    shorewall.conf. For existing users, LOAD_HELPERS_ONLY=No is the
    default.

    For new users that employ the sample configurations,
    LOAD_HELPERS_ONLY=Yes will be the default. That setting causes only
    a small subset of modules to be loaded; it is assumed that the
    remaining modules will be autoloaded. Additionally, capability
    detection in the compiler is deferred until each capability is
    actually used. As a consequence, no modules are autoloaded
    unnecessarily.

    Modules loaded when LOAD_HELPERS_ONLY=Yes are the protocol
    helpers. These cannot be autoloaded.

    In addition, the nf_conntrack_sip module is loaded with
    sip_direct_media=0. This setting is slightly less secure than
    sip_direct_media=1, but it solves many VOIP problems that users
    routinely encounter.

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

1)  A 'feature' of xtables-addons when applied to Debian Lenny causes
    extra /31 networks to appear for nethash sets in the output of
    "ipset -L" and "ipset -S". A hack has been added to prevent these
    from being saved when Shorewall is saving IPSETS during 'stop'.

    As part of this change, the generated script is more careful about
    verifying the existence of the correct ipset utility before using
    it to save the contents of the sets.

2)  The mDNS macro previously did not include IGMP (protocol 2) and it
    did not specify the mDNS multicast address (224.0.0.251). These
    omissions have been corrected.

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

1)  In kernel 2.6.31, the handling of the rp_filter interface option was
    changed incompatibly. Previously, the effective value was determined
    by the setting of net.ipv4.config.dev.rp_filter logically ANDed with
    the setting of net.ipv4.config.all.rp_filter.

    Beginning with kernel 2.6.31, the value is the arithmetic MAX of
    those two values.

    Given that Shorewall sets net.ipv4.config.all.rp_filter to 1 if
    there are any interfaces specifying 'routefilter', specifying
    'routefilter' on any interface has the effect of setting the option
    on all interfaces.

    To allow Shorewall to handle this issue, a number of changes were
    necessary:

    a)  There is no way to safely determine if a kernel supports the
        new semantics or the old so the Shorewall compiler uses the
        kernel version reported by uname.

    b)  This means that the kernel version is now recorded in
        the capabilities file. So if you use capabilities files, you
        need to regenerate the files with Shorewall[-lite] 4.4.6 or
        later.

    c)  If the capabilities file does not contain a kernel version,
        the compiler assumes version 2.6.30 (the old rp_filter
        behavior).

    d)  The ROUTE_FILTER option in shorewall.conf now accepts the
    	following values:

	0 or No  - Shorewall sets net.ipv4.config.all.rp_filter to 0.
	1 or Yes - Shorewall sets net.ipv4.config.all.rp_filter to 1.
	2        - Shorewall sets net.ipv4.config.all.rp_filter to 2.
	Keep	 - Shorewall does not change the setting of
	           net.ipv4.config.all.rp_filter if the kernel version
		   is 2.6.31 or later.

	The default remains Keep.

    e)  The 'routefilter' interface option can have values 0,1 or 2. If
    	'routefilter' is specified without a value, the value 1 is
    	assumed.

2)  SAVE_IPSETS=Yes has been resurrected but in a different form. With
    this setting, the contents of your ipsets are saved during 'shorewall
    stop' and 'shorewall save' and they are restored during 'shorewall
    start' and 'shorewall restore'. Note that the contents may only be
    restored during 'restore' if the firewall is currently in the
    stopped state and there are no ipsets currently in use. In
    particular, when 'restore' is being executed to recover from a
    failed start/restart, the contents of the ipsets are not changed.

    When SAVE_IPSETS=Yes, you may not include ipsets in your
    /etc/shorewall/routestopped configuration.

3)  IPv6 addresses following a colon (":") may either be surrounded by
    <..> or by the more standard [..].

4)  A DHCPfwd macro has been added that allows unicast DHCP traffic to
    be forwarded through the firewall. Courtesy of Tuomo Soini.

5)  Shorewall (/sbin/shorewall) now supports a 'show macro' command:

    	      shorewall show macro <macro>

    Example:

    	      shorewall show macro LDAP

    The command displays the contents of the macro.<macro> file.

6)  You may now preview the generated ruleset by using the '-r' option
    to the 'check' command (e.g., "shorewall check -r").

    The output is a shell script fragment, similar to the way it
    appears in the generated script.

7)  It is now possible to enable a simplified traffic shaping
    facility by setting TC_ENABLED=Simple in shorewall.conf.

    See http://www.shorewall.net/simple_traffic_shaping.html for
    details.

8)  Previously, when TC_EXPERT=No, packets arriving through 'tracked'
    provider interfaces were unconditionally passed to the PREROUTING
    tcrules. This was done so that tcrules could reset the packet mark
    to zero, thus allowing the packet to be routed using the 'main'
    routing table. Using the main table allowed dynamic routes (such as
    those added for VPNs) to be effective.

    The route_rules file was created to provide a better alternative
    to clearing the packet mark. As a consequence, passing these
    packets to PREROUTING complicates things without providing any real
    benefit.

    Beginning with this release, when TRACK_PROVIDERS=Yes and TC_EXPERT=No,
    packets arriving through 'tracked' interfaces will not be passed to
    the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in
    4.4.3, this change should be transparent to most, if not all, users.

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

1)  The change which removed the 15 port limitation on
    /etc/shorewall/routestopped was incomplete. The result was that if
    more than 15 ports were listed, an error was generated.

2)  If any interfaces had the 'bridge' option specified, compilation
    failed with the error:

    Undefined subroutine &Shorewall::Rules::match_source_interface called
    at /usr/share/shorewall/Shorewall/Rules.pm line 2319.

3)  The compiler now flags port number 0 as an error in all
    contexts. Previously, port 0 was allowed with the result that
    invalid iptables-restore input could be generated in some cases.

4)  The 'show policies' command now works in Shorewall6 and
    Shorewall6-lite.

5)  Traffic shaping modules from /lib/modules/<version>/net/sched/ are
    now correctly loaded. Previously, that directory was not
    searched. Additionally, Shorewall6 now tries to load the cls_flow
    module; previously, only Shorewall attempts to load that module.

6)  The Shorewall6-lite shorecap program was previously including the
    IPv4 base library rather than the IPv6 version. Also, Shorewall6
    capability detection was determing the availablity of the mangle
    capability before it had determined if ip6tables was installed.

7)  The setting of MODULE_SUFFIX was previously ignored except when
    compiling for export.

8)  Detection of the Enhanced Reject capability in the compiler was
    broken for IPv4 compilations.

9)  The 'reload -c' command would ignore the setting of DONT_LOAD in
    shorewall.conf. The 'reload' command without '-c' worked as
    expected.

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

1)  Shorewall now allows DNAT rules that change only the destination
    port.

    Example:

	DNAT	loc	net::456	udp	234

    That rule will modify the destination port in UDP packets received
    from the 'loc' zone from 456 to 234. Note that if the destination
    is the firewall itself, then the destination port will be rewritten
    but that no ACCEPT rule from the loc zone to the $FW zone will have
    been created to handle the request. So such rules should probably
    exclude the firewall's IP addresses in the ORIGINAL DEST column.

2)  Systems that do not log Netfilter messages locally can now set
    LOGFILE=/dev/null in shorewall.conf.

3)  The 'shorewall show connections' and 'shorewall dump' commands now
    display the current number of connections and the max supported
    connections.

    Example:

	shorewall show connections
    	Shorewall 4.5.0 Connections (62 out of 65536) at gateway - Sat ...

    In that case, there were 62 current connections out of a maximum
    number supported of 65536.

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

1)  In some simple one-interface configurations, the following Perl
    run-time error messages were issued:

      Generating Rule Matrix...
      Use of uninitialized value in concatenation (.) or string at
      /usr/share/shorewall/Shorewall/Chains.pm line 649.
      Use of uninitialized value in concatenation (.) or string at
      /usr/share/shorewall/Shorewall/Chains.pm line 649.
      Creating iptables-restore input...

2)  The Shorewall operations log (specified by STARTUP_LOG) is now
    secured 0600.

3)  Previously, the compiler generated an incorrect test for interface
    availability in the generated code for adding route rules. The
    result was that the rules were always added, regardless of the
    state of the provider's interface. Now, the rules are only added
    when the interface is available.

4)  When TC_WIDE_MARKS=Yes and class numbers are not explicitly
    specified in /etc/shorewall/tcclasses, duplicate class numbers
    result. A typical error message is:

    	    ERROR: Command "tc class add dev eth3 parent 1:1 classid
    	    1:1 htb rate 1024kbit ceil 100000kbit prio 1 quantum 1500"
    	    Failed

    Note that the class ID of the class being added is a duplicate of
    the parent's class ID.

    Also, when TC_WIDE_MARKS=Yes, values > 255 in the MARK column of
    /etc/shorewall/tcclasses were rejected.

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

1)  The Shorewall packages now include a logrotate configuration file.

2)  The limit of 15 entries in a port list has been relaxed in
    /etc/shorewall/routestopped.

3)  The following seemingly valid configuration produces a fatal
    error reporting "Duplicate interface name (p+)"

    /etc/shorewall/zones:

       #ZONE		TYPE
       fw		firewall
       world		ipv4
       z1:world		bport4
       z2:world		bport4

    /etc/shorewall/interfaces:

       #ZONE		INTERFACE	BROADCAST	OPTIONS
       world		br0		-		bridge
       world		br1		-		bridge
       z1		br0:p+
       z2		br1:p+

    This error occurs because the Shorewall implementation requires
    that each bridge port must have a unique name.

    To work around this problem, a new 'physical' interface option has
    been created. The above configuration may be defined using the
    following in /etc/shorewall/interfaces:

       #ZONE		INTERFACE	BROADCAST	OPTIONS
       world		br0		-		bridge
       world		br1		-		bridge
       z1		br0:x+		-		physical=p+
       z2		br1:y+		-		physical=p+

    In this configuration, 'x+' is the logical name for ports p+ on
    bridge br0 while 'y+' is the logical name for ports p+ on bridge
    br1.

    If you need to refer to a particular port on br1 (for example
    p1023), you write it as y1023; Shorewall will translate that name
    to p1023 when needed.

    It is allowed to have a physical name ending in '+' with a logical
    name that does not end with '+'. The reverse is not allowed; if the
    logical name ends in '+' then the physical name must also end in
    '+'.

    This feature is not restricted to bridge ports. Beginning with this
    release, the interface name in the INTERFACE column can be
    considered a logical name for the interface, and the actual
    interface name is specified using the 'physical' option. If no
    'physical' option is present, then the physical name is assumed to
    be the same as the logical name. As before, the logical interface
    name is used throughout the rest of the configuration to refer to
    the interface.

4)  Previously, Shorewall has used the character '2' to form the name
    of chains involving zones and/or the word 'all' (e.g., fw2net,
    all2all). When zones names are given numeric suffixes, these
    generated names are hard to read (e.g., foo1232bar). To make these
    names clearer, a ZONE2ZONE option has been added.

    ZONE2ZONE has a default value of "2" but can also be given the
    value "-" (e.g., ZONE2ZONE="-") which causes Shorewall to separate
    the two parts of the name with a hyphen (e.g., foo123-bar).

5)  Only one instance of the following warning is now generated;
    previously, one instance of a similar warning was generated for
    each COMMENT encountered.

	COMMENTs ignored -- require comment support in iptables/Netfilter

6)  The shorewall and shorewall6 utilities now support a 'show
    policies' command. Once Shorewall or Shorewall6 has been restarted
    using a script generated by this version, the 'show policies'
    command will list each pair of zones and give the applicable
    policy. If the policy is enforced in a chain, the name of the chain
    is given.

    Example:

	net 	=>	loc	DROP using chain net2all

    Note that implicit intrazone ACCEPT policies are not displayed for
    zones associated with a single network where that network
    doesn't specify 'routeback'.

7)  The 'show' and 'dump' commands now support an '-l' option which
    causes chain displays to include the rule number of each rule.

    (Type 'iptables -h' and look for '--line-number')

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

1.  Previously, if 'routeback' was specified in /etc/shorewall/routestopped:

    a) 'shorewall check' produced an internal error
    b) The 'routeback' option didn't work

2)  If an alias IP address was added and RETAIN_ALIASES=No in
    shorewall.conf, then a compiler internal error resulted.

3)  Previously, the generated script would try to detect the values
    for all run-time variables (such as IP addresses), regardless of
    what command was being executed. Now, this information is only
    detected when it is needed.

4)  Nested zones where the parent zone was defined by a wildcard
    interface (name ends with +) in /etc/shorewall/interfaces did
    not work correctly in some cases.

5)  IPv4 addresses embedded in IPv6 (e.g., ::192.168.1.5) were
    incorrectly reported as invalid.

6)  Under certain circumstances, optional providers were not detected
    as being usable.

    Additionally, the messages issued when an optional provider was not
    usable were confusing; the message intended to be issued when the
    provider shared an interface ("WARNING: Gateway <gateway> is not
    reachable -- Provider <name> (<number>) not Added") was being
    issued when the provider did not share an interface. Similarly, the
    message intended to be issued when the provider did not share an
    interface ("WARNING: Interface <interface> is not usable --
    Provider <name> (<number>) not Added") was being issued when the
    provider did share an interface.

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

1)  On Debian systems, a default installation will now set
    INITLOG=/dev/null in /etc/default/shorewall. In all configurations,
    the default values for the log variables are changed to:

    	STARTUP_LOG=/var/log/shorewall-init.log
	LOG_VERBOSITY=2

    The effect is much the same as the old defaults, with the exception
    that:

	a) Start, stop, etc. commands issued through /sbin/shorewall
	   will be logged.
	b) Logging will occur at maximum verbosity.
	c) Log entries will be date/time stamped.

    On non-Debian systems, new installs will now log all Shorewall
    commands to /var/log/shorewall-init.log.

2)  A new TRACK_PROVIDERS option has been added in shorewall.conf.
    The value of this option becomes the default for the 'track'
    provider option in /etc/shorewall/providers.

3)  A new 'limit' option has been added to
    /etc/shorewall/tcclasses. This option specifies the number of
    packets that are allowed to be queued within the class. Packets
    exceeding this limit are dropped. The default value is 127 which is
    the value that earlier versions of Shorewall used.  The option is
    ignored with a warning if the 'pfifo' option has been specified.

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

1)  Detection of Persistent SNAT was broken in the rules compiler.

2)  Initialization of the compiler's chain table was occurring before
    shorewall.conf had been read and before the capabilities had been
    determined. This could lead to incorrect rules and Perl runtime
    errors.

3)  The 'shorewall check' command previously did not detect errors in
    /etc/shorewall/routestopped.

4)  In earlier versions, if a file with the same name as a built-in
    action were present in the CONFIG_PATH, then the compiler would
    process that file like it was an extension script.

    The compiler now ignores the presence of such files.

5)  Several configuration issues which previously produced an error or
    warning are now handled differently.

    a)  MAPOLDACTIONS=Yes and MAPOLDACTIONS= in shorewall.conf are now
        handled as they were by the old shell-based compiler. That is,
        they cause pre-3.0 built-in actions to be mapped automatically
        to the corresponding macro invocation.

    b)  SAVE_IPSETS=Yes no longer produces a fatal error -- it is now a
        warning.

    c)  DYNAMIC_ZONES=Yes no longer produces a fatal error -- it is now
        a warning.

    d)  RFC1918_STRICT=Yes no longer produces a fatal error -- it is now
        a warning.

6)  Previously, it was not possible to specify an IP address range in
    the ADDRESS column of /etc/shorewall/masq. Thanks go to Jessee
    Shrieve for the patch.

7)  The 'wait4ifup' script included for Debian compatibility now runs
    correctly with no PATH.

8)  The new per-IP LIMIT feature now works with ancient iptables
    releases (e.g., 1.3.5 as found on RHEL 5). This change required
    testing for an additional capability which means that those who use
    a capabilities file should regenerate that file after installing
    4.4.2.

9)  One unintended difference between Shorewall-shell and
    Shorewall-perl was that Shorewall-perl did not support the MARK
    column in action bodies. This has been corrected.

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

1)  Prior to this release, line continuation has taken precedence over
    #-style comments. This prevented us from doing the following:

    	    ACCEPT    net:206.124.146.176,\   #Gateway
	    	          206.124.146.177,\   #Mail
			  206.124.146.178\    #Server
			  		      ...

    Now, unless a line ends with '\', any trailing comment is stripped
    off (including any white-space preceding the '#'). Then if the line
    ends with '\', it is treated as a continuation line as normal.

2)  Three new columns have been added to FORMAT-2 macro bodies.

    	  MARK
	  CONNLIMIT
	  TIME

    These three columns correspond to the similar columns in
    /etc/shorewall/rules and must be empty in macros invoked from an
    action.

3)  Accounting chains may now have extension scripts. Simply place your
    Perl script in the file /etc/shorewall/<chain> and when the
    accounting chain named <chain> is created, your script will be
    invoked.

    As usual, the variable $chainref will contain a reference to the
    chain's table entry.

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

1)  If ULOG was specified as the LOG LEVEL in the all->all policy, the
    rules at the end of the INPUT and OUTPUT chains would still use the
    LOG target rather than ULOG.

2)  Using CONTINUE policies with a nested IPSEC zone was still broken
    in some cases.

3)  The setting of IP_FORWARDING has been change to Off in the
    one-interface sample configuration since forwarding is typically
    not required with only a single interface.

4)  If MULTICAST=Yes in shorewall.conf, multicast traffic was
    incorrectly exempted from ACCEPT policies.

5)  Previously, the definition of a zone that specified "nets=" in
    /etc/shorewall/interfaces could not be extended by entries in
    /etc/shorewall/hosts.

6)  Previously, "nets=" could be specified in a multi-zone interface
    definition ("-" in the ZONES column) in /etc/shorewall/zones. This
    now raises a fatal compilation error.

7)  MULTICAST=Yes generates an incorrect rule that limits its
    effectiveness to a small part of the multicast address space.

8)  Checking for zone membership has been tighened up. Previously,
    a zone could contain <interface>:0.0.0.0/0 along with other hosts;
    now, if the zone has <interface>:0.0.0.0/0 (even with exclusions),
    then it may have no additional members in /etc/shorewall/hosts.

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

1)  To replace the SAME keyword in /etc/shorewall/masq, support has
    been added for 'persistent' SNAT. Persistent SNAT is required when
    an address range is specified in the ADDRESS column and when you
    want a client to always receive the same source/destination IP
    pair. It replaces SAME: which was removed in Shorewall 4.4.0.

    To specify persistence, follow the address range with
    ":persistent".

    Example:

    #INTERFACE	SOURCE	   ADDRESS
    eth0	0.0.0.0/0  206.124.146.177-206.124.146.179:persistent

    This feature requires Persistent SNAT support in your kernel and
    iptables.

    If you use a capabilities file, you will need to create a new one
    as a result of this feature.

    WARNING: Linux kernels beginning with 2.6.29 include persistent
    SNAT support. If your iptables supports persistent SNAT but your
    kernel does not, there is no way for Shorewall to determine that
    persistent SNAT isn't going to work. The kernel SNAT code blindly
    accepts all SNAT flags without verifying them and returns them to
    iptables when asked.

2)  A 'clean' target has been added to the Makefiles. It removes backup
    files (*~ and .*~).

3)  The meaning of 'full' has been redefined when used in the context
    of a traffic shaping sub-class. Previously, 'full' always meant the
    OUT-BANDWIDTH of the device. In the case of a sub-class, however,
    that definition is awkward to use because the sub-class is limited
    by the parent class.

    Beginning with this release, 'full' in a sub-class definition
    refers to the specified rate defined for the parent class. So
    'full' used in the RATE column refers to the parent class's RATE;
    when used in the CEIL column, 'full' refers to the parent class's
    CEIL.

    As part of this change, the compiler now issues a warning if the
    sum of the top-level classes' RATEs exceeds the OUT-BANDWIDTH of
    the device. Similarly, a warning is issued if the sum of the RATEs
    of a class's sub-classes exceeds the rate of the CLASS.

4)  When 'nets=<network>' or 'nets=(<net1>,<net2>,...) is specified in
    /etc/shorewall/interfaces, multicast traffic will now be sent to
    the zone along with limited broadcasts.

5)  A flaw in the parsing logic for the zones file allowed most zone
    types containing the character string 'ip' to be accepted as a
    synonym for 'ipv4' (or ipv6 if compiling an IPv6 configuration).

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

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. Includes everything needed
                   to create an IPv4 firewall.

		   Shorewall-shell is no longer available.

    - 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 you 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 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.

    As always, /var/lib/shorewall[6] is the default directory which may
    be overridden using the /etc/shorewall[6]/vardir file.

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.

    See http://www.shorewall.net/Dynamic.html for information about
    this feature and for instructions for installing xtables-addons on
    your firewall.

    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 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. Dynamic information includes IP
    addresses, default gateways, networks routed through an interface,
    etc. If any of those steps fail, an error message is generated and
    the state of the firewall is not changed.

7)  To improve the readability of 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 -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 shorewall6.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 of 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' was used when
      there were 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' and 'shorewall6 compile' commands, 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 (see the
    Migration Considerations above).

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 claimed to be 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.

28) A 'flow=<keys>' option has been added to the
    /etc/shorewall/tcclasses OPTIONS column.

    Shorewall attaches an SFQ queuing discipline to each leaf HTB
    and HFSC class. SFQ ensures that each flow gets equal access to the
    interface. The default definition of a flow corresponds roughly to
    a Netfilter connection. So if one internal system is running
    BitTorrent, for example, it can have lots of 'flows' and can thus
    take up a larger share of the bandwidth than a system having only a
    single active connection. The flow classifier (module cls_flow)
    works around this by letting you define what a 'flow' is.

    The clasifier must be used carefully or it can block off all
    traffic on an interface!

    The flow option can be specified for an HTB or HFSC leaf class (one
    that has no sub-classes). We recommend that you use the following:

    	Shaping internet-bound traffic: flow=nfct-src
	Shaping traffic bound for your local net: flow=dst

    These will cause a 'flow' to consists of the traffic to/from each
    internal system.

    When more than one key is give, they must be enclosed in
    parenthesis and separated by commas.

    To see a list of the possible flow keys, run this command:

       tc filter add flow help

    Those that begin with "nfct-" are Netfilter connection tracking
    fields. As shown above, we recommend flow=nfct-src; that means that
    we want to use the source IP address before SNAT as the key.

    Note: Shorewall cannot determine ahead of time if the flow
    classifier is available in your kernel (especially if it was built
    into the kernel as opposed to being loaded as a
    module). Consequently, you should check ahead of time to ensure
    that both your kernel and 'tc' utility support the feature.

    You can test the 'tc' utility by typing (as root):

    	tc filter add flow help

    If flow is supported, you will see:

       Usage: ... flow ...

       	      [mapping mode]: map key KEY [ OPS ] ...
 	      [hashing mode]: hash keys KEY-LIST ...

       ...

    If flow is not supported, you will see:

       Unknown filter "flow", hence option "help" is unparsable

    If your kernel supports module autoloading, just type (as root):

       modprobe cls_flow

    If 'flow' is supported, no output is produced; otherwise, you will
    see:

       FATAL: Module cls_flow not found.

    If your kernel is not modularized or does not support module
     autoloading, look at your kernel configuration (either
    /proc/config.gz or the .config file in
    /lib/modules/<kernel-version>/build/

    If 'flow' is supported, you will see:

       NET_CLS_FLOW=m

    or

       NET_CLS_FLOW=y

    For modularized kernels, Shorewall will attempt to load
    /lib/modules/<kernel-version>/net/sched/cls_flow.ko by default.