# Shorewall News and Announcements

Tom Eastep
Copyright © 2001-2007 Thomas M. Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

January 16, 2007

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. An unprintable character in a comment caused /sbin/shorewall to fail when used with a light-weight shell like 'dash'.
3. When using some flavors of 'ash', certain /sbin/shorewall commands produced 'ipset: not found' messages.
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. 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.

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. 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".

Old News here