From bba2e84ae9804135c2b3191d6332443d197b734c Mon Sep 17 00:00:00 2001
From: teastep
October 28, 2006
+
November 18, 2006
Problems Corrected in 3.2.6.2006-10-28 Shorewall 3.2.5
1) When using a light-weight shell (e.g., ash) with multiple
providers, the /etc/iproute2/rt_tables database may become corrupted.
2) A startup error occurred when the LENGTH or TOS column was
non-empty in /etc/shorewall/tcrules.
3) A startup error resulted when whitespace as included in LOGFORMAT.
4) Previously, when conntrack match support was not available, the
'norfc1918' option on an interface or host group was incorrectly
filtering IPSEC traffic whose source IP address was reserved by RFC
1918.
5) If a DNAT or REDIRECT rule was used where the effective policy
between the source and final destination zones is ACCEPT, the ACCEPT
part of the rule was not generated. This was intended as an
optimizaiton but it could lead to confusing results if there was a
DROP or REJECT rule following.
This optimization has been removed. You may always use DNAT- and
REDIRECT- to suppress generation of the ACCEPT rule.
6) Shorewall[-lite] previously would return an error exit status to a
"start" command where Shorewall was already running. It not returns
a "success" status.
7) The install.sh scripst have been corrected to work properly when
used to create packages on Slackware and Arch Linux.
5) A change in version 3.2.5 broke Mac Filtration in some
cases. Result was:
Setting up MAC Filtration -- Phase 1...
iptables v1.3.6: policy match: invalid policy `--dir'
Try `iptables -h' or 'iptables --help' for more information.
ERROR: Command "/sbin/iptables -A eth1_fwd -s 0.0.0.0/0 -m state
--state NEW -m policy --pol --dir in -j eth1_mac" Failed
6) At VERBOSITY 1 and higher, the 'shorewall add' and 'shorewall
delete' commands generated a fractured message. The message
contents depended in the setting of IPSECFILE as follows:
IPSECFILE=ipsec
ipsec...
IPSECFILE=zones
IPSEC...
The messages have been corrected and are only produced at VERBOSITY
2 and higher as follows:
IPSECFILE=ipsec
Processing /etc/shorewall/ipsec...
IPSECFILE=zones
Processing IPSEC...
7) Previously, when <action>:none appeared in a rule, the name of the
action chain created was preceded by "%" and might have a one- or
two-digit number appended. If both <action> and <action>:none
appeared, then two chains were created. This has been corrected
such that <action> and <action>:none are treated identically.
8) If SAVE_IPSETS=Yes in shorewall.conf, the "shorewall[-lite] save"
command produced error messages as follows:
Dynamic Rules Saved
Currently-running Configuration Saved to /var/lib/shorewall/restore
grep: /var/lib/shorewall/restore-base: No such file or directory
grep: /var/lib/shorewall/restore-base: No such file or directory
Current Ipset Contents Saved to
/var/lib/shorewall/restore-ipsets
9) If BRIDGING=No in shorewall.conf, then an attempt to define a zone
using ipsets fails as follows:
ERROR: BRIDGING=Yes is needed for this zone definition: z eth0:+iset
Other Changes in 3.2.6.
1) The "shorewall [re]load" command now supports a "-c" option.
Example:
shorewall reload -c gateway
When -c is given, Shorewall will capture the capabilities of the
remote system to a file named "capabilities" in the export
directory before compiling the configuration.
If the file "capabilities" does not currently exist in the
export directory then "-c" is automatically assumed.
2) If 0 (zero) is specified for the IN-BANDWIDTH in
/etc/shorewall/tcdevices then no ingress qdisc will be created for
the device.
Problems Corrected in 3.2.5diff --git a/web/images/leaflogo.jpg b/web/images/leaflogo.jpg new file mode 100644 index 0000000000000000000000000000000000000000..1238bbba30d9d533359b316923234bc3e568f5ea GIT binary patch literal 4559 zcmb7`S5%X0u!es^uhJ0+B@lWMLKOk&lF&m!2~BCzr3wg2?;S!@5Jdt+q<2(A1(7P! zAt1dfh@glRbJ*uB-52}n%y;?DJm1W$S+j;XO
1) Entries such as the following in /etc/shorewall/masq generate a
run-time error:
eth0 eth1!192.168.1.12 206.124.146.176
Omitting the exclusion (!192.168.1.12) avoids the error.
2) Previously, the 'provider' portion of the packet mark was not being
cleared after routing for traffic that originates on the firewall
itself.
3) In prior releases, it was not possible to mark an outgoing packet
with a high mark (HIGH_ROUTE_MARKS=Yes) when the packet originated
on the firewall itself.
4) The detected capabilities were not displayed by 'shorewall dump'
when the effective VERBOSITY was less than 2.
Other changes in 3.2.5
1) For users whose kernel and iptables have Extended MARK Target
support, it is now possible to logically AND or OR a value into the
current packet mark by preceding the mark value (and optional mask)
with an ampersand ("&") or vertical bar ("|") respectively.
Example: To logically OR the value 4 into the mark value for
packets from 192.168.1.1:
#MARK SOURCE
|4 192.168.1.1
2) A new macro (macro.RDP) has been added for Microsoft Remote
Desktop. This macro was contributed by Tuomo Soini.
3) A new 'maclog' extension file has been added. This file is
processed just before logging based on the setting of
MACLIST_LOG_LEVEL is done. When the script is copyied at compile
time, the CHAIN variable will contain the name of the chain where
rules should be inserted. Remember that if you have specified
MACLIST_TABLE=mangle, then your run_iptables commands should
include "-t mangle".
4) Beginning with this release, Shorewall and Shorewall lite will
share the same change log and release notes.
2006-10-30
+2006-11-18
Introduction
@@ -104,17 +104,17 @@ Features page.
The current
Stable Release version
-is 3.2.5
+is 3.2.6