---------------------------------------------------------------------------- S H O R E W A L L 5 . 1 . 1 0 . 2 ------------------------------- D e c e m b e r 3 1 , 2 0 1 7 ---------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------- 5.1.10.2 1) There are two related defects in 5.1.10 and 5.1.10.1 that manifest when AUTOMAKE=Yes. When AUTOMAKE=Yes, the commands 'start', 'restart' and 'reload' cause the 'find' utility to be run in each entry in the CONFIG_PATH to look for files that have been modified since the current firewall script was created. a) While the compiler only searches in the directires themselves, 'find' was not limited to just those directories, but was rather searching the entire tree rooted in each entry of the directories. b) If the CONFIG_PATH was prefixed by ":", then there was effectively an empty entry in CONFIG_PATH, which resulted in a search of the entire tree rooted in the current working directory. Both problems have been corrected: a) Find is run with '-maxdepth 1', to limit the search to just the files in the directory. b) Find is not run if a path in CONFIG_PATH is empty. 5.1.10.1 1) The Shorewall-core installer previously failed to update the shell library files correctly when SHAREDIR was not set to /usr/share/. That has been corrected. 2) Previously, the installer modified the shorewall[6].conf installed in /etc/shorewall[6] based on the Linux distribution (HOST in shorewallrc) but installed an unmodified file in /usr/share/shorewall/configfiles/. Beginning with this release, the modified file is also installed in the latter directory. 5.1.10 1) Several typos have been corrected in the manpages (Roberto Sánchez). 2) Regarding Known Problem 3 below, the code added in 5.0.15 could fail to delete an existing default route if the new default route was not identical to the one being replaced. Now, the default route is deleted, even the new route is different. 3) Previously, if the 'ss' utility was not installed but 'netstat' was installed, the 'dump' command would issue the error message /sbin/shorewall: line 1: netatat: not found and the dump would not contain socket information. That problem has been corrected. 4) Previously, a plain 'reset' command would only reset counters in the 'filter' and 'mangle' tables. Now, all four tables have their counters reset. 5) Specifying IN-BANDWIDTH would previously cause a run-time start/restart/reload failure when a later version of iproute2 was installed. The problem has been observed on both iproute2 4.13.0 and 4.14.0. The failure message was similar to the following: Setting up Traffic Control... "rate" or "avrate" MUST be specified. Illegal "police" ERROR: Command "tc filter add dev ppp0 parent ffff: protocol all prio 10 basic police mpu 64 drop rate 55378kbit burst 10kb" Failed This problem has been resolved. 6) Previously, Shorewall-init would recompile the firewall script each time that it ran. Now, it only compiles the script if it doesn't exist. 7) Most interface OPTIONS have always been ignored when the INTERFACE name is '+'. Beginning with this release, a warning is issued when an ignored option is specified with interface name '+'. Example: The 'sourceroute' option is ignored when used with interface name '+' In most cases, this issue can be worked around by a change similar to the following: Original: net + dhcp,routeback,sourceroute=0 Change to: net all dhcp,physical=+,routeback,sourceroute=0 --- ---------- As part of this change, interfaces that specify a wildcard physical interface name will generate a warning if any of the following options are specified: accept_ra arp_filter arp_ignore forward logmartians proxyarp proxyndp routefilter sourceroute When the warning is issued, the specified option is then ignored for the interface. Example: WARNING: The 'sourceroute' option is ignored when used with a wildcard physical name /etc/shorewall6.universal/interfaces (line 14) 8) When the IPv6 Universal sample configuration was used, the following warning was issued during start/restart/reload: WARNING: Cannot set Accept Source Routing on + The Universal interfaces file has been corrected to eliminate that error. 9) Previously, the Shorewall and Shorewall6 example interfaces.annotated files were truncated, due to a defect in the Shorewall build tools. That defect has been corrected so that the files are no longer truncated. ---------------------------------------------------------------------------- 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. 2) The 'enable', 'reenable' and 'disable' commands do not work correctly in configurations with USE_DEFAULT_RT=No and optional providers listed in the DUPLICATE column. 3) While the 'ip' utility now accepts IPv6 routes with multiple 'nexthop' destinations, these routes are not balanced. They are rather instantiated as a sequence of single routes with different metrics. Furthermore, the 'ip route replace' command fails on such routes. Beginning with Shorewall6 5.0.15, the generated script uses a "delete..add.." sequence on these routes rather than a single "replace" command. ---------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------- 1) Previously, it was necessary to remove ${CONFDIR}/shorewall[6] from the CONFIG_PATH to create a configuration directory for a remote firewall managed by shorewall[6]-lite. Without this modification, when the compiler looked for a file that was not present in the configuration directory, it would attempt to read the file by the same name residing in ${CONFDIR}/shorewall[6]. Now, if the setting of CONFIG_PATH begins with a colon (":"), the first directory in the path is ignored when compiling for export or when the user running the compiler is not root. The released copies of shorewall[6].conf have all been modified to set CONFIG_PATH with a leading colon. 2) The documentation surrounding use of DNS names in Shorewall configuration has been improved. 3) It is now possible to associate a particular protocol with an action in shorewall[6]-actions(5). When a protocol is specified in that file, it is not necessary to specify the protocol in the PROTO column when invoking the action. If a protocol is included in the PROTO column then it must match the one specified in the actions file. If an action defined with a protocol is used as a Policy Action, then only packets with the specified protocol will be passed to the action. A number of standard actions definitions in /usr/share/shorewall[6]/actions.std have had a protocol added. The protocol has no effect if 'builtin' or 'inline' is also specified; specifying 'builtin' with a protocol results in a warning message. No warning is issued when 'inline' is specified with a protocol, thus allowing 'inline' and a protocol to appear together in actions.std. Note that 'noinline' in shorewall-actions(5) can override an 'inline' specification in actions.std. 4) The FIN action previously included the PSH flag (FIN,ACK,PSH). To make the action a bit more general, the PSH flag is now removed and TCP packets with just the FIN and ACK flags set will now match. ---------------------------------------------------------------------------- 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.6.x or earlier, please see http://www.shorewall.net/pub/shorewall/5.0/shorewall-5.0.15/releasenotes.txt 2) Shorewall 5.1 now has a single CLI program, ${SBINDIR}/shorewall (normally /sbin/shorewall). This program performs all of the same functions previously performed by /sbin/shorewall, /sbin/shorewall6, /sbin/shorewall-lite and /sbin/shorewall6-lite and is installed as part of the Shorewall-core package. It's default 'personality' is determined by the Shorewall packages installed: a) If the Shorewall package is installed, then by default, /sbin/shorewall behaves as in prior versions. b) If the Shorewall package is not installed, but the Shorewall-lite package is present, then /sbin/shorewall behaves as did /sbin/shorewall-lite in prior versions. c) If neither the Shorewall nor Shorewall-lite packages are installed, but the Shorewall6-lite package is installed, then /sbin/shorewall behaves as did /sbin/shorewall6-lite in prior versions. The program's personality can be altered through use of two new options. -6 When specified, changes the personality from Shorewall to Shorewall6 or from Shorewall-lite to Shorewall6-lite. -l When specified, changes the personality from Shorewall to Shorewall-lite or from Shorewall6 to Shorewall6-lite. This option is only required when both the standard package (Shorewall or Shorewall6) and the corresponding -lite package are installed on the system. The following is a comparison of Shorewall 5.0 and Shorewall 5.1 with respect to the CLI invocation: All four packages installed: Shorewall 5.0 Shorewall 5.1 shorewall shorewall shorewall6 shorewall -6 shorewall-lite shorewall -l shorewall6-lite shorewall -6l Only Shorewall-lite and Shorewall6-lite installed: Shorewall 5.0 Shorewall 5.1 shorewall-lite shorewall shorewall6-lite shorewall -6 A single shorewall(8) manpage now describes the CLI. The shorewall6(8), shorewall-lite(8) and shorewall6-lite(8) manpages are now minimal and refer the reader to shorewall(8). For backward compatibility, Shorewall6, Shorewall-lite and Shorewall6-lite install symlinks $SBINDIR/shorewall6, $SBINDIR/shorewall-lite and $SBINDIR/shorewall6-lite respectively. When the shorewall program is invoked through one of these symlinks, it adopts the appropriate personality. 3) The CHAIN_SCRIPTS option in the .conf files has been eliminated, and the compiler no longer looks for script files with the same name as a chain or action. If you are using such files, you will need to convert them into equivalent ?begin perl .... ?end perl text or to use the IP[6]TABLES target and/or inline matches. For the common case where you have an action xxx with an empty action.xxx file and have perl code in a file named xxx, the compiler will now generate a fatal error: ERROR: File action.xxx is empty and file xxx exists - the two must be combined as described in the Migration Considerations section of the Shorewall release notes For information about resolving this error, see http://www.shorewall.org/Shorewall-5.html#idp41228128. 4) The Netfilter team have removed support for the rawpost table, so Shorewall no longer supports features requiring that table (stateless netmapping in the netmap file). The good news is that, since kernel 3.7, Netfilter supports stateful IPv6 network mapping which is now also supported in Shorewall6 (see shorewall6-netmap(5)). 5) The (undocumented) Makefiles haven't been maintained for many releases and have been removed. 6) Beginning with Shorewall 5.1.2, The DROP_DEFAULT, REJECT_DEFAULT, etc. options may now specify a comma-separated list of actions rather than just a single action. The actions are invoked in the order in which they are listed and each action may optionally be followed by a colon (":") and a log level. The POLICY column in shorewall[6]-policy can now specify a similar list of actions. In that file, the list may be preceded by a plus sign ("+"), in which case the listed actions will be in addition to those listed in the related _DEFAULT setting in shorewall[6].conf. With these changes, the Drop and Reject policy actions are now deprecated in favor of a list of smaller actions. A warning is issued when these deprecated actions are used; the warning refers the reader to http://www.shorewall.net/Actions.html#Default. 7) Beginning with Shorewall 5.1.2, the allowBcast, dropBcast, and Broadcast no longer handle multicast. Multicast is handeled separately in actions allowMcast, dropMcast and Multicast. The now-deprecated Drop and Reject policy actions have been modified so that they continue to silently drop multicast packets. 8) According to the Netfilter team (see https://patchwork.kernel.org/patch/9198133/), the --nflog-range option of the NFLOG target has never worked correctly, and they have deprecated that option in favor of the --nflog-size option. To accomodate this change, Shorewall 5.1.5 added an "--nflog-size support" (NFLOG_SIZE) Shorewall capability and a USE_NFLOG_SIZE option in shorewall[6].conf. If USE_NFLOG_SIZE=Yes, then if the capability is present, Shorewall will use '--nflog-size' in place of '--nflog-range'. If USE_NFLOG_SIZE=Yes and the capability is not present, an error is raised. If you don't use NFLOG or if you use NFLOG with omittted second parameter or with 0 as the second parameter, and 'shorewall show capabilities' indicated that --nflog-size support is present, you may safely set USE_NFLOG_SIZE=Yes. If you pass a non-zero value as the second parameter to NFLOG and the '--nflog-size support' capability is present, you need to verify that those NFLOG messages are as you expect with USE_NFLOG_SIZE=Yes. 9) The MODULE_SUFFIX option in shorewall[6].conf was eliminated in Shorewall 5.1.7. Shorewall now finds modules, independent of their filename suffix. 'shorewall [-6] update' will automatically remove any MODULE_SUFFIX setting. 10) Beginning with Shorewall 5.1.8, when RESTORE_DEFAULT_ROUTE=Yes the default route is only restored when there are no enabled 'balance/primary' providers and no enabled fallback providers. Also beginning with Shorewall 5.1.8, if the default route(s) have been restored to the 'main' table, and a fallback provider is successfully enabled, the default route(s) are removed from the main table. 11) Because restoring default routes to the main routing table can break the ability of Foolsm and other link status monitors to properly detect non-functioning provider links, a warning message is issued when the 'persistent' provider option is specified and RESTORE_DEFAULT_ROUTE=Yes. WARNING: When RESTORE_DEFAULT_ROUTE=Yes, the 'persistent' option may not work as expected This change was released in Shorewall 5.1.8. 12) Most interface OPTIONS have always been ignored when the INTERFACE name is '+'. Beginning with the Shorewall 5.1.10 release, a warning is issued when an ignored option is specified with interface name '+'. Example: The 'sourceroute' option is ignored when used with interface name '+' In many cases, this issue can be worked around by a change similar to the following: Original: net + dhcp,routeback,sourceroute=0 Change to: net all dhcp,physical=+,routeback,sourceroute=0 --- ---------- As part of this change, interfaces that specify a wildcard physical interface name will generate a warning if any of the following options are specified: accept_ra arp_filter arp_ignore forward logmartians proxyarp proxyndp routefilter sourceroute When the warning is issued, the specified option is then ignored for the interface. Example: WARNING: The 'sourceroute' option is ignored when used with a wildcard physical name /etc/shorewall6.universal/interfaces (line 14) ---------------------------------------------------------------------------- V. N O T E S F R O M O T H E R 5 . 1 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 5 . 1 . 9 ---------------------------------------------------------------------------- 1) This release includes defect repair through Shorewall 5.1.8.1. 2) Previously, Shorewall6 did not accept square brackets ("[...]") around the GATEWAY address in a Providers file entry. That has been corrected, so that the usual convention of enclosing IPv6 addresses in square brackets is allowed in that context. 3) Previously, if the IP variables was set in a remote firewall's configuration directory, and the named file did not exist on the local administrative system, then a fatal error was raised. Example: ERROR: The program specified in IP (/usr/bin/ip) does not exist or is not executable Beginning with this release, the contents of the IP option will not be verified at compile time when compiling for export. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 9 ---------------------------------------------------------------------------- 1) The mangle file now supports a TCPMSS action for setting the MSS value in TCP SYN packets. See shorewall-mangle(5) for details. As part of this change, the TCPMSS rule generated by the CLAMPMSS option has been moved from the filter table FOWARD chain to the mangle table FORWARD chain. 2) The Broadcast and Multicast actions are now inlined when the Address Type Match capability is available. 3) It is now possible to specify 'noinline' in an entry in /etc/shorewall[6]/actions to override the 'inline' option specified in /usr/share/shorewall/actions.std. 4) Logging is now supported in the snat file. - Log levels may be specified on SNAT, MASQUERADE and CONTINUE rules. - The NFLOG, ULOG and LOG actions are now supported. See shorewall-snat(5) for details. 5) A logging manpage (shorewall-logging(5)) has been added. 6) The IPMI macro now includes support for Redfish remote consoles. 7) The Sample configuration files now use logical interface names to simplify adapting them to fit the newer interface naming convention adopted by the kernel. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 8 ---------------------------------------------------------------------------- 1) This release includes defect repair through Shorewall 5.1.7.2. 2) The copyright dates and product version comments have been updated in a number of files. 3) The undocumented and unmaintained Makefile files for Shorewall-lite and Shorewall6-lite have been removed from Shorewall and Shorewall6 respectively. 4) The 'dump' command logic now does a better job of detecting and suppressing the printing of empty IPSec SPD entries. 5) A number of issues with persistent providers that resulted in 'ip rule add' and 'ip route add' failures have been corrected. The most common senario involved a 'reload' while a persistent interface was disabled. 6) Previously, the generated script contained incorrect logic for deleting default routes with metric zero ('balanced' routes and routes generated by 'fallback=nn'); the logic only worked correctly when applied to the 'main' routing table. It now works correctly for all routing tables. 7) The 'ip xfrm policy' command ignores the -4 and -6 options and dumps the policies for both address families. This release contains a workaround that suppresses entries for the other family. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 8 ---------------------------------------------------------------------------- 1) For historical reasons, Shorewall has always assumed that LOG target support is present unless proven otherwise. While this has worked correctly when a capabilities file is used and when LOAD_HELPERS_ONLY=No, it can generate an unworkable firewall script when LOAD_HELPERS_ONLY=Yes. Beginning with this release, Shorewall will treat LOG target like any other capability and will verify its presense in all cases where the target is used. 2) The level 4 optimizer now does a better job of handling small chains with rules specifying an IPSEC policy. This can result in elimination of these chains. 3) Beginning with this release, when RESTORE_DEFAULT_ROUTE=Yes the default route is only restored when there are no enabled 'balance/primary' providers and no enabled fallback providers. Also beginning with this release, if the default route(s) have been restored to the 'main' table, and a fallback provider is successfully enabled, the default route(s) are removed from the main table. 4) Because restoring default routes to the main routing table can break the ability of Foolsm and other link status monitors to properly detect non-functioning provider links, a warning message is now issued when the 'persistent' provider option is specified and RESTORE_DEFAULT_ROUTE=Yes. WARNING: When RESTORE_DEFAULT_ROUTE=Yes, the 'persistent' option may not work as expected ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 7 ---------------------------------------------------------------------------- 5.1.7.2 1) Previously during the opening of a configuration file, if SELinux denied the "getattr" (stat) request, then the compiler would skip processing of the file as if it did not exist. Now, if "getattr" fails for any reason other than that the file does not exist, an error is raised. ERROR: Unable to access : 2) Previously, when a range was passed to the MARK() action (mangle file), any specified protocol, port and time restrictions were ignored. Now these elements are included in the rule. 5.1.7.1 1) Previously, the 'reenable' command failed on a persistent provider interface with a message similar to the following: RTNETLINK answers: File exists ERROR: Command "/sbin/ip -4 rule add from 10.2.10.2 pref 20000 table IPv6Beta" Failed That problem has been corrected and the 'reenable' command now works properly on both persistant and non-persistant interfaces. Note: The firewall script must be recompiled in order for this change to become effective. 5.1.7 1) This release includes defect repair through Shorewall 5.1.6.1. 2) Previously, there was a typo in IPv4 Example 5 in the shorewall-snat(5) manpage. The DEST column contained eth0+myset[dst] which should have been eth0:+myset[dst] That has been corrected. 3) Previously, specifying an ipset name in the DEST column of the IPv4 snat file had no effect. That has been corrected so that only connections whose destination matches the ipset are affected by the rule. 4) Previously, passing an invalid vlsm to the 'ipcalc' command coult result in a series of shell diagnostics beginning with: shorewall: 3730: /home/teastep/bin/shorewall: Invalid VLSM: not found That has been corrected so that the correct message is issued: ERROR: Invalid VLSM (Tuomo Soini) 5) ADD_IP_ALIASES has defaulted to Yes for both Shorewall and Shorewall6, leading to 'not found' errors during start/reload/restart. Now, ADD_IP_ALIASES=No is the default for IPv6 and may not be changed. 6) When Shorewall-init was configured to save ipsets, it could leave behind an empty or useless .tmp file if no ipsets were saved. Now that file is removed automatically. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 7 ---------------------------------------------------------------------------- 1) Loading of kernel modules has been streamlined (Tuomo Soini). 2) The MODULE_SUFFIX option in shorewall[6].conf has been eliminated. Shorewall now finds modules, independent of their filename suffix. 'shorewall [-6] update' will automatically remove any MODULE_SUFFIX setting. 3) When 'detect' is specified in the GATEWAY column for a provider, the generated script now looks for an existing default route in the provider's routing table to obtain the provider's default gateway. This is useful when dhcpcd5 is installed, since the .lease files created by dhcpcd5 are binary coded and are hence not usable for learning the configured gateway. 4) The Shorewall Event actions (IfEvent, SetEvent and ResetEvent) now accept DNAT and REDIRECT as the argument. For DNAT, a server address must be specified in the DEST column. A server port may NOT be specified in the DEST column, so the port number cannot be changed by the action. 5) Shorewall now supports Docker configuration that create the DOCKER-INGRESS chain in the filter table. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 6 ---------------------------------------------------------------------------- 1) This release contains defect repair through Shorewall 5.1.5.2. 2) http://www.shorewall.net/shorewall_extension_scripts.htm states that $SHAREDIR and $CONFDIR can be used in extension scripts, that has not been true for some time. Beginning with this release, those variables are once again available in the generated script. 3) Under very rare circumstances, when OPTIMIZE level 8 was used, messages such as the following could be issued during compilation: Use of uninitialized value in hash element at /usr/share/shorewall/Shorewall/Rules.pm line 818. Use of uninitialized value in concatenation (.) or string at /usr/share/shorewall/Shorewall/Rules.pm line 823. That has been corrected. 4) Previously, Shorewall's treatment of wildcard interfaces differed from Netfilter's. Shorewall did not consider 'eth' to match 'eth+' while Netfilter did. Beginning with this release, Shorewall is consistent with Netfilter. 5) Previously, systemd could attempt to start the IPv4 and IPv6 firewalls simultaneously, which might lead to iptables-restore and ip6tables-restore being run at the same time resulting in a failure to start one of the firewalls. Beginning with this release, Shorewall and Shorwall6 will be started serially as will Shorewall-lite and Shorewall6-lite. 6) To prevent other init systems from starting the IPv4 and IPv6 firewalls in parallel, the ip[6]-tables-restore '--wait' option, if available, is used. This change introduces a new RESTORE_WAIT_OPTION capability. Note: If the new capability is not available on your system, and you don't run systemd, you can still avoid the parallel start problem by configuring the same LOCKFILE in both your shorewall.conf and shorewall6.conf files. 7) Previously, the RDP macro only allowed TCP traffic, even though RDP also requires UDP. That has been corrected so that both protocols are allowed. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 6 ---------------------------------------------------------------------------- 1) The SPARSE option in shorewallrc originally caused only shorewall[6].conf to be installed in /etc/shorewall[6], but later the conntrack and params files were also installed. To prevent these additional files from being installed, SPARSE may now be set to 'Very', either by editing the file directly or by using the configure or configure.pl scripts. This setting is recommended if you wish to use a single set of configuration files for both IPv4 and IPv6 as described at http://www.shorewall.org/SharedConfig.html. 2) Two new run-time extensions scripts have been added: - enabled Invoked when an optional interface has been successfully enabled using the 'enable' command. - disabled Invoked when an optional interface has been successfully disabled using the 'disable' command. Like all run-time extension scripts, the contents of each script are placed in a function body. In the case of these new scripts, the function is passed arguments: $1 = the physical name of the interface $2 = the logical name of the interface $3 = the name of the Provider, if any, associated with the interface. 3) When a zone (z1) is defined to be a sub-zone of another zone (z2), the compiler now verifies that the two zones have at least one interface in common. If they do not, a warning message is generated: WARNING: Zone z1 is defined to be a sub-zone of z2, yet the two zones have no interface in common 4) Runtime address variables may now be used as the server IP address and Runtime port variables may be used as the server port in DNAT rules. Example: DNAT net $FW:ð1:%{PORT} tcp 9999 5) Previously, systemd could attempt to start the IPv4 and IPv6 firewalls simultaneously, which might lead to iptables-restore and ip6tables-restore being run at the same time resulting in a failure to start one of the firewalls. Beginning with this release, Shorewall and Shorwall6 will be started serially as will Shorewall-lite and Shorewall6-lite. 6) To prevent problems when other init systems start the IPv4 and IPv6 firewalls in parallel, the ip[6]-tables '--wait' option, if available, is used. The amount of time to wait is determined by the setting of MUTEX_TIMEOUT (default 60 seconds). This change introduces a new RESTORE_WAIT_OPTION capability. Note: If the new capability is not available on your system, and you don't run systemd, you can still avoid the parallel start problem by configuring the same LOCKFILE in both your shorewall.conf and shorewall6.conf files. 7) Previously, the sample configuration files specified MODULE_SUFFIX="ko ko.xz", whereas the default .conf files specified MODULE_SUFFIX=ko. The latter no longer works on RHEL7-based systems. Beginning with this release, the default .conf files also specify MODULE_SUFFIX="ko ko.xz". ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 5 ---------------------------------------------------------------------------- 5.1.5.2 1) Previously, Specifying a USER in the OUTPUT section of the accounting file caused the compilter to incorrectly generate the following error message: ERROR: USER/GROUP may only be specified in the OUTPUT section That has been corrected, and no error message is generated in this case. 2) When BASIC_FILTERS=Yes, the compiler previously generated an invalid tc command when when a source port was specified in a tcfilters entry. The compiler now generates correct input in this case. 3) Previously, a MAC address could be specified in the OUTPUT section of the accounting file and no error would be generated at compile time. A failure would occur, however, at run-time. Now, an error is raised during compilation. 5.1.5.1 1) To compensate for the presence of a masq file with no entries, the compiler will now attempt to process the snat file when such a masq file is found. Previously, if a masq file with no entries was found, the snat file, if any, was ignored. 2) Previously, maintainers could not create reproducible packages because the 'configure' and 'configure.pl' scripts inserted the current date and time into the generated shorewallrc file. To support reproducible package builds, the scripts now recognize the SOURCE_DATE_EPOCH environmental variable (see https://reproducible-builds.org/specs/source-date-epoch/). The change to 'configure' was supplied by Bernhard M. Wiedemann. 5.1.5 1) This release contains defect repair through Shorewall 5.1.4.4. 2) Previously, when 0 was used as a port number or when a port number > 65535 was specified, an 'uninitialized variable' Perl exception occurred when the compiler attempted to issue an error message. That has been corrected. 3) When running with Perl 5.26, messages such at the following could be issued: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^(\s*|.*[^&@%]){ <-- HERE (.*)}\s*$/ at /usr/share/shorewall/Shorewall/Config.pm line 2343. That problem has been corrected. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 5 ---------------------------------------------------------------------------- 1) Run-time port variables are now supported. See http://www.shorewall.org/configuration_file_basics.htm#Port_Variables for details. 2) The Shorewall and Shorewall6 manpages are now consolidated. Almost all of the Shorewall6 manpages are manpage aliases for the corresponding Shorewall manpages which describe the files for both products. 3) There is now a FIN standard action which handles TCP packets with the FIN, ACK and PSH flags set. 4) According to the Netfilter team (see https://patchwork.kernel.org/patch/9198133/), the --nflog-range option of the NFLOG target has never worked correctly, and they have deprecated that option in favor of the --nflog-size option. To accomodate this change, there is now an "--nflog-size support" (NFLOG_SIZE) Shorewall capability and a USE_NFLOG_SIZE option in shorewall[6].conf. For further information, see the Migrations Issues item number 8. 5) The RESTORE_DEFAULT_ROUTE option has now been added to shorewall6.conf. Prior to this release, RESTORE_DEFAULT_ROUTE=Yes has always been assumed for Shorewall6 configurations. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 4 ---------------------------------------------------------------------------- 5.1.4.4 1) A defect in 5.1.4.3 caused a startup failure when two or more 'fallback' providers were configured. That has been corrected. 5.1.4.3 1) When running on prior-generation distributions such as RHEL6, IPv6 multi-ISP configurations failed to start due to an error such as the following: ERROR: Command "ip -6 -6 route replace default scope global table 250 nexthop via ::192.88.99.1 dev tun6to4 weight 1" Failed Such configurations now start successfully. 5.1.4.2 1) Many broken links in the manpages have been corrected. 2) Support for the NFQUEUE '--queue-cpu-fanout' option, introduced in Shorewall 5.1.0, contained a defect which could result in the following compile-time error: Use of uninitialized value $fanout in concatenation (.) or string at /usr/share/shorewall/Shorewall/Rules.pm line 643, <$currentfile> line 2. That has been corrected. 5.1.4.1 1) The introductory material in shorewall-rules(5) has been cleaned up. 2) The information about LOGFORMAT in shorewall[6].conf(5) and shorewall[6]-zones(5) has been expanded. In Shorewall 5.1.0, the setting of LOGFORMAT in the default and sample .conf files was changed to "%s:%s " to enable 10-character zone names (up from 5 characters using the default "Shorewall:%s:%s:" setting). As part of this change, if a shorewall.conf file which did not set LOGFORMAT is updated using "shorewall update", LOGFORMAT is set to "Shorewall:%s:%s:" to preserve the existing behavior. This can have an effect on new installations, however in that scipts or log analyzers can no longer be configured to simply look for "Shorewall:" in log messages unless the setting of LOGFORMAT is changed. The manpages (and the Migration Considerations below) have been updated to describe how to locate these messages using the new "%s:%s " setting. 3) The BLACKLIST action was inadvertently omitted from Shorewall6 in Shorewall 5.1.1. That has been corrected. 5.1.4.1 1) The introductory material in shorewall-rules(5) has been cleaned up. 2) The information about LOGFORMAT in shorewall[6].conf(5) and shorewall[6]-zones(5) has been expanded. In Shorewall 5.1.0, the setting of LOGFORMAT in the default and sample .conf files was changed to "%s:%s " to enable 10-character zone names (up from 5 characters using the default "Shorewall:%s:%s:" setting). As part of this change, if a shorewall.conf file which did not set LOGFORMAT is updated using "shorewall update", LOGFORMAT is set to "Shorewall:%s:%s:" to preserve the existing behavior. This can have an effect on new installations, however in that scipts or log analyzers can no longer be configured to simply look for "Shorewall:" in log messages unless the setting of LOGFORMAT is changed. The manpages (and the Migration Considerations below) have been updated to describe how to locate these messages using the new "%s:%s " setting. 3) The BLACKLIST action was inadvertently omitted from Shorewall6 in Shorewall 5.1.1. That has been corrected. 5.1.4 1) This release contains defect repair through Shorewall 5.1.3.1. 2) Previously, if a Shorewall Variable ( e.g., @chain ) was the target of a conditional ?RESET directive (one that was enclosed in ?if... ?else...?endif logic), the compiler could incorrectly use an existing chain created from the action rather than creating a new (and different) chain. That has been corrected. 3) Previously, if alternate input format specified a column that had already been specified, the contents of that column were silently overwritten. Now, a warning message is issued stating that the prior value has been replaced by the newer value. 4) Previously, a string-valued interface option, such as 'physical', could be given an empty value (e.g., "physical=,"), and the compiler would fail to flag it. Now, this usage raises an error. 5) Previously, the 'tunnel-src' and 'tunnel-dst' zone options would generate an error under Shorewall6. That has been corrected. 6) A number of small documentation corrections have been made. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 4 ---------------------------------------------------------------------------- 1) All IPv6 standard actions have been deleted and their logic has been added to their IPv4 counterparts who can now handle both address families. 2) Previously, ?error and ?require messages as well as verbose ?info and ?warning messages (those that report the file and line numbers) generated from an action file would report the action file name and line number rather than the file and line number where the action was invoked. The file and line number where the action was invoked were listed second. Beginning with this release, the invoking file and line number are listed first and the action file and line number are not reported. This allows for creation of clearer messages. Example: Previously, when an invalid value was passed for the 'bricks' parameter to the GlusterFS action on line 45 of the rules file, a message such as the following was issued (folded to 76 columns): ERROR: Invalid value for Bricks (2000) /usr/share/shorewall/action.GlusterFS (line 15) from /etc/shorewall/rules (line 45) Note that the message seems to imply that the error is in action.GlusterFS rather than in the rules file. Beginning with this release, the message will be: ERROR: Invalid value (2000) for the GlusterFS Bricks argument /etc/shorewall/rules (line 45) Note: This change only affects actions, including inline actions. Macros will continue to report the old way. 3) IPv6 UPnP support (including MINIUPNPD) is now available. 4) A PERL_HASH_SEED option has been added to allow the Perl hash seed to be specified. See shorewall.conf(5) and perlsec(1) for details. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 3 ---------------------------------------------------------------------------- 5.1.3.1 1) There was a typo in the BLACKLIST_DEFAULT settings in the 5.1.3 sample config files, which resulted in a compilation error. That typo has been corrected. 2) There was also a typo in the two-interface IPv4 sample snat file; 192.168.0.0/16 was inadvertently entered as 92.168.0.0/16. That has been corrected. 3) Previously, when processing the policy file, 'all+' was incorrectly treated the same as 'all'. That has been corrected so that 'all+' causes intra-zone traffic to be included in the policy. 5.1.3 1) This release includes defect repair for releases through 5.1.2.4. 2) The documentation for 'reload' has been corrected: - A command synopsis has been added in shorewall(8). - The command synopsis in the 'help' output has been corrected. 3) The CONFIG_PATH setting has been corrected in the IPv6 Universal sample configuration. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 3 ---------------------------------------------------------------------------- 1) The tarball installers and uninstallers have been unified and now use a common library that is included in each tarball (Matt Darfuille). 2) The installers now print a diagnostic if the relevant shorewallrc file cannot be loaded (Matt Darfuille). 3) The /etc/default/... files installed on Debian are now dependent on whether systemd is used or not (Matt Darfuille). 4) In Perl 5.8.1 and again in 5.18.0, the Perl developers altered the behavior of the hash function used in the implementation of hashes. The hash key is now chosen randomly as a defense against DOS attacks targeting Perl programs. Such attacks supply input data that causes a single hash bucket to be used. While those changes improved security, they cause non-deterministic program behavior when the 'keys', 'values' and 'each' functions are used. Prior to this release, Shorewall sorted the lists produced by those functions to ensure that consecutive compilations of the same configuration produced the same ruleset. In this release, compilation speed has been improved by removing the sort calls and by instructing Perl to use a constant hash key. Note: The ruleset produced by this release will be equivalent to that produced by 5.1.2, but will likely be different. 5) All builtin actions have been replaced with standard actions. In some cases. the standard action produces different but equivalent rules when compared to those produced by the corresponding builtin action. 6) The PROTO columns may now specify tcp:!syn (6:!syn) which matches TCP packets with the SYN flag reset or one or more of ACK, RST or FIN set. The dropNotSyn and rejNotSyn actions have been modified to use this feature. 7) During 'update', the settings of all _LEVEL and _DEFAULT options are now enclosed in quotes. This is done because these settings often contain parentheses and the .conf files are process by the shell. The sample configurations also have these settings enclosed in quotes. Update will continue to also enclose in quotes any settings that contains characters other than alphanumeric, '/', and '.'. ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 2 ---------------------------------------------------------------------------- 1) Previously, when the 5.1 CLI program was run with no command given, a shell exception was raised. That has been corrected (Tuomo Soini). 2) A caution has been added in shorewall[6]-rtrules regarding similar rules at the same priority. 3) The 'dropBcasts' builtin action now works with Shorewall6. Previously, an attempt to use that action failed with a 'missing action file' error. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 2 ---------------------------------------------------------------------------- 1) Terminology change. What we've previously referred to as "default actions" are now called "policy actions" to better describe their purpose. 2) The DROP_DEFAULT, REJECT_DEFAULT, etc. options may now specify a comma-separated list of actions rather than just a single action. The actions are invoked in the order in which they are listed and each action may optionally be followed by a colon (":") and a log level. The POLICY column in shorewall[6]-policy can now specify a similar list of actions. In that file, the list may be preceded by a plus sign ("+"), in which case the listed actions will be in addition to those listed in the related _DEFAULT setting in shorewall[6].conf. 3) With the preceding change, the Drop and Reject policy actions are now deprecated in favor of a list of smaller actions. A warning is issued when these deprecated actions are used; the warning refers the reader to http://www.shorewall.net/Actions.html#Default. 4) A LOG_LEVEL option has been added to shorewall[6].conf with default value 'info'. The sample config files have been updated to use $LOG_LEVEL rather than 'info' so that changing this option's setting will change all default packet logging. Like with any option, $LOG_LEVEL can be used throughout the configuration (with the exception of shorewall[6]-params). 5) The LIMIT column in shorewall[6]-policy has been renamed RATE for consistency with shorewall[6]-rules. No change is required to existing configurations, including those that specify 'limit' in alternate input format. 6) Beginning with this release, the allowBcast, dropBcast, and Broadcast no longer handling multicast. Multicast is handeled separately in actions allowMcast, dropMcast and Multicast. The now-deprecated Drop and Reject actions have been modified so that ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 1 ---------------------------------------------------------------------------- 1) This release contains defect repair up through Shorewall 5.1.0.1. 2) Previously, expanded variables would be enclosed in single quotes in ?ERROR, ?WARNING and ?INFO directive output. That has been corrected. 3) The obsolete Drop and Reject macros have been removed (Drop and Reject are now actions rather than macros). 4) A typo has been corrected in the parameter descriptions in action.Drop and action.Reject. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 1 ---------------------------------------------------------------------------- 1) Previously, the compiler did not check for routefilter/provider issues. Now, a fatal compilation error is raised in the following cases: a) USE_DEFAULT_RT=Yes, ROUTE_FILTER=Yes in shorewall.conf and a regular provider (not tproxy) is defined in the providers file. b) USE_DEFAULT_RT=Yes and a provider interface specifies a non-zero value for the 'routefilter' option in the interfaces file. c) USE_DEFAULT_RT=No, ROUTE_FILTER=Yes in shorewall.conf, and a provider interface doesn't specify the 'balance' or 'primary' option in the providers file. d) USE_DEFAULT_RT=No, a provider interface specifies the non-zero value for the 'routefilter' option in the interfaces file but does not specify the 'balance' or 'primary' option in the providers file. 2) When 'routefilter' is specified by itself or with a non-zero value (e.g., routefilter=1), the 'logmartians' option is now also set implicitly when LOG_MARTIANS=No. If you actually want route filtering without logging, then you must also include 'logmartians=0'. 3) Since the creation of the USE_DEFAULT_RT option, when USE_DEFAULT_RT=Yes, 'balance=1' is assumed on all provider interfaces unless 'fallback', 'load', 'primary', 'loose' or 'tproxy' is specified. This makes it awkward to define a provider that does not generate a default route in either the 'balance' or 'default' routing tables; it is necessary to specify 'loose' then add the routing rules that are suppressed by that option. To address this issue, it is now possible to specify BALANCE_PROVIDERS=No. When BALANCE_PROVIDERS=No and none of the above-listed options is specified, the provider will generate no entry in the 'balance' or 'default routing tables irrespective of the setting of USE_DEFAULT_RT. All of the released shorewall[6].conf files now specify BALANCE_PROVIDERS=No. The default value is the effective setting of USE_DEFAULT_RT to provide backward compatibility with earlier releases. 4) When using ipset-based dynamic blacklisting, it is now possible to specify BLACKLIST in the POLICY column of policy files. When BLACKLIST is specified, the source IP address is automatically added to the dynamic blacklist ipset and then the packet is dropped. This new policy adds BLACKLIST_DEFAULT to shorewall[6].conf; the default setting is "Drop". 5) A BLACKLIST action has been added; the action adds the sender to the dynamic blacklist IPSET. BLACKLIST accepts two optional argument: 1 - Action to take after adding the sender to the ipset. Default is DROP. 2 - specifies the timeout for the added/updated entry. If no timeout is passed, the one specified in DYNAMIC_BLACKLIST, if any, is used. Otherwise, the one specified when the ipset was created, if any, is used. 6) Given that there was already a BLACKLIST macro which implemented the BLACKLIST action in blrules, the preceding change required that BLACKLIST behave differently when invoked from the blrules file and when invoked from the rules file. Because BLACKLIST invoked from the rules file normally generates two rules, an action (not inlined) is more appropriate there than is a macro. When it is invoked from the blrules file, it only generates a single rule so the optimizer will inline it anyway. For historical reasons, the compiler treats the blrules file as if it were the section BLACKLIST in the rules file. So, to implement this dual behavior in the BLACKLIST action, a new 'section' option has been added in the action file. When 'section' is specified, the name of the current section and a comma are prepended to the argument list passed when invoking the action. The action.BLACKLIST file then has the following structure: ?if @1 eq 'BLACKLIST' ?else ?endif 7) There is now a 'show action ' command for Shorewall and Shorewall6. The command displays the action file for the specified . ---------------------------------------------------------------------------- P R O B L E M S C O R R E C T E D I N 5 . 1 . 0 ---------------------------------------------------------------------------- 5.1.0.1 1) Shorewall6-lite 5.1.0 failed to start under systemd. That has been corrected. 2) Previously, the setting of PAGER in shorewall[6].conf was not propagated to a remote configuration during 'export', 'remote-start', 'remote-reload' and 'remote-restart'. That has been corrected. 5.1.0 1) This release includes defect repair through Shorewall 5.0.15.2. 2) A defect associated with CHAIN_SCRIPTS=Yes previously prevented some of the optimizations associated with optimize level 4 from being applied. Removal of the CHAIN_SCRIPT option (see below) has eliminated the defect. 3) The install.sh and uninstall.sh have had some minor cleanup (Matt Darfeuille). 4) Previously, when SAVE_IPSETS=Yes or SAVE_IPSETS=ipv4, the restore phase of a rejected safe-restart would fail. That has been corrected. 5) It is now possible to include compact IPv6 addresses (those with "::") in IP6TABLES() parameters. Previously, such addresses resulted in an "INVALID ACTION..." error. ---------------------------------------------------------------------------- N E W F E A T U R E S I N 5 . 1 . 0 ---------------------------------------------------------------------------- 1) Shorewall 5.1 now has a single CLI program, ${SBINDIR}/shorewall (normally /sbin/shorewall). This program performs all of the same functions previously performed by /sbin/shorewall, /sbin/shorewall6, /sbin/shorewall-lite and /sbin/shorewall6-lite and is installed as part of the Shorewall-core package. It's default 'personality' is determined by the Shorewall packages installed: a) If the Shorewall package is installed, then by default, /sbin/shorewall behaves as in prior versions. b) If the Shorewall package is not installed, but the Shorewall-lite package is present, then /sbin/shorewall behaves as did /sbin/shorewall-lite in prior versions. c) If neither the Shorewall nor Shorewall-lite packages are installed, but the Shorewall6-lite package is installed, then /sbin/shorewall behaves as did /sbin/shorewall6-lite in prior versions. The program's personality can be altered through use of two new options. -6 When specified, changes the personality from Shorewall to Shorewall6 or from Shorewall-lite to Shorewall6-lite. -l When specified, changes the personality from Shorewall to Shorewall-lite or from Shorewall6 to Shorewall6-lite. This option is only required when both the standard package (Shorewall or Shorewall6) and the corresponding -lite package are installed on the system. The following is a comparison of Shorewall 5.0 and Shorewall 5.1 with respect to the CLI invocation: All four packages installed: Shorewall 5.0 Shorewall 5.1 shorewall shorewall shorewall6 shorewall -6 shorewall-lite shorewall -l shorewall6-lite shorewall -6l Only Shorewall-lite and Shorewall6-lite installed: Shorewall 5.0 Shorewall 5.1 shorewall-lite shorewall shorewall6-lite shorewall -6 A single shorewall(8) manpage now describes the CLI. The shorewall6(8), shorewall-lite(8) and shorewall6-lite(8) manpages are now minimal and refer the reader to shorewall(8). For backward compatibility, Shorewall6, Shorewall-lite and Shorewall6-lite install symlinks $SBINDIR/shorewall6, $SBINDIR/shorewall-lite and $SBINDIR/shorewall6-lite respectively. When the shorewall program is invoked through one of these symlinks, it adopts the appropriate personality. 2) Several settings in the default/sample .conf files have been modified: a) The LOGFORMAT setting has been changed from "Shorewall:%s:%s:" to "%s %s " to enable longer zone names. b) The LOGLIMIT setting has been changed from empty to "s:1/sec:10", to enable log trottling by default. c) The AUTOMAKE setting has been changed from "No" to "Yes", to avoid unnecessary recompilation. d) The IP_FORWARDING setting has been changed from "On" to "Keep" in shorewall.conf to accomodate cases where forwarding has been configured before installing Shorewall. e) The OPTIMIZE setting has been changed to "All", to create more compact rulesets by default. f) TC_CLEAR has been set to "No" in the shorewall6.conf files. 3) The allowed syntax in the SOURCE and DEST columns in the rules file has been extended to allow multiple comma-separated :[:][] tupples in a single rule. Where the lists mulitiple addresses separated by commas, the must be enclosed in parentheses. Example: net:(1.2.3.4,2.3.4.5),dmz:(5.6.7.8,6.7.8.9) See shorewall[6]-rules(5) for details. A similar change has been made to the conntrack and mangle files, where multiple : groups can be specified: Example: eth0:(1.2.3.4,2.3.4.5),eth1(5.6.7.8,6.7.8.9) See shorewall[6]-conntrack(5) and shorewall[6]-mangle(5) for details. 5) The CHAIN_SCRIPTS option in the .conf files has been eliminated, and the compiler no longer looks for script files with the same name as a chain or action. If you are using such files, you will need to convert them into equivalent ?begin perl .... ?end perl text or to use the IP[6]TABLES target and/or inline matches. See http://www.shorewall.org/Shorewall-5.html#idp41228128. 5) The --queue-cpu-fanout NFQUEUE option is now supported in NFQUEUE rules and policies. It is enabled by following the high queue number with the letter 'c' (e.g., NFQUEUE(0:3c)). This option requires 'NFQUEUE CPU Fanout' support in your kernel and ip[6]tables. 6) A SWITCH column has been added to the mangle files. See shorewall[6]-mangle(5) for details. 7) A 'show ipsec' command has been added. This command displays the contents of the IPSEC "Security Policy Database" (SPD) and "Security Association Database" (SAD). SAD keys are not shown. 8) The Netfilter team have removed support for the rawpost table, so Shorewall no longer supports features requiring that table (stateless netmapping in the netmap file). The good news is that, since kernel 3.7, Netfilter supports stateful IPv6 network mapping which is now also supported in Shorewall6 (see shorewall6-netmap(5)). 9) In the released tarballs, the action.* files now reside in a separate Actions/ directory. 10) The 'echo' builtin in recent versions of the dash shell does not support the -n option. To accomodate that version, Shorewall no longer uses either the -e or -n options. 11) When LOAD_HELPERS_ONLY=No, additional modules required for NAT are now loaded. 12) The (undocumented) Makefiles haven't been maintained for many releases and have been removed. 1