As always, when upgrading from one major release of Shorewall to another, the installer will prompt you about replacing your existing shorewall.conf with the updated one from the package. Shorewall is designed with the assumption that users will never replace shorewall.conf and retaining your existing file will always produce upward-compatible behavior.

That having been said, there are a few settings that you may have in your shorewall.conf that will cause compilation warning or error messages after the upgrade.

If the column headings in your /etc/shorewall/zones file look like this:

#ZONE   DISPLAY         COMMENTS
net     Net             The big bad net
loc     Local           The local LAN

then you are using the original zones file format that has been deprecated since Shorewall 3.0.

You will need to convert to the new file format which has the following headings:

#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS

You will need to add an entry for your firewall zone. The default name for the firewall zone is 'fw' but may have been overriden in your old configuration using the FW option in shorewall.conf.

#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall

The remainder of your zones will have type 'ipv4' unless they are mentioned in your /etc/shorewall/ipsec file (see below).

#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
net     ipv4            # The big bad net
loc     ipv4            # The local LAN

This file is no longer used -- its specifications are now included in /etc/shorewall/zones.

Take this example:

#ZONE   IPSEC    OPTIONS         IN              OUT
#       ONLY                     OPTIONS         OPTIONS
ipsec1  Yes
ipsec2  No

This would translate to the following entries in /etc/shorewall/zones:

#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
ipsec1  ipsec4
ipsec2  ipv4

Any OPTIONS, IN OPTIONS and OUT OPTIONS should simply be copied from /etc/shorewall/ipsec to /etc/shorewall/zones.

The BROADCAST column is essentially unused in Squeeze. If it contains anything except 'detect' or '-', then you will receive this warning^[5]:

To eliminate the warning, replace the contents of the BROADCAST column with '-' or 'detect'.

The 'norfc1918' option has been removed. If you specify the option, you will receive the following warning:

To eliminate the warning, simply remove the 'norfc1918' option from the OPTIONS list. You may wish to consider NULL_ROUTE_RFC1918=Yes as a replacement (see shorewall.conf (5)).

The 'norfc1918' option has been removed. If you specify the option, you will receive the following warning:

To eliminate the warning, simply remove the 'norfc1918' option from the OPTIONS list. You may wish to consider NULL_ROUTE_RFC1918=Yes as a replacement (see shorewall.conf (5)).

Shorewall 4.4 detects dead policy file entries that result when an entry is masked by an earlier more general entry.

Example:

#SOURCE DEST     POLICY    LOG LEVEL
all     all      REJECT    info
loc     net      ACCEPT

Shorewall-shell silently accepted the above even though the loc->net policy is useless. Shorewall-perl generates a fatal compilation error:

There is a long tradition of specifying an interface name in the SOURCE column of this file.

Masquerading/SNAT occurs in the Netfilter POSTROUTING chain where an incoming interface may not be specified in iptables rules. Consequently, while processing the shorewall start and shorewall restart commands, the generated script must examine the firewall's main routing table to determine those networks that are routed out of the interface; the script then adds a MASQUERADE/SNAT rule for connections from each of those networks. This additional processing requires the named interface to be up and configured when Shorewall starts or restarts.

Users often complain that Shorewall fails to start at boot time because a VPN interface that is named as a masq SOURCE isn't up and configured during boot.

To emphasize this restriction, if an interface is named in the SOURCE column of one or more entries, a single warning is issued as follows:

To suppress this warning, replace the interface name with the list of networks that are routed out of the interface.

Example.

Existing entry:

#INTERFACE              SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/
#                                                                                       GROUP
eth0                    eth1

Current routing configuration:

gateway:~# ip route ls dev eth1
172.20.1.0/24  proto kernel  scope link  src 172.20.1.254 
224.0.0.0/4  scope link 
gateway:~# 

Replacement entry:

#INTERFACE              SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/
#                                                                                       GROUP
eth0                    172.20.1.0/24

Note that no entry is included for 224.0.0.0/4 since that is the multicast IP range and there should never be any packets with a SOURCE IP address in that network.

If you include a destination zone in a 'nonat' rule, Shorewall issues the following warning:

Nonat rules include:

To eliminate the warning, remove the DEST zone.

Example.

Before:

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME
#                                                       PORT(S) PORT(S)         DEST            LIMIT           GROUP
NONAT           loc             net             tcp     80

After:

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME
#                                                       PORT(S) PORT(S)         DEST            LIMIT           GROUP
NONAT           loc             -               tcp     80

Shorewall 4.4 versions prior to 4.4.19 do not support icmp type lists in the DEST PORT(S) column. Only a single ICMP type may be listed. If you have a shell variable with a list of ICMP types that you use in a rule, you can work around this limitation as follows. Replace this rule:

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME
#                                                       PORT(S) PORT(S)         DEST            LIMIT           GROUP
ACCEPT          z1              z2              icmp    $ITYPES

with:

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME
#                                                       PORT(S) PORT(S)         DEST            LIMIT           GROUP

BEGIN SHELL
for type in $ITYPES; do
ACCEPT          z1              z2              icmp    $type
done
END SHELL

The 'critical' option is no longer needed and hence is no longer supported. If you have critical hosts defined, you will receive this warning:

To suppress the warning, simply remove the option.

Shorewall 4.4 also treats the routestopped file differently from earlier releases. Previously, the routestopped file was parsed during shorewall stop processing so that changes made to the file while Shorewall was running would be applied at the next stop. This is no longer the case -- the routestopped file is processed during compilation just like the rest of the configuration files so that when shorewall stop is issued, the firewall will pass traffic based on the contents of the routestopped file at the last start or restart.

If you change the routestopped file and now want to stop the firewall, you can run this sequence of commands:

shorewall compile
shorewall stop

The /etc/shorewall/tos file now has zone-independent SOURCE and DEST columns as do all other files except the rules and policy files.

The SOURCE column may be one of the following:

The DEST column may be one of the following:

This is a permanent change. The old zone-based rules have never worked right and this is a good time to replace them. We have tried to make the new syntax cover the most common cases without requiring change to existing files. In particular, it will handle the tos file released with Shorewall 1.4 and earlier.

With the shell-based compiler, all extension scripts were copied into the compiled script and executed at run-time. In some cases, this approach doesn't work with Shorewall Perl because (almost) the entire rule set is built by the compiler. As a result, Shorewall-perl runs some extension scripts at compile-time rather than at run-time. Because the compiler is written in Perl, these extension scripts from earlier versions will no longer work.

The following table summarizes when the various extension scripts are run:

Compile-time extension scripts are executed using the Perl 'eval `cat <file>`' mechanism. Be sure that each script returns a 'true' value; otherwise, the Shorewall-perl compiler will assume that the script failed and will abort the compilation.

When a script is invoked, the $chainref scalar variable will usually hold a reference to a chain table entry.

To add a rule to the chain:

Where

Example:

To insert a rule into the chain:

The log_rule_limit function works like it does in the shell compiler with three exceptions:

Example:

    log_rule_limit
              'info' , 
              $chainref , 
              $chainref->{name},
              'DROP' , 
              '',    #Limit
              '' ,   #Log tag
              'add'
              '-p tcp ';         

Here is an example of an actual initdone script used with Shorewall 3.4:

run_iptables -t mangle -I PREROUTING -p esp -j MARK --set-mark 0x50
run_iptables -t filter -I INPUT -p udp --dport 1701 -m mark --mark 0x50 -j ACCEPT
run_iptables -t filter -I OUTPUT -p udp --sport 1701 -j ACCEPT

Here is the corresponding script used with Shorewall 4.4:

use Shorewall::Chains;

insert_rule $mangle_table->{PREROUTING}, 1, "-p esp -j MARK --set-mark 0x50";
insert_rule $filter_table->{INPUT},      1, "-p udp --dport 1701 -m mark --mark 0x50 -j ACCEPT";
insert_rule $filter_table->{OUTPUT},     1, "-p udp --sport 1701 -j ACCEPT";

1;

The initdone script is unique because the $chainref variable is not set before the script is called. The above script illustrates how the $mangle_table, $filter_table, and $nat_table references can be used to add or insert rules in arbitrary chains.

Shorewall 4.4 insists that ipset names begin with a letter and be composed of alphanumeric characters, underscores (_) and dashes (-). When used in a Shorewall configuration file, the name must be preceded by a plus sign (+) as with the shell-based compiler.

Shorewall 4.4.6 re-introduced SAVE_IPSETS=Yes with slightly different semantics:

If you find that output bandwidth is extremely limited, it is likely due to TCP Segmentation Offload (TSO) and/or Generic Segmentation Offload (GSO) being enabled in the network adapter. To verify that, install the ethtool package and use the -k command:

root@gateway:~# ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
root@gateway:~#

If that is the case, you can correct the problem by adjusting the minburst setting in /etc/shorewall/tcinterfaces. We suggest starting at 10-12kb and adjust as necessary. Example:

#INTERFACE	TYPE		IN-BANDWIDTH			OUT-BANDWIDTH
eth0		External	50mbit:200kb			5.0mbit:100kb:200ms:100mbit:10kb

Alternatively, you can turn off TSO and GSO using this command in /etc/shorewall/init:

ethtool -k ethN tso off gso off