The Perl-based compiler requires the following capabilities in your kernel and iptables.

These capabilities are in current distributions.

Now that Netfilter has features to deal reasonably with port lists, I see no reason to duplicate those features in Shorewall. The Shorewall-shell compiler goes to great pain (in some cases) to break very long port lists ( > 15 where port ranges in lists count as two ports) into individual rules. In the new compiler, I'm avoiding the ugliness required to do that. The new compiler just generates an error if your list is too long. It will also produce an error if you insert a port range into a port list and you don't have extended multiport support.

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.

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 exceptios 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 ruleset 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 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 scripts generated by the Perl-based Compiler, the Netfilter ruleset 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.

DELAYBLACKLISTLOAD=Yes is not supported. The entire ruleset 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. So it is important that the syntax is consistent 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 4.0.0 requires Address type match. Shorewall-perl versions 4.0.1 and later will use Address type match if it is available; otherwise, they 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

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.