----------------------------------------------------------------------------
		    S H O R E W A L L  4 . 5 . 1 1 . 2
                   ------------------------------------
                      D e c e m b e r  3 1 ,  2 0 1 2
----------------------------------------------------------------------------

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

4.5.11.2

1)  Corrected fix 2 from 4.5.11.1.

4.5.11.1

1)  Beginning with Shorewall 4.5.10, if the name of an optional
    interface contained one or more characters that are not valid in a
    shell function name, then the generated script would fail with a
    "syntax error: bad function name" shell diagnostic.

    That problem has been corrected so that a valid function name is
    generated.

2)  The kernel modules supplied by xtables-addons are now listed in the
    modules.xtables files. They were previously omitted.

4.5.11

1)  This release includes the defect repair from Shorewall 4.5.10.1.

----------------------------------------------------------------------------
           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)  This release expands upon the concept of 'Shorewall Variables'
    that was introduced in 4.5.10 with the creation of '@0' in SWITCH
    columns. Beginning with 4.5.10, '@0' (or '@{0}') in a SWITCH column
    expands to the name of the current chain.

    In this release, the Shorewall variables @loglevel and @logtag
    are added. These variables are only available within action bodies
    (both regular and in-line).

    Their contents are:

    @loglevel
	
	The log level specified when the action was invoked. If no
	level was specified, @loglevel expands to 'none'.

    @logtag

	The log tag specified when the action was invoked. If no tag
	was specified, @logtag expands to an empty string.

    @1, @2, ...

    	Same as $1, $2, ...

    Additionally, @chain has been added as a synonym for @0. Remember
    that, unlike $0, non-alphanumeric charaters other than '_' have
    been removed from @0.

2)  Action variables ($0, $1,...$n) and Shorewall variables are now
    available in ?IF and ?ELSIF directives.

3)  A 'nolog' option has been added to /etc/shorewall[6]/actions. This
    option causes the compiler to forego adding the log level and log
    tag from the action invocation to those rules within the body that
    do not specify a tag and/or level.

3)  An 'IGNOREUNKNOWNVARIABLES' option has been added to
    /etc/shorewall[6]/shorewall[6].conf. When set to 'Yes', this option
    instructs the compiler to expand unknown shell variables and
    action parameters to an empty string rather than raising an error.

4)  ?SET and ?RESET directives are now available:

    	 ?SET <variable>   <value>
	 ?RESET <variable>

    To cater to both Shell and Perl programmers, the <variable> may
    be entered with or without leading '$'.

    The ?SET command sets the named <variable> to the specified
    <value> where <value> is a Perl-compatible expression.

    The ?RESET command deletes the named <variable> from the compiler's
    variable table.

    Shorewall variables (@chain, @loglevel,...) and action parameters
    ($1, $2,...) are read-only and their values may not be changed
    (although action parameter values may be changed using Embedded
    Perl).

5)  This release introduces user-defined address variables. Address
    variables are used at run-time rather than at compile-time. Prior
    to this release, two types of address variables were available:

       &<interface>  	 Expands to the primary IP address of
       			 <interface>

       %<interface>	 Expands to the IP address of the default
       			 gateway out of <interface>

    The two new types added in this release are distinguished by the
    use of "{....}".

    	&{<variable>}	 Address contained in run-time variable
 			 <variable>. The named shell variable must
 			 contain a valid IP address, either from the
 			 generated script's environment or from having
 			 been set in the generated script's 'init'
 			 extension script. If the variable is empty or
 			 if its contents are not a valid IP address, an
 			 error is raised and the state of the firewall
 			 is not changed.

        %{<variable>}	 Address contained in run-time variable
			 <variable>. If the named variable is empty,
			 the generated script sets it to the all-zeros
			 address (0.0.0.0 in IPv4 and :: in IPv6). When
			 this variable appears in a SOURCE or
			 DESTINATION column of any configuration file,
			 or if it appears in the ADDRESSES column of
			 the masq file, then no rule is generated when
			 the address variable is empty. Otherwise, the
			 rule is generated with the all-zeros address
			 replacing the variable. As above, if the
			 variable is non-empty and if it does not
			 contain a valid IP address, an error is raised
			 and the firewall state is unchanged.

6)  The output of 'show [-f] capabities' is now sorted to make
    individual capabities easier to find.

7)  Beginning with this release, ?FORMAT is preferred over FORMAT for
    specifying the format of records in these configuration files:

        action.* files
	conntrack
	interface
	macro.* files
	tcrules

    While deprecated, FORMAT (without the '?') is still supported.

    Also, ?COMMENT is preferred over COMMENT for attaching comments to
    generated netfilter rules in the following files.

        accounting
       	action.* files
       	blrules files
       	conntrack
       	macro.* files
       	masq
       	nat
       	rules
       	secmarks
       	tcrules
       	tunnels

    When one of the deprecated forms is encountered, a warning message
    is issued.

    Example:

       WARNING: 'FORMAT' is deprecated in favor of '?FORMAT' -
       		consider running 'shorewall update -D'.

    As the warning indicates, 'update -D' will traverse the CONFIG_PATH
    replacing FORMAT and COMMENT lines with ?FORMAT and ?COMMENT
    directives respectively. The original version of modified files
    will be saved with a .bak suffix. 

    During the update, .bak files are skipped as are files in
    ${SHAREDIR}/shorewall and ${SHAREDIR}/shorewall6.

----------------------------------------------------------------------------
                   V.  M I G R A T I O N   I S S U E S
----------------------------------------------------------------------------

1)  If you are migrating from Shorewall 4.2.x or earlier, please see
    http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.27/releasenotes.txt

2)  The BLACKLIST section of the rules file has been eliminated. 
    If you have entries in that file section, you must move them to the
    blrules file.

3)  This version of Shorewall requires either the Digest::SHA1 or
    Digest::SHA Perl module.

        Debian: libdigest-sha1-perl or libdigest-sha-perl
	Fedora: perl-Digest-SHA1 or perl-Digest-SHA
	OpenSuSE: perl-Digest-SHA1 or perl-Digest-SHA

4)  The generated firewall script now maintains the
    /var/lib/shorewall[6][-lite]/interface.status files used by SWPING
    and by LSM.

    If you have optional providers and do not run a link monitor like
    SWPING  or LSM that updates these files, then you should remove
    /etc/shorewall[6]/isusable if it is installed.

    Beginning with Shorewall 4.5.3.1:

    - The 'disable' command stores a 1 in the interface's .status file.
    - The .status file is ignored on 'enable' but not on 'start',
      'restart', 'restore' and 'refresh'.

    This means that a disabled interface can only be re-enabled using
    the 'enable' command.

5)  The /etc/shorewall[6]/tos file is now deprecated in favor of the
    TOS() action in /etc/shorewall[6]/tcrules.

6)  The MARK/CLASSIFY column in /etc/shorewall[6]/tcrules has been
    renamed ACTION to reflect the expanded set of actions that can be
    specified in the column. There is no change to existing
    functionality.

7)  Beginning with Shorewall 4.5.2, using /etc/shorewall-lite/vardir
    and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in
    favor of the VARDIR setting in shorewallrc.

        NOTE: While the name of the variable remains VARDIR, the
              meaning is slightly different. When set in shorewallrc,
              each product (shorewall-lite, and shorewall6-lite) will
              create a directory under the specified path name to
	      hold state information.

	      Example:

		  VARDIR=/opt/var/

		  The state directory for shorewall-lite will be
		  /opt/var/shorewall-lite/ and the directory for
		  shorewall6-lite will be /opt/var/shorewall6-lite.

	      When VARDIR is set in /etc/shorewall[6]/vardir, the
	      product will save its state directly in the specified
	      directory.

    In Shorewall 4.5.8, a VARLIB variable was added to the shorewallrc
    file and the meaning of VARDIR is once again consistent. The
    default setting of VARDIR for a particular product is
    ${VARLIB}/$product. There is an entry of that form in the
    shorewallrc file. Because there is a single shorewallrc file for
    all installed products, the /etc/shorewall[6]-lite/vardir file
    provides the only means for overriding this default.

8)  Begining with Shorewall 4.5.6, the tcrules file is processed if
    MANGLE_ENABLED=Yes, independent of the setting of TC_ENABLED. This
    allows actions like TTL and TPROXY to be used without enabling
    traffic shaping.

    If you have rules in your tcrules file that you only want processed
    when TC_ENABLED is other than 'No', then enclose them in

    	 ?IF $TC_ENABLED
	 ...
	 ?ENDIF

    If they are to be processed only if TC_ENABLED=Internal, then enclose
    them in

    	 ?IF TC_ENABLED eq 'Internal'
	 ...
	 ?ENDIF

9)  Beginning with Shorewall 4.5.7, the deprecated
    /etc/shorewall[6]/blacklist files are no longer installed. Existing
    files are still processed by the compiler. Note that blacklist
    files may be converted to equivalent blrules files using
    'shorewall[6] update -b'.

10) In Shorewall 4.5.7, the /etc/shorewall[6]/notrack file was renamed
    /etc/shorewall[6]/conntrack. When upgrading to a release >= 4.5.7,
    the conntrack file will be installed along side of an existing
    notrack file. When both files exist, a compiler warning is
    generated:

       WARNING: Both notrack and conntrack exist; conntrack is ignored

    This warning may be eliminated by moving any entries in the notrack
    file to the conntrack file and removing the notrack file.

11) In Shorewall 4.5.8, the /etc/shorewall[6]/routestopped files were
    deprecated if favor of new /etc/shorewall[6]/stoppedrules
    counterparts. The new files have much more familiar and
    straightforward semantics. Once a stoppedrules file is populated,
    the compiler will process that file and will ignore the
    corresponding routestopped file.

12) In Shorewall 4.5.8, a new variable (VARLIB) was added to the
    shorewallrc file. This variable assumes the role formerly played by
    VARDIR, and VARDIR now designates the configuration directory for a
    particular product.

    This change should be transparent to all users:

    a) If VARDIR is set in an existing shorewallrc file and VARLIB is
       not, then VARLIB is set to ${VARDIR} and VARDIR is set to
       ${VARLIB}/${PRODUCT}.

    b) If VARLIB is set in a shorewallrc file and VARDIR is not, then
       VARDIR is set to ${VARLIB}/${PRODUCT}.

    The Shorewall-core installer will automatically update
    ~/.shorewallrc and save the original in ~/.shorewallrc.bak

13) Previously, the macro.SNMP macro opened both UDP ports 161 and 162 
    from SOURCE to DEST. This is against the usual practice of opening
    these ports in the opposite direction. Beginning with Shorewall
    4.5.8, the SNMP macro opens port 161 from SOURCE to DEST as before,
    and a new SNMPTrap macro is added that opens port 162 (from SOURCE
    to DEST).

14) Beginning with Shorewall 4.5.11, ?FORMAT is preferred over FORMAT
    for specifying the format of records in these configuration files:

        action.* files
	conntrack
	interface
	macro.* files
	tcrules

    While deprecated, FORMAT (without the '?') is still supported.

    Also, ?COMMENT is preferred over COMMENT for attaching comments to
    generated netfilter rules in the following files.

        accounting
       	action.* files
       	blrules files
       	conntrack
       	macro.* files
       	masq
       	nat
       	rules
       	secmarks
       	tcrules
       	tunnels

    When one of the deprecated forms is encountered, a warning message
    is issued.

    Examples:

       WARNING: 'FORMAT' is deprecated in favor of '?FORMAT' -
       		consider running 'shorewall update -D'.

       WARNING: 'COMMENT' is deprecated in favor of '?COMMENT' -
       		consider running 'shorewall update -D'.

    As the warnings indicate, 'update -D' will traverse the CONFIG_PATH 
    replacing FORMAT and COMMENT lines with ?FORMAT and ?COMMENT
    directives respectively. The original version of modified files
    will be saved with a .bak suffix. 


    During the update, .bak files are skipped as are files in
    ${SHAREDIR}/shorewall and ${SHAREDIR}/shorewall6.

----------------------------------------------------------------------------
        V I.  N O T E S  F R O M  O T H E R  4 . 5  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 . 5 . 1 0
----------------------------------------------------------------------------

1)  This release includes all defect repair included in
    4.5.9.1-4.5.9.3.

2)  Under rare circumstances, optimize level 16 could produce invalid
    iptables-restore input which would cause start/restart to fail.

3)  Before this release, the 'started' script was run prior to copying
    the temporary script file (e.g., /var/lib/shorewall/.start) to
    /var/dir/shorewall/firewall. If the script failed, the copy would
    not take place even though the firewall had started
    successfully. The script is now copied before running the 'started'
    script.

    If you compare the script generated by this release with one
    generated by a prior release, We suggest that you ignore whitespace
    changes (e.g., use the '-w' option in diff); that way, you can see
    the actual change more clearly.

4)  AUTOCOMMENT=No now works correctly; previously, it behaved the same
    as AUTOCOMMENT=Yes.

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

1)  Shorewall now treats optional non-provider interfaces in a manner
    similar to provider interfaces.

    - They may have entries in /etc/shorewall/routes.
    - They may be enabled/disabled using the 'enable' and 'disable' 
      commands.
    - Shorewall-init will simply enable an optional interface when it
      comes up and disable it when it goes down.

2)  The /etc/shorewall/secmarks and /etc/shorewall6/secmarks files now
    support the UNTRACKED state. See the manpages for details.

3)  The /etc/shorewall/conntrack and /etc/shorewall6/conntrack files
    now support a DROP target.

    It is now possible to specify 'all-' in the SOURCE column which
    generates rules for all zones that are outside of the firewall
    itself.

4)  A SWITCH column has been added to the /etc/shorewall/conntrack and
    /etc/shorewall/conntrack6 files.

5)  In a SWITCH column, the character '@' is replaced by the chain
    name (non-alphanumeric characters other than '-' and '_' are
    suppressed).

6)  An AUDIT action has been added to the /etc/shorewall/rules and
    /etc/shorewall6/rules.

7)  The audited targets (A_ACCEPT, A_DROP, etc.) are now supported in
    /etc/shorewall6/rules.

8)  An additional format (3) has been added to the conntrack file. In
    this format, zone names are not used in the SOURCE column; rather,
    a suffix in the ACTION column determines which raw-table chain the
    generated Netfilter rule will be placed in. See the manpages for
    details.

9)  A ULOG ACTION has been added to /etc/shorewall/rules.

10) Within an action body, the variable $0 now expands to the action
    chain name (including leading '%' if present).

11) 'In-line' actions are now available. An action is designated as
    in-line within /etc/shorewall[6]/actions; that file has a
    new OPTIONS column and specifying 'inline' in that column
    designates the action as in-line.

    Normally, actions are expanded into their own chain with a
    unique chain being created for each unique invocation (considering
    log level, tag and parameters). An in-line actions is expanded
    inline within the chain that invokes it. In that sense,
    in-line actions are very similar to macros.

    In-line actions differ from macros in several ways:

    a) A zone may be specified in the SOURCE and DEST columns of a
       macro, while zone names are disallowed in these columns within
       an in-line action (same as in a regular action).

    b) The name of the current chain is available in $0 within the body
       of an in-line action (also within a regular action beginning with
       Beta 3).

    c) In-line actions accept multiple parameters which are available
       in$1, $2, etc (as they are in a regular action).

    d) PARAM has no special meaning in the body of an in-line action
       ($1 serves the same purpose in an in-line action).

    e) Only FORMAT 2 is available in an in-line action.

    f) In-line actions must be defined in
       /etc/shorewall[6]/actions. Those files have been extended to
       include an OPTIONS column. The only option currently supported
       is 'in-line'.

    In-line actions differ from normal actions in that:

    a) Obviously, they are expanded in-line like a macro rather than
       being in their own chain. That means that columns in the
       invocation are merged with those in the action body in the same
       way as they are in a macro.

    b) When AUTOCOMMENT=Yes, each generated rule is commented with the
       name of an in-line action.

    c) Within an in-line action, ?BEGIN PERL ... ?END PERL does not
       have access to the special features available in action a normal
       action body.

    The compiler allows overriding the setting of 'inline' on the
    Shorewall standard actions within
    /etc/shorewall[6]/actions. Beware, however, that some of them
    don't work when in-lined so the compiler will ignore the 'inline'
    option with a warning for those actions:

    	    Broadcast
	    DropSmurfs
	    Invalid
	    NonSyn
	    RST
	    TCPFlags

12) In SWITCH columns, the named switch can now be initialized by the
    'start' command (other commands do not change switch values).

    Initialization is accomplished by adding '=0' or '=1' to the
    switch name.

    Example (using alternative rule column specification):

    #ACTION 	   SOURCE      	    DEST   ...
    NFLOG	   all		    all	   ; switch:logall=1

    The above will cause the 'logall' switch
    (/proc/net/nf_condition/logall) to be initialized to 1 (on). Note
    that netfilter provides no atomic way to define and initialize a
    switch so the loading of the ruleset and the initialization of the
    switches are distinct operations.

13) Also in SWITCH columns, the name of the current Netfilter chain
    will be substituted for '@0' and '@{0}'.

    Example (using alternative rule column specification):

    #ACTION 	   SOURCE      	    DEST   ...
    NFLOG	   net		    fw	   ; switch:@{0}_logall

    The name of the switch will be 'net2fw_logall'.

    Note 1: Non-alphanumeric characters other than '_' and '-' will be
    deleted from the chain name before substitution.

    Note 2: The chain name substituted is the one to which the rule is
    initially added. The rule may end up in a different chain due to
    optimization.

14) Optimization level 16 now suppresses duplicate rules in chains from
    all tables (it previously only suppressed duplicates in the 'raw'
    table).

    Non-adjacent rules containing 'mark', 'connmark', 'dscp', 'ecn',
    'set', 'tos' or 'u32' matches are not suppressed:

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

1)  References to the obsolete USE_ACTIONS option have been removed
    from the manpages.

2)  NFLOG has been documented for some time as a valid ACTION in the
    rules files but support for that action has never been implemented
    until this release.

3)  The Checksum Target capability detection in the rules compiler was
    broken with the result that the presence of the capability was not
    detected.

4)  If an interface named in the INTERFACE column was not defined in
    tcdevices and if the REDIRECTED column for that entry was
    non-empty, then compile-time Perl diagnostics were generated and an
    invalid firewall script was generated.

5)  When LOAD_HELPERS_ONLY=No, the 'compile' command previously left
    behind a temporary chain in the raw table.

6)  Under very rare circumstances involving exclusion in multiple
    Netfilter tables, optimization level 8 could result in
    start/restart failure or jumps to the wrong exclusion chain.

7)  4.5.9.2 broke multi-ISP on RHEL5-based systems. This release
    includes a patch from Tuomo Soini that corrects the problem.

4.5.9.2

1)  Previously, the rules in the 'routemark' chain did not specify a
    mask in the MARK target. While a mask isn't strictly necessary in
    those rules, one has been added to ally fears of those who read the
    generated ruleset.

    Note: The 'routemark' chain is used to apply provider marks to
    packets received from 'track' provider interfaces. It is traversed
    early in the mangle PREROUTING chain when no other marks have yet
    been applied to the packet.

2)  If exclusion was used with TPROXY in the tcrules file, an invalid 
    iptables ruleset was generated causing start and restart commands
    to fail when running iptables-restore.

3)  Previously, when the name of provider was the same as it's
    associated interface, the generated script contained a syntax
    error.

4.5.9.1

1)  Previously, using a wildcard interface name in a rule would result
    in this error:

      ERROR: Invalid ipset name (ppp+) : ...

    Such entries are now handled correctly.

2)  The shorewall-masq(5) manpage incorrectly stated that the SOURCE
    column may use exclusion with an interface name (e.g.,
    eth1:!1.2.3.4). That hasn't been the case for some time. To
    accomplish the same thing, do this:

       eth0	1.2.3.4	  NONAT
       eth0	eth1

    Note: Using an interface name in the SOURCE column is deprecated.

3)  Previously, if a MARK was specified for a tc class that explicitly
    specified a class number, the following spurious warning message
    was issued:

      WARNING: Class NUMBER ignored -- 
               INTERFACE <name> does not have the 'classify' option

    That warning message is no longer issued.

4)  With Shorewall 4.5.9, there were issues when the ipset utility was
    not installed, some of which prevented Shorewall from starting.

4.5.9

1)  This release contains all defect repair from Shorewall 4.5.8.2.

2)  A typo has been corrected in the shorewallrc.default file.

3)  Beginning with Shorewall 4.5.7.2, Shorewall unconditionally
    restores the provider mark as the first rule in the mangle table
    OUTPUT and PREROUTING chains. Previously, the provider mark was
    restored only if it was non-zero.

    It has become clear that some users need it one way while others
    need it the other way. To resolve this issue, a RESTORE_ROUTEMARKS
    option has been added to shorewall.conf and shorewall6.conf. When
    this option is set to Yes (the default), the 4.5.7.2 approach is
    used (always restore the mark, even if it is zero); when it is set
    to No, the pre-4.5.7.2 behavior is retained (only restore the mark
    if it is non-zero).

4)  Two error messages produced by the RST action have been
    corrected. They previously referred to errors in the NotSyn action
    rather than RST.

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

1)  Prior to this release, if a dynamic zone was associated with more
    than one interface, then Shorewall created a separate ipset for
    each interface. This meant that multiple 'add' and 'delete'
    commands might be required to change the zone composition.

    This release introduces a 'dynamic_shared' zone option. When that
    option is specified, a single ipset is generated regardless of the
    number of entries the zone has in the hosts file.

    The 'dynamic_shared' option may only be specified in the OPTIONS
    column of the zones file. 

    The syntax of the 'add' and 'delete' commands is changed for zones
    having the 'dynamic_shared' option:

    	   add <zone> <address>[,<address> ... ]

       	   delete <zone> <address>[,<address> ... ]

    Example:

        shorewall add direct 172.20.1.99

    The syntax for 'add' and 'delete' for zones not having the
    'dynamic_shared' option is unchanged.

2)  Puppet and Teredo macros have been contributed by Paul Gear.

3)  The 'show' command now supports a -b (brief) option that suppresses
    listing of rules that have zero packet count and omits chains that
    have no rules listed (Paul Gear).

4)  A CHECKSUM action has been added to the tcrules files. This action
    computes and fills in the checksum in a packet that lacks one.
    This is particularly useful if you need to work around old
    applications, such as dhcp clients, that do not work well with
    checksum offloads, but you don't want to disable checksum offload
    in your device.

    As part of this change, a new 'Checksum Target' capability has been
    added, so if you use a capabilities file, it needs to be
    re-generated after you install this release.

5)  The 'shorewall6 show routing' command now sorts the contents of
    each routing table in the same way as 'shorewall show routing'.

6)  It is now possible to specify a mark range in the ACTION column of
    the tcrules file. This causes the generated ruleset to assign marks
    in the range in round-robin fashion. As part of this change, a
    STATE column is also added that allows marks to be assigned only to
    packets that are in one of the specified states (NEW, RELATED,
    ESTABLISHED, etc.). Specifying NEW in this column along with 
    a range in the ACTION column allows for load-balancing SNAT rules
    over a number of different external addresses.

    Example:

    /etc/shorewall/tcrules

    #ACTION	SOURCE		DEST		...
    1-3:CF	eth1		172.20.1.0/24	; state=NEW

    /etc/shorewall/masq

    #INTERFACE	SOURCE		ADDRESS	...
    eth0	192.168.1.0/24  1.1.1.1	; mark=1:C
    eth0	192.168.1.0/24	1.1.1.5	; mark=2:C
    eth0	192.168.1.0/24	1.1.1.9 ; mark=3:C

    Specifying a mark range require the 'Statistics Match' capability
    in your iptables and kernel.
 
----------------------------------------------------------------------------
             P R O B L E M S  C O R R E C T E D  I N  4 . 5 . 8
----------------------------------------------------------------------------

4.5.8.2

1)  The 'shorewall show' command previously produced no output. That
    command now works with ipset versions 4 and later.

2)  The change in 4.5.8.1 that enabled industry-standard IPv4 address
    representation broke the ability to place IP ranges or IPv6 ipsets 
    in the hosts file. Those abilities have been restored.

3)  The treatment of the SYSTEMD and INITFILE shorewallrc variables has
    been inconsistent. The -lite installers ignore INITFILE when
    SYSTEMD is specified, while the other installers do not. Now,
    the -lite installers install the .service file if SYSTEMD is
    specified and they install the sysv-init script if INITFILE is
    specified. That is consistent with the behavior of the other
    installers.

4.5.8.1

1)  With ipset version 5 or later installed, the Shorewall 'add'
    command failed with this error message:

       Zone <zone>, interface <interface> does not have a dynamic
       host list"

2)  When generating ipset names for dynamic zones, the compiler was
    dropping dashes ('-') from the interface name and adding a 
    unique suffix. For example the ipset for zone 'foo' and interface
    'bar-if' might be 'foo_barif_1'. Dashes are now retained so that
    the generated set name in this example will be 'foo_bar-if'. This
    change also allows the 'add' and 'delete' commands to work
    correctly when the interface name contains one or more dashes.

    Although dash is documented as being an accepted character in ipset
    names, names containing a dash would generate an error in some
    contexts. That has also been corrected.

3)  In 4.5.8, a shell syntax error occurred when installing on a system
    running systemd. That error has been eliminated.

4.5.8

1)  This release includes the defect repair from Shorewall 4.5.7.1.

2)  The restriction that TTL and HL tcrules could only be placed in the
    FORWARD chain prevented these rules from being used to hide a router
    from traceroute[6]. It is now allowed to place these rules in the
    PREROUTING chain by following the specification with ':P' (e.g.,
    'TTL(+1):P').

3)  Previously, the macro.SNMP macro opened both UDP ports 161 and 162 
    from SOURCE to DEST. This is against the usual practice of opening
    these ports in the opposite direction. Beginning with this release,
    macro.SNMP opens port 161 from SOURCE to DEST as before, and a new
    SNMPTrap macro is added that opens port 162 (from SOURCE to
    DEST).

4)  Previously, when compiling for export, both
    /etc/shorewall/shorewall[6].conf and the shorewall[6].conf in the
    configuration directory were processed. Now, only the copy in the
    configuration directory is processed.

5)  The 'iptables_raw' module has been added to the modules.essential
    file.

6)  Several corrections have been made to the Fedora/Redhat SysV init
    script for Shorewall-init.

7)  The <directory> parameter to the 'try' command is now documented in
    the shorewall(8) and shorewall6(8) manpages.

8)  Some redundant interface-option rules have been removed in
    configurations with multiple zones configured on a single
    interface.

9)  Previously, when compiling for export, the compilation would fail
    if the setting of SHAREDIR in the firewall's shorewallrc was
    different from the setting on the admin system. Such compilations
    now succeed.

10) Earlier versions of the compiler accepted ":" as the sole contents
    of a USER/GROUP column with the result that iptables-restore
    failed. This incorrect usage now generates a compile-time error.

11) The 4.5.7 Shorewall compiler unconditionally probes for all 
    helpers, causing their corresponding modules to be loaded. Now,
    this probing will only occur when LOAD_HELERS_ONLY=No.

12) The 'conntrack' files released in Shorewall 4.5.7 contained an
    incorrect control port number for  PPTP (1729 vs. 1723). The port
    number has been corrected.

13) A typo in the PPtP macro has been corrected.

14) The compiler previously accepted TTL(-0) and HL(-0) in the ACTION
    column of tcrules, leading to a failure of the generated script. +0
    was also accepted with the same result. Now, this incorrect usage
    is flagged as an error.

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

1)  This release attempts to alleviate the confustion that results
    from different usage of the VARDIR variable name.

    Beginning with Shorewall 4.5.2, 'VARDIR' became a variable in the
    shorewallrc file with the default value '/var/lib'. This was at
    odds with the usage of VARDIR in /etc/$product/vardir, where the
    variable VARDIR holds the state directory for a particular product
    (e.g., /var/lib/shorewall). This latter usage is reflected in the
    Shorewall code which has always used VARDIR to hold the individual
    product's state directory.

    To eliminate this issue going forward, a VARLIB variable has been
    added to shorewallrc to assume the role previously filled by
    VARDIR, while VARDIR now defaults to '${VARDIR}/${PRODUCT}'.

    When a pre-4.5.8 shorewallrc file is present, VARLIB is set to
    ${VARDIR} and VARDIR is set to ${VARLIB}/${PRODUCT}. If VARLIB is
    set in the shorewallrc file and VARDIR is not, then VARDIR also
    defaults to ${VARDIR}/${PRODUCT}. When using the tarball installer,
    the existing shorewallrc file (~/.shorewallrc or
    ${SHAREDIR}/shorewallrc) will be updated and the original will be
    saved as shorewallrc.bak.

    Note that since there is only a single shorewallrc file on a
    system, the only means for overriding the ${VARLIB}/${PRODUCT}
    default setting for VARDIR is still the /etc/$product/vardir file.

2)  A new 'stoppedrules' file has been added and the 'routestopped'
    file is now deprecated. The new file is processed when
    'routestopped' does not exist or is empty. 

    See stoppedrules(5) for details about the new file.

3)  When the -e option (compile for export) is specified in the 'check'
    and 'compile' commands, the current working directory is now
    automatically included in the CONFIG_PATH.

4)  When the -e option is specified in a 'compile' command that
    specifies no script name, the default is now 'firewall' in the
    current working directory. In other words:

       shorewall compile -e

    creates 'firewall' and 'firewall.conf' in the current working
    directory. This is consistent with the behavior of the 'load' and
    'reload' commands.

5)  Multiple UID/GIDs separated by commas may now be given in the
    USER/GROUP column of the rules files.

6)  A warning message is now issued if the 'blacklist' option is	
    specified for a zone (the 'blacklist' option has been deprecated
    for several releases).

7)  A PRIORITY column has been added to the tcfilter files. See
    shorewall-tcfilters(5) and shorewall6-tcfilters(5) for details.

    As part of this change, the method of assigning priorities to
    filters where the PRIORITY is not specified has changed.
    Previously, all ipv4 filters were assigned priority 10 while
    all ipv6 filters were assigned priority 11. Now, for each device,
    the compiler maintains a "high-water priority" that has an initial
    value of 0. When a filter has no priority specified, the high-water
    priority is incremented by 1 and assigned to the filter. When a
    priority greater than the high-water priority is entered in the
    PRIORITY column, the high-water priority is set to the specified
    priority.
    
    An attempt to assign a priority value greater than 65535
    (explicitly or implicitly) raises an error.

8)  It is now possible to explicitly assign priorities to
    classification filters created by shorewall for the following:

    - Filter that classifies packets based on their firewall mark
      value.
    - Filter that classifies ACK packets via the 'tcp-ack' class
      option.
    - Filter that classifies packets based on TOS value.

    Example:

       #DEVICE   MARK    RATE:	   CEIL	  PRIORITY OPTIONS
       #	 	 DMAX:UMAX
       eth0      1:50    5*full/10 full	  1        tcp-ack:15,\
                 	 	   	  	   tos-minimize-delay:20

    In this example, the classifier filters would be evaluated in this
    order:

    - tcp-ack (priority 15)
    - tos-minimize-delay (priority 20)
    - Mark value 1 (priority 50)

    In other words, the filters are evaluated in ascending priority
    order. If one filter doesn't match, the packet is passed to the
    next filter.
    	
    See shorewall-tcclasses(5) and shorewall6-tcclasses(5) for
    additional information.

9)  The PRIORITY column in the tcclasses file is now optional for HFSC
    classes. If that priority is omitted, then an explicit priority
    must be specified for the MARK value and for the 'tcp-ack' and
    'tos*' options if those are used.

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

1)  This release includes all defect repair from Shorewall
    4.5.6.1-4.5.6.2.

2)  The command 'shorewall enable pppX' could fail with the ip diagnostic

       Error: either "to" is duplicate, or "weight" is a garbage.

    Shorewall now generates the correct ip command.

3)  Optimize level 4 could previously combine two rules that each
    specified the 'policy' match, leading to this iptables-restore
    failure:

       policy match: multiple elements but no --strict

    The optimizer now avoids combining such rules.

    While this is a long-standing defect in the optimizer, it was
    exposed by changes in Shorewall 4.5.6.

4)  There were several cases where hard-wired directory names appeared
    in the tarball installers. These have been replaced with the
    appropriate shorewallrc variables.

5)  A defect in RHEL 6.3 and derivatives causes 'shorewall show
    capabilities' to leave an empty ipset in the configuration. The
    same defect can cause the Shorewall compiler to similarly leave
    behind an empty ipset.

    This Shorewall release implements a workaround for the problem.

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

1)  A new 'rpfilter' interface option has been added. Setting this 
    option requires kernel 3.4.0 or later and iptables 1.4.14. This
    option is similar to routefilter but without the disadvantages:

    - Works with both IPv4 and IPv6
    - Uses packet marks when doing reverse path lookup so works with
      all Multi-ISP configurations.
    - Uses standard Netfilter/Shorewall log messages controlled by the
    - RPFILTER_LOG_LEVEL setting in shorewall.conf (5).
    - Disposition and auditing may be controlled using the
    - RPFILTER_DISPOSITION option in shorewall.conf (5).

    This feature adds a new 'RPFilter Match' capability; if you use a
    capabilities file, you should regenerate it using this release.

2)  Beginning with the 3.3 kernels, Netfilter supports a form of
    accounting (nfacct) that is triggered by iptables rules but that
    survives purging and/or reloading the Netfilter ruleset. Shorewall
    support for this form of accounting was added in Shorewall 4.5.7.


    As of this writing, Fedora 17 has partial support for this feature
    but not all. It is necessary to download and build the following:

    - libnetfilter_acct

    - nfacct

    The following Fedora packages are also required:

    - libnetlink and libnetlink-dev

    - libmnl and libmnl-dev

    The tarballs are available from the Netfilter download sites.

    The nfacct utility can create, delete and display nfacct
    objects. These named objects consist of a packet and byte
    counter. Packets matching those netfilter rules that use the nfacct
    match cause the packet and byte count in the object named in the
    match to be incremented.

    To use nfaccnt with Shorewall, use the NFACCT target. See
    shorewall-accounting(5) for details.

    The 'shorewall show nfacct' command is a thin wrapper around the
    'nfacct list' command and displays all objects.

3)  With the addition of the CT action to the /etc/shorewall[6]/notrack
    file, the name of the file does not accurately reflect the file's
    purpose. In this release, the name of the file has been changed to
    'conntrack'.

    The tarball installers will install 'conntrack' along side of an
    existing 'notrack' file. If the 'notrack' file is non-empty, a
    warning message is issued during compilation:

	WARNING: Non-empty notrack file (...);
	         please move its contents to the conntrack file

    This warning can be eliminated by removing the notrack file (if it
    has no entries), or by moving its entries to the conntrack file and
    removing the notrack file. Note that the conntrack file is always
    populated with rules (see enhancement 5).

    If the 'notrack' file exists and is empty, the first compilation
    will remove it with the warning:

        WARNING: Empty notrack file (...) removed

4)  'all' is now accepted as a zone name in the SOURCE column of
    shorewall-conntrack(5). As in the rules file, it means all zones.

5)  Because of the potential for attackers to subvert Netfilter helpers
    like the one for FTP, the Netfilter team are in the process of
    eliminating the automatic association of helpers to connections. In
    the 3.5 kernel, it is possible to disable this automatic
    association, and the team have announced that automatic association
    will eventually be eliminated. While it is certainly more secure to
    add explicit rules that create these associations, for Shorewall to
    require users to add those rules would present a gross
    inconvenience during a Shorewall upgrade.

    To make Shorewall and kernel upgrades as smooth as possible,
    several new features have been added in this release:

    - Shorewall will automatically disable the kernel's automatic
      association of helpers to connections on kernel 3.5 and later.

    - An automatic association of helpers with connections that
      performs the same function as in the pre-3.5 kernels has been
      added. This automatic association is controlled by the new
      AUTOHELPERS shorewall.conf option which is set to 'Yes' by
      default.

    - A HELPERS column has been added to the /etc/shorewall/rules

      In the NEW section:

        When the ACTION is ACCEPT, DNAT or REDIRECT, the specified
      	helper is automatically associated with the connection. HELPERS
      	may be specified in action files, macros and in the rules file
      	itself.

      In the RELATED section:

        The rule will only match related connections that have the
        named helper attached.

    - The standard Macros for applications requiring a helper (FTP,
      IRC, etc) have been modified to automatically specify the correct
      helper in the HELPER column.

    - HELPER is now a valid action in /etc/shorewall/rules. This action
      requires that a helper be present in the HELPER column and causes
      the specified helper to be associated with connections matching
      the rule. No destination zone should be specified in HELPER
      rules. HELPER rules allow specification of a helper for
      connections that are ACCEPTed by the applicable policy.

      Example:

	loc->net policy is ACCEPT.

	In /etc/shorewall/rules:

	   FTP(HELPER)	   loc	-

        or equivalently

	   HELPER    loc     -      tcp      21 ; helper=ftp

    - The set of enabled helpers (either by AUTOHELPERS=Yes or by the
      HELPERS column) can be taylored using the new HELPERS option in
      shorewall.conf.

    By making AUTOHELPERS=Yes the default, users can upgrade their
    systems to a 3.5+ kernel without disrupting the operation of their
    firewalls. Beyond such upgrades, we suggest setting AUTOHELPERS=No
    and follow one of two strategies:

    - Use the HELPERS column in the rules file to enable helpers as
      needed (preferred); or

    - Taylor the conntrack file to enable helpers on only those
      connections that are required.

    With either of these approaches, the list if available helpers can
    be trimmed using the HELPERS option and rules can be added to the
    RELATED section of the rules file to further restrict the effect of
    helpers.

    The implementation of these new function places conditional rules
    in the /etc/shorewall[6]/conntrack file. These rules are included
    conditionally based in the setting of AUTOHELPERS.

    Example:

       ?if $AUTOHELPERS && __CT_TARGET

       ?if __FTP_HELPER
       CT:helper:ftp	all	-	tcp	21
       ?endif
       ...
       ?endif

    __FTP_HELPER evaluates to false if the HELPERS setting is
    non-empty and 'ftp' is not listed in that setting.

    For example, if you only need FTP access from your 'loc' zone, then
    add this rule outside of the outer-most ?if....?endif shown above.

       CT:helper:ftp	loc	-	tcp	21

    For an overview of Netfilter Helpers and Shorewall's support for
    dealing with them, see

       http://www.shorewall.net/Helpers.html.

    See
    
       https://home.regit.org/netfilter-en/secure-use-of-helpers/

    for additional information.

6)  To make the spelling of the AUTO* shorewall[6].conf options
    consistent, the AUTO_COMMENT option has been renamed
    AUTOCOMMENT. AUTO_COMMENT is still accepted as an
    alias. 'shorewall[6] update' will rename the option in the updated
    .conf file.

7)  The CT:helper action in the /etc/shorewall[6]/conntrack file
    (formerly the notrack file) lacked flexibility. To allow different
    options to be specified for each helper, the syntax of the
    CT:helper action has been redesigned.

    	CT:helper:<helper>[(<option>=<value>[,...])]

    where <option> is one of:

    - ctevents
    - expevents

    Example:

       CT:helper:ftp(expevents=new)

    See shorewall-conntrack (5) for details.

8)  The deprecated /etc/shorewall[6]/blacklist files are no longer
    installed. Existing files are still processed by the compiler. Note
    that blacklist files may be converted to equivalent blrules files
    using 'shorewall[6] update -b'.

9)  "?IF", "?ELSE", "?ELSEIF" and "?END" are now case-insensitive so,
    for example, they can be entered as "?if", "?else", "elseif" AND
    "?end".

10) Optimization level 4 now locates short chains (3 rules or less)
    that have a single reference and replaces that single reference with
    the rules themselves.

    Optimization level 8 now eliminates duplicate rules in the raw
    table.

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

4.5.6.2

1)  The compiler now generates an error when a SOURCE interface is
    specified in a rule where the SOURCE zone is the firewall itself.

2)  Previously, entries in /etc/shorewall/notrack that specified a
    Vserver zone in the SOURCE column were omitted from the generated
    ruleset.

3)  The set of helpers available in the notrack file and in the HELPER
    column of the tcrules file was incorrect:

    - The Amanda helper requires a UDP port -- Shorewall was requiring
      TCP.

    - The H323 module supplies two helpers: 'RAW' and 'Q.931';
      Shorewall only accepted 'h323'.

    - The Netbios NS module supplies the 'netbios-ns' helper; Shorewall
      only accepted 'netbios_ns'.

4)  The conditional directive '?IF 0' generated an error from the
    compiler. It now causes following lines to be omitted.

4.5.6.1

1)  The 'systemctl' command in the Shorewall[6], Shorewall[6] Lite and
    Shorewall Init installers was incorrect with the result that the
    product was not started automatically on boot.

4.5.6

1)  This release includes the defect repairs from Shorewall 4.5.5.1 through
    4.5.5.4.

2)  Previously, the tcrules file was not processed when
    TC_ENABLED=No. That meant that to use features like TPROXY, it was
    necessary to set TC_ENABLED=Yes and create a dummy
    /etc/shorewall/tcstart file. Now, only MANGLE_ENABLED=Yes is
    required.

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

1)  Support for size tables has been added in complex TC. 

    The OPTIONS column of /etc/shorewall/tcdevices now allows a
    'linklayer' option whose value may be 'ethernet', 'atm' or 'adsl';
    the last two are synonyms.

    When 'linklayer' is specified, it may be followed by additional
    options:

	mtu=<mtu> - The device MTU; default 2048 (will be rounded up to a
		     power of two)

    	mpu=<mpubytes> - Minimum packet size used in
    		         calculations. Smaller packets will be rounded up
    		         to this size

    	tsize=<tablesize> - Size table entries; default is 512

    	overhead=<overheadbytes> - Number of overhead bytes per packet.

    See tc-stab (8) for details about these options.

2)  It is now possible to specify the LS (linksharing) rate for an HFSC
    class in /etc/shorewall/tcclasses. See shorewall-tcclasses (5) for
    details.

3)  It is now possible to specify that a leaf class will use the RED
    (Random Early Detection) queuing discipline rather than SFQ or
    pfifo. A new class OPTION is defined:

      red=(<red option>=<value>, ...)

      	When specified on a leaf class, causes the class to use the RED
      	(Random Early Detection) queuing discipline rather than
      	SFQ. See tc-red (8) for additional information.

    	Allowable <red option>s are:

    	min <min>
            Average queue size in bytes at which marking becomes a
            possibility.
    	max <max>
	    At this average queue size, the marking probability is
	    maximal. Must be at least twice <min> to prevent
            synchronous retransmits, higher for low <min>.
   	probability <probability>
            Maximum probability for marking, specified as a floating
            point number from 0.0 to 1.0. Suggested values are 0.01 or
            0.02 (1 or 2%, respectively).
        limit <limit>
            Hard limit on the real (not average) queue size in bytes.
	    Further packets are dropped. Should be set higher than
            <max>+<burst>. It is advised to set this a few times higher
            than <max>. Shorewall requires that <limit> be at least
            twice <min>.
        burst <burst>
            Used for determining how fast the average queue size is
            influenced by the real queue size. Larger values make the
            calculation more sluggish, allowing longer bursts of
            traffic before marking starts. Real life experiments
            support the following guide‐line:
            (<min>+<min>+<max>)/(3*<avpkt>).
        avpkt <avpkt>
            Optional. Specified in bytes. Used with burst to determine
            the time constant for average queue size calculations. 1000
            is a good value and is the Shorewall default.
        bandwidth <bandwidth>
            Optional. This rate is used for calculating the average
            queue size after some idle time. Should be set to the
            bandwidth of your interface. Does not mean that RED will
            shape for you!
        ecn
            RED can either 'mark' or 'drop'. Explicit Congestion
            Notification (ECN) allows RED to notify remote hosts that
            their rate exceeds the amount of bandwidth
            available. Non-ECN capable hosts can only be notified by
            dropping a packet. If this parameter is specified, packets
            which indicate that their hosts honor ECN will only be
            marked and not dropped, unless the queue size hits limit
            bytes. Needs a tc binary with RED support compiled
            in. Recommended.

4)  The handling of the USER/GROUP column of the rules file has been
    rewritten. As part of this rewrite:

    a)  The ability to specify a program name (e.g., +prog) has been
        eliminated. The kernel feature which that ability depended on
        was removed in kernel version 2.6.14.

    b)  It is now possible to specify UID and/or GID ranges of the form
    	'low-high' where 'low' and 'high' are integers and low <= high.

5)  It is now possible to use Perl-compatible expressions in ?IF
    directives. As before, variables must be environmental variables,
    options from shorewall.conf, shell variables set in the params file
    or capabilities. As previously, capabilities may be entered with
    leading '__' rather than '$'.

    Example:

	?IF $BLACKLIST_LOGLEVEL && ! __LOG_OPTIONS

6)  The ?ELSIF directive has been added allowing more convenient
    expression of complex include scenarios.

    Example (column headings abbreviated to fit release notes format):

       #NAME     NUM MARK    DUP  INTERFACE GWAY   OPTIONS
       ?IF $FALLBACK
       ComcastB  1   0x10000 -    COMB_IF   detect fallback
       ComcastC  2   0x20000 -    COMC_IF   detect fallback
       ?ELSIF $STATISTICAL
       ComcastB  1   0x10000 -    COMB_IF   detect load=0.66666667
       ComcastC  2   0x20000 -    COMC_IF   detect load=0.33333333
       ?ELSE
       ComcastB  1   0x10000 -    COMB_IF   detect balance=2
       ComcastC  2   0x20000 -    COMC_IF   detect loose,balance
       ?ENDIF

7)  And ORIGINAL DEST column has been added to the masq file, allowing
    SNAT rules to match only DNAT traffic to a particular original source
    address.

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

4.5.5.4

1)  In the generated script, the logic for handling wildcard interfaces
    with the 'wait=n' option was incorrect. For each matching interface,
    the script would check its readiness n times in rapid
    succession. The script now sleeps 1 second between checks.

4.5.5.3

1)  When logical interface names were used, an entry in tcrules that
    included a classid could result in the compiler failing with this
    Perl diagnostic:

      Can't use an undefined value as an ARRAY reference at
      /usr/share/shorewall/Shorewall/Tc.pm line nnn, <$currentfile>
      line 20.

4.5.5.2

1)  Previously, when ipp2p was used in the /etc/shorewall/tcpri file,
    the generated code for saving the packet mark was clearing the
    connection marks fields not having to do with traffic shaping. It
    now only alters the traffic-shaping part of the connection mark.

2)  Shorewall 4.4.11 allowed UID and GID ranges to be specified in the
    USER:GROUP column of the rules file. That undocumented capability
    has been restored for the benefit of Debian users upgrading from
    Squeeze to Wheezy.

3)  The special TPROXY mark value is now shown in the output of
    'shorewall show marks'.

4)  Assuming that A = 0 and B = 1, the following conditionals
    previously produced incorrect results:

      ?IF $A
      ?IF $B
      <text>
      ?ENDIF
      ?ENDIF

    The <text> was included when it should have been omitted.

4.5.5.1

1)  The change in Shorewall 4.5.4 that cleared the 'default' table if
    there were no 'fallback' providers broke multiple 'fallback'
    providers that didn't supply a weight. The symptoms were that there
    were host routes to the default gateways in the 'default' routing
    table but no default routes through those gateways.

    This has now been corrected and multiple 'fallback' routes are once
    again supported.

2)  When a logical device name was specified in the REDIRECTED
    INTERFACES column of /etc/shorewall/tcdevices, that name was used
    in the generated script rather than the device's physical
    name. Unless the two were the same, this caused start/restart
    failure. Shorewall now uses the physical name.

4.5.5

1)  This release includes all defect repair from Shorewall 4.5.4.1 and
    4.5.4.2.

2)  The Shorewall compiler sometimes must defer generating a rule until
    runtime. This is done by placing shell commands in its internal
    representation of a chain. These commands are then executed at run
    time to create the final rule.

    If all of the following were true, then an incorrect ruleset could
    be generated:

    a)  Optimization level 4 was set.
    b)  A chain (chain A) containing shell commands had three or fewer
        rules and commands.
    c)  The last rule in a second chain was a conditional jump to
        chain A.

    Under these conditions, the rules and commands in Chain A replaced
    the conditional jump and the conditional part was lost.

    Example (Lines are folded to fit the release note format):

	Chain A:

           if [ $SW_ETH0_ADDRESS != 0.0.0.0 ]; then
	      echo "-A net_dnat -d $SW_ETH0_ADDRESS\
                  -j DNAT --to-destination 1.2.3.4" >&3
          fi

       Chain B:

          ...
          -A dnat -i eth0 -j

       Result:

          if [ $SW_ETH0_ADDRESS != 0.0.0.0 ]; then
	      echo "-A dnat -d $SW_ETH0_ADDRESS\
                  -j DNAT --to-destination 1.2.3.4" >&3
          fi

       Notice that the '-i eth0' match has been lost.

3)  The Shorewall-core configure and configure.pl script were treating
    SYSCONFDIR as a synonym for CONFDIR making it impossible to set
    SYSCONFDIR.

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

1)   It is now possible to include additional information in netfilter
     messages when using plain log levels (debug, info, ...). This is
     done by following the level with a parenthesized comma-separated
     list of "log options".

     Valid log options are:

     ip_options

       Log messages will include the option settings from the IP
       header.

     macdecode

       Decode the MAC address and protocol.

     tcp_sequence

       Include TCP sequence numbers.

     tcp_options

       Include options from the TCP header.

     uid

       Include the UID of the sending program; only effective for
       packets originating on the firewall itself.

     Example: info(tcp_options,tcp_sequence)

2)   The Shorewall-init configuration file (/etc/default/shorewall-init
     or /etc/sysconfig/shorewall-init) now contains a LOGFILE setting.
     When specified, all messages generated by interface updown events
     are logged there. The sample configuration file and the logrotate
     file configure this log as /var/log/shorewall-ifupdown.log.

3)   Previously, the 'ignore' interface option could only be specified
     by itself and could not be specified unless the ZONE column was
     empty (i.e, contained '-'). Now, it is allowed to specify
     'ignore=1' without these restrictions.

     With 'ignore=1', the generated script will still ignore
     Shorewall-init 'up' and 'down' events but the interface will still
     be subject to hairpin filtering unless it has the 'routefilter' or
     'routeback' option.

4)   Imbedded shell and Perl directives may now be optionally preceded
     by a question mark ('?').

     Example:

         ?BEGIN PERL
	 use strict;
         ...
	 ?END PERL

5)  To aid package maintainers for distributions that don't include the
    Digest::SHA Perl module, the Shorewall install.sh script looks for
    the DIGEST environmental variable and if the setting is not 'SHA',
    then the Shorewall::Chains module is modified to use $DIGEST as the
    module name.

    To specify SHA1

    	   DIGEST=SHA1 ./install.sh

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

4.5.4.2

A large number of defects in Shorewall-init have been corrected:

    a) The installer now enables startup at boot on Debian.

    b) When more than one product was listed in the PRODUCTS setting in
       /etc/default/shorewall-init (/etc/sysconfig/shorewall-init),
       only the first product was acted upon.

    b) Interface up/down handling was always using 'restart'; if an
       interface is disabled, 'restart' doesn't bring it up. Interface
       up/down handling now uses the 'enable' and 'disable' commands
       when an optional provider interface goes up or down.

2)   The order in which the compiler processes line-continuation (line
     ending in '\') and conditional-inclusion directives (?IF, ?ELSE,
     and ?ENDIF) has been reversed.

     Previously, the compiler built a concatenated line, then checked
     to see if the line began with ?IF, ?ELSE or ?ENDIF. Now, the
     compiler checks for ?IF, ?ELSE or ?ENDIF first and prevents those
     lines from becoming part of the concatenation.

     Example:

	Previously, given these lines and assuming that $FOO was
	non-empty and non-zero:

	    ACCEPT:\
	    ?IF $FOO
	    bar
	    ?ELSE
	    baz
	    ?END

        then the lines would become

	    ACCEPT:\?IF $FOO
	    bar
	    ?ELSE
	    baz
	    ?END

        Now, they will be become simply

	    ACCEPT:bar

3)  Two issues with the shorecap programs have been corrected:

    a) The Shorewall6-lite version failed to run with the message:

          /usr/share/shorewall6-lite/lib.cli: No such file or directory

    b) The Shorewall-lite version would not run if SHAREDIR was set to
       a value other than /usr/share in shorewallrc.

4)  If an iprange appeared in the SOURCE column of /etc/shorewall/masq,
    then compilation would fail on RHEL5-based systems with the error:

      Address Ranges require the Multiple Match capability in
         your kernel and iptables

5)  The Shorewall 4.5.2.3 fix for the Shorewall-core installer's
    handling of --host=linux was not brought forward into 4.5.3. It has
    been included again in this version.

6)  Single-line embedded PERL and SHELL commands have been
    re-enabled.

7)  If an iprange appeared in the SOURCE column of /etc/shorewall/masq,
    then compilation would fail on RHEL5-based systems with the error:

      Address Ranges require the Multiple Match capability in
         your kernel and iptables

4.5.4.1

1)  Beginning with Shorewall 4.4.22, the 'pptpserver' tunnel type has
    been configured as a PPTP client running on the firewall rather
    than as a server on the firewall. It is now correctly configured as
    a server.

2)  The shorewall-accounting (5) and shorewall6-accounting (5)
    documentation for the IPSEC column is incorrect. Rather than
    'accountin' and 'accountout', the chain names should be
    'accipsecin' and 'accipsecout'.

3)  IPSEC accounting did not work if the accounting file was sectioned.
  
    Beginning with this release, the IPSEC column can be specified in
    any section. As always, the IPSEC column contains a comma-separated
    list of items. In the FORWARD chain, the first (or only) item in
    the list must be either 'in' or 'out' to indicate whether the rule
    matches incoming packets that have been decrypted ('in') or
    outgoing packets that will be encrypted ('out'). There are no
    restrictions with respect to which chain IPSEC rules can appear in
    a sectioned file.

4.5.4

1)  This release includes all defect repairs from Shorewall 4.5.3.1.

2)  When EXPORTMODULES=No in shorewall.conf, the following errors were
    issued:

    /usr/share/shorewall/modules: line 19: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 23: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 27: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 31: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 35: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 39: ?INCLUDE: command not found

    These messages have been eliminated.

3)  If the configuration settings in the PACKET MARK LAYOUT section of
    shorewall.conf (shorewall6.conf) had empty settings, the 'update'
    command would previously set them to their default settings. It now
    leaves them empty.

4)  Previously, Shorewall used 'unreachable' routes to null-route the
    RFC1918 subnets. This approach has two drawbacks:

    - It can cause problems for IPSEC in that it can cause packets to
      be rejected rather than encrypted and forwarded.

    - It can return 'host unreachable' ICMPs to other systems that
      attempt to route RFC1918 addresses through the firewall.

    To eliminate these problems, Shorewall now uses 'blackhole' routes.
    Such routes don't interfere with IPSEC and silently drop packets
    rather than return an ICMP.

5)  The 'default' routing table is now cleared if there are no
    'fallback' providers.

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

1)  The TPROXY tcrules action introduced in Shorewall 4.4.7 was
    incomplete and required additional rules to be added in the 'start'
    or 'started' extension scripts.

    In this release, the TPROXY implementation has been changed and an
    additional DIVERT action has been created. Because the new TPROXY
    has a different set of parameters than the prior one, the tcrules
    file now supports two formats: 

    FORMAT 1 - (default, deprecated )

        The TPROXY action allows three arguments, the first of which
        ('mark') is required.

    FORMAT 2

    	The TPROXY action has two optional arguments; these are the
    	second and third arguments to the format-1 TPROXY:

	    port -- the port on which the proxy is listening. While
	    	    this argument is optional, it will normally be
	    	    supplied.

 	    ip address -- The address on which the proxy is listening. 

    The file format is specified by a line like this:

    	FORMAT {1|2}

    The Sample configurations have been updated to use FORMAT 2.

    The format-2 tcrules file also supports the DIVERT action. The
    DIVERT action directs matching packets to the local system if there
    is a transparent socket in the local system that matches the
    destination of the packet. DIVERT is used to redirect response
    packets from remote web servers back to the proxy process
    running on the firewall rather than being routed directly back to
    the client.

    Finally, the providers file supports a new 'tproxy' option. When
    'tproxy' is specified:

    - It must be the only OPTION given
    - The MARK, DUPLICATE and GATEWAY columns must be empty.
    - The loopback device (lo) should be specified as the INTERFACE.

    The 'tproxy' option causes a reserved mark value to be associated
    with the provider and for its associated routing rule to have
    priority 1.

    Here is the TPROXY configuration at shorewall.net:

    interfaces:

      FORMAT 2
      #ZONE	INTERFACE	OPTIONS
      net	eth0		...
      net	eth1		...
      loc	eth2		...
      -		lo		ignore

    tcrules:

      FORMAT 2
      #ACTION			SOURCE	DEST	PROTO	DEST	SOURCE
      #							PORT(S) PORT(S)
      DIVERT			eth1	-	tcp	-	80
      DIVERT			eth0	-	tcp	-	80
      TPROXY(3129,172.20.1.254)	eth2	-	tcp	80

    providers:
    
      #NAME  NUMBER MARK DUPLICATE INTERFACE GATEWAY	OPTIONS
      ...
      Squid  3	    -	 -	    lo	     -		tproxy

    /etc/squid3/squid.conf:

        ...
	http_port 172.20.1.254:3129 tproxy
        ...

2)  With some misgivings, this release adds support for the geoip match
    feature available in xtables-addons. Geoip allows matching of the
    source or destination IP address by ISO 3661 country codes. The
    Shorewall support requires xtables-addons 1.33 or later.

    The support is implemented in the form of extended syntax in the
    SOURCE and DEST columns of the rules file.

    To specify a single country code, add a caret prefix ('^').
    
    Example: ^A1

    To specify multiple country codes, enter them as a
    comma-separated list enclosed in square brackets ('[...]') with a
    caret prefix ('^').

    Example: ^[A1,A2]

    A listing of two-character country codes is available at
    http://www.shorewall.net/ISO-3661.html.

    Example rule - Drop email from Anonymous Proxies and Satellite
    	    	   Providers:

    #ACTION   	   SOURCE	 	DEST	PROTO	DEST
    #		   					PORT(S)
    DROP:info	   net:^[A1,A2]		dmz	tcp	25

    The compiler determines the set of valid country codes by examining
    the geoip database which is normally installed in
    /usr/share/xt_geoip/. There are two sub-directories at that
    location:

        BE - The big-endian database.
	LE - The little-endian database.

    To accomodate both big-endian and little-endian machines and
    to allow the database to be installed elsewhere, a GEOIPDIR option
    has been added in shorewall.conf and shorewall6.conf. The default
    setting is "/usr/share/xt_geoip/LE" since Shorewall is normally
    installed on little-endian machines.

3)  OPTIMIZE level 4 now performs an additional optimization. If the
    last rule in a chain is an unqualified jump to a simple target,
    then all immediately preceding rules with the same simple target
    are omitted. 

    For example, consider this chain:

    	-A fw-net -p udp --dport 67:68 -j ACCEPT
	-A fw-net -p udp --sport 1194 -j ACCEPT
	-A fw-net -p 41 -j ACCEPT
	-A fw-net -j ACCEPT

    Since all of the rules are jumps to the simple target ACCEPT, this
    chain is totally optimized away and jumps to 'fw-net' are replaced
    with jumps to ACCEPT.

    As part of this enhancement, when both OPTIMIZE level 1 and level 4
    are selected, the level 1 optimization step is skipped because it
    is now a limited subset of level 4.

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

4.5.3.1

1)  Previously, nested conditionals did not work correctly in all
    cases. In particular:

        ?IF $FALSE
            ?IF $FALSE
               foo
               bar
            ?ENDIF
            baz
            bop
        ?ENDIF

    In this case, the lines 'baz' and 'bop' were incorrectly included
    when they should have beeen omitted.

2)  The 'balance' routing table is now cleared if there are no
    'balance' providers.

3)  Previously, the compiler generated an invalid 'ip add route'
    command if an IPv6 provider had '-' in the GATEWAY column.

4)  As noted in the Migration Considerations below, the generated
    firewall script maintains the interface .status files used by LSM
    and SWPING. Up to now, however, the 'disable' command did not
    update the .status file. That has been corrected. As part of the
    change, the 'isusable' script is no longer consulted by the
    'enable' command.

5)  The configure and configure.pl scripts have not been outputting the
    setting of SPARSE, with the result that /etc/shorewall and
    /etc/shorewall6 are fully-populated on Debian systems. This has
    been corrected.

    For Debian users that want to remove the extra files from
    /etc/shorewall (/etc/shorewall6), the following script will
    do the job (replace 'shorewall' by 'shorewall6' to clean
    /etc/shorewall6):

       #!/bin/sh

       cd /etc/shorewall

       for f in *; do
           [ -f /usr/share/shorewall/configfiles/$f ] && \
           diff -q $f /usr/share/shorewall/configfiles/$f > /dev/null \
           && rm $f;
      done

    Once you have done that, edit ~/.shorewallrc and add

         SPARSE=Yes

    to the settings in that file.

4.5.3

1)  This version includes all defect repairs from Shorewall 4.5.2.1 -
    4.5.2.4.

2)  The LOCKFILE setting in shorewall.conf and shorewall6.conf had
    inadvertently become undocumented. It is now documented again.

3)  In an initial installation of Shorewall, Shorewall6, Shorewall Lite
    or Shorewall6 Lite was done under Shorewall 4.5.2, then the
    firewall would not start up at boot even though the installer
    indicated that it would. That defect has been corrected.

4)  Previously, when per-IP rate limiting was invoked, the compiler
    would use the deprecated '--ratelimit' option, even if the
    preferred '--ratelimit-upto' option was available. Now, the
    compiler uses the preferred option if it is supported by the
    installed version of iptables.

5)  Prior to this release, using a manual chain in the ACTION column of
    a macro body generated an error:

    ERROR: Invalid Action (mychain) in macro, macro.FOO (line ...)

    This now works correctly and generates a jump to the specified
    manual chain.

6)  If SHAREDIR was other than /usr/share and $CONFDIR/shorewall/init
    did not exist, then an error message similar to this is emited:

      Processing /usr/local/share/shorewall/init ...
      Usage: /etc/init.d/shorewall
                 {start|stop|refresh|restart|force-reload|status}

7)  Prevously, a line with the single word COMMENT in the tunnels file
    would generate the following error: 

        ERROR: Zone must be specified

    Now, such a line correctly resets the current rule comment.

8)  In Shorewall 4.5.2, the MARK column in the tcrules file was renamed
    to ACTION but only 'mark' was accepted in the alternate
    specification format. Now both 'mark' and 'action' are accepted.

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

1)  The '-T' option is now supported in the Shorewall and Shorewall6
    'load', 'reload', 'restart' and 'start' commands. As with the
    'check' command, it causes a Perl stack trace to be printed along
    with compiler WARNING and ERROR messages.

2)  The debuggability of assertion failures has been improved.

    - A Perl stack trace is now generated unconditionally on an
      assertion failure.

    - Relevant data is passed as additional arguments to assertion
      checks so that setting a breakpoint in
      Shorewall::Config::assert() can now allows examination of the
      data structures surrounding the failure.

3)  The GATEWAY column of the tunnels file has been renamed 'GATEWAYS'
    and now accepts a list of host and network addresses as well as IP
    ranges.

    Exclusion is not permitted.

    In the alternate specification format, both 'gateway' and
    'gateways' are accepted as the column name.

4)  The 'refresh' command now allows additional options:

    -d - Run the rules compiler under the Perl debugger.

    -n - Don't modify routing.

    -T - Produce a Perl Stack trace on errors and warnings.

    -D <directory> - Look in <directory> first for configuration files.

5)  The interfaces file now supports two formats:

    FORMAT 1 - (default, deprecated)

        Includes the BROADCAST column (UNICAST in Shorewall6).

    FORMAT 2

        Does not include the BROADCAST (UNICAST) column.

    The format is specified by a line line this:

    	FORMAT {1|2}

    The Sample configurations have been updated to use FORMAT 2.

6)  A change has been made in the packaging for Slackware. On
    Slackware, there is an /etc/rc.d/firewall.rc script that looks for
    /etc/rc.d/shorewall.rc and /etc/rc.d/shorewall6.rc and runs them,
    passing it's own arguments.

    The file installed as firewall.rc is named
    init.slackware.firewall.sh and has traditionally been included in
    the Shorewall package. Beginning with this release, it is moved to
    the Shorewall-core package. This opens the door for releasing
    Slackware versions of the -lite products in the future.

    The init scripts for Slackware are now described in slackware.rc
    as:

	AUXINITSOURCE=init.slackware.firewall.sh
    	AUXINITFILE=rc.firewall
    	INITSOURCE=init.slackware.$PRODUCT.sh
    	INITFILE=rc.$PRODUCT

7)  Previously, errors reported in macros were hard to analyze.

    Example: 

       ERROR: Unknown destination zone (bar)
       	      /usr/share/shorewall/macro.SSH (line 11),

    In this case, we don't know where the SSH macro was invoked
    incorrectly. Beginning with this release, the stack of
    includes/opens will be included in ERROR and WARNING messages. 

    Example:

       ERROR: Unknown destination zone (bar) 
          /usr/share/shorewall/macro.SSH (line 11)
	  from /etc/shorewall/rules (line 42)

    This shows that the SSH macro was invoked on line 42 of the rules
    file.

8)  There is now a BLACKLIST macro that works as follows:

    - If BLACKLIST_LOGLEVEL is set, then the macro invokes the
      'blacklog' action.
    - Otherwise, the macro invokes the BLACKLIST_DISPOSITION action.

9)  An RST action has been added which matches tcp packets with the RST
    flag set. The action accepts two optional parameters:

    - Action (ACCEPT or DROP). Default is DROP.
    - Audit  ('audit' or omitted). Default is omitted.

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

4.5.2.4

1)  Installation on Slackware has been corrected.

2)  The 'shorewall reset' command now correctly resets the IPv4 packet
    and byte counters; previously, it was resetting the IPv6 counters.

3)  The Shorewall installer now modifies the Chains.pm file for
    Digest::SHA depencency when $DESTDIR is set, provided that $BUILD =
    $HOST. This allows rpm to automatically generate the correct module
    dependency.

4)  With fresh installs on Debian and derivatives, the firewall did
    not start at boot, even though the installer indicated that it
    would. This defect, introduced in Shorewall 4.5.2, has been
    corrected.

4.5.2.3

1)  The 'show routing' command was broken with dash 0.5.7-2ubuntu2
    installed. It now works correctly.

2)  Recent distributions have dropped Digest::SHA1 in favor of
    Digest::SHA. The Shorewall installer now replaces the former
    with the latter when appropriate.

3)  A couple of issues with Debian release compliance have been
    corrected.

4)  The 'configure' script failed to handle --host=linux correctly; the
    result was that it tried to open .default rather than
    shorewallrc.default.

5)  Previously, setting TC_EXPERT=Yes did not allow SAVE/RESTORE of all
    parts of the packet/connection mark. That has been corrected.

4.5.2.2

1)  If a shorewallrc file is passed to the Shorewall-core 4.5.2.1
    installer, subsequent compilations will fail. The error message
    indicates that the compiler is looking for the lib.core file
    but the pathname has embedded whitespace.

    This has been corrected.

2)  The Shorewall 4.5.2.1 installer was installing the wrong Makefile
    for Shorewall and Shorewall6.

4.5.2.1

1)  The 4.5.2 configure script does not work on RHEL5 systems and
    derivatives. To allow RPMs to be built on those systems, a
    Perl-based script (configure.pl) has been added. The sample .spec
    files included in the various packages have been changed to use the
    new script.

2)  In release 4.5.2, if an INCLUDE directive appeared inside a ?IF
    ... ?ENDIF sequence, then the following error would be generated
    after the included file had been read:

    	  ERROR: Missing ?ENDIF to match the ?IF at line ...

3)  An error in the shorewallrc.file has been corrected.

4)  The shorewallrc.redhat file has been change to conform to Fedora
    packaging guidelines.

5)  The installers now modify the Makefile if non-standard settings are
    used for SBINDIR or SHAREDIR.

6)  The configure script now detects that it is running on a version
    of Bash that won't support the features used in the script.

7)  Both configure and configure.pl now detect the distribution if
    'host' or 'vendor' (--host or --vendor) are not specified on the
    command line.

4.5.2

1)  This release includes the defect repairs from Shorewall 4.5.1.1 and
    4.5.1.2 (see below).

2)  The generated firewall script includes code to automatically create
    ipsets that are referenced but that don't exist. That code was
    broken in releases 4.4.22 and later. This defect has been
    corrected. As part of the fix, the generated script will now
    issue a warning message when it creates an ipset.

4.5.1.2

1)  The Shorewall Lite and Shorewall6 Lite installers have been 
    installing the wrong SysV init script on Debian and derivatives.
    The correct script is now installed.

2)  Nested TC classes could result in Perl diagnostics like this one:

    Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in
    numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042,
    <$currentfile> line 13.

    These harmless messages have been eliminated.

3)  It is once again possible to omit the minimum length in the LENGTH
    column of the tcrules file.

4)  Under the following conditions, a compiler internal error was
    raised:

    - Extended conntrack match support is available.
    - Repeat Match is not available.
    - A DNAT rule specifies a destination port, a server port and
      an original destination.

5)  Beginning with release 4.4.26, setting both 'nets=' and 'dhcp' on
    an interface does not work correctly. That issue has been resolved
    in this release.

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

1)  The 'mss' option is now supported in the /etc/shorewall[6]/hosts
    files. See the manpages for details.

2)  It is now possible to conditionally include or omit configuration
    entries based on the settings of shell variables. See
    http://www.shorewall.net/configuration_file_basics.htm#Conditional
    for details.

3)  The MARK/CLASSIFY column in /etc/shorewall[6]/tcrules has been
    renamed ACTION to reflect the expanded set of actions that can be
    specified in the column.

4)  Some users are finding these ipset warnings objectionable:

    - Warning when a referenced ipset does not exist.
    - Warning when using [src] in a destination column or [dst] in a
      source column.

    These warnings may now be suppressed by setting IPSET_WARNINGS=No
    in shorewall.conf and/or shorewall6.conf.

5)  The evolution of the Shorewall installation process
    continues. Testers are invited to provide comments and suggestions
    about the following.

    Beginning with this release, the installers accept a configuration
    file as a parameter. Options set in the configuration file are as
    follows:

    BUILD (optional)   -- Platform on which the installation is being
    	  	     	  performed. Possible values are:

			  apple - OS X
			  archlinux - ArchLinux
			  cygwin - Cygwin running under Windows
			  debian - Debian and derivatives
			  linux - Generic Linux system
			  redhat - Fedora, RHEL and derivatives
			  suse - SLES and OpenSuSE
			
			  If no value is assigned, then the installer
			  will detect the platform.

    HOST (Optional)    -- Allowed values are same as for BUILD. If not
    	 	          specified, the BUILD setting is used.

    CONFDIR (Req'd)    -- Directory where product configuration
    	    	       	  directory is installed. Normally /etc.

    SHAREDIR (Req'd)   -- Directory where architecture-independent
    	     	     	  product files are installed. Normally
    	     	     	  /usr/share.

    LIBEXECDIR (Req'd) -- Directory where product executables are
    	       	          installed. Normally /usr/share or
    	       	          /usr/libexec.

    PERLLIBDIR (Req'd) -- Directory where Shorewall Perl modules are
    	       	       	  to be installed. Traditionally
    	       	       	  /usr/share/shorewall.
 
    SBINDIR (Req'd)    -- Directory where product CLI programs are
    	    	          installed. Normally /sbin

    MANDIR (Req.d)     -- Directory where manpages are
    	   	          installed. Mornally /usr/share/man.

    INITFILE (Optional)
                       -- Optional. If given, specifies the installed
		       	  filename of the initscript. Normally 
			  set to $PRODUCT which the installers expand
			  to the name of the product being installed.
			  If not specified, no init script will be
			  installed.

    INITSOURCE (Optional)
                       -- Must be specified if INITFILE is specified. 
		          Gives the name of the file to be installed
			  as the INITFILE. 

    INITDIR (Optional) -- Directory where SysV init scripts are
    	    	          installed. Must be specified if INITFILE is
    	    	          specified.

    ANNOTATED (Optional) 
                       -- If non-empty, indicates that the
    		       	  configuration files are to be annotated with
			  manpage information. Normally empty.

    SYSTEMD (Optional) -- Name of the directory where .service files
    	    	       	  are to be installed. Should only be specified
    	    	       	  on systems running systemd.

    SYSCONFDIR (Optional)
                       -- Name of the directory where subsystem
    		          init configuration information is stored. 
			  On Debian and derivates, this is
    			  /etc/default.  On other systems, it is
			  /etc/sysconfig.

    SYSCONFFILE (Optional) 
                       -- Name of the file to be installed in the
		          SYSCONFIGDIR. The installed name of the file
			  will always be the product name (shorewall,
    			  shorewall-lite, etc.)

    SPARSE (Optional)  -- If non-empty, causes only the .conf file to
    	   	          be installed in
    	   	          ${CONFDIR}/${PRODUCT}/. Otherwise, all of 
			  the product's skeleton configuration files
			  will be installed.

    TEMPDIR (Optional) -- If non-empty, the generated firewall script
    	    	       	  will export the variable TMPDIR with 
			  value $TEMPDIR.

    VARDIR (Required)  -- Directory where product state information
    	   	          is stored. Normally /var/lib.

			  This setting was previously stored in the
			  optional vardir file in the product's 
			  configuration directory.

    Each of the product tarballs contains a set of configuration files
    for the various HOSTS: 

    	shorewallrc.apple
    	shorewallrc.archlinux
	shorewallrc.cygwin
    	shorewallrc.debian
    	shorewallrc.default (for HOST 'linux')
	shorewallrc.redhat
	shorewallrc.suse

    To aid distribution packagers, a configure script has been added.
    The arguments to the script are the usual list of <option>=<value>
    assignments. The supported options are the same as those above,
    although they may be in lower case and may be optionally preceded
    by '--'.

    The configure script uses the setting of --host to select the
    appropriate rc file. It reads that file to establish default
    settings and then applies the values specified in the argument
    list. To allow use with the %configure RPM macro, only the last
    occurrence of a particular option setting is applied. The resulting
    settings are written to a file named 'shorewallrc' in the current
    working directory and are also written to standard out.

    When Shorewall-core is installed on a system (with no DESTDIR), it
    copies the specified configuration file into root's
    ~/.shorewallrc. The ~/.shorewallrc file is then used, by default,
    when installing the other packages.

    To further aid use with %configure, several aliases are supported:

       alias   	       option
       -----           ------
       sharedstatedir  vardir
       datadir	       sharedir
       sysconfdir      confdir

    The configuration file is also copied to
    ${SHAREDIR}/shorewall/shorewallrc where the CLI programs and init
    scripts can find it. Those programs are modified by the installer
    when ${SHAREDIR} is not /usr/share.

    When using Shorewall-lite or Shorewall6-lite, if the remote
    firewall's shorewallrc file differs from that on the firewall, then
    a copy of the remote file should be placed in the firewall's
    configuration directory on the administrative system.

    Beginning with this release, using /etc/shorewall-lite/vardir
    and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in
    favor of the VARDIR setting in shorewallrc.

        NOTE: While the name of the variable remains VARDIR, the
              meaning is slightly different. When set in shorewallrc,
              each product (shorewall-lite, and shorewall6-lite) will
              create a directory under the specified path name to
	      hold state information.

	      Example:

		  VARDIR=/opt/var/lib/

		  The state directory for shorewall-lite will be
		  /opt/var/lib/shorewall-lite/ and the directory for
		  shorewall6-lite will be /opt/var/lib/shorewall6-lite.

	      When VARDIR is set in /etc/shorewall[6]-lite/vardir, the
	      product will save its state in the specified directory.

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

4.5.1.1

1)  When checking or compiling for export (-e option), /sbin/shorewall
    would previously issue a warning message if the SHOREWALL_SHELL
    specified in the remote firewall's shorewall.conf did not exist.

2)  The changes to TOS handling in 4.5.1 are incompatible with older
    releases such as RHEL5 and derivatives. That has been corrected.

3)  The rules compiler now verifies that the protocol is TCP, UDP, SCTP
    or DCCP when checking a port range (low:high or low-high).

4)  Previously, start or restart using the init script would fail with
    an error message referencing 'SHOREWALL_INIT_SCRIPT'. This defect
    was not visible to users that set AUTOMAKE=Yes or that run
    Shorewall-init.

4.5.1

1)  This release includes all defect repair from versions
    4.5.0.1-4.5.0.3.

2)  The Shorewall-init installer now installs the proper init script on
    Redhat and Fedora.

3)  A typo has been corrected in the blrules man pages.

4)  Previously, if the interface appearing in the HOSTS column of
    /etc/shorewall6/hosts was not defined in
    /etc/shorewall6/interfaces, then the compiler would terminate with
    a Perl diagnostic:

      	   Can't use an undefined value as a HASH reference at
      	   /usr/share/shorewall/Shorewall/Zones.pm line 1817,
      	   <$currentfile> line ...

5)  The handling of the LIBEXEC and PERLLIB variables was broken in the
    base 4.5.0 release. Simon Mater has supplied a fix which is
    included in this release.

6)  On systems running systemd, init scripts are no longer installed in
    /etc/rc.d/init.d.

7)  The Shorewall Init installer now correctly detects the use of
    systemd.

8)  On systems running systemd, the installer now installs
    /sbin/shorewall-init. That file has not existed previously, even
    though shorewall-init.service is trying to use it.

9)  The compiler was previously failing to validate the contents of the
    LENGTH and TOS columns in /etc/shorewall/tcrules. The contents of
    those columns are now validated by the compiler and an appropriate
    error message is issued if validation fails.

10) The column headings in the tos files are now in the proper
    order. Previously, the SOURCE PORT and DEST PORT columns were
    reversed.

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

1)  Support is now included for IMQ. This takes the form of of
    IMQ(<number>) in the MARK/CLASSIFY column of
    /etc/shorewall/tcrules.

2)  It is no longer necessary to specify a MARK value for the default
    class under a device that does not specify the 'classify'
    option. Simple set the MARK column to '-' in the default class.

3)  Previously, the install scripts included in the Shorewall packages
    were very restrictive. They could either be run to install directly
    onto the system in a distribution-dependent way, or they could
    install into a directory in a distribution-independent way. This
    limited their usefullness to packagers.

    Beginning with this release, the install scripts handle the install
    system and the target system independently. When running an
    installer, the following environmental variables can be set:

    a)  BUILD - Describes the system where the installer is
        running. Accepted values are:

	    cygwin    - Cygwin running under a Microsoft OS
	    apple     - OS X
	    debian    - Debian,Ubuntu,etc.
	    redhat    - Fedora,RHEL,Centos,Foobar,etc.
	    slackware - Slackware
	    archlinux - Arch Linux
	    linux     - Generic Linux
	    
        If BUILD is not set, then the installer uses its existing
        algorithm for detecting the current OS and distribution.

    b)  HOST - Describes the system where the installed package
        will run.

	- For Shorewall and Shorewall6, the possible values are
          the same as for BUILD.

        - If HOST is not set, the value of BUILD (through setting or
          detection) is used.
    
        - For Shorewall-lite and Shorewall6-lite, the possible choices
          are debian,  redhat, suse, slackware, archlinux and
          linux.

    	- For Shorewall-init, the possible choices are debian,
          redhat, and suse.

    c)  INITDIR - Gives the absolute path name of the directory
    	containing the init scripts.

    The choice of HOST and TARGET follow the naming of similar macros
    in rpm and autoconf.

    As part of these changes, LIBEXEC and PERLLIB must now hold an
    absolute pathname. So, for example, if you have been using

    	LIBEXEC=libexec

    you will need to change to

        LIBEXEC=/usr/libexec

    Additionally, support has been added for sourcing a file containing
    option settings. The file name is 'shorewall-pkg.config' in the
    parent directory of the untar'ed package file.

5)  The .spec files included with each package have undergone
    considerable revision.

    When running the package ./install.sh script:

    a) The setting for LIBEXEC is taken from the standard '_libexecdir'
       rpm macro.

    b) The setting for PERLLIB is taken from the standard
       'perl_privlib' rpm macro.

    c) The setting for INITDIR is taken from the standard
       '_initddir' rpm macro.

    d) The setting of BUILD is detected by the install script.

    e) The setting for TARGET is taken from the standard '_vendor' rpm
       macro.

    The rpms included with Shorewall are built with these settings of
    the standard rpm-supplied macros:

    	%_libexecdir  	   	/usr/libexec
        %perl_privlib		/usr/share/shorewall
	%_initddir		/etc/init.d
	%_vendor		suse
 
    The setting of %perl_sitelib is chosen for portability, since there
    seems to be no common location for site-specific Perl modules among
    the rpm-based distributions.

6)  A SWITCH column has been added to /etc/shorewall/masq. This column
    allows for enabling and disabling a rule based on a setting in
    /proc/net/nf_condition. See shorewall-masq(5) for details.

7)  The rules compiler now issues a warning when the 'src' ipset flag
    is used in a destination column or the 'dst' ipset flag is used in
    a source column.

8)  Support has been added for matching and setting the "Differentiated
    Services Code Point" (DSCP) field in the IP header. See
    shorewall-tcrules(5) and shorewall6-tcrules(5) for details.

9)  "Run-time gateway variables" are now supported. These variables
    have names that are composed of a percent sign ('%') followed by
    the logical name of an interface defined in
    /etc/shorewall/interfaces. They are expanded to the IP address of
    the default gateway out of the corresponding interface.

    Example: 

    %eth0 expands to the IP address of the default gateway out of eth0.

    See
    http://www.shorewall.net/configuration_file_basics.htm#Variables
    for details.

10) The 'update' command now omits non-default settings of
    WIDE_TC_MARKS and HIGH_ROUTE_MARKS from the updated .conf file.

11) The 'isusable' extension script is no longer installed by
    default. Users wishing to install it may simply copy it from
    /usr/share/shorewall[6]/configfiles. 

12) Support has been added for seting the "Type of Service" (TOS)
    header field in shorewall-tcrules(5) and shorewall6-tcrules(5). See
    the manpages for details. As part of this change, use of the
    shorewall-tos(5) and shorewall6-tos(5) files is deprecated and a
    warning is issued on the first rule in each file.

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

4.5.0.3

1)  The .service file with Shorewall Init specified that
    /sbin/shorewall-init should be run for start and stop, but there
    was no such file.

    Now, the installer will install /sbin/shorewall-init and will omit
    installing /etc/rc.d/init.d/shorewall-init when systemd is being
    used.

2)  If the variable DEBUG was set to a non-empty value in the environment
    or in /etc/shorewall/params, then 'shorewall stop' and 'shorewall
    clear' would not totally remove the old ruleset and a subsequent
    'shorewall start' would fail.

3)  'shorewall trace stop' or 'shorewall trace clear' would previously
    fail to remove the entire ruleset.

4.5.0.2

1)  The init scripts from shorewall.net that were installed on systems
    other than Redhat-based and Debian-based systems were broken.
    
    '/etc/init.d/shorewall start' and /etc/init.d/shorewall restart'
    failed with:

    	 "ERROR: No directory 'start'"

    or

	"ERROR: No directory 'restart'"

2)  The Shorewall-init installer now works correctly when installing
    the product on a Redhat-based distribution.

4.5.0.1

1)  The handling of the LIBEXEC and PERLLIB variables was broken in the
    base 4.5.0 release. Simon Mater has supplied a fix which is
    included in this release.
    
2)  A typo has been corrected in the blrules man pages.

3)  Previously, if the interface appearing in the HOSTS column of
    /etc/shorewall6/hosts was not defined in
    /etc/shorewall6/interfaces, then the compiler would terminate with
    a Perl diagnostic:

      	   Can't use an undefined value as a HASH reference at
      	   /usr/share/shorewall/Shorewall/Zones.pm line 1817,
      	   <$currentfile> line ...

4)  The Shorewall-init installer now installs the correct init script
    on Fedora and Redhat systems.

4.5.0

1)  This release includes all defect repair included in
    4.4.27.1-4.4.27.3.

2)  The start and restart commands in Shorewall Lite and Shorewall6
    Lite now correctly handle the 'trace' and 'debug'
    keywords. Previously, those keywords were ignored.

3)  The 'ip route list' command on recent Linux systems (Ubuntu 11.10,
    for example) displays the IPv4 routing table in a seemingly random
    order. In the 'show routing' and 'dump' commands, Shorewall and
    Shorewall-lite now sort the output into the traditional
    'Most-specific to most-general' order.

4) Previously, specifying 'No' in the HAVEROUTE column of
    /etc/shorewall6/proxyndp resulted in a run-time error. The code has
    been corrected so that no error occurs.

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

1)  The rules generated by the following interface options are now
    traversed after those generated by the blrules file.

	dhcp
	maclist
    	nosmurfs
	sfilter
        tcpflags

    As part of this change, the BLACKLIST section in the rules file has
    been eliminated. If you have rules in that section, you must move
    them to the blrules file prior to installing this Shorewall
    version.

2)  The timeout interval after which the previous state is restored 
    may now be specified in the safe-start and safe-restart commands.

3)  The packing of the Shorewall products has been changed. Beginning
    with this release, the packages are:

    - Shorewall Core  -- Core libraries installed in
      		         /usr/share/shorewall/

    - Shorewall       -- Requires Shorewall Core. Together with
                         Shorewall Core, provides IPv4 firewalling.

    - Shorewall6      -- Requires Shorewall. Provides IPv6 firewalling.

    - Shorewall Lite  -- Requires Shorewall Core. As before.

    - Shorewall6 Lite -- Requires Shorewall Core. As before.

    - Shorewall Init  -- As before.

4)  Shorewall and Shorewall6 now share a single install.sh file as do
    Shorewall Lite and Shorewall6 Lite.

5)  Functions common to both /usr/share/shorewall/prog.header and
    /usr/share/shorewall/prog.header6 are now in a new library -
    lib.core. The files /usr/share/shorewall/prog.footer is now used
    for both IPv4 and IPv6.

6)  Run-time address variables (e.g., &eth0) may now be used in the
    SOURCE column of the rtrules files.

7)  The route_rules file has been renamed to 'rtrules'. The Shorewall
    and Shorewall6 installers will perform the rename on an existing
    file.

    If both files exist, route_rules will be processed and rtrules 
    will be ignored with a warning.

8)  A 'PROBABILITY' column has been added to the tcrules files. It
    causes the rule to match randomly with the probability specified in
    the column. See shorewall-tcrules(5) and shorewall6-tcrules(5) for
    details.

9)  An alternative to the balance=<weight> option in the providers file
    is now available. This alternative works when there are multiple
    links to the same ISP where both links use an ethernet interface (as
    opposed to PPP0E) and have the same default gateway.

    As part of this change, the generated firewall script now
    automatically maintains the
    /var/lib/shorewall[6][-lite]/interface.status files used by SWPING
    and by LSM.

    See http://www.shorewall.net/MultiISP.html#load for additional
    information.

    Example that sends 1/3 of the connections to the ComcastC provider
    and the rest to ComcastB:

    /etc/shorewall/shorewall.conf

    MARK_IN_FORWARD_CHAIN=No
    ...
    USE_DEFAULT_RT=Yes

    /etc/shorewall/providers:

    #NAME    NUMBER MARK DUP  INTERFACE GATEWAY       OPTIONS
    ComcastB 1      -    -    eth1      70.90.191.126 loose,balance,load=0.66666667
    ComcastC 2      -    -    eth0      67.170.120.1  loose,fallback,load=0.33333333

    Note: The 'loose' option is specified so that the compiler will not
    	  generate and rules based on interface IP addresses. That way
	  we have complete control over the priority of such rules 
	  through entries in the rtrules file.

    /etc/shorewall/rtrules

    #SOURCE             DEST  PROVIDER  PRIORITY
    70.90.191.120/29    -     ComcastB  1000
    &eth0	    	-     ComcastC  1000

    Note: eth0 has a dynamic address, so &eth0 is used in the SOURCE
    	  column.

    Note: Priority = 1000 means that these rules will come before rules
    	  that select a provider based on marks.

10) The Shorewall files in /etc/default and /etc/sysconfig now support
    two new options that affect how '/etc/init.d/shorewall start' 
    and '/etc/init.d/shorewall restart' behave:

    STARTOPTIONS   -- options to the start commmand.
    RESTARTOPTIONS -- options to the restart command.

    For example, if you always want 'start' to flush the conntrack
    table, then you would have:

    	   STARTOPTIONS="-p"

11) The Git repository has been reorganized to place the samples and
    manpages under their corresponding product directories. For
    example, trunk/manpage6 was moved to trunk/Shorewall6/manpages.

