These are the problems corrected since Shorewall 1.4.8 There has been a low continuing level of confusion over the terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all instances of "Static NAT" have been replaced with "One-to-one NAT" in the documentation and configuration files. The description of NEWNOTSYN in shorewall.conf has been reworded for clarity. Wild-card rules (those involving "all" as SOURCE or DEST) will no longer produce an error if they attempt to add a rule that would override a NONE policy. The logic for expanding these wild-card rules now simply skips those (SOURCE,DEST) pairs that have a NONE policy.

None.

These are the new features added since Shorewall 1.4.8 To cut down on the number of "Why are these ports closed rather than stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def have been changed from 'reject' to 'DROP'. For easier identification, packets logged under the 'norfc1918' interface option are now logged out of chains named 'rfc1918'. Previously, such packets were logged under chains named 'logdrop'. Distributors and developers seem to be regularly inventing new naming conventions for kernel modules. To avoid the need to change Shorewall code for each new convention, the MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names in your particular distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz". To see what suffix is used by your distribution: ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter All of the files listed should have the same suffix (extension). Set MODULE_SUFFIX to that suffix. Examples: If all files end in ".kzo" then set MODULE_SUFFIX="kzo" If all files end in ".kz.o" then set MODULE_SUFFIX="kz.o" Support for user defined rule ACTIONS has been implemented through two new files: /etc/shorewall/actions - used to list the user-defined ACTIONS./etc/shorewall/action.template - For each user defined <action>:copy this file to /etc/shorewall/action.<action>Add the appropriate rules in that file for the <action>.Once an <action> has been defined, it may be used like any of the builtin ACTIONS (ACCEPT, DROP, etc.) in /etc/shorewall/rules. Example: You want an action that logs a packet at the 'info' level and accepts the connection. In /etc/shorewall/actions, you would add: LogAndAccept You would then copy /etc/shorewall/action.template to /etc/shorewall/action.LogAndAccept and in that file, you would add the two rules: LOG:info ACCEPT