Bug#299747: New upstream version 2.2.2

[FX]

package: shorewall
New upstream version 2.2.2 is available.
Problems corrected in version 2.2.2
1) The SOURCE column in the /etc/shorewall/tcrules file now allows IP
  ranges (assuming that your iptables and kernel support ranges).
2) If A is a user-defined action and you have file /etc/shorewall/A
  then when that file is invoked, the $TAG value may be incorrect.
3) Previously, if an iptables command generating a logging rule
  failed, the Shorewall [re]start was still successful. This error
  is now considered fatal and Shorewall will be either restored from
  the last save (if any) or it will be stopped.
4) The port numbers for UDP and TCP were previously reversed in the
  /usr/share/shorewall/action.AllowPCA file.
5) Previously, the 'install.sh' script did not update the
  /usr/share/shorewall/action.* files.
6) Previously, when an interface name appeared in the DEST column of
  /etc/shorewall/tcrules, the name was not validated against the set
  of defined interfaces and bridge ports.
-----------------------------------------------------------------------
New Features in version 2.2.2
1) The SOURCE column in the /etc/shorewall/tcrules file now allows $FW
  to be optionally followed by ":" and a host/network address or
  address range.
2) Shorewall now clears the output device only if it is a
  terminal. This avoids ugly control sequences being placed in files
  when /sbin/shorewall output is redirected.
3) The output from 'arp -na' has been added to the 'shorewall status'
  display.
4) The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges
  to appear in port lists handled by "multiport match". If Shorewall
  detects this capability, it will use "multiport match" for port
  lists containing port ranges. Be cautioned that each port range
  counts for TWO ports and a port list handled with "multiport match"
  can still specify a maximum of 15 ports.
  As always, if a port list in /etc/shorewall/rules is incompatible
  with "multiport match", a separate iptables rule will be generated
  for each element in the list.
5) Traditionally, the RETURN target in the 'rfc1918' file has caused
  'norfc1918' processing to cease for a packet if the packet's source
  IP address matches the rule. Thus, if you have:
        SUBNETS                 TARGET
        192.168.1.0/24          RETURN
  then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even
  though you also have:
        SUBNETS                 TARGET
        10.0.0.0/8              logdrop
  Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic
  to be logged and dropped since while the packet's source matches the
  RETURN rule, the packet's destination matches the 'logdrop' rule.
 
  If not specified or specified as empty (e.g., RFC1918_STRICT="")
  then RFC1918_STRICT=No is assumed.

  WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
  support 'Connection Tracking' match.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]