----------------------------------------------------------------------------
S H O R E W A L L 4 . 5 . 2 1 . 5
------------------------------------
D e c e m b e r 1 9 , 2 0 1 3
----------------------------------------------------------------------------
I. PROBLEMS CORRECTED IN THIS RELEASE
II. KNOWN PROBLEMS REMAINING
III. NEW FEATURES IN THIS RELEASE
IV. MIGRATION ISSUES
V. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES
----------------------------------------------------------------------------
I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
----------------------------------------------------------------------------
4.5.21.5
1) A number of minor updates have been made to the documentation and
manpages.
2) The 'postcompile' extension script is now documented at
http://www.shorewall.org/shorewall_extension_scripts.htm
3) The 'add' command previously failed if 'IPSET=' appeared in the
shorewall.conf file. This has been corrected.
4.5.21.4
1) The Broadcast actions have been corrected:
o --dst-type BROADCAST has been removed from the IPv6 version
o A superfluous DROP rule in the IPv4 version has been suppressed.
2) Previously, if an HFSC class was specified with dmax but not umax,
then the firewall would fail to start with the messages:
Nov 14 13:42:42 Setting up Traffic Control...
HFSC: Illegal "umax"
HFSC: Illegal "sc"
ERROR: Command "tc class add dev eth1 parent 1:1 classid 1:110 hfsc sc
umax b dmax 150ms rate 1575kbit ul rate 3150kbit" Failed
That problem has been corrected.
4.5.21.3
1) The Shorewall-init tarball installer now works correctly on recent
Ubuntu releases.
2) The installers now run update-rc.d on Debian-based systems that
don't have insserv installed.
4.5.21.2
1) Previously, the AutoBL action would fail if the kernel and iptables
did not support the Recent Match '--reap' option. A new REAP_OPTION
capability has been added to work around this issue.
2) The Shorewall-core installer no longer reports an error from 'cp'
stating that it could not stat the shorewallrc file.
3) When a non-root user attempts to execute 'version -a', the CLI no
longer attempts to get the version of the compiled
firewall. Previously, The command issued the following diagnostic
when run by non-root:
/sbin/shorewall: /var/lib/shorewall/firewall: Permission denied
4) Shorewall no longer uses 'fgrep' to allow for use on systems
without that utility. All uses of 'fgrep' have been replaced by
'grep -F'.
5) Placing |<mark> in the ACTION column of the tcrules file no longer
raises a fatal compilation error.
6) Support has been added to the Shorewall-core configure scripts and
installer for Ubuntu Raring.
4.5.21.1
1) Problems with the Shorewall Init installer (install.sh) were
corrected. These problems affected initial Gentoo and Debian
installs.
2) A problem that prevented multiple ICMP/ICMP6 types to be specified
in a rule has been corrected.
3) Previously, an attempt to specify RAS or Q.931 in the HELPER column
was rejected with an error.
4) The 'nohostroute' provider option was not honored in the default
table when USE_DEFAULT_RT=Yes.
4.5.21
1) ip[6]tables 1.4.20 introduced an incompatible change that causes
the program to fail if there is another instance of either iptables
or ip6tables already running. This behavior can be avoided if the
new -w option is specified.
To work around this problem, the compiler now uses the -w option
(when available) during capabilities determination so that
shorewall and shorewall6 compilations can proceed in parallel.
2) Previously, the Shorewall-init installer unconditionally installed
the sysconfig file even when a different SYSCONFFILE was specified.
(Thomas D).
3) /sbin/shorewall-init now includes the correct SYSCONFDIR name in
its error message that reports the absense of
${SYSCONFDIR}/shorewall-init. (Thomas D).
4) /sbin/shorewall-init and the Shorewall-init SysV init scripts now
honor the setting of $OPTIONS.
5) The -lite installers now look in ${SHAREDIR} for the coreversion
file rather than in /usr/share/.
6) If a Shorewall-lite installation used an /etc/shorewall-lite/vardir
file to set a non-standard state directory, the administrative
system would send the firewall and firewall.conf files to the wrong
directory on the firewall system.
7) Previously, the compiler verified 'monthdays' specifications in the
rules TIME column, but failed to include --monthdays in the
generated rule. That omission has been corrected.
8) The installers now use 'insserv' on Debian systems to update the
SysV init symlinks. Previously, update-rc.d was used but that
approach fails on Debian 7.
9) The Multicast DNS macros (mDNS and mDNSbi) now allow the entire
non-priv port range (1024-65535) for the the dynamic unicast
port. Previously, only the Linux 2.6+ dynamic port range
(32768-65535) were allowed.
----------------------------------------------------------------------------
I I. K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
1) On systems running Upstart, shorewall-init cannot reliably secure
the firewall before interfaces are brought up.
----------------------------------------------------------------------------
I I I. N E W F E A T U R E S I N T H I S R E L E A S E
----------------------------------------------------------------------------
4.5.21.4
1) The tcrules file now supports DROP entries to allow early dropping
of DOS packets.
4.5.21
1) When a REJECT target is specified, Shorewall normally handles the
packet as follows:
- If the destination address is a broadcast or multicast address,
the packet is dropped.
- If the protocol is IGMP (1), then the packet is dropped.
- If the protocol is TCP (6) then the packet is rejected with an
RST.
- If the protocol is UDP (17) then the packet is rejected with
a 'port-unreachable' ICMP (ICMP6).
- If the protocol is ICMP (ICMP6), then the packet is rejected
with a 'host-unreachable' ('addr-unreachable') ICMP (ICMP6).
- Otherwise, the packet is rejected with a 'host-prohibited'
(adm-prohibited) ICMP (ICMP6).
Beginning with this release, this behavior may be modified using
the new REJECT_ACTION option in shorewall.conf (shorewall6.conf).
REJECT_ACTION=<action>
where <action> is the name of an action that implements your
alternative handling. The 'nolog' and 'inline' options are
automatically assumed for the named <action>.
The following action implements the standard behavior described
above:
?format 2
#TARGET SOURCE DEST PROTO
Broadcast(DROP) - - -
DROP - - 2
INLINE - - 6 ; -j REJECT --reject-with tcp-reset
?if __ENHANCED_REJECT
INLINE - - 17 ; -j REJECT
?if __IPV4
INLINE - - 1 ; -j REJECT --reject-with icmp-host-unreachable
INLINE - - - ; -j REJECT --reject-with icmp-host-prohibited
?else
INLINE - - 58 ; -j REJECT --reject-with icmp6-addr-unreachable
INLINE - - - ; -j REJECT --reject-with icmp6-adm-prohibited
?endif
?else
INLINE - - - ; -j REJECT
?endif
2) In earlier versions, default log levels in shorewall.conf
(shorewall6.conf) were not validated, making it difficult to
determine what setting was causing the following error message:
ERROR: Log level INFO requires LOG Target support in your kernel
and iptables
This change will make log level errors from shorewall.conf and
shorewall6.conf easier to isolate by including the option name.
Example:
ERROR: Log level INFO for option SFILTER_LOG_LEVEL requires LOG
Target support in your kernel and iptables
3) The 'shorewall dump' command now uses 'ss' rather than 'netstat' to
produce socket-related information. By Martin Gignac.
4) Thomas D has provided installer support for Gentoo. Thank you
Thomas!
5) The generated firewall script inserts a host route for each
provider gateway into both the main routing table and into the
provider's routing table. This is necessary on older kernels to
avoid failure of default route insertion into the tables.
It has been discovered, however, that these host routes prevent
Zebra from being able to add routes on some distributions, most
notably Debian 7.0. To work around this issue, two new provider
options are now available:
hostroute This is the default and causes the host routes
described above to be inserted.
nohostroute Prevents the host routes from being inserted.
6) It was previously not possible for Perl code in an action file to
change the rule comment as is done using the ?COMMENT directive
outside of Perl.
To allow actions to manipulate the current comment, two functions
are made available:
push_comment() Clears the current rule comment and returns
that comment to the caller.
set_comment($) Sets the current rule comment to the passed
string.
Typical usage would be:
?BEGIN PERL
use Shorewall::Config;
...
my $oldcomment = push_comment(); #Save and clear current
#current rule comment
...
set_comment('This is a comment');
add_ijump(....); #This rule will have comment
# /* This is a comment */
set_comment(''); #Clear current rule comment
add_ijump(....); #This rule has no comment
...
set_comment($oldcomment) #Restore caller's comment
#if any.
?END PERL
7) The compiler version used to create the current firewall script is
now displayed in the output of the 'status' and 'version -a'
commands.
----------------------------------------------------------------------------
I V. M I G R A T I O N I S S U E S
----------------------------------------------------------------------------
1) If you are migrating from Shorewall 4.2.x or earlier, please see
http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.27/releasenotes.txt
2) The BLACKLIST section of the rules file has been eliminated.
If you have entries in that file section, you must move them to the
blrules file.
3) This version of Shorewall requires either the Digest::SHA1 or
Digest::SHA Perl module.
Debian: libdigest-sha1-perl or libdigest-sha-perl
Fedora: perl-Digest-SHA1 or perl-Digest-SHA
OpenSuSE: perl-Digest-SHA1 or perl-Digest-SHA
4) The generated firewall script now maintains the
/var/lib/shorewall[6][-lite]/interface.status files used by SWPING
and by LSM.
If you have optional providers and do not run a link monitor like
SWPING or LSM that updates these files, then you should remove
/etc/shorewall[6]/isusable if it is installed.
Beginning with Shorewall 4.5.3.1:
- The 'disable' command stores a 1 in the interface's .status file.
- The .status file is ignored on 'enable' but not on 'start',
'restart', 'restore' and 'refresh'.
This means that a disabled interface can only be re-enabled using
the 'enable' command.
5) The /etc/shorewall[6]/tos file is now deprecated in favor of the
TOS() action in /etc/shorewall[6]/tcrules.
6) The MARK/CLASSIFY column in /etc/shorewall[6]/tcrules has been
renamed ACTION to reflect the expanded set of actions that can be
specified in the column. There is no change to existing
functionality.
7) Beginning with Shorewall 4.5.2, using /etc/shorewall-lite/vardir
and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in
favor of the VARDIR setting in shorewallrc.
NOTE: While the name of the variable remains VARDIR, the
meaning is slightly different. When set in shorewallrc,
each product (shorewall-lite, and shorewall6-lite) will
create a directory under the specified path name to
hold state information.
Example:
VARDIR=/opt/var/
The state directory for shorewall-lite will be
/opt/var/shorewall-lite/ and the directory for
shorewall6-lite will be /opt/var/shorewall6-lite.
When VARDIR is set in /etc/shorewall[6]/vardir, the
product will save its state directly in the specified
directory.
In Shorewall 4.5.8, a VARLIB variable was added to the shorewallrc
file and the meaning of VARDIR is once again consistent. The
default setting of VARDIR for a particular product is
${VARLIB}/$product. There is an entry of that form in the
shorewallrc file. Because there is a single shorewallrc file for
all installed products, the /etc/shorewall[6]-lite/vardir file
provides the only means for overriding this default.
8) Begining with Shorewall 4.5.6, the tcrules file is processed if
MANGLE_ENABLED=Yes, independent of the setting of TC_ENABLED. This
allows actions like TTL and TPROXY to be used without enabling
traffic shaping.
If you have rules in your tcrules file that you only want processed
when TC_ENABLED is other than 'No', then enclose them in
?IF $TC_ENABLED
...
?ENDIF
If they are to be processed only if TC_ENABLED=Internal, then enclose
them in
?IF TC_ENABLED eq 'Internal'
...
?ENDIF
9) Beginning with Shorewall 4.5.7, the deprecated
/etc/shorewall[6]/blacklist files are no longer installed. Existing
files are still processed by the compiler. Note that blacklist
files may be converted to equivalent blrules files using
'shorewall[6] update -b'.
10) In Shorewall 4.5.7, the /etc/shorewall[6]/notrack file was renamed
/etc/shorewall[6]/conntrack. When upgrading to a release >= 4.5.7,
the conntrack file will be installed along side of an existing
notrack file. When both files exist, a compiler warning is
generated:
WARNING: Both notrack and conntrack exist; conntrack is ignored
This warning may be eliminated by moving any entries in the notrack
file to the conntrack file and removing the notrack file.
11) In Shorewall 4.5.8, the /etc/shorewall[6]/routestopped files were
deprecated if favor of new /etc/shorewall[6]/stoppedrules
counterparts. The new files have much more familiar and
straightforward semantics. Once a stoppedrules file is populated,
the compiler will process that file and will ignore the
corresponding routestopped file.
12) In Shorewall 4.5.8, a new variable (VARLIB) was added to the
shorewallrc file. This variable assumes the role formerly played by
VARDIR, and VARDIR now designates the configuration directory for a
particular product.
This change should be transparent to all users:
a) If VARDIR is set in an existing shorewallrc file and VARLIB is
not, then VARLIB is set to ${VARDIR} and VARDIR is set to
${VARLIB}/${PRODUCT}.
b) If VARLIB is set in a shorewallrc file and VARDIR is not, then
VARDIR is set to ${VARLIB}/${PRODUCT}.
The Shorewall-core installer will automatically update
~/.shorewallrc and save the original in ~/.shorewallrc.bak
13) Previously, the macro.SNMP macro opened both UDP ports 161 and 162
from SOURCE to DEST. This is against the usual practice of opening
these ports in the opposite direction. Beginning with Shorewall
4.5.8, the SNMP macro opens port 161 from SOURCE to DEST as before,
and a new SNMPTrap macro is added that opens port 162 (from SOURCE
to DEST).
14) Beginning with Shorewall 4.5.11, ?FORMAT is preferred over FORMAT
for specifying the format of records in these configuration files:
action.* files
conntrack
interface
macro.* files
tcrules
While deprecated, FORMAT (without the '?') is still supported.
Also, ?COMMENT is preferred over COMMENT for attaching comments to
generated netfilter rules in the following files.
accounting
action.* files
blrules files
conntrack
masq
nat
rules
secmarks
tcrules
tunnels
When one of the deprecated forms is encountered, a warning message
is issued.
Examples:
WARNING: 'FORMAT' is deprecated in favor of '?FORMAT' -
consider running 'shorewall update -D'.
WARNING: 'COMMENT' is deprecated in favor of '?COMMENT' -
consider running 'shorewall update -D'.
As the warnings indicate, 'update -D' will traverse the CONFIG_PATH
replacing FORMAT and COMMENT lines with ?FORMAT and ?COMMENT
directives respectively. The original version of modified files
will be saved with a .bak suffix.
During the update, .bak files are skipped as are files in
${SHAREDIR}/shorewall and ${SHAREDIR}/shorewall6.
15) To allow finer-grained selection of the connection-tracking states
that are passed through blacklists (both dynamic and static), a
BLACKLIST option was added to shorewall.conf and shorewall6.conf in
Shorewall 4.5.13.
The BLACKLISTNEWONLY option was deprecated at that point. A
'shorewall update' ( 'shorewall6 update' ) will replace the
BLACKLISTNEWONLY option with the equivalent BLACKLIST option.
16) In Shorewall 4.5.14, the BLACKLIST_LOGLEVEL option was renamed
BLACKLIST_LOG_LEVEL to be consistent with the other log-level
option names. BLACKLIST_LOGLEVEL continues to be accepted as a
synonym for BLACKLIST_LOG_LEVEL, but a 'shorewall update' or
'shorewall6 update' command will replace BLACKLIST_LOGLEVEL with
BLACKLIST_LOG_LEVEL in the new .conf file.
----------------------------------------------------------------------------
V. N O T E S F R O M O T H E R 4 . 5 R E L E A S E S
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 2 0
----------------------------------------------------------------------------
1) On some distributions, the shorewall-lite and shorewall6-lite
uninstallers could fail with a syntax error.
2) A typographical error in the usage text produced by the -h command
in the compiled firewall script has been corrected.
3) The handling of INITSOURCE is now uniform between the standard and
the -lite installers.
4) Previously, when SYSCONFFILE was specified in shorewallrc, the
installers would always install default.debian rather than the
named file. That has been corrected.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 2 0
----------------------------------------------------------------------------
1) A new TRACK_RULES option has been added to shorewall[6].conf. When
set to 'Yes', this option causes most rules to be tagged with a
comment which gives the configuration file name and line number
that caused the rule to be generated. These comments replace any
comments added via AUTOCOMMENT=Yes and ?COMMENT entries.
Setting this option to 'Yes' requires the 'Comments' capability in
your kernel and ip[6]tables.
2) You may now specify 'OPTIMIZE=All' in shorewall[6].conf to enable
all optimizations. If new optimization levels are added in the
future, OPTIMIZE=All will automatically enable those optimizations.
For completeness, 'OPTIMIZE=None' disables all optimizations.
3) 'list' and 'ls' are now documented alternatives for 'show' in the
CLI programs. /sbin/shorewall and /sbin/shorewall6 now accept 'ck'
as an abbreviation for 'check' and 'co' as an abbreviation for
'compile'.
4) Beginning with this release, if /etc/os-release exists during
installation, then the ID setting in that file will be used to
determine which Linux distribution is running on the system.
5) The 'status' command now obeys the effective VERBOSITY and will
produce no output when the effective VERBOSITY is less than 1.
6) The CLI exit status codes are now documented in the manpages
(shorewall(8), shorewall6(8), etc.).
7) Beginning with this release, the shorewallrc file supports a
SERVICEFILE variable. SERVICEFILE is only relevant when SERVERD is
non-empty, in which case it names the file to be installed as the
product's .service file. If SERVERD is specified but SERVICEFILE is
not, the assumed value of SERVERFILE is $PRODUCT.service.
8) The ${SBINDIR}/shorewall-init utility will now compile
configurations if needed
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 9
----------------------------------------------------------------------------
1) The shorewall-init.service file previously specified an incorrect
path name for the shorewall-init utility
2) Previously, the '-q' option did not suppress all output from
certain commands such as 'check'.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 9
----------------------------------------------------------------------------
1) The 'Limit' action now produces a warning message stating that it
is deprecated in favor of per-IP limiting using the RATE LIMIT
column.
2) Generation of logging rules has been largely re-written to directly
creatre rules in the compiler's internal representation.
Previously, such rules were created in iptables format then
translated into the internal form.
3) A form of 'events' or 'triggers' is now available. Events are
implemented using the ip[6]tables 'recent' match so they are
actually lists of IP addresses with associated timestamps and
packet counts. They may be tested in a number of ways:
- Any matching packets to/from an address ever?
- Any matching packets to/from an address in the last N seconds?
- M or more matching packets to/from an address?
- M or more matching packets to/from an address in the last N
seconds?
See http://www.shorewall.net/Events.html for details and usage
examples.
4) As part of adding event support, the CLI programs now support
two new variants of the 'show' command.
show events
Displays the contents of all events.
show event <event> ...
Displays the contents of the listed events.
Note that a given event can be used for both IPv4 and IPv6. So
/sbin/shorewall and /sbin/shorewall-lite will show entries that are
different from /sbin/shorewall6 and /sbin/shorewall6-lite.
5) Using the event mechanism described above, Shorewall now supports a
form of automatic blacklisting when the number of connection
attempts in a given period of time is exceeded.
See http://www.shorewall.net/Events.html for details.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 8
----------------------------------------------------------------------------
1) This release includes all defect repair from Shorewall 4.5.17.1.
2) The following warning message could be emitted inappropriately when
running shorewall 4.5.17.
The rule(s) generated by this entry are unreachable and have been
discarded
These warnings, which were disabled in Shorewall 4.5.17.1, are now
only emitted where appropriate. The message has also been reworded
to:
One or more unreachable rules in chain <name> have been discarded
The message is issued a maximum of once per Netfilter chain.
3) A problem that could cause the 'trace' compiler option to produce
false error messages or to produce an altered generated firewall
script has been corrected.
4) If the 'Owner Name Match' capability was not available, the
following error message would previously appear during compilation:
iptables: No chain/target/match by that name.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 8
----------------------------------------------------------------------------
1) 'NONE' policies are now instantiated between 'local' zone and zones
other than the firewall. Similarly, 'NONE' policies are
instantiated between 'loopback' zones and zones other than $FW
and other 'loopback' zones.
This provides a cleaner implementation than the one provided in
Shorewall 4.5.17, and one that should be easier to maintain going
forward.
2) James Shubin has contributed a Kerberos macro.
3) A new 'unmanaged' interface option has been added. This option may
be used to define interfaces that allow all traffic to/from the
firewall but that's all. They are not accessible from hosts on
other interfaces nor can traffic from an unmanaged interface be
forwarded to hosts on other interfaces.
The following interface options are mutually-exclusive with
'unmanaged':
- blacklist
- bridge
- destonly
- detectnets
- dhcp
- maclist
- nets
- norfc1918
- nosmurfs
- optional
- routeback
- rpfilter
- sfilter
- tcpflags
- upnp
- upnpclient
Unmanaged interfaces may not be associated with a zone in either
the interfaces or hosts files.
The 'lo' interface may not be unmanaged when there are vserver
zones defined.
4) The value (0 or 1) for the 'routeback' interface option may now
be specified (e.g., 'routeback=0'). This allows overriding the
Shorewall default setting for bridge devices which is
'routeback=1'.
5) The ?SHELL, ?PERL, ?BEGIN SHELL, ?END SHELL, ?BEGIN PERL and ?END
PERL directives are now case-insensitive.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 7
----------------------------------------------------------------------------
4.5.17.1
1) The following warning message may be emitted inappropriately when
running shorewall 4.5.17. The message is no longer issued.
The rule(s) generated by this entry are unreachable and have been
discarded
2) Rules intended to increment nfacct objects would previously be
optimized away when they immediately preceded an unconditional jump
to the same target. Such rules are now retained.
3) A bug in the optimizer in 4.5.17 can cause 'set' and 'geoip'
matches to be dropped. That has been corrected.
4.5.17
1) When INLINE was used in the tcrules file and no target ('-j' part)
is included in the free-form part of the rule, an invalid
iptables rule was generated.
2) Thanks to Roberto Sanchez, many typos in the manpages have been
corrected.
3) A number of issues have been corrected in the Debian and
Redhat/Fedora Shorewall-init SysV init scripts:
a) Settings in ${SHAREDIR}/vardir are now handled correctly.
b) Exit status is now returned correctly.
c) Stale lock files are avoided.
4) When the compiled firewall script is run directly, it no longer
attempts to copy itself onto itself using the 'cp' utility.
5) An optimizer defect that could leave unreferenced chains in the
configuration has been corrected.
6) Unreferenced chains in the IPV6 nat table are now omitted.
7) Rules with trivial exclusion (a single net or ipset preceded by
'!') now generate the iptables matches in the correct
order. Previously, the exclusion match(es) was(were) placed at the
end. This is important in rules that auto-increment nfacct objects.
8) Previously, conntrack helpers were enabled by the 'stop'
command. Now, these helpers are only enabled by the 'clear'
command.
9) Previously, an interface label (e.g., dev:N) could be specified
as the 'physical' interface in /etc/shorewall/interfaces. This
is now disallowed.
10) The Perl function 'shorewall' was not previously exported by
Shorewall::Config, with the result that the function had
to be called as Shorewall::Config::shorewall(...). the function is
now exported and can be called from ?BEGIN PERL blocks as simply
shorewall(...).
11) Previously, two ICMPv6 type names were mis-translated.
address-unreachable was translated to 1/2; should be 1/3
port-unreachable was translated to 1/3; should be 1/4
These translations have been corrected.
12) If a TPROXY IPv6 address was specified in /etc/shorewall6/tcrules
using the [<address>]/vlsm form (e.g.,
'TPROXY(0x100,3129,[2001:470:b:227::44]/64)') then an 'Invalid Address'
error was issued. This has been corrected.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 7
----------------------------------------------------------------------------
1) Route types 'blackhole', 'unreachable' and 'prohibit' are no longer
copied to provider routing tables by default when
USE_DEFAULT_RT=No. You may cause them to be copied by including
'blackhole', 'unreachable' and/or 'prohibit' in the COPY list along
with interface names.
2) Previously, the generated script always added a host route to a
provider's gateway in the provider's routing table. Beginning with
this release, the 'noautosrc' provider option can be used to
inhibit this behavior. 'noautosrc' must be used with care since the
absense of such a route can cause start/restart runtime failures.
3) A '-c' (conditional) option has been added to the 'compile' command.
This option causes compilation to proceed if:
a) The specified (or defaulted) firewall script does not exist; or
b) A file on the CONFIG_PATH (including any directory specified in
the command) is newer than the existing script.
4) A new interface option has been added.
destonly
Causes the compiler to omit rules to handle traffic arriving on
the interface.
5) It is now possible to use 'all+' in the SOURCE and DEST columns of
/etc/shorewall[6]/policy file. It has the same meaning as in the
rules file in that it can override default intra-zone ACCEPT
policies.
6) Beginning with this release, most special handling of 'Auth' (TCP
port 113) has been removed. In particular, the Drop default action
will no longer default to silently REJECTing Auth requests but will
rather simply process them like other tcp packets.
7) Traditionally, Shorewall has treated the loopback interface ('lo')
as follows:
- It deals with firewall-to-firewall, firewall-to-vserver,
vserver-to-firewall, and vserver-to-vserver traffic.
- All filtering is done in the OUTPUT flow; all traffic arriving on
'lo' is silently accepted.
- If no firewall-to-firewall policy or rules are defined, then
a simple ACCEPT rule is also included in the OUTPUT chain for
'lo' (after any vserver-oriented jumps).
Beginning with this release, the handling of firewall-to-firewall
traffic can be altered by adding a zone of type 'loopback'.
- 'loopback' zones must be associated with the loopback device in
the interfaces and/or hosts file.
/etc/shorewall/zones
#ZONE TYPE
loop loopback
/etc/shorewall/interfaces
?FORMAT 2
#ZONE INTERFACE OPTIONS
loop lo ...
When this is done, the ACCEPT jumps for 'lo' in the INPUT and
OUTPUT chains are omitted and replaced with jumps to the loop2fw
and fw2loop (loop-fw and fw-lop) chains respectively. This
provides a model similar to other zones for fireall-to-firewall
traffic.
8) A new 'local' zone TYPE has been added to /etc/shorewall[6]/zones.
A 'local' zone is similar to an 'ipv4' ('ipv6') zone, except that
rules and policies to/from a 'local' zone may only be to/from the
firewall zone and vserver zones.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 6
----------------------------------------------------------------------------
4.5.16.1
1) Version 4.5.16 broke the handling of application helpers when the
CT Target is available. Symptom is messages like the following:
Use of uninitialized value $Shorewall::Config::sillyname in
concatenation (.) or string at
/usr/share/shorewall/Shorewall/Config.pm line 3907.
That has been corrected.
4.5.16
1) Previously, the TOS target and tos match did not work on older
iptables versions such as 1.3.5 in RHEL5-based distributions. That
has been corrected. To correct this problem, a new capability (New
tos Match) was created, so users who utilize a capabilities file
will need to regenerate the file. This applies to all distributions
and not just the older ones.
2) A_ACCEPT! is now recognized as a rules ACTION. Previously, it was
documented in shorewall[6]-rules(5) but was not implemented.
3) Previously, NFACCT accounting rules generated iptables rules with
the matches in the incorrect order. That caused the counters to be
incremented before all of the matches had been checked. Now, the
counter in an NFACCT rule is incremented only if all of the other
matches have been successful.
4) A number of ipset-related modules were incorrectly included in
/usr/share/shorewall/helpers. Those entries have now been removed.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 6
----------------------------------------------------------------------------
1) A new Shorewall6 interface option, 'accept_ra' has been added. The
option value may be set as follows:
0
Do not accept Router Advertisements.
1
Accept Route Advertisements if forwarding is disabled.
2
Overrule forwarding behavior. Accept Route Advertisements even
if forwarding is enabled.
If the option is specified without a value, then value 1 is
assumed.
2) Two new macros have been added:
macro.Xymon contributed by T.J. Yang
macro.VRRP contributed by James Shubin
3) A new INLINE action has been added. This action allows defining
arbitrary iptables rules in the blrules and rules files, as well as
in action and macro bodies.
The basic form of an INLINE rule is as follows:
INLINE <src> <dst> <proto> ... ; <iptables matches and jump>
The <iptables matches and jump> are added to the rule generated by
the contents of the other supplied columns. Given the 'raw' nature
of this action, you should examine the rule generated by the entry
(e.g., 'shorewall check -r') prior to attempting a 'start' or
'restart' operation.
Example:
INLINE $FW net tcp 1234 ; -j SECCTX --name foo
This entry generates the following:
-A fw2net -p 6 --dport 1234 -j SECCTX --name foo
When multiple matches are specified, the compiler will keep them in
the order in which they appear, but they will not necessarily be at
the end of the generated rule. For example, if addresses are
specified in the SOURCE and/or DEST columns, their generated matches
will appear after those specified using ';'.
Note: The following matches will always appear at the front of the
rule in the order shown:
p
dport
sport
icmp-type
icmpv6-type
s
d
i
o
policy
state or conntrack --ctstate
As part of this change, a new 'builtin' action type has been added.
ip[6]tables targets not supported by Shorewall (such as 'SECCTX' in
the example above), must be defined in your
/etc/shorewall[6]/actions file:
Example:
SECCTX builtin
Such builtin actions may only be used in INLINE action invocations;
they may not appear in the ACTION column of a rule.
If you want to use a standard Shorewall-supported action, you can
pass it as a parameter to INLINE.
Example:
INLINE(ACCEPT) $FW net ; -m foo --bar baz
Note that if you include a log level with INLINE and do not pass a
parameter, Shorewall will automatically assume that the parameter
is LOG. That means that you must not specify a log level if you
specify your own rule target with '-j'.
The alternate input format may be used with INLINE, provided that
the {....} form of alternate input is used.
Example:
INLINE $FW net { owner=teastep } ; -j FOO --bar
4) The INLINE action is also supported in the accounting and tcrules
files. In the accounting file, INLINE is treated the same as COUNT
in the with the exception that the freeform iptables input
following the ';' is appended to any matches generated by the
column contents. INLINE is treated similarly in the tcrules file;
that is, the freeform input following ';' must specify the rule
target, if any. In the accounting and tcrules files, INLINE does
not accept a parameter.
5) It is now possible to specify HELPERS=none in
/etc/shorewall[6]/shorewall[6].conf.
This setting has two consequences:
a) All of the *_HELPER capabilities are set to off.
b) No probing of helpers is performed, thus eliminating "xt_CT: No
such helper XXX" warnings when the compiler is probing the
system for capabilities.
6) It is now possible to specify multiple nfacct objects in an NFACCT
accounting rule. Where previously, the following rules were given:
SECTION INPUT
NFACCT(all)
NFACCT(all_in)
SECTION OUTPUT
NFACCT(all)
NFACCT(all_out)
SECTION FORWARD
NFACCT(all)
NFACCT(all_fwd)
It is now possible to do the same thing as follows:
SECTION INPUT
NFACCT(all,all_in)
SECTION OUTPUT
NFACCT(all,all_out)
SECTION FORWARD
NFACCT(all,all_fwd)
To allow a nfobject to be incremented unconditionally, you may
follow the object name with '!' (e.g., NFACCT(all!)). When
'!' is omitted, the object is incremented only if all of the rule's
matches succeed.
7) It is now possible to increment an nfacct counter when a packet
matches an ipset. To do that, simplly include the counter object's
name in parentheses after the ipset specification.
Examples:
a) Increment the mysetcounter nfacct object when a packet's source
matches myset.
+myset[src](mysetcounter)
b) Increment the mysetcounter1 and mysetcounter2 nfacct objects
when a packet's sourcematches myset.
+myset[src](mysetcounter1,mysetcounter2)
b) In an accounting rule, increment the 'all' nfacct object
unconditionally and increment the 'mysetcounter' object only if
the packet source matches myset:
NFACCT(all!) - +myset(mysetcounter)
8) Prior to the availability of BEGIN PERL....END PERL in
configuration files, the only way to execute a chain-specific
script was to create a script file with the same name as the chain
and place it in a directory on the CONFIG_PATH. That facility has
the drawback that the compiler will attempt to run a non-script
file just because it has the same name as a chain. To disable this
facility, a new CHAIN_SCRIPTS option has been added to
shorewall[6].conf. The facility is disabled by setting
CHAIN_SCRIPTS=No. If not specified or specified as the empty value,
CHAIN_SCRIPTS=Yes is assumed for backward compatibility.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 5
----------------------------------------------------------------------------
1) Previously, the Shorewall and Shorewall6 install.sh scripts did two
things wrong with respect to the /etc/shorewall[6]/routes file:
- The existing file was unconditionally removed.
- A skeleton file was not installed when SPARSE was not set in
the shorewallrc file.
Additionally, the installer would remove /etc/shorewall[6]/tcstart.
2) The Shorewall-init install.sh script previously refused to replace
/sbin/ifup-local and /sbin/ifdown-local when those files has been
installed by an earlier version of Shorewall-init.
3) Previously, Shorewall-init's integration with NetworkManager was
incomplete on SuSE with the result that NetworkManager interface
change events were not processed. That has been corrected.
4) Beginning with Shorewall 4.5.8, Shorewall6 has interpreted /32
networks as hosts (/128). /32 IPv6 networks are once again handled
correctly.
5) Using names such as such as EF, BE, CS1, ... for DSCP didn't work
previously. Thibaut Chèze has provided a fix.
6) An incorrect range test prevented DSCP classes CS6 and CS7 from
being accepted. The test has been corrected and those classes are
now allowed.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 5
----------------------------------------------------------------------------
1) Prior to this release, Shorewall has only supported blackhole null
routing in the /etc/shorewall[6]/routes file and in the
NULL_ROUTE_RFC1918 option.
Beginning with this release, Shorewall also supports 'unreachable'
and 'prohibit' routes.
In /etc/shorewall/routes, the GATEWAY column may contain 'blackhole',
'unreachable' or 'prohibit'.
NULL_ROUTE_RFC1918 can also assume those values, in addition to 'Yes'
and 'No' (case-insensitive). 'Yes' is equivalent to 'blackhole' for
backward compatibility.
Please see http://www.shorewall.net/MultiISP.html#null_routing for
details. That section was provided by Mr Dash Four.
2) The 'ifupdown' script installed by Shorewall-init is now
distribution-specific. Previously, the script determined the
distribution at run-time.
3) The ${VARDIR}/undo_<provider>_routing scripts no longer invoke
a Shorewall internal function so that they may be processed
directly by a shell.
4) The compiler now detects multiple entries in
/etc/shorewall[6]/routes with the same PROVIDER and DEST and raises
an error. If an entry for the 'main' table in /etc/shorewall/routes
has one of the RFC1918 networks as the DEST and if
NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the
entry in /etc/shorewall/routes is used.
5) Prior to now, the generated shell script has always used routing
table (provider) numbers rather than names. To make the script more
readable and to aid in debugging, a new USE_RT_NAMES option has
been added to shorewall[6].conf.
When set to 'Yes', Shorewall will use routing table (provider)
names in the generated script rather than table numbers. When set
to 'No' (the default), routing table numbers will be used.
Caution
If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must
insure that all of your providers have entries in
/etc/iproute2/rt_tables as well as the following entries:
255 local
254 main
253 default
250 balance
0 unspec
Without these entries, the firewall will fail to start.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 4
----------------------------------------------------------------------------
1) Previously, a list of IPv6 host addresses where each address was
enclosed in square brackets generated a fatal compile-time error.
Such lists are now handled correctly.
2) The Shorewall 'load', 'reload' and 'export' commands have now been
modified to use a shorewallrc file in a remote system's export
directory. If the directory layout of the remote system differs
from that of the administrative system, then the remote system's
export directory should contains a copy of that system's
shorewallrc file.
3) A syntax error in the Shorewall uninstall.sh file has been
eliminated.
4) The contents of the various configpath files have been corrected.
5) The Shorewall uninstall.sh script previously failed to remove the
macro files from ${SHAREDIR}/shorewall. Those files are now
removed.
6) The 'version -a' command now prints the correct shorewall-core
version when it is run from shorewall6, shorewall-lite and
shorewall6-lite.
7) It is now possible to specify a port or port range along with an
address variable in the ADDRESSES column of /etc/shorewall/masq.
Example:
#INTERFACE SOURCE ADDRESS PROTO DEST
# PORT(S)
eth0 172.20.4.0/24 ð0:44 tcp 45
Previously, this usage generated a fatal compilation error.
8) Port numbers and service names may now be specified with the
UDPLITE protocol.
9) The SUBSYSLOCK setting in the default shorewall6.conf file has been
changed from /var/lock/subsys/shorewall to
/var/lock/subsys/shorewall6.
10) 'blackhole' routes are now copied to provider tables when
USE_DEFAULT_RT=No. Previously, these routes were not copied with
the result that packets could be routed to blackholed addresses.
11) Duplicate interface names could previously appear in a case
statement in the generated script. These duplicates are now
suppressed.
12) Previously, a duplicate 'echo' command could appear in the
generated script. Now only a single command appears.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 4
----------------------------------------------------------------------------
1) Previously, when compiling for export to a Shorewall lite system,
either /etc/shorewall/params was required to be readable by the
user or the remote host's configuration directory was required to
include a (possibly empty) params file.
Beginning with this release, when a directory name is specified in
a 'compile', 'check', 'load', 'reload' or 'export' command and the
user is not root (euid is not zero), then /sbin/shorewall and
/sbin/shorewall6 will only look in the specified directory for the
params and shorewall[6].conf files.
2) The BLACKLIST_LOGLEVEL option has been renamed BLACKLIST_LOG_LEVEL
to be consistent with the other log-level option
names. BLACKLIST_LOGLEVEL continues to be accepted as a synonym for
BLACKLIST_LOG_LEVEL, but a 'shorewall update' or 'shorewall6
update' command will replace BLACKLIST_LOGLEVEL with
BLACKLIST_LOG_LEVEL in the new .conf file.
3) Rules in the ESTABLISHED section are now placed in separate
chains. Rules for traffic from zone Za to zone Zb and placed in
^Za2Zb or ^Za-Zb, depending on the setting of
ZONE2ZONE. Previously, they were placed in Za2Zb (Za-Zb).
4) When the effective VERBOSITY is 2, the compiler now produces a
report as follows:
Configuration uses these capabilities ('*' denotes required):
ADDRTYPE
ARPTABLESJF
AUDIT_TARGET*
COMMENTS
CONNTRACK_MATCH
CT_TARGET
ENHANCED_REJECT
EXMARK
FTP_HELPER*
FWMARK_RT_MASK
GOTO_TARGET
IPSET_MATCH*
IRC_HELPER*
LOG_TARGET*
MANGLE_ENABLED
MANGLE_FORWARD
MARK*
MULTIPORT
NETBIOS_NS_HELPER
NEW_CONNTRACK_MATCH
NFACCT_MATCH*
NFLOG_TARGET*
RAW_TABLE*
RPFILTER_MATCH*
XMULTIPORT*
Shorewall configuration verified
5) While we understand the evils of NAT, it is required for proper
failover handling in IPv6 multi-ISP configurations. To accommodate
that limited use case, Shorewall6 now supports basic Masquerade,
SNAT and DNAT.
This feature requires a 3.7 or later kernel and iptables 1.4.17 or
later.
Note: The current Fedora 18 3.4.7 kernel does not support IPv6
MASQUERADE, so you must specify one or more addresses in the
ADDRESSES column. To approximate masquerade when running that
kernel, use an address variable in the ADDRESS column.
Example /etc/shorewall6/masq:
INTERFACE SOURCE ADDRESS
p3p1 2001:470:b:227::0/24 &p3p1
DNAT rules that specify a port number in the DEST column, must
enclose the server address (if any) in square brackets.
Example:
ACTION SOURCE DEST PROTO PORTS
DNAT net fw:[2001:470:b:227::2]:22 tcp 1022
6) 'blackhole' routes may now be defined in /etc/shorewall[6]/routes.
Simply place 'blackhole' in the GATEWAY column and leave the DEVICE
column empty.
7) The iptables/ip6tables 'multiport match' feature allows for
matching either the source or the destination port against a list
of port numbers. Up to this time, Shorewall did not allow users to
take advantage of that capability.
Beginning with this release, placing an equal sign in a SOURCE
PORT(S) column is interpreted as 'match the list specified in the
DEST PORT(S) column against both the packet source and destination
port in the packet. If there is any match, then the packet matches
the rule.
Example from the accounting file:
#ACTION CHAIN SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(S)
COUNT - br0 - tcp 80 =
This rule matches all TCP packets entering through br0 where either
the source port or the destination port is 80.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 3
----------------------------------------------------------------------------
1) If a chain consisted of a single RETURN rule, optimize level 4
would handle it incorrectly by moving the RETURN rule to the
chain(s) that jumped to the single-rule chain. The optimizer now
simply eliminates the chain and rule.
As part of this change, the optimizer now deletes trailing RETURN
rules from chains.
2) If a default inline action was specified with parameters, the
compiler would fail with an internal error.
3) The compiler was mis-handling simple arithmetic expressions
consisting of a single number, evaluating the number as '' rather
than as its numberic value.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 3
----------------------------------------------------------------------------
1) A new DEFER_DNS_RESOLUTION option has been added to shorewall.conf.
Up to this time, when a DNS name appears in the SOURCE, DEST or
ORIGINAL DEST column of a configuration file, the compiler verifies
that the name can be resolved and then passes the name on to the
generated script. This means that ip[6]tables-restore must resolve
the name when the script runs.
When DEFER_DNS_RESOLUTION=Yes (the default) this old behavior is
retained. When DEFER_DNS_RESOLUTION=No, the compiler resolves the
name and uses the address(es) in the generated script.
2) The '@' Shorewall variables are now writable using the ?SET directive.
The variables are now also used when generating the contents of
--log-prefix in logging rules. Within an action body, the two
fields in the --log-prefix are:
@chain -- Existing variable.
@disposition -- New variable.
When either of these are undefined or empty, the compiler uses
the same value as previously.
When a non-inlined action is entered, @disposition is given the
empty value. When an inline action is entered, @disposition is not
altered.
Also added is a @caller variable which names the chain or action
which invoked the action.
When any action is exited, the variables revert to their values
when the action was entered.
When RESET, the named Shorewall variables are not removed from the
variable table but are rather set to the empty value.
3) Optimize level 8 now makes multiple passes of each table.
4) There are now two new sections in the rules file:
INVALID
Allows definition of rules to be applied to packets in the
INVALID connection state.
UNTRACKED
Allows definition of rules to be applied to packets in the
UNTRACKED connection state (due to entries in the conntrack
file).
The implementation of these sections is modeled after that of the
RELATED section. There are options in shorewall.conf
(shorewall6.conf) that control the disposition and logging of
packets that fail to match any of the rules in the section.
INVALID_DISPOSITION
Valid values are CONTINUE, DROP, REJECT, and A_DROP.
The default is CONTINUE, which provides compatibility with
earlier releases (the packets are subject to the rules in
the NEW section).
INVALID_LOG_LEVEL.
Determines logging of packets handled by
INVALID_DISPOSITION. Empty by default (no logginig).
UNTRACKED_DISPOSITION
Valid values are CONTINUE, ACCEPT, DROP, REJECT, A_ACCEPT
and A_DROP.
The default is CONTINUE, which provides compatibility with
earlier releases (the packets are subject to the rules in
the NEW section).
UNTRACKED_LOG_LEVEL.
Determines logging of packets handled by
NOTRACK_DISPOSITION. Empty by default (no logging).
The new order of sections in the rules files is:
ALL
ESTABLISHED
RELATED
INVALID
UNTRACKED
NEW
5) There are now 'Related', 'Untracked', 'Established' and 'New'
actions that match packets in the RELATED, UNTRACKED, ESTABLISHED
and NEW states respectively.
These actions are in-line and have a single parameter that
specifies the action to be taken. The action may be anything that
is valid in the ACTION column of the rules file.
As part of this change, action.Invalid, action.NotSyn and
action.RST are also inline and can accept an arbitrary action as an
argument. The 'audit' parameter, while still accepted, is
deprecated in favor of passing 'A_ACCEPT' etc. directly to the
inline.
The TCPFlags action may also now be inlined, although it is not
inlined by default.
6) The preceding enhancement required infrastructure for allowing
BEGIN PERL...END PERL to function in the body of an inline action.
use Shorewall::Rules;
perl_action_helper( $target, $matches )
$target is the target of the rule and may include log level and
tag (e.g, 'DROP:info:foo').
$matches is a string containing one or more ip[6]tables
matches.
Example: "-m conntrack --state ESTABLISHED".
The function returns true.
This function may be called in both inline and regular actions. In
an inline action, the matches from the invoking rule (SOURCE, DEST,
etc) are applied (in addition to the match(s) passed). In a regular
action only the passed matches are applied to the rule.
7) To allow finer-grained selection of the connection-tracking states
that are passed through blacklists (both dynamic and static), a
BLACKLIST option has been added in shorewall.conf and
shorewall6.conf.
The BLACKLISTNEWONLY option is now deprecated. A 'shorewall update'
( 'shorewall6 update' ) will replace the BLACKLISTNEWONLY option
with the equivalent BLACKLIST option.
8) The shorewallrc.archlinux file now assumes that systemd is
installed (Evangelos Foutras).
9) When the 'CONNTRACK match' capability is present (as it is in all
current distros), optimize level 16 now combines adjacent rules
that differ only in the conntrack states matched.
10) The legacy 'dropInvalid' and 'allowInvalid' builtin actions have
been converted to inline actions that invoke the Invalid action.
11) Parameters may now be omitted in action invocations. The following
two invocations are equivalent:
ACTION(-,foo,-,-)
ACTION(,FOO,,)
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 2
----------------------------------------------------------------------------
1) This release contains the defect repairs from Shorewall 4.5.11.1
and 4.5.11.2.
2) Two defects associated with 'update -D' have been corrected.
- shorewall.conf.bak is no longer deleted.
- files that are not changed no longer have their mtime updated.
3) Inline actions in the RELATED and ESTABLISHED sections now work
correctly.
4) The 'dropInvalid' built-in function now works correctly.
5) The compiler now generates an error when a protocol list is used in
a context where only a single protocol name/number is accepted.
6) The generated script now correctly deletes Traffic Control
configurations when CLEAR_TC=Yes. Previously, the configurations on
interfaces with a '@xxxxxx' suffix in their names were not cleared.
7) Under very rare circumstances, optimize level 4 could leave a rule
that jumped to a non-existant chain, causing iptables-restore to
fail.
8) If an error was raised while compiling a default action, the
following Perl diagnostic could appear and the Shorewall error
message would not be printed.
9) It is once again possible to use DNS names in rules without an
interface name.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 2
----------------------------------------------------------------------------
1) The rules compiler has traditionally issued a warning when the
version of /etc/shorewall[6]/capabilities is less than the version
supported by the compiler. This warning may be suppressed by
setting the new option 'WARNOLDCAPVERSION' to 'No' in
shorewall[6].conf.
2) The compiler now ignores '-m comment' differences when deleting
duplicate rules under optimization level 16.
3) Support has been added for the FQ CODEL (Fair-queuing
Controlled-delay) queuing discipline. See shorewall-tcclasses (5)
and shorewall6-tcclasses (5) for details.
4) Support for arptables has been added to Shorewall and Shorewall
Lite.
- Both classic arptables and arptables_jf (fork maintained by Jay
Fenlason)
- There is now an ARPTABLES option in the shorewall.conf file to
specify the path to the arptables binary.
- An arprules file has been added to allow specification of
arptables rules. See shorewall-arprules (5) for details.
- A 'show arptables' command has been added to show the active
arptables rules.
- arptables rules are saved and restored by the save and restore
commands if the new option SAVE_ARPTABLES is set to Yes in
shorewall.conf.
- arptables rules are displayed in the 'dump' command.
As part of this change, a new capability ('Arptables JF') has been
added. If you use a capabilities file, you should regenerate it
after installing this version.
5) The interpretation of the log tag when LOGTAGONLY=Yes is changed.
Previously, the log tag replaced the chain name in the generated
log prefix. Now, the tag is interpreted as a chain name and a
disposition separated by a comma.
So this rule:
LOG:info:foo,bar
will generate the following log prefix when using the default
LOGFORMAT setting:
Shorewall:foo:bar:
Similarly,
LOG:info:,bar net fw
will generate
Shorewall:net2fw:bar:
6) Rules generated by the RELATED section of the rules file are now in
separate chains. For each pair of zones (za,zb), RELATED
connections are handled by a chain whose name is "+za2zb"
(ZONE_SEPARATOR=2) or "+za-zb" (ZONE_SEPARATOR='-'). This results
in only one state match to jump to the new chain rather than a
state match for every rule in the section.
7) Protocol lists are now supported in the PROTO columns of the
following additional files:
accounting
conntrack
masq
secmarks
stoppedrules
tcfilters
tcpri
tcrules
8) When an terminating rule is added to the end of a chain, the
Compiler now marks that chain as 'complete' and inhibits the
appending of any additional rules.
A terminating rule is one that has no matches and either uses '-g'
(goto) or is a jump to one of the following:
ACCEPT
DROP
RETURN
QUEUE
CLASSIFY
CT
DNAT
MASQUERADE
NETMAP
NFQUEUE
NOTRACK
REDIRECT
RAWDNAT
RAWSNAT
REJECT
SAME
SNAT
TPROXY
A chain with no RETURN statements and whose last rule is
terminating.
Additionally, when optimize level 4 is selected, chains that
contain a single RETURN rule are optimized away.
9) Eric Teeter has contributed macro.ActiveDir, a macro that handles
Samba 4 active directory.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 1
----------------------------------------------------------------------------
4.5.11.2
1) Corrected fix 2 from 4.5.11.1.
4.5.11.1
1) Beginning with Shorewall 4.5.10, if the name of an optional
interface contained one or more characters that are not valid in a
shell function name, then the generated script would fail with a
"syntax error: bad function name" shell diagnostic.
That problem has been corrected so that a valid function name is
generated.
2) The kernel modules supplied by xtables-addons are now listed in the
modules.xtables files. They were previously omitted.
4.5.11
1) This release includes the defect repair from Shorewall 4.5.10.1.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 1
----------------------------------------------------------------------------
1) This release expands upon the concept of 'Shorewall Variables'
that was introduced in 4.5.10 with the creation of '@0' in SWITCH
columns. Beginning with 4.5.10, '@0' (or '@{0}') in a SWITCH column
expands to the name of the current chain.
In this release, the Shorewall variables @loglevel and @logtag
are added. These variables are only available within action bodies
(both regular and in-line).
Their contents are:
@loglevel
The log level specified when the action was invoked. If no
level was specified, @loglevel expands to 'none'.
@logtag
The log tag specified when the action was invoked. If no tag
was specified, @logtag expands to an empty string.
@1, @2, ...
Same as $1, $2, ...
Additionally, @chain has been added as a synonym for @0. Remember
that, unlike $0, non-alphanumeric charaters other than '_' have
been removed from @0.
2) Action variables ($0, $1,...$n) and Shorewall variables are now
available in ?IF and ?ELSIF directives.
3) A 'nolog' option has been added to /etc/shorewall[6]/actions. This
option causes the compiler to forego adding the log level and log
tag from the action invocation to those rules within the body that
do not specify a tag and/or level.
3) An 'IGNOREUNKNOWNVARIABLES' option has been added to
/etc/shorewall[6]/shorewall[6].conf. When set to 'Yes', this option
instructs the compiler to expand unknown shell variables and
action parameters to an empty string rather than raising an error.
4) ?SET and ?RESET directives are now available:
?SET <variable> <value>
?RESET <variable>
To cater to both Shell and Perl programmers, the <variable> may
be entered with or without leading '$'.
The ?SET command sets the named <variable> to the specified
<value> where <value> is a Perl-compatible expression.
The ?RESET command deletes the named <variable> from the compiler's
variable table.
Shorewall variables (@chain, @loglevel,...) and action parameters
($1, $2,...) are read-only and their values may not be changed
(although action parameter values may be changed using Embedded
Perl).
5) This release introduces user-defined address variables. Address
variables are used at run-time rather than at compile-time. Prior
to this release, two types of address variables were available:
&<interface> Expands to the primary IP address of
<interface>
%<interface> Expands to the IP address of the default
gateway out of <interface>
The two new types added in this release are distinguished by the
use of "{....}".
&{<variable>} Address contained in run-time variable
<variable>. The named shell variable must
contain a valid IP address, either from the
generated script's environment or from having
been set in the generated script's 'init'
extension script. If the variable is empty or
if its contents are not a valid IP address, an
error is raised and the state of the firewall
is not changed.
%{<variable>} Address contained in run-time variable
<variable>. If the named variable is empty,
the generated script sets it to the all-zeros
address (0.0.0.0 in IPv4 and :: in IPv6). When
this variable appears in a SOURCE or
DESTINATION column of any configuration file,
or if it appears in the ADDRESSES column of
the masq file, then no rule is generated when
the address variable is empty. Otherwise, the
rule is generated with the all-zeros address
replacing the variable. As above, if the
variable is non-empty and if it does not
contain a valid IP address, an error is raised
and the firewall state is unchanged.
6) The output of 'show [-f] capabities' is now sorted to make
individual capabities easier to find.
7) Beginning with this release, ?FORMAT is preferred over FORMAT for
specifying the format of records in these configuration files:
action.* files
conntrack
interface
macro.* files
tcrules
While deprecated, FORMAT (without the '?') is still supported.
Also, ?COMMENT is preferred over COMMENT for attaching comments to
generated netfilter rules in the following files.
accounting
action.* files
blrules files
conntrack
macro.* files
masq
nat
rules
secmarks
tcrules
tunnels
When one of the deprecated forms is encountered, a warning message
is issued.
Example:
WARNING: 'FORMAT' is deprecated in favor of '?FORMAT' -
consider running 'shorewall update -D'.
As the warning indicates, 'update -D' will traverse the CONFIG_PATH
replacing FORMAT and COMMENT lines with ?FORMAT and ?COMMENT
directives respectively. The original version of modified files
will be saved with a .bak suffix.
During the update, .bak files are skipped as are files in
${SHAREDIR}/shorewall and ${SHAREDIR}/shorewall6.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1 0
----------------------------------------------------------------------------
1) This release includes all defect repair included in
4.5.9.1-4.5.9.3.
2) Under rare circumstances, optimize level 16 could produce invalid
iptables-restore input which would cause start/restart to fail.
3) Before this release, the 'started' script was run prior to copying
the temporary script file (e.g., /var/lib/shorewall/.start) to
/var/dir/shorewall/firewall. If the script failed, the copy would
not take place even though the firewall had started
successfully. The script is now copied before running the 'started'
script.
If you compare the script generated by this release with one
generated by a prior release, We suggest that you ignore whitespace
changes (e.g., use the '-w' option in diff); that way, you can see
the actual change more clearly.
4) AUTOCOMMENT=No now works correctly; previously, it behaved the same
as AUTOCOMMENT=Yes.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1 0
----------------------------------------------------------------------------
1) Shorewall now treats optional non-provider interfaces in a manner
similar to provider interfaces.
- They may have entries in /etc/shorewall/routes.
- They may be enabled/disabled using the 'enable' and 'disable'
commands.
- Shorewall-init will simply enable an optional interface when it
comes up and disable it when it goes down.
2) The /etc/shorewall/secmarks and /etc/shorewall6/secmarks files now
support the UNTRACKED state. See the manpages for details.
3) The /etc/shorewall/conntrack and /etc/shorewall6/conntrack files
now support a DROP target.
It is now possible to specify 'all-' in the SOURCE column which
generates rules for all zones that are outside of the firewall
itself.
4) A SWITCH column has been added to the /etc/shorewall/conntrack and
/etc/shorewall/conntrack6 files.
5) In a SWITCH column, the character '@' is replaced by the chain
name (non-alphanumeric characters other than '-' and '_' are
suppressed).
6) An AUDIT action has been added to the /etc/shorewall/rules and
/etc/shorewall6/rules.
7) The audited targets (A_ACCEPT, A_DROP, etc.) are now supported in
/etc/shorewall6/rules.
8) An additional format (3) has been added to the conntrack file. In
this format, zone names are not used in the SOURCE column; rather,
a suffix in the ACTION column determines which raw-table chain the
generated Netfilter rule will be placed in. See the manpages for
details.
9) A ULOG ACTION has been added to /etc/shorewall/rules.
10) Within an action body, the variable $0 now expands to the action
chain name (including leading '%' if present).
11) 'In-line' actions are now available. An action is designated as
in-line within /etc/shorewall[6]/actions; that file has a
new OPTIONS column and specifying 'inline' in that column
designates the action as in-line.
Normally, actions are expanded into their own chain with a
unique chain being created for each unique invocation (considering
log level, tag and parameters). An in-line actions is expanded
inline within the chain that invokes it. In that sense,
in-line actions are very similar to macros.
In-line actions differ from macros in several ways:
a) A zone may be specified in the SOURCE and DEST columns of a
macro, while zone names are disallowed in these columns within
an in-line action (same as in a regular action).
b) The name of the current chain is available in $0 within the body
of an in-line action (also within a regular action beginning with
Beta 3).
c) In-line actions accept multiple parameters which are available
in$1, $2, etc (as they are in a regular action).
d) PARAM has no special meaning in the body of an in-line action
($1 serves the same purpose in an in-line action).
e) Only FORMAT 2 is available in an in-line action.
f) In-line actions must be defined in
/etc/shorewall[6]/actions. Those files have been extended to
include an OPTIONS column. The only option currently supported
is 'in-line'.
In-line actions differ from normal actions in that:
a) Obviously, they are expanded in-line like a macro rather than
being in their own chain. That means that columns in the
invocation are merged with those in the action body in the same
way as they are in a macro.
b) When AUTOCOMMENT=Yes, each generated rule is commented with the
name of an in-line action.
c) Within an in-line action, ?BEGIN PERL ... ?END PERL does not
have access to the special features available in action a normal
action body.
The compiler allows overriding the setting of 'inline' on the
Shorewall standard actions within
/etc/shorewall[6]/actions. Beware, however, that some of them
don't work when in-lined so the compiler will ignore the 'inline'
option with a warning for those actions:
Broadcast
DropSmurfs
Invalid
NonSyn
RST
TCPFlags
12) In SWITCH columns, the named switch can now be initialized by the
'start' command (other commands do not change switch values).
Initialization is accomplished by adding '=0' or '=1' to the
switch name.
Example (using alternative rule column specification):
#ACTION SOURCE DEST ...
NFLOG all all ; switch:logall=1
The above will cause the 'logall' switch
(/proc/net/nf_condition/logall) to be initialized to 1 (on). Note
that netfilter provides no atomic way to define and initialize a
switch so the loading of the ruleset and the initialization of the
switches are distinct operations.
13) Also in SWITCH columns, the name of the current Netfilter chain
will be substituted for '@0' and '@{0}'.
Example (using alternative rule column specification):
#ACTION SOURCE DEST ...
NFLOG net fw ; switch:@{0}_logall
The name of the switch will be 'net2fw_logall'.
Note 1: Non-alphanumeric characters other than '_' and '-' will be
deleted from the chain name before substitution.
Note 2: The chain name substituted is the one to which the rule is
initially added. The rule may end up in a different chain due to
optimization.
14) Optimization level 16 now suppresses duplicate rules in chains from
all tables (it previously only suppressed duplicates in the 'raw'
table).
Non-adjacent rules containing 'mark', 'connmark', 'dscp', 'ecn',
'set', 'tos' or 'u32' matches are not suppressed:
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 9
----------------------------------------------------------------------------
4.5.9.3
1) References to the obsolete USE_ACTIONS option have been removed
from the manpages.
2) NFLOG has been documented for some time as a valid ACTION in the
rules files but support for that action has never been implemented
until this release.
3) The Checksum Target capability detection in the rules compiler was
broken with the result that the presence of the capability was not
detected.
4) If an interface named in the INTERFACE column was not defined in
tcdevices and if the REDIRECTED column for that entry was
non-empty, then compile-time Perl diagnostics were generated and an
invalid firewall script was generated.
5) When LOAD_HELPERS_ONLY=No, the 'compile' command previously left
behind a temporary chain in the raw table.
6) Under very rare circumstances involving exclusion in multiple
Netfilter tables, optimization level 8 could result in
start/restart failure or jumps to the wrong exclusion chain.
7) 4.5.9.2 broke multi-ISP on RHEL5-based systems. This release
includes a patch from Tuomo Soini that corrects the problem.
4.5.9.2
1) Previously, the rules in the 'routemark' chain did not specify a
mask in the MARK target. While a mask isn't strictly necessary in
those rules, one has been added to ally fears of those who read the
generated ruleset.
Note: The 'routemark' chain is used to apply provider marks to
packets received from 'track' provider interfaces. It is traversed
early in the mangle PREROUTING chain when no other marks have yet
been applied to the packet.
2) If exclusion was used with TPROXY in the tcrules file, an invalid
iptables ruleset was generated causing start and restart commands
to fail when running iptables-restore.
3) Previously, when the name of provider was the same as it's
associated interface, the generated script contained a syntax
error.
4.5.9.1
1) Previously, using a wildcard interface name in a rule would result
in this error:
ERROR: Invalid ipset name (ppp+) : ...
Such entries are now handled correctly.
2) The shorewall-masq(5) manpage incorrectly stated that the SOURCE
column may use exclusion with an interface name (e.g.,
eth1:!1.2.3.4). That hasn't been the case for some time. To
accomplish the same thing, do this:
eth0 1.2.3.4 NONAT
eth0 eth1
Note: Using an interface name in the SOURCE column is deprecated.
3) Previously, if a MARK was specified for a tc class that explicitly
specified a class number, the following spurious warning message
was issued:
WARNING: Class NUMBER ignored --
INTERFACE <name> does not have the 'classify' option
That warning message is no longer issued.
4) With Shorewall 4.5.9, there were issues when the ipset utility was
not installed, some of which prevented Shorewall from starting.
4.5.9
1) This release contains all defect repair from Shorewall 4.5.8.2.
2) A typo has been corrected in the shorewallrc.default file.
3) Beginning with Shorewall 4.5.7.2, Shorewall unconditionally
restores the provider mark as the first rule in the mangle table
OUTPUT and PREROUTING chains. Previously, the provider mark was
restored only if it was non-zero.
It has become clear that some users need it one way while others
need it the other way. To resolve this issue, a RESTORE_ROUTEMARKS
option has been added to shorewall.conf and shorewall6.conf. When
this option is set to Yes (the default), the 4.5.7.2 approach is
used (always restore the mark, even if it is zero); when it is set
to No, the pre-4.5.7.2 behavior is retained (only restore the mark
if it is non-zero).
4) Two error messages produced by the RST action have been
corrected. They previously referred to errors in the NotSyn action
rather than RST.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 9
----------------------------------------------------------------------------
1) Prior to this release, if a dynamic zone was associated with more
than one interface, then Shorewall created a separate ipset for
each interface. This meant that multiple 'add' and 'delete'
commands might be required to change the zone composition.
This release introduces a 'dynamic_shared' zone option. When that
option is specified, a single ipset is generated regardless of the
number of entries the zone has in the hosts file.
The 'dynamic_shared' option may only be specified in the OPTIONS
column of the zones file.
The syntax of the 'add' and 'delete' commands is changed for zones
having the 'dynamic_shared' option:
add <zone> <address>[,<address> ... ]
delete <zone> <address>[,<address> ... ]
Example:
shorewall add direct 172.20.1.99
The syntax for 'add' and 'delete' for zones not having the
'dynamic_shared' option is unchanged.
2) Puppet and Teredo macros have been contributed by Paul Gear.
3) The 'show' command now supports a -b (brief) option that suppresses
listing of rules that have zero packet count and omits chains that
have no rules listed (Paul Gear).
4) A CHECKSUM action has been added to the tcrules files. This action
computes and fills in the checksum in a packet that lacks one.
This is particularly useful if you need to work around old
applications, such as dhcp clients, that do not work well with
checksum offloads, but you don't want to disable checksum offload
in your device.
As part of this change, a new 'Checksum Target' capability has been
added, so if you use a capabilities file, it needs to be
re-generated after you install this release.
5) The 'shorewall6 show routing' command now sorts the contents of
each routing table in the same way as 'shorewall show routing'.
6) It is now possible to specify a mark range in the ACTION column of
the tcrules file. This causes the generated ruleset to assign marks
in the range in round-robin fashion. As part of this change, a
STATE column is also added that allows marks to be assigned only to
packets that are in one of the specified states (NEW, RELATED,
ESTABLISHED, etc.). Specifying NEW in this column along with
a range in the ACTION column allows for load-balancing SNAT rules
over a number of different external addresses.
Example:
/etc/shorewall/tcrules
#ACTION SOURCE DEST ...
1-3:CF eth1 172.20.1.0/24 ; state=NEW
/etc/shorewall/masq
#INTERFACE SOURCE ADDRESS ...
eth0 192.168.1.0/24 1.1.1.1 ; mark=1:C
eth0 192.168.1.0/24 1.1.1.5 ; mark=2:C
eth0 192.168.1.0/24 1.1.1.9 ; mark=3:C
Specifying a mark range require the 'Statistics Match' capability
in your iptables and kernel.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 8
----------------------------------------------------------------------------
4.5.8.2
1) The 'shorewall show' command previously produced no output. That
command now works with ipset versions 4 and later.
2) The change in 4.5.8.1 that enabled industry-standard IPv4 address
representation broke the ability to place IP ranges or IPv6 ipsets
in the hosts file. Those abilities have been restored.
3) The treatment of the SYSTEMD and INITFILE shorewallrc variables has
been inconsistent. The -lite installers ignore INITFILE when
SYSTEMD is specified, while the other installers do not. Now,
the -lite installers install the .service file if SYSTEMD is
specified and they install the sysv-init script if INITFILE is
specified. That is consistent with the behavior of the other
installers.
4.5.8.1
1) With ipset version 5 or later installed, the Shorewall 'add'
command failed with this error message:
Zone <zone>, interface <interface> does not have a dynamic
host list"
2) When generating ipset names for dynamic zones, the compiler was
dropping dashes ('-') from the interface name and adding a
unique suffix. For example the ipset for zone 'foo' and interface
'bar-if' might be 'foo_barif_1'. Dashes are now retained so that
the generated set name in this example will be 'foo_bar-if'. This
change also allows the 'add' and 'delete' commands to work
correctly when the interface name contains one or more dashes.
Although dash is documented as being an accepted character in ipset
names, names containing a dash would generate an error in some
contexts. That has also been corrected.
3) In 4.5.8, a shell syntax error occurred when installing on a system
running systemd. That error has been eliminated.
4.5.8
1) This release includes the defect repair from Shorewall 4.5.7.1.
2) The restriction that TTL and HL tcrules could only be placed in the
FORWARD chain prevented these rules from being used to hide a router
from traceroute[6]. It is now allowed to place these rules in the
PREROUTING chain by following the specification with ':P' (e.g.,
'TTL(+1):P').
3) Previously, the macro.SNMP macro opened both UDP ports 161 and 162
from SOURCE to DEST. This is against the usual practice of opening
these ports in the opposite direction. Beginning with this release,
macro.SNMP opens port 161 from SOURCE to DEST as before, and a new
SNMPTrap macro is added that opens port 162 (from SOURCE to
DEST).
4) Previously, when compiling for export, both
/etc/shorewall/shorewall[6].conf and the shorewall[6].conf in the
configuration directory were processed. Now, only the copy in the
configuration directory is processed.
5) The 'iptables_raw' module has been added to the modules.essential
file.
6) Several corrections have been made to the Fedora/Redhat SysV init
script for Shorewall-init.
7) The <directory> parameter to the 'try' command is now documented in
the shorewall(8) and shorewall6(8) manpages.
8) Some redundant interface-option rules have been removed in
configurations with multiple zones configured on a single
interface.
9) Previously, when compiling for export, the compilation would fail
if the setting of SHAREDIR in the firewall's shorewallrc was
different from the setting on the admin system. Such compilations
now succeed.
10) Earlier versions of the compiler accepted ":" as the sole contents
of a USER/GROUP column with the result that iptables-restore
failed. This incorrect usage now generates a compile-time error.
11) The 4.5.7 Shorewall compiler unconditionally probes for all
helpers, causing their corresponding modules to be loaded. Now,
this probing will only occur when LOAD_HELERS_ONLY=No.
12) The 'conntrack' files released in Shorewall 4.5.7 contained an
incorrect control port number for PPTP (1729 vs. 1723). The port
number has been corrected.
13) A typo in the PPtP macro has been corrected.
14) The compiler previously accepted TTL(-0) and HL(-0) in the ACTION
column of tcrules, leading to a failure of the generated script. +0
was also accepted with the same result. Now, this incorrect usage
is flagged as an error.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 8
----------------------------------------------------------------------------
1) This release attempts to alleviate the confustion that results
from different usage of the VARDIR variable name.
Beginning with Shorewall 4.5.2, 'VARDIR' became a variable in the
shorewallrc file with the default value '/var/lib'. This was at
odds with the usage of VARDIR in /etc/$product/vardir, where the
variable VARDIR holds the state directory for a particular product
(e.g., /var/lib/shorewall). This latter usage is reflected in the
Shorewall code which has always used VARDIR to hold the individual
product's state directory.
To eliminate this issue going forward, a VARLIB variable has been
added to shorewallrc to assume the role previously filled by
VARDIR, while VARDIR now defaults to '${VARDIR}/${PRODUCT}'.
When a pre-4.5.8 shorewallrc file is present, VARLIB is set to
${VARDIR} and VARDIR is set to ${VARLIB}/${PRODUCT}. If VARLIB is
set in the shorewallrc file and VARDIR is not, then VARDIR also
defaults to ${VARDIR}/${PRODUCT}. When using the tarball installer,
the existing shorewallrc file (~/.shorewallrc or
${SHAREDIR}/shorewallrc) will be updated and the original will be
saved as shorewallrc.bak.
Note that since there is only a single shorewallrc file on a
system, the only means for overriding the ${VARLIB}/${PRODUCT}
default setting for VARDIR is still the /etc/$product/vardir file.
2) A new 'stoppedrules' file has been added and the 'routestopped'
file is now deprecated. The new file is processed when
'routestopped' does not exist or is empty.
See stoppedrules(5) for details about the new file.
3) When the -e option (compile for export) is specified in the 'check'
and 'compile' commands, the current working directory is now
automatically included in the CONFIG_PATH.
4) When the -e option is specified in a 'compile' command that
specifies no script name, the default is now 'firewall' in the
current working directory. In other words:
shorewall compile -e
creates 'firewall' and 'firewall.conf' in the current working
directory. This is consistent with the behavior of the 'load' and
'reload' commands.
5) Multiple UID/GIDs separated by commas may now be given in the
USER/GROUP column of the rules files.
6) A warning message is now issued if the 'blacklist' option is
specified for a zone (the 'blacklist' option has been deprecated
for several releases).
7) A PRIORITY column has been added to the tcfilter files. See
shorewall-tcfilters(5) and shorewall6-tcfilters(5) for details.
As part of this change, the method of assigning priorities to
filters where the PRIORITY is not specified has changed.
Previously, all ipv4 filters were assigned priority 10 while
all ipv6 filters were assigned priority 11. Now, for each device,
the compiler maintains a "high-water priority" that has an initial
value of 0. When a filter has no priority specified, the high-water
priority is incremented by 1 and assigned to the filter. When a
priority greater than the high-water priority is entered in the
PRIORITY column, the high-water priority is set to the specified
priority.
An attempt to assign a priority value greater than 65535
(explicitly or implicitly) raises an error.
8) It is now possible to explicitly assign priorities to
classification filters created by shorewall for the following:
- Filter that classifies packets based on their firewall mark
value.
- Filter that classifies ACK packets via the 'tcp-ack' class
option.
- Filter that classifies packets based on TOS value.
Example:
#DEVICE MARK RATE: CEIL PRIORITY OPTIONS
# DMAX:UMAX
eth0 1:50 5*full/10 full 1 tcp-ack:15,\
tos-minimize-delay:20
In this example, the classifier filters would be evaluated in this
order:
- tcp-ack (priority 15)
- tos-minimize-delay (priority 20)
- Mark value 1 (priority 50)
In other words, the filters are evaluated in ascending priority
order. If one filter doesn't match, the packet is passed to the
next filter.
See shorewall-tcclasses(5) and shorewall6-tcclasses(5) for
additional information.
9) The PRIORITY column in the tcclasses file is now optional for HFSC
classes. If that priority is omitted, then an explicit priority
must be specified for the MARK value and for the 'tcp-ack' and
'tos*' options if those are used.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 7
----------------------------------------------------------------------------
1) This release includes all defect repair from Shorewall
4.5.6.1-4.5.6.2.
2) The command 'shorewall enable pppX' could fail with the ip diagnostic
Error: either "to" is duplicate, or "weight" is a garbage.
Shorewall now generates the correct ip command.
3) Optimize level 4 could previously combine two rules that each
specified the 'policy' match, leading to this iptables-restore
failure:
policy match: multiple elements but no --strict
The optimizer now avoids combining such rules.
While this is a long-standing defect in the optimizer, it was
exposed by changes in Shorewall 4.5.6.
4) There were several cases where hard-wired directory names appeared
in the tarball installers. These have been replaced with the
appropriate shorewallrc variables.
5) A defect in RHEL 6.3 and derivatives causes 'shorewall show
capabilities' to leave an empty ipset in the configuration. The
same defect can cause the Shorewall compiler to similarly leave
behind an empty ipset.
This Shorewall release implements a workaround for the problem.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 7
----------------------------------------------------------------------------
1) A new 'rpfilter' interface option has been added. Setting this
option requires kernel 3.4.0 or later and iptables 1.4.14. This
option is similar to routefilter but without the disadvantages:
- Works with both IPv4 and IPv6
- Uses packet marks when doing reverse path lookup so works with
all Multi-ISP configurations.
- Uses standard Netfilter/Shorewall log messages controlled by the
- RPFILTER_LOG_LEVEL setting in shorewall.conf (5).
- Disposition and auditing may be controlled using the
- RPFILTER_DISPOSITION option in shorewall.conf (5).
This feature adds a new 'RPFilter Match' capability; if you use a
capabilities file, you should regenerate it using this release.
2) Beginning with the 3.3 kernels, Netfilter supports a form of
accounting (nfacct) that is triggered by iptables rules but that
survives purging and/or reloading the Netfilter ruleset. Shorewall
support for this form of accounting was added in Shorewall 4.5.7.
As of this writing, Fedora 17 has partial support for this feature
but not all. It is necessary to download and build the following:
- libnetfilter_acct
- nfacct
The following Fedora packages are also required:
- libnetlink and libnetlink-dev
- libmnl and libmnl-dev
The tarballs are available from the Netfilter download sites.
The nfacct utility can create, delete and display nfacct
objects. These named objects consist of a packet and byte
counter. Packets matching those netfilter rules that use the nfacct
match cause the packet and byte count in the object named in the
match to be incremented.
To use nfaccnt with Shorewall, use the NFACCT target. See
shorewall-accounting(5) for details.
The 'shorewall show nfacct' command is a thin wrapper around the
'nfacct list' command and displays all objects.
3) With the addition of the CT action to the /etc/shorewall[6]/notrack
file, the name of the file does not accurately reflect the file's
purpose. In this release, the name of the file has been changed to
'conntrack'.
The tarball installers will install 'conntrack' along side of an
existing 'notrack' file. If the 'notrack' file is non-empty, a
warning message is issued during compilation:
WARNING: Non-empty notrack file (...);
please move its contents to the conntrack file
This warning can be eliminated by removing the notrack file (if it
has no entries), or by moving its entries to the conntrack file and
removing the notrack file. Note that the conntrack file is always
populated with rules (see enhancement 5).
If the 'notrack' file exists and is empty, the first compilation
will remove it with the warning:
WARNING: Empty notrack file (...) removed
4) 'all' is now accepted as a zone name in the SOURCE column of
shorewall-conntrack(5). As in the rules file, it means all zones.
5) Because of the potential for attackers to subvert Netfilter helpers
like the one for FTP, the Netfilter team are in the process of
eliminating the automatic association of helpers to connections. In
the 3.5 kernel, it is possible to disable this automatic
association, and the team have announced that automatic association
will eventually be eliminated. While it is certainly more secure to
add explicit rules that create these associations, for Shorewall to
require users to add those rules would present a gross
inconvenience during a Shorewall upgrade.
To make Shorewall and kernel upgrades as smooth as possible,
several new features have been added in this release:
- Shorewall will automatically disable the kernel's automatic
association of helpers to connections on kernel 3.5 and later.
- An automatic association of helpers with connections that
performs the same function as in the pre-3.5 kernels has been
added. This automatic association is controlled by the new
AUTOHELPERS shorewall.conf option which is set to 'Yes' by
default.
- A HELPERS column has been added to the /etc/shorewall/rules
In the NEW section:
When the ACTION is ACCEPT, DNAT or REDIRECT, the specified
helper is automatically associated with the connection. HELPERS
may be specified in action files, macros and in the rules file
itself.
In the RELATED section:
The rule will only match related connections that have the
named helper attached.
- The standard Macros for applications requiring a helper (FTP,
IRC, etc) have been modified to automatically specify the correct
helper in the HELPER column.
- HELPER is now a valid action in /etc/shorewall/rules. This action
requires that a helper be present in the HELPER column and causes
the specified helper to be associated with connections matching
the rule. No destination zone should be specified in HELPER
rules. HELPER rules allow specification of a helper for
connections that are ACCEPTed by the applicable policy.
Example:
loc->net policy is ACCEPT.
In /etc/shorewall/rules:
FTP(HELPER) loc -
or equivalently
HELPER loc - tcp 21 ; helper=ftp
- The set of enabled helpers (either by AUTOHELPERS=Yes or by the
HELPERS column) can be taylored using the new HELPERS option in
shorewall.conf.
By making AUTOHELPERS=Yes the default, users can upgrade their
systems to a 3.5+ kernel without disrupting the operation of their
firewalls. Beyond such upgrades, we suggest setting AUTOHELPERS=No
and follow one of two strategies:
- Use the HELPERS column in the rules file to enable helpers as
needed (preferred); or
- Taylor the conntrack file to enable helpers on only those
connections that are required.
With either of these approaches, the list if available helpers can
be trimmed using the HELPERS option and rules can be added to the
RELATED section of the rules file to further restrict the effect of
helpers.
The implementation of these new function places conditional rules
in the /etc/shorewall[6]/conntrack file. These rules are included
conditionally based in the setting of AUTOHELPERS.
Example:
?if $AUTOHELPERS && __CT_TARGET
?if __FTP_HELPER
CT:helper:ftp all - tcp 21
?endif
...
?endif
__FTP_HELPER evaluates to false if the HELPERS setting is
non-empty and 'ftp' is not listed in that setting.
For example, if you only need FTP access from your 'loc' zone, then
add this rule outside of the outer-most ?if....?endif shown above.
CT:helper:ftp loc - tcp 21
For an overview of Netfilter Helpers and Shorewall's support for
dealing with them, see
http://www.shorewall.net/Helpers.html.
See
https://home.regit.org/netfilter-en/secure-use-of-helpers/
for additional information.
6) To make the spelling of the AUTO* shorewall[6].conf options
consistent, the AUTO_COMMENT option has been renamed
AUTOCOMMENT. AUTO_COMMENT is still accepted as an
alias. 'shorewall[6] update' will rename the option in the updated
.conf file.
7) The CT:helper action in the /etc/shorewall[6]/conntrack file
(formerly the notrack file) lacked flexibility. To allow different
options to be specified for each helper, the syntax of the
CT:helper action has been redesigned.
CT:helper:<helper>[(<option>=<value>[,...])]
where <option> is one of:
- ctevents
- expevents
Example:
CT:helper:ftp(expevents=new)
See shorewall-conntrack (5) for details.
8) The deprecated /etc/shorewall[6]/blacklist files are no longer
installed. Existing files are still processed by the compiler. Note
that blacklist files may be converted to equivalent blrules files
using 'shorewall[6] update -b'.
9) "?IF", "?ELSE", "?ELSEIF" and "?END" are now case-insensitive so,
for example, they can be entered as "?if", "?else", "elseif" AND
"?end".
10) Optimization level 4 now locates short chains (3 rules or less)
that have a single reference and replaces that single reference with
the rules themselves.
Optimization level 8 now eliminates duplicate rules in the raw
table.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 6
----------------------------------------------------------------------------
4.5.6.2
1) The compiler now generates an error when a SOURCE interface is
specified in a rule where the SOURCE zone is the firewall itself.
2) Previously, entries in /etc/shorewall/notrack that specified a
Vserver zone in the SOURCE column were omitted from the generated
ruleset.
3) The set of helpers available in the notrack file and in the HELPER
column of the tcrules file was incorrect:
- The Amanda helper requires a UDP port -- Shorewall was requiring
TCP.
- The H323 module supplies two helpers: 'RAW' and 'Q.931';
Shorewall only accepted 'h323'.
- The Netbios NS module supplies the 'netbios-ns' helper; Shorewall
only accepted 'netbios_ns'.
4) The conditional directive '?IF 0' generated an error from the
compiler. It now causes following lines to be omitted.
4.5.6.1
1) The 'systemctl' command in the Shorewall[6], Shorewall[6] Lite and
Shorewall Init installers was incorrect with the result that the
product was not started automatically on boot.
4.5.6
1) This release includes the defect repairs from Shorewall 4.5.5.1 through
4.5.5.4.
2) Previously, the tcrules file was not processed when
TC_ENABLED=No. That meant that to use features like TPROXY, it was
necessary to set TC_ENABLED=Yes and create a dummy
/etc/shorewall/tcstart file. Now, only MANGLE_ENABLED=Yes is
required.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 6
----------------------------------------------------------------------------
1) Support for size tables has been added in complex TC.
The OPTIONS column of /etc/shorewall/tcdevices now allows a
'linklayer' option whose value may be 'ethernet', 'atm' or 'adsl';
the last two are synonyms.
When 'linklayer' is specified, it may be followed by additional
options:
mtu=<mtu> - The device MTU; default 2048 (will be rounded up to a
power of two)
mpu=<mpubytes> - Minimum packet size used in
calculations. Smaller packets will be rounded up
to this size
tsize=<tablesize> - Size table entries; default is 512
overhead=<overheadbytes> - Number of overhead bytes per packet.
See tc-stab (8) for details about these options.
2) It is now possible to specify the LS (linksharing) rate for an HFSC
class in /etc/shorewall/tcclasses. See shorewall-tcclasses (5) for
details.
3) It is now possible to specify that a leaf class will use the RED
(Random Early Detection) queuing discipline rather than SFQ or
pfifo. A new class OPTION is defined:
red=(<red option>=<value>, ...)
When specified on a leaf class, causes the class to use the RED
(Random Early Detection) queuing discipline rather than
SFQ. See tc-red (8) for additional information.
Allowable <red option>s are:
min <min>
Average queue size in bytes at which marking becomes a
possibility.
max <max>
At this average queue size, the marking probability is
maximal. Must be at least twice <min> to prevent
synchronous retransmits, higher for low <min>.
probability <probability>
Maximum probability for marking, specified as a floating
point number from 0.0 to 1.0. Suggested values are 0.01 or
0.02 (1 or 2%, respectively).
limit <limit>
Hard limit on the real (not average) queue size in bytes.
Further packets are dropped. Should be set higher than
<max>+<burst>. It is advised to set this a few times higher
than <max>. Shorewall requires that <limit> be at least
twice <min>.
burst <burst>
Used for determining how fast the average queue size is
influenced by the real queue size. Larger values make the
calculation more sluggish, allowing longer bursts of
traffic before marking starts. Real life experiments
support the following guideâline:
(<min>+<min>+<max>)/(3*<avpkt>).
avpkt <avpkt>
Optional. Specified in bytes. Used with burst to determine
the time constant for average queue size calculations. 1000
is a good value and is the Shorewall default.
bandwidth <bandwidth>
Optional. This rate is used for calculating the average
queue size after some idle time. Should be set to the
bandwidth of your interface. Does not mean that RED will
shape for you!
ecn
RED can either 'mark' or 'drop'. Explicit Congestion
Notification (ECN) allows RED to notify remote hosts that
their rate exceeds the amount of bandwidth
available. Non-ECN capable hosts can only be notified by
dropping a packet. If this parameter is specified, packets
which indicate that their hosts honor ECN will only be
marked and not dropped, unless the queue size hits limit
bytes. Needs a tc binary with RED support compiled
in. Recommended.
4) The handling of the USER/GROUP column of the rules file has been
rewritten. As part of this rewrite:
a) The ability to specify a program name (e.g., +prog) has been
eliminated. The kernel feature which that ability depended on
was removed in kernel version 2.6.14.
b) It is now possible to specify UID and/or GID ranges of the form
'low-high' where 'low' and 'high' are integers and low <= high.
5) It is now possible to use Perl-compatible expressions in ?IF
directives. As before, variables must be environmental variables,
options from shorewall.conf, shell variables set in the params file
or capabilities. As previously, capabilities may be entered with
leading '__' rather than '$'.
Example:
?IF $BLACKLIST_LOGLEVEL && ! __LOG_OPTIONS
6) The ?ELSIF directive has been added allowing more convenient
expression of complex include scenarios.
Example (column headings abbreviated to fit release notes format):
#NAME NUM MARK DUP INTERFACE GWAY OPTIONS
?IF $FALLBACK
ComcastB 1 0x10000 - COMB_IF detect fallback
ComcastC 2 0x20000 - COMC_IF detect fallback
?ELSIF $STATISTICAL
ComcastB 1 0x10000 - COMB_IF detect load=0.66666667
ComcastC 2 0x20000 - COMC_IF detect load=0.33333333
?ELSE
ComcastB 1 0x10000 - COMB_IF detect balance=2
ComcastC 2 0x20000 - COMC_IF detect loose,balance
?ENDIF
7) And ORIGINAL DEST column has been added to the masq file, allowing
SNAT rules to match only DNAT traffic to a particular original source
address.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 5
----------------------------------------------------------------------------
4.5.5.4
1) In the generated script, the logic for handling wildcard interfaces
with the 'wait=n' option was incorrect. For each matching interface,
the script would check its readiness n times in rapid
succession. The script now sleeps 1 second between checks.
4.5.5.3
1) When logical interface names were used, an entry in tcrules that
included a classid could result in the compiler failing with this
Perl diagnostic:
Can't use an undefined value as an ARRAY reference at
/usr/share/shorewall/Shorewall/Tc.pm line nnn, <$currentfile>
line 20.
4.5.5.2
1) Previously, when ipp2p was used in the /etc/shorewall/tcpri file,
the generated code for saving the packet mark was clearing the
connection marks fields not having to do with traffic shaping. It
now only alters the traffic-shaping part of the connection mark.
2) Shorewall 4.4.11 allowed UID and GID ranges to be specified in the
USER:GROUP column of the rules file. That undocumented capability
has been restored for the benefit of Debian users upgrading from
Squeeze to Wheezy.
3) The special TPROXY mark value is now shown in the output of
'shorewall show marks'.
4) Assuming that A = 0 and B = 1, the following conditionals
previously produced incorrect results:
?IF $A
?IF $B
<text>
?ENDIF
?ENDIF
The <text> was included when it should have been omitted.
4.5.5.1
1) The change in Shorewall 4.5.4 that cleared the 'default' table if
there were no 'fallback' providers broke multiple 'fallback'
providers that didn't supply a weight. The symptoms were that there
were host routes to the default gateways in the 'default' routing
table but no default routes through those gateways.
This has now been corrected and multiple 'fallback' routes are once
again supported.
2) When a logical device name was specified in the REDIRECTED
INTERFACES column of /etc/shorewall/tcdevices, that name was used
in the generated script rather than the device's physical
name. Unless the two were the same, this caused start/restart
failure. Shorewall now uses the physical name.
4.5.5
1) This release includes all defect repair from Shorewall 4.5.4.1 and
4.5.4.2.
2) The Shorewall compiler sometimes must defer generating a rule until
runtime. This is done by placing shell commands in its internal
representation of a chain. These commands are then executed at run
time to create the final rule.
If all of the following were true, then an incorrect ruleset could
be generated:
a) Optimization level 4 was set.
b) A chain (chain A) containing shell commands had three or fewer
rules and commands.
c) The last rule in a second chain was a conditional jump to
chain A.
Under these conditions, the rules and commands in Chain A replaced
the conditional jump and the conditional part was lost.
Example (Lines are folded to fit the release note format):
Chain A:
if [ $SW_ETH0_ADDRESS != 0.0.0.0 ]; then
echo "-A net_dnat -d $SW_ETH0_ADDRESS\
-j DNAT --to-destination 1.2.3.4" >&3
fi
Chain B:
...
-A dnat -i eth0 -j
Result:
if [ $SW_ETH0_ADDRESS != 0.0.0.0 ]; then
echo "-A dnat -d $SW_ETH0_ADDRESS\
-j DNAT --to-destination 1.2.3.4" >&3
fi
Notice that the '-i eth0' match has been lost.
3) The Shorewall-core configure and configure.pl script were treating
SYSCONFDIR as a synonym for CONFDIR making it impossible to set
SYSCONFDIR.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 5
----------------------------------------------------------------------------
1) It is now possible to include additional information in netfilter
messages when using plain log levels (debug, info, ...). This is
done by following the level with a parenthesized comma-separated
list of "log options".
Valid log options are:
ip_options
Log messages will include the option settings from the IP
header.
macdecode
Decode the MAC address and protocol.
tcp_sequence
Include TCP sequence numbers.
tcp_options
Include options from the TCP header.
uid
Include the UID of the sending program; only effective for
packets originating on the firewall itself.
Example: info(tcp_options,tcp_sequence)
2) The Shorewall-init configuration file (/etc/default/shorewall-init
or /etc/sysconfig/shorewall-init) now contains a LOGFILE setting.
When specified, all messages generated by interface updown events
are logged there. The sample configuration file and the logrotate
file configure this log as /var/log/shorewall-ifupdown.log.
3) Previously, the 'ignore' interface option could only be specified
by itself and could not be specified unless the ZONE column was
empty (i.e, contained '-'). Now, it is allowed to specify
'ignore=1' without these restrictions.
With 'ignore=1', the generated script will still ignore
Shorewall-init 'up' and 'down' events but the interface will still
be subject to hairpin filtering unless it has the 'routefilter' or
'routeback' option.
4) Imbedded shell and Perl directives may now be optionally preceded
by a question mark ('?').
Example:
?BEGIN PERL
use strict;
...
?END PERL
5) To aid package maintainers for distributions that don't include the
Digest::SHA Perl module, the Shorewall install.sh script looks for
the DIGEST environmental variable and if the setting is not 'SHA',
then the Shorewall::Chains module is modified to use $DIGEST as the
module name.
To specify SHA1
DIGEST=SHA1 ./install.sh
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 4
----------------------------------------------------------------------------
4.5.4.2
A large number of defects in Shorewall-init have been corrected:
a) The installer now enables startup at boot on Debian.
b) When more than one product was listed in the PRODUCTS setting in
/etc/default/shorewall-init (/etc/sysconfig/shorewall-init),
only the first product was acted upon.
b) Interface up/down handling was always using 'restart'; if an
interface is disabled, 'restart' doesn't bring it up. Interface
up/down handling now uses the 'enable' and 'disable' commands
when an optional provider interface goes up or down.
2) The order in which the compiler processes line-continuation (line
ending in '\') and conditional-inclusion directives (?IF, ?ELSE,
and ?ENDIF) has been reversed.
Previously, the compiler built a concatenated line, then checked
to see if the line began with ?IF, ?ELSE or ?ENDIF. Now, the
compiler checks for ?IF, ?ELSE or ?ENDIF first and prevents those
lines from becoming part of the concatenation.
Example:
Previously, given these lines and assuming that $FOO was
non-empty and non-zero:
ACCEPT:\
?IF $FOO
bar
?ELSE
baz
?END
then the lines would become
ACCEPT:\?IF $FOO
bar
?ELSE
baz
?END
Now, they will be become simply
ACCEPT:bar
3) Two issues with the shorecap programs have been corrected:
a) The Shorewall6-lite version failed to run with the message:
/usr/share/shorewall6-lite/lib.cli: No such file or directory
b) The Shorewall-lite version would not run if SHAREDIR was set to
a value other than /usr/share in shorewallrc.
4) If an iprange appeared in the SOURCE column of /etc/shorewall/masq,
then compilation would fail on RHEL5-based systems with the error:
Address Ranges require the Multiple Match capability in
your kernel and iptables
5) The Shorewall 4.5.2.3 fix for the Shorewall-core installer's
handling of --host=linux was not brought forward into 4.5.3. It has
been included again in this version.
6) Single-line embedded PERL and SHELL commands have been
re-enabled.
7) If an iprange appeared in the SOURCE column of /etc/shorewall/masq,
then compilation would fail on RHEL5-based systems with the error:
Address Ranges require the Multiple Match capability in
your kernel and iptables
4.5.4.1
1) Beginning with Shorewall 4.4.22, the 'pptpserver' tunnel type has
been configured as a PPTP client running on the firewall rather
than as a server on the firewall. It is now correctly configured as
a server.
2) The shorewall-accounting (5) and shorewall6-accounting (5)
documentation for the IPSEC column is incorrect. Rather than
'accountin' and 'accountout', the chain names should be
'accipsecin' and 'accipsecout'.
3) IPSEC accounting did not work if the accounting file was sectioned.
Beginning with this release, the IPSEC column can be specified in
any section. As always, the IPSEC column contains a comma-separated
list of items. In the FORWARD chain, the first (or only) item in
the list must be either 'in' or 'out' to indicate whether the rule
matches incoming packets that have been decrypted ('in') or
outgoing packets that will be encrypted ('out'). There are no
restrictions with respect to which chain IPSEC rules can appear in
a sectioned file.
4.5.4
1) This release includes all defect repairs from Shorewall 4.5.3.1.
2) When EXPORTMODULES=No in shorewall.conf, the following errors were
issued:
/usr/share/shorewall/modules: line 19: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 23: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 27: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 31: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 35: ?INCLUDE: command not found
/usr/share/shorewall/modules: line 39: ?INCLUDE: command not found
These messages have been eliminated.
3) If the configuration settings in the PACKET MARK LAYOUT section of
shorewall.conf (shorewall6.conf) had empty settings, the 'update'
command would previously set them to their default settings. It now
leaves them empty.
4) Previously, Shorewall used 'unreachable' routes to null-route the
RFC1918 subnets. This approach has two drawbacks:
- It can cause problems for IPSEC in that it can cause packets to
be rejected rather than encrypted and forwarded.
- It can return 'host unreachable' ICMPs to other systems that
attempt to route RFC1918 addresses through the firewall.
To eliminate these problems, Shorewall now uses 'blackhole' routes.
Such routes don't interfere with IPSEC and silently drop packets
rather than return an ICMP.
5) The 'default' routing table is now cleared if there are no
'fallback' providers.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 4
----------------------------------------------------------------------------
1) The TPROXY tcrules action introduced in Shorewall 4.4.7 was
incomplete and required additional rules to be added in the 'start'
or 'started' extension scripts.
In this release, the TPROXY implementation has been changed and an
additional DIVERT action has been created. Because the new TPROXY
has a different set of parameters than the prior one, the tcrules
file now supports two formats:
FORMAT 1 - (default, deprecated )
The TPROXY action allows three arguments, the first of which
('mark') is required.
FORMAT 2
The TPROXY action has two optional arguments; these are the
second and third arguments to the format-1 TPROXY:
port -- the port on which the proxy is listening. While
this argument is optional, it will normally be
supplied.
ip address -- The address on which the proxy is listening.
The file format is specified by a line like this:
FORMAT {1|2}
The Sample configurations have been updated to use FORMAT 2.
The format-2 tcrules file also supports the DIVERT action. The
DIVERT action directs matching packets to the local system if there
is a transparent socket in the local system that matches the
destination of the packet. DIVERT is used to redirect response
packets from remote web servers back to the proxy process
running on the firewall rather than being routed directly back to
the client.
Finally, the providers file supports a new 'tproxy' option. When
'tproxy' is specified:
- It must be the only OPTION given
- The MARK, DUPLICATE and GATEWAY columns must be empty.
- The loopback device (lo) should be specified as the INTERFACE.
The 'tproxy' option causes a reserved mark value to be associated
with the provider and for its associated routing rule to have
priority 1.
Here is the TPROXY configuration at shorewall.net:
interfaces:
FORMAT 2
#ZONE INTERFACE OPTIONS
net eth0 ...
net eth1 ...
loc eth2 ...
- lo ignore
tcrules:
FORMAT 2
#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(S)
DIVERT eth1 - tcp - 80
DIVERT eth0 - tcp - 80
TPROXY(3129,172.20.1.254) eth2 - tcp 80
providers:
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
...
Squid 3 - - lo - tproxy
/etc/squid3/squid.conf:
...
http_port 172.20.1.254:3129 tproxy
...
2) With some misgivings, this release adds support for the geoip match
feature available in xtables-addons. Geoip allows matching of the
source or destination IP address by ISO 3661 country codes. The
Shorewall support requires xtables-addons 1.33 or later.
The support is implemented in the form of extended syntax in the
SOURCE and DEST columns of the rules file.
To specify a single country code, add a caret prefix ('^').
Example: ^A1
To specify multiple country codes, enter them as a
comma-separated list enclosed in square brackets ('[...]') with a
caret prefix ('^').
Example: ^[A1,A2]
A listing of two-character country codes is available at
http://www.shorewall.net/ISO-3661.html.
Example rule - Drop email from Anonymous Proxies and Satellite
Providers:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
DROP:info net:^[A1,A2] dmz tcp 25
The compiler determines the set of valid country codes by examining
the geoip database which is normally installed in
/usr/share/xt_geoip/. There are two sub-directories at that
location:
BE - The big-endian database.
LE - The little-endian database.
To accomodate both big-endian and little-endian machines and
to allow the database to be installed elsewhere, a GEOIPDIR option
has been added in shorewall.conf and shorewall6.conf. The default
setting is "/usr/share/xt_geoip/LE" since Shorewall is normally
installed on little-endian machines.
3) OPTIMIZE level 4 now performs an additional optimization. If the
last rule in a chain is an unqualified jump to a simple target,
then all immediately preceding rules with the same simple target
are omitted.
For example, consider this chain:
-A fw-net -p udp --dport 67:68 -j ACCEPT
-A fw-net -p udp --sport 1194 -j ACCEPT
-A fw-net -p 41 -j ACCEPT
-A fw-net -j ACCEPT
Since all of the rules are jumps to the simple target ACCEPT, this
chain is totally optimized away and jumps to 'fw-net' are replaced
with jumps to ACCEPT.
As part of this enhancement, when both OPTIMIZE level 1 and level 4
are selected, the level 1 optimization step is skipped because it
is now a limited subset of level 4.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 3
----------------------------------------------------------------------------
4.5.3.1
1) Previously, nested conditionals did not work correctly in all
cases. In particular:
?IF $FALSE
?IF $FALSE
foo
bar
?ENDIF
baz
bop
?ENDIF
In this case, the lines 'baz' and 'bop' were incorrectly included
when they should have beeen omitted.
2) The 'balance' routing table is now cleared if there are no
'balance' providers.
3) Previously, the compiler generated an invalid 'ip add route'
command if an IPv6 provider had '-' in the GATEWAY column.
4) As noted in the Migration Considerations below, the generated
firewall script maintains the interface .status files used by LSM
and SWPING. Up to now, however, the 'disable' command did not
update the .status file. That has been corrected. As part of the
change, the 'isusable' script is no longer consulted by the
'enable' command.
5) The configure and configure.pl scripts have not been outputting the
setting of SPARSE, with the result that /etc/shorewall and
/etc/shorewall6 are fully-populated on Debian systems. This has
been corrected.
For Debian users that want to remove the extra files from
/etc/shorewall (/etc/shorewall6), the following script will
do the job (replace 'shorewall' by 'shorewall6' to clean
/etc/shorewall6):
#!/bin/sh
cd /etc/shorewall
for f in *; do
[ -f /usr/share/shorewall/configfiles/$f ] && \
diff -q $f /usr/share/shorewall/configfiles/$f > /dev/null \
&& rm $f;
done
Once you have done that, edit ~/.shorewallrc and add
SPARSE=Yes
to the settings in that file.
4.5.3
1) This version includes all defect repairs from Shorewall 4.5.2.1 -
4.5.2.4.
2) The LOCKFILE setting in shorewall.conf and shorewall6.conf had
inadvertently become undocumented. It is now documented again.
3) In an initial installation of Shorewall, Shorewall6, Shorewall Lite
or Shorewall6 Lite was done under Shorewall 4.5.2, then the
firewall would not start up at boot even though the installer
indicated that it would. That defect has been corrected.
4) Previously, when per-IP rate limiting was invoked, the compiler
would use the deprecated '--ratelimit' option, even if the
preferred '--ratelimit-upto' option was available. Now, the
compiler uses the preferred option if it is supported by the
installed version of iptables.
5) Prior to this release, using a manual chain in the ACTION column of
a macro body generated an error:
ERROR: Invalid Action (mychain) in macro, macro.FOO (line ...)
This now works correctly and generates a jump to the specified
manual chain.
6) If SHAREDIR was other than /usr/share and $CONFDIR/shorewall/init
did not exist, then an error message similar to this is emited:
Processing /usr/local/share/shorewall/init ...
Usage: /etc/init.d/shorewall
{start|stop|refresh|restart|force-reload|status}
7) Prevously, a line with the single word COMMENT in the tunnels file
would generate the following error:
ERROR: Zone must be specified
Now, such a line correctly resets the current rule comment.
8) In Shorewall 4.5.2, the MARK column in the tcrules file was renamed
to ACTION but only 'mark' was accepted in the alternate
specification format. Now both 'mark' and 'action' are accepted.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 3
----------------------------------------------------------------------------
1) The '-T' option is now supported in the Shorewall and Shorewall6
'load', 'reload', 'restart' and 'start' commands. As with the
'check' command, it causes a Perl stack trace to be printed along
with compiler WARNING and ERROR messages.
2) The debuggability of assertion failures has been improved.
- A Perl stack trace is now generated unconditionally on an
assertion failure.
- Relevant data is passed as additional arguments to assertion
checks so that setting a breakpoint in
Shorewall::Config::assert() can now allows examination of the
data structures surrounding the failure.
3) The GATEWAY column of the tunnels file has been renamed 'GATEWAYS'
and now accepts a list of host and network addresses as well as IP
ranges.
Exclusion is not permitted.
In the alternate specification format, both 'gateway' and
'gateways' are accepted as the column name.
4) The 'refresh' command now allows additional options:
-d - Run the rules compiler under the Perl debugger.
-n - Don't modify routing.
-T - Produce a Perl Stack trace on errors and warnings.
-D <directory> - Look in <directory> first for configuration files.
5) The interfaces file now supports two formats:
FORMAT 1 - (default, deprecated)
Includes the BROADCAST column (UNICAST in Shorewall6).
FORMAT 2
Does not include the BROADCAST (UNICAST) column.
The format is specified by a line line this:
FORMAT {1|2}
The Sample configurations have been updated to use FORMAT 2.
6) A change has been made in the packaging for Slackware. On
Slackware, there is an /etc/rc.d/firewall.rc script that looks for
/etc/rc.d/shorewall.rc and /etc/rc.d/shorewall6.rc and runs them,
passing it's own arguments.
The file installed as firewall.rc is named
init.slackware.firewall.sh and has traditionally been included in
the Shorewall package. Beginning with this release, it is moved to
the Shorewall-core package. This opens the door for releasing
Slackware versions of the -lite products in the future.
The init scripts for Slackware are now described in slackware.rc
as:
AUXINITSOURCE=init.slackware.firewall.sh
AUXINITFILE=rc.firewall
INITSOURCE=init.slackware.$PRODUCT.sh
INITFILE=rc.$PRODUCT
7) Previously, errors reported in macros were hard to analyze.
Example:
ERROR: Unknown destination zone (bar)
/usr/share/shorewall/macro.SSH (line 11),
In this case, we don't know where the SSH macro was invoked
incorrectly. Beginning with this release, the stack of
includes/opens will be included in ERROR and WARNING messages.
Example:
ERROR: Unknown destination zone (bar)
/usr/share/shorewall/macro.SSH (line 11)
from /etc/shorewall/rules (line 42)
This shows that the SSH macro was invoked on line 42 of the rules
file.
8) There is now a BLACKLIST macro that works as follows:
- If BLACKLIST_LOGLEVEL is set, then the macro invokes the
'blacklog' action.
- Otherwise, the macro invokes the BLACKLIST_DISPOSITION action.
9) An RST action has been added which matches tcp packets with the RST
flag set. The action accepts two optional parameters:
- Action (ACCEPT or DROP). Default is DROP.
- Audit ('audit' or omitted). Default is omitted.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 2
----------------------------------------------------------------------------
4.5.2.4
1) Installation on Slackware has been corrected.
2) The 'shorewall reset' command now correctly resets the IPv4 packet
and byte counters; previously, it was resetting the IPv6 counters.
3) The Shorewall installer now modifies the Chains.pm file for
Digest::SHA depencency when $DESTDIR is set, provided that $BUILD =
$HOST. This allows rpm to automatically generate the correct module
dependency.
4) With fresh installs on Debian and derivatives, the firewall did
not start at boot, even though the installer indicated that it
would. This defect, introduced in Shorewall 4.5.2, has been
corrected.
4.5.2.3
1) The 'show routing' command was broken with dash 0.5.7-2ubuntu2
installed. It now works correctly.
2) Recent distributions have dropped Digest::SHA1 in favor of
Digest::SHA. The Shorewall installer now replaces the former
with the latter when appropriate.
3) A couple of issues with Debian release compliance have been
corrected.
4) The 'configure' script failed to handle --host=linux correctly; the
result was that it tried to open .default rather than
shorewallrc.default.
5) Previously, setting TC_EXPERT=Yes did not allow SAVE/RESTORE of all
parts of the packet/connection mark. That has been corrected.
4.5.2.2
1) If a shorewallrc file is passed to the Shorewall-core 4.5.2.1
installer, subsequent compilations will fail. The error message
indicates that the compiler is looking for the lib.core file
but the pathname has embedded whitespace.
This has been corrected.
2) The Shorewall 4.5.2.1 installer was installing the wrong Makefile
for Shorewall and Shorewall6.
4.5.2.1
1) The 4.5.2 configure script does not work on RHEL5 systems and
derivatives. To allow RPMs to be built on those systems, a
Perl-based script (configure.pl) has been added. The sample .spec
files included in the various packages have been changed to use the
new script.
2) In release 4.5.2, if an INCLUDE directive appeared inside a ?IF
... ?ENDIF sequence, then the following error would be generated
after the included file had been read:
ERROR: Missing ?ENDIF to match the ?IF at line ...
3) An error in the shorewallrc.file has been corrected.
4) The shorewallrc.redhat file has been change to conform to Fedora
packaging guidelines.
5) The installers now modify the Makefile if non-standard settings are
used for SBINDIR or SHAREDIR.
6) The configure script now detects that it is running on a version
of Bash that won't support the features used in the script.
7) Both configure and configure.pl now detect the distribution if
'host' or 'vendor' (--host or --vendor) are not specified on the
command line.
4.5.2
1) This release includes the defect repairs from Shorewall 4.5.1.1 and
4.5.1.2 (see below).
2) The generated firewall script includes code to automatically create
ipsets that are referenced but that don't exist. That code was
broken in releases 4.4.22 and later. This defect has been
corrected. As part of the fix, the generated script will now
issue a warning message when it creates an ipset.
4.5.1.2
1) The Shorewall Lite and Shorewall6 Lite installers have been
installing the wrong SysV init script on Debian and derivatives.
The correct script is now installed.
2) Nested TC classes could result in Perl diagnostics like this one:
Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in
numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042,
<$currentfile> line 13.
These harmless messages have been eliminated.
3) It is once again possible to omit the minimum length in the LENGTH
column of the tcrules file.
4) Under the following conditions, a compiler internal error was
raised:
- Extended conntrack match support is available.
- Repeat Match is not available.
- A DNAT rule specifies a destination port, a server port and
an original destination.
5) Beginning with release 4.4.26, setting both 'nets=' and 'dhcp' on
an interface does not work correctly. That issue has been resolved
in this release.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 2
----------------------------------------------------------------------------
1) The 'mss' option is now supported in the /etc/shorewall[6]/hosts
files. See the manpages for details.
2) It is now possible to conditionally include or omit configuration
entries based on the settings of shell variables. See
http://www.shorewall.net/configuration_file_basics.htm#Conditional
for details.
3) The MARK/CLASSIFY column in /etc/shorewall[6]/tcrules has been
renamed ACTION to reflect the expanded set of actions that can be
specified in the column.
4) Some users are finding these ipset warnings objectionable:
- Warning when a referenced ipset does not exist.
- Warning when using [src] in a destination column or [dst] in a
source column.
These warnings may now be suppressed by setting IPSET_WARNINGS=No
in shorewall.conf and/or shorewall6.conf.
5) The evolution of the Shorewall installation process
continues. Testers are invited to provide comments and suggestions
about the following.
Beginning with this release, the installers accept a configuration
file as a parameter. Options set in the configuration file are as
follows:
BUILD (optional) -- Platform on which the installation is being
performed. Possible values are:
apple - OS X
archlinux - ArchLinux
cygwin - Cygwin running under Windows
debian - Debian and derivatives
linux - Generic Linux system
redhat - Fedora, RHEL and derivatives
suse - SLES and OpenSuSE
If no value is assigned, then the installer
will detect the platform.
HOST (Optional) -- Allowed values are same as for BUILD. If not
specified, the BUILD setting is used.
CONFDIR (Req'd) -- Directory where product configuration
directory is installed. Normally /etc.
SHAREDIR (Req'd) -- Directory where architecture-independent
product files are installed. Normally
/usr/share.
LIBEXECDIR (Req'd) -- Directory where product executables are
installed. Normally /usr/share or
/usr/libexec.
PERLLIBDIR (Req'd) -- Directory where Shorewall Perl modules are
to be installed. Traditionally
/usr/share/shorewall.
SBINDIR (Req'd) -- Directory where product CLI programs are
installed. Normally /sbin
MANDIR (Req.d) -- Directory where manpages are
installed. Mornally /usr/share/man.
INITFILE (Optional)
-- Optional. If given, specifies the installed
filename of the initscript. Normally
set to $PRODUCT which the installers expand
to the name of the product being installed.
If not specified, no init script will be
installed.
INITSOURCE (Optional)
-- Must be specified if INITFILE is specified.
Gives the name of the file to be installed
as the INITFILE.
INITDIR (Optional) -- Directory where SysV init scripts are
installed. Must be specified if INITFILE is
specified.
ANNOTATED (Optional)
-- If non-empty, indicates that the
configuration files are to be annotated with
manpage information. Normally empty.
SYSTEMD (Optional) -- Name of the directory where .service files
are to be installed. Should only be specified
on systems running systemd.
SYSCONFDIR (Optional)
-- Name of the directory where subsystem
init configuration information is stored.
On Debian and derivates, this is
/etc/default. On other systems, it is
/etc/sysconfig.
SYSCONFFILE (Optional)
-- Name of the file to be installed in the
SYSCONFIGDIR. The installed name of the file
will always be the product name (shorewall,
shorewall-lite, etc.)
SPARSE (Optional) -- If non-empty, causes only the .conf file to
be installed in
${CONFDIR}/${PRODUCT}/. Otherwise, all of
the product's skeleton configuration files
will be installed.
TEMPDIR (Optional) -- If non-empty, the generated firewall script
will export the variable TMPDIR with
value $TEMPDIR.
VARDIR (Required) -- Directory where product state information
is stored. Normally /var/lib.
This setting was previously stored in the
optional vardir file in the product's
configuration directory.
Each of the product tarballs contains a set of configuration files
for the various HOSTS:
shorewallrc.apple
shorewallrc.archlinux
shorewallrc.cygwin
shorewallrc.debian
shorewallrc.default (for HOST 'linux')
shorewallrc.redhat
shorewallrc.suse
To aid distribution packagers, a configure script has been added.
The arguments to the script are the usual list of <option>=<value>
assignments. The supported options are the same as those above,
although they may be in lower case and may be optionally preceded
by '--'.
The configure script uses the setting of --host to select the
appropriate rc file. It reads that file to establish default
settings and then applies the values specified in the argument
list. To allow use with the %configure RPM macro, only the last
occurrence of a particular option setting is applied. The resulting
settings are written to a file named 'shorewallrc' in the current
working directory and are also written to standard out.
When Shorewall-core is installed on a system (with no DESTDIR), it
copies the specified configuration file into root's
~/.shorewallrc. The ~/.shorewallrc file is then used, by default,
when installing the other packages.
To further aid use with %configure, several aliases are supported:
alias option
----- ------
sharedstatedir vardir
datadir sharedir
sysconfdir confdir
The configuration file is also copied to
${SHAREDIR}/shorewall/shorewallrc where the CLI programs and init
scripts can find it. Those programs are modified by the installer
when ${SHAREDIR} is not /usr/share.
When using Shorewall-lite or Shorewall6-lite, if the remote
firewall's shorewallrc file differs from that on the firewall, then
a copy of the remote file should be placed in the firewall's
configuration directory on the administrative system.
Beginning with this release, using /etc/shorewall-lite/vardir
and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in
favor of the VARDIR setting in shorewallrc.
NOTE: While the name of the variable remains VARDIR, the
meaning is slightly different. When set in shorewallrc,
each product (shorewall-lite, and shorewall6-lite) will
create a directory under the specified path name to
hold state information.
Example:
VARDIR=/opt/var/lib/
The state directory for shorewall-lite will be
/opt/var/lib/shorewall-lite/ and the directory for
shorewall6-lite will be /opt/var/lib/shorewall6-lite.
When VARDIR is set in /etc/shorewall[6]-lite/vardir, the
product will save its state in the specified directory.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 1
----------------------------------------------------------------------------
4.5.1.1
1) When checking or compiling for export (-e option), /sbin/shorewall
would previously issue a warning message if the SHOREWALL_SHELL
specified in the remote firewall's shorewall.conf did not exist.
2) The changes to TOS handling in 4.5.1 are incompatible with older
releases such as RHEL5 and derivatives. That has been corrected.
3) The rules compiler now verifies that the protocol is TCP, UDP, SCTP
or DCCP when checking a port range (low:high or low-high).
4) Previously, start or restart using the init script would fail with
an error message referencing 'SHOREWALL_INIT_SCRIPT'. This defect
was not visible to users that set AUTOMAKE=Yes or that run
Shorewall-init.
4.5.1
1) This release includes all defect repair from versions
4.5.0.1-4.5.0.3.
2) The Shorewall-init installer now installs the proper init script on
Redhat and Fedora.
3) A typo has been corrected in the blrules man pages.
4) Previously, if the interface appearing in the HOSTS column of
/etc/shorewall6/hosts was not defined in
/etc/shorewall6/interfaces, then the compiler would terminate with
a Perl diagnostic:
Can't use an undefined value as a HASH reference at
/usr/share/shorewall/Shorewall/Zones.pm line 1817,
<$currentfile> line ...
5) The handling of the LIBEXEC and PERLLIB variables was broken in the
base 4.5.0 release. Simon Mater has supplied a fix which is
included in this release.
6) On systems running systemd, init scripts are no longer installed in
/etc/rc.d/init.d.
7) The Shorewall Init installer now correctly detects the use of
systemd.
8) On systems running systemd, the installer now installs
/sbin/shorewall-init. That file has not existed previously, even
though shorewall-init.service is trying to use it.
9) The compiler was previously failing to validate the contents of the
LENGTH and TOS columns in /etc/shorewall/tcrules. The contents of
those columns are now validated by the compiler and an appropriate
error message is issued if validation fails.
10) The column headings in the tos files are now in the proper
order. Previously, the SOURCE PORT and DEST PORT columns were
reversed.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 1
----------------------------------------------------------------------------
1) Support is now included for IMQ. This takes the form of of
IMQ(<number>) in the MARK/CLASSIFY column of
/etc/shorewall/tcrules.
2) It is no longer necessary to specify a MARK value for the default
class under a device that does not specify the 'classify'
option. Simple set the MARK column to '-' in the default class.
3) Previously, the install scripts included in the Shorewall packages
were very restrictive. They could either be run to install directly
onto the system in a distribution-dependent way, or they could
install into a directory in a distribution-independent way. This
limited their usefullness to packagers.
Beginning with this release, the install scripts handle the install
system and the target system independently. When running an
installer, the following environmental variables can be set:
a) BUILD - Describes the system where the installer is
running. Accepted values are:
cygwin - Cygwin running under a Microsoft OS
apple - OS X
debian - Debian,Ubuntu,etc.
redhat - Fedora,RHEL,Centos,Foobar,etc.
slackware - Slackware
archlinux - Arch Linux
linux - Generic Linux
If BUILD is not set, then the installer uses its existing
algorithm for detecting the current OS and distribution.
b) HOST - Describes the system where the installed package
will run.
- For Shorewall and Shorewall6, the possible values are
the same as for BUILD.
- If HOST is not set, the value of BUILD (through setting or
detection) is used.
- For Shorewall-lite and Shorewall6-lite, the possible choices
are debian, redhat, suse, slackware, archlinux and
linux.
- For Shorewall-init, the possible choices are debian,
redhat, and suse.
c) INITDIR - Gives the absolute path name of the directory
containing the init scripts.
The choice of HOST and TARGET follow the naming of similar macros
in rpm and autoconf.
As part of these changes, LIBEXEC and PERLLIB must now hold an
absolute pathname. So, for example, if you have been using
LIBEXEC=libexec
you will need to change to
LIBEXEC=/usr/libexec
Additionally, support has been added for sourcing a file containing
option settings. The file name is 'shorewall-pkg.config' in the
parent directory of the untar'ed package file.
5) The .spec files included with each package have undergone
considerable revision.
When running the package ./install.sh script:
a) The setting for LIBEXEC is taken from the standard '_libexecdir'
rpm macro.
b) The setting for PERLLIB is taken from the standard
'perl_privlib' rpm macro.
c) The setting for INITDIR is taken from the standard
'_initddir' rpm macro.
d) The setting of BUILD is detected by the install script.
e) The setting for TARGET is taken from the standard '_vendor' rpm
macro.
The rpms included with Shorewall are built with these settings of
the standard rpm-supplied macros:
%_libexecdir /usr/libexec
%perl_privlib /usr/share/shorewall
%_initddir /etc/init.d
%_vendor suse
The setting of %perl_sitelib is chosen for portability, since there
seems to be no common location for site-specific Perl modules among
the rpm-based distributions.
6) A SWITCH column has been added to /etc/shorewall/masq. This column
allows for enabling and disabling a rule based on a setting in
/proc/net/nf_condition. See shorewall-masq(5) for details.
7) The rules compiler now issues a warning when the 'src' ipset flag
is used in a destination column or the 'dst' ipset flag is used in
a source column.
8) Support has been added for matching and setting the "Differentiated
Services Code Point" (DSCP) field in the IP header. See
shorewall-tcrules(5) and shorewall6-tcrules(5) for details.
9) "Run-time gateway variables" are now supported. These variables
have names that are composed of a percent sign ('%') followed by
the logical name of an interface defined in
/etc/shorewall/interfaces. They are expanded to the IP address of
the default gateway out of the corresponding interface.
Example:
%eth0 expands to the IP address of the default gateway out of eth0.
See
http://www.shorewall.net/configuration_file_basics.htm#Variables
for details.
10) The 'update' command now omits non-default settings of
WIDE_TC_MARKS and HIGH_ROUTE_MARKS from the updated .conf file.
11) The 'isusable' extension script is no longer installed by
default. Users wishing to install it may simply copy it from
/usr/share/shorewall[6]/configfiles.
12) Support has been added for seting the "Type of Service" (TOS)
header field in shorewall-tcrules(5) and shorewall6-tcrules(5). See
the manpages for details. As part of this change, use of the
shorewall-tos(5) and shorewall6-tos(5) files is deprecated and a
warning is issued on the first rule in each file.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 4 . 5 . 0
----------------------------------------------------------------------------
4.5.0.3
1) The .service file with Shorewall Init specified that
/sbin/shorewall-init should be run for start and stop, but there
was no such file.
Now, the installer will install /sbin/shorewall-init and will omit
installing /etc/rc.d/init.d/shorewall-init when systemd is being
used.
2) If the variable DEBUG was set to a non-empty value in the environment
or in /etc/shorewall/params, then 'shorewall stop' and 'shorewall
clear' would not totally remove the old ruleset and a subsequent
'shorewall start' would fail.
3) 'shorewall trace stop' or 'shorewall trace clear' would previously
fail to remove the entire ruleset.
4.5.0.2
1) The init scripts from shorewall.net that were installed on systems
other than Redhat-based and Debian-based systems were broken.
'/etc/init.d/shorewall start' and /etc/init.d/shorewall restart'
failed with:
"ERROR: No directory 'start'"
or
"ERROR: No directory 'restart'"
2) The Shorewall-init installer now works correctly when installing
the product on a Redhat-based distribution.
4.5.0.1
1) The handling of the LIBEXEC and PERLLIB variables was broken in the
base 4.5.0 release. Simon Mater has supplied a fix which is
included in this release.
2) A typo has been corrected in the blrules man pages.
3) Previously, if the interface appearing in the HOSTS column of
/etc/shorewall6/hosts was not defined in
/etc/shorewall6/interfaces, then the compiler would terminate with
a Perl diagnostic:
Can't use an undefined value as a HASH reference at
/usr/share/shorewall/Shorewall/Zones.pm line 1817,
<$currentfile> line ...
4) The Shorewall-init installer now installs the correct init script
on Fedora and Redhat systems.
4.5.0
1) This release includes all defect repair included in
4.4.27.1-4.4.27.3.
2) The start and restart commands in Shorewall Lite and Shorewall6
Lite now correctly handle the 'trace' and 'debug'
keywords. Previously, those keywords were ignored.
3) The 'ip route list' command on recent Linux systems (Ubuntu 11.10,
for example) displays the IPv4 routing table in a seemingly random
order. In the 'show routing' and 'dump' commands, Shorewall and
Shorewall-lite now sort the output into the traditional
'Most-specific to most-general' order.
4) Previously, specifying 'No' in the HAVEROUTE column of
/etc/shorewall6/proxyndp resulted in a run-time error. The code has
been corrected so that no error occurs.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 4 . 5 . 0
----------------------------------------------------------------------------
1) The rules generated by the following interface options are now
traversed after those generated by the blrules file.
dhcp
maclist
nosmurfs
sfilter
tcpflags
As part of this change, the BLACKLIST section in the rules file has
been eliminated. If you have rules in that section, you must move
them to the blrules file prior to installing this Shorewall
version.
2) The timeout interval after which the previous state is restored
may now be specified in the safe-start and safe-restart commands.
3) The packing of the Shorewall products has been changed. Beginning
with this release, the packages are:
- Shorewall Core -- Core libraries installed in
/usr/share/shorewall/
- Shorewall -- Requires Shorewall Core. Together with
Shorewall Core, provides IPv4 firewalling.
- Shorewall6 -- Requires Shorewall. Provides IPv6 firewalling.
- Shorewall Lite -- Requires Shorewall Core. As before.
- Shorewall6 Lite -- Requires Shorewall Core. As before.
- Shorewall Init -- As before.
4) Shorewall and Shorewall6 now share a single install.sh file as do
Shorewall Lite and Shorewall6 Lite.
5) Functions common to both /usr/share/shorewall/prog.header and
/usr/share/shorewall/prog.header6 are now in a new library -
lib.core. The files /usr/share/shorewall/prog.footer is now used
for both IPv4 and IPv6.
6) Run-time address variables (e.g., ð0) may now be used in the
SOURCE column of the rtrules files.
7) The route_rules file has been renamed to 'rtrules'. The Shorewall
and Shorewall6 installers will perform the rename on an existing
file.
If both files exist, route_rules will be processed and rtrules
will be ignored with a warning.
8) A 'PROBABILITY' column has been added to the tcrules files. It
causes the rule to match randomly with the probability specified in
the column. See shorewall-tcrules(5) and shorewall6-tcrules(5) for
details.
9) An alternative to the balance=<weight> option in the providers file
is now available. This alternative works when there are multiple
links to the same ISP where both links use an ethernet interface (as
opposed to PPP0E) and have the same default gateway.
As part of this change, the generated firewall script now
automatically maintains the
/var/lib/shorewall[6][-lite]/interface.status files used by SWPING
and by LSM.
See http://www.shorewall.net/MultiISP.html#load for additional
information.
Example that sends 1/3 of the connections to the ComcastC provider
and the rest to ComcastB:
/etc/shorewall/shorewall.conf
MARK_IN_FORWARD_CHAIN=No
...
USE_DEFAULT_RT=Yes
/etc/shorewall/providers:
#NAME NUMBER MARK DUP INTERFACE GATEWAY OPTIONS
ComcastB 1 - - eth1 70.90.191.126 loose,balance,load=0.66666667
ComcastC 2 - - eth0 67.170.120.1 loose,fallback,load=0.33333333
Note: The 'loose' option is specified so that the compiler will not
generate and rules based on interface IP addresses. That way
we have complete control over the priority of such rules
through entries in the rtrules file.
/etc/shorewall/rtrules
#SOURCE DEST PROVIDER PRIORITY
70.90.191.120/29 - ComcastB 1000
ð0 - ComcastC 1000
Note: eth0 has a dynamic address, so ð0 is used in the SOURCE
column.
Note: Priority = 1000 means that these rules will come before rules
that select a provider based on marks.
10) The Shorewall files in /etc/default and /etc/sysconfig now support
two new options that affect how '/etc/init.d/shorewall start'
and '/etc/init.d/shorewall restart' behave:
STARTOPTIONS -- options to the start commmand.
RESTARTOPTIONS -- options to the restart command.
For example, if you always want 'start' to flush the conntrack
table, then you would have:
STARTOPTIONS="-p"
11) The Git repository has been reorganized to place the samples and
manpages under their corresponding product directories. For
example, trunk/manpage6 was moved to trunk/Shorewall6/manpages.
distrib
>
Mageia
>
4
>
i586
>
media
>
core-release
>
by-pkgid
>
f1e0663d7c4e8265b8e5b6a277871fd8
>
files
>
11
