[Shorewall-announce] Shorewall 2.2.3
teastep at shorewall.net
Thu Apr 7 13:20:35 PDT 2005
1) If a zone is defined in /etc/shorewall/hosts using
<interface>:!<network> in the HOSTS column then startup errors occur
on "shorewall [re]start".
2) Previously, if "shorewall status" was run on a system whose kernel
lacked advanced routing support (CONFIG_IP_ADVANCED_ROUTER), then
no routing information was displayed.
1) A new extension script "continue" has been added. This script is
invoked after Shorewall has set the built-in filter chains'
policy to DROP, deleted any existing Netfilter rules and user
chains and has enabled existing connections.
It is useful for enabling certain communication while Shorewall is
being [re]started. Be sure to delete any rules that you add here in
your /etc/shorewall/start file.
2) There has been ongoing confusion about how the
/etc/shorewall/routestopped file works. People understand how it
works with the 'shorewall stop' command but when they read that
'shorewall restart' is logically equivalent to 'shorewall stop'
followed by 'shorewall start' then they erroneously conclude that
/etc/shorewall/routestopped can be used to enable new connections
during 'shorewall restart'. Up to now, it cannot -- that file is not
processed during either 'shorewall start' or 'shorewall restart'.
Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped
will be processed TWICE during 'shorewall start' and during
'shorewall restart'. It will be processed early in the command
execution to add rules allowing new connections while the command
is running and it will be processed again when the
command is complete to remove the rules added earlier.
The result of this change will be that during most of [re]start, new
connections will be allowed in accordance with the contents of
3) The performance of configurations with a large numbers of entries in
/etc/shorewall/maclist can be improved by setting the new
MACLIST_TTL variable in /etc/shorewall/shorewall.conf.
If your iptables and kernel support the "Recent Match" (see the
output of "shorewall check" near the top), you can cache the results
of a 'maclist' file lookup and thus reduce the overhead associated
with MAC Verification.
When a new connection arrives from a 'maclist' interface, the packet
passes through then list of entries for that interface in
/etc/shorewall/maclist. If there is a match then the source IP
address is added to the 'Recent' set for that interface. Subsequent
connection attempts from that IP address occurring within
$MACLIST_TTL seconds will be accepted without having to scan all
of the entries. After $MACLIST_TTL from the first accepted
connection request from an IP address, the next connection request
from that IP address will be checked against the entire list.
If MACLIST_TTL is not specified or is specified as empty (e.g,
MACLIST_TTL="" or is specified as zero then 'maclist' lookups
will not be cached.
4) You can now specify QUEUE as a policy and you can designate a
common action for QUEUE policies in /etc/shorewall/actions. This is
useful for sending packets to something like Snort Inline.
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep at shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
More information about the Shorewall-announce