From 9d8ab415b9f01cd50c92761ca2dcae32b143deed Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 19 Jul 2007 15:14:31 +0000 Subject: [PATCH] Update news git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6906 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- web/News.htm | 1241 ++++++++++++++++++++++++++++++++++------------ web/oldnews.html | 307 ++++++++++++ 2 files changed, 1240 insertions(+), 308 deletions(-) diff --git a/web/News.htm b/web/News.htm index 98d1b5c45..88ad47d09 100644 --- a/web/News.htm +++ b/web/News.htm @@ -24,10 +24,940 @@ href="GnuCopyright.htm" target="_self">GNU Free Documentation License”.

-

July 15, 2007
+

July 15, 200

+

2007-07-20 Shorewall 4.0.0

+
----------------------------------------------------------------------------
+                   R E L E A S E  H I G H L I G H T S
+----------------------------------------------------------------------------
+1) This is the first Shorewall release that fully integrates the new
+   Shorewall-perl compiler. See the "New Features" section below.
+
+2) You are now offered a choice as to which compiler(s) you install. In
+   4.0.0, there are the following packages:
+
+   - Shorewall-common ( common files )
+   - Shorewall-shell ( the shell-based compiler )
+   - Shorewall-perl (the Perl-based compiler )
+
+   You must install at least one of the compiler packages (you may
+   install them both) along with Shorewall-common.
+
+   YOU DO NOT NEED TO UNINSTALL ANY OF YOUR CURRENT PACKAGES.
+
+   See the Migration Considerations below for further information.
+
+3) The facilities for supporting bridge/firewalls under earlier
+   releases are deprecated and their documentation is omitted from the
+   4.0 distribution. New bridge support is implemented in the
+   Shorewall-perl compiler. This support utilizes the reduced-function
+   physdev match support available in Linux kernel 2.6.20 and later.
+
+Problems corrected in 4.0.0 Final.
+
+1)  The shorewall-lite install.sh may now be run multiple times from
+    the same directory. Previously, the manpages were gzipped in-place
+    which made it impossible to rerun the script.
+
+2)  If shorewall.conf contained SHOREWALL_COMPILER=shell (which it can
+    on Shorewall 3.4.2-4 systems) and the shorewall-shell RPM was
+    removed, subsequent "shorewall [re]start" operations failed. When
+    shorewall-shell is removed, the shorewall.conf file is modified to
+    specify SHOREWALL_COMPILER= and the original is saved in
+    shorewall.conf.rpmsave.
+
+3)  The contents of the LOG LEVEL column in /etc/shorewall/policy are
+    now validated at compile time by Shorewall-perl.
+
+Other changes in Shorewall 4.0.0 Final.
+
+1)  The Perl modules in /usr/share/shorewall-perl/Shorewall/ have been
+    consolidated somewhat, leading to slightly faster compilation.
+
+Migration Considerations:
+
+1)  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)
+    which are 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 to use shorewall-perl exclusively then use the
+    second command above then
+
+        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:
+
+         ERROR: No Shorewall compiler is installed
+
+    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
+
+        cd shorewall-shell-4.0.0
+        ./install.sh
+        cd ../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
+
+        cd shorewall-perl-4.0.0
+        ./install.sh
+        cd ../shorewall-common-4.0.0
+        ./install.sh
+        shorewall check
+        shorewall restart
+
+        Be sure to modify shorewall.conf if it still has
+        SHOREWALL_COMPILER=shell.
+
+2)  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.
+
+3)  The -f option is no longer the default when Shorewall is started at
+    boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
+    "shorewall start" is nearly as fast as "shorewall restore" and
+    "shorewall start" uses the current configuration which avoids
+    confusion.
+
+    If you plan on continuing to use Shorewall-shell and you want to
+    use the "-f" option at boot time, then you must add the following
+    to /etc/sysconfig/shorewall or /etc/default/shorewall:
+
+       OPTIONS="-f"
+
+    If you currently have neither of those files, you will need to
+    create one of them. 
+
+4)  This issue will only affect you if you use Shorewall Lite and have
+    modified /usr/share/configpath to specify a different LITEDIR.
+
+    The implementation of LITEDIR has always been
+    unsatisfactory. Furthermore, there have been other cases where
+    people have asked to be able to designate the state directory
+    (default /var/lib/shorewall[-lite]).
+
+    To meet these objectives:
+
+    a)  The LITEDIR variable has been eliminated in
+        /usr/share/shorewall[-lite]/configpath.
+
+    b)  A new file /etc/shorewall[-lite]/vardir has been added. This
+        file is not created by default but may be added as needed. It
+        is expected to contain a single variable assignment:
+
+           VARDIR=<directory>
+
+        Example:
+
+           VARDIR=/root/shorewall
+    
+    To change VARDIR, copy the old directory to the new one before you
+    restart Shorewall[-lite].
+
+    To use this feature with Shorewall-lite, all packages involved
+    (compiler, shorewall-common and shorewall-lite) must be version
+    4.0.0-RC2 or later.
+
+----------------------------------------------------------------------------
+                         N E W  F E A T U R E S
+----------------------------------------------------------------------------
+1)  Shorewall-perl
+
+    This Shorewall package includes a complete rewrite of the compiler
+    in Perl.
+
+    I decided to make Shorewall-perl a separate package for several reasons:
+
+    a) Embedded applications are unlikely to adopt Shorewall-perl; even
+       Mini-Perl has a substantial disk and RAM footprint.
+
+    b) Because of the gross incompatibilities between the new compiler and the
+       old (see below), migration to the new compiler must be voluntary.
+    ------------------------------------------------------------------------
+                      T H E   G O O D   N E W S:
+    ------------------------------------------------------------------------
+    a) The compiler has a small disk footprint.
+    b) The compiler is very fast.
+    c) The compiler generates a firewall script that uses iptables-restore;
+       so the script is very fast.
+    d) The new compiler does a much better job of validating the
+       configuration and catches many errors that resulted in run-time
+       failures with the old compiler.
+    e) Use of the Shorewall-perl is optional! The old slow clunky
+       Bourne-shell compiler is still available.
+    ------------------------------------------------------------------------
+                      T H E   B A D   N E W S:
+    ------------------------------------------------------------------------
+    There are a number of incompatibilities between the Perl-based compiler
+    and the Bourne-shell one.
+
+    a) The Perl-based compiler requires the following capabilities in your
+       kernel and iptables.
+
+       - addrtype match
+       - multiport match
+
+       These capabilities are in current distributions.
+
+    b) Now that Netfilter has features to deal reasonably with port lists,
+       I see no reason to duplicate those features in Shorewall. The
+       Bourne-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.
+
+    c) The old BRIDGING=Yes support has been replaced by new bridge
+       support that uses the reduced 'physdev match' capabilities found
+       in kernel 2.6.20 and later. This new implementation may be used
+       where it is desired to control traffic through a bridge.
+
+       The new implementation includes the following features:
+
+       a)  A new "Bridge Port" zone type is defined. Specify 'bport' or
+           'bport4' in the TYPE column of /etc/shorewall/zones.
+
+           Bridge Port zones should be a sub-zone of a regular ipv4 zone
+           that represents all hosts attached to the bridge.
+
+       b)  A new 'bridge' option is defined for entries in      
+           /etc/shorewall/interfaces. Bridges should have this option
+           specified, even if you don't want to filter traffic going
+           through the bridge.
+
+       c)  Bridge ports must now be defined in
+           /etc/shorewall/interfaces. The INTERFACE column contains
+           both the bridge name and the port name separated by a colon
+           (e.g., "br0:eth1"). No OPTIONS are allowed for bridge
+           ports. The bridge must be defined before its ports and must
+           have the 'bridge' option.
+
+       Bridge Port (BP) zones have a number of limitations:
+
+       a)  Each BP zone may only be associated with ports on a single
+           bridge.
+
+       b)  BP zones may not be associated with interfaces that are not
+           bridge ports.
+
+       c)  You may not have policies or rules where the DEST is a BP
+           zone but the source is not a BP zone. If you need such
+           rules, you must use the BP zone's parent zone as the DEST
+           zone.
+
+       Example (Bridge br0 with ports eth1 and tap0):
+
+       /etc/shorewall/zones:
+
+        fw      firewall
+        net     ipv4
+        loc     ipv4
+        lan:loc bport
+        vpn:loc bport
+
+       /etc/shorewall/interfaces:
+
+        net     eth0    -       ...
+        loc     br0     -       ...
+        lan     eth1
+        vpn     tap0
+
+       When using the /etc/shorewall/hosts file to define a bport4
+       zone, you specify only the port name:
+
+       Example:
+
+       /etc/shorewall/zones:
+
+        fw      firewall
+        net     ipv4
+        loc     ipv4
+        lan:loc bport
+        vpn:loc bport
+
+       /etc/shorewall/hosts
+
+        lan     eth1:192.168.2.0/24     ...
+
+       The structure of the accounting rules changes slightly when
+       there are bridges defined in the Shorewall
+       configuration. Because of the restrictions imposed by Netfilter
+       in kernel 2.6.21 and later, output accounting rules must be
+       segregated from forwarding and input rules.
+
+       To accomplish this separation, Shorewall-perl creates two
+       accounting chains:
+
+       - accounting - for input and forwarded traffic.
+       - accountout - for output traffic.
+
+       If the CHAIN column contains '-', then:
+
+       - If the SOURCE column in a rule includes the name of the
+         firewall zone (e.g., $FW), then the rule is add only
+         to the accountout chain.
+
+       - Otherwise, if the DEST in the rule is any or all or 0.0.0.0/0,
+         then the rule is added to both accounting and accountout.
+
+       - Otherwise, the rule is added to accounting only.
+
+       See http://www.shorewall.net/4.0/bridge-Shorewall-perl.html for
+       additional information about the new bridge support.     
+
+    d) The BROADCAST column in the interfaces file is essentially unused;
+       if you enter anything in this column but '-' or 'detect', you will
+       receive a warning.
+
+    e) Because the compiler is written in Perl, some of your extension
+       scripts from earlier versions will no longer work because
+       Shorewall-perl runs those extension scripts at compile-time rather
+       than at run-time. 
+
+       Compile-time scripts are:
+
+           initdone
+           maclog
+           All per-chain scripts including those associated with actions.
+
+       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.
+
+       All scripts will need to begin with the following line:
+
+           use Shorewall::Chains;
+
+       For more complex scripts, you may need to 'use' other Shorewall
+       Perl modules -- browse /usr/share/shorewall-perl/Shorewall/ to
+       see what's available.
+
+       When a script is invoked, the $chainref scalar variable will hold a
+       reference to a chain table entry. 
+
+           $chainref->{name}  contains the name of the chain
+           $chainref->{table} holds the table name
+       
+           To add a rule to the chain:
+
+              add_rule( $chainref, <the rule> );
+
+           Where
+
+              <the rule> is a scalar argument holding the rule text. Do
+              not include "-A <chain name>"
+
+           Example:
+
+              add_rule( $chainref, '-j ACCEPT' );
+
+           To insert a rule into the chain:
+
+              insert_rule( $chainref, <rulenum>, <the rule> );
+
+           The log_rule_limit function works like it does in the shell
+           compiler with two exceptions:
+
+              - You pass the chain reference rather than the name of
+                the chain.
+              - The commands are 'add' and 'insert' rather than '-A'
+                and '-I'.
+              - There is only a single "pass as-is to iptables"
+                argument (so you must quote that part).
+
+           Example:
+
+              log_rule_limit(
+                             'info' , 
+                              $chainref ,            
+                              $chainref->{name},
+                              'DROP' , 
+                              '',      #Limit
+                              '' ,     #Log tag
+                              'add',   #Command
+                              '-p tcp' #Pass as-is
+                             );
+
+       Note that in the 'initdone' script, there is no default chain
+       ($chainref). You can objtain a reference to a standard chain by:
+
+           my $chainref = $chain_table{<table>}{<chain name>};
+
+       Example:
+
+           my $chainref = $chain_table{'filter'}{'INPUT'};
+
+       The continue script is eliminated. That script was designed to
+       allow you to add special rules during [re]start. Shorewall-perl
+       doesn't need such rules.
+
+       See http://www.shorewall.net/4.0/shorewall_extension_scripts.htm
+       for further information about extension scripts under
+       Shorewall-perl.
+
+    f) The 'refresh' command now works like 'restart' with the
+       following exceptions:
+
+       - The refresh command is rejected if Shorewall is not running.
+       - The refresh command only rebuilds the 'blacklst' chain.
+       - A directory name may not be specified in the refresh command.
+
+    g) 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:
+
+           [all:]<address>[,...]
+           [all:]<interface>[:<address>[,...]]
+           $FW[:<address>[,...]]
+
+       The DEST column may be one of the following:
+       
+           [all:]<address>[,...]
+           [all:]<interface>[:<address>[,...]]
+
+       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.
+
+    h) 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:
+
+        i)   Your ipsets must be loaded before Shorewall starts. You
+             are free to try to do that with the following code in
+             /etc/shorewall/start:
+
+             if [ "$COMMAND" = start ]; then
+                ipset -U :all: :all:
+                ipset -F
+                ipset -X
+                ipset -R < /my/ipset/contents
+             fi
+
+             The file '/my/ipset/contents' (not its real name of
+             course) will normally be produced using the ipset -S
+             command.
+
+             The above will work most of the time but will fail in a
+             'shorewall stop' - 'shorewall start' sequence if you
+             use ipsets in your routestopped file (see below).
+
+        ii)  Your ipsets may not be reloaded until Shorewall is stopped
+             or cleared.
+
+        iii) If you specify ipsets in your routestopped file then
+             Shorewall must be cleared in order to reload your ipsets.
+
+       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.
+
+    i) Because the configuration files (with the exception of
+       /etc/shorewall/params) are now processed by the Perl-based
+       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.
+
+    j) 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.
+
+    k) DELAYBLACKLISTLOAD=Yes is not supported. The entire ruleset is
+       atomically loaded with one execution of iptables-restore.
+
+    l) MAPOLDACTIONS=Yes is not supported. People should have converted
+       to using macros by now.
+
+    m) The pre Shorewall-3.0 format of the zones file is not supported;
+       neither is the /etc/shorewall/ipsec file.
+
+    n) 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.
+
+    o) 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       ...
+
+    p) The 'allowoutUPnP' built-in action is no longer supported. The
+       Netfilter team have removed support for '-m owner --owner-cmd'
+       which that action depended on. 
+
+    q) The treatment of the following interface options has changed under
+       Shorewall-perl.
+
+       - arp_filter
+       - routefilter
+       - logmartians
+       - proxy_arp
+       - sourceroute
+
+       With the Shorewall-shell compiler, Shorewall resets these options
+       on all interfaces then sets the option on those interfaces
+       for which the option is defined in /etc/shorewall/interfaces.
+
+       Under Shorewall-perl, these options can be specified with the value
+       0 or 1 (e.g., proxy_arp=0). If no value is specified, the value 1
+       is assumed. Shorewall will modify only the setting of those
+       interfaces for which the option is specified and will set the
+       option to the given value.
+
+       A fatal compilation error is also generated if you specify one of
+       these options with a wildcard interface (one ending with '+').
+
+    r) The LOG_MARTIANS and ROUTE_FILTER options are now tri-valued in
+       Shorewall-perl.
+
+        Yes -  Same as before
+        No  -  Same as before except that it applies regardless of
+               whether any interfaces have the logmartians/routefilter
+               option
+        Keep - Shorewall ignores the option entirely (which is the
+        default).
+
+    s)  Shorewall-perl support nn 'optional' option has been added to
+        /etc/shorewall/interfaces. This option is recognized by
+        Shorewall-perl but not by Shorewall-shell. When 'optional' is
+        specified for an interface, Shorewall will be silent when:
+
+        - a /proc/sys/net/ipv4/conf/ entry for the interface cannot be
+          modified (including for proxy ARP).
+
+        - The first address of the interface cannot be obtained.
+
+        I specify 'optional' on interfaces to Xen virtual machines that
+        may or may not be running when Shorewall is [re]started.
+
+        CAUTION: Use 'optional' at your own risk. If you [re]start
+        Shorewall when an 'optional' interface is not available and then
+        do a 'shorewall save', subsequent 'shorewall restore' and
+        'shorewall -f start' operations will instantiate a ruleset that
+        does not support that interface, even if it is available at the
+        time of the restore/start.
+
+     t) Shorewall-perl validates all IP addresses and addresses ranges
+        in rules. DNS names are resolved and an error is issued for any
+        name that cannot be resolved.
+     u) Shorewall-perl checks configuration files for the presense of
+        characters that can cause problems if they are allowed into the
+        generated firewall script:
+
+        - Double Quotes. These are prohibited except in the
+          shorewall.conf and params files.
+
+        - Single Quotes. These are prohibited except in the
+          shorewall.conf and params files and in COMMENT lines.
+
+        - Single back quotes. These are prohibited except in the 
+          shorewall.conf and params files.
+
+        - Backslash. Probibited except as the last character on a line
+          to denote line continuation.
+
+     v) Under Shorewall-perl, macros may invoke other macros with the
+        restriction that such macros may not be invoked within an action
+        body.
+
+        When marcros are invoked recursively, the parameter passed to an
+        invocation are automatically propagated to lower level macros.
+
+         Macro invocations may be nested to a maximum level of 5.
+    ------------------------------------------------------------------------
+                      P R E R E Q U I S I T E S
+    ------------------------------------------------------------------------
+    - Perl (I use Perl 5.8.8 but other versions should work fine)
+    - Perl Cwd Module
+    - Perl File::Basename Module
+    - Perl File::Temp Module
+    - Perl Getopt::Long Module
+    ------------------------------------------------------------------------
+               U S I N G   T H E   N E W   C O M P I L E R
+    If you only install one compiler, then that compiler will be used.
+
+    If you install both compilers, then the compiler actually used depends
+    on the SHOREWALL_COMPILER setting in shorewall.conf.
+
+    The value of this new option can be either 'perl' or 'shell'.
+
+    If you add 'SHOREWALL_COMPILER=perl' to /etc/shorewall/shorewall.conf
+    then by default, the new compiler will be used on the system. If you
+    add it to shorewall.conf in a separate directory (such as a
+    Shorewall-lite export directory) then the new compiler will only be
+    used when you compile from that directory.
+
+    If you only install one compiler, it is suggested that you do not set
+    SHOREWALL_COMPILER.
+
+    You can also select the compiler to use on the command line using the
+    'C option:
+
+       '-C shell' means use the shell compiler
+       '-C perl' means use the perl compiler
+
+    The -C option overrides the setting in shorewall.conf. 
+
+    Example:
+
+        shorewall restart -C perl
+
+2)  Thanks to Paul Gear, an IPPServer macro has been added. Be sure to
+    read the comments in the macro file before trying to use this
+    macro.
+
+3)  Eariler generations of Shorewall Lite required that remote root
+    login via ssh be enabled in order to use the 'load' and 'reload'
+    commands.
+
+    Beginning with this release, you may define an alternative means
+    for accessing the remote firewall system.
+
+    Two new options have been added to shorewall.conf:
+
+        RSH_COMMAND
+        RCP_COMMAND
+
+    The default values for these are as follows:
+
+        RSH_COMMAND: ssh ${root}@${system} ${command}
+        RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
+
+    Shell variables that will be set when the commands are envoked are
+    as follows:
+
+       root  - root user. Normally 'root' but may be overridden using
+               the '-r' option.
+
+       system - The name/IP address of the remote firewall system.
+
+       command - For RSH_COMMAND, the command to be executed on the 
+                 firewall system.
+
+       files   - For RCP_COMMAND, a space-separated list of files to
+                 be copied to the remote firewall system.
+
+       destination - The directory on the remote system that the files 
+                     are to be copied into. 
+
+4)  The accounting, masq, rules and tos files now have a 'MARK' column
+    similar to the column of the same name in the tcrules file. This
+    column allows filtering by MARK and CONNMARK value (CONNMARK is
+    only accepted under Shorewall Perl).
+
+5)  SOURCE and DEST are now reserved zone names to avoid problems with
+    bi-directional macro definitions which use these as names as key
+    words.
+
+6)  The "shorewall show zones" command now flags zone members that have
+    been added using "shorewall add" by preceding them with a plus sign
+    ("+").
+
+    Example:
+
+    Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007
+
+    fw (firewall)
+    net (ipv4)
+        eth0:0.0.0.0/0
+    loc (ipv4)
+        br0:0.0.0.0/0
+        eth4:0.0.0.0/0
+        eth5:0.0.0.0/0
+        +eth1:0.0.0.0/0
+    dmz (ipv4)
+        eth3:0.0.0.0/0
+    vpn (ipv4)
+        tun+:0.0.0.0/0
+
+    In the above output, "eth1:0.0.0.0/0" was dynamically added to the
+    'loc' zone. As part of this change, "shorewall delete" will only
+    delete entries that have been added dynamically. In earlier
+    versions, any entry could be deleted although the ruleset was only
+    changed by deleting entries that had been added dynamically.
+
+7)  The 'shorewall version' command now lists the version of the
+    installed compiler(s) if the -a option is used:
+
+    gateway:/bulk/backup # shorewall version -a
+    4.0.0-Beta1
+    Shorewall-shell 4.0.0-Beta1
+    Shorewall-perl 4.0.0-Beta1
+    gateway:/bulk/backup #
+
+8)  The Perl compiler is externalized. Both the compiler.pl program
+    and the Perl Module interface are documented.
+
+    The compiler program is /usr/share/shorewall-perl/compiler.pl:
+
+        compiler.pl [ <option> ... ] [ <filename> ]
+
+    If a <filename> is given, then the configuration will be compiled
+    output placed in the named file. If <filename> is not given, then
+    the configuration will simply be syntax checked.
+
+    Options are:
+
+    -v <verbosity>
+    --verbosity=<verbosity>
+    
+        The <verbosity> is a number between 0 and 2 and corresponds to
+        the VERBOSITY setting in shorewall.conf. This setting controls
+        the verbosity of the compiler itself.
+
+    -e
+    --export
+
+        If given, the configuration will be compiled for export to
+        another system.
+
+    -d <directory>
+    --directory=<directory>
+
+        If this option is omitted, the configuration in /etc/shorewall
+        is compiled/checked. Otherwise, the configuration in the named
+        directory will be compiled/checked.
+
+    -t
+    --timestamp
+
+        If given, each progress message issued by the compiler and by
+        the compiled program will be timestamped.
+
+    --debug
+
+        If given, when a warning or error message is issued, it is 
+        supplimented with a stack trace. Requires the Carp Perl
+        module.
+
+    Example (compiles the configuration in the current directory 
+             generating a script named 'firewall' and using VERBOSITY
+             2).
+
+       /usr/share/shorewall-perl/compiler.pl -v 2 -d . firewall
+
+    Note: For compatibility with the Shorewall 3.4.2 and 3.4.3
+    releases, options not passed on the run-line get their values from
+    environmental variables:
+
+           Option                 Variable
+
+           --verbosity            VERBOSE
+           --export               EXPORT
+           --directory            SHOREWALL_DIR
+           --timestamp            TIMESTAMP
+
+    The Perl Module is externalized as follows:
+
+        use lib '/usr/share/shorewall-perl';
+        use Shorewall::Compiler;
+        
+            compiler $filename, $directory, $verbose, $options
+
+    The arguments to the compiler function are as follows:
+
+        $filename -   Name of the compiled script to be created.
+                      If the arguments evaluates to false, the
+                      configuration is syntax checked
+                      
+        $directory -  The directory containing the configuration.
+                      If passed as '', then /etc/shorewall/ is assumed.
+
+        $verbose -    The verbosity level (0-2).
+
+        $options -    A bitmap of options. Shorewall::Compiler
+                      exports two constants to help building this
+                      argument:
+
+                        EXPORT    = 0x01
+                        TIMESTAMP = 0x02
+
+    The compiler raises an exception with 'die' if it encounters an
+    error; $@ contains the 'ERROR' messages describing the problem.
+    
+    The compiler function can be called repeatedly with different
+    inputs.
+
+9)  When TC_ENABLED=Internal, Shorewall-perl now validates classids in
+    the MARK/CLASSIFY column of /etc/shorewall/tcrules against the
+    classes generated by /etc/shorewall/tcclasses.
+
+10) During installation, Shorewall generates the Perl module
+    /usr/share/shorewall-perl/Shorewall/Ports.pm, using your
+    /etc/protocols and /etc/services as input.
+
+    To re-generate the module from those two files:
+
+        1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm
+           file.
+        2. /usr/share/shorewall-perl/buildports.pl > \
+           /usr/share/shorewall-perl/Shorewall/Ports.pm
+
+    Note: If the buildports.pl program fails to run to a successful
+    completion during installation, a fallback version of
+    module will be installed. That fallback module was generated from
+    the /etc/protocols and /etc/services shipped with Ubuntu Feisty
+    Fawn.
+
+    Even if the buildports.pl program runs successfully, the fallback
+    module is also installed as
+    /usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you
+    encounter problems with the generated module, simply copy the
+    fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.
+
+11) Tuomo Soini has contributed bi-directional macros for various
+    tunnel types:
+
+          IPsecah
+          GRE
+          IPsec
+          IPIP
+          IPsecnat
+          L2TP
+
+12) The -f option is no longer the default when Shorewall is started at
+    boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
+    "shorewall start" is nearly as fast as "shorewall restore" and
+    "shorewall start" uses the current configuration which avoids
+    confusion.
+
+
+    To re-generate the module from those two files:
+
+        1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm
+           file.
+        2. /usr/share/shorewall-perl/buildports.pl > \
+           /usr/share/shorewall-perl/Shorewall/Ports.pm
+
+    Note: If the buildports.pl program fails to run to a successful
+    completion during installation, a fallback version of
+    module will be installed. That fallback module was generated from
+    the /etc/protocols and /etc/services shipped with Ubuntu Feisty
+    Fawn.
+
+    Even if the buildports.pl program runs successfully, the fallback
+    module is also installed as
+    /usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you
+    encounter problems with the generated module, simply copy the
+    fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.
+
+11) Tuomo Soini has contributed bi-directional macros for various
+    tunnel types:
+
+          IPsecah
+          GRE
+          IPsec
+          IPIP
+          IPsecnat
+          L2TP
+
+12) The -f option is no longer the default when Shorewall is started at
+    boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
+    "shorewall start" is nearly as fast as "shorewall restore" and
+    "shorewall start" uses the current configuration which avoids
+    confusion.
+
+13) The implementation of LITEDIR has always been
+    unsatisfactory. Furthermore, there have been other cases where
+    people have asked to be able to designate the state directory
+    (default /var/lib/shorewall[-lite]).
+
+    To meet these objectives:
+
+    a)  The LITEDIR variable has been eliminated in
+        /usr/share/shorewall[-lite]/configpath.
+
+    b)  A new file /etc/shorewall[-lite]/vardir has been added. This
+        file is not created by default but may be added as needed. It
+        is expected to contain a single variable assignment:
+
+           VARDIR=<directory>
+
+        Example:
+
+           VARDIR=/root/shorewall
+    
+    To change VARDIR, copy the old directory to the new one before you
+    restart Shorewall[-lite].
+
+    To use this feature with Shorewall-lite, all packages involved
+    (compiler, shorewall-common and shorewall-lite) must be version
+    4.0.0-RC2 or later.
+
+

2007-07-15 Shorewall 3.4.5

Problems Corrected in 3.4.5.
 
@@ -76,8 +1006,8 @@ Other changes in 3.4.5.
 
     where
 
-	<file>    is the name of the capabilities file.
-	<version> is the current Shorewall version.
+        <file>    is the name of the capabilities file.
+        <version> is the current Shorewall version.
 
     Existing capabilities files contain no CAPVERSION. When such a file
     is read, Shorewall will issue this message:
@@ -325,311 +1255,6 @@ style="font-weight: bold;">2007-04-01 Shorewall 3.4.2

 
Shorewall 3.4.0

Release Highlights

1)  Shorewall can now be tailored to reduce its footprint on embedded
    systems. As part of this change, actions are now completely
    optional.

    See http://www.shorewall.net/Modularization.html for details.

2)  Exclusion is now possible in /etc/shorewall/hosts. This is required
    for bridge/firewalls under kernel 2.6.20 and later.

    See http://www.shorewall.net/NewBridge.html.

3)  Shorewall and Shorewall Lite now include man pages. There is a 
    man page for shorewall(8), one for shorewall-lite(8) and one for
    each configuration file. As part of this change, all documentation
    has been removed from Shorewall configuration files. This should
    make it easier from users to upgrade from one release to the next
    since the configuration files will only change when column is added
    or renamed.

    See http://www.shorewall.net/manpages/Manpages.html

4)  Shorewall now remembers the changes that it has made to routing as
    a result of entries in /etc/shorewall/providers and
    /etc/shorewall/route_rules and reverses those changes when
    appropriate.

Problems Corrected in 3.4.0 Final.

1)  In the rules file, following the action with "!" is supposed to
    exempt the rule from being suppressed by OPTIMIZE=1. That feature
    was not working.

2)  If both a macro body and a macro invocation contained an entry in the
    SOURCE or DEST column, then compilation failed with the error:

           merge_macro_source_dest: command not found

3)  An obscure bug in rule activation having to do with the new
    exclusion feature in /etc/shorewall/hosts has been corrected.

4) The "shorewall-[lite] [re]start and stop" commands reset the
   proxy_arp flag on all interfaces on the system making it impossible
   to control proxy arp manually with Shorewall installed. With this
   change, shorewall will only clear proxy arp if there were entries in
   /etc/shorewall/proxyarp the last time that Shorewall was
   [re]started.

New Features in Shorewall 3.4:

1)  In order to accomodate small embedded applications, Shorewall 3.4
    is now modularized. In addition to the base files, there are
    loadable "libraries" that may be included or omitted from an
    embedded system as required.

    Loadable Shorewall libraries reside in /usr/share/shorewall/ and
    have names that begin with "lib.". The following libraries are
    included in Shorewall 3.4:

    - lib.accounting. Must be available if you include entries in
      /etc/shorewall/accounting.

    - lib.actions. Must be available if you do not specify
      USE_ACTIONS=No in /etc/shorewall/shorewall.conf.

    - lib.base. The base Shorewall library required by all programs,
      including compiled firewall scripts. This library is also
      released as part of Shorewall Lite and is installed in
      /usr/share/shorewall-lite/.

    - lib.cli. Library containing the code common to /sbin/shorewall,
      /sbin/shorewall-lite. This library is also released as part of
      Shorewall Lite and is installed in /usr/share/shorewall-lite/.

    - lib.config. Library containing the code that is common to
      /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. 

    - lib.dynamiczones. Must be available if you specify
      DYNAMIC_ZONES=Yes in shorewall.conf.

    - lib.maclist. Must be available if you specify the 'maclist'
      option in /etc/shorewall/interfaces or /etc/shorewall/hosts.

    - lib.nat. Must be available if you have entries in
      /etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap
      or if you use DNAT or REDIRECT rules.

    - lib.providers. Must be available if you have entries in
      /etc/shorewall/providers.

    - lib.proxyarp. Must be available if you have entries in
      /etc/shorewall/proxyarp or if you specify the 'proxyarp' option
      in /etc/shorewall/interfaces.

    - lib.tc. Must be available if you have entries in
      /etc/shorewall/tcdevices and /etc/shorewall/tcclasses.

    - lib.tcrules. Must be available if you have entries in
      /etc/shorewall/tcrules.

    - lib.tunnels. Must be available if you have entries in
      /etc/shorewall/tunnels.

    Embedded applications can further decrease the size of the Shorewall
    footprint by:

    - Omitting the macro files.
    - Omitting all unused extension scripts.

    See http://www.shorewall.net/Modularization.html for additional
    details.

2)  As hinted in the previous bullet, there is a new USE_ACTIONS option
    in /etc/shorewall/shorewall.conf. Shorewall actions can be very
    powerful but they also require a lot of code to implement. Embedded
    applications can omit that code by setting
    USE_ACTIONS=No. Shorewall will ignore all action-related files
    including /usr/share/shorewall/actions.std and
    /etc/shorewall/actions. Builtin actions will still be available for
    use in rules and macros.

    The 'Limit' action has been converted to a builtin so that Limit is
    available even when USE_ACTIONS=No.

    See the next item for more information.

3)  Prior to Shorewall 3.4, default actions were specified in
    /usr/share/shorewall/actions.std or in /etc/shorewall/actions.

    This approach has two drawbacks:

    a) All DROP policies must use the same default action and all
       REJECT policies must use the same default action.

    b) Now that we have modularized action processing (see the New
       Features section below), we need a way to define default rules
       for a policy that does not involve actions.

    The solution is two-fold:

    - Four new options have been added to the
      /etc/shorewall/shorewall.conf file that allow specifying the
       default action for DROP, REJECT, ACCEPT and QUEUE.

       The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and
       QUEUE_DEFAULT.

       DROP_DEFAULT describes the rules to be applied before a
       connection request is dropped by a DROP policy; REJECT_DEFAULT
       describes the rules to be applied if a connection request is
       rejected by a REJECT policy. The other two are similar for
       ACCEPT and QUEUE policies.

       The value assigned to these may be:

        a) The name of an action.
        b) The name of a macro
        c) 'None' or 'none'

       The default values are:

        DROP_DEFAULT="Drop"
        REJECT_DEFAULT="Reject"
        ACCEPT_DEFAULT=none
        QUEUE_DEFAULT=none

       If USE_ACTIONS=Yes, then these values refer to action.Drop and
       action.Reject respectively. If USE_ACTIONS=No, then these values
       refer to macro.Drop and macro.Reject.

       If you set the value of either option to "None" then no default
       action will be used and the default action or macro (if any)
       must be specified in /etc/shorewall/policy

    - The POLICY column in /etc/shorewall/policy has been extended.

       In /etc/shorewall/policy, when the POLICY is DROP, REJECT,
       ACCEPT or QUEUE then the policy may be followed by ":" and one
       of the following:

        a) The word "None" or "none". This causes any default
           action defined in /etc/shorewall/shorewall.conf
           to be omitted for this policy.
        b) The name of an action (requires that USE_ACTIONS=Yes
           in shorewall.conf). That action will be invoked
           before the policy is enforced.
        c) The name of a macro. The rules in that macro will
           be applied before the policy is enforced. This
           does not require USE_ACTIONS=Yes.

    Example:

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

4)  For users whose kernel and iptables have Extended MARK Target
    support, it is now possible to logically AND or OR a value into the
    current packet mark by preceding the mark value (and optional mask)
    with an ampersand ("&") or vertical bar ("|") respectively.

    Example: To logically OR the value 4 into the mark value for
    packets from 192.168.1.1:

    #MARK   SOURCE
    |4      192.168.1.1

5)  Previously, zone names were restricted to five characters in
    length. That limit derives from the --log-prefix in Netfilter log
    messages which must be 29 bytes or less in length. With the
    standard Shorewall LOGFORMAT, that leaves 11 characters for the
    chain name; given that many chain names are of the form
    <zone1>2<zone2>, that gives a maximum zone name length of 5.

    Beginning with this release, the maximum length of a zone name is
    dependent on the LOGFORMAT (the maximum length may never be less
    than 5 but it may be greater than 5). For example, setting
    LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters.

6)  Netfilter provides support for attachment of comments to Netfilter
    rules. Comments can be up to 255 bytes in length and are visible
    using the "shorewall show <chain>", "shorewall show nat",
    "shorewall show mangle" and "shorewall dump" commands. Comments are
    delimited by '/* ... */" in the output.

    Beginning with Shorewall 3.4, you may place COMMENT lines in the
    /etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat
    and /etc/shorewall/masq files and in action files. The remainder of
    the line is treated as a comment and it will be attached as a
    Netfilter comment to the rule(s) generated by succeding entries
    in the file.

    Note: Do not prefix the comment with "#". Shorewall's two-pass
    compiler strips off "#" comments in the first pass and processes
    COMMENT lines in the second pass. Hence, by the time that COMMENT
    is processed, the "#" and everything following it has been removed
    (see example below).

    To stop the current comment from being attached to further
    rules, simply include COMMENT on a line by itself (so that the
    following rules will have no comment) or specify a new COMMENT.

    If you do not have Comment support in your iptables/kernel (see the
    output of "shorewall[-lite] show capabilities") then COMMENTS are
    ignored with this warning:

     COMMENT ignored --  requires comment support in iptables/Netfilter

    Example from my rules file:

            #SOURCE      SOURCE     DEST       PROTO DEST PORT(S)

            COMMENT Stop Microsoft Noise

            REJECT       loc        net        tcp   137,445
            REJECT       loc        net        udp   137:139

            COMMENT  # Stop comment from being attached to rules below

    The output of "shorewall show loc2net" includes (folded):

    0     0 reject     tcp  --  *      *       0.0.0.0/0
          0.0.0.0/0    multiport dports 137,445 /* Stop Microsoft Noise */
    0     0 reject     udp  --  *      *       0.0.0.0/0
          0.0.0.0/0    udp dpts:137:139 /* Stop Microsoft Noise */

7)  A new macro (macro.RDP) has been added for Microsoft Remote
    Desktop. This macro was contributed by Tuomo Soini.

8)  A new 'maclog' extension file has been added. This file is
    processed just before logging based on the setting of
    MACLIST_LOG_LEVEL is done. When the extension is invoked, the CHAIN
    variable will contain the name of the chain where rules should be
    inserted. Remember that if you have specified MACLIST_TABLE=mangle,
    then your run_iptables commands should include "-t mangle".

9)  The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to
    more accurately describe the contents of the column.

10) Previously, it was not possible to use exclusion in
    /etc/shorewall/hosts. Beginning with this release, you may now use
    exclusion lists in entries in this file. Exclusion lists are
    discussed at:

       http://www.shorewall.net/configuration_file_basics.htm#Exclusion.

    Example:

        loc     eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28

    In that example, the 'loc' zone is defined to be the subnet
    192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4
    and hosts in the sub-network 192.168.1.16/28.

11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing"
    commands have been added. The first produces the same output as "ip
    addr ls". The second produces a report about your routing rules and
    tables.

12) Beginning with this release, Shorewall and Shorewall Lite will
    share common change logs and release notes.

13) In Shorewall versions prior to 3.4, multiple jumps to a '2all'
    chain could be generated in succession.

    Example from an earlier shorewall version:

    gateway:~ # shorewall-lite show eth2_fwd
    Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006

    Counters reset Thu Oct 19 08:34:47 PDT 2006

    Chain eth2_fwd (1 references)
     pkts bytes target     prot opt in     out     source            destination
        0     0 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW
        0     0 wifi2all   all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
        0     0 wifi2all   all  --  *      br0     0.0.0.0/0            0.0.0.0/0
        0     0 wifi2all   all  --  *      eth3    0.0.0.0/0            0.0.0.0/0
        0     0 wifi2all   all  --  *      tun+    0.0.0.0/0            0.0.0.0/0
    gateway:~ #

    This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.

    gateway:~ # shorewall-lite show eth2_fwd
    Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006

    Counters reset Thu Oct 19 09:15:19 PDT 2006

    Chain eth2_fwd (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID,NEW
        0     0 wifi2all   all  --  *      *       0.0.0.0/0            0.0.0.0/0
    gateway:~ #

    Note that with OPTIMIZE=1, traffic destined for an
    interface/Address that falls outside of all defined zones may now
    be logged out of a '2all' chain rather than out of the FORWARD
    chain.

    The OPTIMIZE setting also controls the suppression of redundant
    wildcard rules (those specifying "all" in the SOURCE or DEST
    column). A wildcard rule is considered to be redundant when it
    has the same ACTION and Log Level as the applicable policy.

    Example:

        /etc/shorewall/policy

        #SOURCE         DEST            POLICY          LEVEL
        loc             net             ACCEPT

        /etc/shorewall/rules

        #ACTION         SOURCE          DEST    PROTO   DEST
        #                                               PORT(S)
        ...
        ACCEPT          all             all     icmp    8

    OPTIMIZE=0

    gateway:~ # shorewall show loc2net
    Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006

    Counters reset Thu Oct 26 07:54:58 PDT 2006

    Chain loc2net (1 references)
     pkts bytes target     prot opt in     out     source               destination
      ...
        0     0 DROP       all  --  *      *      !192.168.0.0/22       0.0.0.0/0
        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8
        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

    gateway:~

    OPTIMIZE=1

    gateway:~ # shorewall show loc2net
    Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006

    Counters reset Thu Oct 26 07:56:38 PDT 2006

    Chain loc2net (1 references)
     pkts bytes target     prot opt in     out     source               destination
      ...
        0     0 DROP       all  --  *      *      !192.168.0.0/22       0.0.0.0/0
        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

    gateway:~

    If you really want a rule that duplicates the policy, follow the
    action with "!":

        #ACTION         SOURCE          DEST    PROTO   DEST
        #                                               PORT(S)
        ...
        ACCEPT!         all             all     icmp    8

14) IP Address ranges are now allowed in the drop, reject, allow and
    logdrop shorewall[-lite] commands.

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

    When Shorewall starts or is restarted and there are entries in
    /etc/shorewall/providers, Shorewall will capture the contents
    of /etc/shorewall/rt_tables and will restore that database when
    Shorewall is stopped or restarted. Similarly, the default route
    will be captured the first time that you [re]start Shorewall using
    this version and will be restored under the following conditions:

    a) shorewall stop
    b) shorewall clear
    c) shorewall restart or restore and there are no entries in
       /etc/shorewall/providers.

    Once the default route has been restored, Shorewall will delete
    the saved copy so that it will once again be captured at the next
    shorewall start or shorewall restore.

16) Shorewall no longer includes policy matches in its generated
    ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC
    networks are defined using the 'ipsec' option in
    /etc/shorewall/hosts).

17) The Makefile installed in /usr/share/shorewall/configfiles/ is now
    the same one mentioned at
    http://www.shorewall.net/CompiledPrograms.html.

    Once the file is copied into an export directory, you modify the
    setting of the HOST variable to match the name of the remote
    firewall.

    The default target is the "firewall" script so "make" compiles the
    firewall script if any of the configuration files have
    changed. "make install" builds "firewall" if necessary then
    installs it on the remote firewall. "make capabilities" will
    generate the "capabilities" file. "make save" will save the running
    configuration on the remote firewall.

18) Shorewall and Shorewall Lite now include the following manpages. 

              shorewall-accounting(5)
              shorewall-actions(5)
              shorewall-blacklist(5)
              shorewall.conf(5)
              shorewall-ecn(5)
              shorewall-exclusion(5)
              shorewall-hosts(5)
              shorewall-interfaces(5)
              shorewall-lite.conf(5)
              shorewall-lite(8)
              shorewall-maclist(5)
              shorewall-masq(5)
              shorewall-nat(5)
              shorewall-nesting(5)
              shorewall-netmap(5)
              shorewall-params(5)
              shorewall-policy(5)
              shorewall-providers(5)
              shorewall-proxyarp(5)
              shorewall-rfc1918(5)
              shorewall-route_rules(5)
              shorewall-routestopped(5)
              shorewall-rules(5)
              shorewall-tcclasses(5)
              shorewall-tcdevices(5)
              shorewall-tcrules(5)
              shorewall-template(5)
              shorewall-tos(5)
              shorewall-tunnels(5)
              shorewall(8)
              shorewall-zones(5)

    Now that the manpages are in place, command-specific help has been
    removed since it duplicates information in the man pages.

19) From the beginning, the Shorewall configuration files in
    /etc/shorewall/ have contained documentary comments. While these
    comments are useful, they present an upgrade problem. Beginning
    with this release, these comments are removed from the
    configuration files themselves and are replaced by the manpages
    described in the preceding release note entry.

20) Shorewall now uses tc fwmark filters to classify packets for
    traffic shaping when the DEVICE isn't an interface described in
    /etc/shorewall/interfaces. This is in preparation for the upcoming
    change to the way that --physdev-out works in iptables/Netfilter;
    that change is now scheduled for kernel 2.6.20.

21) If your kernel and iptables have extended multiport support, then
    Shorewall will use that support for the destination port when
    generating rules from entries in the /etc/shorewall/tcrules file.
22) The 'safe-start' and 'safe-restart' command have been
    improved. Both now accept an optional directory name; if supplied,
    Shorewall will look first in that directory for configuration
    files.

    The commands have also been enhanced to only restore the
    configuration once in the event of a failure. Previously, if there
    was a current 'save' command in effect, then that configuration
    would be restored on a failure and then the last-running
    configuration would be restored.

23) The 'try' command has been reimplemented with new semantics. 

    If Shorewall is started then the firewall state is saved to a
    temporary saved configuration (/var/lib/shorewall/.try). Next, if
    Shorewall is currently started then a restart command is issued;
    otherwise, a start command is performed. if an error occurs during
    the  compliation phase  of  the  restart or start, the command
    terminates without changing the Shorewall state. If an error occurs
    during the restart phase, then a 'shorewall restore' is performed
    using the saved configuration. If an error occurs during the start
    phase, then Shorewall is  cleared. If the start/restart succeeds
    and a timeout is specified then a 'clear' or 'restore' is performed
    after timeout seconds. 

24) The syntax of the 'export' command has been made slightly
    friendlier.

    The old syntax:

        export <directory1> [user@]system:[<directory2>]

    It is now:

        export <directory1> [user@]system[:<directory2>]

    In other words, if you don't need to specify <directory2>, you may
    omit the colon (":") following the system name.
    
    The old syntax is still accepted -- that is, you can still 
    type:

        export firewall2:

    which is equivalent to

        export firewall2

25) Shorewall commands may be speeded up slightly by using a
    'capabilities' file. The 'capabilities' file was originally
    designed for use with Shorewall Lite and records the
    iptables/Netfilter features available on the target system.

    To generate a capabilities file, execute the following command as
    root:

      shorewall show -f capabilities > /etc/shorewall/capabilities

    When you install a new kernel and/or iptables, be sure to generate
    a new capabilities file.
        
26) When syslogd is run with the -C option (which in some
    implementations causes syslogd to log to an in-memory circular
    buffer), /sbin/shorewall will now use the 'logread' command to read
    the log from that buffer. This is for combatibility with OpenWRT.

27) There is now a ":T" qualifier in /etc/shorewall/tcrules which
    causes the resulting rule to be inserted into the POSTROUTING
    chain.

28) The program /usr/share/shorewall/wait4ifup can be used to wait for
    a network device (such as a ppp device) to reach the UP state. 
    
        /usr/share/shorewall/wait4ifup <interface> [ <seconds> ]

    The program will wait for up to <seconds> seconds for the 
    named <interface> to reach the UP state. If <seconds> is not given,
    60 seconds is assumed.

    The exit status is zero if <interface> comes up within <seconds>
    seconds and non-zero otherwise.

29) Previously, 'ipsecnat' tunnels allowed AH traffic by default
    (unless 'isecnat:noah' was given). Given that AH is incompatible
    with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.

30) Shorewall now generates half as many rules as previously in the
    'blacklst' chain when BLACKLIST_LOGLEVEL is specified.

31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in
    shorewall.conf then Shorewall will not process
    /etc/shorewall/params when the compiled script is run. With
    EXPORTPARAMS=No, any shell variables needed at run-time must be set
    in /etc/shorewall/init.

    In a Shorewall/Shorewall Lite environment, this allows
    /etc/shorewall/params to be written to run exclusively
    on the administrative system while /etc/shorewall/init runs
    exclusively on the firewall system.

    So shell variables required at compile time may be set in
    /etc/shorewall/params and those required at run-time may be set in
    /etc/shorewall/init.

    Note 1: If you need shell variables values in your
    /etc/shorewall/stop or /etc/shorewall/stopped script, then you need
    to set their values in /etc/shorewall/stop. /etc/shorewall/init is
    not invoked during processing of the 'stop' and 'clear' commands.

    Note 2: EXPORTPARAMS was actually introduced in Shorewall version
    3.2.9. It is described here for the benefit of those who did not
    install that version.

  
 

-2007-01-16 Shorewall 3.2.9

- 
-
Problems Corrected in 3.2.9

1)  While most distributions store the Shorewall Lite compiled program
    in /var/lib/shorewall-lite/, Shorewall includes features that allow
    that location to be changed on a per-distribution basis. The
    default for a particular distribution may be determined by the
    command "shorewall[-lite] show config".

        teastep@lists:~/shorewall/trunk$ shorewall show config
        Default CONFIG_PATH is /etc/shorewall:/usr/share/shorewall
        LITEDIR is /var/lib/shorewall-lite
        teastep@lists:~/shorewall/trunk$

    The LITEDIR setting is the location where the compiled script
    should be placed. Unfortunately, the "shorewall [re]load" command
    previously used the setting on the administrative system rather
    than the one from the firewall system so it was possible for that
    command to upload the compiled script to the wrong directory.

    To work around this problem, Shorewall now determines the LITEDIR
    setting on the firewall system and uses that setting for uploading
    the compiled script and its companion .conf file.

2)  Previously, IP ranges and ipset names were handled incorrectly in
    the last column of the maclist file with the result that run-time
    errors occured.

3)  The new SIP and H323 Netfilter helper modules were not being
    automatically loaded by Shorewall. They have now been added to the
    /usr/share/shorewall[-lite]/modules files.

Other Changes in 3.2.9

1)  Previously, 'ipsecnat' tunnels allowed AH traffic by default
    (unless 'isecnat:noah' was given). Given that AH is incompatible
    with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.

2)  A macro that handles SixXS has been contributed by Christian
    Roessner.

3)  It is rather difficult to code a 'params' file that assigns other
    than constant values such that it works correctly with Shorewall
    Lite. To work around this problem, a new EXPORTPARAMS option
    has been added to shorewall.conf. When EXPORTPARAMS=No, the
    'params' file is no longer copied to the compiler output.

    With EXPORTPARAMS=No, if you need to set environmental variables on
    the firewall system for use by your extension scripts, then do so
    in the init extension script.

    The default is EXPORTPARAMS=Yes to retain the current behavior. So
    if you are happy with the current behavior, you need make no change
    to your shorewall.conf file.

-

-2007-01-16 Shorewall 3.2.8

- 
-
Problems Corrected in 3.2.8

1)  The 'ash' shell produced an error when processing an entry with a
    log tag from /etc/shorewall/rules.

2)  If the file /etc/shorewall/init did not exist, then the compiler
    would incorrectly copy /usr/share/shorewall/init into the
    compiled script. /usr/share/shorewall/init is a symbolic link
    to the Shorewall init script (usually /etc/init.d/shorewall).

3)  Previously, "ipp2p:udp" was incorrectly rejected in the PROTO
    column of an action definition.

Other Changes in 3.2.8.

1)  New macros for network printing protocols have been added,
    courtesy of Tuomo Soini. Tuomo also provided a macro for TFTP.

    The print-oriented macros are:

        macro.IPP
        macro.Jetdirect
        macro.Printer

- 
-

-

-
2006-12-14 Shorewall 3.2.7

-
Problems Corrected in 3.2.7

1)  Handling of saved ipsets in /etc/shorewall/ipsets is broken when
    used on a system running Shorewall Lite. If there is a file named
    'ipsets' on the CONFIG_PATH when the firewall script is compiled,
    then the compiled script attempts to restore the ipsets from that
    file (which may not exist on the firewall system).

2)  The 'try' command failed on systems whose /bin/sh is Busybox ash:

        /sbin/shorewall: export: 2158: Illegal option -n

3)  Previously, Shorewall has assumed that the root user is named
    'root'. Beginning with this release, the root user may have a
    different name. This required the addition of an '-r' option for
    the 'shorewall load' and 'shorewall reload' commands.

        [re]load [ -e ] [ -c ] [ -r <root user> ] [ <dir> ] system

    Example: shorewall reload -r foobar firewall

4)  On systems with a light-weight shell such as ash or dash for /bin/sh,
    the output of "shorewall show macros" was garbled.

Other Changes in 3.2.7

1)  Prior to this release, on firewall systems with Shorewall Lite
    installed, the local modules file is used to determine which kernel
    modules to load. Beginning with this release, if there is a
    'modules' file in the export directory when the firewall script is
    compiled, then that file will be copied into the compiled script
    and used on the firewall system.

2)  When syslogd is run with the -C option (which in some
    implementations causes syslogd to log to an in-memory circular
    buffer), /sbin/shorewall will now use the 'logread' command to read
    the log from that buffer. This is for combatibility with OpenWRT.

3)  Failures of the start, restart and restore commands are now logged
    using 'logger'. These failures are logged with the 'kern' facility 
    and 'err' priority. As part of this change, normal state changes
    are now logged with the 'kern' facility and 'info' priority.

- 
-

-2006-11-18 Shorewall 3.2.6

- 
-
Problems Corrected in 3.2.6.

1)  When using a light-weight shell (e.g., ash) with multiple
providers, the /etc/iproute2/rt_tables database may become corrupted.

2)  A startup error occurred when the LENGTH or TOS column was
    non-empty in /etc/shorewall/tcrules.

3)  A startup error resulted when whitespace as included in LOGFORMAT.

4)  Previously, when conntrack match support was not available, the
    'norfc1918' option on an interface or host group was incorrectly
    filtering IPSEC traffic whose source IP address was reserved by RFC
    1918.

5)  If a DNAT or REDIRECT rule was used where the effective policy
    between the source and final destination zones is ACCEPT, the ACCEPT
    part of the rule was not generated. This was intended as an
    optimizaiton but it could lead to confusing results if there was a
    DROP or REJECT rule following.

    This optimization has been removed. You may always use DNAT- and
    REDIRECT- to suppress generation of the ACCEPT rule.

6)  Shorewall[-lite] previously would return an error exit status to a
    "start" command where Shorewall was already running. It not returns
    a "success" status.

7)  The install.sh scripst have been corrected to work properly when 
    used to create packages on Slackware and Arch Linux.

5)  A change in version 3.2.5 broke Mac Filtration in some
    cases. Result was:

      Setting up MAC Filtration -- Phase 1...
      iptables v1.3.6: policy match: invalid policy `--dir'
      Try `iptables -h' or 'iptables --help' for more information.
      ERROR: Command "/sbin/iptables -A eth1_fwd -s 0.0.0.0/0 -m state 
             --state NEW -m policy --pol --dir in -j eth1_mac" Failed

6)  At VERBOSITY 1 and higher, the 'shorewall add' and 'shorewall
    delete' commands generated a fractured message. The message
    contents depended in the setting of IPSECFILE as follows:

    IPSECFILE=ipsec

        ipsec...

    IPSECFILE=zones

        IPSEC...

    The messages have been corrected and are only produced at VERBOSITY
    2 and higher as follows:

    IPSECFILE=ipsec

        Processing /etc/shorewall/ipsec...

    IPSECFILE=zones

        Processing IPSEC...

7)  Previously, when <action>:none appeared in a rule, the name of the
    action chain created was preceded by "%" and might have a one- or
    two-digit number appended. If both <action> and <action>:none
    appeared, then two chains were created. This has been corrected
    such that <action> and <action>:none are treated identically.

8)  If SAVE_IPSETS=Yes in shorewall.conf, the "shorewall[-lite] save"
    command produced error messages as follows:

       Dynamic Rules Saved
       Currently-running Configuration Saved to /var/lib/shorewall/restore
       grep: /var/lib/shorewall/restore-base: No such file or directory
       grep: /var/lib/shorewall/restore-base: No such file or directory
       Current Ipset Contents Saved to
       /var/lib/shorewall/restore-ipsets

9)  If BRIDGING=No in shorewall.conf, then an attempt to define a zone
    using ipsets fails as follows:

    ERROR: BRIDGING=Yes is needed for this zone definition: z eth0:+iset

Other Changes in 3.2.6.

1)  The "shorewall [re]load" command now supports a "-c" option.

    Example:

        shorewall reload -c gateway

    When -c is given, Shorewall will capture the capabilities of the
    remote system to a file named "capabilities" in the export
    directory before compiling the configuration.

    If the file "capabilities" does not currently exist in the 
    export directory then "-c" is automatically assumed.

2)  If 0 (zero) is specified for the IN-BANDWIDTH in
    /etc/shorewall/tcdevices then no ingress qdisc will be created for
    the device.

- 
-

-2006-10-28 Shorewall 3.2.5

- 
-
Problems Corrected in 3.2.5

1)  Entries such as the following in /etc/shorewall/masq generate a
    run-time error:

           eth0    eth1!192.168.1.12            206.124.146.176

    Omitting the exclusion (!192.168.1.12) avoids the error.

2)  Previously, the 'provider' portion of the packet mark was not being
    cleared after routing for traffic that originates on the firewall
    itself.

3)  In prior releases, it was not possible to mark an outgoing packet
    with a high mark (HIGH_ROUTE_MARKS=Yes) when the packet originated
    on the firewall itself.

4)  The detected capabilities were not displayed by 'shorewall dump'
    when the effective VERBOSITY was less than 2.

Other changes in 3.2.5

1)  For users whose kernel and iptables have Extended MARK Target
    support, it is now possible to logically AND or OR a value into the
    current packet mark by preceding the mark value (and optional mask)
    with an ampersand ("&") or vertical bar ("|") respectively.

    Example: To logically OR the value 4 into the mark value for
    packets from 192.168.1.1:

    #MARK   SOURCE
    |4      192.168.1.1

2)  A new macro (macro.RDP) has been added for Microsoft Remote
    Desktop. This macro was contributed by Tuomo Soini.

3)  A new 'maclog' extension file has been added. This file is
    processed just before logging based on the setting of
    MACLIST_LOG_LEVEL is done. When the script is copyied at compile
    time, the CHAIN variable will contain the name of the chain where
    rules should be inserted. Remember that if you have specified
    MACLIST_TABLE=mangle, then your run_iptables commands should
    include "-t mangle".

4)  Beginning with this release, Shorewall and Shorewall lite will
    share the same change log and release notes.

- 
-

-2006-10-6 Shorewall 3.0.9

- 
-
Problems corrected in 3.0.9

1)  When using a light-weight shell like ash or dash, "shorewall
    [re]start" fails when using the built-in traffic shaper. The error
    messages resemble these:

    local: 3: eth0:: bad variable name
    ERROR: Command "tc class add dev eth0 parent 1: classid 1:1 htb rate 800kbit mtu" Failed

2)  The output formating of the 'hits' command under BusyBox 1.2.0 has
    been corrected.

3)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not
    affect traffic to/from the firewall zone. That has been corrected.

4)  Previously, using IP address ranges in the accounting file could
    cause non-fatal iptables errors during shorewall [re]start.

Other changes in 3.0.9

1)  It is now possible to use the special value 'detect' in the ADDRESS
    column of /etc/shorewall/masq. This allows you to specify SNAT (as
    opposed to MASQUERADE) without having to know the ip address of the
    external interface. Shorewall must be restarted each time that the
    external address (the address of the interface named in the
    INTERFACE column) changes.

2)  Experimental optimization for PPP devices has been added to the
    providers file. If you omit the GATEWAY column for a ppp device (or
    enter "-" in the column) then Shorewall will generate routes
    for the named INTERFACE that do not specify a gateway IP address
    (the peer address will be assumed).

3)  Normally, Shorewall tries to protect users from themselves by
    preventing PREROUTING and OUTPUT tcrules from being applied to
    packets that have been marked by the 'track' option in
    /etc/shorewall/providers.

    If you really know what you are doing and understand packet marking
    thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and
    Shorewall will not include these cautionary checks.

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

- 
-

-2006-09-27 Shorewall 3.2.4

- 
-
Shorewall Problems corrected in 3.2.4

1)  Previously, the directory name in the command "shorewall start
    <directory name>" was being dropped by "/sbin/shorewall".

2)  Previous, when /usr/share/shorewall/xmodules had been copied to
    /etc/shorewall/modules, Shorewall was not looking in the correct
    directory for the "xt_..." modules. There are two parts to the fix:

    - The /usr/share/shorewall/xmodules file has been removed. The
      /usr/share/shorewall/modules file will now load all required
      modules regardless of which kernel version you are running.
    - The MODULESDIR option can now contain a colon-separated list of
      directories to search for modules with the default being:

      /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname -r)/kernel/net/netfilter

3)  Rules in /etc/shorewall/tos which specify zones defined
    using entries in /etc/shorewall/hosts applied to all traffic
    to/from the zone interfaces (the bridge port, ipset or IP
    address(es) in the zone definition were ignored).

4)  Previously, 'shorewall-lite dump' did not report traffic shaping
    information even if TC_ENABLED was set to Yes or Internal in the
    shorewall.conf file used to compile the exported firewall script.

    To correct this problem, the firewall script must be recompiled and
    re-exported.

5)  Previously, errors during the compile phase were not reflected in
    the exit status of /sbin/shorewall. Thanks to Tuomo Soini for
    finding and correcting this problem.

Other Shorewall changes in 3.2.4

1)  Previously, scripts compiled for export (-e option) depended on
    /usr/share/shorewall-lite/functions in order to run correctly. This
    made it possible for a compiled script to be incompatible with the
    version of Shorewall Lite installed on a firewall system.

    Beginning with Shorewall 3.2.4, this dependency is removed such
    that version incompatibility between Shorewall and Shorewall Lite
    should not be a concern going forward.

2)  Two new macros have been added, courtesy of Tuomo Soini

        macro.Finger
        macro.Telnets

3)  The output of "shorewall show macros" has been enhanced to show
    macros in each directory in the CONFIG_PATH.

Shorewall Lite problems corrected in 3.2.4

1)  Previous, when /usr/share/shorewall-lite/xmodules had been copied to
    /etc/shorewall-lite/modules, Shorewall was not looking in the correct
    directory for the "xt_..." modules. There are two parts to the fix:

    - The /usr/share/shorewall-lite/xmodules file has been removed. The
      /usr/share/shorewall-lite/modules file will now load all required
      modules regardless of which kernel version you are running.
    - The MODULESDIR option can now contain a colon-separated list of
      directories to search for modules with the default being:

      /lib/modules/$(uname
      -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname
      -r)/kernel/net/netfilter

     /usr/share/shorewall-lite/modules contains a *lot* of modules. If
     you use module autoloading (which non-embedded Linux distributions
     do), then you can improve your "shorewall [re]start" time by
     trimming all but the helper modules from the file. To do that,
     create the file /etc/shorewall-lite/modules with the following
     entries:

        loadmodule ip_conntrack_amanda
        loadmodule ip_conntrack_ftp
        loadmodule ip_conntrack_irc
        loadmodule ip_conntrack_netbios_ns
        loadmodule ip_conntrack_pptp
        loadmodule ip_conntrack_tftp
        loadmodule ip_nat_amanda
        loadmodule ip_nat_ftp
        loadmodule ip_nat_irc
        loadmodule ip_nat_pptp
        loadmodule ip_nat_snmp_basic
        loadmodule ip_nat_tftp

Other Shorewall Lite changes in 3.2.4

None.

- 
-

-2006-08-26 Shorewall 3.2.3

- 
-
Shorewall Problems Corrected in 3.2.3

 1)  A problem in 'install.sh' resulted in sandbox violations on
     Gentoo and, when Shorewall is installed using an RPM, the problem
     caused an incorrect copy of shorewall.conf to be installed in
     /usr/share/shorewall/configfiles/.

 2)  A typo in the functions file caused startup errors when the user's
     distribution did not support a true mktemp program (such as
     Bering Uclibc). Patch courtesy of Cédric Schieli.

 3)  Several erroneous references to ip_addr_del() were made in
     /var/lib/shorewall/compiler and in the code that it generates.

     a) These should have been references to del_ip_addr()
     b) One of the calls also had an incorrect parameter list.

 4)  Previously, "shorewall check -e" would erroneously attempt to
     detect interfaces configured for traffic shaping.

 5)  SUBSYSLOCK functionality has been restored.

 6)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not
     affect traffic to/from the firewall zone. That has been corrected.

 7)  When /sbin/shorewall was run under BusyBox ash, shell errors would
     occur if certain command options were given.

 8)  Previously, the 'optional' provider option did not detect the case
     where the interface was DOWN but still had a configured IP
     address. Shorewall was detecting such interfaces as UP and later
     'ip replace route' commands would fail.

     It should also be clarified that the 'optional' option is intended
     to detect cases where a provider interface is in a state that would
     cause 'shorewall [re]start' to fail; it is not intended to
     determine whether communication is possible using the interface.

 9)  Previously, the "shorewall add" command would fail with error
     messages indicating that the commands "chain_exists" and
     "verify_hosts_file" could not be found.

 10) Using earlier Shorewall versions, the following sequence of
     commands produced inconsistant results:

     a) shorewall [re] start
     b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses
     c) shorewall refresh
     d) shorewall save
     e) shorewall restore (or reboot and shorewall start -f during boot
        up)

     After that series of commands, the state of traffic shaping was as
     it was after step a) rather than as it was after step c). The fix
     involved re-implementing 'shorewall refresh' as a compile/execute
     procedure similar to [re]start. While the entire configuration is
     recompiled, only ecn, blacklisting, tcrules and traffic control
     will be updated in the running configuration.

 11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been
     incorrect with the result that the rules didn't work at all.

 Other Shorewall changes in 3.2.3

 1)  A 'shorewall export' command has been added.

     shorewall export [ <directory1> ] [user@]<system>:[<directory2>]

     If <directory1> is omitted, then the current working directory is
     assumed.

     Causes the shorewall configuration in <directory1> to be compiled
     into a program called '<directory1>/firewall'. If compilation is
     successful, the '<directory1>/firewall' script is copied via scp
     to the specified <system>.

     Example:

         shorewall export admin@gateway:

     This command would compile the configuration in the current working
     directory then copy the 'firewall' (and 'firewall.conf') files to
     admin's home directory on system 'gateway'.

 2)  Normally, Shorewall tries to protect users from themselves by
     preventing PREROUTING and OUTPUT tcrules from being applied to
     packets that have been marked by the 'track' option in
     /etc/shorewall/providers.

     If you really know what you are doing and understand packet marking
     thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and
     Shorewall will not include these cautionary checks.

 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.

     See the Migration Considerations section for further information.

 4)  Previously, if you specified 'detectnets' on an interface with a
     default route, Shorewall would ignore the default route with a
     warning message. This could lead to systems that were inaccessible
     from the net, even from systems listed in the 'routestopped' file.

     Specifying 'detectnets' on an interface with a default route now
     generates a fatal error.

Shorewall Lite problems corrected in 3.2.3

1)  A typo in /usr/share/shorewall-lite/functions caused startup errors
    on distributions like Bering Uclibc that don't have a true mktemp
    utility.

Other Shorewall Lite changes in 3.2.3

None.

- 
-

-2006-08-10 Shorewall 3.2.2

- 
-
Problems corrected in 3.0.8

1)  If the 'upnp' interface option was specified on one or more
    interfaces but no forwardUPnP rule was included, the following
    diagnostic messages were issued:

        WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on
                eth0)
        ERROR: Fatal error in find_logactionchain

    Given that the fatal error message is obscure if the first WARNING
    isn't noticed, the ERROR message has been eliminated with the
    result that Shorewall now starts but won't handle UPnP properly.

2)  If BRIDGING=No in shorewall.conf, then an entry in
    /etc/shorewall/hosts such as the following would result in an
    obscure failure of an iptables command:

    loc   br0:eth0

    Shorewall now detects this case and issues a more helpful error
    message:

    ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0

3)  Users of the Multi-ISP feature may experience this error during startup:

    /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +
        $rulenum : syntax error: operand expected (error token is
        "$rulenum ")

4)  A more useful diagnostic is now given when a command fails during
    setup of traffic shaping.

5)  Shorewall now checks to see if devices in /etc/shorewall/tcdevices
    exist. If a device does not exist, a warning message is issued and
    that device's entries in /etc/shorewall/tcclasses are ignored. This
    applies to "shorewall start", "shorewall restart" and "shorewall
    refresh".

6)  It is now possible to exclude a single source MAC address using
    !<MAC address>. Previously, a startup error occurred.

7)  Shorewall would use the incorrect shell for compilation in the
    following case:

8)  Reporting of the "Mangle FORWARD Chain" capability was broken. While
    Shorewall correctly detected and used the capability, the output of
    "shorewall show capabilities" and "shorewall dump" showed the
    capability as "Not Available".

9)  Extension scripts for policy chains (chains with the word 'all' in
    their name) were not being run previously.

-Tom

- 
-

-2006-07-24 End of support for Shorewall
-2.4

- 
-
Support for Shorewall 2.4 has ended. As always, we will try to help you
with your problems but I personally will not spend any time reading old
code trying to solve your problem and I will not provide patches for any
bugs found in versions earlier than 3.0.

- 
-

-2006-07-21 Shorewall 3.2.1

- 
-
Problems Corrected in Shorewall 3.2.1:

1)  The output formatting of the 'hits' command under BusyBox 1.2.0 has
    been corrected.

2)  Shorewall no longer requires extended MARK support to use the 'track'
    provider option when HIGH_ROUTE_MARKS=No.

3)  The output of the 'hits' command was previously scrambled if
    /etc/services contained spaces as column delimiters rather than
    tabs.

4)  The /usr/share/shorewall/xmodules file was previously just a copy
    of /usr/share/shorewall/modules.

5)  The version number in the comments at the top of shorewall.conf has
    been corrected.

6)  The script generated when the -e option is given to the 'compile'
    command is  setting CONFIG_PATH to the value given in the remote
    firewall's shorewall.conf processed at compile time. This is
    generally incorrect and results in the inability to load any kernel
    modules on the firewall during 'shorewall-lite [re]start'.

Problems Corrected in Shorewall Lite 3.2.1:

1)  The output formatting of the 'hits' command under BusyBox 1.2.0 has
    been corrected.

2)  The output of the 'hits' command was previously scrambled if
    /etc/services contained spaces as column delimiters rather than
    tabs.

3)  The /usr/share/shorewall-lite/xmodules file was previously just a
    copy of /usr/share/shorewall-lite/modules.

4)  The version number in the comments at the top of shorewall.conf has
    been corrected.

- 
-

-2006-07-19 Shorewall bridge/firewall support
-change upcoming

- 
-
I regret to announce that Shorewall bridge/firewall support in its
current form (BRIDGING=Yes in shorewall.conf) is going away. I will
retain the code in Shorewall for the foreseeable future but users
migrating to new kernels coming out next year will find that their
current bridge configurations no longer work. Shorewall bridge/firewall
users upgrading to more immediate new kernel releases (possibly as early
as 2.6.18) will find Netfilter warning messages appearing in their
kernel log when Shorewall [re]starts.

The reason that this support is going away is that the underlying
Netfilter feature that BRIDGING=Yes depends on (physdev match) is being
reduced in scope to the point that it will no longer be possible to use
that feature for Shorewall zone definition. There is a significant list
of pending Netfilter bug reports than cannot be resolved so long as
'physdev match' works the way that it does today.

While 'physdev match' was a great idea in terms of the function that it
provides, it appears impossible to implement that function without
breaking other parts of the greater Linux IP stack; in short, 'physdev
match' in its current form should never have been released in the first
place.

So -- what can current Shorewall bridge/firewall users do? 
-----------------------------------------------------------------------
a) Configure Shorewall as if you have a simple bridge
(http://www.shorewall.net/SimpleBridge.html) and use ebtables to filter
traffic in and out of the individual bridge ports.

b) Configure Shorewall so that you specifically enumerate the IP
addresses of the hosts connected to all but one of the bridge ports.

Example where br0 connects to 192.168.1.0/24:

/etc/shorewall/shorewall.conf

BRIDGING=<doesn't matter>

/etc/shorewall/zones

z1      ipv4
z2      ipv4

/etc/shorewall/interfaces

-       br0     detect  routeback

/etc/shorewall/hosts:

z1      br0:192.168.1.1-192.168.1.15,192.168.1.18,...
z2      br0:192.168.1.0/24

In other words, explicitly specify the hosts in the first zone listed
in /etc/shorewall/zones (z1 in the above example) then simply specify
the entire network for the second zone. If the second zone contains your
default gateway, then you would enter 0.0.0.0/0 rather than
192.168.1.0/24.

I will expand these instructions into an article on the web site just as
soon as I find the time.

c) If you have ipset support, you can take the same approach as in b)
above but define 'z1' using one or more ipsets rather than with an
explicit lists of network/host IP addresses. That will generally result
in a smaller ruleset.
-----------------------------------------------------------------------
I realize that the options available to you are more cumbersome to
configure and maintain than what you have today but at the moment, I see
no alternatives. I will however continue to ponder the problem, and if I
come up with something better I will let you know.

-Tom

- 
-

-2006-07-11 Shorewall 3.2.0

- 
-
New Features:

1)  Shorewall has always been very noisy (lots of messages). No longer.

    You set the default level of verbosity using the VERBOSITY option in
    shorewall.conf. If you don't set it (as would be the case if you use your
    old shorewall.conf file) then VERBOSITY defaults to a value of 2 which
    results in behavior compatible with previous Shorewall versions.
    A value of 1 suppresses some of the output (like the old -q option did)
    while a value of 0 makes Shorewall almost silent. A value of -1
    suppresses all output except warning and error messages.

    The value specified in the 3.2 shorewall.conf is 1. So you can make
    Shorewall as verbose as previously using a single -v and you can make it
    almost silent by using a single -q.

    If VERBOSITY is set at 2, you can still make a command nearly
    silent by using two "q"s (e.g., shorewall -qq restart).

    In summary, each "q" subtracts one from VERBOSITY while each "v" adds one
    to VERBOSITY.

    The "shorewall show log", "shorewall logwatch" and "shorewall dump"
    commands require VERBOSITY to be greater than or equal to 3 to
    display MAC addresses.This is consistent with the previous
    implementation which required a single -v to enable MAC display but
    means that if you set VERBOSITY=0 in shorewall.conf, then you will
    need to include -vvv in commands that display log records in order
    to have MACs displayed.

    To make the display of MAC addresses less cumbersome, a '-m' option has
    been added to the "show" and logwatch commands:

        shorewall show -m log
        shorewall logwatch -m

2)  A new 'shorewall compile' command has been added.

     shorewall compile [ -e ] [ <config directory> ] <script file>

    where:

        -e                    Allows the generated script to run
                              on a system with Shorewall Lite installed.
                              Generates an error if the configuration uses
                              an option that would prevent the generated
                              script from running on a system other than
                              where the 'compile' command is running (see
                              additional consideration a) below).

        <config directory>    Is an optional directory to be searched for
                              configuration files prior to those listed
                              in CONFIG_DIR in
                              /etc/shorewall/shorewall.conf.

        <script file>         Is the name of the output file.

    The 'compile' command processes the configuration and generates a
    script file which may then be executed to configure the firewall.

    The generated script supports the following commands:

        start -   starts the firewall
        stop  -   stops the firewall
        clear -   clears the firewall (removes all iptables rules)
        restart - restarts the firewall
        status  - displays the firewall status
        version - displays the version of shorewall used to create the
                  script

    The generated script contains error checking and will terminate if an
    important command fails. Before terminating:

    a) The script will check for the existence of the restore script
       specified by the RESTOREFILE variable in shorewall.conf. If that
       restore script exists, it is executed.

    b) If the restore script doesn't exist but Shorewall appears to be
       installed on the system, the equivalent of an
       "/sbin/shorewall stop" command is executed.

    Some additional considerations:

    a) When you run 'compile' on one system and then run the generated script
       on another system under Shorewall Lite, there are certain limitations.

       1) A compatible version of Shorewall Lite must be running on the remote
          system. Going forward, the goal is that any minor version of
          the current major version will be compatible. So if the
          program is compiled using Shorewall 3.2.x, any 3.2.y version
          or 3.p.q version (where p > 2) of Shorewall Lite will be compatible.
       2) The 'detectnets' interface option is not allowed.
       3) DYNAMIC_ZONES=Yes is not allowed.
       4) You must supply the file /etc/shorewall/capabilities to provide
          the compiler with knowledge of the capabilities of the system
          where the script is to be run. See below.
       5) If your /etc/shorewall/params file contains code other than simple
          assignment statements with contant values, then you should move
          that code to /etc/shorewall/init. That way, the code will be
          executed on the target system when the compiled script is run and
          not on the local system at compile time.

    b) If you run the "shorewall compile" or "shorewall check" commands under
       a user other than 'root', then you must supply
       /etc/shorewall/capabilities.

    c) To aid in building /etc/shorewall/capabilities, a 'shorecap' program
       is provided in the Shorewall Lite package and is installed in
       /usr/share/shorewall-lite/shorecap when you install Shorewall Lite.

       For instructions about running shorecap, see the comments at the
       top of the program file (it's a simple shell script).

    The "shorewall start" and "shorewall restart" commands have been
    rewritten to use compilation. They both compile a temporary program
    then run it. This results in a slightly longer elapsed time than the
    similar commands required under earlier versions of Shorewall but new
    connections are blocked for a much smaller percentage of that time.

    If an error is found during the compilation phase, /sbin/shorewall
    terminates and the Shorewall state is unchanged.

    Under Shorewall 3.1.5, "shorewall restart" takes roughly 16.5 seconds
    on my firewall:

        real    0m16.599s
        user    0m6.292s
        sys     0m9.885s

    Of the elapsed 16.5 seconds, new connections are disabled less than
    3.5 seconds. Here are some numbers for comparison:

    A) shorewall restart (Shorewall 3.0.4)

        real    0m17.540s
        user    0m5.956s
        sys     0m10.737s

    B) ./foo restart # foo created using "shorewall compile"

        real    0m3.297s
        user    0m1.444s
        sys     0m1.728s

    C) shorewall restore (Shorewall 3.0.4) # Restores from file generated by
                                           # "shorewall save"

        real    0m1.164s
        user    0m0.556s
        sys     0m0.608s

    D) shorewall restore (shorewall 3.1.5)

        real    0m1.637s
        user    0m0.728s
        sys     0m0.584s

    The time difference between B and C reflects the difference between
    "iptables-restore" and multiple executions of "iptables". The time
    difference between C and D results from the fact that the "restore"
    command in Shorewall 3.1 runs the compiled program in a way that
    turns all iptables commands into no-ops then invokes
    iptables-restore. The system is a 1.4Ghz Celeron with 512MB RAM.

    As a final part of this change, the "check" command now compiles the
    current configuration and writes the compiled output to /dev/null. So
    "check" performs all of the same validation that compile does. Note that
    there is still no guarantee that the generated script won't encounter
    run-time errors.

2)  The /etc/shorewall/maclist file has a new column layout. The first column
    is now DISPOSITION. This column determines what to do with matching
    packets and can have the value ACCEPT or DROP (if MACLIST_TABLE=filter, it
    can also contain REJECT). This change is upward compatible so your existing
    maclist file can still be used.

    ACCEPT, DROP and REJECT may be optionally followed by a log level to
    cause the packet to be logged.

4)  In macro files, you can now use the reserved words SOURCE and DEST
    in the columns of the same names. When Shorewall expands the
    macro, it will substitute the SOURCE from the macro invocation for
    SOURCE and the DEST from the invocation for DEST. This allows you
    to write macros that act in both directions (from source to destination
    and from destination to source).

    Example:

        macro.FOO:

            PARAM      SOURCE        DEST      udp     500
            PARAM      DEST          SOURCE    udp     500

        /etc/shorewall/rules:

            FOO/ACCEPT    fw         net

        Resulting rules:

            ACCEPT        fw         net        udp     500
            ACCEPT        net        fw         udp     500

    This new feature has been used to implement the SMBBI macro.
    SMBBI is the same as the SMB macro with the exception that
    it passes SMB traffic in both directions whereas SMB only
    passes that traffic in one direction.

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

6)  /sbin/shorewall now supports a "-t" option that causes all progress
    messages to be timestamped.

    Example (VERBOSITY=0 in shorewall.conf):

    gateway:/etc/shorewall # shorewall -t restart
    07:08:51 Compiling...
    07:09:05 Shorewall configuration compiled to /var/lib/shorewall/.restart
    07:09:05 Restarting Shorewall....
    07:09:08 done.
    gateway:/etc/shorewall #

7)  A 'refreshed' extension script has been added -- it is executed after
    "shorewall refresh" has finished.

8)  Two new dynamic blacklisting commands have been added:

        logdrop -- like 'drop' but causes the dropped packets to be logged.

        logreject -- like 'reject' but causes the rejected packets to be
                     logged.

    Packets are logged at the BLACKLIST_LOGLEVEL if one was specified at the
    last "shorewall [re]start"; otherwise, they are logged at the 'info'
    log level.

9)  A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When
    this option is set to "Yes", it causes subzones to be treated differently
    with respect to policies.

    Subzones are defined by following their name with ":" and a list of parent
    zones (in /etc/shorewall/zones). Normally, you want to have a set of
    special rules for the subzone and if a connection doesn't match any of
    those subzone-specific rules then you want the parent zone rules and
    policies to be applied. With IMPLICIT_CONTINUE=Yes, that happens
    automatically.

    If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
    subzones are not subject to this special treatment.

    With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
    by including an explicit policy (one that does not specify "all" in either
    the SOURCE or the DEST columns).

    Example:

    /etc/shorewall/zones:

        prnt       ipv4
        chld:prnt  ipv4

    Traffic to/from the 'chld' zone will first pass through the applicable
    'chld' rules and if none of those rules match then it will be passed through
    the appropriate 'prnt' rules. If the connection request does not match
    any of the 'prnt' rules then the relevant 'prnt' policy is applied.

    If you want the fw->chld policy to be ACCEPT, simply add this entry to
    /etc/shorewall/policy:

        $FW      chld        ACCEPT

    Traffic from all other zones to 'chld' will be subject to the implicit
    CONTINUE policy.

10) Shorewall now includes support for explicit routing rules when the
    /etc/shorewall/providers file is used. A new file,
    /etc/shorewall/route_rules can be used to add routing rules based on
    packet source and/or destination.

    The file has the following columns:

                SOURCE(optonal) An ip address (network or host) that
                                matches the source IP address in a packet.
                                May also be specified as an interface
                                name optionally followed by ":" and an
                                address. If the define 'lo' is specified,
                                the packet must originate from the firewall
                                itself.

                DEST(optional)  An ip address (network or host) that
                                matches the destination IP address in a packet.

                                If you choose to omit either SOURCE or DEST,
                                place "-" in the column. Note that you
                                may not omit both SOURCE and DEST.

                PROVIDER        The provider to route the traffic through.
                                May be expressed either as the provider name
                                or the provider number. You may also specify
                                the 'main' routing table here, either by
                                name or by number (254).

                PRIORITY
                                The rule's priority which determines the order
                                in which the rules are processed.

                                1000-1999   Before Shorewall-generated
                                            'MARK' rules

                                11000- 11999 After 'MARK' rules but before
                                            Shorewall-generated rules for
                                            provider interfaces.

                                26000-26999 After provider interface rules but
                                            before 'default' rule.

                                Rules with equal priority are applied in
                                the order in which they appear in the file.

    Example 1: You want all traffic coming in on eth1 to be routed to the ISP1
             provider:

            #PROVIDER   PRIORITY        SOURCE                  DEST
            ISP1        1000            eth1

    Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple
               providers. In this case you have to set up a rule to ensure that
               the OpenVPN traffic is routed back through the tunX interface(s)
               rather than through any of the providers. 10.8.0.0/24 is the
               subnet choosen in your OpenVPN configuration (server 10.8.0.0
               255.255.255.0)

        #SOURCE                 DEST            PROVIDER        PRIORITY
        -                       10.8.0.0/24     main            1000

11) Prior to now, it has not been possible to use connection marking in
    /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
    'track' option.

    Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
    shorewall.conf to effectively divide the packet mark and connection mark
    into two 8-byte mark fields.

    When you do this:

        a) The MARK field in the providers file must have a value that is
           less than 65536 and that is a multiple of 256 (using hex
           representation, the values are 0x0100-0xFF00 with the low-order
           8 bits being zero).

        b) You may only set those mark values in the PREROUTING chain.

        c) Marks used for traffic shaping must still be in the range of 1-255
           and may still not be set in the PREROUTING chain.

        d) When you SAVE or RESTORE in tcrules, only the TC mark value is
           saved or restored. Shorewall handles saving and restoring the
           routing (provider) marks.

12) A TOS column has been added to /etc/shorewall/tcrules. This allows marking
    based on the contents of the TOS field in the packet header.

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

    a)  Packets *arriving* on a tracked interface are now passed to the PREROUTING
        marking chain so that they may be marked with a mark other than the
        'track' mark (the connection still retains the 'track' mark).

    b)  When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets
        in the PREROUTING chain (i.e., you can specify a mark value of zero).

14) Shorewall will now attempt to detect the MTU of devices listed in
    /etc/shorewall/tcdevices and will use the detected MTU in setting
    up traffic shaping.

15) In /etc/shorewall/rules, the values "all-" and "all+-" may now be
    used for zone names. "all-" means "All zones except the firewall";
    "all+-" means "All zones except the firewall" and intra-zone
    traffic is included.

16) 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:

    a) /usr/share/shorewall/modules -- the former
    /etc/shorewall/modules

    b) /usr/share/shorewall/xmodules -- a new file that support
    xtables.

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

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

17) Shorewall now checks to see if devices in /etc/shorewall/tcdevices
    exist. If a device does not exist, a warning message is issued and
    that device's entries in /etc/shorewall/tcclasses are ignored. This
    applies to "shorewall start", "shorewall restart" and "shorewall
    refresh".

18) "load" and "reload" commands have been added. These commands allow
    a non-root user with ssh access to a remote system running
    Shorewall Lite to compile a firewall script on the local system and
    to install that script on the remote system.

    Syntax is:

           shorewall [re]load [ <directory> ] <system>

    If <directory> is omitted, the current working directory is
    assumed.

    The command is equivalent to:

    /sbin/shorewall compile -e <directory> firewall &&\
    scp firewall root@<system>:/var/lib/shorewall-lite/ &&\
    ssh root@<system> '/sbin/shorewall-lite [re]start' # Note 1

    In other words, the configuration in the specified (or defaulted)
    directory is compiled to a file called firewall in that
    directory. If compilation succeeds, then 'firewall' is copied to the
    (usually remote) <system> using scp. If the copy succeeds,
    Shorewall Lite on <system> is started or restarted via ssh (
    load causes Shorewall Lite to be started and 'reload' causes
    Shorewall Lite to be re-started)

    Note 1: In Shorewall Lite 3.2.0 RC4, the 'firewall' script has moved
    from /usr/share/shorewall-lite/ to /var/lib/shorewall-lite in
    packages from shorewall.net. The package maintainers for the
    various distributions are free to choose the directory where the
    script will be stored under their distribution by altering the
    value of LITEDIR in /usr/share/shorewall/configpath. You can run the
    "shorewall show config" command to see how your distribution
    defines LITEDIR.

- 
-

-2006-06-21 Shorewall 3.0.8

- 
-
Problems corrected in 3.0.8

1)  If the 'upnp' interface option was specified on one or more
    interfaces but no forwardUPnP rule was included, the following
    diagnostic messages were issued:

        WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on
                eth0)
        ERROR: Fatal error in find_logactionchain

    Given that the fatal error message is obscure if the first WARNING
    isn't noticed, the ERROR message has been eliminated with the
    result that Shorewall now starts but won't handle UPnP properly.

2)  If BRIDGING=No in shorewall.conf, then an entry in
    /etc/shorewall/hosts such as the following would result in an
    obscure failure of an iptables command:

    loc   br0:eth0

    Shorewall now detects this case and issues a more helpful error
    message:

    ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0

3)  Users of the Multi-ISP feature may experience this error during startup:

    /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +
        $rulenum : syntax error: operand expected (error token is
        "$rulenum ")

4)  A more useful diagnostic is now given when a command fails during
    setup of traffic shaping.

5)  Shorewall now checks to see if devices in /etc/shorewall/tcdevices
    exist. If a device does not exist, a warning message is issued and
    that device's entries in /etc/shorewall/tcclasses are ignored. This
    applies to "shorewall start", "shorewall restart" and "shorewall
    refresh".

6)  It is now possible to exclude a single source MAC address using
    !<MAC address>. Previously, a startup error occurred.

7)  Shorewall would use the incorrect shell for compilation in the
    following case:

8)  Reporting of the "Mangle FORWARD Chain" capability was broken. While
    Shorewall correctly detected and used the capability, the output of
    "shorewall show capabilities" and "shorewall dump" showed the
    capability as "Not Available".

9)  Extension scripts for policy chains (chains with the word 'all' in
    their name) were not being run previously.

- 
-

-2006-05-27 Shorewall 2.4.9

- 
-
Problems corrected in 2.4.9

1)  Updated the bogons file to reflect recent IANA allocations.

2)  If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq and
    if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall start" will
    fail with the error 'Error: an inet prefix is expected rather than "SAME".'.

3)  It is now possible to exclude a single source MAC address using
    !<MAC address>. Previously, a startup error occurred.

- 
-

-2006-05-06 Shorewall 3.0.7

- 
-
Problems corrected in 3.0.7

1)  Previously, if your kernel did not supply the mangle table FORWARD chain
    then "shorewall [re]start" would fail. Now, if your mangle table does
    not supply this chain Shorewall will avoid using either that chain or
    the mangle table POSTROUTING chain. This change is strictly to stop Shorewall
    from blowing up during [re]start on very old kernels (such as 2.4.17
    running on a PS2); if your kernel does not support these chains and you
    try to mark packets in either of them using entries in
    /etc/shorewall/tcrules, [re]start will fail.

2)  Previously, if there were more than 10 IP addresses on a multi-ISP interface,
    some of the routing rules generated by Shorewall were placed after the
    default rule which resulted in them not being recognized.

3)  When install.sh is used to install on a Debian or Ubuntu system, the
    SUBSYSLOCK option in shorewall.conf was not being cleared.
    It will now be cleared, provided that Perl is installed on the system.

4)  When exclusion lists appeared in the /etc/shorewall/tcrules file, the
    resulting 'exclusion chains' (whose names begin with 'excl_') were not
    deleted as part of 'shorewall [re]start'. This meant that 'refresh'
    would fail, either the first or second time that it was done since
    the last 'shorewall [re]start'.

Other changes in 3.0.7

None.

-
-
- 
-

-2006-03-28 Shorewall moved to Subversion 

- 
-
 Effectively today, Shorewall source code repository was migrated to Subversion SCM.

Please read https://sourceforge.net/svn/?group_id=22587 
-and  http://www.shorewall.net/download.htm#SVN 
-for more information.

-
-
- 
-

-2006-03-28 Shorewall 3.0.6

- 
-
Problems corrected in 3.0.6

1)  A typo in the output of "help drop" has been corrected.

2)  Previously, 'shorewall start' would fail in the presence of a network
    interface named 'inet'.

3)  A shell syntax error was reported when duplicate policies appeared in
    /etc/shorewall/policy.

4)  The iptable_nat and iptable_mangle modules were previously omitted
    from /etc/shorewall/modules.

5)  If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq 
    and if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall 
    start" will fail with the error 'Error: an inet prefix is expected rather 
    than "SAME".'.

6)  Previously, the 'routeback' option was ignored in an entry in the
    /etc/shorewall/hosts file that referred to a (set of) bridge port(s).

    Example:

            dmz        xenbr0:vif+           routeback

Other changes in 3.0.6

1)  A 'refreshed' extension script has been added -- it is executed after
    "shorewall refresh" has finished.

-
-
- 
-

-2006-02-10 Shorewall 3.0.5

- 
-
Problems corrected in Shorewall 3.0.5

1)  Previously, if /etc/shorewall/ipsets existed, it was run when Shorewall starts
    but not when Shorewall was restored.

2)  When using the NETKEY IPSEC implementation in kernel 2.6 but without the
    policy match patch and the Netfilter/IPSEC patches, previously an
    entry in /etc/shorewall/tunnels was not sufficient in cases where:

    a) gw<->gw traffic was encrypted
    b) The gw<->gw policy through the tunnel was not ACCEPT

    Thanks to Tuomo Soini, this has been corrected. By simply including the
    remote VPN zone in the GATEWAY ZONE column for the tunnel's entry, no
    additional rules are required.

3)  Extra blank output lines are no longer produced by install.sh (patch
    courtesy of Tuomo Soini).

4)  TCP packets sent to QUEUE by rules in the ESTABLISHED section of the
    rules file previously didn't work (they had the "--syn" parameter
    added to them which resulted in a rule that no traffic would match).

    WARNING: If you use the QUEUE target from an action, Shorewall will
    still insert --syn if the protocol is tcp. So you don't want to
    invoke such an action from the ESTABLISHED section of the rules
    file.

5)  The description of the SOURCE column in /etc/shorewall/rules has been
    improved (patch courtesy of Ed Suominen).

6)  The 'allow', 'drop' and 'reject' commands no longer produce iptables
    errors when executed while Shorewall is not started.

7)  The spelling of "maximize-throughput" has been corrected in the code
    that implements tcclasses parsing. Patch courtesy of Paul Traina.

8)  Shorewall now generates the correct match for devices in
    /etc/shorewall/tcdevices that are actually bridge ports.

New Features in Shorewall 3.0.5

1)  The facilities available for dealing with the TOS field in
    /etc/shorewall/tcclasses has been expended. The OPTIONS field is now may
    contain a comma-separates list of the following:

        tos=0x<value>[/0x<mask>]        (mask defaults to 0xff)
                                        - this lets you define a classifier
                                        for the given <value>/<mask> combination
                                        of the IP packet's TOS/Precedence/DiffSrv
                                        octet (aka the TOS byte).  Please note,
                                        classifiers override all mark settings,
                                        so if you define a classifer for a class,
                                        all traffic having that mark will go in it
                                        regardless of any mark set on the packet
                                        by a firewall/mangle filter.

                                        NOTE: multiple tos= statements may be
                                        applied per class and per interface, but
                                        a given value/mask pair is valid for only
                                        ONE class per interface.

        tos-<tosname>                        - aliases for the following TOS octet
                                        value and mask encodings.  TOS encodings
                                        of the "TOS byte" have been deprecated in
                                        favor of diffserve classes, but programs
                                        like ssh, rlogin, and ftp still use them.

                                           tos-minimize-delay          0x10/0x10
                                        tos-maximize-throughput         0x08/0x08
                                        tos-maximize-reliability 0x04/0x04
                                        tos-minimize-cost         0x02/0x02
                                        tos-normal-service         0x00/0x1e

        tcp-ack                         -    defined causes an tc filter to
                                        be created that puts all tcp ack
                                        packets on that interface that have
                                        an size of <=64 Bytes to go in this
                                        class. This is useful for speeding up
                                        downloads. Please note that the size
                                        of the ack packets is limited to 64
                                        bytes as some applications (p2p for
                                        example) use to make every packet an
                                        ack packet which would cause them
                                        all into here. We want only packets
                                        WITHOUT payload to match, so the size
                                        limit.

                                        NOTE: This option is only valid for
                                        ONE class per interface.

    Note that the semantics of 'tos-<tosname>' have changed slightly. Previously,
    these were tested using a mask of 0xff (example: tos-minimize-delay was
    equivalent to 0x10/0xff). Now each bit is tested individually.

    This enhancement is courtesy of Paul Traina.

- 
-

-2006-01-05 Shorewall 3.0.4

- 
-
Problems Corrected in 3.0.4

1)  The shorewall.conf file is once again "console friendly". Patch is
    courtesy of Tuomo Soini.

2)  A potential security hole has been closed. Previously, Shorewall ACCEPTed
    all traffic from a bridge port that was sent back out on the same port. If
    the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,
    xenbr0:vif+), this could lead to traffic being passed in variance with the
    supplied policies and rules.

3)  Previously, an intra-zone policy of NONE would cause a startup error. That
    problem has been corrected.

4)  When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not
    add the retained aliases. This means that the following sequence of
    events resulted in missing aliases:

            shorewall start
            shorewall restart
            shorewall save
            reboot
            shorewall -f start (which is the default during boot up)

5)  When a 2.x standard action is invoked with a log level (example
    "AllowPing:info"), logging does not occur.

New Features in 3.0.4

1)  By popular demand, the 'Limit' action described at
    http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard
    action. Limit requires 'recent match' support in your kernel and iptables.

2)  DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This
    change is reported to improve Java startup time on some distributions.

3)  Shorewall now contains support for wildcard ports. In
    /etc/shorewall/hosts, you may specify the port name with trailing "+" then 
    use specific port names in rules.

    Example:

    /etc/shorewall/hosts

        vpn      br0:tap+

    /etc/shorewall/rules

        DROP      vpn:tap0              vpn:tap1          udp    9999

4)  For the benefit of those who run Shorewall on distributions that don't 
    autoload kernel modules, /etc/shorewall/modules now contains load commands 
    for a wide range of Netfilter modules.

- 
-

-2005-12-13 Shorewall 3.0.3

- 
-
Problems Corrected in 3.0.3

1) The comments in the /etc/shorewall/shorewall.conf and
   /etc/shorewall/hosts files have been changed to clarify when
   BRIDGING=Yes is required when dealing with bridges.

2) Thanks to Tuomo Soini, formatting of the comments in the tcdevices
   and tcclasses files has been cleaned up.

3) Specifying 'trace' on the 'safe-start' and 'safe-restart' command no
   longer fails.

4) The output of "shorewall help restore" has been corrected. It previously
   printed incorrect syntax for that command.

5) The README.txt file in the tarball was stale and contained incorrect
   information. It has been corrected.

6) The shorewall.conf default setting of CLEAR_TC was previously "No". Given
   that the default setting of TC_ENABLED is "Internal", the setting of
   CLEAR_TC has been changed to the more appropriate value of "Yes".

7) Specifying an interface name in the SOURCE column of /etc/shorewall/tcrules
   resulted in a startup error.

8) When the 'install.sh' script is used on Debian, it now creates
   /var/log/shorewall-init.log. And if perl is installed on the system then
   STARTUP_ENABLED=Yes is specified in shorewall.conf (the user must still
   set startup=1 in /etc/default/shorewall).

New Features in 3.0.3 

-
-1) A "shorewall show macros" command has been added. This command displays
-   a list of the standard macros along with a brief description of each.
-
-2) The '-q' option is now supported with 'safe-start' and 'safe-restart'.
-
-3) The value "-" is now allowed in the ADDRESS/SUBNET column of
-   /etc/shorewall/blacklist. That value is equivalent to specifying
-   0.0.0.0/0 in that column.
-
-4) The output of "shorewall show tc" and "shorewall show classifiers" is
-   now included in the output from "shorewall dump". This will aid us in
-   analyzing traffic shaping problems.
-
-5) You can now specify 'none' in the COPY column of /etc/shorewall/providers
-   to signal that you want Shorewall to only copy routes through the interface
-   listed in the INTERFACE column.
-
-   Note: This works on older versions of Shorewall as well. It is
-         now documented.
-
-6) An 'ipdecimal' command has been added to /sbin/shorewall. This command
-   converts between dot-quad and decimal.
-
-   Example:
-
-    gateway:/etc/openvpn# shorewall ipdecimal 192.168.1.4
-        3232235780
-    gateway:/etc/openvpn# shorewall ipdecimal 3232235780
-        192.168.1.4
-    gateway:/etc/openvpn#
-
-7) /etc/init.d/shorewall now supports a 'reload' command which is
-   synonymous with the 'restart' command.

-

-2005-12-12 Shorewall 2.4.7

-

-Problems Corrected in 2.4.7

-

-1)  When MACLIST_TABLE=mangle and an interface is enabled for DHCP (the

-    'dhcp' option is specified in /etc/shorewall/interfaces) then
-broadcasts

-    on UDP port 67 to address 255.255.255.255 from address 0.0.0.0 were
-being

-    dropped and logged. While this did not prevent the client from
-acquiring

-    an IP address, it could result in lots of log messages.

-

-2)  Entries for openvpn tunnels (including openvpnclient and

-    openvpnserver) that specify a port but no protocol cause startup

-    errors as follows:

-

-           iptables v1.3.3: unknown protocol `1194' specified

-           Try `iptables -h' or 'iptables --help' for more
-information.

-           ERROR: Command "/usr/sbin/iptables -A net2fw -p 1194 -s

-           0.0.0.0/0 --sport 1194 -j ACCEPT" Failed

-

-    The problem may be worked around by specifying the protocol as well

-    (e.g., "openvpn:udp:3455).

-

-3)  If the previous firewall configuration included a policy other than

-    ACCEPT in the nat, mangle or raw tables then Shorewall would not set

-    the policy to ACCEPT. This could result in a ruleset that rejected
-or

-    dropped all traffic.

-

-4)  Specifying an interface name in the SOURCE column 

-    of /etc/shorewall/tcrules resulted in a startup error.

- 
-

-2005-12-01 End of Support for Shorewall versions
-2.0 and 2.2

-

-Effective today, versions 2.0 and 2.2 are no longer supported. This
-means that if you find a bug in one of these releases, we won't fix it and if
-you ask for help with one of these releases, we will not spend much time
-trying to solve your issue.

-
-

-2005-11-25 Shorewall 3.0.2

- 
-
Problems Corrected in 3.0.2

1) A couple of typos in the one-interface sample configuration have
   been corrected.

2) The 3.0.1 version of Shorewall was incompatible with old versions of
   the Linux kernel (2.4.7 for example). The new code ignores errors
   produced when Shorewall 3.x is run on these ancient kernels.

3) Arch Linux installation routines has been improved.

New Features in 3.0.2

1) A new Webmin macro has been added. This macro assumes that Webmin is
   running on its default port (10000).

- 
-

-2005-11-18 Shorewall 3.0.1

-
-
Problems Corrected in 3.0.1 

-
-1) If the previous firewall configuration included a policy other than
-   ACCEPT in the nat, mangle or raw tables then Shorewall would not set
-   the policy to ACCEPT. This could result in a ruleset that rejected or
-   dropped all traffic.
-
-2) The Makefile was broken such that 'make' didn't always work correctly.
-
-3) If the SOURCE or DEST column in a macro body was non-empty and a dash
-   ("-") appeared in the corresponding column of an invocation of that
-   macro, then an invalid rule was generated.
-
-4) The comments in the /etc/shorewall/blacklist file have been updated to
-   clarify that the PORTS column refers to destination port number/service
-   names.
-
-5) When CLAMPMSS is set to a value other than "No" and FASTACCEPT=Yes, the
-   order of the rules generated was incorrect causing RELATED TCP connections
-   to not have CLAMPMSS applied.
-
-New Features in 3.0.1
-
-1)  To make the macro facility more flexible, Shorewall now examines the
-    contents of the SOURCE and DEST columns in both the macro body and in
-    the invocation and tries to create the intended rule. If the value in
-    the invocation appears to be an address (IP or MAC) or the name of an
-    ipset, then it is placed after the value in the macro body. Otherwise,
-    it is placed before the value in the macro body.
-
-    Example 1:
-
-    /etc/shorewall/macro.foo:
-
-    PARAM        -            192.168.1.5      tcp    http
-
-    /etc/shorewallrules:
-
-    foo/ACCEPT   net          loc
-
-    Effective rule:
-
-    ACCEPT       net          loc:192.168.1.5   tcp   http
-
-    Example 2:
-
-    /etc/shorewall/macro.bar:
-
-    PARAM        net           loc              tcp    http
-
-    /etc/shorewall/rules:
-
-    bar/ACCEPT   -             192.168.1.5
-
-    Effective rule:
-
-    ACCEPT       net           loc:192.168.1.5  tcp    http

-
-

-

-11/11/2005 Shorewall 3.0.0

-
-
New Features in Shorewall 3.0.0

1) Error and warning messages are made easier to spot by using
   capitalization (e.g., ERROR: and WARNING:).

2) A new option 'critical' has been added to
   /etc/shorewall/routestopped. This option can be used to enable
   communication with a host or set of hosts during the entire
   "shorewall [re]start/stop" process. Listing a host with this option
   differs from listing it without the option in several ways:

   a) The option only affect traffic between the listed host(s) and the
   firewall itself.

   b) If there are any entries with 'critical', the firewall
   will be completely opened briefly during start, restart and stop but
   there will be no chance of any packets to/from the listed host(s)
   being dropped or rejected.

   Possible uses for this option are:

   a) Root file system is NFS mounted. You will want to list the NFS server
   in the 'critical' option.

   b) You are running Shorewall in a Crossbeam environment
   (www.crossbeam.com). You will want to list the Crossbeam interface
   in this option

3) A new 'macro' feature has been added.

   Macros are very similar to actions and can be used in similar
   ways. The differences between actions and macros are as follows:

   a) An action creates a separate chain with the same name as the
      action (when logging is specified on the invocation of an action,
      a chain beginning with "%" followed by the name of the action and
      possibly followed by a number is created). When a macro is
      invoked, it is expanded in-line and no new chain is created.

   b) An action may be specified as the default action for a policy;
      macros cannot be specified this way.

   c) Actions must be listed in either /usr/share/shorewall/actions.std
      or in /etc/shorewall/actions. Macros are defined simply by
      placing their definition file in the CONFIG_PATH.

   d) Actions are defined in a file with a name beginning with
      "action." and followed by the name of the action. Macro files are
      defined in a file with a name beginning with "macro.".

   e) Actions may invoke other actions. Macros may not directly invoke
      other macros although they may invoke other macros indirectly
      through an action.

   f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They
      are allowed in a macro with the restriction that the a macro
      containing one of these rules may not be invoked from an action.

   g) The values specified in the various columns when you invoke a
      macro are substituted in the corresponding column in each rule in
      the macro. The first three columns get special treatment:

      ACTION         If you code PARAM as the action in a macro then
                 when you invoke the macro, you can include the
                 name of the macro followed by a slash ("/") and
                 an ACTION (either built-in or user-defined. All
                 instances of PARAM in the body of the macro will be
                 replaced with the ACTION.

                 Any logging applied when the macro is invoked is
                 applied following the same rules as for actions.

      SOURCE and
      DEST         If the rule in the macro file specifies a value and
                 the invocation of the rule also specifies a value then
                 the value in the invocation is appended to the value
                 in the rule using ":" as a separator.

                 Example:

                 /etc/shorewall/macro.SMTP

                 PARAM                -        loc        tcp        25

                 /etc/shorewall/rules:

                 SMTP/DNAT:info                net        192.168.1.5

                 Would be equivalent to the following in the rules file:

                 DNAT:info           net        loc:192.168.1.5        tcp        25

      Rest         Any value in the invocation replaces the value in the
                 rule in the macro.

    One additional restriction applies to the mixing of macros and
    actions. Macros that are invoked from actions cannot themselves
    invoke other actions.

4)  If you have 'make' installed on your firewall, then when you use
    the '-f' option to 'shorewall start' (as happens when you reboot),
    if your /etc/shorewall/ directory contains files that were modified
    after Shorewall was last restarted then Shorewall is started using
    the config files rather than using the saved configuration.

5)  The 'arp_ignore' option has been added to /etc/shorewall/interfaces
    entries. This option sets
    /proc/sys/net/ipv4/conf/<interface>/arp_ignore. By default, the
    option sets the value to 1. You can also write arp_ignore=<value>
    where value is one of the following:

        1 - reply only if the target IP address is local address
        configured on the incoming interface

        2 - reply only if the target IP address        is local address
        configured on the incoming interface and both with the sender's
        IP address are part from same subnet on this interface

        3 - do not reply for local addresses configured with scope
        host, only resolutions for global and link addresses are
        replied

        4-7 - reserved

         8 - do not reply for all local addresses

    WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN
    PROXY ARP.

6)  In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works
    like "all" but also includes intrazone traffic. So the rule:

         ACCEPT     loc                 all+         tcp           22

    would allow SSH traffic from loc->loc whereas

         ACCEPT     loc                 all         tcp           22

    does not.

7)  A new FASTACCEPT option has been added to shorewall.conf.

    Normally, Shorewall defers accepting ESTABLISHED/RELATED packets
    until these packets reach the chain in which the original connection
    was accepted. So for packets going from the 'loc' zone to the 'net'
    zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'
    chain.

    If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are
    accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
    FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or
    RELATED sections of /etc/shorewall/rules.

8)  Shorewall now generates an error if the 'norfc1918' option is
    specified for an interface with an RFC 1918 address.

9)  You may now specify "!" followed by a list of addresses in the
    SOURCE and DEST columns of entries in /etc/shorewall/rules,
    /etc/shorewall/tcrules and in action files and Shorewall will
    generate the rule that you expect.

    Example 1 (/etc/shorewall/rules):

    #ACTION    SOURCE                                DEST        PROTO     DEST PORT(S)
    ACCEPT     loc:!192.168.1.0/24,10.0.0.0/8        net        tcp          80

    That rule would allow loc->net HTTP access except for the local
    networks 192.168.1.0/24 and 10.0.0.0/8.

    Example 2 (/etc/shorewall/rules):

    #ACTION    SOURCE                                DEST        PROTO     DEST PORT(S)
    ACCEPT     loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \
                                                net        tcp          80

    That rule would allow loc->net HTTP access from the local
    network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.

10) Tunnel types "openvpnserver" and "openvpnclient" have been added
    to reflect the introduction of client and server OpenVPN
    configurations in OpenVPN 2.0.

11) The COMMAND variable is now set to 'restore' in restore
    scripts. The value of this variable is sometimes of interest to
    programmers providing custom /etc/shorewall/tcstart scripts.

12) Previously, if you defined any intra-zone rule(s) then any traffic
    not matching the rule(s) was subject to normal policies (which
    usually turned out to involve the all->all REJECT policy). Now, the
    intra-zone ACCEPT policy will still be in effect in the presence of
    intra-zone rules. That policy can still be overridden by an
    explicit policy in your /etc/shorewall/policy file.

    Example:

    /etc/shorewall/rules:

    DNAT        loc:!192.168.1.4  loc:192.168.1.4:3128        tcp        80

    Any other loc->loc traffic will still be accepted. If you want to
    also log that other loc->loc traffic at the info log level then
    insert this into /etc/shorewall/policy:

    #SOURCE        DEST        POLICY        LOG LEVEL
    loc                loc        ACCEPT        info

13) Prior to Shorewall 2.5.3, the rules file only controlled packets in
    the Netfilter states NEW and INVALID. Beginning with this release,
    the rules file can also deal with packets in the ESTABLISHED and
    RELATED states.

    The /etc/shorewall/rules file may now be divided into
    "sections". Each section is introduced by a line that begins with
    the keyword SECTION followed by the section name. Sections
    are as listed below and must appear in the order shown.

    ESTABLISHED

        Rules in this section apply to packets in the ESTABLISHED
        state.

    RELATED

        Rules in this section apply to packets in the RELATED state.

    NEW

        Rules in this section apply to packets in the NEW and INVALID
        states.

    Rules in the ESTABLISHED and RELATED sections are limited to the
    following ACTIONs:

        ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.

    Macros may be used in these sections provided that they expand to
    only these ACTIONs.

    At the end of the ESTABLISHED and RELATED sections, there is an
    implicit "ALLOW   all          all all" rule.

    RESTRICTION: If you specify FASTACCEPT=Yes in
    /etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED
    sections must be empty.

14) The value 'ipp2p' is once again allowed in the PROTO column of
    the rules file. It is recommended that rules specifying 'ipp2p'
    only be included in the ESTABLISHED section of the file.


15) Shorewall actions lack a generalized way to pass parameters to an
    extension script associated with an action. To work around this
    lack, some users have used the log tag as a parameter. This works
    but requires that a log level other than 'none' be specified when
    the action is invoked. Beginning with this release, you can invoke
    an action with 'none'.

    Example:

        #ACTION                                SOURCE          DEST
        A:none:these,are,parameters     $FW                net

    When /etc/shorewall/A is invoked, the LEVEL variable will be empty
    but the TAG variable will contain "these,are,parameters" which
    can be easily parsed to isolate "these", "are" and "parameters":

        ifs=$IFS
        IFS=,
        set -- $TAG
        IFS=$ifs2

    Now, $1 = these, $2 = are and $3 = parameters

16) The "shorewall check" command now checks the /etc/shorewall/masq,
    /etc/shorewall/blacklist, /etc/shorewall/proxyarp,
    /etc/shorewall/nat and /etc/shorewall/providers files.

17) Arne Bernin's "tc4shorewall" package has been integrated into
    Shorewall.

    See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.

    Thanks, Arne!

18) When /usr/share/shorewall/functions is loaded it now sets
2
         SHOREWALL_LIBRARY=Loaded

    Application code such as /etc/shorewall/tcstart may test that
    variable to determine if the library has been loaded into the
    current shell process.

19) The install.sh script now does a much cleaner job of backing up the
    current installation. It copies the directories /etc/shorewall,
    /usr/share/shorewall and /var/lib/shorewall to a directory of the
    same name with "-$VERSION.bkout" appended. The init script and
    /sbin/shorewall are backed up to the /usr/share/shorewall and
    /var/lib/shorewall directories respectively. This makes it very
    simple to remove the backups:

           rm -rf /etc/shorewall-*.bkout
           rm -rf /usr/share/shorewall-*.bkout
           rm -rf /var/lib/shorewall-*.bkout

20) A new '-n' option has been added to the "start", "restart",
    "restore",  "stop" and "try" commands. This option instructs
    Shorewall to not alter the routing in any way.

    This option is useful when you have a multi-ISP environment because
    it prevents the route cache from being flushed which preserves the
    mapping of end-point address pairs to routes.

21) The output of "shorewall dump" now includes a capabilities report
    such as the one produced by "shorewall show capabilities".

22) The "plain" zone type has been replaced by "ipv4". The types
    "IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",
    "ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".

23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been
    removed as have the 'newnotsyn' options in /etc/shorewall/interfaces
    and /etc/shorewall/hosts. See the Migration Considerations for
    instructions if you wish to block "new-not-syn" TCP packets.

24) The "shorewall show zones" command now displays the zone type. You
    must have restarted Shorewall using this release before this feature
    will work correctly.

25) The multi-ISP code now requires that that you set MARK_IN_FORWARD_CHAIN=Yes
    in shorewall.conf. This is done to ensure that "shorewall refresh" will
    work correctly.

26) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"
    keyword in the PROTOCOL column of the relevant files, the following
    values may be specified:

        ipp2p:tcp           Equivalent to ipp2p and matches TCP traffic
                            only.
        ipp2p:udp           Matches UDP traffic.
        ipp2p:all           Matches both UDP and TCP traffic. You may
                            not specify a SOURCE PORT with this PROTOCOL.

27) Normally MAC verification triggered by the 'maclist' interface and host
    options is done out of the INPUT and FORWARD chains of the filter table.
    Users have reported that under some circumstances, MAC verification is
    failing for forwarded packets when the packets are being forwarded out
    of a bridge.

    To work around this problem, a MACLIST_TABLE option has been added to
    shorewall.conf. The default value is MACLIST_TABLE=filter which results
    in the current behavior. If MACLIST_TABLE=mangle then filtering will
    take place out of the PREROUTING chain of the mangle table. Because
    the REJECT target may not be used in the PREROUTING chain, the settings
    MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.

28) The sample configurations are now packaged with the product. They are
    in the Samples directory on the tarball and are in the RPM they are
    in the Samples sub-directory of the Shorewall documentation
    directory.

- 
-

-10/31/2005 Shorewall 2.4.6

-

-Problems Corrected in 2.4.6

-
-
    
-  
  1. "shorewall refresh" would fail if there were entries in
-    /etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.
    2. 
-  
  2. An unprintable character in a comment caused /sbin/shorewall to fail
-    when used with a light-weight shell like 'dash'.
    3. 
-  
  3. When using some flavors of 'ash', certain /sbin/shorewall commands
-    produced 'ipset: not found' messages.
    4. 
-  
  4. Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0 but the
-    implementation was incomplete. It has now been completed and is
-    documented in the /etc/shorewall/tunnels file.
    5. 
-  
  5. The test that Shorewall uses to detect the availability of the owner
-    match capability has been changed to avoid the generation of ipt_owner
-    messages under kernel 2.6.14.
    6. 
-

-New Features in 2.4.6

-
-
    
-  
  1. Normally MAC verification triggered by the 'maclist' interface and host
-    options is done out of the INPUT and FORWARD chains of the filter table.
-    Users have reported that under some circulstances, MAC verification is
-    failing for forwarded packets when the packets are being forwarded out of
-    a bridge.
    
-    
    
-    To work around this problem, a MACLIST_TABLE option has been added to
-    shorewall.conf. The default value is MACLIST_TABLE=filter which results
-    in the current behavior. If MACLIST_TABLE=mangle then filtering will take
-    place out of the PREROUTING chain of the mangle table. Because the REJECT
-    target may not be used in the PREROUTING chain, the settings
-    MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.
    2. 
-  
  2. A "dump" command has been added to /sbin/shorewall for compatibility
-    with Shorewall 3.0. In 2.4.6, the "dump" command provides the same output
-    as the "status".
    
-  
    3. 
-

 Old News here

  
 
diff --git a/web/oldnews.html b/web/oldnews.html
index 9c7cec1a9..1e9a7b0b1 100644
--- a/web/oldnews.html
+++ b/web/oldnews.html
@@ -10,6 +10,313 @@
 
   
   10/05/2005
+
+2007-01-16 Shorewall 3.2.9

+ 
+
Problems Corrected in 3.2.9

1)  While most distributions store the Shorewall Lite compiled program
    in /var/lib/shorewall-lite/, Shorewall includes features that allow
    that location to be changed on a per-distribution basis. The
    default for a particular distribution may be determined by the
    command "shorewall[-lite] show config".

        teastep@lists:~/shorewall/trunk$ shorewall show config
        Default CONFIG_PATH is /etc/shorewall:/usr/share/shorewall
        LITEDIR is /var/lib/shorewall-lite
        teastep@lists:~/shorewall/trunk$

    The LITEDIR setting is the location where the compiled script
    should be placed. Unfortunately, the "shorewall [re]load" command
    previously used the setting on the administrative system rather
    than the one from the firewall system so it was possible for that
    command to upload the compiled script to the wrong directory.

    To work around this problem, Shorewall now determines the LITEDIR
    setting on the firewall system and uses that setting for uploading
    the compiled script and its companion .conf file.

2)  Previously, IP ranges and ipset names were handled incorrectly in
    the last column of the maclist file with the result that run-time
    errors occured.

3)  The new SIP and H323 Netfilter helper modules were not being
    automatically loaded by Shorewall. They have now been added to the
    /usr/share/shorewall[-lite]/modules files.

Other Changes in 3.2.9

1)  Previously, 'ipsecnat' tunnels allowed AH traffic by default
    (unless 'isecnat:noah' was given). Given that AH is incompatible
    with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.

2)  A macro that handles SixXS has been contributed by Christian
    Roessner.

3)  It is rather difficult to code a 'params' file that assigns other
    than constant values such that it works correctly with Shorewall
    Lite. To work around this problem, a new EXPORTPARAMS option
    has been added to shorewall.conf. When EXPORTPARAMS=No, the
    'params' file is no longer copied to the compiler output.

    With EXPORTPARAMS=No, if you need to set environmental variables on
    the firewall system for use by your extension scripts, then do so
    in the init extension script.

    The default is EXPORTPARAMS=Yes to retain the current behavior. So
    if you are happy with the current behavior, you need make no change
    to your shorewall.conf file.

+

+2007-01-16 Shorewall 3.2.8

+ 
+
Problems Corrected in 3.2.8

1)  The 'ash' shell produced an error when processing an entry with a
    log tag from /etc/shorewall/rules.

2)  If the file /etc/shorewall/init did not exist, then the compiler
    would incorrectly copy /usr/share/shorewall/init into the
    compiled script. /usr/share/shorewall/init is a symbolic link
    to the Shorewall init script (usually /etc/init.d/shorewall).

3)  Previously, "ipp2p:udp" was incorrectly rejected in the PROTO
    column of an action definition.

Other Changes in 3.2.8.

1)  New macros for network printing protocols have been added,
    courtesy of Tuomo Soini. Tuomo also provided a macro for TFTP.

    The print-oriented macros are:

        macro.IPP
        macro.Jetdirect
        macro.Printer

+ 
+

+

+
2006-12-14 Shorewall 3.2.7

+
Problems Corrected in 3.2.7

1)  Handling of saved ipsets in /etc/shorewall/ipsets is broken when
    used on a system running Shorewall Lite. If there is a file named
    'ipsets' on the CONFIG_PATH when the firewall script is compiled,
    then the compiled script attempts to restore the ipsets from that
    file (which may not exist on the firewall system).

2)  The 'try' command failed on systems whose /bin/sh is Busybox ash:

        /sbin/shorewall: export: 2158: Illegal option -n

3)  Previously, Shorewall has assumed that the root user is named
    'root'. Beginning with this release, the root user may have a
    different name. This required the addition of an '-r' option for
    the 'shorewall load' and 'shorewall reload' commands.

        [re]load [ -e ] [ -c ] [ -r <root user> ] [ <dir> ] system

    Example: shorewall reload -r foobar firewall

4)  On systems with a light-weight shell such as ash or dash for /bin/sh,
    the output of "shorewall show macros" was garbled.

Other Changes in 3.2.7

1)  Prior to this release, on firewall systems with Shorewall Lite
    installed, the local modules file is used to determine which kernel
    modules to load. Beginning with this release, if there is a
    'modules' file in the export directory when the firewall script is
    compiled, then that file will be copied into the compiled script
    and used on the firewall system.

2)  When syslogd is run with the -C option (which in some
    implementations causes syslogd to log to an in-memory circular
    buffer), /sbin/shorewall will now use the 'logread' command to read
    the log from that buffer. This is for combatibility with OpenWRT.

3)  Failures of the start, restart and restore commands are now logged
    using 'logger'. These failures are logged with the 'kern' facility 
    and 'err' priority. As part of this change, normal state changes
    are now logged with the 'kern' facility and 'info' priority.

+ 
+

+2006-11-18 Shorewall 3.2.6

+ 
+
Problems Corrected in 3.2.6.

1)  When using a light-weight shell (e.g., ash) with multiple
providers, the /etc/iproute2/rt_tables database may become corrupted.

2)  A startup error occurred when the LENGTH or TOS column was
    non-empty in /etc/shorewall/tcrules.

3)  A startup error resulted when whitespace as included in LOGFORMAT.

4)  Previously, when conntrack match support was not available, the
    'norfc1918' option on an interface or host group was incorrectly
    filtering IPSEC traffic whose source IP address was reserved by RFC
    1918.

5)  If a DNAT or REDIRECT rule was used where the effective policy
    between the source and final destination zones is ACCEPT, the ACCEPT
    part of the rule was not generated. This was intended as an
    optimizaiton but it could lead to confusing results if there was a
    DROP or REJECT rule following.

    This optimization has been removed. You may always use DNAT- and
    REDIRECT- to suppress generation of the ACCEPT rule.

6)  Shorewall[-lite] previously would return an error exit status to a
    "start" command where Shorewall was already running. It not returns
    a "success" status.

7)  The install.sh scripst have been corrected to work properly when 
    used to create packages on Slackware and Arch Linux.

5)  A change in version 3.2.5 broke Mac Filtration in some
    cases. Result was:

      Setting up MAC Filtration -- Phase 1...
      iptables v1.3.6: policy match: invalid policy `--dir'
      Try `iptables -h' or 'iptables --help' for more information.
      ERROR: Command "/sbin/iptables -A eth1_fwd -s 0.0.0.0/0 -m state 
             --state NEW -m policy --pol --dir in -j eth1_mac" Failed

6)  At VERBOSITY 1 and higher, the 'shorewall add' and 'shorewall
    delete' commands generated a fractured message. The message
    contents depended in the setting of IPSECFILE as follows:

    IPSECFILE=ipsec

        ipsec...

    IPSECFILE=zones

        IPSEC...

    The messages have been corrected and are only produced at VERBOSITY
    2 and higher as follows:

    IPSECFILE=ipsec

        Processing /etc/shorewall/ipsec...

    IPSECFILE=zones

        Processing IPSEC...

7)  Previously, when <action>:none appeared in a rule, the name of the
    action chain created was preceded by "%" and might have a one- or
    two-digit number appended. If both <action> and <action>:none
    appeared, then two chains were created. This has been corrected
    such that <action> and <action>:none are treated identically.

8)  If SAVE_IPSETS=Yes in shorewall.conf, the "shorewall[-lite] save"
    command produced error messages as follows:

       Dynamic Rules Saved
       Currently-running Configuration Saved to /var/lib/shorewall/restore
       grep: /var/lib/shorewall/restore-base: No such file or directory
       grep: /var/lib/shorewall/restore-base: No such file or directory
       Current Ipset Contents Saved to
       /var/lib/shorewall/restore-ipsets

9)  If BRIDGING=No in shorewall.conf, then an attempt to define a zone
    using ipsets fails as follows:

    ERROR: BRIDGING=Yes is needed for this zone definition: z eth0:+iset

Other Changes in 3.2.6.

1)  The "shorewall [re]load" command now supports a "-c" option.

    Example:

        shorewall reload -c gateway

    When -c is given, Shorewall will capture the capabilities of the
    remote system to a file named "capabilities" in the export
    directory before compiling the configuration.

    If the file "capabilities" does not currently exist in the 
    export directory then "-c" is automatically assumed.

2)  If 0 (zero) is specified for the IN-BANDWIDTH in
    /etc/shorewall/tcdevices then no ingress qdisc will be created for
    the device.

+ 
+

+2006-10-28 Shorewall 3.2.5

+ 
+
Problems Corrected in 3.2.5

1)  Entries such as the following in /etc/shorewall/masq generate a
    run-time error:

           eth0    eth1!192.168.1.12            206.124.146.176

    Omitting the exclusion (!192.168.1.12) avoids the error.

2)  Previously, the 'provider' portion of the packet mark was not being
    cleared after routing for traffic that originates on the firewall
    itself.

3)  In prior releases, it was not possible to mark an outgoing packet
    with a high mark (HIGH_ROUTE_MARKS=Yes) when the packet originated
    on the firewall itself.

4)  The detected capabilities were not displayed by 'shorewall dump'
    when the effective VERBOSITY was less than 2.

Other changes in 3.2.5

1)  For users whose kernel and iptables have Extended MARK Target
    support, it is now possible to logically AND or OR a value into the
    current packet mark by preceding the mark value (and optional mask)
    with an ampersand ("&") or vertical bar ("|") respectively.

    Example: To logically OR the value 4 into the mark value for
    packets from 192.168.1.1:

    #MARK   SOURCE
    |4      192.168.1.1

2)  A new macro (macro.RDP) has been added for Microsoft Remote
    Desktop. This macro was contributed by Tuomo Soini.

3)  A new 'maclog' extension file has been added. This file is
    processed just before logging based on the setting of
    MACLIST_LOG_LEVEL is done. When the script is copyied at compile
    time, the CHAIN variable will contain the name of the chain where
    rules should be inserted. Remember that if you have specified
    MACLIST_TABLE=mangle, then your run_iptables commands should
    include "-t mangle".

4)  Beginning with this release, Shorewall and Shorewall lite will
    share the same change log and release notes.

+ 
+

+2006-10-6 Shorewall 3.0.9

+ 
+
Problems corrected in 3.0.9

1)  When using a light-weight shell like ash or dash, "shorewall
    [re]start" fails when using the built-in traffic shaper. The error
    messages resemble these:

    local: 3: eth0:: bad variable name
    ERROR: Command "tc class add dev eth0 parent 1: classid 1:1 htb rate 800kbit mtu" Failed

2)  The output formating of the 'hits' command under BusyBox 1.2.0 has
    been corrected.

3)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not
    affect traffic to/from the firewall zone. That has been corrected.

4)  Previously, using IP address ranges in the accounting file could
    cause non-fatal iptables errors during shorewall [re]start.

Other changes in 3.0.9

1)  It is now possible to use the special value 'detect' in the ADDRESS
    column of /etc/shorewall/masq. This allows you to specify SNAT (as
    opposed to MASQUERADE) without having to know the ip address of the
    external interface. Shorewall must be restarted each time that the
    external address (the address of the interface named in the
    INTERFACE column) changes.

2)  Experimental optimization for PPP devices has been added to the
    providers file. If you omit the GATEWAY column for a ppp device (or
    enter "-" in the column) then Shorewall will generate routes
    for the named INTERFACE that do not specify a gateway IP address
    (the peer address will be assumed).

3)  Normally, Shorewall tries to protect users from themselves by
    preventing PREROUTING and OUTPUT tcrules from being applied to
    packets that have been marked by the 'track' option in
    /etc/shorewall/providers.

    If you really know what you are doing and understand packet marking
    thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and
    Shorewall will not include these cautionary checks.

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

+ 
+

+2006-09-27 Shorewall 3.2.4

+ 
+
Shorewall Problems corrected in 3.2.4

1)  Previously, the directory name in the command "shorewall start
    <directory name>" was being dropped by "/sbin/shorewall".

2)  Previous, when /usr/share/shorewall/xmodules had been copied to
    /etc/shorewall/modules, Shorewall was not looking in the correct
    directory for the "xt_..." modules. There are two parts to the fix:

    - The /usr/share/shorewall/xmodules file has been removed. The
      /usr/share/shorewall/modules file will now load all required
      modules regardless of which kernel version you are running.
    - The MODULESDIR option can now contain a colon-separated list of
      directories to search for modules with the default being:

      /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname -r)/kernel/net/netfilter

3)  Rules in /etc/shorewall/tos which specify zones defined
    using entries in /etc/shorewall/hosts applied to all traffic
    to/from the zone interfaces (the bridge port, ipset or IP
    address(es) in the zone definition were ignored).

4)  Previously, 'shorewall-lite dump' did not report traffic shaping
    information even if TC_ENABLED was set to Yes or Internal in the
    shorewall.conf file used to compile the exported firewall script.

    To correct this problem, the firewall script must be recompiled and
    re-exported.

5)  Previously, errors during the compile phase were not reflected in
    the exit status of /sbin/shorewall. Thanks to Tuomo Soini for
    finding and correcting this problem.

Other Shorewall changes in 3.2.4

1)  Previously, scripts compiled for export (-e option) depended on
    /usr/share/shorewall-lite/functions in order to run correctly. This
    made it possible for a compiled script to be incompatible with the
    version of Shorewall Lite installed on a firewall system.

    Beginning with Shorewall 3.2.4, this dependency is removed such
    that version incompatibility between Shorewall and Shorewall Lite
    should not be a concern going forward.

2)  Two new macros have been added, courtesy of Tuomo Soini

        macro.Finger
        macro.Telnets

3)  The output of "shorewall show macros" has been enhanced to show
    macros in each directory in the CONFIG_PATH.

Shorewall Lite problems corrected in 3.2.4

1)  Previous, when /usr/share/shorewall-lite/xmodules had been copied to
    /etc/shorewall-lite/modules, Shorewall was not looking in the correct
    directory for the "xt_..." modules. There are two parts to the fix:

    - The /usr/share/shorewall-lite/xmodules file has been removed. The
      /usr/share/shorewall-lite/modules file will now load all required
      modules regardless of which kernel version you are running.
    - The MODULESDIR option can now contain a colon-separated list of
      directories to search for modules with the default being:

      /lib/modules/$(uname
      -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname
      -r)/kernel/net/netfilter

     /usr/share/shorewall-lite/modules contains a *lot* of modules. If
     you use module autoloading (which non-embedded Linux distributions
     do), then you can improve your "shorewall [re]start" time by
     trimming all but the helper modules from the file. To do that,
     create the file /etc/shorewall-lite/modules with the following
     entries:

        loadmodule ip_conntrack_amanda
        loadmodule ip_conntrack_ftp
        loadmodule ip_conntrack_irc
        loadmodule ip_conntrack_netbios_ns
        loadmodule ip_conntrack_pptp
        loadmodule ip_conntrack_tftp
        loadmodule ip_nat_amanda
        loadmodule ip_nat_ftp
        loadmodule ip_nat_irc
        loadmodule ip_nat_pptp
        loadmodule ip_nat_snmp_basic
        loadmodule ip_nat_tftp

Other Shorewall Lite changes in 3.2.4

None.

+ 
+

+2006-08-26 Shorewall 3.2.3

+ 
+
Shorewall Problems Corrected in 3.2.3

 1)  A problem in 'install.sh' resulted in sandbox violations on
     Gentoo and, when Shorewall is installed using an RPM, the problem
     caused an incorrect copy of shorewall.conf to be installed in
     /usr/share/shorewall/configfiles/.

 2)  A typo in the functions file caused startup errors when the user's
     distribution did not support a true mktemp program (such as
     Bering Uclibc). Patch courtesy of Cédric Schieli.

 3)  Several erroneous references to ip_addr_del() were made in
     /var/lib/shorewall/compiler and in the code that it generates.

     a) These should have been references to del_ip_addr()
     b) One of the calls also had an incorrect parameter list.

 4)  Previously, "shorewall check -e" would erroneously attempt to
     detect interfaces configured for traffic shaping.

 5)  SUBSYSLOCK functionality has been restored.

 6)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not
     affect traffic to/from the firewall zone. That has been corrected.

 7)  When /sbin/shorewall was run under BusyBox ash, shell errors would
     occur if certain command options were given.

 8)  Previously, the 'optional' provider option did not detect the case
     where the interface was DOWN but still had a configured IP
     address. Shorewall was detecting such interfaces as UP and later
     'ip replace route' commands would fail.

     It should also be clarified that the 'optional' option is intended
     to detect cases where a provider interface is in a state that would
     cause 'shorewall [re]start' to fail; it is not intended to
     determine whether communication is possible using the interface.

 9)  Previously, the "shorewall add" command would fail with error
     messages indicating that the commands "chain_exists" and
     "verify_hosts_file" could not be found.

 10) Using earlier Shorewall versions, the following sequence of
     commands produced inconsistant results:

     a) shorewall [re] start
     b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses
     c) shorewall refresh
     d) shorewall save
     e) shorewall restore (or reboot and shorewall start -f during boot
        up)

     After that series of commands, the state of traffic shaping was as
     it was after step a) rather than as it was after step c). The fix
     involved re-implementing 'shorewall refresh' as a compile/execute
     procedure similar to [re]start. While the entire configuration is
     recompiled, only ecn, blacklisting, tcrules and traffic control
     will be updated in the running configuration.

 11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been
     incorrect with the result that the rules didn't work at all.

 Other Shorewall changes in 3.2.3

 1)  A 'shorewall export' command has been added.

     shorewall export [ <directory1> ] [user@]<system>:[<directory2>]

     If <directory1> is omitted, then the current working directory is
     assumed.

     Causes the shorewall configuration in <directory1> to be compiled
     into a program called '<directory1>/firewall'. If compilation is
     successful, the '<directory1>/firewall' script is copied via scp
     to the specified <system>.

     Example:

         shorewall export admin@gateway:

     This command would compile the configuration in the current working
     directory then copy the 'firewall' (and 'firewall.conf') files to
     admin's home directory on system 'gateway'.

 2)  Normally, Shorewall tries to protect users from themselves by
     preventing PREROUTING and OUTPUT tcrules from being applied to
     packets that have been marked by the 'track' option in
     /etc/shorewall/providers.

     If you really know what you are doing and understand packet marking
     thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and
     Shorewall will not include these cautionary checks.

 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.

     See the Migration Considerations section for further information.

 4)  Previously, if you specified 'detectnets' on an interface with a
     default route, Shorewall would ignore the default route with a
     warning message. This could lead to systems that were inaccessible
     from the net, even from systems listed in the 'routestopped' file.

     Specifying 'detectnets' on an interface with a default route now
     generates a fatal error.

Shorewall Lite problems corrected in 3.2.3

1)  A typo in /usr/share/shorewall-lite/functions caused startup errors
    on distributions like Bering Uclibc that don't have a true mktemp
    utility.

Other Shorewall Lite changes in 3.2.3

None.

+ 
+

+2006-08-10 Shorewall 3.2.2

+ 
+
Problems corrected in 3.0.8

1)  If the 'upnp' interface option was specified on one or more
    interfaces but no forwardUPnP rule was included, the following
    diagnostic messages were issued:

        WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on
                eth0)
        ERROR: Fatal error in find_logactionchain

    Given that the fatal error message is obscure if the first WARNING
    isn't noticed, the ERROR message has been eliminated with the
    result that Shorewall now starts but won't handle UPnP properly.

2)  If BRIDGING=No in shorewall.conf, then an entry in
    /etc/shorewall/hosts such as the following would result in an
    obscure failure of an iptables command:

    loc   br0:eth0

    Shorewall now detects this case and issues a more helpful error
    message:

    ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0

3)  Users of the Multi-ISP feature may experience this error during startup:

    /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +
        $rulenum : syntax error: operand expected (error token is
        "$rulenum ")

4)  A more useful diagnostic is now given when a command fails during
    setup of traffic shaping.

5)  Shorewall now checks to see if devices in /etc/shorewall/tcdevices
    exist. If a device does not exist, a warning message is issued and
    that device's entries in /etc/shorewall/tcclasses are ignored. This
    applies to "shorewall start", "shorewall restart" and "shorewall
    refresh".

6)  It is now possible to exclude a single source MAC address using
    !<MAC address>. Previously, a startup error occurred.

7)  Shorewall would use the incorrect shell for compilation in the
    following case:

8)  Reporting of the "Mangle FORWARD Chain" capability was broken. While
    Shorewall correctly detected and used the capability, the output of
    "shorewall show capabilities" and "shorewall dump" showed the
    capability as "Not Available".

9)  Extension scripts for policy chains (chains with the word 'all' in
    their name) were not being run previously.

-Tom

+ 
+

+2006-07-24 End of support for Shorewall
+2.4

+ 
+
Support for Shorewall 2.4 has ended. As always, we will try to help you
with your problems but I personally will not spend any time reading old
code trying to solve your problem and I will not provide patches for any
bugs found in versions earlier than 3.0.

+ 
+

+2006-07-21 Shorewall 3.2.1

+ 
+
Problems Corrected in Shorewall 3.2.1:

1)  The output formatting of the 'hits' command under BusyBox 1.2.0 has
    been corrected.

2)  Shorewall no longer requires extended MARK support to use the 'track'
    provider option when HIGH_ROUTE_MARKS=No.

3)  The output of the 'hits' command was previously scrambled if
    /etc/services contained spaces as column delimiters rather than
    tabs.

4)  The /usr/share/shorewall/xmodules file was previously just a copy
    of /usr/share/shorewall/modules.

5)  The version number in the comments at the top of shorewall.conf has
    been corrected.

6)  The script generated when the -e option is given to the 'compile'
    command is  setting CONFIG_PATH to the value given in the remote
    firewall's shorewall.conf processed at compile time. This is
    generally incorrect and results in the inability to load any kernel
    modules on the firewall during 'shorewall-lite [re]start'.

Problems Corrected in Shorewall Lite 3.2.1:

1)  The output formatting of the 'hits' command under BusyBox 1.2.0 has
    been corrected.

2)  The output of the 'hits' command was previously scrambled if
    /etc/services contained spaces as column delimiters rather than
    tabs.

3)  The /usr/share/shorewall-lite/xmodules file was previously just a
    copy of /usr/share/shorewall-lite/modules.

4)  The version number in the comments at the top of shorewall.conf has
    been corrected.

+ 
+

+2006-07-19 Shorewall bridge/firewall support
+change upcoming

+ 
+
I regret to announce that Shorewall bridge/firewall support in its
current form (BRIDGING=Yes in shorewall.conf) is going away. I will
retain the code in Shorewall for the foreseeable future but users
migrating to new kernels coming out next year will find that their
current bridge configurations no longer work. Shorewall bridge/firewall
users upgrading to more immediate new kernel releases (possibly as early
as 2.6.18) will find Netfilter warning messages appearing in their
kernel log when Shorewall [re]starts.

The reason that this support is going away is that the underlying
Netfilter feature that BRIDGING=Yes depends on (physdev match) is being
reduced in scope to the point that it will no longer be possible to use
that feature for Shorewall zone definition. There is a significant list
of pending Netfilter bug reports than cannot be resolved so long as
'physdev match' works the way that it does today.

While 'physdev match' was a great idea in terms of the function that it
provides, it appears impossible to implement that function without
breaking other parts of the greater Linux IP stack; in short, 'physdev
match' in its current form should never have been released in the first
place.

So -- what can current Shorewall bridge/firewall users do? 
-----------------------------------------------------------------------
a) Configure Shorewall as if you have a simple bridge
(http://www.shorewall.net/SimpleBridge.html) and use ebtables to filter
traffic in and out of the individual bridge ports.

b) Configure Shorewall so that you specifically enumerate the IP
addresses of the hosts connected to all but one of the bridge ports.

Example where br0 connects to 192.168.1.0/24:

/etc/shorewall/shorewall.conf

BRIDGING=<doesn't matter>

/etc/shorewall/zones

z1      ipv4
z2      ipv4

/etc/shorewall/interfaces

-       br0     detect  routeback

/etc/shorewall/hosts:

z1      br0:192.168.1.1-192.168.1.15,192.168.1.18,...
z2      br0:192.168.1.0/24

In other words, explicitly specify the hosts in the first zone listed
in /etc/shorewall/zones (z1 in the above example) then simply specify
the entire network for the second zone. If the second zone contains your
default gateway, then you would enter 0.0.0.0/0 rather than
192.168.1.0/24.

I will expand these instructions into an article on the web site just as
soon as I find the time.

c) If you have ipset support, you can take the same approach as in b)
above but define 'z1' using one or more ipsets rather than with an
explicit lists of network/host IP addresses. That will generally result
in a smaller ruleset.
-----------------------------------------------------------------------
I realize that the options available to you are more cumbersome to
configure and maintain than what you have today but at the moment, I see
no alternatives. I will however continue to ponder the problem, and if I
come up with something better I will let you know.

-Tom

+ 
+

+2006-07-11 Shorewall 3.2.0

+ 
+
New Features:

1)  Shorewall has always been very noisy (lots of messages). No longer.

    You set the default level of verbosity using the VERBOSITY option in
    shorewall.conf. If you don't set it (as would be the case if you use your
    old shorewall.conf file) then VERBOSITY defaults to a value of 2 which
    results in behavior compatible with previous Shorewall versions.
    A value of 1 suppresses some of the output (like the old -q option did)
    while a value of 0 makes Shorewall almost silent. A value of -1
    suppresses all output except warning and error messages.

    The value specified in the 3.2 shorewall.conf is 1. So you can make
    Shorewall as verbose as previously using a single -v and you can make it
    almost silent by using a single -q.

    If VERBOSITY is set at 2, you can still make a command nearly
    silent by using two "q"s (e.g., shorewall -qq restart).

    In summary, each "q" subtracts one from VERBOSITY while each "v" adds one
    to VERBOSITY.

    The "shorewall show log", "shorewall logwatch" and "shorewall dump"
    commands require VERBOSITY to be greater than or equal to 3 to
    display MAC addresses.This is consistent with the previous
    implementation which required a single -v to enable MAC display but
    means that if you set VERBOSITY=0 in shorewall.conf, then you will
    need to include -vvv in commands that display log records in order
    to have MACs displayed.

    To make the display of MAC addresses less cumbersome, a '-m' option has
    been added to the "show" and logwatch commands:

        shorewall show -m log
        shorewall logwatch -m

2)  A new 'shorewall compile' command has been added.

     shorewall compile [ -e ] [ <config directory> ] <script file>

    where:

        -e                    Allows the generated script to run
                              on a system with Shorewall Lite installed.
                              Generates an error if the configuration uses
                              an option that would prevent the generated
                              script from running on a system other than
                              where the 'compile' command is running (see
                              additional consideration a) below).

        <config directory>    Is an optional directory to be searched for
                              configuration files prior to those listed
                              in CONFIG_DIR in
                              /etc/shorewall/shorewall.conf.

        <script file>         Is the name of the output file.

    The 'compile' command processes the configuration and generates a
    script file which may then be executed to configure the firewall.

    The generated script supports the following commands:

        start -   starts the firewall
        stop  -   stops the firewall
        clear -   clears the firewall (removes all iptables rules)
        restart - restarts the firewall
        status  - displays the firewall status
        version - displays the version of shorewall used to create the
                  script

    The generated script contains error checking and will terminate if an
    important command fails. Before terminating:

    a) The script will check for the existence of the restore script
       specified by the RESTOREFILE variable in shorewall.conf. If that
       restore script exists, it is executed.

    b) If the restore script doesn't exist but Shorewall appears to be
       installed on the system, the equivalent of an
       "/sbin/shorewall stop" command is executed.

    Some additional considerations:

    a) When you run 'compile' on one system and then run the generated script
       on another system under Shorewall Lite, there are certain limitations.

       1) A compatible version of Shorewall Lite must be running on the remote
          system. Going forward, the goal is that any minor version of
          the current major version will be compatible. So if the
          program is compiled using Shorewall 3.2.x, any 3.2.y version
          or 3.p.q version (where p > 2) of Shorewall Lite will be compatible.
       2) The 'detectnets' interface option is not allowed.
       3) DYNAMIC_ZONES=Yes is not allowed.
       4) You must supply the file /etc/shorewall/capabilities to provide
          the compiler with knowledge of the capabilities of the system
          where the script is to be run. See below.
       5) If your /etc/shorewall/params file contains code other than simple
          assignment statements with contant values, then you should move
          that code to /etc/shorewall/init. That way, the code will be
          executed on the target system when the compiled script is run and
          not on the local system at compile time.

    b) If you run the "shorewall compile" or "shorewall check" commands under
       a user other than 'root', then you must supply
       /etc/shorewall/capabilities.

    c) To aid in building /etc/shorewall/capabilities, a 'shorecap' program
       is provided in the Shorewall Lite package and is installed in
       /usr/share/shorewall-lite/shorecap when you install Shorewall Lite.

       For instructions about running shorecap, see the comments at the
       top of the program file (it's a simple shell script).

    The "shorewall start" and "shorewall restart" commands have been
    rewritten to use compilation. They both compile a temporary program
    then run it. This results in a slightly longer elapsed time than the
    similar commands required under earlier versions of Shorewall but new
    connections are blocked for a much smaller percentage of that time.

    If an error is found during the compilation phase, /sbin/shorewall
    terminates and the Shorewall state is unchanged.

    Under Shorewall 3.1.5, "shorewall restart" takes roughly 16.5 seconds
    on my firewall:

        real    0m16.599s
        user    0m6.292s
        sys     0m9.885s

    Of the elapsed 16.5 seconds, new connections are disabled less than
    3.5 seconds. Here are some numbers for comparison:

    A) shorewall restart (Shorewall 3.0.4)

        real    0m17.540s
        user    0m5.956s
        sys     0m10.737s

    B) ./foo restart # foo created using "shorewall compile"

        real    0m3.297s
        user    0m1.444s
        sys     0m1.728s

    C) shorewall restore (Shorewall 3.0.4) # Restores from file generated by
                                           # "shorewall save"

        real    0m1.164s
        user    0m0.556s
        sys     0m0.608s

    D) shorewall restore (shorewall 3.1.5)

        real    0m1.637s
        user    0m0.728s
        sys     0m0.584s

    The time difference between B and C reflects the difference between
    "iptables-restore" and multiple executions of "iptables". The time
    difference between C and D results from the fact that the "restore"
    command in Shorewall 3.1 runs the compiled program in a way that
    turns all iptables commands into no-ops then invokes
    iptables-restore. The system is a 1.4Ghz Celeron with 512MB RAM.

    As a final part of this change, the "check" command now compiles the
    current configuration and writes the compiled output to /dev/null. So
    "check" performs all of the same validation that compile does. Note that
    there is still no guarantee that the generated script won't encounter
    run-time errors.

2)  The /etc/shorewall/maclist file has a new column layout. The first column
    is now DISPOSITION. This column determines what to do with matching
    packets and can have the value ACCEPT or DROP (if MACLIST_TABLE=filter, it
    can also contain REJECT). This change is upward compatible so your existing
    maclist file can still be used.

    ACCEPT, DROP and REJECT may be optionally followed by a log level to
    cause the packet to be logged.

4)  In macro files, you can now use the reserved words SOURCE and DEST
    in the columns of the same names. When Shorewall expands the
    macro, it will substitute the SOURCE from the macro invocation for
    SOURCE and the DEST from the invocation for DEST. This allows you
    to write macros that act in both directions (from source to destination
    and from destination to source).

    Example:

        macro.FOO:

            PARAM      SOURCE        DEST      udp     500
            PARAM      DEST          SOURCE    udp     500

        /etc/shorewall/rules:

            FOO/ACCEPT    fw         net

        Resulting rules:

            ACCEPT        fw         net        udp     500
            ACCEPT        net        fw         udp     500

    This new feature has been used to implement the SMBBI macro.
    SMBBI is the same as the SMB macro with the exception that
    it passes SMB traffic in both directions whereas SMB only
    passes that traffic in one direction.

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

6)  /sbin/shorewall now supports a "-t" option that causes all progress
    messages to be timestamped.

    Example (VERBOSITY=0 in shorewall.conf):

    gateway:/etc/shorewall # shorewall -t restart
    07:08:51 Compiling...
    07:09:05 Shorewall configuration compiled to /var/lib/shorewall/.restart
    07:09:05 Restarting Shorewall....
    07:09:08 done.
    gateway:/etc/shorewall #

7)  A 'refreshed' extension script has been added -- it is executed after
    "shorewall refresh" has finished.

8)  Two new dynamic blacklisting commands have been added:

        logdrop -- like 'drop' but causes the dropped packets to be logged.

        logreject -- like 'reject' but causes the rejected packets to be
                     logged.

    Packets are logged at the BLACKLIST_LOGLEVEL if one was specified at the
    last "shorewall [re]start"; otherwise, they are logged at the 'info'
    log level.

9)  A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When
    this option is set to "Yes", it causes subzones to be treated differently
    with respect to policies.

    Subzones are defined by following their name with ":" and a list of parent
    zones (in /etc/shorewall/zones). Normally, you want to have a set of
    special rules for the subzone and if a connection doesn't match any of
    those subzone-specific rules then you want the parent zone rules and
    policies to be applied. With IMPLICIT_CONTINUE=Yes, that happens
    automatically.

    If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
    subzones are not subject to this special treatment.

    With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
    by including an explicit policy (one that does not specify "all" in either
    the SOURCE or the DEST columns).

    Example:

    /etc/shorewall/zones:

        prnt       ipv4
        chld:prnt  ipv4

    Traffic to/from the 'chld' zone will first pass through the applicable
    'chld' rules and if none of those rules match then it will be passed through
    the appropriate 'prnt' rules. If the connection request does not match
    any of the 'prnt' rules then the relevant 'prnt' policy is applied.

    If you want the fw->chld policy to be ACCEPT, simply add this entry to
    /etc/shorewall/policy:

        $FW      chld        ACCEPT

    Traffic from all other zones to 'chld' will be subject to the implicit
    CONTINUE policy.

10) Shorewall now includes support for explicit routing rules when the
    /etc/shorewall/providers file is used. A new file,
    /etc/shorewall/route_rules can be used to add routing rules based on
    packet source and/or destination.

    The file has the following columns:

                SOURCE(optonal) An ip address (network or host) that
                                matches the source IP address in a packet.
                                May also be specified as an interface
                                name optionally followed by ":" and an
                                address. If the define 'lo' is specified,
                                the packet must originate from the firewall
                                itself.

                DEST(optional)  An ip address (network or host) that
                                matches the destination IP address in a packet.

                                If you choose to omit either SOURCE or DEST,
                                place "-" in the column. Note that you
                                may not omit both SOURCE and DEST.

                PROVIDER        The provider to route the traffic through.
                                May be expressed either as the provider name
                                or the provider number. You may also specify
                                the 'main' routing table here, either by
                                name or by number (254).

                PRIORITY
                                The rule's priority which determines the order
                                in which the rules are processed.

                                1000-1999   Before Shorewall-generated
                                            'MARK' rules

                                11000- 11999 After 'MARK' rules but before
                                            Shorewall-generated rules for
                                            provider interfaces.

                                26000-26999 After provider interface rules but
                                            before 'default' rule.

                                Rules with equal priority are applied in
                                the order in which they appear in the file.

    Example 1: You want all traffic coming in on eth1 to be routed to the ISP1
             provider:

            #PROVIDER   PRIORITY        SOURCE                  DEST
            ISP1        1000            eth1

    Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple
               providers. In this case you have to set up a rule to ensure that
               the OpenVPN traffic is routed back through the tunX interface(s)
               rather than through any of the providers. 10.8.0.0/24 is the
               subnet choosen in your OpenVPN configuration (server 10.8.0.0
               255.255.255.0)

        #SOURCE                 DEST            PROVIDER        PRIORITY
        -                       10.8.0.0/24     main            1000

11) Prior to now, it has not been possible to use connection marking in
    /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
    'track' option.

    Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
    shorewall.conf to effectively divide the packet mark and connection mark
    into two 8-byte mark fields.

    When you do this:

        a) The MARK field in the providers file must have a value that is
           less than 65536 and that is a multiple of 256 (using hex
           representation, the values are 0x0100-0xFF00 with the low-order
           8 bits being zero).

        b) You may only set those mark values in the PREROUTING chain.

        c) Marks used for traffic shaping must still be in the range of 1-255
           and may still not be set in the PREROUTING chain.

        d) When you SAVE or RESTORE in tcrules, only the TC mark value is
           saved or restored. Shorewall handles saving and restoring the
           routing (provider) marks.

12) A TOS column has been added to /etc/shorewall/tcrules. This allows marking
    based on the contents of the TOS field in the packet header.

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

    a)  Packets *arriving* on a tracked interface are now passed to the PREROUTING
        marking chain so that they may be marked with a mark other than the
        'track' mark (the connection still retains the 'track' mark).

    b)  When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets
        in the PREROUTING chain (i.e., you can specify a mark value of zero).

14) Shorewall will now attempt to detect the MTU of devices listed in
    /etc/shorewall/tcdevices and will use the detected MTU in setting
    up traffic shaping.

15) In /etc/shorewall/rules, the values "all-" and "all+-" may now be
    used for zone names. "all-" means "All zones except the firewall";
    "all+-" means "All zones except the firewall" and intra-zone
    traffic is included.

16) 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:

    a) /usr/share/shorewall/modules -- the former
    /etc/shorewall/modules

    b) /usr/share/shorewall/xmodules -- a new file that support
    xtables.

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

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

17) Shorewall now checks to see if devices in /etc/shorewall/tcdevices
    exist. If a device does not exist, a warning message is issued and
    that device's entries in /etc/shorewall/tcclasses are ignored. This
    applies to "shorewall start", "shorewall restart" and "shorewall
    refresh".

18) "load" and "reload" commands have been added. These commands allow
    a non-root user with ssh access to a remote system running
    Shorewall Lite to compile a firewall script on the local system and
    to install that script on the remote system.

    Syntax is:

           shorewall [re]load [ <directory> ] <system>

    If <directory> is omitted, the current working directory is
    assumed.

    The command is equivalent to:

    /sbin/shorewall compile -e <directory> firewall &&\
    scp firewall root@<system>:/var/lib/shorewall-lite/ &&\
    ssh root@<system> '/sbin/shorewall-lite [re]start' # Note 1

    In other words, the configuration in the specified (or defaulted)
    directory is compiled to a file called firewall in that
    directory. If compilation succeeds, then 'firewall' is copied to the
    (usually remote) <system> using scp. If the copy succeeds,
    Shorewall Lite on <system> is started or restarted via ssh (
    load causes Shorewall Lite to be started and 'reload' causes
    Shorewall Lite to be re-started)

    Note 1: In Shorewall Lite 3.2.0 RC4, the 'firewall' script has moved
    from /usr/share/shorewall-lite/ to /var/lib/shorewall-lite in
    packages from shorewall.net. The package maintainers for the
    various distributions are free to choose the directory where the
    script will be stored under their distribution by altering the
    value of LITEDIR in /usr/share/shorewall/configpath. You can run the
    "shorewall show config" command to see how your distribution
    defines LITEDIR.

+ 
+

+2006-06-21 Shorewall 3.0.8

+ 
+
Problems corrected in 3.0.8

1)  If the 'upnp' interface option was specified on one or more
    interfaces but no forwardUPnP rule was included, the following
    diagnostic messages were issued:

        WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on
                eth0)
        ERROR: Fatal error in find_logactionchain

    Given that the fatal error message is obscure if the first WARNING
    isn't noticed, the ERROR message has been eliminated with the
    result that Shorewall now starts but won't handle UPnP properly.

2)  If BRIDGING=No in shorewall.conf, then an entry in
    /etc/shorewall/hosts such as the following would result in an
    obscure failure of an iptables command:

    loc   br0:eth0

    Shorewall now detects this case and issues a more helpful error
    message:

    ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0

3)  Users of the Multi-ISP feature may experience this error during startup:

    /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +
        $rulenum : syntax error: operand expected (error token is
        "$rulenum ")

4)  A more useful diagnostic is now given when a command fails during
    setup of traffic shaping.

5)  Shorewall now checks to see if devices in /etc/shorewall/tcdevices
    exist. If a device does not exist, a warning message is issued and
    that device's entries in /etc/shorewall/tcclasses are ignored. This
    applies to "shorewall start", "shorewall restart" and "shorewall
    refresh".

6)  It is now possible to exclude a single source MAC address using
    !<MAC address>. Previously, a startup error occurred.

7)  Shorewall would use the incorrect shell for compilation in the
    following case:

8)  Reporting of the "Mangle FORWARD Chain" capability was broken. While
    Shorewall correctly detected and used the capability, the output of
    "shorewall show capabilities" and "shorewall dump" showed the
    capability as "Not Available".

9)  Extension scripts for policy chains (chains with the word 'all' in
    their name) were not being run previously.

+ 
+

+2006-05-27 Shorewall 2.4.9

+ 
+
Problems corrected in 2.4.9

1)  Updated the bogons file to reflect recent IANA allocations.

2)  If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq and
    if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall start" will
    fail with the error 'Error: an inet prefix is expected rather than "SAME".'.

3)  It is now possible to exclude a single source MAC address using
    !<MAC address>. Previously, a startup error occurred.

+ 
+

+2006-05-06 Shorewall 3.0.7

+ 
+
Problems corrected in 3.0.7

1)  Previously, if your kernel did not supply the mangle table FORWARD chain
    then "shorewall [re]start" would fail. Now, if your mangle table does
    not supply this chain Shorewall will avoid using either that chain or
    the mangle table POSTROUTING chain. This change is strictly to stop Shorewall
    from blowing up during [re]start on very old kernels (such as 2.4.17
    running on a PS2); if your kernel does not support these chains and you
    try to mark packets in either of them using entries in
    /etc/shorewall/tcrules, [re]start will fail.

2)  Previously, if there were more than 10 IP addresses on a multi-ISP interface,
    some of the routing rules generated by Shorewall were placed after the
    default rule which resulted in them not being recognized.

3)  When install.sh is used to install on a Debian or Ubuntu system, the
    SUBSYSLOCK option in shorewall.conf was not being cleared.
    It will now be cleared, provided that Perl is installed on the system.

4)  When exclusion lists appeared in the /etc/shorewall/tcrules file, the
    resulting 'exclusion chains' (whose names begin with 'excl_') were not
    deleted as part of 'shorewall [re]start'. This meant that 'refresh'
    would fail, either the first or second time that it was done since
    the last 'shorewall [re]start'.

Other changes in 3.0.7

None.

+
+
+ 
+

+2006-03-28 Shorewall moved to Subversion 

+ 
+
 Effectively today, Shorewall source code repository was migrated to Subversion SCM.

Please read https://sourceforge.net/svn/?group_id=22587 
+and  http://www.shorewall.net/download.htm#SVN 
+for more information.

+
+
+ 
+

+2006-03-28 Shorewall 3.0.6

+ 
+
Problems corrected in 3.0.6

1)  A typo in the output of "help drop" has been corrected.

2)  Previously, 'shorewall start' would fail in the presence of a network
    interface named 'inet'.

3)  A shell syntax error was reported when duplicate policies appeared in
    /etc/shorewall/policy.

4)  The iptable_nat and iptable_mangle modules were previously omitted
    from /etc/shorewall/modules.

5)  If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq 
    and if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall 
    start" will fail with the error 'Error: an inet prefix is expected rather 
    than "SAME".'.

6)  Previously, the 'routeback' option was ignored in an entry in the
    /etc/shorewall/hosts file that referred to a (set of) bridge port(s).

    Example:

            dmz        xenbr0:vif+           routeback

Other changes in 3.0.6

1)  A 'refreshed' extension script has been added -- it is executed after
    "shorewall refresh" has finished.

+
+
+ 
+

+2006-02-10 Shorewall 3.0.5

+ 
+
Problems corrected in Shorewall 3.0.5

1)  Previously, if /etc/shorewall/ipsets existed, it was run when Shorewall starts
    but not when Shorewall was restored.

2)  When using the NETKEY IPSEC implementation in kernel 2.6 but without the
    policy match patch and the Netfilter/IPSEC patches, previously an
    entry in /etc/shorewall/tunnels was not sufficient in cases where:

    a) gw<->gw traffic was encrypted
    b) The gw<->gw policy through the tunnel was not ACCEPT

    Thanks to Tuomo Soini, this has been corrected. By simply including the
    remote VPN zone in the GATEWAY ZONE column for the tunnel's entry, no
    additional rules are required.

3)  Extra blank output lines are no longer produced by install.sh (patch
    courtesy of Tuomo Soini).

4)  TCP packets sent to QUEUE by rules in the ESTABLISHED section of the
    rules file previously didn't work (they had the "--syn" parameter
    added to them which resulted in a rule that no traffic would match).

    WARNING: If you use the QUEUE target from an action, Shorewall will
    still insert --syn if the protocol is tcp. So you don't want to
    invoke such an action from the ESTABLISHED section of the rules
    file.

5)  The description of the SOURCE column in /etc/shorewall/rules has been
    improved (patch courtesy of Ed Suominen).

6)  The 'allow', 'drop' and 'reject' commands no longer produce iptables
    errors when executed while Shorewall is not started.

7)  The spelling of "maximize-throughput" has been corrected in the code
    that implements tcclasses parsing. Patch courtesy of Paul Traina.

8)  Shorewall now generates the correct match for devices in
    /etc/shorewall/tcdevices that are actually bridge ports.

New Features in Shorewall 3.0.5

1)  The facilities available for dealing with the TOS field in
    /etc/shorewall/tcclasses has been expended. The OPTIONS field is now may
    contain a comma-separates list of the following:

        tos=0x<value>[/0x<mask>]        (mask defaults to 0xff)
                                        - this lets you define a classifier
                                        for the given <value>/<mask> combination
                                        of the IP packet's TOS/Precedence/DiffSrv
                                        octet (aka the TOS byte).  Please note,
                                        classifiers override all mark settings,
                                        so if you define a classifer for a class,
                                        all traffic having that mark will go in it
                                        regardless of any mark set on the packet
                                        by a firewall/mangle filter.

                                        NOTE: multiple tos= statements may be
                                        applied per class and per interface, but
                                        a given value/mask pair is valid for only
                                        ONE class per interface.

        tos-<tosname>                        - aliases for the following TOS octet
                                        value and mask encodings.  TOS encodings
                                        of the "TOS byte" have been deprecated in
                                        favor of diffserve classes, but programs
                                        like ssh, rlogin, and ftp still use them.

                                           tos-minimize-delay          0x10/0x10
                                        tos-maximize-throughput         0x08/0x08
                                        tos-maximize-reliability 0x04/0x04
                                        tos-minimize-cost         0x02/0x02
                                        tos-normal-service         0x00/0x1e

        tcp-ack                         -    defined causes an tc filter to
                                        be created that puts all tcp ack
                                        packets on that interface that have
                                        an size of <=64 Bytes to go in this
                                        class. This is useful for speeding up
                                        downloads. Please note that the size
                                        of the ack packets is limited to 64
                                        bytes as some applications (p2p for
                                        example) use to make every packet an
                                        ack packet which would cause them
                                        all into here. We want only packets
                                        WITHOUT payload to match, so the size
                                        limit.

                                        NOTE: This option is only valid for
                                        ONE class per interface.

    Note that the semantics of 'tos-<tosname>' have changed slightly. Previously,
    these were tested using a mask of 0xff (example: tos-minimize-delay was
    equivalent to 0x10/0xff). Now each bit is tested individually.

    This enhancement is courtesy of Paul Traina.

+ 
+

+2006-01-05 Shorewall 3.0.4

+ 
+
Problems Corrected in 3.0.4

1)  The shorewall.conf file is once again "console friendly". Patch is
    courtesy of Tuomo Soini.

2)  A potential security hole has been closed. Previously, Shorewall ACCEPTed
    all traffic from a bridge port that was sent back out on the same port. If
    the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,
    xenbr0:vif+), this could lead to traffic being passed in variance with the
    supplied policies and rules.

3)  Previously, an intra-zone policy of NONE would cause a startup error. That
    problem has been corrected.

4)  When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not
    add the retained aliases. This means that the following sequence of
    events resulted in missing aliases:

            shorewall start
            shorewall restart
            shorewall save
            reboot
            shorewall -f start (which is the default during boot up)

5)  When a 2.x standard action is invoked with a log level (example
    "AllowPing:info"), logging does not occur.

New Features in 3.0.4

1)  By popular demand, the 'Limit' action described at
    http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard
    action. Limit requires 'recent match' support in your kernel and iptables.

2)  DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This
    change is reported to improve Java startup time on some distributions.

3)  Shorewall now contains support for wildcard ports. In
    /etc/shorewall/hosts, you may specify the port name with trailing "+" then 
    use specific port names in rules.

    Example:

    /etc/shorewall/hosts

        vpn      br0:tap+

    /etc/shorewall/rules

        DROP      vpn:tap0              vpn:tap1          udp    9999

4)  For the benefit of those who run Shorewall on distributions that don't 
    autoload kernel modules, /etc/shorewall/modules now contains load commands 
    for a wide range of Netfilter modules.

+ 
+

+2005-12-13 Shorewall 3.0.3

+ 
+
Problems Corrected in 3.0.3

1) The comments in the /etc/shorewall/shorewall.conf and
   /etc/shorewall/hosts files have been changed to clarify when
   BRIDGING=Yes is required when dealing with bridges.

2) Thanks to Tuomo Soini, formatting of the comments in the tcdevices
   and tcclasses files has been cleaned up.

3) Specifying 'trace' on the 'safe-start' and 'safe-restart' command no
   longer fails.

4) The output of "shorewall help restore" has been corrected. It previously
   printed incorrect syntax for that command.

5) The README.txt file in the tarball was stale and contained incorrect
   information. It has been corrected.

6) The shorewall.conf default setting of CLEAR_TC was previously "No". Given
   that the default setting of TC_ENABLED is "Internal", the setting of
   CLEAR_TC has been changed to the more appropriate value of "Yes".

7) Specifying an interface name in the SOURCE column of /etc/shorewall/tcrules
   resulted in a startup error.

8) When the 'install.sh' script is used on Debian, it now creates
   /var/log/shorewall-init.log. And if perl is installed on the system then
   STARTUP_ENABLED=Yes is specified in shorewall.conf (the user must still
   set startup=1 in /etc/default/shorewall).

New Features in 3.0.3 

+
+1) A "shorewall show macros" command has been added. This command displays
+   a list of the standard macros along with a brief description of each.
+
+2) The '-q' option is now supported with 'safe-start' and 'safe-restart'.
+
+3) The value "-" is now allowed in the ADDRESS/SUBNET column of
+   /etc/shorewall/blacklist. That value is equivalent to specifying
+   0.0.0.0/0 in that column.
+
+4) The output of "shorewall show tc" and "shorewall show classifiers" is
+   now included in the output from "shorewall dump". This will aid us in
+   analyzing traffic shaping problems.
+
+5) You can now specify 'none' in the COPY column of /etc/shorewall/providers
+   to signal that you want Shorewall to only copy routes through the interface
+   listed in the INTERFACE column.
+
+   Note: This works on older versions of Shorewall as well. It is
+         now documented.
+
+6) An 'ipdecimal' command has been added to /sbin/shorewall. This command
+   converts between dot-quad and decimal.
+
+   Example:
+
+    gateway:/etc/openvpn# shorewall ipdecimal 192.168.1.4
+        3232235780
+    gateway:/etc/openvpn# shorewall ipdecimal 3232235780
+        192.168.1.4
+    gateway:/etc/openvpn#
+
+7) /etc/init.d/shorewall now supports a 'reload' command which is
+   synonymous with the 'restart' command.

+

+2005-12-12 Shorewall 2.4.7

+

+Problems Corrected in 2.4.7

+

+1)  When MACLIST_TABLE=mangle and an interface is enabled for DHCP (the

+    'dhcp' option is specified in /etc/shorewall/interfaces) then
+broadcasts

+    on UDP port 67 to address 255.255.255.255 from address 0.0.0.0 were
+being

+    dropped and logged. While this did not prevent the client from
+acquiring

+    an IP address, it could result in lots of log messages.

+

+2)  Entries for openvpn tunnels (including openvpnclient and

+    openvpnserver) that specify a port but no protocol cause startup

+    errors as follows:

+

+           iptables v1.3.3: unknown protocol `1194' specified

+           Try `iptables -h' or 'iptables --help' for more
+information.

+           ERROR: Command "/usr/sbin/iptables -A net2fw -p 1194 -s

+           0.0.0.0/0 --sport 1194 -j ACCEPT" Failed

+

+    The problem may be worked around by specifying the protocol as well

+    (e.g., "openvpn:udp:3455).

+

+3)  If the previous firewall configuration included a policy other than

+    ACCEPT in the nat, mangle or raw tables then Shorewall would not set

+    the policy to ACCEPT. This could result in a ruleset that rejected
+or

+    dropped all traffic.

+

+4)  Specifying an interface name in the SOURCE column 

+    of /etc/shorewall/tcrules resulted in a startup error.

+ 
+

+2005-12-01 End of Support for Shorewall versions
+2.0 and 2.2

+

+Effective today, versions 2.0 and 2.2 are no longer supported. This
+means that if you find a bug in one of these releases, we won't fix it and if
+you ask for help with one of these releases, we will not spend much time
+trying to solve your issue.

+
+

+2005-11-25 Shorewall 3.0.2

+ 
+
Problems Corrected in 3.0.2

1) A couple of typos in the one-interface sample configuration have
   been corrected.

2) The 3.0.1 version of Shorewall was incompatible with old versions of
   the Linux kernel (2.4.7 for example). The new code ignores errors
   produced when Shorewall 3.x is run on these ancient kernels.

3) Arch Linux installation routines has been improved.

New Features in 3.0.2

1) A new Webmin macro has been added. This macro assumes that Webmin is
   running on its default port (10000).

+ 
+

+2005-11-18 Shorewall 3.0.1

+
+
Problems Corrected in 3.0.1 

+
+1) If the previous firewall configuration included a policy other than
+   ACCEPT in the nat, mangle or raw tables then Shorewall would not set
+   the policy to ACCEPT. This could result in a ruleset that rejected or
+   dropped all traffic.
+
+2) The Makefile was broken such that 'make' didn't always work correctly.
+
+3) If the SOURCE or DEST column in a macro body was non-empty and a dash
+   ("-") appeared in the corresponding column of an invocation of that
+   macro, then an invalid rule was generated.
+
+4) The comments in the /etc/shorewall/blacklist file have been updated to
+   clarify that the PORTS column refers to destination port number/service
+   names.
+
+5) When CLAMPMSS is set to a value other than "No" and FASTACCEPT=Yes, the
+   order of the rules generated was incorrect causing RELATED TCP connections
+   to not have CLAMPMSS applied.
+
+New Features in 3.0.1
+
+1)  To make the macro facility more flexible, Shorewall now examines the
+    contents of the SOURCE and DEST columns in both the macro body and in
+    the invocation and tries to create the intended rule. If the value in
+    the invocation appears to be an address (IP or MAC) or the name of an
+    ipset, then it is placed after the value in the macro body. Otherwise,
+    it is placed before the value in the macro body.
+
+    Example 1:
+
+    /etc/shorewall/macro.foo:
+
+    PARAM        -            192.168.1.5      tcp    http
+
+    /etc/shorewallrules:
+
+    foo/ACCEPT   net          loc
+
+    Effective rule:
+
+    ACCEPT       net          loc:192.168.1.5   tcp   http
+
+    Example 2:
+
+    /etc/shorewall/macro.bar:
+
+    PARAM        net           loc              tcp    http
+
+    /etc/shorewall/rules:
+
+    bar/ACCEPT   -             192.168.1.5
+
+    Effective rule:
+
+    ACCEPT       net           loc:192.168.1.5  tcp    http

+
+

+

+11/11/2005 Shorewall 3.0.0

+
+
New Features in Shorewall 3.0.0

1) Error and warning messages are made easier to spot by using
   capitalization (e.g., ERROR: and WARNING:).

2) A new option 'critical' has been added to
   /etc/shorewall/routestopped. This option can be used to enable
   communication with a host or set of hosts during the entire
   "shorewall [re]start/stop" process. Listing a host with this option
   differs from listing it without the option in several ways:

   a) The option only affect traffic between the listed host(s) and the
   firewall itself.

   b) If there are any entries with 'critical', the firewall
   will be completely opened briefly during start, restart and stop but
   there will be no chance of any packets to/from the listed host(s)
   being dropped or rejected.

   Possible uses for this option are:

   a) Root file system is NFS mounted. You will want to list the NFS server
   in the 'critical' option.

   b) You are running Shorewall in a Crossbeam environment
   (www.crossbeam.com). You will want to list the Crossbeam interface
   in this option

3) A new 'macro' feature has been added.

   Macros are very similar to actions and can be used in similar
   ways. The differences between actions and macros are as follows:

   a) An action creates a separate chain with the same name as the
      action (when logging is specified on the invocation of an action,
      a chain beginning with "%" followed by the name of the action and
      possibly followed by a number is created). When a macro is
      invoked, it is expanded in-line and no new chain is created.

   b) An action may be specified as the default action for a policy;
      macros cannot be specified this way.

   c) Actions must be listed in either /usr/share/shorewall/actions.std
      or in /etc/shorewall/actions. Macros are defined simply by
      placing their definition file in the CONFIG_PATH.

   d) Actions are defined in a file with a name beginning with
      "action." and followed by the name of the action. Macro files are
      defined in a file with a name beginning with "macro.".

   e) Actions may invoke other actions. Macros may not directly invoke
      other macros although they may invoke other macros indirectly
      through an action.

   f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They
      are allowed in a macro with the restriction that the a macro
      containing one of these rules may not be invoked from an action.

   g) The values specified in the various columns when you invoke a
      macro are substituted in the corresponding column in each rule in
      the macro. The first three columns get special treatment:

      ACTION         If you code PARAM as the action in a macro then
                 when you invoke the macro, you can include the
                 name of the macro followed by a slash ("/") and
                 an ACTION (either built-in or user-defined. All
                 instances of PARAM in the body of the macro will be
                 replaced with the ACTION.

                 Any logging applied when the macro is invoked is
                 applied following the same rules as for actions.

      SOURCE and
      DEST         If the rule in the macro file specifies a value and
                 the invocation of the rule also specifies a value then
                 the value in the invocation is appended to the value
                 in the rule using ":" as a separator.

                 Example:

                 /etc/shorewall/macro.SMTP

                 PARAM                -        loc        tcp        25

                 /etc/shorewall/rules:

                 SMTP/DNAT:info                net        192.168.1.5

                 Would be equivalent to the following in the rules file:

                 DNAT:info           net        loc:192.168.1.5        tcp        25

      Rest         Any value in the invocation replaces the value in the
                 rule in the macro.

    One additional restriction applies to the mixing of macros and
    actions. Macros that are invoked from actions cannot themselves
    invoke other actions.

4)  If you have 'make' installed on your firewall, then when you use
    the '-f' option to 'shorewall start' (as happens when you reboot),
    if your /etc/shorewall/ directory contains files that were modified
    after Shorewall was last restarted then Shorewall is started using
    the config files rather than using the saved configuration.

5)  The 'arp_ignore' option has been added to /etc/shorewall/interfaces
    entries. This option sets
    /proc/sys/net/ipv4/conf/<interface>/arp_ignore. By default, the
    option sets the value to 1. You can also write arp_ignore=<value>
    where value is one of the following:

        1 - reply only if the target IP address is local address
        configured on the incoming interface

        2 - reply only if the target IP address        is local address
        configured on the incoming interface and both with the sender's
        IP address are part from same subnet on this interface

        3 - do not reply for local addresses configured with scope
        host, only resolutions for global and link addresses are
        replied

        4-7 - reserved

         8 - do not reply for all local addresses

    WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN
    PROXY ARP.

6)  In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works
    like "all" but also includes intrazone traffic. So the rule:

         ACCEPT     loc                 all+         tcp           22

    would allow SSH traffic from loc->loc whereas

         ACCEPT     loc                 all         tcp           22

    does not.

7)  A new FASTACCEPT option has been added to shorewall.conf.

    Normally, Shorewall defers accepting ESTABLISHED/RELATED packets
    until these packets reach the chain in which the original connection
    was accepted. So for packets going from the 'loc' zone to the 'net'
    zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'
    chain.

    If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are
    accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
    FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or
    RELATED sections of /etc/shorewall/rules.

8)  Shorewall now generates an error if the 'norfc1918' option is
    specified for an interface with an RFC 1918 address.

9)  You may now specify "!" followed by a list of addresses in the
    SOURCE and DEST columns of entries in /etc/shorewall/rules,
    /etc/shorewall/tcrules and in action files and Shorewall will
    generate the rule that you expect.

    Example 1 (/etc/shorewall/rules):

    #ACTION    SOURCE                                DEST        PROTO     DEST PORT(S)
    ACCEPT     loc:!192.168.1.0/24,10.0.0.0/8        net        tcp          80

    That rule would allow loc->net HTTP access except for the local
    networks 192.168.1.0/24 and 10.0.0.0/8.

    Example 2 (/etc/shorewall/rules):

    #ACTION    SOURCE                                DEST        PROTO     DEST PORT(S)
    ACCEPT     loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \
                                                net        tcp          80

    That rule would allow loc->net HTTP access from the local
    network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.

10) Tunnel types "openvpnserver" and "openvpnclient" have been added
    to reflect the introduction of client and server OpenVPN
    configurations in OpenVPN 2.0.

11) The COMMAND variable is now set to 'restore' in restore
    scripts. The value of this variable is sometimes of interest to
    programmers providing custom /etc/shorewall/tcstart scripts.

12) Previously, if you defined any intra-zone rule(s) then any traffic
    not matching the rule(s) was subject to normal policies (which
    usually turned out to involve the all->all REJECT policy). Now, the
    intra-zone ACCEPT policy will still be in effect in the presence of
    intra-zone rules. That policy can still be overridden by an
    explicit policy in your /etc/shorewall/policy file.

    Example:

    /etc/shorewall/rules:

    DNAT        loc:!192.168.1.4  loc:192.168.1.4:3128        tcp        80

    Any other loc->loc traffic will still be accepted. If you want to
    also log that other loc->loc traffic at the info log level then
    insert this into /etc/shorewall/policy:

    #SOURCE        DEST        POLICY        LOG LEVEL
    loc                loc        ACCEPT        info

13) Prior to Shorewall 2.5.3, the rules file only controlled packets in
    the Netfilter states NEW and INVALID. Beginning with this release,
    the rules file can also deal with packets in the ESTABLISHED and
    RELATED states.

    The /etc/shorewall/rules file may now be divided into
    "sections". Each section is introduced by a line that begins with
    the keyword SECTION followed by the section name. Sections
    are as listed below and must appear in the order shown.

    ESTABLISHED

        Rules in this section apply to packets in the ESTABLISHED
        state.

    RELATED

        Rules in this section apply to packets in the RELATED state.

    NEW

        Rules in this section apply to packets in the NEW and INVALID
        states.

    Rules in the ESTABLISHED and RELATED sections are limited to the
    following ACTIONs:

        ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.

    Macros may be used in these sections provided that they expand to
    only these ACTIONs.

    At the end of the ESTABLISHED and RELATED sections, there is an
    implicit "ALLOW   all          all all" rule.

    RESTRICTION: If you specify FASTACCEPT=Yes in
    /etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED
    sections must be empty.

14) The value 'ipp2p' is once again allowed in the PROTO column of
    the rules file. It is recommended that rules specifying 'ipp2p'
    only be included in the ESTABLISHED section of the file.


15) Shorewall actions lack a generalized way to pass parameters to an
    extension script associated with an action. To work around this
    lack, some users have used the log tag as a parameter. This works
    but requires that a log level other than 'none' be specified when
    the action is invoked. Beginning with this release, you can invoke
    an action with 'none'.

    Example:

        #ACTION                                SOURCE          DEST
        A:none:these,are,parameters     $FW                net

    When /etc/shorewall/A is invoked, the LEVEL variable will be empty
    but the TAG variable will contain "these,are,parameters" which
    can be easily parsed to isolate "these", "are" and "parameters":

        ifs=$IFS
        IFS=,
        set -- $TAG
        IFS=$ifs2

    Now, $1 = these, $2 = are and $3 = parameters

16) The "shorewall check" command now checks the /etc/shorewall/masq,
    /etc/shorewall/blacklist, /etc/shorewall/proxyarp,
    /etc/shorewall/nat and /etc/shorewall/providers files.

17) Arne Bernin's "tc4shorewall" package has been integrated into
    Shorewall.

    See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.

    Thanks, Arne!

18) When /usr/share/shorewall/functions is loaded it now sets
2
         SHOREWALL_LIBRARY=Loaded

    Application code such as /etc/shorewall/tcstart may test that
    variable to determine if the library has been loaded into the
    current shell process.

19) The install.sh script now does a much cleaner job of backing up the
    current installation. It copies the directories /etc/shorewall,
    /usr/share/shorewall and /var/lib/shorewall to a directory of the
    same name with "-$VERSION.bkout" appended. The init script and
    /sbin/shorewall are backed up to the /usr/share/shorewall and
    /var/lib/shorewall directories respectively. This makes it very
    simple to remove the backups:

           rm -rf /etc/shorewall-*.bkout
           rm -rf /usr/share/shorewall-*.bkout
           rm -rf /var/lib/shorewall-*.bkout

20) A new '-n' option has been added to the "start", "restart",
    "restore",  "stop" and "try" commands. This option instructs
    Shorewall to not alter the routing in any way.

    This option is useful when you have a multi-ISP environment because
    it prevents the route cache from being flushed which preserves the
    mapping of end-point address pairs to routes.

21) The output of "shorewall dump" now includes a capabilities report
    such as the one produced by "shorewall show capabilities".

22) The "plain" zone type has been replaced by "ipv4". The types
    "IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",
    "ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".

23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been
    removed as have the 'newnotsyn' options in /etc/shorewall/interfaces
    and /etc/shorewall/hosts. See the Migration Considerations for
    instructions if you wish to block "new-not-syn" TCP packets.

24) The "shorewall show zones" command now displays the zone type. You
    must have restarted Shorewall using this release before this feature
    will work correctly.

25) The multi-ISP code now requires that that you set MARK_IN_FORWARD_CHAIN=Yes
    in shorewall.conf. This is done to ensure that "shorewall refresh" will
    work correctly.

26) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"
    keyword in the PROTOCOL column of the relevant files, the following
    values may be specified:

        ipp2p:tcp           Equivalent to ipp2p and matches TCP traffic
                            only.
        ipp2p:udp           Matches UDP traffic.
        ipp2p:all           Matches both UDP and TCP traffic. You may
                            not specify a SOURCE PORT with this PROTOCOL.

27) Normally MAC verification triggered by the 'maclist' interface and host
    options is done out of the INPUT and FORWARD chains of the filter table.
    Users have reported that under some circumstances, MAC verification is
    failing for forwarded packets when the packets are being forwarded out
    of a bridge.

    To work around this problem, a MACLIST_TABLE option has been added to
    shorewall.conf. The default value is MACLIST_TABLE=filter which results
    in the current behavior. If MACLIST_TABLE=mangle then filtering will
    take place out of the PREROUTING chain of the mangle table. Because
    the REJECT target may not be used in the PREROUTING chain, the settings
    MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.

28) The sample configurations are now packaged with the product. They are
    in the Samples directory on the tarball and are in the RPM they are
    in the Samples sub-directory of the Shorewall documentation
    directory.

+ 
+

+10/31/2005 Shorewall 2.4.6

+

+Problems Corrected in 2.4.6

+
+
    
+  
  1. "shorewall refresh" would fail if there were entries in
+    /etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.
    2. 
+  
  2. An unprintable character in a comment caused /sbin/shorewall to fail
+    when used with a light-weight shell like 'dash'.
    3. 
+  
  3. When using some flavors of 'ash', certain /sbin/shorewall commands
+    produced 'ipset: not found' messages.
    4. 
+  
  4. Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0 but the
+    implementation was incomplete. It has now been completed and is
+    documented in the /etc/shorewall/tunnels file.
    5. 
+  
  5. The test that Shorewall uses to detect the availability of the owner
+    match capability has been changed to avoid the generation of ipt_owner
+    messages under kernel 2.6.14.
    6. 
+

+New Features in 2.4.6

+
+
    
+  
  1. Normally MAC verification triggered by the 'maclist' interface and host
+    options is done out of the INPUT and FORWARD chains of the filter table.
+    Users have reported that under some circulstances, MAC verification is
+    failing for forwarded packets when the packets are being forwarded out of
+    a bridge.
    
+    
    
+    To work around this problem, a MACLIST_TABLE option has been added to
+    shorewall.conf. The default value is MACLIST_TABLE=filter which results
+    in the current behavior. If MACLIST_TABLE=mangle then filtering will take
+    place out of the PREROUTING chain of the mangle table. Because the REJECT
+    target may not be used in the PREROUTING chain, the settings
+    MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.
    2. 
+  
  2. A "dump" command has been added to /sbin/shorewall for compatibility
+    with Shorewall 3.0. In 2.4.6, the "dump" command provides the same output
+    as the "status".
    
+  
    3. 
+

+

 Shorewall 2.4.5