Known problems in Shorewall 4.4.8

1)  Logical interface names in the EXTERNAL column of
    /etc/shorewall/proxyarp were previously not mapped to their
    corresponding physical interface names. This could cause 'start' or
    'restart' to fail.

    Corrected in Shorewall 4.4.8.1

2)  If find_first_interface_address() cannot determine the address of
    the passed interface, the following message is issued and the
    process continues:

    	    /usr/share/shorewall/lib.common: line 438:
                startup_error: command not found

    Corrected in Shorewall 4.4.8.1

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

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

    Corrected in Shorewall 4.4.8.1

4)  With optimize 4, if an unnecessary NONAT rule is included in
    /etc/shorewall/rules, 'shorewall start' and/or 'shorewall restart'
    can fail with invalid iptables-restore input.

    Corrected in Shorewall 4.4.8.2

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

    Corrected in Shorewall 4.4.8.2

6)  Wildcard interface names (those ending in '+') can result in
    iptables-restore failure with optimize 4.

    Corrected in Shorewall 4.4.8.3

7)  Invalid iptables-restore input involving the 'tcpre'
    mangle chain is possible with optimize 4.

    Corrected in Shorewall 4.4.8.3

8)  A couple of fixes to the 4.4.8.2 change for startup log naming are
    included. The main symptom occurred on Debian systems where perl
    reported that /etc/shorewall.conf did not exist.

    Corrected in Shorewall 4.4.8.3

9)  If OPTIMIZE 2 and there are no OUTPUT rules and the only effective
    output policy is $FW->all ACCEPT, then the OUTPUT chain is empty
    and no packets can be sent.

    Corrected in Shorewall 4.4.8.4