I forgot to add the last new feature to the previous announcement.
Shorewall 2.2.2 is now available.
http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2
ftp://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2
Problems Corrected:
1. The SOURCE column in the /etc/shorewall/tcrules file now correctly
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 by Shorewall during [re]start, 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 during an upgrade.
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:
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.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key