The Perl-based compiler requires multiport match in your kernel and iptables.

BRIDGING=Yes is not supported. The kernel code necessary to support this option was removed in Linux kernel 2.6.20. Alternative bridge support is provided by Shorewall-perl.

DYNAMIC_ZONES=Yes is not supported in Shorewall-perl 4.2. Use an ipset to define your dytnamic zones. In Shorewall 4.4, dynamic zone support based on ipsets was added to Shorewall.

The BROADCAST column in the interfaces file is essentially unused if your kernel/iptables has Address Type Match support. If that support is present and you enter anything in this column but '-' or 'detect', you will receive a warning.

The 'refresh' command is now similar to restart with the exceptions that:

With the shell-based compiler, extension scripts were copied into the compiled script and executed at run-time. In many 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, your 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 Shorweall-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-perl:

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.

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. I've 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.

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

Shorewall is now out of the ipset load/reload business with the exception of ipsets used for dynamic zones. With scripts generated by the Perl-based Compiler, the Netfilter rule set is never cleared. That means that there is no opportunity for Shorewall to load/reload your ipsets since that cannot be done while there are any current rules using ipsets.

So:

As a consequence, scripts generated by the Perl-based compiler will ignore /etc/shorewall/ipsets and will issue a warning if you set SAVE_IPSETS=Yes in shorewall.conf.

Because the configuration files (with the exception of /etc/shorewall/params) are now processed by the Shorewall-perl compiler rather than by the shell, only the basic forms of Shell expansion ($variable and ${variable}) are supported. The more exotic forms such as ${variable:=default} are not supported. Both variables defined in /etc/shorewall/params and environmental variables (exported by the shell) can be used in configuration files.

USE_ACTIONS=No is not supported. That option is intended to minimize Shorewall's footprint in embedded applications. As a consequence, Default Macros are not supported by Shorewall-perl.

DELAYBLACKLISTLOAD=Yes is not supported. The entire rule set is atomically loaded with one execution of iptables-restore.

MAPOLDACTIONS=Yes is not supported. People should have converted to using macros by now.

The pre Shorewall-3.0 format of the zones file is not supported (IPSECFILE=ipsec); neither is the /etc/shorewall/ipsec file.

BLACKLISTNEWONLY=No is not permitted with FASTACCEPT=Yes. This combination doesn't work in previous versions of Shorewall so the Perl-based compiler simply rejects it.

Shorewall-perl has a single rule generator that is used for all rule-oriented files. This implementation enforces consistency of syntax between files.

With shorewall-shell, there is a special syntax in the SOURCE column of /etc/shorewall/masq to designate "all traffic entering the firewall on this interface except...".

Example:

#INTERFACE       SOURCE                  ADDRESSES
eth0             eth1!192.168.4.9        ...

Shorewall-perl uses syntax that is consistent with the rest of Shorewall:

#INTERFACE       SOURCE                  ADDRESSES
eth0             eth1:!192.168.4.9       ...

The 'allowoutUPnP' built-in action is no longer supported. In kernel 2.6.14, the Netfilter team have removed support for '-m owner --owner-cmd' which that action depended on.

The PKTTYPE option is ignored by Shorewall-perl. Shorewall-perl will use Address type match if it is available; otherwise, it will behave as if PKTTYPE=No had been specified.

Shorewall-perl 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 accepts the above even though the loc->net policy is useless. Shorewall-perl generates a fatal compilation error.

In the SOURCE column of the rules file, when an interface name is followed by a list of IP addresses, the behavior of Shorewall-perl differs from that of Shorewall-shell.

Example:

#ACTION SOURCE                                 DEST PROTO DEST
#                                                         PORT(S)
ACCEPT  loc:eth0:192.168.1.3,192.168.1.5       $FW  tcp   22

With Shorewall-shell, this rule accepts SSH connection to the firewall from 192.168.1.3 through eth0 or from 192.168.1.5 through any interface. With Shorewall-perl, the rule accepts SSH connections through eth0 from 192.168.1.3 and through eth0 from 192.168.1.5. Shorewall-shell supports this syntax that gives the same result as Shorewall-perl.

#ACTION SOURCE                                 DEST PROTO DEST
#                                                         PORT(S)
ACCEPT loc:eth0:192.168.1.3,eth0:192.168.1.5   $fw  tcp   22

Shorewall-perl does not support this alternative syntax.

Shorewall-perl gives a warning if a zone name is entered in the DEST column of a nonat rule. Nonat rules include:

So rather than this:

#ACTION            SOURCE             DEST             PROTO        DEST PORT(S)
DNAT-              net                loc:192.168.1.3  tcp          21

you instead want:

#ACTION            SOURCE             DEST             PROTO        DEST PORT(S)
DNAT-              net                192.168.1.3      tcp          21

Supplying an interface name in the SOURCE column of /etc/shorewall/masq is deprecated as of Shorewall 4.4. 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 network addresses (e.g., 192.168.144.0/24).