releasenotes.txt

sharewall is very good

    <interface>_in and <interface>_fwd chains and moved their rules
    to the appropriate rules chain (a <zone>2<xxx> chain).

    This worked badly in cases where a zone was associated with more
    than one interface. Rules could be duplicated or, worse, a rule
    that was intended for only input from one of the interfaces would
    be applied to input from all of the zone's interfaces.
    
    This problem has been corrected so that an interface-related
    chains is only deleted if:

    a) the chain has no rules in it; or
    b) the interface is associated with only one zone and that zone is
       associated with only that interface in which case it is safe to
       move the rules.

Other changes in Shorewall 4.2.3

1)  Except with the -e option is specified, the Shorewall-perl compiler
    now verifies user/group names appearing in the USER/GROUP column of
    the rules file.

2)  The output of 'shorewall dump' now includes the output from
    'netstat -tunap'.

3)  Shorewall-perl now accepts '+' as an interface name in
    /etc/shorewall/interfaces. That name matches any interface and is
    useful for defining a zone that will match any interface that might
    be added after Shorewall is started.

    A couple of words of caution are in order. 

    a) Because '+' matches any interface name, Shorewall cannot
       verify interface names appearing in other files when '+' is
       defined in /etc/shorewall/interfaces.

    b) The zone assigned to '+' must be the last one defined in
       /etc/shorewall/zones.

4)  Shorewall-perl now uses the iptables --goto parameter in obvious
    cases.

5)  The 'reset' command now allows you to reset the packet and byte
    counter on individual chains:

    	    shorewall reset chain1 chain2 ...
	    shorewall-lite reset chain1 chain2 ...

Problems Corrected in 4.2.4

1)  Previously, when exclusion was used in an entry in
    /etc/shorewall/hosts, Shorewall-perl ignored the exclusion when
    generating rules for the following OPTIONS in that entry:
 
        blacklist
	maclist
	norfc1918
	tcpflags

2)  Shorewall-perl previously promoted all exclusion in the
    /etc/shorewall/hosts file to the zone level. That meant that
    all traffic to/from the zone passed through exclusion rules 
    rather than only the traffic matching a hosts records that
    specified exclusion.

    Example /etc/shorewall/hosts:

    	    z	eth0:192.168.4.0/24
	    z	eth1:10.0.0.0/24!10.0.0.99

        Traffic entering eth0 from network 192.168.4.0/24 would still
        be checked for '!10.0.0.99'.

    This has been corrected.

Other changes in 4.2.4

1)  Support for IPv6 was added -- see above.

Problems corrected in 4.2.5

1)  If exclusion is used to define a zone in /etc/shorewall/hosts and
    that zone is used as the SOURCE zone in a DNAT or REDIRECT rule,
    then Shorewall-perl can generate invalid iptables-restore input.

2)  A bug in the Perl Cwd module (see
    http://rt.cpan.org/Public/Bug/Display.html?id=13851) causes the
    Shorewall-perl compiler to fail if it doesn't have at least read
    access to its current working directory. 4.2.5 contains a
    workaround.

3)  If 'critical' was specified on an entry in
    /etc/shorewall6/routestopped, Shorewall6 (Shorewall-perl) would
    generate an error. 

4)  In certain cases where exclusion occurred in /etc/shorewall/hosts,
    Shorewall-perl would generate incorrect iptables-restore input.

5)  In certain cases where exclusion occurred in /etc/shorewall/hosts,
    Shorewall-perl would generate invalid iptables-restore input.

6)  The 'shorewall6 refresh' command runs iptables_restore rather than
    ip6tables_restore.

7)  The commands 'shorewall6 save-start', 'shorewall6-save-restart' and
    'shorewall6 restore' were previously broken.

8)  The Debian init script was checking $startup in
    /etc/default/shorewall rather than in /etc/default/shorweall6

9)  The Archlinux init scripts for Shorewall6 and Shorewall6 Lite were
    unconverted Shorewall scripts.

10) When 'detect' is used in the GATEWAY column of
    /etc/shorewall/providers, Shorewall-perl now ensures that the
    gateway was successfully detected. If the gateway cannot be
    detected, action is taken depending on whether the provider is
    'optional' or not. If the provider is optional, it's configuration
    is skipped; if the provider is not optional, the current operation
    is aborted.

11) The command 'shorewall6 debug start' would previously fail with

    	ERROR: Command "/sbin/ip6tables -t nat -F" Failed

12) Both ipv4 and ipv6 compiled programs attempt to run the tcclear 
    script itself at run time rather than running the copy of the
    file in the compiled script. This usually isn't noticable unless
    you are running Shorewall Lite or Shorewall6 Lite in which case,
    the script doesn't get run (since it is on the administrative
    system and not the firewall system).

13) If your iptables/kernel included "Extended Connection Tracking
    Match support" (see the output of "shorewall show capabilities"),
    then a REDIRECT rule that specified a port list or range would
    cause Shorewall-perl to create invalid iptables-restore input:

    Running /usr/sbin/iptables-restore...
    iptables-restore v1.4.2-rc1: conntrack: Bad value for
       "--ctorigdstport" option: "1025:65535"
       Error occurred at line: 191
       Try `iptables-restore -h' or 'iptables-restore --help' for more information.
      ERROR: iptables-restore Failed. Input is in
         /var/lib/shorewall/.iptables-restore-input

New Feature in Shorewall 4.2.5

1)  A new 'fallback' option is added in
    /etc/shorewall/providers. The option works similar to 'balance'
    except that the default route is added in the default routing table
    (253) rather than in the main table (254).

    The option can be used by itself or followed by =<number> (e.g,
    fallback=2).

    When the option is used by itself, a separate (not balanced)
    default route is added with a metric equal to the provider's NUMBER.

    When the option is used with a number, a balanced route is added
    with the weight set to the specified number.

    'fallback' is ignored if USE_DEFAULT_RT=Yes in shorewall.conf and
    is only available with Shorewall-perl.

    'fallback' is useful in situations where:

    - You want all traffic to be sent via one primary provider unless
      there is a compelling reason to use a different provider

    - If the primary provider is down, then you want to balance the
      outgoing traffic among a set of other providers or to a
      ordered list of providers.

    In this case:

    - Do not specify 'balance' on any of the providers.
    - Disable route filtering ('ROUTE_FILTER=No' in shorewall.conf).
    - Specify 'fallback' on those providers that you want to use if 
      the primary is down.
    - Only the primary provider should have a default route in the main
      routing table.

    See http://www.shorewall.net/MultiISP.html#Complete for an example
    of this option's use.

2)  Shorewall-perl now transparently handles the xtables-addon version
    of ipp2p. Shorewall detects whether the installed ipp2p is from
    patch-o-matic-ng or from xtables-addon and proceeds accordingly.

    If the patch-o-matic-ng version is installed:

    a) If no DEST PORT is supplied, the default is "--ipp2p".
    b) If "ipp2p" is supplied as the DEST PORT, it will be passed to
       iptables-restore as "--ipp2p".

    If the xtables-addons version is installed:

    a) If no DEST PORT is supplied, the default is "--edk --gnu --dc
       --kazaa".
    b) If "ipp2p" is supplied as the DEST PORT, it will be passed to
       iptables-restore as "--edk --gnu --dc --kazaa". 

    Shorewall-perl now also accepts a comma-separated list of options
    (e.g., "edk,gnu,dc,kazaa).

    Additionally, Shorewall now looks for modules in /lib/modules/$(uname
    -r)/extra and in /lib/modules/$(uname -r)/extra/ipset

    This change introduced a new capability ("Old IPP2P Match Syntax")
    so if you use a capabilities file, be sure to re-generate the
    file(s) after you have installed 4.2.5.

3)  There is now a macro.Git, which opens git-daemon's port (9418/tcp).

4)  There is also a macro.IRC which open's the Internet Relay Chat port
    (6667/tcp).

Problems corrected in 4.2.6

1)  The CONFIG_PATH in the two- and three-interface Shorewall6 sample
    configurations was incorrect with the result that this error
    occurred on 'shorewall6 check' or 'shorewall6 start'.

   	   ERROR: No IP zones defined

2)  Setting TCP_FLAGS_DISPOSITION=REJECT caused both Shorewall-shell
    and Shorewall-perl to create invalid iptables commands. This has
    been corrected but we still strongly recommend against that
    setting; TCP_FLAGS_DISPOSITION=DROP is preferred.

3)  Shorewall-perl was generating code that checked for state match
    before kernel modules were loaded. This caused start/restart to
    fail on systems without kernel module loading. 

4)  The Shorewall6 and Shorewall6-lite Makefiles were incorrect.

5)  If a service name is used in a port-mapping rule (a DNAT or
    REDIRECT rule that changes the destination port), and if the
    kernel and iptables include Extended Connection Match support, then
    invalid iptables-restore input is produced by Shorewall-perl.

6)  If iptables 1.4.1 or later was installed, Shorewall-perl generated
    incorrect iptables-restore input if exclusion was used in the
    ORIGINAL DEST field of a DNAT or REDIRECT rule.

7)  On kernels earlier than 2.6.20, the 'shorewall show connections'
    command fails.

New Features in Shorewall 4.2.6

1)  A BitTorrent32 macro has been added. This macro matches the
    extended TCP port range used by BitTorrent 3.2 and later.

2)  A new COUNT action has been added to Shorewall-perl. This action
    creates an iptables (ip6tables) rule with no target. Connections
    matching such a rule are simply counted and the packet is passed on
    to the next rule.

    Shorewall-shell ignores COUNT in actions and macros, thus allowing
    the standard actions (action.Drop and action.Reject) to have a
    COUNT rule as their first entry.

3)  A new RESTORE_DEFAULT_ROUTE option has been added to
    shorewall.conf. It is used to determine whether to restore the
    default route saved when there are 'balance' providers defined but
    all of them are down.

    The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
    pre-4.2.6 behavior. 

    RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
    default route in the main table (USE_DEFAULT_RT=No) or in the
    default table (USE_DEFAULT_RT=Yes) when there are no balance
    providers available. In that case, RESTORE_DEFAULT_ROUTE=No
    will cause any default route in the relevant table to be deleted.

4)  IPv4 firewall scripts produced by Shorewall-perl now use dhcpcd's
    database when trying to detect the gateway for an interface
    ("detect" in the GATEAWAY column in /etc/shorewall/interfaces).

    As part of this change, it is now permitted to specify 'detect'
    when USE_DEFAULT_RT=Yes; in that case, the script will only detect
    gateways for point-to-point devices and for devices configured by
    dhcpcd.

5)  Shorewall-perl now supports port inversion. A port number or list
    of port numbers may be preceded by '!" which will cause the rule to
    match all ports EXCEPT those listed:

    Example: To blacklist 206.124.146.176 for all tcp ports except 80:

    	     ADDRESS/SUBNET	  PROTO		  PORT(S)
   	     206.124.146.177	  tcp		  !80

6)  Shorewall-perl now supports protocol inversion. A protocol name or
    number may be preceded by '!' to specify all protocols except the
    one following '!'.

    Example: To blacklist 206.124.146.176 for all protocols except 
             UDP:

    	     ADDRESS/SUBNET	  PROTO		  PORT(S)
   	     206.124.146.177	  !udp

    Note that ports may not be specified when protocol inversion
    is used.

7)  When using Shorewall-perl, neither the 'start' nor 'started'
    extension script is run during processing of the 'restore'
    command. To allow extension of that command, we have added a
    'restored' extension script that runs at the successful completion
    of 'restore'. This script is only available with Shorewall-perl.

    With Shorewall-shell, both scripts are run during 'restore' but in
    that case, the run_iptables() function does nothing. So any
    run_iptables() calls in the 'start' script are effectively ignored.

8)  Shorewall-perl now correctly handles 'here documents' quoting
    (<<EOF .... EOF) in run-time extension scripts.