Beginning with Shorewall 4.6.0, section headers are now preceded by '?' (e.g., '?SECTION ...'). If your configuration contains any bare 'SECTION' entries, the following warning is issued:

WARNING: 'SECTION' is deprecated in favor of '?SECTION' - consider running 'shorewall update -D' ...

As mentioned in the message, running 'shorewall[6] update -D' will eliminate the warning.

Beginning with Shorewall 4.6.0, the 'tcrules' file has been superseded by the 'mangle' file. Existing 'tcrules' files will still be processed, with the restriction that TPROXY is no longer supported in FORMAT 1. If your 'tcrules' file has non-commentary entries, the following warning message is issued:

WARNING: Non-empty tcrules file (...); consider running 'shorewall update -t'

See shorewall(8) for limitations of 'update -t'.

The default value LOAD_HELPERS_ONLY is now 'Yes'.

Beginning with Shorewall 4.5.0, FORMAT-1 actions and macros are deprecated and a warning will be issued for each FORMAT-1 action or macro found.

WARNING: FORMAT-1 actions are deprecated and support will be dropped in a future release.

WARNING: FORMAT-1 macros are deprecated and support will be dropped in a future release.

To eliminate these warnings, add the following line before the first rule in the action or macro:

?FORMAT 2

and adjust the columns appropriately. FORMAT-1 actions have the following columns:

while FORMAT-2 actions have these columns:

FORMAT-1 macros have the following columns:

while FORMAT-2 macros have the following columns:

Shorewall, Shorewall6, Shorewall-lite and Shorewall6-lite now depend on the new package Shorewall-core. If you use the Shorewall installers, you must install Shorewall-core prior to installing or upgrading any of the other packages.

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.

This version of Shorewall requires the Digest::SHA1 or the Digest:SHA Perl module.

The generated firewall script now maintains the /var/lib/shorewall[6][-lite]/interface.status files used by SWPING and by LSM.

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:

When VARDIR is set in /etc/shorewall[6]/vardir, the product will save its state directly in the specified directory.

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 they are to be processed only if TC_ENABLED=Internal, then enclose them in

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.

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.

If the 'notrack' file is non-empty, a warning message is issued during compilation:

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

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.

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:

The Shorewall-core installer will automatically update ~/.shorewallrc and save the original in ~/.shorewallrc.bak.

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).

Beginning with Shorewall 4.5.11, ?FORMAT is preferred over FORMAT for specifying the format of records in these configuration files:

The first instance of 'FORMAT' (without the '?') will generate this warning:

As the warning suggests, 'shorewall[6] update -D' will convert all instances of FORMAT to ?FORMAT in files on the CONFIG_PATH.

Also beginning with Shorewalll 4.5.11, ?COMMENT is preferred over COMMENT for specifying comments to be attached to generated Netfilter rules in the following files:

The first instance of 'COMMENT' (without the '?') will generate this warning:

As the warning suggests, 'shorewall[6] update -D' will convert all instances of COMMENT to ?COMMENT in files on the CONFIG_PATH.

Also beginning with Shorewalll 4.5.11, ?COMMENT is preferred over COMMENT for specifying comments to be attached to generated Netfilter rules in the following files:

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.

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.

If you are using Shorewall-perl, there are no additional upgrade issues. If you are using Shorewall-shell or are upgrading from a Shorewall version earlier than 4.0.0 then you will need to migrate to Shorewall-perl. Shorewall-4.3.5 and later only use the perl-based compiler.

If you have specified "SHOREWALL_COMPILER=shell" in shorewall.conf, then you must either:

Failure to do so will result in the following warning:

The shorewall stop, shorewall clear, shorewall6 stop and shorewall6 clear commands no longer read the routestopped file. The routestopped file used is the one that was present at the last start, restart or restore command.

The old macro parameter syntax (e.g., SSH/ACCEPT) is now deprecated in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.3 documentation uses the new syntax exclusively, although the old syntax continues to be supported.

Support for the SAME target in /etc/shorewall/masq and /etc/shorewall/rules has been removed, following the removal of the underlying support in the Linux kernel.

Supplying an interface name in the SOURCE column of /etc/shorewall/masq is now deprecated. Entering the name of an interface there will result in a compile-time warning:

WARNING: Using an interface as the masq SOURCE requires the interface to be up and configured when Shorewall starts/restarts

To avoid this warning, replace interface names by the corresponding netwok(s) in CIDR format (e.g., 192.168.144.0/24).

Previously, Shorewall has treated traffic shaping class IDs as decimal numbers (or pairs of decimal numbers). That worked fine until IPMARK was implemented. IPMARK requires Shorewall to generate class Ids in numeric sequence. In 4.3.9, that didn't work correctly because Shorewall was generating the sequence "..8,9,10,11..." when the correct sequence was "...8,9,a,b,...". Shorewall now treats class IDs as hex, like 'tc' and 'iptables' do.

This should only be an issue if you have more than 9 interfaces defined in /etc/shorewall/tcdevices and if you use class IDs in /etc/shorewall/tcrules. You will need to renumber the class IDs for devices 10 and greater.

Support for the 'norfc1918' interface and host option has been removed. If 'norfc1918' is specified for an entry in either the interfaces or the hosts file, a warning is issued and the option is ignored. Simply remove the option to avoid the warning.

Similarly, if RFC1918_STRICT=Yes or a non-empty RFC1918_LOG_LEVEL is given in shorewall.conf, a warning will be issued and the option will be ignored.

You may simply delete the RFC1918-related options from your shorewall.conf file if you are seeing warnings regarding them.

Users who currently use 'norfc1918' are encouraged to consider using NULL_ROUTE_RFC1918=Yes instead.

The install.sh scripts in the Shorewall and Shorewall6 packages no longer create a backup copy of the existing configuration. If you want your configuration backed up prior to upgrading, you will need to do that yourself. As part of this change, the fallback.sh scripts are no longer released.

Previously, if an ipsec zone was defined as a sub-zone of an ipv4 or ipv6 zone using the special <child>:<parent>,... syntax, CONTINUE policies for the sub-zone did not work as expected. Traffic that was not matched by a sub-zone rule was not compared against the parent zone(s) rules. In 4.4.0, such traffic IS compared against the parent zone rules.

The name any is now reserved and may not be used as a zone name.

Perl module initialization has changed in Shorewall 4.4.1. Previously, each Shorewall Perl package would initialize its global variables for IPv4 in an INIT block. Then, if the compilation turned out to be for IPv6, Shorewall::Compiler::compiler() would reinitialize them for IPv6.

Beginning in Shorewall 4.4.1, the modules do not initialize themselves in an INIT block. So if you use Shorewall modules outside of the Shorewall compilation environment, then you must explicitly call the module's 'initialize' function after the module has been loaded.

Checking for zone membership has been tighened up. Previously, a zone could contain <interface>:0.0.0.0/0 along with other hosts; now, if the zone has <interface>:0.0.0.0/0 (even with exclusions), then it may have no additional members in /etc/shorewall/hosts.

ADD_IP_ALIASES=No is now the setting in the released shorewall.conf and in all of the samples. This will not affect you during upgrade unless you choose to replace your current shorewall.conf with the one from the release (not recommended).

The names of interface configuration variables in generated scripts have been changed to ensure uniqueness. These names now begin with SW_. This change will only affect you if your extension scripts are using one or more of these variables.

were iface is a capitalized interface name (e.g., ETH0) and provider is the capitalized name of a provider.

If your /etc/shorewall/params (or /etc/shorewall6/params) file sends output to Standard Output, you need to be aware that the output will be redirected to Standard Error beginning with Shorewall 4.4.16.

Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is deprecated. With EXPORTPARAMS=No, the variables set by /etc/shorewall/params (/etc/shorewall6/params) at compile time are now available in the compiled firewall script.

The iprange and ipaddr commands require the 'bc' utility.

Beginning with Shorewall 4.4.26, the WIDE_TC_MARKS and HIGH_ROUTE_MARKS options are deprecated in favor of TC_BITS, MASK_BITS, PROVIDER_BITS and PROVIDER_OFFSET. See the Packet Marking using /etc/shorewall/tcrules article. The shorewall update (shorewall6 update) command will automatically generate the correct values for these new options depending on your settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS.

Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero mark values < 256 to be assigned in the OUTPUT chain. This has been changed so that only high mark values may be assigned there. Packet marking rules for traffic shaping of packets originating on the firewall must be coded in the POSTROUTING table.

Previously, Shorewall did not range-check the value of the VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2: a) A VERBOSITY setting outside the range -1 through 2 is rejected. b) After the -v and -q options are applied, the resulting value is adjusted to fall within the range -1 through 2.

Specifying a destination zone in a NAT-only rule now generates a warning and the destination zone is ignored. NAT-only rules are:

The default value for LOG_MARTIANS has been changed. Previously, the defaults were: Shorewall-perl - 'Off' Shorewall-shell - 'No' The new default values are:

Shorewall-perl users may:

Shorewall-shell users may:

The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has been changed from Yes to No. If you are a Debian or Ubuntu user and you select replacement of shorewall.conf during upgrade to Shorewall 4.2, you will want to change IMPLICIT_CONTINUE back to 'Yes' if you have nested zones that rely on IMPLICIT_CONTINUE=Yes for proper operation.

The 'norfc1918' option is deprecated. Use explicit rules instead. Note that there is a new 'Rfc1918' macro that acts on addresses reserved by RFC 1918.

DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use ipset-based zones instead.

Beginning with Shorewall 4.0.0, there is no single 'shorewall' package. Rather there are two compiler packages (shorewall-shell and shorewall-perl) and a set of base files (shorewall-common) required by either compiler package.

Although the names of the packages are changing, you can upgrade without having to uninstall/reinstall.

To repeat: You do not need to uninstall any existing package.

If you attempt to upgrade using the shorewall-common RPM, you get this result:

gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm 
error: Failed dependencies:
shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch
gateway:~ #

You must either:

rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpm

or

rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-perl-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpm

If you don't want shorewall-shell, you must use the second command (installing both shorewall-shell and shorewall-perl) then remove shorewall-shell using this command:

rpm -e shorewall-shell

If you are upgrading using the tarball, you must install shorewall-shell and/or shorewall-perl before you upgrade using shorewall-common. Otherwise, the install.sh script fails with:

The shorewall-shell and shorewall-perl packages are installed from the tarball in the expected way; untar the package, and run the install.sh script.

Example 1: You have 'shorewall' installed and you want to continue to use the shorewall-shell compiler.

tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-shell-4.0.0.tar.bz2

pushd shorewall-shell-4.0.0
./install.sh
popd
pushd shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restart

Example 2: You have shorewall 3.4.4 and shorewall-perl 4.0.0-Beta7 installed and you want to upgrade to 4.0. You do not need the shell-based compiler.

tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-perl-4.0.0.tar.bz2

pushd shorewall-perl-4.0.0
./install.sh
popd
pushd /shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restart

The RPMs are set up so that if you upgrade an existing Shorewall installation as part of a distribution upgrade and you have not already installed shorewall-perl, then you will end up with Shorewall-common and Shorewall-shell installed.

The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work slightly differently in Shorewall 4.0.0. In prior releases, leaving these options empty was equivalent to setting them to 'No' which caused the corresponding flag in /proc to be reset for all interfaces. Beginning in Shorewall 4.0.0, leaving these options empty causes Shorewall to leave the flags in /proc as they are. You must set the option to 'No' in order to obtain the old behavior.

The :noah option is now the default for ipsec tunnels. Tunnels that use AH (protocol 51) must specify ipsec:ah in the TYPE column.

Users upgrading from Debian Etch (Shorewall 3.2.6) to Debian Lenny (Shoreall 4.0.15) report finding an issue with VOIP (Asterisk) traffic. See Shorewall FAQ 77 for details.

Shorewall supports the notion of "default actions". A default action defines a set of rules that are applied before a policy is enforced. Default actions accomplish two goals:

In prior Shorewall versions, default actions (action.Drop and action.Reject) were defined for DROP and REJECT policies in /usr/share/shorewall/actions.std. These could be overridden in /etc/shorewall/actions.

This approach has two drawbacks:

If you have not overridden the defaults using entries in /etc/shorewall/actions then you need make no changes to migrate to Shorewall version 3.4. If you have overridden either of these entries, then please read on.

The change in version 3.4 is two-fold:

Example:

#SOURCE         DEST            POLICY          LOGLEVEL
loc             net             ACCEPT
net             all             DROP:MyDrop     info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all             all             REJECT:MyReject info

The 'Limit' action is now a builtin. If you have 'Limit' listed in /etc/shorewall/actions, remove the entry. Also remove the files /etc/shorewall/action.Limit and/or /etc/shorewall/Limit if you have them.

This issue only applies if you have entries in /etc/shorewall/providers.

Previously, Shorewall has not attempted to undo the changes it has made to the firewall's routing as a result of entries in /etc/shorewall/providers and /etc/shorewall/routes. Beginning with this release, Shorewall will attempt to undo these changes. This change can present a migration issue in that the initial routing configuration when this version of Shorewall is installed has probably been changed by Shorewall already. Hence, when Shorewall restores the original configuration, it will be installing a configuration that the previously-installed version has already modified.

The steps to correcting this after you have installed version 3.4 or later of Shorewall are as follows:

This issue only applies if you run Shorewall Lite.

The /etc/shorewall-lite/shorewall.conf file has been renamed /etc/shorewall-lite/shorewall-lite.conf. When you upgrade, your shorewall.conf file will be renamed shorewall-lite.conf.

If you are upgrading from version 2.4 or earlier, please read the 3.0.0 upgrade considerations below.

A number of macros have been split into two. The macros affected are:

Each of these macros now handles only traffic on the native (plaintext) port. There is a corresponding macro with S added to the end of the name for the SSL version of the same protocol. Thus each macro results in the insertion of only one port per invocation. The Web macro has not been split, but two new macros, HTTP and HTTPS have been created. The Web macro is deprecated in favour of these new macros, and may be removed from future Shorewall releases.

These changes have been made to ensure no unexpected ports are opened due to the use of macros.

In previous Shorewall releases, DNAT and REDIRECT rules supported a special syntax for exclusion of a subnet from the effect of the rule.

Example:

That feature has never worked correctly when Z2 is a dynamic zone. Furthermore, now that Shorewall supports exclusion lists, the capability is redundant since the above rule can now be written in the form:

DNAT     Z1:!<list of exclusions>   loc:192.168.1.4   ...

Beginning with Shorewall 3.2.0, the special exclusion syntax will no longer be supported.

Important if you use the QUEUE target.

In the /etc/shorewall/rules file and in actions, you may now specify 'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also requires that the SYN flag is set and the RST, FIN and ACK flags be off ("--syn" is added to the iptables rule).

As part of this change, Shorewall no longer adds the "--syn" option to TCP rules that specify QUEUE as their target.

Extension Scripts may require change

In previous releases, extension scripts were executed during [re]start by using the Bourne Shell "." operator. In addition to executing commands during [re]start, these scripts had to "save" the commands to be executed during shorewall restore.

This clumsiness has been eliminated in Shorewall 3.2. In Shorewall 3.2, extension scripts are copied in-line into the compiled program and are executed in-line during start, restart and restore. This applies to all extension scripts except those associated with a chain or action -- those extension scripts continue to be processed at compile time.

This new approach has two implications for existing scripts.

Beginning with this release, the way in which packet marking in the PREROUTING chain interacts with the 'track' option in /etc/shorewall/providers has changed in two ways:

Kernel version 2.6.16 introduces 'xtables', a new common packet filtering and connection tracking facility that supports both IPv4 and IPv6. Because a different set of kernel modules must be loaded for xtables, Shorewall now includes two 'modules' files:

If you wish to use the new file, then simply execute this command:

cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules

(Versions >= 3.2.3) Previously, CLASSIFY tcrules were always processed out of the POSTROUTING chain. Beginning with this release, they are processed out of the POSTROUTING chain *except* when the SOURCE is $FW[:<address>] in which case the rule is processed out of the OUTPUT chain.

With correctly-coded rulesets, this change should have no effect. Users having incorrectly-coded tcrules may need to change them.

Example:

While the user may have expected this rule to only affect traffic from the firewall itself, the rule was really equivalent to this one:

So after this change, the second rule will be required rather than the first if that is what was really wanted.

The "monitor" command has been eliminated.

The "DISPLAY" and "COMMENTS" columns in the /etc/shorewall/zones file have been removed and have been replaced by the former columns of the /etc/shorewall/ipsec file. The latter file has been removed.

Additionally the FW option in shorewall.conf has been deprecated and is no longer set to 'fw' by default. New users are expected to define the firewall zone in /etc/shorewall/zones.

Adhering to the principle of least astonishment, the old /etc/shorewall/ipsec file will continue to be supported. A new IPSECFILE variable in /etc/shorewall/shorewall.conf determines the name of the file that Shorewall looks in for IPSEC information. If that variable is not set or is set to the empty value then IPSECFILE=ipsec is assumed. So if you simply upgrade and don't do something idiotic like replace your current shorewall.conf file with the new one, your old configuration will continue to work. A dummy 'ipsec' file is included in the release so that your package manager (e.g., rpm) won't remove your existing file.

The shorewall.conf file included in this release sets IPSECFILE=zones so that new users are expected to use the new zone file format.

The DROPINVALID option has been removed from shorewall.conf. The behavior will be as if DROPINVALID=No had been specified. If you wish to drop invalid state packets, use the dropInvalid built-in action.

The 'nobogons' interface and hosts option as well as the BOGON_LOG_LEVEL option have been eliminated.

Most of the standard actions have been replaced by parameterized macros (see below). So for example, the action.AllowSMTP and action.DropSMTP have been removed an a parameterized macro macro.SMTP has been added to replace them.

In order that current users don't have to immediately update their rules and user-defined actions, Shorewall can substitute an invocation of the a new macro for an existing invocation of one of the old actions. So if your rules file calls AllowSMTP, Shorewall will replace that call with SMTP(ACCEPT). Because this substitution is expensive, it is conditional based on the setting of MAPOLDACTIONS in shorewall.conf. If this option is set to YES or if it is not set (such as if you are using your old shorewall.conf file) then Shorewall will perform the substitution. Once you have converted to use the new macros, you can set MAPOLDACTIONS=No and invocations of those actions will go much quicker during 'shorewall [re]start'.

The STATEDIR variable in /etc/shorewall/shorewall.conf has been removed. STATEDIR is now fixed at /var/lib/shorewall. If you have previously set STATEDIR to another directory, please copy the files from that directory to /var/lib/shorewall/ before [re]starting Shorewall after the upgrade to this version.

The "shorewall status" command now just gives the status of Shorewall (started or not-started). The previous status command has been renamed "dump". The command also shows the state relative to the state diagram at http://shorewall.org/starting_and_stopping_shorewall.htm. In addition to the state, the time and date at which that state was entered is shown.

Note that at least one "shorewall [re]start" must be issued after upgrading to this release before "shorewall status" will show anything but "Unknown" for the state.

The "shorewall forget" command now removes the dynamic blacklist save file (/var/lib/shorewall/save).

In previous versions of Shorewall, the rules generated by entries in /etc/shorewall/tunnels preceded those rules generated by entries in /etc/shorewall/rules. Beginning with this release, the rules generated by entries in the tunnels file will appear *AFTER* the rules generated by the rules file. This may cause you problems if you have REJECT, DENY or CONTINUE rules in your rules file that would cause the tunnel transport packets to not reach the rules that ACCEPT them. See https://shorewall.org/VPNBasics.html for information on the rules generated by entries in the tunnels file.

The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been removed as have the 'newnotsyn' options in /etc/shorewall/interfaces and /etc/shorewall/hosts.

TCP new-not-syn packets may be blocked using the 'dropNotSyn' or 'rejNotSyn' built-in actions.

Example: Reject all new-not-syn packets from the net and log them at the 'info' level.

#ACTION          SOURCE           DEST           PROTO
SECTION NEW
rejNotSyn:info   net              all            tcp

Note that the rule is added at the front of the NEW section of the rules file.

A new TC_SCRIPT option replaces TC_ENABLED in shorewall.conf. If the option is not set then the internal shaper (tc4shorewall by Arne Bernin) is used. Otherwise, the script named in the variable is used.

Users who currently use an /etc/shorewall/tcstart file and wish to continue to do so should set TC_SCRIPT=/etc/shorewall/tcstart in shorewall.conf.

Shorewall now enforces the restriction that mark values used in /etc/shorewall/tcrules are less than 256. If you are using mark values >= 256, you must change your configuration before you upgrade.

The value "ipp2p" is no longer accepted in the PROTO column of the /etc/shorewall/rules file. This support has never worked as intended and cannot be made to work in a consistent way. A "Howto" article on filtering P2P with Shorewall and ipp2p will be forthcoming.

LEAF/Bering packages for 2.4.0 and later releases are not available from shorewall.net. See the LEAF site for those packages.