----------------------------------------------------------------------------
		     S H O R E W A L L  5 . 1 . 2 . 2
                       -----------------------------
                         M a r c h  0 7,  2 0 1 7
----------------------------------------------------------------------------

I.    PROBLEMS CORRECTED IN THIS RELEASE
II.   KNOWN PROBLEMS REMAINING
III.  NEW FEATURES IN THIS RELEASE
IV.   MIGRATION ISSUES
V.    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
----------------------------------------------------------------------------

5.1.2.2

1)  The IPv4 AllowICMPs macro has been changed to an inline action
    so that it may be used in the _DEFAULT settings in shorewall.conf.

2)  Previously, the IPv4 action REJECT(icmp-tcp-reset) produced an
    invalid iptables rule. That has been corrected. As part of this
    change, the action may also be written REJECT(tcp-reset).

3)  Previously, the following compiler directives were incorrectly
    being processed when they should have been omitted due to
    ?if...?else logic.

        ERROR
        WARNING
        INFO
        WARNING!
        INFO!
        REQUIRE

    That has been corrected.

4)  Previously, when LOAD_HELPERS_ONLY=Yes, the ?REQUIRES compiler
    directive could report that a capability was not available when it
    actually was. That has been corrected.

5)  Previously on Debian and derivatives, when systemd asked to stop a
    Shorewall firewall, the firewall would be placed in a safe state
    rather than cleared as was the default case with SysV init. Now,
    the firewall is cleared to conform to the Debian init convention,
    which requires that 'stop' should undo whatever 'start' did.

6)  When an inline action was used as a policy action, the compiler
    previously incorrectly applied the policy log level to each of the
    rules in the action. That has been corrected.

7)  Previously, inline policy actions had the policy log level applied
    to each rule rather than the level (if any) specified in the
    corresponding xxx_DEFAULT setting in shorewall[6].conf. That has
    been corrected.

5.1.2.1

1)  In Shorewall 5.1.2, the command 'shorewall show action allowinUPdP;
    fails with a 'file not found' error. That has been corrected.

2)  In Shorewall 5.1.2, when the BLACKLIST action is used in the
    blrules file, logging does not occur regardless of the setting of
    BLACKLIST_LOG_LEVEL. That has been corrected.

5.1.2

1)  Previously, when the 5.1 CLI program was run with no command given,
    a shell exception was raised. That has been corrected (Tuomo
    Soini).

2)  A caution has been added in shorewall[6]-rtrules regarding
    similar rules at the same priority.

3)  The 'dropBcasts' builtin action now works with
    Shorewall6. Previously, an attempt to use that action failed with a
    'missing action file' error.

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

2)  The 'enable', 'reenable' and 'disable' commands do not work
    correctly in configurations with USE_DEFAULT_RT=No and optional
    providers listed in the DUPLICATE column.

3)  While the 'ip' utility now accepts IPv6 routes with multiple
    'nexthop' destinations, these routes are not balanced. They are
    rather instantiated as a sequence of single routes with different
    metrics.  Furthermore,  the 'ip route replace' command fails on
    such routes. Beginning with Shorewall6 5.0.15, the generated script
    uses a "delete..add.." sequence on these routes rather than a
    single "replace" command.

----------------------------------------------------------------------------
      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)  Terminology change. What we've previously referred to as "default
    actions" are now called "policy actions" to better describe their
    purpose.

2)  The DROP_DEFAULT, REJECT_DEFAULT, etc. options may now specify a
    comma-separated list of actions rather than just a single
    action. The actions are invoked in the order in which they are
    listed and each action may optionally be followed by a colon (":")
    and a log level.

    The POLICY column in shorewall[6]-policy can now specify a
    similar list of actions. In that file, the list may be preceded by
    a plus sign ("+"), in which case the listed actions will be in
    addition to those listed in the related _DEFAULT setting in
    shorewall[6].conf.

3)  With the preceding change, the Drop and Reject policy actions are
    now deprecated in favor of a list of smaller actions. A warning is
    issued when these deprecated actions are used; the warning refers
    the reader to http://www.shorewall.net/Actions.html#Default.

4)  A LOG_LEVEL option has been added to shorewall[6].conf with default
    value 'info'. The sample config files have been updated to use
    $LOG_LEVEL rather than 'info' so that changing this option's
    setting will change all default packet logging. Like with any
    option, $LOG_LEVEL can be used throughout the configuration (with
    the exception of shorewall[6]-params).

5)  The LIMIT column in shorewall[6]-policy has been renamed RATE for
    consistency with shorewall[6]-rules. No change is required to
    existing configurations, including those that specify 'limit' in
    alternate input format.

6)  Beginning with this release, the allowBcast, dropBcast, and
    Broadcast no longer handling multicast. Multicast is handeled
    separately in actions allowMcast, dropMcast and Multicast. The
    now-deprecated Drop and Reject actions have been modified so that
    they continue to silently drop multicast packets. 

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

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

2)  Shorewall 5.1 now has a single CLI program, ${SBINDIR}/shorewall
    (normally /sbin/shorewall). This program performs all of the same
    functions previously performed by /sbin/shorewall,
    /sbin/shorewall6, /sbin/shorewall-lite and /sbin/shorewall6-lite
    and is installed as part of the Shorewall-core package. It's
    default 'personality' is determined by the Shorewall packages
    installed:

    a) If the Shorewall package is installed, then by default,
       /sbin/shorewall behaves as in prior versions.

    b) If the Shorewall package is not installed, but the
       Shorewall-lite package is present, then /sbin/shorewall behaves
       as did /sbin/shorewall-lite in prior versions.

    c) If neither the Shorewall nor Shorewall-lite packages are
       installed, but the Shorewall6-lite package is installed, then
       /sbin/shorewall behaves as did /sbin/shorewall6-lite in prior
       versions.

    The program's personality can be altered through use of two new
    options.

    -6  When specified, changes the personality from Shorewall to
     	Shorewall6 or from Shorewall-lite to Shorewall6-lite.

    -l  When specified, changes the personality from Shorewall to
     	Shorewall-lite or from Shorewall6 to Shorewall6-lite. This
     	option is only required when both the standard package
     	(Shorewall or Shorewall6) and the corresponding -lite package
     	are installed on the system.

    The following is a comparison of Shorewall 5.0 and Shorewall 5.1
    with respect to the CLI invocation:

    	 All four packages installed:

    	 Shorewall 5.0			Shorewall 5.1

	 shorewall 			shorewall
	 shorewall6			shorewall -6
	 shorewall-lite			shorewall -l
	 shorewall6-lite		shorewall -6l

	 Only Shorewall-lite and Shorewall6-lite installed:

	 Shorewall 5.0	     	        Shorewall 5.1

	 shorewall-lite			shorewall
	 shorewall6-lite		shorewall -6

    A single shorewall(8) manpage now describes the CLI.

    The shorewall6(8), shorewall-lite(8) and shorewall6-lite(8)
    manpages are now minimal and refer the reader to shorewall(8).

    For backward compatibility, Shorewall6, Shorewall-lite and
    Shorewall6-lite install symlinks $SBINDIR/shorewall6,
    $SBINDIR/shorewall-lite and
    $SBINDIR/shorewall6-lite respectively. When the shorewall program
    is invoked through one of these symlinks, it adopts the appropriate
    personality.

3)  The CHAIN_SCRIPTS option in the .conf files has been eliminated,
    and the compiler no longer looks for script files with the same
    name as a chain or action.

    If you are using such files, you will need to convert them into
    equivalent ?begin perl .... ?end perl text or to use the
    IP[6]TABLES target and/or inline matches.

    For the common case where you have an action xxx with an empty
    action.xxx file and have perl code in a file named xxx, the
    compiler will now generate a fatal error:

      ERROR: File action.xxx is empty and file xxx exists - the two
      	     must be combined as described in the Migration
      	     Considerations section of the Shorewall release notes

    For information about resolving this error, see
    http://www.shorewall.org/Shorewall-5.html#idp41228128.

4)  The Netfilter team have removed support for the rawpost table, so
    Shorewall no longer supports features requiring that table
    (stateless netmapping in the netmap file). The good news is that,
    since kernel 3.7, Netfilter supports stateful IPv6 network mapping
    which is now also supported in Shorewall6 (see
    shorewall6-netmap(5)).

5)  The (undocumented) Makefiles haven't been maintained for many
    releases and have been removed.

6)  Beginning with Shorewall 5.1.2, The DROP_DEFAULT, REJECT_DEFAULT,
    etc. options may now specify a comma-separated list of actions
    rather than just a single action. The actions are invoked in the
    order in which they are listed and each action may optionally be
    followed by a colon (":") and a log level.  The POLICY column in
    shorewall[6]-policy can now specify a similar list of actions. In
    that file, the list may be preceded by a plus sign ("+"), in which
    case the listed actions will be in addition to those listed in the
    related _DEFAULT setting in shorewall[6].conf.

    With these changes, the Drop and Reject policy actions are now
    deprecated in favor of a list of smaller actions. A warning is
    issued when these deprecated actions are used; the warning refers
    the reader to http://www.shorewall.net/Actions.html#Default.

7)  Beginning with Shorewall 5.1.2, the allowBcast, dropBcast, and
    Broadcast no longer handling multicast. Multicast is handeled
    separately in actions allowMcast, dropMcast and Multicast. The
    now-deprecated Drop and Reject policy actions have been modified so
    that they continue to silently drop multicast packets. 

----------------------------------------------------------------------------
         V.  N O T E S  F R O M  O T H E R  5 . 1  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  5 . 1 . 0
----------------------------------------------------------------------------
1)  This release contains defect repair up through Shorewall 5.1.0.1.

2)  Previously, expanded variables would be enclosed in single quotes
    in ?ERROR, ?WARNING and ?INFO directive output. That has been
    corrected.

3)  The obsolete Drop and Reject macros have been removed (Drop and
    Reject are now actions rather than macros).

4)  A typo has been corrected in the parameter descriptions in
    action.Drop and action.Reject.

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

1)  Previously, the compiler did not check for routefilter/provider
    issues. Now, a fatal compilation error is raised in the following
    cases:

    a)  USE_DEFAULT_RT=Yes, ROUTE_FILTER=Yes in shorewall.conf and a
        regular provider (not tproxy) is defined in the
        providers file.

    b)  USE_DEFAULT_RT=Yes and a provider interface specifies a
    	non-zero value for the 'routefilter' option in the interfaces
        file.

    c)  USE_DEFAULT_RT=No, ROUTE_FILTER=Yes in shorewall.conf, and
        a provider interface doesn't specify the 'balance' or 'primary'
    	option in the providers file.

    d)  USE_DEFAULT_RT=No, a provider interface specifies the non-zero
        value for the 'routefilter' option in the interfaces file but
	does not specify the 'balance' or 'primary' option in the
    	providers file.

2)  When 'routefilter' is specified by itself or with a non-zero value
    (e.g., routefilter=1), the 'logmartians' option is now also set
    implicitly when LOG_MARTIANS=No. If you actually want route
    filtering without logging, then you must also include
    'logmartians=0'.

3)  Since the creation of the USE_DEFAULT_RT option, when
    USE_DEFAULT_RT=Yes, 'balance=1' is assumed on all provider
    interfaces unless 'fallback', 'load', 'primary', 'loose' or
    'tproxy' is specified. This makes it awkward to define a provider
    that does not generate a default route in either the 'balance' or
    'default' routing tables; it is necessary to specify 'loose' then
    add the routing rules that are suppressed by that option.

    To address this issue, it is now possible to specify
    BALANCE_PROVIDERS=No. When BALANCE_PROVIDERS=No and none of the
    above-listed options is specified, the provider will generate no
    entry in the 'balance' or 'default routing tables irrespective of
    the setting of USE_DEFAULT_RT.

    All of the released shorewall[6].conf files now specify
    BALANCE_PROVIDERS=No. The default value is the effective setting of
    USE_DEFAULT_RT to provide backward compatibility with earlier
    releases.

4)  When using ipset-based dynamic blacklisting, it is now possible to
    specify BLACKLIST in the POLICY column of policy files. When
    BLACKLIST is specified, the source IP address is automatically
    added to the dynamic blacklist ipset and then the packet is
    dropped. This new policy adds BLACKLIST_DEFAULT to
    shorewall[6].conf; the default setting is "Drop".

5)  A BLACKLIST action has been added; the action adds the sender to
    the dynamic blacklist IPSET.

    BLACKLIST accepts two optional argument:

    1 - Action to take after adding the sender to the ipset. Default is
        DROP.
    2 - specifies the timeout for the added/updated entry.

    If no timeout is passed, the one specified in
    DYNAMIC_BLACKLIST, if any, is used. Otherwise, the one specified
    when the ipset was created, if any, is used.

6)  Given that there was already a BLACKLIST macro which implemented
    the BLACKLIST action in blrules, the preceding change required that
    BLACKLIST behave differently when invoked from the blrules file and
    when invoked from the rules file. Because BLACKLIST invoked from
    the rules file normally generates two rules, an action (not
    inlined) is more appropriate there than is a macro. When it is
    invoked from the blrules file, it only generates a single rule so
    the optimizer will inline it anyway.

    For historical reasons, the compiler treats the blrules file as if
    it were the section BLACKLIST in the rules file. So, to implement
    this dual behavior in the BLACKLIST action, a new 'section' option
    has been added in the action file. When 'section' is specified, the
    name of the current section and a comma are prepended to the
    argument list passed when invoking the action. The action.BLACKLIST
    file then has the following structure:

    	 ?if @1 eq 'BLACKLIST'
	    <logic to generate rule from the blrules file>
	 ?else
	    <logic to generate rules from the rules file>
	 ?endif

7)  There is now a 'show action <action>' command for Shorewall and
    Shorewall6. The command displays the action file for the specified
    <action>.

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

5.1.0.1

1)  Shorewall6-lite 5.1.0 failed to start under systemd. That has
    been corrected.

2)  Previously, the setting of PAGER in shorewall[6].conf was not
    propagated to a remote configuration during 'export',
    'remote-start', 'remote-reload' and 'remote-restart'. That has been
    corrected.

5.1.0

1)  This release includes defect repair through Shorewall 5.0.15.2.

2)  A defect associated with CHAIN_SCRIPTS=Yes previously prevented
    some of the optimizations associated with optimize level 4 from
    being applied. Removal of the CHAIN_SCRIPT option (see below) has
    eliminated the defect.

3)  The install.sh and uninstall.sh have had some minor cleanup (Matt
    Darfeuille).

4)  Previously, when SAVE_IPSETS=Yes or SAVE_IPSETS=ipv4, the restore
    phase of a rejected safe-restart would fail. That has been
    corrected.

5)  It is now possible to include compact IPv6 addresses (those with
    "::") in IP6TABLES() parameters. Previously, such addresses
    resulted in an "INVALID ACTION..." error.

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

1)  Shorewall 5.1 now has a single CLI program, ${SBINDIR}/shorewall
    (normally /sbin/shorewall). This program performs all of the same
    functions previously performed by /sbin/shorewall,
    /sbin/shorewall6, /sbin/shorewall-lite and /sbin/shorewall6-lite
    and is installed as part of the Shorewall-core package. It's
    default 'personality' is determined by the Shorewall packages
    installed:

    a) If the Shorewall package is installed, then by default,
       /sbin/shorewall behaves as in prior versions.

    b) If the Shorewall package is not installed, but the
       Shorewall-lite package is present, then /sbin/shorewall behaves
       as did /sbin/shorewall-lite in prior versions.

    c) If neither the Shorewall nor Shorewall-lite packages are
       installed, but the Shorewall6-lite package is installed, then
       /sbin/shorewall behaves as did /sbin/shorewall6-lite in prior
       versions.

    The program's personality can be altered through use of two new
    options.

    -6  When specified, changes the personality from Shorewall to
     	Shorewall6 or from Shorewall-lite to Shorewall6-lite.

    -l  When specified, changes the personality from Shorewall to
     	Shorewall-lite or from Shorewall6 to Shorewall6-lite. This
     	option is only required when both the standard package
     	(Shorewall or Shorewall6) and the corresponding -lite package
     	are installed on the system.

    The following is a comparison of Shorewall 5.0 and Shorewall 5.1
    with respect to the CLI invocation:

    	 All four packages installed:

    	 Shorewall 5.0			Shorewall 5.1

	 shorewall 			shorewall
	 shorewall6			shorewall -6
	 shorewall-lite			shorewall -l
	 shorewall6-lite		shorewall -6l

	 Only Shorewall-lite and Shorewall6-lite installed:

	 Shorewall 5.0	     	        Shorewall 5.1

	 shorewall-lite			shorewall
	 shorewall6-lite		shorewall -6

    A single shorewall(8) manpage now describes the CLI.

    The shorewall6(8), shorewall-lite(8) and shorewall6-lite(8)
    manpages are now minimal and refer the reader to shorewall(8).

    For backward compatibility, Shorewall6, Shorewall-lite and
    Shorewall6-lite install symlinks $SBINDIR/shorewall6,
    $SBINDIR/shorewall-lite and
    $SBINDIR/shorewall6-lite respectively. When the shorewall program
    is invoked through one of these symlinks, it adopts the appropriate
    personality.

2)  Several settings in the default/sample .conf files have been
    modified:

    a)  The LOGFORMAT setting has been changed from "Shorewall:%s:%s:"
    	to "%s %s " to enable longer zone names.

    b)  The LOGLIMIT setting has been changed from empty to
    	"s:1/sec:10", to enable log trottling by default.

    c)  The AUTOMAKE setting has been changed from "No" to "Yes", to
    	avoid unnecessary recompilation.

    d)  The IP_FORWARDING setting has been changed from "On" to "Keep"
    	in shorewall.conf to accomodate cases where forwarding has been
    	configured before installing Shorewall.

    e)  The OPTIMIZE setting has been changed to "All", to create more
    	compact rulesets by default.

    f)  TC_CLEAR has been set to "No" in the shorewall6.conf files.

3)  The allowed syntax in the SOURCE and DEST columns in the rules file
    has been extended to allow multiple comma-separated
    <zone>:[<interface>:][<address-list>] tupples in a single
    rule. Where the <address-list> lists mulitiple addresses separated
    by commas, the <address-list> must be enclosed in parentheses.

    Example: net:(1.2.3.4,2.3.4.5),dmz:(5.6.7.8,6.7.8.9)

    See shorewall[6]-rules(5) for details.

    A similar change has been made to the conntrack and mangle files,
    where multiple <interface>:<address-lists> groups can be specified:

    Example: eth0:(1.2.3.4,2.3.4.5),eth1(5.6.7.8,6.7.8.9)

    See shorewall[6]-conntrack(5) and shorewall[6]-mangle(5) for
    details.

5)  The CHAIN_SCRIPTS option in the .conf files has been eliminated,
    and the compiler no longer looks for script files with the same
    name as a chain or action.

    If you are using such files, you will need to convert them into
    equivalent ?begin perl .... ?end perl text or to use the
    IP[6]TABLES target and/or inline matches.

    See http://www.shorewall.org/Shorewall-5.html#idp41228128.

5)  The --queue-cpu-fanout NFQUEUE option is now supported in NFQUEUE
    rules and policies. It is enabled by following the high queue
    number with the letter 'c' (e.g., NFQUEUE(0:3c)). This option
    requires 'NFQUEUE CPU Fanout' support in your kernel and
    ip[6]tables.

6)  A SWITCH column has been added to the mangle files. See
    shorewall[6]-mangle(5) for details.

7)  A 'show ipsec' command has been added. This command displays the
    contents of the IPSEC "Security Policy Database" (SPD) and
    "Security Association Database" (SAD). SAD keys are not shown.

8)  The Netfilter team have removed support for the rawpost table, so
    Shorewall no longer supports features requiring that table
    (stateless netmapping in the netmap file). The good news is that,
    since kernel 3.7, Netfilter supports stateful IPv6 network mapping
    which is now also supported in Shorewall6 (see
    shorewall6-netmap(5)).

9)  In the released tarballs, the action.* files now reside in a
    separate Actions/ directory.

10) The 'echo' builtin in recent versions of the dash shell does not
    support the -n option. To accomodate that version, Shorewall no
    longer uses either the -e or -n options.

11) When LOAD_HELPERS_ONLY=No, additional modules required for NAT are
    now loaded.

12) The (undocumented) Makefiles haven't been maintained for many
    releases and have been removed.
1
