shorewall_code/Shorewall-common/releasenotes.txt

Shorewall 4.2.5

----------------------------------------------------------------------------
               R E L E A S E  4 . 2  H I G H L I G H T S
----------------------------------------------------------------------------
1) Support is included for multiple internet providers through the same
   ethernet interface.

2) Support for NFLOG has been added.

3) Enhanced operational logging.

4) The tarball installers now work under Cygwin.

5) Shorewall-perl now supports IFB devices which allow traffic shaping of
   incoming traffic.

6) Shorewall-perl supports definition of u32 traffic classification
   filters.

7) Support for IPv6 is available beginning with Shorewall 4.2.4.

   Minimun system requirements for IPv6 support:

   - Kernel 2.6.25 or later.
   - iptables 1.4.0 or later with 1.4.1 strongly recommended.
   - Perl 5.10 if you wish to use DNS names in your IPv6 config files. 
     In that case you will also have to install Perl Socket6 support.

Problems corrected in 4.2.5

1)  If exclusion is used to define a zone in /etc/shorewall/hosts and
    that zone is used as the SOURCE zone in a DNAT or REDIRECT rule,
    then Shorewall-perl can generated invalid iptables-restore input.

2)  A bug in the Perl Cwd module (see
    http://rt.cpan.org/Public/Bug/Display.html?id=13851) causes the
    Shorewall-perl compiler to fail if it doesn't have at least read
    access to its current working directory. 4.2.5 contains a
    workaround.

3)  If 'critical' was specified on an entry in
    /etc/shorewall/routestopped, Shorewall6 (Shorewall-perl) would
    generate an error. 

4)  In certain cases where exclusion occurred in /etc/shorewall/hosts,
    Shorewall-perl would generate incorrect iptables-restore input.

5)  In certain cases where exclusion occurred in /etc/shorewall/hosts,
    Shorewall-perl would generate invalid iptables-restore input.

6)  The 'shorewall6 refresh' command runs iptables_restore rather than
    ip6tables_restore.

7)  The commands 'shorewall6 save-start', 'shorewall6-save-restart' and
    'shorewall6 restore' were previously broken.

8)  The Debian init script was checking $startup in
    /etc/default/shorewall rather than in /etc/default/shorweall6

9)  The Archlinux init scripts for Shorewall6 and Shorewall6 Lite were
    unconverted Shorewall scripts.

10) When 'detect' is used in the GATEWAY column of
    /etc/shorewall/providers, Shorewall-perl now ensures that the
    gateway was successfully detected. If the gateway cannot be
    detected, action is taken depending on whether the provider is
    'optional' or not. If the provider is optional, it's configuration
    is skipped; if the provider is not optional, the current operation
    is aborted.

11) The command 'shorewall6 debug start' would previously fail with

    	ERROR: Command "/sbin/ip6tables -t nat -F" Failed

Known Problems Remaiining:

1)  When exclusion is used in an entry in /etc/shorewall/hosts, then
    Shorewall-shell produces an invalid iptables rule if any of the 
    following OPTIONS are also specified in the entry:    

        blacklist
	maclist
	norfc1918
	tcpflags

New Feature in Shorewall 4.2.5

1)  A new 'fallback' option is added in
    /etc/shorewall/providers. The option works similar to 'balance'
    except that the default route is added in the default routing table
    (253) rather than in the main table (254).

    The option can be used by itself or followed by =<number> (e.g,
    fallback=2).

    When the option is used by itself, a separate (not balanced)
    default route is added with a metric equal to the provider's NUMBER.

    When the option is used with a number, a balanced route is added
    with the weight set to the specified number.

    'fallback' is ignored if USE_DEFAULT_RT=Yes in shorewall.conf and
    is only available with Shorewall-perl.

    'fallback' is useful in situations where:

    - You want all traffic to be sent via one primary provider unless
      there is a compelling reason to use a different provider

    - If the primary provider is down, then you want to balance the
      outgoing traffic among a set of other providers or to a
      ordered list of providers.

    In this case:

    - Do not specify 'balance' on any of the providers.
    - Disable route filtering ('ROUTE_FILTER=No' in shorewall.conf).
    - Specify 'fallback' on those providers that you want to use if 
      the primary is down.
    - Only the primary provider should have a default route in the main
      routing table.

    See http://www.shorewall.net/MultiISP.html#Complete for an example
    of this option's use.

2)  Shorewall-perl now transparently handles the xtables-addon version
    of ipp2p. Shorewall detects whether the installed ipp2p is from
    patch-o-matic-ng or from xtables-addon and proceeds accordingly.

    If the patch-o-matic-ng version is installed:

    a) If no DEST PORT is supplied, the default is "--ipp2p".
    b) If "ipp2p" is supplied as the DEST PORT, it will be passed to
       iptables-restore as "--ipp2p".

    If the xtables-addons version is installed:

    a) If no DEST PORT is supplied, the default is "--edk --gnu --dc
       --kazaa".
    b) If "ipp2p" is supplied as the DEST PORT, it will be passed to
       iptables-restore as "--edk --gnu --dc --kazaa". 

    Shorewall-perl now also accepts a comma-separated list of options
    (e.g., "edk,gnu,dc,kazaa).

    Additionally, Shorewall now looks for modules in /lib/modules/$(uname
    -r)/extra and in /lib/modules/$(uname -r)/extra/ipset

    This change introduced a new capability ("Old IPP2P Match Syntax")
    so if you use a capabilities file, be sure to re-generate the
    file(s) after you have installed 4.2.5.

3)  There is now a macro.Git, which opens git-daemon's port (9418/tcp).

Migration Issues.

1)  Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
    mark values < 256 to be assigned in the OUTPUT chain. This has been
    changed so that only high mark values may be assigned
    there. Packet marking rules for traffic shaping of packets
    originating on the firewall must be coded in the POSTROUTING table.

2)  Previously, Shorewall did not range-check the value of the
    VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2:

    a) A VERBOSITY setting outside the range -1 through 2 is rejected.
    b) After the -v and -q options are applied, the resulting value is
       adjusted to fall within the range -1 through 2.

3)  Specifying a destination zone in a NAT-only rule now generates a
    warning and the destination zone is ignored. NAT-only rules are:

             NONAT
             REDIRECT-
             DNAT-

4)  The default value for LOG_MARTIANS has been changed. Previously,
    the defaults were:

        Shorewall-perl - 'Off'
        Shorewall-shell - 'No'

    The new default values are:

        Shorewall-perl - 'On'
        Shorewall-shell - 'Yes'.

    Shorewall-perl users may:

    a) Accept the new default -- martians will be logged from all
       interfaces with route filtering except those with log_martians=0
       in /etc/shorewall/interfaces.

    b) Explicitly set LOG_MARTIANS=Off to maintain compatibility with
       prior versions of Shorewall.

    Shorewall-shell users may:

    a) Accept the new default -- martians will be logged from all
       interfaces with the route filtering enabled.

    b) Explicitly set LOG_MARTIONS=No to maintain compatibility with 
       prior versions of Shorewall.

5)  The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has
    been changed from Yes to No.

6)  The 'norfc1918' option is deprecated. Use explicit rules instead.
    Note that there is a new 'Rfc1918' macro that acts on addresses
    reserved by RFC 1918.

7)  DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use
    ipset-based zones instead.

New Features in Shorewall 4.2

1)  Shorewall 4.2 contains support for multiple Internet providers
    through a single ethernet interface. Configuring two providers
    through a single interface differs from two providers through two
    interfaces in several ways.

    a) Only ethernet (or ethernet-like) interfaces can be used. For
       inbound traffic, the MAC addresses of the gateway routers is used
       to determine which provider a packet was received through. Note
       that only routed traffic can be categorized using this technique.

    b) You must specify the address on the interface that corresponds to
       a particular provider in the INTERFACE column by following the
       interface name with a colon (":") and the address.
 
    c) Entries in /etc/shorewall/masq must be qualified by the provider
       name (or number).

    d) This feature requires Realm Match support in your kernel and
       iptables. If you use a capabilities file, you need to regenerate
       the file with Shorewall 4.2 or Shorewall-lite 4.2.
 
    e) You must add route_rules entries for networks that are accessed
       through a particular provider.

    f) If you have additional IP addresses through either provider,
       you must add route_rules to direct traffic FROM each of those
       addresses through the appropriate provider.

    g) You must add MARK rules for any traffic that you know originates
       from a particular provider.

     Example:

     Providers Blarg (1) and Avvanta (2) are both connected to
     eth0. The firewall's IP address with Blarg is 206.124.146.176/24
     (gateway 206.124.146.254) and the IP address from Avvanta is
     130.252.144.8/24 (gateway 130.252.144.254). We have a second IP
     address (206.124.146.177) from Blarg.

     /etc/shorewall/providers:

       #PROVIDER   NUMBER  MARK    DUPLICATE INTERFACE            GATEWAY
       Blarg       1       1       main      eth0:206.124.146.176 206.124.146.254 ...
       Avvanta     2       2       main      eth0:130.252.144.8   130.252.144.254 ...

     /etc/shorewall/masq:

       #INTERFACE          SOURCE          ADDRESS
       eth0(Blarg)         130.252.144.8   206.124.146.176
       eth0(Avvanta)       206.124.146.176 130.252.144.8
       eth0(Blarg)         eth1            206.124.146.176
       eth0(Avvanta)       eth1            130.252.144.8

     /etc/shorewall/route_rules:

        #SOURCE            DEST                    PROVIDER        PRIORITY
        -                  206.124.146.0/24        Blarg           1000
        -                  130.252.144.0/24        Avvanta         1000
        206.124.146.177    -                       Blarg           26000

     /etc/shorewall/tcrules

        #MARK/CLASSIFY  SOURCE                       DEST
        1                eth0:206.124.146.0/24  0.0.0.0/0
        2                eth0:130.242.144.0/24  0.0.0.0/0

2)  You may now include the name of a table (nat, mangle or filter) in
    a 'shorewall refresh' command by following the table name with a
    colon (e.g., mangle:). This causes all non-builtin chains in the
    table to be reloaded.

    Example:

        shorewall refresh nat:

3)  When no chain name is given to the 'shorewall refresh' command, the
    mangle table is refreshed along with the blacklist chain (if
    any). This allows you to modify /etc/shorewall/tcrules and install
    the changes using 'shorewall refresh'.

4)  Support for the NFLOG log target has been added. NFLOG is a
    successor to ULOG. In addition, both ULOG and NFLOG may be followed
    by a list of up to three numbers in parentheses.

    The first number specifies the netlink group (1-32). If omitted
    (e.g., NFLOG(,0,10)) then a value of 1 is assumed.

    The second number specifies the maximum number of bytes to copy. If
    omitted, 0 (no limit) is assumed.

    The third number specifies the number of log messages that should
    be buffered in the kernel before they are sent to user space. The
    default is 1.

    Examples:

    /etc/shorewall/shorewall.conf:

        MACLIST_LOG_LEVEL=NFLOG(1,0,1)

    /etc/shorewall/rules:

        ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080

5)  Shorewall-perl 4.2 implements an alternative syntax for macro
    parameters and for the NFQUEUE queue number. Rather than following
    the macro name (or NFQUEUE) with a slash ("/") and the parameter,
    the parameter may be enclosed in parentheses.

    Examples -- each pair shown below are equivalent:

    DNS/ACCEPT          DNS(ACCEPT)
    NFQUEUE/3           NFQUEUE(3)
    
    The old syntax will still be accepted but will cease to be documented
    in some future Shorewall release.

6)  Shorewall 4.2 contains enhanced operational logging capabilities
    through a set of related enhancements to Shorewall-common and
    Shorewall-perl. The enhancements are not supported by
    Shorewall-shell nor are they supported by Shorewall-lite except
    when the script is compiled using Shorewall-perl.

    a)  The STARTUP_LOG option in /etc/shorewall/shorewall.conf gives
        the name of the Shorewall operational log. The log will be
        created if it does not exist.

    b)  The LOG_VERBOSITY option in /etc/shorewall/shorewall.conf gives
        the verbosity at which logging will occur. It uses the same
        value range as VERBOSITY:

        -1    Do not log
        0     Almost quiet
        1     Only major steps
        2     Verbose

    c)  An absolute VERBOSITY may be specified on the command line
        using the -v option followed by -1,0,1 or 2.

        Example:

                shorewall -v2 check

    d)  The /etc/init.d/shorewall script supplied with the
        shorewall.net packages sets '-v0' as the default. This may be
        overridden with the OPTIONS setting in /etc/defaults/shorewall or
        /etc/sysconfig/shorewall.

    Logging occurs on both Shorewall-perl and the generated script when
    the following commands are issued:

        start
        restart
        refresh

    Messages in the log are always timestamped.

    This change implemented two new options to the Shorewall-perl
    compiler (/usr/share/shorewall-perl/compiler.pl).

        --log=<logfile>
        --log_verbosity={-1|0-2}

    The --log option is ignored when --log_verbosity is not supplied or
    is supplied with value -1.

    To avoid a proliferation of parameters to
    Shorewall::Compiler::compile(), that function has been changed to
    use named parameters. Parameter names are:

         object          Object file. If omitted or '', the
                         configuration is syntax checked. 
         directory       Directory. If omitted or '', configuration
                         files are located using
                         CONFIG_PATH. Otherwise, the directory named by
                         this parameter is searched first.
         verbosity       Verbosity; range -1 to 2
         timestamp       0|1 -- timestamp messages.
         debug           0|1 -- include stack trace in warning/error
                         messages. 
         export          0|1 -- compile for export.
         chains          List of chains to be reloaded by 'refresh'.
         log             File to log compiler messages to.
         log_verbosity   Log Verbosity; range -1 to 2.

    Those parameters that are supplied must have defined values.

    Defaults are:

             object         '' ('check' command)
             directory      ''
             verbosity      1
             timestamp      0
             debug          0
             export         0
             chains         ''
             log            ''
             log_verbosity  -1
             

    Example:

    use lib '/usr/share/shorewall-perl/';
    use Shorewall::Compiler;

    compiler( object        => '/root/firewall', 
              log           => '/root/compile.log',
              log_verbosity => 2 );

7)  Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
    mark values < 256 to be assigned in the OUTPUT chain. This has been
    changed so that only high mark values may be assigned
    there. Packet marking rules for traffic shaping of packets
    originating on the firewall must be coded in the POSTROUTING chain.

8)  Previously, Shorewall did not range-check the value of the
    VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2:

    a) A VERBOSITY setting outside the range -1 through 2 is rejected.
    b) After the -v and -q options are applied, the resulting value is
       adjusted to fall within the range -1 through 2.

9)  The tcdevices file has been extended to include an OPTIONS
    column. Currently only a single option is defined.

    classify   When specified, you must use explicit CLASSIFY tcrules
               to classify traffic by class. Shorewall will not create
               any CLASSIFY rules to classify traffic by mark value.

    See http://www.shorewall.net/traffic_shaping.htm for further
    information.

10) COMMENT lines are now supported in macro bodies by Shorewall-perl
    and are ignored by the Shorewall-shell compiler.

    COMMENT lines in macros work slightly differently from COMMENT
    lines in other files. COMMENT lines in macros are ignored if
    COMMENT support is not available or if there was a COMMENT in use
    when the top-level macro was invoked. This allows the
    following:

        /etc/shorewall/macro.SSH:

            #ACTION SOURCE  PROTO   DEST    SOURCE  RATE    USER/
            #                       PORT(S) PORT(S) LIMIT   GROUP
            COMMENT My SSH Macro
            PARAM   -       -       tcp     22

        /etc/shorewall/rules:

            COMMENT Allow SSH from home
            SSH/ALLOW     net:$MYIP        $FW
            COMMENT
   
        The comment line in macro.SSH will not override the 
        COMMENT line in the rules file and the generated rule will show

                /* Allow SSH from home */

        when displayed through the Shorewall show and dump commands.

    If a macro is invoked and there is no current comment, then the
    name of the macro automatically becomes the current comment. This
    makes macros self-commenting.   

11) If the program named in SHOREWALL_SHELL doesn't exist or is not
    executable, Shorewall and Shorewall-lite now both fall back to
    /bin/sh after issuing a warning message. Previously, both
    terminated with a fatal error.

12) Shorewall-perl now generates fatal error conditions if there are
    no IPv4 zones defined or there are no interfaces defined.

13) Shorewall now unconditionally uses tc filter rules to classify
    traffic by MARK value. Previously, Shorewall used the CLASSIFY
    target in the POSTROUTING chain if it was available.

14) The Shorewall installers (install.sh) now work on Windows
    under Cygwin. By default, they install under the user id and group
    of the person doing the install. This can be overridden by
    specifying OWNER and GROUP explicitly.

    Example:

        OWNER=foo GROUP=bar ./install.sh

    To install Shorewall-perl under Cygwin:

    $ tar -zxf shorewall-perl-4.x.y.tar.bz2
    $ tar -zxf shorewall-common-4.x.y.tar.bz2
    $ cd shorewall-perl-4.x.y
    $ ./install.sh
    $ cd ../shorewall-common-4.x.y
    $ ./install.sh
    
    The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).

15) When installing on Cygwin, /etc/shorewall is no longer fully
    populated. Rather, only the shorewall.conf and params files are
    installed. As always, the full configuration file set is installed
    in /usr/share/shorewall/configfiles.

16) Specifying a destination zone in a NAT-only rule now generates a
    warning and the destination zone is ignored. NAT-only rules are:

             NONAT
             REDIRECT-
             DNAT-

17)  The /etc/shorewall/masq and /etc/shorewall/nat file now accept a
    comma-separated list of interface names where before only a single
    interface name could be listed (Shorewall-perl only).

    This feature is not for beginners. It iterates over the
    list of interfaces, substituting each interface in place of the
    list and processing the resulting entry according to the semantics
    of earlier Shorewall versions. If you don't know where to use this,
    don't try.

    Example 1:

    /etc/shorewall/masq:

    #INTERFACE              SOURCE          ADDRESS
    eth0,eth1               eth2            1.2.3.4

    equivalent to:

    #INTERFACE              SOURCE          ADDRESS
    eth0                    eth2            1.2.3.4
    eth1                    eth2            1.2.3.4

    Example 2:

    /etc/shorewall/masq:

    #INTERFACE                       SOURCE      ADDRESS
    eth0,eth1::192.168.1.0/24        eth2        1.2.3.4

    equivalent to:

    #INTERFACE              SOURCE          ADDRESS
    eth0::192.168.1.0/24    eth2            1.2.3.4
    eth1::192.168.1.0/24    eth2            1.2.3.4

    Example 3:

    /etc/shorewall/nat:

    #EXTERNAL        INTERFACE       INTERNAL
    206.124.146.178  eth0,wlan0      192.168.1.3

    equivalent to:

    #EXTERNAL        INTERFACE       INTERNAL
    206.124.146.178  eth0            192.168.1.3
    206.124.146.178  wlan0           192.168.1.3

18) Previously, the INTERFACE name used in the masq, nat and netmap
    files had to exactly match the name of an interface from the
    interfaces file. Beginning with Shorewall-perl 4.1.4, the
    interface may loosely match a wildcard entry in the interfaces
    file.

    Example:

    /etc/shorewall/interfaces:

        vpn        tun+        

    /etc/shorewall/masq:

        tun1        192.168.4.0/24

19) Previously, Shorewall classified non-firewall zones as either
    'simple' or 'complex'. Attributes of a zone which made it 'complex'
    included:

    - The zone was of type 'ipsec' or 'ipsec4' or it had a hosts
      entry with the 'ipsec' options.
    - The zone had OPTIONS, IN OPTIONS or OUT OPTIONS
    - The zone had more than one network on a given interface
    - The zone had a hosts file entry with an exclusion.
    - The zone had a hosts file entry specifying an ipset.

    The handling of 'simple' and 'complex' zones was different.

    -  complex zones had their own 'forward' chain (named
       '<zone>_frwd').
    -  complex zones with exclusions had their own 'input' and
       'output' chains.

    Beginning with Shorewall-perl 4.2, all non-firewall zones will be
    treated as 'complex'. This will have the effect of one additional
    filter chain per zone but in most cases, the average number of
    filter rules traversed by a connection request will be reduced.

20) The need for interface-specific chains (such as eth0_in, eth4_fwd,
    etc.) in the filter table has been drastically reduced. This has
    the effect of reducing the average number of rules that each packet
    must traverse.

21) The default value for LOG_MARTIANS is now 'Yes' ('On' in
    Shorewall-perl). Previously, the default value was 'No' ('Off' in
    Shorewall-perl). The shorewall.conf file has also been 
    updated to specify a value of 'Yes' (which is interpreted as 'On'
    by Shorewall-perl).

22) Shorewall-perl now generates an error when a MAC address appears in
    a traffic shaping rule in the OUTPUT or POSTROUTING chains.

23) Macros are now self-commenting under control of a new AUTO_COMMENT
    option in shorewall.conf. When this option is set, if there is not
    a current comment when a macro is invoked, the behavior under
    Shorewall-perl is as if the first line of the macro file was
    "COMMENT <macro name>".

    So, if you have this rule:

            SSH/ACCEPT  loc         fw

    then the generated netfilter rule will include "/* SSH */" when
    viewed with 'iptables -L' or 'shorewall show loc2fw' or 'shorewall
    dump'.

    The AUTO_COMMENT option has a default value of 'Yes' and is only
    available under Shorewall-perl. The option is ignored by
    Shorewall-shell.

24) The default value for the IMPLICIT_CONTINUE option has been changed
    to 'No'.

25) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP
    port 1701 in both directions and assumes that the source port will
    also be 1701. Some implementations (particularly OS X) use a
    different source port. In that case, you should use
    'generic:udp:1701' rather than 'l2tp'.

26) The /etc/shorewall/tcdevices and /etc/shorewall/tcclasses files
    have undergone some changes, especially when the 'classify' option
    has been specified.

    Normally Shorewall assigns interface numbers sequentially to
    devices listed in /etc/shorewall/tcdevices. Beginning with
    Shorewall 4.1.6, you can explicitly specify inteface numbers by
    prefixing the interface name with the interface number and a colon:

    Example:

     #INTERFACE    IN-BANDWITH     OUT-BANDWIDTH        OPTIONS
     1:eth0        1300kbit        384kbit              classify
     2:eth1        5600kbit        1000kbit        

     In /etc/shorewall/tcclasses:

     a) You can specify the INTERFACE using either the interface name
        or interface number.

     b) classes associated with devices which have the 'classify'
        option _must_ specify a class number by following the interface
        name/number with a colon (":") and the class number. The same
        class number may be used for classes defined on different
        interfaces but a class number may not be the same as any
        interface number.

    A class number may be specified when 'classify' has not been
    specified for the associated device. When a class number has not
    been given, the default class number remains the mark value
    prefixed by "1".

27) Shorewall now supports Intermediate Functional Block (IFB) devices.
    These devices allow shaping of incoming traffic.

    The 'ifb' module is available in the kernels included with today's
    distributions. You must load the module manually:

    If your distribution has modprobe:

       modprobe ifb [ numifbs=<number> ]

    Otherwise:

       insmod <path to net driver modules>/ifb.ko [ numifbs=<number> ]

    By default, the module automatically creates two IFB devices (ifb0
    and ifb1). To create only one, specify 'numifbs=1'.

    Example:

        ursa:~ # modprobe ifb numifbs=1
        ursa:~ # ip link ls
        1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
                link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
                link/ether cc:2b:cb:24:1b:00 brd ff:ff:ff:ff:ff:ff
        3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
                link/ether 00:1a:73:db:8c:35 brd ff:ff:ff:ff:ff:ff
        4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop qlen 32
               link/ether 26:99:d8:7d:32:26 brd ff:ff:ff:ff:ff:ff
        ursa:~ # 

    After you have created the IFB(s), you must bring it(them) up:

            ip link set dev ifb0 up

    You can place all of this in /etc/shorewall/init as follows:

            modprobe ifb numifbs=1
        ip link set dev ifb0 up

    The /etc/shorewall/tcdevices file has been extended to include an
    additional REDIRECTED DEVICES column. To convert your configuration
    to use an IFB:

    a) Look at your current /etc/shorewall/tcdevices file. Suppose you
       have:

        #INTERFACE  IN-BANDWIDTH  OUT-BANDWIDTH  OPTIONS
        eth0        1300kbit      384kbit        -

        Change it as follows:

        #INTERFACE  IN-BANDWIDTH  OUT-BANDWIDTH  OPTIONS  REDIRECTED
        #                                                 DEVICES
        eth0        -             384kkbit       -
        ifb0        -             1300kbit       -        eth0

       Note that the old IN-BANDWIDTH for eth0 has become the
       OUT-BANDWIDTH for ifb0 and that neither device has an
       IN-BANDWIDTH in the new configuration.

       Finally note that eth0 has been specified as a REDIRECTED device
       for the IFB.

    b) There are no Netfilter hooks between the real device (eth0) and
       the IFB (ifb0). So tcrules cannot be used to specify shaping of
       traffic leaving the IFB. To allow that traffic to be classified,
       a new /etc/shorewall/tcfilters file has been added.

       /etc/shorewall/tcfilters can be used for classifying traffic on
       any interface. When using entries in that file, it is important
       to realize that those entries act on packets as they appear 'on
       the wire'. That means that on output, SNAT/MASQUERADE has been
       applied and on input (output to an IFB), DNAT has not yet been
       applied.

       Columns in the file are:

       INTERFACE:CLASS

                The interface name or number followed by a colon (":")
                and the class number.

       SOURCE
                Source IP address. May be a host or network address.
                Specify "-" if any SOURCE address should match.

       DEST
                Destination IP address. May be a host or network
                address. Specify "-" if any DEST address should match.

       PROTO
                Protocol Name/Number. Specify "-" if any PROTO should
                match.

       DEST PORT(S)
                A comma-separated list of destination ports. May only
                be given if the PROTO is tcp, udp, icmp or
                sctp. Port ranges may be used, except when the PROTO is
                icmp. Specify "-" if any PORT should match.

       SOURCE PORT(S)
                A comma-separated list of source port. May only be
                given if the PROTO is tcp, udp or sctp. Port ranges
                may be used unless the protocol is icmp. Specify "-" if
                any PORT should match.

    Entries in /etc/shorewall/tcfilters generate U32 tc filters which
    may be displayed using the "shorewall show filters" ("shorewall-lite
    show filters") command. Note: The 'show filters' command is an
    alias for the existing 'show classifiers' command.

    Note that /etc/shorewall/tcfilters provides a usable alternative to
    HIGH_ROUTE_MARKS=Yes. You can use marks to select between providers
    and use entries in /etc/shorewall/tcfilters (or CLASSIFY tcrules)
    for traffic shaping.

28) If an interface fails when using balanced multi-ISP routing, the
    default route is lost. If there are remaining working interfaces
    with dynamic gateway addresses, Shorewall will be unable to
    determine those gateways.

    Beginning with Shorewall (Shorewall-lite) 4.1.7, the 'init' script
    may participate in gateway detection by setting variables with
    pre-determined names as follows:

         <gw>_GATEWAY

    where <gw> is the interface name:

          - in upper case
          - with any characters not allowed in shell variable names
            replaced by '_'.

    Example (from OpenWRT): 

          Interface:           eth0.1
          Variable:            ETH0_1_GATEWAY
          /etc/shorewall/init: 

              ETH0_1_GATEWAY=$(uci get /var/state/network.wan0.gateway)

29) A new CONNBYTES column has been added to the tcrules file. The
    column defines a byte or packet range that the connection must fall
    within in order for the rule to match. The contents are:

             [!]<min>:[<max>[:{O|R|B}[:{B|P|A}]]]

    !     matches if the the packet/byte count is not within the range 
          defined by <min> and <max>.

    <min> is an integer which defines the beginning of the byte/packet
          range.

    <max> is an integer which defines the end of the byte/packet range. 
          If omitted, only the beginning of the range is checked.

    The first letter gives the direction which the range refers to:

    O    - The original direction of the connection.
    R    - The opposite direction from the original connection.
    B    - The total of both directions.

    If omitted, 'B' is assumed.

    The second letter determins what the range refers to.

    B    - Bytes
    P    - Packets
    A    - Average packet size.

    If omitted, 'B' is assumed.

    Examples:

        1000000:          - Connection has transferred a total of
                            at least 1,000,000 bytes.

        1000000::R        - Connection has transferred at least
                            1,000,000 bytes in the direction opposite
                            of the original direction (typical of a
                            large download).

        1000000::O:P      - Connection has sent at least 1,000,000
                            packets in the direction of the original
                            connection.

30) A new MANGLE_ENABLED option is added to shorewall.conf. The default
    setting is 'Yes' which causes Shorewall to assume responsibility for
    the Netfilter mangle table.

    When MANGLE_ENABLED is set to 'No', Shorewall assumes no
    responsibility for that table. In this setting:

    a) Shorewall doesn't alter the mangle table.
    b) You may not use Shorewall Traffic Shaping (TC_ENABLED must be
       set to 'No'.
    c) The tcrules file is ignored.
    d) The providers file must be empty.
    e) All entries in tcdevices must specify the 'classify' option and
       traffic classification may only occur using the tcfilters file.

    This allows for another application running on your firewall to
    take over the mangle table and use it for it's own purposes.

31) Shorewall-perl now supports an ORIGINAL DEST column in macro files.
    The column must be left empty if the macro is to be used in the
    body of an action.

    The new column is placed between the SOURCE PORT(S) and RATE LIMIT
    columns. So that Shorewall-perl can determine which column layout
    each macro has, a new FORMAT directive is added:

             FORMAT {1|2}

    The default is FORMAT 1 which is the old format. FORMAT 2 specifies
    that the macro is in the new format.

32) Shorewall-perl implements a new Rfc1918 macro that deals with
    RFC 1918 addresses. This macro should be used in place of 
    the 'norfc1918' interface option which is deprecated.

    The macro body is:

    #ACTION             SOURCE          DEST    PROTO   DEST    SOURCE  ORIGINAL        RATE    USER/
    #                                                   PORT(S) PORT(S) DEST            LIMIT   GROUP
    FORMAT 2
    PARAM               SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \
                                        DEST    -       -       -       -               -       -
    PARAM               SOURCE          DEST    -       -       -       10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

    The 'norfc1918' option on the interface associated with zone 'z'
    and with RFC1018_STRICT=Yes is equivalent to:

        Rfc1918(DROP)      z    all

33) A better way to perform RFC 1918 filtration is to null-route the
    address ranges reserved by RFC 1918. You can do that by setting the
    new NULL_ROUTE_RFC1918 option to 'Yes' in shorewall.conf.

    It is highly recommended that you also set ROUTE_FILTER=Yes to get
    Martian messages. These will help diagnose problems where you need
    to be able to access hosts with RFC 1918 addresses that are outside
    of your local networks. Sometimes, these can be subtle such as the
    case where your ISP is using RFC 1918 addresses on their DHCP
    servers.

    NULL_ROUTE_RFC1918 defaults to 'No' and is only supported by
    Shorewall-perl; Shorewall-shell ignores the option.

34) There is now a macro.SANE which supports network-attached
    scanners. Shorewall now automatically loads the sane connection
    tracking helper module.

    Thanks for this feature go to Tuomo Soini.

35) Previously, when IP_FORWARDING=Yes in shorewall.conf, Shorewall
    would enable ip forwarding before instantiating the rules. This
    could lead to incorrect connection tracking entries being created
    between the time that forwarding was enabled and when the nat table
    rules were instantiated.

    Beginning with Shorewall 4.0.11 and 4.1.7, enabling of forwarding
    is deferred until after the rules are in place.

36) When using Shorewall-perl, the CEIL and RATE columns must now
    contain arithmetic expressions consisting of:
    
    a) Numeric digits (Hex numbers not allowed).
    b) Parentheses.
    c) The arithmetic operators +-* and /.
    d) The word 'full'.

37) The installers (install.sh) now auto-detect a Cygwin environment
    and install under the current user's ID if OWNER and GROUP are not
    given.

38) The 'start' and 'restart' commands now support a '-p' (purge)
    option which cause all entries to be removed from the Netfilter
    conntrack table. In order to use this option, the 'conntrack'
    utility must be installed on your system. Although it is generally
    not installed by default, Most distributions have this utility in
    their repositories. 

39) A 'save' extension script is added. The script is run after
    iptables-save has completed successfully.

    The 'load' and 'reload' commands copy the save script (if any) to
    /etc/shorewall-lite/ on the remove firewall system. The 'export'
    command copies the file to the same directory as the 'firewall' and
    'firewall.conf' scripts.

    I have the following commands in my 'save' script:

     [ -s /root/ipsets.save ] && cp -a /root/ipsets.save /root/ipsets.save.backup
     ipset -S > /root/ipsets.save

    These commands complement my 'init' script:

     qt modprobe ifb numifbs=1
     qt ip link set dev ifb0 up

     if [ "$COMMAND" = start ]; then
         ipset -U :all: :all:
            ipset -U :all: :default:
            ipset -F
            ipset -X
            ipset -R < /root/ipsets.save
     fi

    Those two scripts allow me to save and restore the contents of my
    ipsets automatically under Shorewall-perl/Shorewall-lite (my
    routestopped file does not use ipsets).

40) A HELPER column is included in the tcrules file. The value in this
    column names one of the Netfilter protocol 'helper' module sets
    (ftp, sip, amanda, etc).

    See http://www.shorewall.net/traffic_shaping.htm for an example.

41) DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl.

42) Farkas Levante has contributed a macro.Mail macro that covers SMTP,
    SMTPS and submission.

43) Beginning with Shorewall 4.0.0, the -f option was no longer the
    default for '/etc/init.d/shorewall start'. Beginning with 4.0.13
    and 4.2.0-Beta3, this is also true for Shoreawall-lite.

44) A new USE_DEFAULT_RT option has been added to shorewall.conf. When
    set to 'Yes', it causes the Shorewall multi-ISP feature to create
    a different set of routing rules which are resilient to changes in
    the main routing table. Such changes can occur for a number of
    reasons,  VPNs going up and down being an example.

    The idea is to send packets through the main table prior to
    applying any of the Shorewall-generated routing rules. So changes
    to the main table will affect the routing of packets by default. 

    When USE_DEFAULT_RT=Yes:

    a) Both the DUPLICATE and the COPY columns in the providers file
       must remain empty (or contain "-").

    b) The default route is added to the the 'default' table rather
       than to the main table.

    c) 'balance' is assumed unless 'loose' is specified.

    d) Packets are sent through the main routing table by a rule with
       priority 999. In /etc/shorewall/routing_rules, the range 1-998
       may be used for inserting rules that bypass the main table.

    e) All provider gateways must be specified explicitly in the
       GATEWAY column. 'detect' may not be specified.

    f) You should disable all default route management outside of 
       Shorewall. If a default route is added to the main table while
       Shorewall is started, then all policy routing will stop working
       (except for those routing rules in the priority range 1-998).

45) The 'shorewall restart' command now supports an -f option. When
    this option is specified, no compilation occurs; rather, the script
    which last started or restarted Shorewall is used. 

46) A macro supporting RNDC (BIND remote management protocol) traffic
    has been added.  It can be used as any other macro (e.g., RNDC/ACCEPT)
    in the rules file.

47) If 'NONAT' is specified in the ADDRESS column of an entry in 
    /etc/shorewall/masq, then traffic matching that entry is not
    passed to the entries that follow.

New Features added in Shorewall 4.2.1

1)  With the recent renewed interest in DOS attacks, it seems
    appropriate to have connection limiting support in Shorewall. To
    that end, a CONNLIMIT column has been added to both the policy and
    rules files.

    The content of these columns is of the format

    	[!] <limit>[:<mask>]

    where

	<limit> is the limit on simultaneous TCP connections.

	<mask>  specifies the size of the network to which
		the limit applies and is specified as a
		CIDR mask length. The default value for
		<mask> is 32 which means that each remote
		IP address can have <limit> TCP connections
		active at once.

 	!	Not allowed in the policy file. In the rules file, it
		causes connections to match when the number of
		current connections exceeds <limit>.

    When specified in the policy file, the limit is enforced on all
    connections that are subject to the given policy (just like
    LIMIT:BURST). The limit is checked on new connections before the
    connection is passed through the rules in the NEW section of the
    rules file.

    It is important to note that while the limit is only checked for
    those destinations specified in the DEST column, the number of
    current connections is calculated over all destinations and not
    just the destination specified in the DEST column.

    Use of this feature requires the connlimit match capability in your
    kernel and iptables. If you use a capabilities file when compiling
    your Shorewall configuration(s), then you need to regenerate the
    file using Shorewall or Shorewall-lite 4.2.1.

2)  Shorewall now supports time/date restrictions on entries in the 
    rules file via a new TIME column.

    The contents of this column is a series of one or more "time
    elements" separated by apersands ("&"). Possible time elements are:

    utc       	Times are expressed in Greenwich Mean Time.
    localtz 	Times are expressed in local civil time (default)
    timestart=hh:mm[:ss]
    timestop=hh:mm[:ss]   Start and stop time of day for rule
    weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or
    			  Sun
    monthdays=dd[,dd]...  where dd is an ordinal day of the month.
    datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
    datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
			  where	      yyyy = Year
                               	first mm   = Month
                                      dd   = Day
                                      hh   = Hour
                                  2nd mm   = Minute
                                      ss   = Second

    Examples:

    1)	utc&timestart=10:00&timestop=12:00

	Between 10am and 12 noon each day, GMT

    2)  datestart=2008-11-01T12:00

        Beginning November 1, 2008 at noon LCT.

    Use of this feature requires the time match capability in your
    kernel and iptables. If you use a capabilities file when compiling
    your Shorewall configuration(s), then you need to regenerate the
    file using Shorewall or Shorewall-lite 4.2.1.

3)  If your kernel and iptables support "-m conntrack --ctorigdstport"
    then Shorewall will utilize that capability to ensure that when you
    do port mapping (change the destination port but not the
    destination IP address), the final destination port is not opened
    as a side effect.

    Example:

    DNAT net loc:206.124.146.177:22 tcp 2222 - 206.124.146.177

    That rule maps port 2222 -> 22 but without this new feature, it
    also opens port 22 directly.

    To use this feature, you must be running Shorewall-perl and the
    output of 'shorewall show capabilities' must show:

       Extended Connection Tracking Match Support: Available

New Featurs in Shorewall 4.2.2

1)  A macro supporting JAP (anonymization protocol) has been added.
    It can be used as any other macro (e.g., JAP/ACCEPT) in the rules
    file.

2)  A macro supporting DAAP (Digital Audio Access Protocol) has been added.
    It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules
    file.

3)  A macro supporting DCC (Distributed Checksum Clearinghouse) has been
    added.  It can be used as any other macro (e.g., DCCP/ACCEPT) in the
    rules file.

4)  A macro supporting GNUnet (secure peer-to-peer networking) has been
    added.  It can be used as any other macro (e.g., GNUnet/ACCEPT) in the
    rules file.

5)  In 4.2.1, a single capability ("Extended conntrack match support")
    was used both to control the use of --ctorigport and to trigger use
    of the new syntax for inversion of --ctorigdst (e.g., "!
    --ctorigdst ..."). In 4.2.2, these are controlled by two separate
    capabilities. If you use a capabilities file when compiling your
    configuration, be sure to generate a new one after installing
    4.2.2.

Problems corrected in Shorewall 4.2.1

1)  A description of the CONNBYTES column has been added to
    shorewall-tcrules(5).

2)  Previously, Shorewall-perl would accept zero as the <max> value in
    the CONNBYTES column of tcrules even when the <min> field was
    non-zero. A value of zero for <max> was equivalent to omitting
    <max>.

3)  iptables 1.4.1 discontinued support of syntax generated by
    shorewall in some cases. Shorewall now detects when the new syntax
    is required and uses it instead.

4)  The Shorewall-perl implementation of the LENGTH column in
    /etc/shorewall/tcrules was incomplete with the result that 
    all LENGTH rules matched. Thanks to Lennart Sorensen for the patch.

5)  The 'export' command no longer fails with the error:

    /sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi")

Problems corrected in Shorewall 4.2.2

1)  Shorewall-perl now insures that each line copied from a
    configuration file or user exit is terminated with a newline
    character.

2) When ipranges were used to define zones, Shorewall-perl could
   generate invalid iptables-restore input if 'Repeat Match' was not
   available. Repeat Match is not a true match -- it rather is a
   feature of recent iptables releases that allows a match to be
   repeated within a rule.

3)  With Shorewall-perl, if a destination port list had exactly 16
    ports, where a port-range counts as two ports, then Shorewall-perl
    would fail to split the rule into multiple rules and an
    iptables-restore error would result.

4)  The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1
    compatibility contained a typo that prevented it from working
    correctly.

5)  If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP
    address and no zone name in the DEST column, Shorewall-perl would
    reject the rule. If a zone name was specified, Shorewall-perl 
    would issue a Warning message.     

Problems corrected in Shorewall 4.2.3

1)  Previously, Shorewall would allow compilation for export of a
    script named 'shorewall' with the unfortunate side effect that
    the 'shorewall.conf' file was overwritten. Scripts named
    'shorewall' now cause a fatal error to be raised.

2)  Previously, Shorewall-perl attempted to do Shell variable
    substitution on the first line in /etc/shorewall/compile.

3)  Following the Netfilter tradition, the IPP2P maintainer has made an
    incompatible syntax change (the --ipp2p option has been
    removed). Shorewall has always used "-m ipp2p --ipp2p" when
    detecting the presence of IPP2P support.

    Shorewall-common and Shorewall-perl have been modified to use 
    "-m ipp2p --edk" instead.

4)  When Extended Conntrack Match support was available, Shorewall-perl
    would create invalid iptables-restore input for certain DNAT rules.

5)  An optimization in all Shorewall-perl 4.2 versions could  cause
    undesirable side effects. The optimization deleted the
    <interface>_in and <interface>_fwd chains and moved their rules
    to the appropriate rules chain (a <zone>2<xxx> chain).

    This worked badly in cases where a zone was associated with more
    than one interface. Rules could be duplicated or, worse, a rule
    that was intended for only input from one of the interfaces would
    be applied to input from all of the zone's interfaces.
    
    This problem has been corrected so that an interface-related
    chains is only deleted if:

    a) the chain has no rules in it; or
    b) the interface is associated with only one zone and that zone is
       associated with only that interface in which case it is safe to
       move the rules.

Other changes in Shorewall 4.2.3

1)  Except with the -e option is specified, the Shorewall-perl compiler
    now verifies user/group names appearing in the USER/GROUP column of
    the rules file.

2)  The output of 'shorewall dump' now includes the output from
    'netstat -tunap'.

3)  Shorewall-perl now accepts '+' as an interface name in
    /etc/shorewall/interfaces. That name matches any interface and is
    useful for defining a zone that will match any interface that might
    be added after Shorewall is started.

    A couple of words of caution are in order. 

    a) Because '+' matches any interface name, Shorewall cannot
       verify interface names appearing in other files when '+' is
       defined in /etc/shorewall/interfaces.

    b) The zone assigned to '+' must be the last one defined in
       /etc/shorewall/zones.

4)  Shorewall-perl now uses the iptables --goto parameter in obvious
    cases.

5)  The 'reset' command now allows you to reset the packet and byte
    counter on individual chains:

    	    shorewall reset chain1 chain2 ...
	    shorewall-lite reset chain1 chain2 ...

Problems Corrected in 4.2.4

1)  Previously, when exclusion was used in an entry in
    /etc/shorewall/hosts, Shorewall-perl ignored the exclusion when
    generating rules for the following OPTIONS in that entry:
 
        blacklist
	maclist
	norfc1918
	tcpflags

2)  Shorewall-perl previously promoted all exclusion in the
    /etc/shorewall/hosts file to the zone level. That meant that
    all traffic to/from the zone passed through exclusion rules 
    rather than only the traffic matching a hosts records that
    specified exclusion.

    Example /etc/shorewall/hosts:

    	    z	eth0:192.168.4.0/24
	    z	eth1:10.0.0.0/24!10.0.0.99

        Traffic entering eth0 from network 192.168.4.0/24 would still
        be checked for '!10.0.0.99'.

    This has been corrected.

Other changes in 4.2.4

1)  Support for IPv6 was added -- see above.