diff --git a/Shorewall-common/changelog.txt b/Shorewall-common/changelog.txt
index 3bbd1ba3e..23d853ca0 100644
--- a/Shorewall-common/changelog.txt
+++ b/Shorewall-common/changelog.txt
@@ -1,3 +1,8 @@
+Changes in 4.1.4
+
+1) Fix do_test() to accept 0 and to use the same mask as
+ Shorewall-shell
+
Changes in 4.1.3
1) Fix NFLOG/ULOG upcasing problem.
diff --git a/Shorewall-common/releasenotes.txt b/Shorewall-common/releasenotes.txt
index 6f85a7725..a19303e72 100644
--- a/Shorewall-common/releasenotes.txt
+++ b/Shorewall-common/releasenotes.txt
@@ -1,4 +1,4 @@
-Shorewall 4.1 Patch Release 3.
+Shorewall 4.1 Patch Release 4.
----------------------------------------------------------------------------
R E L E A S E 4 . 1 H I G H L I G H T S
@@ -8,58 +8,21 @@ Shorewall 4.1 Patch Release 3.
2) Support for NFLOG has been added.
-3) Enhanced operational logging
+3) Enhanced operational logging.
-Problems corrected in Shorewall 4.1.3.
+4) The tarball installers now work under Cygwin.
-1) If NFLOG or ULOG was specified with parameters, the resulting
- iptables-restore input contained elements that were incorrectly
- up-cased.
+Problems corrected in Shorewall 4.1.4.
-2) If STARTUP_LOG is specified without LOG_VERBOSITY, /sbin/shorewall
- produces an error.
+1) Previously, a value of 0 was ignored in the TEST column of tcrules
+ and the MARK column of the rules files.
-3) If LOG_VERBOSITY is specified without STARTUP_LOG, run-time error
- messages are produced.
-
-4) Shorewall-shell was mishandling the entries in /etc/shorewall/rules
- and in /etc/shorewall/tcrules where both a SOURCE interface and MAC
- address were specified.
-
- Example:
-
- ACCEPT net:eth0:~01-02-03-04-05-06 $FW tcp 22
+ Also, the default mask for entries in these columns has been
+ changed from 0xFF to 0xFFFF for compatibility with Shorewall-shell.
Other changes in Shorewall 4.1.3.
-1) If the program named in SHOREWALL_SHELL doesn't exist or is not
- executable, Shorewall and Shorewall-lite now both fall back to
- /bin/sh after issuing a warning message. Previously, both
- terminated with a fatal error.
-
-2) The error message has been improved when a non-root user attempts
- "shorewall show capabilities".
-
-3) Shorewall-perl now generates fatal error conditions when there are
- no IPv4 zones defined and when there are no interfaces defined.
-
-4) Shorewall now unconditionally uses tc filter rules to classify
- traffic by MARK value. Previously, Shorewall used the CLASSIFY
- target in the POSTROUTING chain if it was available.
-
-5) The Shorewall-common installer (install.sh) now works on Windows
- under Cygwin.
-
- To install Shorewall-perl under Cygwin:
-
- $ tar -xf shorewall-perl-4.1.3.tar.bz2
- $ tar -xf shorewall-common-4.1.3.tar.bz2
- $ cd shorewall-perl-4.1.3
- $ ./install.sh
- $ cd ../shorewall-common-4.1.3
- $ USER=
+Tom EastepShorewall News and Announcements
+Shorewall News and Announcements
-Tom Eastep
+
-Copyright © 2001-2007 Thomas M. Eastep
+
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or any
later version published by the Free Software Foundation; with no Invariant
Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the
-license is included in the section entitled “GNU Free Documentation
-License”.
+license is included in the section entitled GNU Free Documentation
+License.
November 23, 2007
-December 26, 2007
+2007-12-26 Shorewall 4.0.7
+ +Problems corrected in Shorewall-perl 4.0.7+ +
1) If any of the following files was missing, a harmless Perl warning+ +
was issued:
accounting+ +
maclist
masq
nat
netmap
rfc1918
routestopped
tunnels
This problem was experienced mostly by Debian users and users of+ +
Debian derivatives such as Ubuntu.
2) The iptables utility doesn't retry operations that fail due to+ +
resource shortage. Beginning with this release, Shorewall reruns
iptables when such a failure occurs.
3) Previously, Shorewall-perl did not accept log levels in upper case+ +
(e.g., INFO). Beginning with 4.0.7, log levels are treated in a
case-insensitive manner by Shorewall-perl.
4) The column headers in macro files were not aligned. This has been+ +
corrected, along with some inaccuracies in the macro.template file.
5) The shorewall.conf files in the Samples did not contain some+ +
recently-defined options. They are now up to date.
6) The names of the Jabber macros were shuffled. They are now named+ +
correctly.
7) If ADD_IP_ALIASES=Yes, an alias was incorrectly added when the+ +
specified INTERFACE ended with ":" (e.g., eth0:).
8) Shorewall-shell generated an incorrect iptables rule from the+ +
following:
/etc/shorewall/rules:+ +
ACCEPT loc:eth0:~00-02-02-02-02-02 ...+ +
/etc/shorewall/tcrules:+ +
xxxx eth0:~00-02-02-02-02-02 ...+ +
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.7+ +
1) If the program named in SHOREWALL_SHELL doesn't exist or is not+ +
executable, Shorewall and Shorewall-lite now both fall back to
/bin/sh after issuing a warning message. Previously, both
terminated with a fatal error.
2) The error message has been improved when a non-root user attempts+ +
"shorewall show capabilities".
3) Shorewall-perl now generates fatal error conditions when there are+ +
no IPv4 zones defined and when there are no interfaces defined.
2007-12-26 Shorewall 4.1.3
+ +Problems corrected in Shorewall 4.1.3.+ +
1) If NFLOG or ULOG was specified with parameters, the resulting+ +
iptables-restore input contained elements that were incorrectly
up-cased.
2) If STARTUP_LOG is specified without LOG_VERBOSITY, /sbin/shorewall+ +
produces an error.
3) If LOG_VERBOSITY is specified without STARTUP_LOG, run-time error+ +
messages are produced.
4) Shorewall-shell was mishandling the entries in /etc/shorewall/rules+ +
and in /etc/shorewall/tcrules where both a SOURCE interface and MAC
address were specified.
Example:+ +
ACCEPT net:eth0:~01-02-03-04-05-06 $FW tcp 22+ +
Other changes in Shorewall 4.1.3.+ +
1) If the program named in SHOREWALL_SHELL doesn't exist or is not+ +
executable, Shorewall and Shorewall-lite now both fall back to
/bin/sh after issuing a warning message. Previously, both
terminated with a fatal error.
2) The error message has been improved when a non-root user attempts+ +
"shorewall show capabilities".
3) Shorewall-perl now generates fatal error conditions when there are+ +
no IPv4 zones defined and when there are no interfaces defined.
4) Shorewall now unconditionally uses tc filter rules to classify+ +
traffic by MARK value. Previously, Shorewall used the CLASSIFY
target in the POSTROUTING chain if it was available.
5) The Shorewall-common installer (install.sh) now works on Windows+ +
under Cygwin.
To install Shorewall-perl under Cygwin:+ +
$ tar -xf shorewall-perl-4.1.3.tar.bz2
$ tar -xf shorewall-common-4.1.3.tar.bz2
$ cd shorewall-perl-4.1.3
$ ./install.sh
$ cd ../shorewall-common-4.1.3
$ USER=<your user id> GROUP=None ./install.sh
The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).
2007-11-23 Shorewall 4.0.6
Problems corrected in Shorewall-perl 4.0.6. @@ -620,8 +699,8 @@ Other Changes in Shorewall 4.0.4 WARNING: Support for the 'detectnets' option has been removed
2007-09-01 Shorewall 4.0.3
-Problems Corrected in 4.0.3 +2007-09-01 Shorewall +4.0.3
Problems Corrected in 4.0.3 1) Using the LOG target in the rules file could result in two LOG rules being generated by Shorewall-shell. Additionally, using an IP @@ -829,8 +908,8 @@ Other Changes in 4.0.3 Shorewall-common 4.0.3.
-2007-08-19 Shorewall 3.4.6
-Problems Corrected in 3.4.6. +2007-08-19 Shorewall +3.4.6
Problems Corrected in 3.4.6. 1) If the "Mangle FORWARD Chain" capability was supported, entries in the /etc/shorewall/ecn file would cause invalid iptables @@ -891,8 +970,8 @@ Other changes in 3.4.6. Andrew Suffield.
-2007-08-10 Shorewall 4.0.2
-Problems corrected in 4.0.2 +2007-08-10 Shorewall +4.0.2
Problems corrected in 4.0.2 1) The Shorewall-perl compiler was still generating invalid iptables-restore input from entries in /etc/shorewall/ecn. @@ -981,8 +1060,8 @@ Other changes in 4.0.2 not available.
-2007-07-30 Shorewall 4.0.1
-Problems corrected in 4.0.1. +2007-07-30 Shorewall +4.0.1
Problems corrected in 4.0.1. 1) The Shorewall Lite installer was producing an empty shorewall-lite manpage. Since the installer runs as part of creating the RPM, the @@ -1082,10 +1161,10 @@ Other changes in Shorewall 4.0.1. diagnose when using Shorewall-perl so the generated shell program now checks specifically for this problem and terminates with an error if the capability doesn't exist.-
+
-2007-07-20 Shorewall 4.0.0
----------------------------------------------------------------------------- +2007-07-20 Shorewall +4.0.0
---------------------------------------------------------------------------- R E L E A S E H I G H L I G H T S ---------------------------------------------------------------------------- 1) This is the first Shorewall release that fully integrates the new @@ -2014,8 +2093,8 @@ Migration Considerations: 4.0.0-RC2 or later.
-2007-07-15 Shorewall 3.4.5
-Problems Corrected in 3.4.5. +2007-07-15 Shorewall +3.4.5
Problems Corrected in 3.4.5. 1) DYNAMIC_ZONES=Yes can now coexist with Shorewall-perl's 'bport' zones. Those zones themselves may not be dynamically modified but @@ -2085,8 +2164,8 @@ Other changes in 3.4.5. PATH setting.
-2007-06-17 Shorewall 3.4.4
-Problems corrected in 3.4.4: +2007-06-17 Shorewall +3.4.4
Problems corrected in 3.4.4: 1) The commands "shorewall add <interface> <zone>" and "shorewall delete <interface> <zone>" no longer produce spurious error @@ -2226,9 +2305,8 @@ Other changes in 3.4.4: shorewall try -C perl .
-2007-06-12 New Host for www.shorewall.net and -ftp.shorewall.net
-I'm pleased to announce that Ty Christiansen and the folks at Master Mind +2007-06-12 New Host for +www.shorewall.net and ftp.shorewall.net
I'm pleased to announce that Ty Christiansen and the folks at Master Mind Productions (http://mastermindpro.com) have volunteered to host www.shorewall.net and ftp.shorewall.net. @@ -2239,78 +2317,34 @@ Please join me in thanking Ty and Master Mind for their support of the Shorewall project.
-2007-04-30 Shorewall 3.4.3
- --
Problems corrected in Shorewall 3.4.3
-1) The shorecap program was not loading modules correctly.
-2) The CHAIN variable is now set correctly before the 'maclog' script
-is invoked.
--3) The 'shorewall load' and 'shorewall reload' commands redundently
-re-generated the capabilities file when it resided in the export
-directory.
--4) Setting LOGFILE to the value of a shell variable from the params
-file now works.
--5) The 'shorewall-lite restore' command can fail with a 'startup not
-enabled' error.
--6) When ROUTE_FILTER=Yes in shorewall.conf, Shorewall no longer clears
-the rp_filter flag for all interfaces.
--7) When LOG_MARTIANS=Yes in shorewall.conf, Shorewall no longer clears
-the log_martians flag for all interfaces.
--8) The 'shorewall add' and 'shorewall delete' commands no longer fail
-with the message 'ERROR: Only one firewall zone may be defined'.
--9) It was previously impossible to disable martian logging.
--10) IP addresses (aliases) added by ADD_IP_ALIASES and ADD_SNAT_ALIASES
-are now correctly deleted when Shorewall stops.
--11) The 'shorewall add' and 'shorewall delete' commands no longer fail
-with the error 'Only one firewall zone may be defined'.
--12) The special 'detect' value now works correctly in the ADDRESSES
-column of /etc/shorewall/masq.
--Other changes in Shorewall 3.4.3
--1) A LOCKFILE option has been added to shorewall.conf. This file is
-used to serialize updates to the active firewall configuration.
- +If not specified, the defaults are:
2007-04-30 Shorewall +3.4.3
+
Problems corrected in +Shorewall 3.4.3
1) The shorecap program was not loading modules correctly.
2) The CHAIN variable is now set correctly before the 'maclog' script
is invoked.
3) The 'shorewall load' and 'shorewall reload' commands redundently
re-generated the capabilities file when it resided in the export
directory.
4) Setting LOGFILE to the value of a shell variable from the params
file now works.
5) The 'shorewall-lite restore' command can fail with a 'startup not
enabled' error.
6) When ROUTE_FILTER=Yes in shorewall.conf, Shorewall no longer clears
the rp_filter flag for all interfaces.
7) When LOG_MARTIANS=Yes in shorewall.conf, Shorewall no longer clears
the log_martians flag for all interfaces.
8) The 'shorewall add' and 'shorewall delete' commands no longer fail
with the message 'ERROR: Only one firewall zone may be defined'.
9) It was previously impossible to disable martian logging.
10) IP addresses (aliases) added by ADD_IP_ALIASES and ADD_SNAT_ALIASES
are now correctly deleted when Shorewall stops.
11) The 'shorewall add' and 'shorewall delete' commands no longer fail
with the error 'Only one firewall zone may be defined'.
12) The special 'detect' value now works correctly in the ADDRESSES
column of /etc/shorewall/masq.
Other changes in Shorewall 3.4.3
1) A LOCKFILE option has been added to shorewall.conf. This file is
used to serialize updates to the active firewall configuration.
If not specified, the defaults are:
-- +- -
Shorewall - /var/lib/shorewall/lock
-
Shorewall Lite - /var/lib/shorewall-lite/lock
+
Shorewall - + /var/lib/shorewall/lock
Shorewall Lite - + /var/lib/shorewall-lite/lock
-2007-04-08 Shorewall 3.2.10
-
-Problems Corrected in 3.2.10-
1) Previously, if a 'start' or 'restart' command failed during the
compilation step, /sbin/shorewall erroneously returned an exit
status of zero.
2) If IMPLICIT_CONTINUE=Yes was in effect, then sub-zones received the
implicit CONTINUE policy for their intra-zone traffic (rather than
the implicit ACCEPT policy for such traffic). This could cause
intra-zone traffic to be rejected by rules in one of the parent
zones.
3) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. With this
change, shorewall will only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
4) The /usr/share/shorewall[-lite]/modules file has been updated for
kernel 2.6.20.
5) The /proc/net/ip_conntrack pseudo-file has been inexplicably
renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
library has been updated to look for both files.
6) Tunnels of type 'ipsecnat' failed to work properly due to a missing
rule.
7) The 'shorecap' program was not loading modules correctly.
-2007-04-01 Shorewall 3.4.2
- -Problems corrected in Shorewall 3.4.2- -
1) The /usr/share/shorewall[-lite]/modules file has been updated for
kernel 2.6.20.
2) The /proc/net/ip_conntrack pseudo-file has been inexplicably
renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
library has been updated to look for both files.
3) Shoreall 3.4 was not consistent with respect to its treatment of
log level 'none' and 'none!' and built-in actions. In particular,
specifying 'none' with the Limit action produced a run-time error.
Shorewall now correctly suppresses generation of log messages when
a log level of 'none' or 'none!' is given to a built-in action.
4) Tunnels of type 'ipsecnat' would sometimes fail to work because of
a missing rule.
-2007-03-15 Shorewall 3.4.1
- -Problems Corrected in 3.4.1- -
1) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. There was a
partial fix included in 3.4.0; unfortunately, it did not correct the
problem completely. Shorewall 3.4.1 includes the rest of the change
necessarey to only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
2) If the log-prefix in a log message exceeded 29 characters,
'shorewall restart' fails with 'truncate: command not found' and a
possible segmentation fault in iptables.
3) Log messages specifying a log tag had two spaces appended to the
log prefix. This could cause mysterious "log-prefix truncated"
messages.
4) When nested zones were defined in the /etc/shorewall/zones file and
IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,
shell error messages ( usually '<zone>: not found' ) during
compilation resulted.
5) Use of CONTINUE policies lead to startup errors with a message
such as the following:
Applying Policies...
iptables v1.3.7: Couldn't load target
`CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open
shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"
Failed
6) If there were hosts defined as 'critical' in
/etc/shorewall/routestopped then problems occured in two cases:
i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall
clear' was issued.
ii) On Shorewall or Shorewall lite system when 'start' or 'restart'
failed during execution of the compiled script and there was no saved
configuration ('shorewall[-lite] save' has not been issued).
The symptoms were that the following shell messages were issued and
the 'critical' hosts were not enabled:
/var/lib/shorewall/.start: line nnn: source_ip_range: command not found
/var/lib/shorewall/.start: line nnm: dest_ip_range: command not found
Other changes in 3.4.1
1) Several changes are included which allow testing of experimental
versions of Shorewall on systems with 3.4.1 and later 3.4 releases
installed. Among these changes is the detection and reporting of
"Address Type Match" which may be used in future 3.4 releases.
These changes have no effect on normal Shorewall operation.
-2007-03-10 Shorewall 3.4.0
- -Shorewall 3.4.0- -
Release Highlights
1) Shorewall can now be tailored to reduce its footprint on embedded
systems. As part of this change, actions are now completely
optional.
See http://www.shorewall.net/Modularization.html for details.
2) Exclusion is now possible in /etc/shorewall/hosts. This is required
for bridge/firewalls under kernel 2.6.20 and later.
See http://www.shorewall.net/NewBridge.html.
3) Shorewall and Shorewall Lite now include man pages. There is a
man page for shorewall(8), one for shorewall-lite(8) and one for
each configuration file. As part of this change, all documentation
has been removed from Shorewall configuration files. This should
make it easier from users to upgrade from one release to the next
since the configuration files will only change when column is added
or renamed.
See http://www.shorewall.net/manpages/Manpages.html
4) Shorewall now remembers the changes that it has made to routing as
a result of entries in /etc/shorewall/providers and
/etc/shorewall/route_rules and reverses those changes when
appropriate.
Problems Corrected in 3.4.0 Final.
1) In the rules file, following the action with "!" is supposed to
exempt the rule from being suppressed by OPTIMIZE=1. That feature
was not working.
2) If both a macro body and a macro invocation contained an entry in the
SOURCE or DEST column, then compilation failed with the error:
merge_macro_source_dest: command not found
3) An obscure bug in rule activation having to do with the new
exclusion feature in /etc/shorewall/hosts has been corrected.
4) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. With this
change, shorewall will only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
New Features in Shorewall 3.4:
1) In order to accomodate small embedded applications, Shorewall 3.4
is now modularized. In addition to the base files, there are
loadable "libraries" that may be included or omitted from an
embedded system as required.
Loadable Shorewall libraries reside in /usr/share/shorewall/ and
have names that begin with "lib.". The following libraries are
included in Shorewall 3.4:
- lib.accounting. Must be available if you include entries in
/etc/shorewall/accounting.
- lib.actions. Must be available if you do not specify
USE_ACTIONS=No in /etc/shorewall/shorewall.conf.
- lib.base. The base Shorewall library required by all programs,
including compiled firewall scripts. This library is also
released as part of Shorewall Lite and is installed in
/usr/share/shorewall-lite/.
- lib.cli. Library containing the code common to /sbin/shorewall,
/sbin/shorewall-lite. This library is also released as part of
Shorewall Lite and is installed in /usr/share/shorewall-lite/.
- lib.config. Library containing the code that is common to
/usr/share/shorewall/compiler and /usr/share/shorewall/firewall.
- lib.dynamiczones. Must be available if you specify
DYNAMIC_ZONES=Yes in shorewall.conf.
- lib.maclist. Must be available if you specify the 'maclist'
option in /etc/shorewall/interfaces or /etc/shorewall/hosts.
- lib.nat. Must be available if you have entries in
/etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap
or if you use DNAT or REDIRECT rules.
- lib.providers. Must be available if you have entries in
/etc/shorewall/providers.
- lib.proxyarp. Must be available if you have entries in
/etc/shorewall/proxyarp or if you specify the 'proxyarp' option
in /etc/shorewall/interfaces.
- lib.tc. Must be available if you have entries in
/etc/shorewall/tcdevices and /etc/shorewall/tcclasses.
- lib.tcrules. Must be available if you have entries in
/etc/shorewall/tcrules.
- lib.tunnels. Must be available if you have entries in
/etc/shorewall/tunnels.
Embedded applications can further decrease the size of the Shorewall
footprint by:
- Omitting the macro files.
- Omitting all unused extension scripts.
See http://www.shorewall.net/Modularization.html for additional
details.
2) As hinted in the previous bullet, there is a new USE_ACTIONS option
in /etc/shorewall/shorewall.conf. Shorewall actions can be very
powerful but they also require a lot of code to implement. Embedded
applications can omit that code by setting
USE_ACTIONS=No. Shorewall will ignore all action-related files
including /usr/share/shorewall/actions.std and
/etc/shorewall/actions. Builtin actions will still be available for
use in rules and macros.
The 'Limit' action has been converted to a builtin so that Limit is
available even when USE_ACTIONS=No.
See the next item for more information.
3) Prior to Shorewall 3.4, default actions were specified in
/usr/share/shorewall/actions.std or in /etc/shorewall/actions.
This approach has two drawbacks:
a) All DROP policies must use the same default action and all
REJECT policies must use the same default action.
b) Now that we have modularized action processing (see the New
Features section below), we need a way to define default rules
for a policy that does not involve actions.
The solution is two-fold:
- Four new options have been added to the
/etc/shorewall/shorewall.conf file that allow specifying the
default action for DROP, REJECT, ACCEPT and QUEUE.
The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and
QUEUE_DEFAULT.
DROP_DEFAULT describes the rules to be applied before a
connection request is dropped by a DROP policy; REJECT_DEFAULT
describes the rules to be applied if a connection request is
rejected by a REJECT policy. The other two are similar for
ACCEPT and QUEUE policies.
The value assigned to these may be:
a) The name of an action.
b) The name of a macro
c) 'None' or 'none'
The default values are:
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT=none
QUEUE_DEFAULT=none
If USE_ACTIONS=Yes, then these values refer to action.Drop and
action.Reject respectively. If USE_ACTIONS=No, then these values
refer to macro.Drop and macro.Reject.
If you set the value of either option to "None" then no default
action will be used and the default action or macro (if any)
must be specified in /etc/shorewall/policy
- The POLICY column in /etc/shorewall/policy has been extended.
In /etc/shorewall/policy, when the POLICY is DROP, REJECT,
ACCEPT or QUEUE then the policy may be followed by ":" and one
of the following:
a) The word "None" or "none". This causes any default
action defined in /etc/shorewall/shorewall.conf
to be omitted for this policy.
b) The name of an action (requires that USE_ACTIONS=Yes
in shorewall.conf). That action will be invoked
before the policy is enforced.
c) The name of a macro. The rules in that macro will
be applied before the policy is enforced. This
does not require USE_ACTIONS=Yes.
Example:
#SOURCE DEST POLICY LOG
# LEVEL
loc net ACCEPT
net all DROP:MyDrop info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT:MyReject info
4) 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
5) Previously, zone names were restricted to five characters in
length. That limit derives from the --log-prefix in Netfilter log
messages which must be 29 bytes or less in length. With the
standard Shorewall LOGFORMAT, that leaves 11 characters for the
chain name; given that many chain names are of the form
<zone1>2<zone2>, that gives a maximum zone name length of 5.
Beginning with this release, the maximum length of a zone name is
dependent on the LOGFORMAT (the maximum length may never be less
than 5 but it may be greater than 5). For example, setting
LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters.
6) Netfilter provides support for attachment of comments to Netfilter
rules. Comments can be up to 255 bytes in length and are visible
using the "shorewall show <chain>", "shorewall show nat",
"shorewall show mangle" and "shorewall dump" commands. Comments are
delimited by '/* ... */" in the output.
Beginning with Shorewall 3.4, you may place COMMENT lines in the
/etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat
and /etc/shorewall/masq files and in action files. The remainder of
the line is treated as a comment and it will be attached as a
Netfilter comment to the rule(s) generated by succeding entries
in the file.
Note: Do not prefix the comment with "#". Shorewall's two-pass
compiler strips off "#" comments in the first pass and processes
COMMENT lines in the second pass. Hence, by the time that COMMENT
is processed, the "#" and everything following it has been removed
(see example below).
To stop the current comment from being attached to further
rules, simply include COMMENT on a line by itself (so that the
following rules will have no comment) or specify a new COMMENT.
If you do not have Comment support in your iptables/kernel (see the
output of "shorewall[-lite] show capabilities") then COMMENTS are
ignored with this warning:
COMMENT ignored -- requires comment support in iptables/Netfilter
Example from my rules file:
#SOURCE SOURCE DEST PROTO DEST PORT(S)
COMMENT Stop Microsoft Noise
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
COMMENT # Stop comment from being attached to rules below
The output of "shorewall show loc2net" includes (folded):
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 137,445 /* Stop Microsoft Noise */
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139 /* Stop Microsoft Noise */
7) A new macro (macro.RDP) has been added for Microsoft Remote
Desktop. This macro was contributed by Tuomo Soini.
8) 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 extension is invoked, 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".
9) The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to
more accurately describe the contents of the column.
10) Previously, it was not possible to use exclusion in
/etc/shorewall/hosts. Beginning with this release, you may now use
exclusion lists in entries in this file. Exclusion lists are
discussed at:
http://www.shorewall.net/configuration_file_basics.htm#Exclusion.
Example:
loc eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28
In that example, the 'loc' zone is defined to be the subnet
192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4
and hosts in the sub-network 192.168.1.16/28.
11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing"
commands have been added. The first produces the same output as "ip
addr ls". The second produces a report about your routing rules and
tables.
12) Beginning with this release, Shorewall and Shorewall Lite will
share common change logs and release notes.
13) In Shorewall versions prior to 3.4, multiple jumps to a '2all'
chain could be generated in succession.
Example from an earlier shorewall version:
gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006
Counters reset Thu Oct 19 08:34:47 PDT 2006
Chain eth2_fwd (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
0 0 wifi2all all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * br0 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * eth3 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * tun+ 0.0.0.0/0 0.0.0.0/0
gateway:~ #
This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.
gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006
Counters reset Thu Oct 19 09:15:19 PDT 2006
Chain eth2_fwd (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
0 0 wifi2all all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~ #
Note that with OPTIMIZE=1, traffic destined for an
interface/Address that falls outside of all defined zones may now
be logged out of a '2all' chain rather than out of the FORWARD
chain.
The OPTIMIZE setting also controls the suppression of redundant
wildcard rules (those specifying "all" in the SOURCE or DEST
column). A wildcard rule is considered to be redundant when it
has the same ACTION and Log Level as the applicable policy.
Example:
/etc/shorewall/policy
#SOURCE DEST POLICY LEVEL
loc net ACCEPT
/etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
...
ACCEPT all all icmp 8
OPTIMIZE=0
gateway:~ # shorewall show loc2net
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006
Counters reset Thu Oct 26 07:54:58 PDT 2006
Chain loc2net (1 references)
pkts bytes target prot opt in out source destination
...
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~
OPTIMIZE=1
gateway:~ # shorewall show loc2net
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006
Counters reset Thu Oct 26 07:56:38 PDT 2006
Chain loc2net (1 references)
pkts bytes target prot opt in out source destination
...
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~
If you really want a rule that duplicates the policy, follow the
action with "!":
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
...
ACCEPT! all all icmp 8
14) IP Address ranges are now allowed in the drop, reject, allow and
logdrop shorewall[-lite] commands.
15) Previously, Shorewall has not attempted to undo the changes it has
made to the firewall's routing as a result of entries in
/etc/shorewall/providers and /etc/shorewall/routes. Beginning with
this release, Shorewall will attempt to undo these changes.
When Shorewall starts or is restarted and there are entries in
/etc/shorewall/providers, Shorewall will capture the contents
of /etc/shorewall/rt_tables and will restore that database when
Shorewall is stopped or restarted. Similarly, the default route
will be captured the first time that you [re]start Shorewall using
this version and will be restored under the following conditions:
a) shorewall stop
b) shorewall clear
c) shorewall restart or restore and there are no entries in
/etc/shorewall/providers.
Once the default route has been restored, Shorewall will delete
the saved copy so that it will once again be captured at the next
shorewall start or shorewall restore.
16) Shorewall no longer includes policy matches in its generated
ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC
networks are defined using the 'ipsec' option in
/etc/shorewall/hosts).
17) The Makefile installed in /usr/share/shorewall/configfiles/ is now
the same one mentioned at
http://www.shorewall.net/CompiledPrograms.html.
Once the file is copied into an export directory, you modify the
setting of the HOST variable to match the name of the remote
firewall.
The default target is the "firewall" script so "make" compiles the
firewall script if any of the configuration files have
changed. "make install" builds "firewall" if necessary then
installs it on the remote firewall. "make capabilities" will
generate the "capabilities" file. "make save" will save the running
configuration on the remote firewall.
18) Shorewall and Shorewall Lite now include the following manpages.
shorewall-accounting(5)
shorewall-actions(5)
shorewall-blacklist(5)
shorewall.conf(5)
shorewall-ecn(5)
shorewall-exclusion(5)
shorewall-hosts(5)
shorewall-interfaces(5)
shorewall-lite.conf(5)
shorewall-lite(8)
shorewall-maclist(5)
shorewall-masq(5)
shorewall-nat(5)
shorewall-nesting(5)
shorewall-netmap(5)
shorewall-params(5)
shorewall-policy(5)
shorewall-providers(5)
shorewall-proxyarp(5)
shorewall-rfc1918(5)
shorewall-route_rules(5)
shorewall-routestopped(5)
shorewall-rules(5)
shorewall-tcclasses(5)
shorewall-tcdevices(5)
shorewall-tcrules(5)
shorewall-template(5)
shorewall-tos(5)
shorewall-tunnels(5)
shorewall(8)
shorewall-zones(5)
Now that the manpages are in place, command-specific help has been
removed since it duplicates information in the man pages.
19) From the beginning, the Shorewall configuration files in
/etc/shorewall/ have contained documentary comments. While these
comments are useful, they present an upgrade problem. Beginning
with this release, these comments are removed from the
configuration files themselves and are replaced by the manpages
described in the preceding release note entry.
20) Shorewall now uses tc fwmark filters to classify packets for
traffic shaping when the DEVICE isn't an interface described in
/etc/shorewall/interfaces. This is in preparation for the upcoming
change to the way that --physdev-out works in iptables/Netfilter;
that change is now scheduled for kernel 2.6.20.
21) If your kernel and iptables have extended multiport support, then
Shorewall will use that support for the destination port when
generating rules from entries in the /etc/shorewall/tcrules file.
22) The 'safe-start' and 'safe-restart' command have been
improved. Both now accept an optional directory name; if supplied,
Shorewall will look first in that directory for configuration
files.
The commands have also been enhanced to only restore the
configuration once in the event of a failure. Previously, if there
was a current 'save' command in effect, then that configuration
would be restored on a failure and then the last-running
configuration would be restored.
23) The 'try' command has been reimplemented with new semantics.
If Shorewall is started then the firewall state is saved to a
temporary saved configuration (/var/lib/shorewall/.try). Next, if
Shorewall is currently started then a restart command is issued;
otherwise, a start command is performed. if an error occurs during
the compliation phase of the restart or start, the command
terminates without changing the Shorewall state. If an error occurs
during the restart phase, then a 'shorewall restore' is performed
using the saved configuration. If an error occurs during the start
phase, then Shorewall is cleared. If the start/restart succeeds
and a timeout is specified then a 'clear' or 'restore' is performed
after timeout seconds.
24) The syntax of the 'export' command has been made slightly
friendlier.
The old syntax:
export <directory1> [user@]system:[<directory2>]
It is now:
export <directory1> [user@]system[:<directory2>]
In other words, if you don't need to specify <directory2>, you may
omit the colon (":") following the system name.
The old syntax is still accepted -- that is, you can still
type:
export firewall2:
which is equivalent to
export firewall2
25) Shorewall commands may be speeded up slightly by using a
'capabilities' file. The 'capabilities' file was originally
designed for use with Shorewall Lite and records the
iptables/Netfilter features available on the target system.
To generate a capabilities file, execute the following command as
root:
shorewall show -f capabilities > /etc/shorewall/capabilities
When you install a new kernel and/or iptables, be sure to generate
a new capabilities file.
26) When syslogd is run with the -C option (which in some
implementations causes syslogd to log to an in-memory circular
buffer), /sbin/shorewall will now use the 'logread' command to read
the log from that buffer. This is for combatibility with OpenWRT.
27) There is now a ":T" qualifier in /etc/shorewall/tcrules which
causes the resulting rule to be inserted into the POSTROUTING
chain.
28) The program /usr/share/shorewall/wait4ifup can be used to wait for
a network device (such as a ppp device) to reach the UP state.
/usr/share/shorewall/wait4ifup <interface> [ <seconds> ]
The program will wait for up to <seconds> seconds for the
named <interface> to reach the UP state. If <seconds> is not given,
60 seconds is assumed.
The exit status is zero if <interface> comes up within <seconds>
seconds and non-zero otherwise.
29) Previously, 'ipsecnat' tunnels allowed AH traffic by default
(unless 'isecnat:noah' was given). Given that AH is incompatible
with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.
30) Shorewall now generates half as many rules as previously in the
'blacklst' chain when BLACKLIST_LOGLEVEL is specified.
31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in
shorewall.conf then Shorewall will not process
/etc/shorewall/params when the compiled script is run. With
EXPORTPARAMS=No, any shell variables needed at run-time must be set
in /etc/shorewall/init.
In a Shorewall/Shorewall Lite environment, this allows
/etc/shorewall/params to be written to run exclusively
on the administrative system while /etc/shorewall/init runs
exclusively on the firewall system.
So shell variables required at compile time may be set in
/etc/shorewall/params and those required at run-time may be set in
/etc/shorewall/init.
Note 1: If you need shell variables values in your
/etc/shorewall/stop or /etc/shorewall/stopped script, then you need
to set their values in /etc/shorewall/stop. /etc/shorewall/init is
not invoked during processing of the 'stop' and 'clear' commands.
Note 2: EXPORTPARAMS was actually introduced in Shorewall version
3.2.9. It is described here for the benefit of those who did not
install that version.
-Old News here
- +2007-04-08 Shorewall 3.2.10
Problems Corrected in 3.2.10+
1) Previously, if a 'start' or 'restart' command failed during the
compilation step, /sbin/shorewall erroneously returned an exit
status of zero.
2) If IMPLICIT_CONTINUE=Yes was in effect, then sub-zones received the
implicit CONTINUE policy for their intra-zone traffic (rather than
the implicit ACCEPT policy for such traffic). This could cause
intra-zone traffic to be rejected by rules in one of the parent
zones.
3) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. With this
change, shorewall will only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
4) The /usr/share/shorewall[-lite]/modules file has been updated for
kernel 2.6.20.
5) The /proc/net/ip_conntrack pseudo-file has been inexplicably
renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
library has been updated to look for both files.
6) Tunnels of type 'ipsecnat' failed to work properly due to a missing
rule.
7) The 'shorecap' program was not loading modules correctly.
+2007-04-01 Shorewall 3.4.2Problems corrected in Shorewall 3.4.2+
1) The /usr/share/shorewall[-lite]/modules file has been updated for
kernel 2.6.20.
2) The /proc/net/ip_conntrack pseudo-file has been inexplicably
renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli
library has been updated to look for both files.
3) Shoreall 3.4 was not consistent with respect to its treatment of
log level 'none' and 'none!' and built-in actions. In particular,
specifying 'none' with the Limit action produced a run-time error.
Shorewall now correctly suppresses generation of log messages when
a log level of 'none' or 'none!' is given to a built-in action.
4) Tunnels of type 'ipsecnat' would sometimes fail to work because of
a missing rule.
+2007-03-15 Shorewall +3.4.1Problems Corrected in 3.4.1+
1) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. There was a
partial fix included in 3.4.0; unfortunately, it did not correct the
problem completely. Shorewall 3.4.1 includes the rest of the change
necessarey to only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
2) If the log-prefix in a log message exceeded 29 characters,
'shorewall restart' fails with 'truncate: command not found' and a
possible segmentation fault in iptables.
3) Log messages specifying a log tag had two spaces appended to the
log prefix. This could cause mysterious "log-prefix truncated"
messages.
4) When nested zones were defined in the /etc/shorewall/zones file and
IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,
shell error messages ( usually '<zone>: not found' ) during
compilation resulted.
5) Use of CONTINUE policies lead to startup errors with a message
such as the following:
Applying Policies...
iptables v1.3.7: Couldn't load target
`CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open
shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"
Failed
6) If there were hosts defined as 'critical' in
/etc/shorewall/routestopped then problems occured in two cases:
i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall
clear' was issued.
ii) On Shorewall or Shorewall lite system when 'start' or 'restart'
failed during execution of the compiled script and there was no saved
configuration ('shorewall[-lite] save' has not been issued).
The symptoms were that the following shell messages were issued and
the 'critical' hosts were not enabled:
/var/lib/shorewall/.start: line nnn: source_ip_range: command not found
/var/lib/shorewall/.start: line nnm: dest_ip_range: command not found
Other changes in 3.4.1
1) Several changes are included which allow testing of experimental
versions of Shorewall on systems with 3.4.1 and later 3.4 releases
installed. Among these changes is the detection and reporting of
"Address Type Match" which may be used in future 3.4 releases.
These changes have no effect on normal Shorewall operation.
+2007-03-10 Shorewall +3.4.0Shorewall 3.4.0+
Release Highlights
1) Shorewall can now be tailored to reduce its footprint on embedded
systems. As part of this change, actions are now completely
optional.
See http://www.shorewall.net/Modularization.html for details.
2) Exclusion is now possible in /etc/shorewall/hosts. This is required
for bridge/firewalls under kernel 2.6.20 and later.
See http://www.shorewall.net/NewBridge.html.
3) Shorewall and Shorewall Lite now include man pages. There is a
man page for shorewall(8), one for shorewall-lite(8) and one for
each configuration file. As part of this change, all documentation
has been removed from Shorewall configuration files. This should
make it easier from users to upgrade from one release to the next
since the configuration files will only change when column is added
or renamed.
See http://www.shorewall.net/manpages/Manpages.html
4) Shorewall now remembers the changes that it has made to routing as
a result of entries in /etc/shorewall/providers and
/etc/shorewall/route_rules and reverses those changes when
appropriate.
Problems Corrected in 3.4.0 Final.
1) In the rules file, following the action with "!" is supposed to
exempt the rule from being suppressed by OPTIMIZE=1. That feature
was not working.
2) If both a macro body and a macro invocation contained an entry in the
SOURCE or DEST column, then compilation failed with the error:
merge_macro_source_dest: command not found
3) An obscure bug in rule activation having to do with the new
exclusion feature in /etc/shorewall/hosts has been corrected.
4) The "shorewall-[lite] [re]start and stop" commands reset the
proxy_arp flag on all interfaces on the system making it impossible
to control proxy arp manually with Shorewall installed. With this
change, shorewall will only clear proxy arp if there were entries in
/etc/shorewall/proxyarp the last time that Shorewall was
[re]started.
New Features in Shorewall 3.4:
1) In order to accomodate small embedded applications, Shorewall 3.4
is now modularized. In addition to the base files, there are
loadable "libraries" that may be included or omitted from an
embedded system as required.
Loadable Shorewall libraries reside in /usr/share/shorewall/ and
have names that begin with "lib.". The following libraries are
included in Shorewall 3.4:
- lib.accounting. Must be available if you include entries in
/etc/shorewall/accounting.
- lib.actions. Must be available if you do not specify
USE_ACTIONS=No in /etc/shorewall/shorewall.conf.
- lib.base. The base Shorewall library required by all programs,
including compiled firewall scripts. This library is also
released as part of Shorewall Lite and is installed in
/usr/share/shorewall-lite/.
- lib.cli. Library containing the code common to /sbin/shorewall,
/sbin/shorewall-lite. This library is also released as part of
Shorewall Lite and is installed in /usr/share/shorewall-lite/.
- lib.config. Library containing the code that is common to
/usr/share/shorewall/compiler and /usr/share/shorewall/firewall.
- lib.dynamiczones. Must be available if you specify
DYNAMIC_ZONES=Yes in shorewall.conf.
- lib.maclist. Must be available if you specify the 'maclist'
option in /etc/shorewall/interfaces or /etc/shorewall/hosts.
- lib.nat. Must be available if you have entries in
/etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap
or if you use DNAT or REDIRECT rules.
- lib.providers. Must be available if you have entries in
/etc/shorewall/providers.
- lib.proxyarp. Must be available if you have entries in
/etc/shorewall/proxyarp or if you specify the 'proxyarp' option
in /etc/shorewall/interfaces.
- lib.tc. Must be available if you have entries in
/etc/shorewall/tcdevices and /etc/shorewall/tcclasses.
- lib.tcrules. Must be available if you have entries in
/etc/shorewall/tcrules.
- lib.tunnels. Must be available if you have entries in
/etc/shorewall/tunnels.
Embedded applications can further decrease the size of the Shorewall
footprint by:
- Omitting the macro files.
- Omitting all unused extension scripts.
See http://www.shorewall.net/Modularization.html for additional
details.
2) As hinted in the previous bullet, there is a new USE_ACTIONS option
in /etc/shorewall/shorewall.conf. Shorewall actions can be very
powerful but they also require a lot of code to implement. Embedded
applications can omit that code by setting
USE_ACTIONS=No. Shorewall will ignore all action-related files
including /usr/share/shorewall/actions.std and
/etc/shorewall/actions. Builtin actions will still be available for
use in rules and macros.
The 'Limit' action has been converted to a builtin so that Limit is
available even when USE_ACTIONS=No.
See the next item for more information.
3) Prior to Shorewall 3.4, default actions were specified in
/usr/share/shorewall/actions.std or in /etc/shorewall/actions.
This approach has two drawbacks:
a) All DROP policies must use the same default action and all
REJECT policies must use the same default action.
b) Now that we have modularized action processing (see the New
Features section below), we need a way to define default rules
for a policy that does not involve actions.
The solution is two-fold:
- Four new options have been added to the
/etc/shorewall/shorewall.conf file that allow specifying the
default action for DROP, REJECT, ACCEPT and QUEUE.
The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and
QUEUE_DEFAULT.
DROP_DEFAULT describes the rules to be applied before a
connection request is dropped by a DROP policy; REJECT_DEFAULT
describes the rules to be applied if a connection request is
rejected by a REJECT policy. The other two are similar for
ACCEPT and QUEUE policies.
The value assigned to these may be:
a) The name of an action.
b) The name of a macro
c) 'None' or 'none'
The default values are:
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT=none
QUEUE_DEFAULT=none
If USE_ACTIONS=Yes, then these values refer to action.Drop and
action.Reject respectively. If USE_ACTIONS=No, then these values
refer to macro.Drop and macro.Reject.
If you set the value of either option to "None" then no default
action will be used and the default action or macro (if any)
must be specified in /etc/shorewall/policy
- The POLICY column in /etc/shorewall/policy has been extended.
In /etc/shorewall/policy, when the POLICY is DROP, REJECT,
ACCEPT or QUEUE then the policy may be followed by ":" and one
of the following:
a) The word "None" or "none". This causes any default
action defined in /etc/shorewall/shorewall.conf
to be omitted for this policy.
b) The name of an action (requires that USE_ACTIONS=Yes
in shorewall.conf). That action will be invoked
before the policy is enforced.
c) The name of a macro. The rules in that macro will
be applied before the policy is enforced. This
does not require USE_ACTIONS=Yes.< +br>
Example:
#SOURCE DEST POLICY LOG
# LEVEL
loc net ACCEPT
net all DROP:MyDrop info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT:MyReject info
4) 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
5) Previously, zone names were restricted to five characters in
length. That limit derives from the --log-prefix in Netfilter log
messages which must be 29 bytes or less in length. With the
standard Shorewall LOGFORMAT, that leaves 11 characters for the
chain name; given that many chain names are of the form
<zone1>2<zone2>, that gives a maximum zone name length of 5.
Beginning with this release, the maximum length of a zone name is
dependent on the LOGFORMAT (the maximum length may never be less
than 5 but it may be greater than 5). For example, setting
LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters.
6) Netfilter provides support for attachment of comments to Netfilter
rules. Comments can be up to 255 bytes in length and are visible
using the "shorewall show <chain>", "shorewall show nat",
"shorewall show mangle" and "shorewall dump" commands. Comments are
delimited by '/* ... */" in the output.
Beginning with Shorewall 3.4, you may place COMMENT lines in the
/etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat
and /etc/shorewall/masq files and in action files. The remainder of
the line is treated as a comment and it will be attached as a
Netfilter comment to the rule(s) generated by succeding entries
in the file.
Note: Do not prefix the comment with "#". Shorewall's two-pass
compiler strips off "#" comments in the first pass and processes
COMMENT lines in the second pass. Hence, by the time that COMMENT
is processed, the "#" and everything following it has been removed
(see example below).
To stop the current comment from being attached to further
rules, simply include COMMENT on a line by itself (so that the
following rules will have no comment) or specify a new COMMENT.
If you do not have Comment support in your iptables/kernel (see the
output of "shorewall[-lite] show capabilities") then COMMENTS are
ignored with this warning:
COMMENT ignored -- requires comment support in iptables/Netfilter
Example from my rules file:
#SOURCE SOURCE DEST PROTO DEST PORT(S)
COMMENT Stop Microsoft Noise
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
COMMENT # Stop comment from being attached to rules below
The output of "shorewall show loc2net" includes (folded):
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 137,445 /* Stop Microsoft Noise */
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139 /* Stop Microsoft Noise */
7) A new macro (macro.RDP) has been added for Microsoft Remote
Desktop. This macro was contributed by Tuomo Soini.
8) 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 extension is invoked, 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".
9) The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to
more accurately describe the contents of the column.
10) Previously, it was not possible to use exclusion in
/etc/shorewall/hosts. Beginning with this release, you may now use
exclusion lists in entries in this file. Exclusion lists are
discussed at:
http://www.shorewall.net/configuration_file_basics.htm#Exclusion.
Example:
loc eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28
In that example, the 'loc' zone is defined to be the subnet
192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4
and hosts in the sub-network 192.168.1.16/28.
11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing"
commands have been added. The first produces the same output as "ip
addr ls". The second produces a report about your routing rules and
tables.
12) Beginning with this release, Shorewall and Shorewall Lite will
share common change logs and release notes.
13) In Shorewall versions prior to 3.4, multiple jumps to a '2all'
chain could be generated in succession.
Example from an earlier shorewall version:
gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006
Counters reset Thu Oct 19 08:34:47 PDT 2006
Chain eth2_fwd (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
0 0 wifi2all all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * br0 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * eth3 0.0.0.0/0 0.0.0.0/0
0 0 wifi2all all -- * tun+ 0.0.0.0/0 0.0.0.0/0
gateway:~ #
This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.
gateway:~ # shorewall-lite show eth2_fwd
Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006
Counters reset Thu Oct 19 09:15:19 PDT 2006
Chain eth2_fwd (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
0 0 wifi2all all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~ #
Note that with OPTIMIZE=1, traffic destined for an
interface/Address that falls outside of all defined zones may now
be logged out of a '2all' chain rather than out of the FORWARD
chain.
The OPTIMIZE setting also controls the suppression of redundant
wildcard rules (those specifying "all" in the SOURCE or DEST
column). A wildcard rule is considered to be redundant when it
has the same ACTION and Log Level as the applicable policy.
Example:
/etc/shorewall/policy
#SOURCE DEST POLICY LEVEL
loc net ACCEPT
/etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
...
ACCEPT all all icmp 8
OPTIMIZE=0
gateway:~ # shorewall show loc2net
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006
Counters reset Thu Oct 26 07:54:58 PDT 2006< +br>
Chain loc2net (1 references)
pkts bytes target prot opt in out source destination
...
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~
OPTIMIZE=1
gateway:~ # shorewall show loc2net
Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006
Counters reset Thu Oct 26 07:56:38 PDT 2006
Chain loc2net (1 references)
pkts bytes target prot opt in out source destination
...
0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
gateway:~
If you really want a rule that duplicates the policy, follow the
action with "!":
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
...
ACCEPT! all all icmp 8
14) IP Address ranges are now allowed in the drop, reject, allow and
logdrop shorewall[-lite] commands.
15) Previously, Shorewall has not attempted to undo the changes it has
made to the firewall's routing as a result of entries in
/etc/shorewall/providers and /etc/shorewall/routes. Beginning with
this release, Shorewall will attempt to undo these changes.
When Shorewall starts or is restarted and there are entries in
/etc/shorewall/providers, Shorewall will capture the contents
of /etc/shorewall/rt_tables and will restore that database when
Shorewall is stopped or restarted. Similarly, the default route
will be captured the first time that you [re]start Shorewall using
this version and will be restored under the following conditions:
a) shorewall stop
b) shorewall clear
c) shorewall restart or restore and there are no entries in
/etc/shorewall/providers.
Once the default route has been restored, Shorewall will delete
the saved copy so that it will once again be captured at the next
shorewall start or shorewall restore.
16) Shorewall no longer includes policy matches in its generated
ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC
networks are defined using the 'ipsec' option in
/etc/shorewall/hosts).
17) The Makefile installed in /usr/share/shorewall/configfiles/ is now
the same one mentioned at
http://www.shorewall.net/CompiledPrograms.html.
Once the file is copied into an export directory, you modify the
setting of the HOST variable to match the name of the remote
firewall.
The default target is the "firewall" script so "make" compiles the
firewall script if any of the configuration files have
changed. "make install" builds "firewall" if necessary then
installs it on the remote firewall. "make capabilities" will
generate the "capabilities" file. "make save" will save the running
configuration on the remote firewall.
18) Shorewall and Shorewall Lite now include the following manpages.
shorewall-accounting(5)
shorewall-actions(5)
shorewall-blacklist(5)
shorewall.conf(5)
shorewall-ecn(5)
shorewall-exclusion(5)
shorewall-hosts(5)
shorewall-interfaces(5)
shorewall-lite.conf(5)
shorewall-lite(8)
shorewall-maclist(5)
shorewall-masq(5)
shorewall-nat(5)
shorewall-nesting(5)
shorewall-netmap(5)
shorewall-params(5)
shorewall-policy(5)
shorewall-providers(5)
shorewall-proxyarp(5)
shorewall-rfc1918(5)
shorewall-route_rules(5)
shorewall-routestopped(5)
shorewall-rules(5)
shorewall-tcclasses(5)
shorewall-tcdevices(5)
shorewall-tcrules(5)
shorewall-template(5)
shorewall-tos(5)
shorewall-tunnels(5)
shorewall(8)
shorewall-zones(5)
Now that the manpages are in place, command-specific help has been
removed since it duplicates information in the man pages.
19) From the beginning, the Shorewall configuration files in
/etc/shorewall/ have contained documentary comments. While these
comments are useful, they present an upgrade problem. Beginning
with this release, these comments are removed from the
configuration files themselves and are replaced by the manpages
described in the preceding release note entry.
20) Shorewall now uses tc fwmark filters to classify packets for
traffic shaping when the DEVICE isn't an interface described in
/etc/shorewall/interfaces. This is in preparation for the upcoming
change to the way that --physdev-out works in iptables/Netfilter;
that change is now scheduled for kernel 2.6.20.
21) If your kernel and iptables have extended multiport support, then
Shorewall will use that support for the destination port when
generating rules from entries in the /etc/shorewall/tcrules file.
22) The 'safe-start' and 'safe-restart' command have been
improved. Both now accept an optional directory name; if supplied,
Shorewall will look first in that directory for configuration
files.
The commands have also been enhanced to only restore the
configuration once in the event of a failure. Previously, if there
was a current 'save' command in effect, then that configuration
would be restored on a failure and then the last-running
configuration would be restored.
23) The 'try' command has been reimplemented with new semantics.
If Shorewall is started then the firewall state is saved to a
temporary saved configuration (/var/lib/shorewall/.try). Next, if
Shorewall is currently started then a restart command is issued;
otherwise, a start command is performed. if an error occurs during
the compliation phase of the restart or start, the command
terminates without changing the Shorewall state. If an error occurs
during the restart phase, then a 'shorewall restore' is performed
using the saved configuration. If an error occurs during the start
phase, then Shorewall is cleared. If the start/restart succeeds
and a timeout is specified then a 'clear' or 'restore' is performed
after timeout seconds.
24) The syntax of the 'export' command has been made slightly
friendlier.
The old syntax:
export <directory1> [user@]system:[<directory2>]
It is now:
export <directory1> [user@]system[:<directory2>]
In other words, if you don't need to specify <directory2>, you may
omit the colon (":") following the system name.
The old syntax is still accepted -- that is, you can still
type:
export firewall2:
which is equivalent to
export firewall2
25) Shorewall commands may be speeded up slightly by using a
'capabilities' file. The 'capabilities' file was originally
designed for use with Shorewall Lite and records the
iptables/Netfilter features available on the target system.
To generate a capabilities file, execute the following command as
root:
shorewall show -f capabilities > /etc/shorewall/capabil +ities
When you install a new kernel and/or iptables, be sure to generate
a new capabilities file.
26) When syslogd is run with the -C option (which in some
implementations causes syslogd to log to an in-memory circular
buffer), /sbin/shorewall will now use the 'logread' command to read
the log from that buffer. This is for combatibility with OpenWRT.
27) There is now a ":T" qualifier in /etc/shorewall/tcrules which
causes the resulting rule to be inserted into the POSTROUTING
chain.
28) The program /usr/share/shorewall/wait4ifup can be used to wait for
a network device (such as a ppp device) to reach the UP state.
/usr/share/shorewall/wait4ifup <interface> [ <seconds> ]
The program will wait for up to <seconds> seconds for the
named <interface> to reach the UP state. If <seconds> is not given,
60 seconds is assumed.
The exit status is zero if <interface> comes up within <seconds>
seconds and non-zero otherwise.
29) Previously, 'ipsecnat' tunnels allowed AH traffic by default
(unless 'isecnat:noah' was given). Given that AH is incompatible
with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.
30) Shorewall now generates half as many rules as previously in the
'blacklst' chain when BLACKLIST_LOGLEVEL is specified.
31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in
shorewall.conf then Shorewall will not process
/etc/shorewall/params when the compiled script is run. With
EXPORTPARAMS=No, any shell variables needed at run-time must be set
in /etc/shorewall/init.
In a Shorewall/Shorewall Lite environment, this allows
/etc/shorewall/params to be written to run exclusively
on the administrative system while /etc/shorewall/init runs
exclusively on the firewall system.
So shell variables required at compile time may be set in
/etc/shorewall/params and those required at run-time may be set in
/etc/shorewall/init.
Note 1: If you need shell variables values in your
/etc/shorewall/stop or /etc/shorewall/stopped script, then you need
to set their values in /etc/shorewall/stop. /etc/shorewall/init is
not invoked during processing of the 'stop' and 'clear' commands.
Note 2: EXPORTPARAMS was actually introduced in Shorewall version
3.2.9. It is described here for the benefit of those who did not
install that version.
+Old News here