From c66522e6722ab85b1d851782411c1b9291342c37 Mon Sep 17 00:00:00 2001 From: teastep Date: Fri, 29 Sep 2006 03:07:02 +0000 Subject: [PATCH] Belatedly update News for 3.0.8 -- Take 3 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4601 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- web/News.htm | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/web/News.htm b/web/News.htm index 3d21e49f7..2241eb884 100644 --- a/web/News.htm +++ b/web/News.htm @@ -34,10 +34,14 @@ Documentation License”.
Shorewall 3.2.3
Shorewall Problems Corrected in 3.2.3

1) A problem in 'install.sh' resulted in sandbox violations on
Gentoo and, when Shorewall is installed using an RPM, the problem
caused an incorrect copy of shorewall.conf to be installed in
/usr/share/shorewall/configfiles/.

2) A typo in the functions file caused startup errors when the user's
distribution did not support a true mktemp program (such as
Bering Uclibc). Patch courtesy of Cédric Schieli.

3) Several erroneous references to ip_addr_del() were made in
/var/lib/shorewall/compiler and in the code that it generates.

a) These should have been references to del_ip_addr()
b) One of the calls also had an incorrect parameter list.

4) Previously, "shorewall check -e" would erroneously attempt to
detect interfaces configured for traffic shaping.

5) SUBSYSLOCK functionality has been restored.

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

7) When /sbin/shorewall was run under BusyBox ash, shell errors would
occur if certain command options were given.

8) Previously, the 'optional' provider option did not detect the case
where the interface was DOWN but still had a configured IP
address. Shorewall was detecting such interfaces as UP and later
'ip replace route' commands would fail.

It should also be clarified that the 'optional' option is intended
to detect cases where a provider interface is in a state that would
cause 'shorewall [re]start' to fail; it is not intended to
determine whether communication is possible using the interface.

9) Previously, the "shorewall add" command would fail with error
messages indicating that the commands "chain_exists" and
"verify_hosts_file" could not be found.

10) Using earlier Shorewall versions, the following sequence of
commands produced inconsistant results:

a) shorewall [re] start
b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses
c) shorewall refresh
d) shorewall save
e) shorewall restore (or reboot and shorewall start -f during boot
up)

After that series of commands, the state of traffic shaping was as
it was after step a) rather than as it was after step c). The fix
involved re-implementing 'shorewall refresh' as a compile/execute
procedure similar to [re]start. While the entire configuration is
recompiled, only ecn, blacklisting, tcrules and traffic control
will be updated in the running configuration.

11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been
incorrect with the result that the rules didn't work at all.

Other Shorewall changes in 3.2.3

1) A 'shorewall export' command has been added.

shorewall export [ <directory1> ] [user@]<system>:[<directory2>]

If <directory1> is omitted, then the current working directory is
assumed.

Causes the shorewall configuration in <directory1> to be compiled
into a program called '<directory1>/firewall'. If compilation is
successful, the '<directory1>/firewall' script is copied via scp
to the specified <system>.

Example:

shorewall export admin@gateway:

This command would compile the configuration in the current working
directory then copy the 'firewall' (and 'firewall.conf') files to
admin's home directory on system 'gateway'.

2) 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=Yes in shorewall.conf and
Shorewall will not include these cautionary checks.

3) 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.

See the Migration Considerations section for further information.

4) Previously, if you specified 'detectnets' on an interface with a
default route, Shorewall would ignore the default route with a
warning message. This could lead to systems that were inaccessible
from the net, even from systems listed in the 'routestopped' file.

Specifying 'detectnets' on an interface with a default route now
generates a fatal error.

Shorewall Lite problems corrected in 3.2.3

1) A typo in /usr/share/shorewall-lite/functions caused startup errors
on distributions like Bering Uclibc that don't have a true mktemp
utility.

Other Shorewall Lite changes in 3.2.3

None.
-2006-08-10 Shorewall 3.2.2
-
Shorewall Problems Corrected in 3.2.2

1) Previously, the "shorewall stop" command would create empty files
named /nat and /proxyarp.

2) Scripts compiled for export did not support the 'reset' command. As
a result, on firewall systems running Shorewall Lite the command
"shorewall-lite reset" failed.

Other Shorewall changes in 3.2.2

1) The way in which options in /etc/shorewall-lite/shorewall.conf are
handled has been changed. Previously, problems would occur if
options were set differently in the shorewall.conf file located in
a firewall's export directory on the administrative system and in
/etc/shorewall-lite/shorewall.conf on the firewall system.

To eliminate those problems, both Shorewall and Shorewall Lite have
been modified. Now, settings in /etc/shorewall-lite/shorewall.conf
override settings from the export directory. Any variable not set
(or set to the empty value) in /etc/shorewall-lite/shorewall.conf
will get its value from the shorewall.conf file in the firewall's
export directory (see
http://www.shorewall.conf/CompiledPrograms.html for a description
of "export directories").

The "shorewall compile -e" and "shorewall [re]load" commands now
create two files -- the script file and an auxiliary configuration
file. The name of the auxiliary configuration file is formed by
appending ".conf" to the name of the firewall script. So, the
"[re]load" command now creates both 'firewall' and 'firewall.conf'
and the command copies both files to /var/lib/shorewall-lite/ on
the firewall system.

The shorewall.conf file released with Shorewall Lite now sets no
option values. So by default, the options that the firewall
system will use are determined entirely by the shorewall.conf file
in the export directory.

If you are upgrading from an earlier 3.2 release, I recommend that
you modify your /etc/shorewall-lite/shorewall.conf file(s) to set
all variables to the empty value (e.g., IPTABLES= ). This will
allow your Shorewall Lite installation(s) to conform to the new
option convention. Both the administrative system and the firewalls
must be running 3.2.2 or later and each firewall's configuration
must be recompiled and re-exported for changes to take effect.

2) The 'shorewall show capabilites' command now accepts a '-f' (file)
option (e.g., shorewall show -f capabilities). When '-f' is given,
the output is the same as the output from the 'shorecap' program
that is included in Shorewall Lite and can be used to generate a
capabilities file for use during compilation.

WARNING: The output is only meaningful when the command is run by
root.

3) The manner in which Shorewall determines the presence of the
'physdev match' capability has been modified to accomodate the
upcoming kernel change that will remove much of the functionality
of the match.

4) The install.sh script now supports a -n option:

./install.sh -n

When -n is given, no backup of the current configuration is
performed. This is used primarily by Shorewall developers as it
allows repeated installs of the same version without destroying
the backup of the prior version.

5) The "shorewall [re]load" command(s) now support a -s option:

Example:

shorewall reload -s gateway

The option causes the configuration on the firewall to be saved if
[re]start is successfull.

6) A new 'optional' option has been added to
/etc/shorewall/providers. If this option is specified, if the
interface specified in the INTERFACES column isn't up and
configured with an IPv4 address then a warning message is issued
and the provider is not configured.

Shorewall Lite Problems Corrected in 3.2.2

1) The comments at the front of /sbin/shorewall-lite previously
referred to the program as 'shorewall' rather than
'shorewall-lite'.

2) Vestiges of the 'check' command remained. Example:

gateway:~ # shorewall-lite check
/sbin/shorewall: line 1283: check_command: command not found
gateway:~ #

Other Shorewall Lite changes in 3.2.2

1) The way in which options in /etc/shorewall-lite/shorewall.conf are
handled has been changed. Previously, problems would occur if
options were set differently in the shorewall.conf file located in
a firewall's export directory on the administrative system and in
/etc/shorewall-lite/shorewall.conf on the firewall system.

To eliminate those problems, both Shorewall and Shorewall Lite have
been modified. Now, settings in /etc/shorewall-lite/shorewall.conf
override settings from the export directory. Any variable not set
(or set to the empty value) in /etc/shorewall-lite/shorewall.conf
will get its value from the shorewall.conf file in the firewall's
export directory (see
http://www.shorewall.conf/CompiledPrograms.html for a description
of "export directories").

The "shorewall compile -e" and "shorewall [re]load" commands now
create two files -- the script file and an auxiliary configuration
file. If the command is "shorewall compile -e <dir> foo" then the
firewall script will be named 'foo' and the auxiliary configuration
file will be named 'foo.conf'. The "[re]load" command now created
both 'firewall' and 'firewall.conf' and copies both files to
/var/lib/shorewall-lite/ on the firewall system.

The shorewall.conf file released with Shorewall Lite now sets no
option values. So by default, the options that the firewall
system will use are determined entirely by the shorewall.conf file
in the export directory.

If you are upgrading from an earlier 3.2 release, I recommend that
you modify your /etc/shorewall-lite/shorewall.conf file(s) to set
all variables to the empty value (e.g., IPTABLES= ). This will
allow your Shorewall Lite installation(s) to conform to the new
default.

2) The 'shorewall-lite show capabilites' command now accepts a '-f'
option (e.g., shorewall-lite show -f capabilities). When '-f' is
given, the output is the same as the output from the 'shorecap'
program.

WARNING: The output is only meaningful when the command is run by
root.

3) The manner in which Shorewall lite determines the presence of the
'physdev match' capability has been modified to accomodate the
upcoming kernel change that will remove much of the functionality
of the match.

4) The install.sh script now supports a -n option:

./install.sh -n

When -n is given, no backup of the current configuration is
performed. This is used primarily by Shorewall developers as it
allows repeated installs of the same version without destroying
the backup of the prior version.
-2006-07-24 End of support for +
2006-08-10 +Shorewall 3.2.2
+ +
Problems corrected in 3.0.8

1) If the 'upnp' interface option was specified on one or more
interfaces but no forwardUPnP rule was included, the following
diagnostic messages were issued:

WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on
eth0)
ERROR: Fatal error in find_logactionchain

Given that the fatal error message is obscure if the first WARNING
isn't noticed, the ERROR message has been eliminated with the
result that Shorewall now starts but won't handle UPnP properly.

2) If BRIDGING=No in shorewall.conf, then an entry in
/etc/shorewall/hosts such as the following would result in an
obscure failure of an iptables command:

loc br0:eth0

Shorewall now detects this case and issues a more helpful error
message:

ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0

3) Users of the Multi-ISP feature may experience this error during startup:

/usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +
$rulenum : syntax error: operand expected (error token is
"$rulenum ")

4) A more useful diagnostic is now given when a command fails during
setup of traffic shaping.

5) Shorewall now checks to see if devices in /etc/shorewall/tcdevices
exist. If a device does not exist, a warning message is issued and
that device's entries in /etc/shorewall/tcclasses are ignored. This
applies to "shorewall start", "shorewall restart" and "shorewall
refresh".

6) It is now possible to exclude a single source MAC address using
!<MAC address>. Previously, a startup error occurred.

7) Shorewall would use the incorrect shell for compilation in the
following case:

8) Reporting of the "Mangle FORWARD Chain" capability was broken. While
Shorewall correctly detected and used the capability, the output of
"shorewall show capabilities" and "shorewall dump" showed the
capability as "Not Available".

9) Extension scripts for policy chains (chains with the word 'all' in
their name) were not being run previously.

-Tom
+ +
2006-07-24 +End of support for Shorewall 2.4
Support for Shorewall 2.4 has ended. As always, we will try to help you
with your problems but I personally will not spend any time reading old
code trying to solve your problem and I will not provide patches for any
bugs found in versions earlier than 3.0.