----------------------------------------------------------------------------
	            S H O R E W A L L  5 . 1 . 1 2 . 2
                      -------------------------------
                      F e b r u a r y  2 1 ,  2 0 1 8
----------------------------------------------------------------------------

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

1)  The 5.1.12 change that emits warnings when INLINE_MATCHES=Yes did
    not issue a warning when a single semicolon was used to introduce
    inline matches in INLINE, IPTABLES and IP6TABLES rules. That has
    been corrected. Additionally, 'shorewall[6] update' now replaces
    ';' with ';;' in those rules.

    As part of that change, the documentation has been modified to
    prefer ';;' over ';' to introduce inline matches in those rules.

2)  The 'shorewall[6] update' command now replaces a single semicolon
    with double semicolons in INLINE, IPTABLES and IP6TABLES rules.

3)  A typo has been corrected so that the following error message is
    now printed correctly.

        ERROR: The REJECT_ACTION (<action name>) is not terminating

    Previously, an "unknown function" Perl diagnostic was issued in its
    place.

4)  Previously, if a policy action specification in shorewall[6].conf
    or in the policy file included a log tag, a garbled error message
    was issued. That has been corrected.

5)  Under rare rare circumstances, syn flood limiting specified in a
    policy was previously not enforced by the generated ruleset. That
    has been corrected.

5.1.12.1

1)  The macro SSDPServer released in 5.1.12 inadvertently contained the
    content of macro.SSDP. The corrected macro is now available as
    macro.SSDPserver (note the lower case 's' in 'server').

2)  When double semicolons (";;") were used to introduce inline
    matches, column/value pairs enclosed in braces ("{...}") were not
    recongnized correctly if there was any white space between the
    closing brace ("}") and the semicolons. That problem has been
    corrected.

5.1.12

1)  This release contains defect repair from releases through 5.1.11.2.

2)  Many typos in comments in the chains module have been corrected.

3)  Dead code was removed.

4)  A function that is called only from lib.cli-std had been moved
    there from lib.cli.

5)  Trailing white space is now omitted from the generated script.

6)  Apparently random blank lines in the generated script have been
    eliminated.

7)  Previously, the output of 'shorewall show capabilties' only
    displayed the 'Ipset Match (IPSET_MATCH)' capability if it was
    available. Now, it is also displayed when it is not available.   

----------------------------------------------------------------------------
           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)  Beginning with this release, SNAT can be performed on flows
    destined for the firewall itself. In this case, SNAT will be
    performed in the INPUT chain of the nat table; see
    shorewall-snat(5) for details.

    This change introduced a new capability:

        INPUT chain in the nat table (NAT_INPUT_CHAIN)

2)  The undocumented optimize option OPTIMIZE_USE_FIRST (0x1000)
    has been removed.

3)  Some minor performance enhancements have been make to optimization
    category 8.

4)  While INLINE_MATCHES=Yes has been documented as deprecated for some
    time, it has thus far not generated a warning. Beginning with this
    release, a warning is issued:
    
        WARNING: Option INLINE_MATCHES=Yes is deprecated

    See the Migration Issues section for additional information.

5)  The IPMI macro has been extended to include additional protocols
    (Tuomo Soini).

6)  Several new macros have been added:

        Apcupsd
	FreeIPA
	Kpasswd
	RedisSecure
	Rwhois
	SSDP
	SSDPServer

    (Tuomo Soini)

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

8)  According to the Netfilter team (see
    https://patchwork.kernel.org/patch/9198133/), the --nflog-range option
    of the NFLOG target has never worked correctly, and they have
    deprecated that option in favor of the --nflog-size option.

    To accomodate this change, Shorewall 5.1.5 added an "--nflog-size
    support" (NFLOG_SIZE) Shorewall capability and a USE_NFLOG_SIZE
    option in shorewall[6].conf. If USE_NFLOG_SIZE=Yes, then if the
    capability is present, Shorewall will use '--nflog-size' in place
    of '--nflog-range'. If USE_NFLOG_SIZE=Yes and the capability is not
    present, an error is raised.

    If you don't use NFLOG or if you use NFLOG with omittted second
    parameter or with 0 as the second parameter, and 'shorewall show
    capabilities' indicated that --nflog-size support is present, you
    may safely set USE_NFLOG_SIZE=Yes.

    If you pass a non-zero value as the second parameter to NFLOG and
    the '--nflog-size support' capability is present, you need to
    verify that those NFLOG messages are as you expect with
    USE_NFLOG_SIZE=Yes.

9)  The MODULE_SUFFIX option in shorewall[6].conf was eliminated in
    Shorewall 5.1.7. Shorewall now finds modules, independent of their
    filename suffix.

    'shorewall [-6] update' will automatically remove any MODULE_SUFFIX
    setting.

10)  Beginning with Shorewall 5.1.8, when RESTORE_DEFAULT_ROUTE=Yes the
    default route is only restored when there are no enabled
    'balance/primary' providers and no enabled fallback providers.

    Also beginning with Shorewall 5.1.8, if the default route(s) have
    been restored to the 'main' table, and a fallback provider is
    successfully enabled, the default route(s) are removed from the
    main table.

11) Because restoring default routes to the main routing table can
    break the ability of Foolsm and other link status monitors to
    properly detect non-functioning provider links, a warning message
    is issued when the 'persistent' provider option is specified and
    RESTORE_DEFAULT_ROUTE=Yes.

      WARNING: When RESTORE_DEFAULT_ROUTE=Yes, the 'persistent' option
               may not work as expected

    This change was released in Shorewall 5.1.8.

12) Most interface OPTIONS have always been ignored when the INTERFACE
    name is '+'. Beginning with the Shorewall 5.1.10 release, a warning
    is issued when an ignored option is specified with interface name '+'.

	Example: The 'sourceroute' option is ignored when used with
		 interface name '+'

    In many cases, this issue can be worked around by a change similar
    to the following:

    Original:

	net	+		dhcp,routeback,sourceroute=0

    Change to:

	net	all		dhcp,physical=+,routeback,sourceroute=0
		---		     ----------

    As part of this change, interfaces that specify a wildcard physical
    interface name will generate a warning if any of the following
    options are specified:

	accept_ra
	arp_filter
	arp_ignore
	forward
	logmartians
	proxyarp
	proxyndp
	routefilter
	sourceroute

    When the warning is issued, the specified option is then ignored
    for the interface.

    Example:

	WARNING: The 'sourceroute' option is ignored when used with a
		 wildcard physical name
		 /etc/shorewall6.universal/interfaces (line 14)

13) INLINE_MATCHES=Yes has been documented as deprecated for some
    time, but it has not generated a warning. Beginning with the
    Shorewall 5.1.12 release, a warning is issued:
    
        WARNING: Option INLINE_MATCHES=Yes is deprecated

    Additionally, each line that requires modification to work with
    INLINE_MATCHES=No is flagged with the warning:

        WARNING: This entry needs to be changed (replace ';' with ';;')
		 before the INLINE_MATCHES option is removed in
		 Shorewall 5.2

    You can eliminate the warnings by setting INLINE_MATCHES=No and
    by replacing the single semicolon (";") separating inline matches
    from the column-oriented part of the rule with two semicolons
    (";;") in each entry flagged by the second warning.

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

5.1.11.1

1)  When AUTOMAKE=Yes and the 'find' utility is Busybox-based,
    Shorewall 5.1.11 would fail during compilation with the error:

        find: unrecognized: -quit

    That has been corrected.

5.1.11

1)  This release contains defect repair from releases through 5.1.10.2.

2)  Previously, if DYNAMIC_BLACKLIST=ipset,disconnect..., the CLI would
    verify the existence of the 'conntrack' utility on the local system
    when the command was 'remote-start', 'remote-reload' or
    'remote-restart'. Now, that verification is only done for the
    blacklist-oriented commands ('blacklist', 'allow', 'drop', etc.).

3)  Previously, when DYNAMIC_BLACKLIST=ipsec..., the CLI required the
    firewall to be started in order to run the 'allow' command. Now,
    the command only requires that the dynamic blacklist ipset
    exists.

4)  Previously, if an address variable was used in the stoppedrules
    file, the 'clear' command could fail in two different ways,
    depending on whether the related interface was optional or not.

    If the interface was optional, the failure message was similar to
    the following:

       $ shorewall clear
       Clearing Shorewall....
       Preparing iptables-restore input...
       /var/lib/shorewall/firewall: 3064: [: !=: unexpected operator
       Running /sbin/iptables-restore...
       IPv4 Forwarding Enabled
       done.

    If the interface was not optional, the result was similar to:

       $ shorewall debug clear
       Clearing Shorewall....
       Preparing iptables-restore input...
       Running debug_restore_input...
       Bad argument `6'
       Try `iptables -h' or 'iptables --help' for more information.
          ERROR: Command "/sbin/iptables --wait -t filter -A INPUT -s
	  172.17.211.254 -d  -p 6 --dport 22 -i enp2s0 -j ACCEPT"
	  Failed
      Terminated

    This problem has been corrected.

5)  Previously, the 'clear' command enabled forwarding
    unconditionally. Beginning with this release, 'clear' will
    conditionally enable/disable forwarding in the same manner as
    'stop'.

6)  In multi-ISP configurations, it is possible for an IPSEC-tunneled
    connection from the Internet to be forwarded back out to the
    Internet (for example, if all traffic from the remote endpoint is
    sent through the tunnel). If the provider handling the tunnel has
    the 'track' option (or if TRACK_PROVIDERS=Yes), then the outgoing
    tunneled connection is sent back out that interface by
    default (since the encapsulated initial packet arrived through that
    interface). Since this is not always desirable, Shorewall now
    clears the tracking mark on the connection while processing the
    first packet, allowing the connection to not match routing rules
    that are dependent on the tracking mark.

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

1)  Previously, the 'show' command was not available to non-root
    users. Beginning with this release, non-root users may now
    run the following 'show' commands:

    	show action <action>
	show actions
	show ip
	show macro <macro>
	show macros
	show routing

2)  When a RATE is specified on a policy, the rate is enforced in a
    chain whose name begins with '@' (e.g., @net-dmz). Previously, log
    messages in the chain omitted the '@', leading to possible
    confusion. Beginning with this release, the log message will
    reflect the chain's actual name (including the '@').

3)  To improve efficiency, TCP CT entries in the conntrack file and
    TCP entries in the rules file that specify a HELPER will now
    assume that 'tcp:syn' had been specified. That way, the generated
    ip[6]tables rule will only match on the first packet of the
    three-way handshake.

4)  Now that the route caches have been removed from the kernel,
    Multi-ISP really doesn't work without the 'track' provider option.
    As a consequence, TRACK_PROVIDERS=Yes is now the default. Note that
    the 'track' option may still be turned off using 'notrack', when
    TRACK_PROVIDERS=Yes.

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

5.1.10.2

1)  When AUTOMAKE=Yes, the commands 'start', 'restart' and 'reload'
    cause the 'find' utility to be run in each entry in the CONFIG_PATH
    to look for files that have been modified since the current
    firewall script was created.There are two related defects in 5.1.10
    and 5.1.10.1 that manifest when AUTOMAKE=Yes. 

    a) While the compiler only searches in the directories themselves,
       'find' was not limited to just those directories, but was rather
       searched the entire tree rooted in each path in CONFIG_PATH.

    b) If the CONFIG_PATH was prefixed by ":", then there was
       effectively an empty path in CONFIG_PATH, which resulted in a
       search of the entire tree rooted in the current working
       directory.

    Both problems have been corrected:

    a) Find is run with '-maxdepth 1', to limit the search to just the
       files in the directory.

    b) Find is not run on empty paths in CONFIG_PATH.

5.1.10.1

1)  The Shorewall-core installer previously failed to update the shell library
    files correctly when SHAREDIR was not set to /usr/share/. That has
    been corrected.

2)  Previously, the installer modified the shorewall[6].conf installed
    in /etc/shorewall[6] based on the Linux distribution (HOST in
    shorewallrc) but installed an unmodified file in
    /usr/share/shorewall/configfiles/. Beginning with this release,
    the modified file is also installed in the latter directory.

5.1.10

1)  Several typos have been corrected in the manpages (Roberto
    Sánchez).

2)  Regarding Known Problem 3 below, the code added in 5.0.15 could
    fail to delete an existing default route if the new default route
    was not identical to the one being replaced. Now, the default route
    is deleted, even the new route is different.

3)  Previously, if the 'ss' utility was not installed but 'netstat' was
    installed, the 'dump' command would issue the error message

        /sbin/shorewall: line 1: netatat: not found

    and the dump would not contain socket information. That problem
    has been corrected.

4)  Previously, a plain 'reset' command would only reset counters in
    the 'filter' and 'mangle' tables. Now, all four tables have their
    counters reset.

5)  Specifying IN-BANDWIDTH would previously cause a run-time
    start/restart/reload failure when a later version of iproute2 was
    installed. The problem has been observed on both iproute2 4.13.0
    and 4.14.0. The failure message was similar to the following:

     Setting up Traffic Control...
     "rate" or "avrate" MUST be specified.
     Illegal "police"
     ERROR: Command "tc filter add dev ppp0 parent ffff: protocol all
     prio 10 basic police mpu 64 drop rate 55378kbit burst 10kb" Failed

    This problem has been resolved.

6)  Previously, Shorewall-init would recompile the firewall script each
    time that it ran. Now, it only compiles the script if it doesn't
    exist.

7)  Most interface OPTIONS have always been ignored when the INTERFACE
    name is '+'. Beginning with this release, a warning is issued when
    an ignored option is specified with interface name '+'.

	Example: The 'sourceroute' option is ignored when used with
		 interface name '+'

    In most cases, this issue can be worked around by a change similar
    to the following:

    Original:

	net	+		dhcp,routeback,sourceroute=0

    Change to:

	net	all		dhcp,physical=+,routeback,sourceroute=0
		---		     ----------

    As part of this change, interfaces that specify a wildcard physical
    interface name will generate a warning if any of the following
    options are specified:

	accept_ra
	arp_filter
	arp_ignore
	forward
	logmartians
	proxyarp
	proxyndp
	routefilter
	sourceroute

    When the warning is issued, the specified option is then ignored
    for the interface.

    Example:

	WARNING: The 'sourceroute' option is ignored when used with a
		 wildcard physical name
		 /etc/shorewall6.universal/interfaces (line 14)

8)  When the IPv6 Universal sample configuration was used, the
    following warning was issued during start/restart/reload:

        WARNING: Cannot set Accept Source Routing on +

    The Universal interfaces file has been corrected to eliminate that
    error.

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

1)  Previously, it was necessary to remove ${CONFDIR}/shorewall[6] from
    the CONFIG_PATH to create a configuration directory for a remote
    firewall managed by shorewall[6]-lite. Without this modification,
    when the compiler looked for a file that was not present in the
    configuration directory, it would attempt to read the file by the
    same name residing in ${CONFDIR}/shorewall[6].

    Now, if the setting of CONFIG_PATH begins with a colon (":"),
    the first directory in the path is ignored when compiling for
    export or when the user running the compiler is not root.
    The released copies of shorewall[6].conf have all been modified to
    set CONFIG_PATH with a leading colon.

2)  The documentation surrounding use of DNS names in Shorewall
    configuration has been improved.

3)  It is now possible to associate a particular protocol with an
    action in shorewall[6]-actions(5). When a protocol is specified in
    that file, it is not necessary to specify the protocol in the PROTO
    column when invoking the action. If a protocol is included in the
    PROTO column then it must match the one specified in the actions
    file. If an action defined with a protocol is used as a Policy
    Action, then only packets with the specified protocol will be
    passed to the action.

    A number of standard actions definitions in
    /usr/share/shorewall[6]/actions.std have had a protocol added.

    The protocol has no effect if 'builtin' or 'inline' is also
    specified; specifying 'builtin' with a protocol results in a
    warning message. No warning is issued when 'inline' is specified
    with a protocol, thus allowing 'inline' and a protocol to appear
    together in actions.std. Note that 'noinline' in
    shorewall-actions(5) can override an 'inline' specification in
    actions.std.

4)  The FIN action previously included the PSH flag (FIN,ACK,PSH). To
    make the action a bit more general, the PSH flag is now removed and
    TCP packets with just the FIN and ACK flags set will now match.

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

1)  This release includes defect repair through Shorewall 5.1.8.1.

2)  Previously, Shorewall6 did not accept square brackets ("[...]")
    around the GATEWAY address in a Providers file entry. That has been
    corrected, so that the usual convention of enclosing IPv6 addresses
    in square brackets is allowed in that context.

3)  Previously, if the IP variables was set in a remote firewall's
    configuration directory, and the named file did not exist on the
    local administrative system, then a fatal error was raised.

    Example:

       ERROR: The program specified in IP (/usr/bin/ip) does not exist
       	      or is not executable

    Beginning with this release, the contents of the IP option will not
    be verified at compile time when compiling for export.

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

1)  The mangle file now supports a TCPMSS action for setting the MSS
    value in TCP SYN packets. See shorewall-mangle(5) for details. As
    part of this change, the TCPMSS rule generated by the CLAMPMSS
    option has been moved from the filter table FOWARD chain to the
    mangle table FORWARD chain.

2)  The Broadcast and Multicast actions are now inlined when the
    Address Type Match capability is available.

3)  It is now possible to specify 'noinline' in an entry in
    /etc/shorewall[6]/actions to override the 'inline' option
    specified in /usr/share/shorewall/actions.std.

4)  Logging is now supported in the snat file.

    - Log levels may be specified on SNAT, MASQUERADE and CONTINUE
      rules.

    - The NFLOG, ULOG and LOG actions are now supported.

    See shorewall-snat(5) for details.

5)  A logging manpage (shorewall-logging(5)) has been added.

6)  The IPMI macro now includes support for Redfish remote consoles.

7)  The Sample configuration files now use logical interface names to
    simplify adapting them to fit the newer interface naming
    convention adopted by the kernel.

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

1)  This release includes defect repair through Shorewall 5.1.7.2.

2)  The copyright dates and product version comments have been updated
    in a number of files.

3)  The undocumented and unmaintained Makefile files for Shorewall-lite
    and Shorewall6-lite have been removed from Shorewall and Shorewall6
    respectively.

4)  The 'dump' command logic now does a better job of detecting
    and suppressing the printing of empty IPSec SPD entries.

5)  A number of issues with persistent providers that resulted in
    'ip rule add' and 'ip route add' failures have been corrected. The
    most common senario involved a 'reload' while a persistent
    interface was disabled.

6)  Previously, the generated script contained incorrect logic for
    deleting default routes with metric zero ('balanced' routes and
    routes generated by 'fallback=nn'); the logic only worked correctly
    when applied to the 'main' routing table. It now works correctly
    for all routing tables.

7)  The 'ip xfrm policy' command ignores the -4 and -6 options and
    dumps the policies for both address families. This release contains
    a workaround that suppresses entries for the other family.

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

1)  For historical reasons, Shorewall has always assumed that LOG target
    support is present unless proven otherwise. While this has worked
    correctly when a capabilities file is used and when
    LOAD_HELPERS_ONLY=No, it can generate an unworkable firewall
    script when LOAD_HELPERS_ONLY=Yes.

    Beginning with this release, Shorewall will treat LOG target like
    any other capability and will verify its presense in all cases
    where the target is used.

2)  The level 4 optimizer now does a better job of handling small
    chains with rules specifying an IPSEC policy. This can result in
    elimination of these chains.

3)  Beginning with this release, when RESTORE_DEFAULT_ROUTE=Yes the
    default route is only restored when there are no enabled
    'balance/primary' providers and no enabled fallback providers.

    Also beginning with this release, if the default route(s) have been
    restored to the 'main' table, and a fallback provider is
    successfully enabled, the default route(s) are removed from the
    main table.

4)  Because restoring default routes to the main routing table can
    break the ability of Foolsm and other link status monitors to
    properly detect non-functioning provider links, a warning message
    is now issued when the 'persistent' provider option is specified
    and RESTORE_DEFAULT_ROUTE=Yes.

      WARNING: When RESTORE_DEFAULT_ROUTE=Yes, the 'persistent' option
               may not work as expected

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

5.1.7.2

1)  Previously during the opening of a configuration file, if SELinux
    denied the "getattr" (stat) request, then the compiler would skip
    processing of the file as if it did not exist. Now, if "getattr"
    fails for any reason other than that the file does not exist, an
    error is raised.

       ERROR: Unable to access <filename>: <reason for denial>

2)  Previously, when a range was passed to the MARK() action (mangle
    file), any specified protocol, port and time restrictions were
    ignored. Now these elements are included in the rule. 

5.1.7.1

1)  Previously, the 'reenable' command failed on a persistent provider
    interface with a message similar to the following:

     RTNETLINK answers: File exists
     ERROR: Command "/sbin/ip -4 rule add from 10.2.10.2 pref 20000
                     table IPv6Beta" Failed

   That problem has been corrected and the 'reenable' command now
   works properly on both persistant and non-persistant interfaces.

   Note: The firewall script must be recompiled in order for this
         change to become effective.

5.1.7

1)  This release includes defect repair through Shorewall 5.1.6.1.

2)  Previously, there was a typo in IPv4 Example 5 in the
    shorewall-snat(5) manpage. The DEST column contained

        eth0+myset[dst]

    which should have been

        eth0:+myset[dst]

    That has been corrected.

3)  Previously, specifying an ipset name in the DEST column of the IPv4
    snat file had no effect. That has been corrected so that only
    connections whose destination matches the ipset are affected by the
    rule.

4)  Previously, passing an invalid vlsm to the 'ipcalc' command coult
    result in a series of shell diagnostics beginning with:

      shorewall: 3730: /home/teastep/bin/shorewall: Invalid VLSM: not
                                                    found

    That has been corrected so that the correct message is issued:

      ERROR: Invalid VLSM

    (Tuomo Soini)

5)  ADD_IP_ALIASES has defaulted to Yes for both Shorewall and
    Shorewall6, leading to 'not found' errors during
    start/reload/restart. Now, ADD_IP_ALIASES=No is the default for
    IPv6 and may not be changed.

6)  When Shorewall-init was configured to save ipsets, it could leave
    behind an empty or useless .tmp file if no ipsets were saved. Now
    that file is removed automatically.

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

1)  Loading of kernel modules has been streamlined (Tuomo Soini).

2)  The MODULE_SUFFIX option in shorewall[6].conf has been
    eliminated. Shorewall now finds modules, independent of their
    filename suffix.

    'shorewall [-6] update' will automatically remove any MODULE_SUFFIX
    setting.

3)  When 'detect' is specified in the GATEWAY column for a provider,
    the generated script now looks for an existing default route in
    the provider's routing table to obtain the provider's default
    gateway. This is useful when dhcpcd5 is installed, since the .lease
    files created by dhcpcd5 are binary coded and are hence not usable
    for learning the configured gateway.

4)  The Shorewall Event actions (IfEvent, SetEvent and ResetEvent) now
    accept DNAT and REDIRECT as the <action> argument. For DNAT, a
    server address must be specified in the DEST column. A server port
    may NOT be specified in the DEST column, so the port number cannot
    be changed by the action.

5)  Shorewall now supports Docker configuration that create the
    DOCKER-INGRESS chain in the filter table.

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

1)  This release contains defect repair through Shorewall 5.1.5.2.

2)  http://www.shorewall.net/shorewall_extension_scripts.htm states
    that $SHAREDIR and $CONFDIR can be used in extension scripts, that
    has not been true for some time. Beginning with this release, those
    variables are once again available in the generated script.

3)  Under very rare circumstances, when OPTIMIZE level 8 was used,
    messages such as the following could be issued during compilation:

    Use of uninitialized value in hash element at
       /usr/share/shorewall/Shorewall/Rules.pm line 818.
    Use of uninitialized value in concatenation (.) or string at
       /usr/share/shorewall/Shorewall/Rules.pm line 823.

    That has been corrected.

4)  Previously, Shorewall's treatment of wildcard interfaces differed
    from Netfilter's. Shorewall did not consider 'eth' to match 'eth+'
    while Netfilter did. Beginning with this release, Shorewall is
    consistent with Netfilter.

5)  Previously, systemd could attempt to start the IPv4 and IPv6
    firewalls simultaneously, which might lead to iptables-restore and
    ip6tables-restore being run at the same time resulting in a failure
    to start one of the firewalls.

    Beginning with this release, Shorewall and Shorwall6 will be
    started serially as will Shorewall-lite and Shorewall6-lite.

6)  To prevent other init systems from starting the IPv4 and IPv6
    firewalls in parallel, the ip[6]-tables-restore '--wait' option, if
    available, is used. This change introduces a new
    RESTORE_WAIT_OPTION capability.

    Note: If the new capability is not available on your system, and
    you don't run systemd, you can still avoid the parallel start
    problem by configuring the same LOCKFILE in both your
    shorewall.conf and shorewall6.conf files.

7)  Previously, the RDP macro only allowed TCP traffic, even though RDP
    also requires UDP. That has been corrected so that both protocols
    are allowed.

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

1)  The SPARSE option in shorewallrc originally caused only
    shorewall[6].conf to be installed in /etc/shorewall[6], but later
    the conntrack and params files were also installed. To prevent
    these additional files from being installed, SPARSE may now be set
    to 'Very', either by editing the file directly or by using the
    configure or configure.pl scripts.

    This setting is recommended if you wish to use a single set of
    configuration files for both IPv4 and IPv6 as described at
    http://www.shorewall.org/SharedConfig.html.

2)  Two new run-time extensions scripts have been added:

    - enabled

      Invoked when an optional interface has been successfully enabled
      using the 'enable' command.

    - disabled

      Invoked when an optional interface has been successfully disabled
      using the 'disable' command.

    Like all run-time extension scripts, the contents of each script
    are placed in a function body. In the case of these new scripts,
    the function is passed arguments:

	$1 = the physical name of the interface
	$2 = the logical name of the interface
	$3 = the name of the Provider, if any, associated with the
	     interface.

3)  When a zone (z1) is defined to be a sub-zone of another zone (z2),
    the compiler now verifies that the two zones have at least one
    interface in common. If they do not, a warning message is
    generated:

       WARNING: Zone z1 is defined to be a sub-zone of z2, yet the two
                zones have no interface in common

4)  Runtime address variables may now be used as the server IP address
    and Runtime port variables may be used as the server port in DNAT
    rules.

    Example:

	DNAT	net	$FW:&eth1:%{PORT}	tcp	9999

5)  Previously, systemd could attempt to start the IPv4 and IPv6
    firewalls simultaneously, which might lead to iptables-restore and
    ip6tables-restore being run at the same time resulting in a failure
    to start one of the firewalls.

    Beginning with this release, Shorewall and Shorwall6 will be
    started serially as will Shorewall-lite and Shorewall6-lite.

6)  To prevent problems when other init systems start the IPv4 and IPv6
    firewalls in parallel, the ip[6]-tables '--wait' option, if
    available, is used. The amount of time to wait is determined by the
    setting of MUTEX_TIMEOUT (default 60 seconds). This change
    introduces a new RESTORE_WAIT_OPTION capability.
    
    Note: If the new capability is not available on your system, and
    you don't run systemd, you can still avoid the parallel start
    problem by configuring the same LOCKFILE in both your
    shorewall.conf and shorewall6.conf files.

7)  Previously, the sample configuration files specified
    MODULE_SUFFIX="ko ko.xz", whereas the default .conf files specified
    MODULE_SUFFIX=ko. The latter no longer works on RHEL7-based
    systems. Beginning with this release, the default .conf files also
    specify MODULE_SUFFIX="ko ko.xz".

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

5.1.5.2

1)  Previously, Specifying a USER in the OUTPUT section of the
    accounting file caused the compilter to incorrectly generate the
    following error message:

      ERROR: USER/GROUP may only be specified in the OUTPUT section

    That has been corrected, and no error message is generated in this
    case.

2)  When BASIC_FILTERS=Yes, the compiler previously generated an
    invalid tc command when when a source port was specified in a
    tcfilters entry. The compiler now generates correct input in this
    case.

3)  Previously, a MAC address could be specified in the OUTPUT
    section of the accounting file and no error would be generated at
    compile time. A failure would occur, however, at run-time. Now, an
    error is raised during compilation.

5.1.5.1

1)  To compensate for the presence of a masq file with no entries,
    the compiler will now attempt to process the snat file when such a
    masq file is found. Previously, if a masq file with no entries was
    found, the snat file, if any, was ignored.

2)  Previously, maintainers could not create reproducible packages
    because the 'configure' and 'configure.pl' scripts inserted the
    current date and time into the generated shorewallrc file.

    To support reproducible package builds, the scripts now recognize
    the SOURCE_DATE_EPOCH environmental variable (see
    https://reproducible-builds.org/specs/source-date-epoch/).

    The change to 'configure' was supplied by Bernhard M. Wiedemann.

5.1.5

1)  This release contains defect repair through Shorewall 5.1.4.4.

2)  Previously, when 0 was used as a port number or when a port number
    > 65535 was specified, an 'uninitialized variable' Perl exception
    occurred when the compiler attempted to issue an error
    message. That has been corrected.

3)  When running with Perl 5.26, messages such at the following could
    be issued:

      Unescaped left brace in regex is deprecated here (and will be
      fatal in Perl 5.30), passed through in regex; marked by <-- HERE
      in m/^(\s*|.*[^&@%]){ <-- HERE (.*)}\s*$/ at
      /usr/share/shorewall/Shorewall/Config.pm line 2343.

    That problem has been corrected.

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

1)  Run-time port variables are now supported. See
    http://www.shorewall.org/configuration_file_basics.htm#Port_Variables
    for details.

2)  The Shorewall and Shorewall6 manpages are now consolidated. Almost
    all of the Shorewall6 manpages are manpage aliases for the
    corresponding Shorewall manpages which describe the files for both
    products.

3)  There is now a FIN standard action which handles TCP packets with
    the FIN, ACK and PSH flags set.

4)  According to the Netfilter team (see
    https://patchwork.kernel.org/patch/9198133/), the --nflog-range option
    of the NFLOG target has never worked correctly, and they have
    deprecated that option in favor of the --nflog-size option. To
    accomodate this change, there is now an "--nflog-size support"
    (NFLOG_SIZE) Shorewall capability and a USE_NFLOG_SIZE option in
    shorewall[6].conf.

    For further information, see the Migrations Issues item number 8.

5)  The RESTORE_DEFAULT_ROUTE option has now been added to
    shorewall6.conf. Prior to this release, RESTORE_DEFAULT_ROUTE=Yes
    has always been assumed for Shorewall6 configurations. 

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

5.1.4.4

1)  A defect in 5.1.4.3 caused a startup failure when two or more
    'fallback' providers were configured. That has been corrected.

5.1.4.3

1)  When running on prior-generation distributions such as RHEL6,
    IPv6 multi-ISP configurations failed to start due to an error such as
    the following:

       ERROR: Command "ip -6 -6 route replace default scope global 
              table 250 nexthop via ::192.88.99.1 dev tun6to4 weight 1"
              Failed

    Such configurations now start successfully.

5.1.4.2

1)  Many broken links in the manpages have been corrected.

2)  Support for the NFQUEUE '--queue-cpu-fanout' option, introduced in
    Shorewall 5.1.0, contained a defect which could result in the
    following compile-time error:

      Use of uninitialized value $fanout in concatenation (.) or string
      at /usr/share/shorewall/Shorewall/Rules.pm line 643,
      <$currentfile> line 2.

    That has been corrected.

5.1.4.1

1)  The introductory material in shorewall-rules(5) has been cleaned
    up.

2)  The information about LOGFORMAT in shorewall[6].conf(5) and
    shorewall[6]-zones(5) has been expanded.

    In Shorewall 5.1.0, the setting of LOGFORMAT in the default and
    sample .conf files was changed to "%s:%s " to enable 10-character
    zone names (up from 5 characters using the default
    "Shorewall:%s:%s:" setting). As part of this change, if a
    shorewall.conf file which did not set LOGFORMAT is updated using
    "shorewall update", LOGFORMAT is set to "Shorewall:%s:%s:" to
    preserve the existing behavior.

    This can have an effect on new installations, however in that
    scipts or log analyzers can no longer be configured to simply look
    for "Shorewall:" in log messages unless the setting of LOGFORMAT is
    changed. The manpages (and the Migration Considerations below) have
    been updated to describe how to locate these messages using the new
    "%s:%s " setting.

3)  The BLACKLIST action was inadvertently omitted from Shorewall6 in
    Shorewall 5.1.1. That has been corrected.

5.1.4.1

1)  The introductory material in shorewall-rules(5) has been cleaned
    up.

2)  The information about LOGFORMAT in shorewall[6].conf(5) and
    shorewall[6]-zones(5) has been expanded.

    In Shorewall 5.1.0, the setting of LOGFORMAT in the default and
    sample .conf files was changed to "%s:%s " to enable 10-character
    zone names (up from 5 characters using the default
    "Shorewall:%s:%s:" setting). As part of this change, if a
    shorewall.conf file which did not set LOGFORMAT is updated using
    "shorewall update", LOGFORMAT is set to "Shorewall:%s:%s:" to
    preserve the existing behavior.

    This can have an effect on new installations, however in that
    scipts or log analyzers can no longer be configured to simply look
    for "Shorewall:" in log messages unless the setting of LOGFORMAT is
    changed. The manpages (and the Migration Considerations below) have
    been updated to describe how to locate these messages using the new
    "%s:%s " setting.

3)  The BLACKLIST action was inadvertently omitted from Shorewall6 in
    Shorewall 5.1.1. That has been corrected.

5.1.4

1)  This release contains defect repair through Shorewall 5.1.3.1.

2)  Previously, if a Shorewall Variable ( e.g., @chain ) was the target
    of a conditional ?RESET directive (one that was enclosed in ?if...
    ?else...?endif logic), the compiler could incorrectly use an
    existing chain created from the action rather than creating a new
    (and different) chain. That has been corrected.

3)  Previously, if alternate input format specified a column that had
    already been specified, the contents of that column were silently
    overwritten. Now, a warning message is issued stating that the
    prior value has been replaced by the newer value.

4)  Previously, a string-valued interface option, such as
    'physical', could be given an empty value (e.g., "physical=,"), and
    the compiler would fail to flag it. Now, this usage raises an
    error.

5)  Previously, the 'tunnel-src' and 'tunnel-dst' zone options would
    generate an error under Shorewall6. That has been corrected.

6)  A number of small documentation corrections have been made.

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

1)  All IPv6 standard actions have been deleted and their logic
    has been added to their IPv4 counterparts who can now handle
    both address families.

2)  Previously, ?error and ?require messages as well as verbose ?info
    and ?warning messages (those that report the file and line numbers)
    generated from an action file would report the action file name and
    line number rather than the file and line number where the action
    was invoked. The file and line number where the action was invoked
    were listed second. Beginning with this release, the invoking file
    and line number are listed first and the action file and line number
    are not reported. This allows for creation of clearer messages.

    Example:

    Previously, when an invalid value was passed for the 'bricks'
    parameter to the GlusterFS action on line 45 of the rules file, a
    message such as the following was issued (folded to 76 columns):

       ERROR: Invalid value for Bricks (2000)
          /usr/share/shorewall/action.GlusterFS (line 15)
             from /etc/shorewall/rules (line 45)

    Note that the message seems to imply that the error is in
    action.GlusterFS rather than in the rules file.

    Beginning with this release, the message will be:

       ERROR: Invalid value (2000) for the GlusterFS Bricks argument
          /etc/shorewall/rules (line 45)

    Note: This change only affects actions, including inline actions.
          Macros will continue to report the old way.

3)  IPv6 UPnP support (including MINIUPNPD) is now available.

4)  A PERL_HASH_SEED option has been added to allow the Perl hash seed
    to be specified.  See shorewall.conf(5) and perlsec(1) for details.

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

5.1.3.1

1)  There was a typo in the BLACKLIST_DEFAULT settings in the 5.1.3
    sample config files, which resulted in a compilation error.
    That typo has been corrected.

2)  There was also a typo in the two-interface IPv4 sample snat file;
    192.168.0.0/16 was inadvertently entered as 92.168.0.0/16. That has
    been corrected.

3)  Previously, when processing the policy file, 'all+' was incorrectly
    treated the same as 'all'. That has been corrected so that 'all+'
    causes intra-zone traffic to be included in the policy.

5.1.3

1)  This release includes defect repair for releases through 5.1.2.4.

2)  The documentation for 'reload' has been corrected:

    - A command synopsis has been added in shorewall(8).
    - The command synopsis in the 'help' output has been corrected.

3)  The CONFIG_PATH setting has been corrected in the IPv6 Universal
    sample configuration.

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

1)  The tarball installers and uninstallers have been unified and
    now use a common library that is included in each tarball (Matt
    Darfuille).

2)  The installers now print a diagnostic if the relevant shorewallrc
    file cannot be loaded (Matt Darfuille).

3)  The /etc/default/... files installed on Debian are now dependent on
    whether systemd is used or not (Matt Darfuille).

4)  In Perl 5.8.1 and again in 5.18.0, the Perl developers altered the
    behavior of the hash function used in the implementation of
    hashes. The hash key is now chosen randomly as a defense against
    DOS attacks targeting Perl programs. Such attacks supply input data
    that causes a single hash bucket to be used. While those changes
    improved security, they cause non-deterministic program behavior
    when the 'keys', 'values' and 'each' functions are used.

    Prior to this release, Shorewall sorted the lists produced by those
    functions to ensure that consecutive compilations of the same
    configuration produced the same ruleset. In this release,
    compilation speed has been improved by removing the sort calls and
    by instructing Perl to use a constant hash key.

    Note: The ruleset produced by this release will be equivalent
    to that produced by 5.1.2, but will likely be different.

5)  All builtin actions have been replaced with standard actions. In
    some cases. the standard action produces different but equivalent
    rules when compared to those produced by the corresponding builtin
    action.

6)  The PROTO columns may now specify tcp:!syn (6:!syn) which matches
    TCP packets with the SYN flag reset or one or more of ACK, RST or
    FIN set. The dropNotSyn and rejNotSyn actions have been modified to
    use this feature.

7)  During 'update', the settings of all _LEVEL and _DEFAULT options
    are now enclosed in quotes. This is done because these settings
    often contain parentheses and the .conf files are process by
    the shell. The sample configurations also have these settings
    enclosed in quotes.

    Update will continue to also enclose in quotes any settings that
    contains characters other than alphanumeric, '/', and '.'.

----------------------------------------------------------------------------
            P R O B L E M S  C O R R E C T E D  I N  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.

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

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

----------------------------------------------------------------------------
            P R O B L E M S  C O R R E C T E D  I N  5 . 1 . 1
----------------------------------------------------------------------------
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
