Problems corrected in Shorewall-perl 4.0.9
1) If a zone was defined with exclusion in /etc/shorewall/hosts, then
the rules generated for directing outgoing connections to the zone
were incorrect.
Example:
/etc/shorewall/zones:
z ipv4
/etc/shorewall/interfaces:
- eth2
/etc/shorewall/hosts:
z eth2:192.168.1.0/24!192.168.1.5
Traffic from the firewall to 192.168.1.5 was incorrectly classified
as $FW->z.
2) Qualifying ''SOURCE'' and ''DEST'' with an
IP address in a macro file
caused ''SOURCE'' or ''DEST'' to be
interpreted incorrectly as the name
of an interface.
Example:
PARAM DEST SOURCE:224.0.0.22
3) Specifying ''!<user>'' in the USER/GROUP column of the
files that
support it resulted in an invalid iptables rule under
Shorewall-perl.
4) Previously, Shorewall would accept both an interface and an IP
address in tcrules POSTROUTING entries (such as CLASSIFY).
Example:
1:11 eth1:192.168.4.9 - tcp 22
It also allowed both a destination interface and address.
Example:
1:P - eth1:192.168.4.9 tcp 22
Because Netfilter does not allow an input interface to be specified
in POSTROUTING or an output interface to be specified in
PREROUTING, Shorewall must use the routing table to generate a list
of networks accessed through any interface specified in these
cases. Given that a specific address (or set of addresses) has
already been specified, it makes no sense qualify it (them) by
another list of addresses.
5) Shorewall-perl incorrectly generated a fatal error when
'':C'',
'':T'' or '':CT'' was used in a tcrules
entry that gave $FW as the
SOURCE.
6) Users have been confused about this error message:
ERROR: Bridge Ports require Repeat match in your kernel and iptables
The message has been replaced with:
ERROR: Your iptables is not recent enough to support bridge ports
The minimum version required is 1.3.8.
Problems corrected in Shorewall-shell 4.0.8.
1) An optimization added to Shorewall-shell in 4.0.0 has been backed
out to work around a limitation of Busybox ''sed''.
2) Previously, specifying both an interface and an address in the
tcrules DEST column would cause an incomplete rule to be generated.
Example:
1 192.168.1.4 eth2:206.124.146.177 tcp 22
The resulting tcrule would be as if this had been specified:
1 0.0.0.0/0 eth2:206.124.146.177 tcp 22
3) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match
fwmarks to routing tables previously overflowed the designated
range defined for such marks (10000 - 11000).
Known Problems Remaining.
1) The ''refresh'' command doesn''t refresh the mangle
table. So changes
made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
not be reflected in the running ruleset.
Other changes in 4.0.9.
1) The Shorewall-perl now flags unprintable garbage characters in
configuration files with the message:
ERROR: Non-ASCII gunk in file
2) The /usr/share/shorewall/modules file has been updated to reflect
module renaming in kernel 2.6.25.
3) The ''ip route replace'' command is broken in kernel 2.6.24.
To work
around this problem, the undocumented option BROKEN_ROUTING has
been added to shorewall.conf. The default is BROKEN_ROUTING=No.
If you are experiencing ''File Exists'' errors from
''ip route
replace'' commands, then add the following line to your
shorewall.conf:
BROKEN_ROUTING=Yes
Note: This workaround is only available in Shorewall-perl.
--
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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/