[Shorewall-announce] Shorewall 3.0.9

[Tom E. <te...@sh...>]

This is largely a bug-fix roll-up but there are some new features as well=
=2E

Problems corrected in 3.0.9

1)  When using a light-weight shell like ash or dash, "shorewall
    [re]start" fails when using the built-in traffic shaper. The error
    messages resemble these:

    local: 3: eth0:: bad variable name
    ERROR: Command "tc class add dev eth0 parent 1: classid 1:1 htb rate =
800kbit
mtu" Failed

2)  The output formating of the 'hits' command under BusyBox 1.2.0 has
    been corrected.

3)  In prior versions, setting 'mss=3D' in /etc/shorewall/zones did not
    affect traffic to/from the firewall zone. That has been corrected.

4)  Previously, using IP address ranges in the accounting file could
    cause non-fatal iptables errors during shorewall [re]start.

Other changes in 3.0.9

1)  It is now possible to use the special value 'detect' in the ADDRESS
    column of /etc/shorewall/masq. This allows you to specify SNAT (as
    opposed to MASQUERADE) without having to know the ip address of the
    external interface. Shorewall must be restarted each time that the
    external address (the address of the interface named in the
    INTERFACE column) changes.

2)  Experimental optimization for PPP devices has been added to the
    providers file. If you omit the GATEWAY column for a ppp device (or
    enter "-" in the column) then Shorewall will generate routes
    for the named INTERFACE that do not specify a gateway IP address
    (the peer address will be assumed).

3)  Normally, Shorewall tries to protect users from themselves by
    preventing PREROUTING and OUTPUT tcrules from being applied to
    packets that have been marked by the 'track' option in
    /etc/shorewall/providers.

    If you really know what you are doing and understand packet marking
    thoroughly, you can set TC_EXPERT=3DYes in shorewall.conf and
    Shorewall will not include these cautionary checks.

4)  Previously, CLASSIFY tcrules were always processed out of the
    POSTROUTING chain. Beginning with this release, they are processed
    out of the POSTROUTING chain *except* when the SOURCE is
    $FW[:<address>] in which case the rule is processed out of the
    OUTPUT chain.

--=20
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ te...@sh...
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key