Shorewall News and Announcements


2015-09-09 Shorewall 4.6.13
                      N O T I C E

Shorewall 4.6.13 is scheduled to be the last 4.6 release. In
the fall of 2015, Shorewall 5.0.0 will be available. Please see for information about
preparing to migrate to Shorewall 5.

  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  The 'rules' file manpages have been corrected regarding the packets
    that are processed by rules in the NEW section.

2)  Parsing of IPv6 address ranges has been corrected. Previously, use
    of ranges resulted in 'Invalid IPv6 Address' errors.

3)  The shorewall6-hosts man page has been corrected to show the
    proper contents of the HOST(S) column.

4)  Previously, INLINE statements in the mangle file were not 	
    recognized if a chain designator (:F, :P, etc.) followed 	
    INLINE(...). As a consequence, additional matches following a
    semicolon were interpreted as column/value pairs unless
    INLINE_MATCHES=Yes, resulting in compilation failure.

5)  Inline matches on IP[6]TABLE rules could be ignored if
    INLINE_MATCHES=No. They are now recognized.

6)  Specifying an action with a logging level in one of the _DEFAULT
    options in shorewall[6].conf (e.g., REJECT_DEFAULT=Reject:info)
    produced a compilation error:

      ERROR: Invalid value (:info) for first Reject parameter
      	     /usr/share/shorewall/action.Reject (line 52)

    That has been corrected. Note, however, that specifying logging
    with a default action tends to defeat one of the main purposes of
    default actions which is to suppress logging.

7)  Previously, it was necessary to set TC_EXPERT=Yes to have full
    access to the user mark in fw marks. That has been corrected so
    that any place that a mark or mask can be specified, both the TC
    mark and the User mark are accessible.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  'update -t' now converts both the tcrules and tos files.

2)  'second' and 'minute' are now allowed in the LOGLIMIT
    specification in place of 'sec' and 'min' respectively.

3)  The 'update' command now converts additional deprecated option

    - LOGRATE/LOGBURST are converted to the equivalent LOGLIMIT

    - BLACKLISTNEWONLY is now converted to the equivalent BLACKLIST

4)  Two settings now have more reasonable defaults if they don't appear
    in the .conf file being updated:

    - USE_DEFAULT_RT now defaults to No
    - EXPORTMODULES now defaults to No.

5)  When the 'update' command is converting a deprecated file, it now
    makes additional checks when it finds a target file (mangle,
    stoppedrules or blrules) to append the converted rules to:

    - If the file is in the directory $SHAREDIR/$product/configfiles/,
      the file is not opened.
    - If the file is in the directory
      $SHAREDIR/doc/$product/default-config/, the file is not opened.
    - If the file is not writable, the file is not opened.

    When the file isn't opened because of one of these checks, an
    attempt is made to create a new file in either the directory
    specified on the command line (if any) or in the first directory
    listed in the CONFIG_PATH setting.
2014-05-15 Shorewall 4.6.0
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

This release includes all defect repair from releases up through

1)  The tarball installers, now install .service files with mode 644
    rather than mode 600.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  SECTION entries in the accounting and rules files now allow
    "SECTION" to be immediately preceded by "?" (e.g., ?SECTION). The
    new form is preferred and if any SECTION entries do not have the
    question mark, a warning is issued (see Migration Issues below).

2)  The default setting for ZONE2ZONE has been changed from '2' to '-'
    for increased readability when zone names contain '2'.

3)  The 'tcrules' file has been superseded by the 'mangle'
    file. Existing 'tcrules' files will still be processed, with the
    restriction that TPROXY is no longer supported in FORMAT 1.

    You can convert your tcrules file into the equivalent mangle file
    using the command:

       shorewall update -t

    See shorewall(8) and shorewall6(8) for important restrictions of
    the -t option.

4)  Prior to now, the ability to specify raw iptables matches has been
    tied to the INLINE action. Beginning with this release, the two can
    be separated by specifying INLINE_MATCHES=Yes.

    When INLINE_MATCHES=Yes, then inline matches may be specified after
    a semicolon in the following files:

      action files

    Note that semicolons are not allowed in any other files. If you
    want to use the alternative input format in those files, then you
    must inclosed the specifications in curly brackets ({...}). The -i
    option of the 'check' command will warn you of lines that need to
    be changed from using ";" to using "{...}".

5)  The 'conntrack', 'raw', 'mangle' and 'rules' files now support an IPTABLES
    (IP6TABLES) action. This action is similar to INLINE in that it
    allows arbitrary ip[6]tables matches to be specified after a
    semicolon (even when INLINE_MATCHES=No). It differs in that the
    parameter passed is an iptables target with target options.

    Example (rules file):

       IPTABLES(TARPIT --honeypot)	net	pot

    If the particular target that you wish to use is unknown to
    Shorewall, you will get this error message:

       ERROR: Unknown TARGET ()

    You can eliminate that error by adding your target as a builtin
    action in /etc/shorewall[6]/actions.

    As part if this change, the /etc/shorewall[6]/actions file options
    have been extended to allow you to specify the Netfilter table(s)
    where the target is accepted. When 'builtin' is specified, you can
    also include the following options:


    If no table is given, 'filter' is assumed for backward

6)  The 'tcpflags' option is now set by default. To disable the option,
    specify 'tcpflags=0' in the OPTIONS column of the interface file.

7)  You may now use ipset names (preceded by '+') in PORT columns,
    allowing you to take advantage of bitmap:port ipsets.

8)  The counter extensions to ipset matches have been
    implemented. See shorewall[6]-ipsets for details.

9)  DROP is now a valid action in the stoppedrules files. DROP occurs
    in the raw table PREROUTING chain which avoids conntrack entry

10) A new BASIC_FILTERS option is now supported. When set to 'Yes',
    this option causes the compiler to generate basic TC filters from
    tcfilters entries rather than u32 filters.

    Basic filters are more straight-forward than u32 filters and, in
    later iptables/kernel versions, basic filters support ipset
    matches.  Please note that Shorewall cannot reliably detect whether
    your iptables/kernel support ipset matches, so an error-free
    compilation does not guarantee that the firewall will start
    successfully when ipset names are specified in tcfilters entries.

11) The update command now supports an -A option. This is intended to
    perform all available updates to the configuration and is currently
    equivalent to '-b -D -t'.

12) Beginning with this release, FORMAT-1 actions and macros are 
    deprecated and a warning will be issued for each FORMAT-1 action
    or macro found. See the Migration Issues for further information.

13) To facilitate creation of ipsets with characteristics different
    from what Shorewall generates, the 'init' user exit is now executed
    before Shorewall creates ipsets that don't exist.
2013-08-26 Shorewall 4.5.21
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  ip[6]tables 1.4.20 introduced an incompatible change that causes
    the program to fail if there is another instance of either iptables
    or ip6tables already running. This behavior can be avoided if the
    new -w option is specified.

    To work around this problem, the compiler now uses the -w option
    (when available) during capabilities determination so that
    shorewall and shorewall6 compilations can proceed in parallel.

2)  Previously, the Shorewall-init installer unconditionally installed
    the sysconfig file even when a different SYSCONFFILE was specified.
    (Thomas D).

3)  /sbin/shorewall-init now includes the correct SYSCONFDIR name in
    its error message that reports the absense of
    ${SYSCONFDIR}/shorewall-init. (Thomas D).

4)  /sbin/shorewall-init and the Shorewall-init SysV init scripts now
    honor the setting of $OPTIONS.

5)  The -lite installers now look in ${SHAREDIR} for the coreversion
    file rather than in /usr/share/.

6)  If a Shorewall-lite installation used an /etc/shorewall-lite/vardir
    file to set a non-standard state directory, the administrative
    system would send the firewall and firewall.conf files to the wrong
    directory on the firewall system.

7)  Previously, the compiler verified 'monthdays' specifications in the
    rules TIME column, but failed to include --monthdays in the
    generated rule. That omission has been corrected.

8)  The installers now use 'insserv' on Debian systems to update the
    SysV init symlinks. Previously, update-rc.d was used but that
    approach fails on Debian 7.

9)  The Multicast DNS macros (mDNS and mDNSbi) now allow the entire
    non-priv port range (1024-65535) for the the dynamic unicast
    port. Previously, only the Linux 2.6+ dynamic port range
    (32768-65535) were allowed.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  When a REJECT target is specified, Shorewall normally handles the
    packet as follows:

    - If the destination address is a broadcast or multicast address,
      the packet is dropped.

    - If the protocol is IGMP (1), then the packet is dropped.

    - If the protocol is TCP (6) then the packet is rejected with an

    - If the protocol is UDP (17) then the packet is rejected with 
      a 'port-unreachable' ICMP (ICMP6).

    - If the protocol is ICMP (ICMP6), then the packet is rejected
      with a 'host-unreachable' ('addr-unreachable') ICMP (ICMP6).

    - Otherwise, the packet is rejected with a 'host-prohibited'
      (adm-prohibited) ICMP (ICMP6).

    Beginning with this release, this behavior may be modified using
    the new REJECT_ACTION option in shorewall.conf (shorewall6.conf).


    where <action> is the name of an action that implements your
    alternative handling. The 'nolog' and 'inline' options are
    automatically assumed for the named <action>.

    The following action implements the standard behavior described

    ?format 2
    Broadcast(DROP) 	-	-	-
    DROP		-	-	2
    INLINE		-	-	6	; -j REJECT --reject-with tcp-reset
    INLINE		-	-	17	; -j REJECT
    ?if __IPV4
    INLINE		-	-	1	; -j REJECT --reject-with icmp-host-unreachable
    INLINE		-	-	-	; -j REJECT --reject-with icmp-host-prohibited
    INLINE		-	-	58	; -j REJECT --reject-with icmp6-addr-unreachable
    INLINE		-	-	-	; -j REJECT --reject-with icmp6-adm-prohibited
    INLINE		-	-	-	; -j REJECT

2)  In earlier versions, default log levels in shorewall.conf
    (shorewall6.conf) were not validated, making it difficult to
    determine what setting was causing the following error message:

       ERROR: Log level INFO requires LOG Target support in your kernel
       	      and iptables

    This change will make log level errors from shorewall.conf and
    shorewall6.conf easier to isolate by including the option name.


       ERROR: Log level INFO for option SFILTER_LOG_LEVEL requires LOG
              Target support in your kernel and iptables

3)  The 'shorewall dump' command now uses 'ss' rather than 'netstat' to
    produce socket-related information. By Martin Gignac.

4)  Thomas D has provided installer support for Gentoo. Thank you

5)  The generated firewall script inserts a host route for each
    provider gateway into both the main routing table and into the
    provider's routing table. This is necessary on older kernels to
    avoid failure of default route insertion into the tables.

    It has been discovered, however, that these host routes prevent
    Zebra from being able to add routes on some distributions, most
    notably Debian 7.0. To work around this issue, two new provider
    options are now available:

        hostroute   This is the default and causes the host routes
        	    described above to be inserted.

        nohostroute Prevents the host routes from being inserted.

6)  It was previously not possible for Perl code in an action file to
    change the rule comment as is done using the ?COMMENT directive
    outside of Perl. 

    To allow actions to manipulate the current comment, two functions
    are made available:

    	push_comment() Clears the current rule comment and returns 
		       that comment to the caller. 

	set_comment($) Sets the current rule comment to the passed

    Typical usage would be:

        ?BEGIN PERL
	use Shorewall::Config;
	my $oldcomment = push_comment(); #Save and clear current 
	   	       	 		 #current rule comment
	set_comment('This is a comment');
	add_ijump(....);                 #This rule will have comment
	    				 # /* This is a comment */
        set_comment('');                 #Clear current rule comment
	add_ijump(....);		 #This rule has no comment
	set_comment($oldcomment)	 #Restore caller's comment
					 #if any.

7)  The compiler version used to create the current firewall script is
    now displayed in the output of the 'status' and 'version -a'
2013-08-26 Shorewall 4.5.20
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  On some distributions, the shorewall-lite and shorewall6-lite
    uninstallers could fail with a syntax error.

2)  A typographical error in the usage text produced by the -h command
    in the compiled firewall script has been corrected.

3)  The handling of INITSOURCE is now uniform between the standard and
    the -lite installers.

4)  Previously, when SYSCONFFILE was specified in shorewallrc, the
    installers would always install default.debian rather than the
    named file. That has been corrected.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  A new TRACK_RULES option has been added to shorewall[6].conf. When
    set to 'Yes', this option causes most rules to be tagged with a
    comment which gives the configuration file name and line number
    that caused the rule to be generated. These comments replace any
    comments added via AUTOCOMMENT=Yes and ?COMMENT entries.
    Setting this option to 'Yes' requires the 'Comments' capability in
    your kernel and ip[6]tables.

2)  You may now specify 'OPTIMIZE=All' in shorewall[6].conf to enable
    all optimizations. If new optimization levels are added in the 
    future, OPTIMIZE=All will automatically enable those optimizations.

    For completeness, 'OPTIMIZE=None' disables all optimizations.

3)  'list' and 'ls' are now documented alternatives for 'show' in the
    CLI programs. /sbin/shorewall and /sbin/shorewall6 now accept 'ck'
    as an abbreviation for 'check' and 'co' as an abbreviation for

4)  Beginning with this release, if /etc/os-release exists during
    installation, then the ID setting in that file will be used to
    determine which Linux distribution is running on the system.

5)  The 'status' command now obeys the effective VERBOSITY and will
    produce no output when the effective VERBOSITY is less than 1.

6)  The CLI exit status codes are now documented in the manpages
    (shorewall(8), shorewall6(8), etc.).

7)  Beginning with this release, the shorewallrc file supports a
    SERVICEFILE variable. SERVICEFILE is only relevant when SERVERD is
    non-empty, in which case it names the file to be installed as the
    product's .service file. If SERVERD is specified but SERVICEFILE is
    not, the assumed value of SERVERFILE is $PRODUCT.service.

8)  The ${SBINDIR}/shorewall-init utility will now compile
    configurations if needed
2013-07-24 Shorewall 4.5.19
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  The shorewall-init.service file previously specified an incorrect
    path name for the shorewall-init utility

2)  Previously, the '-q' option did not suppress all output from
    certain commands such as 'check'.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The 'Limit' action now produces a warning message stating that it
    is deprecated in favor of per-IP limiting using the RATE LIMIT

2)  Generation of logging rules has been largely re-written to directly
    create rules in the compiler's internal representation.
    Previously, such rules were created in iptables format then
    translated into the internal form.

3)  A form of 'events' or 'triggers' is now available. Events are
    implemented using the ip[6]tables 'recent' match so they are
    actually lists of IP addresses with associated timestamps and
    packet counts. They may be tested in a number of ways:

    - Any matching packets to/from an address ever?
    - Any matching packets to/from an address in the last N seconds?
    - M or more matching packets to/from an address?
    - M or more matching packets to/from an address in the last N

    See for details and usage

4)  As part of adding event support, the CLI programs now support
    two new variants of the 'show' command.

    show events

    	 Displays the contents of all events.

    show event <event> ...

         Displays the contents of the listed events.

    Note that a given event can be used for both IPv4 and IPv6. So
    /sbin/shorewall and /sbin/shorewall-lite will show entries that are
    different from /sbin/shorewall6 and /sbin/shorewall6-lite.

5)  Using the event mechanism described above, Shorewall now supports a
    form of automatic blacklisting when the number of connection
    attempts in a given period of time is exceeded.

    See for details.
2013-06-28 Shorewall 4.5.18
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes all defect repair from Shorewall

2)  The following warning message could be emitted inappropriately when
    running shorewall 4.5.17.
      The rule(s) generated by this entry are unreachable and have been

    These warnings, which were disabled in Shorewall, are now
    only emitted where appropriate. The message has also been reworded

      One or more unreachable rules in chain <name> have been discarded

    The message is issued a maximum of once per Netfilter chain.

3)  A problem that could cause the 'trace' compiler option to produce
    false error messages or to produce an altered generated firewall
    script has been corrected.

4)  If the 'Owner Name Match' capability was not available, the
    following error message would previously appear during compilation:

      iptables: No chain/target/match by that name.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  'NONE' policies are now instantiated between 'local' zone and zones
    other than the firewall.  Similarly, 'NONE' policies are
    instantiated between 'loopback' zones and zones other than $FW
    and other 'loopback' zones. 

    This provides a cleaner implementation than the one provided in
    Shorewall 4.5.17, and one that should be easier to maintain going

2)  James Shubin has contributed a Kerberos macro.

3)  A new 'unmanaged' interface option has been added. This option may
    be used to define interfaces that allow all traffic to/from the
    firewall but that's all. They are not accessible from hosts on
    other interfaces nor can traffic from an unmanaged interface be
    forwarded to hosts on other interfaces.

    The following interface options are mutually-exclusive with

    - blacklist
    - bridge
    - destonly
    - detectnets
    - dhcp
    - maclist
    - nets
    - norfc1918
    - nosmurfs
    - optional
    - routeback
    - rpfilter
    - sfilter
    - tcpflags
    - upnp
    - upnpclient

    Unmanaged interfaces may not be associated with a zone in either
    the interfaces or hosts files.

    The 'lo' interface may not be unmanaged when there are vserver
    zones defined.

4)  The value (0 or 1) for the 'routeback' interface option may now
    be specified (e.g., 'routeback=0'). This allows overriding the
    Shorewall default setting for bridge devices which is

    PERL directives are now case-insensitive.
2013-06-01 Shorewall 4.5.17
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  A number of issues have been corrected in the Debian and
    Redhat/Fedora Shorewall-init SysV init scripts:

    a) Settings in ${SHAREDIR}/vardir are now handled correctly.

    b) Exit status is now returned correctly.

    c) Stale lock files are avoided.

2)  When the compiled firewall script is run directly, it no longer 
    attempts to copy itself onto itself using the 'cp' utility.

3)  An optimizer defect that could leave unreferenced chains in the
    configuration has been corrected.

4)  Unreferenced chains in the IPV6 nat table are now omitted.

5)  Rules with trivial exclusion (a single net or ipset preceded by
    '!') now generate the iptables matches in the correct
    order. Previously, the exclusion match(es) was(were) placed at the
    end. This is important in rules that auto-increment nfacct objects.

6)  Previously, conntrack helpers were enabled by the 'stop'
    command. Now, these helpers are only enabled by the 'clear'

7)  Previously, an interface label (e.g., dev:N) could be specified
    as the 'physical' interface in /etc/shorewall/interfaces. This
    is now disallowed.

8)  The Perl function 'shorewall' was not previously exported by
    Shorewall::Config, with the result that the function had 
    to be called as Shorewall::Config::shorewall(...). the function is
    now exported and can be called from ?BEGIN PERL blocks as simply

9)  Previously, two ICMPv6 type names were mis-translated.

      address-unreachable was translated to 1/2; should be 1/3
      port-unreachable was translated to 1/3; should be 1/4

    These translations have been corrected.

10) If a TPROXY IPv6 address was specified in /etc/shorewall6/tcrules
    using the [<address>]/vlsm form (e.g.,
    'TPROXY(0x100,3129,[2001:470:b:227::44]/64)') then an 'Invalid Address'
    error was issued. This has been corrected.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Route types 'blackhole', 'unreachable' and 'prohibit' are no longer
    copied to provider routing tables by default when
    USE_DEFAULT_RT=No. You may cause them to be copied by including
    'blackhole', 'unreachable' and/or 'prohibit' in the COPY list along
    with interface names.

2)  Previously, the generated script always added a host route to a
    provider's gateway in the provider's routing table. Beginning with 
    this release, the 'noautosrc' provider option can be used to
    inhibit this behavior. 'noautosrc' must be used with care since the
    absense of such a route can cause start/restart runtime failures.

3)  A '-c' (conditional) option has been added to the 'compile' command.
    This option causes compilation to proceed if:

    a) The specified (or defaulted) firewall script does not exist; or
    b) A file on the CONFIG_PATH (including any directory specified in
       the command) is newer than the existing script.

4)  A new interface option has been added.


        Causes the compiler to omit rules to handle traffic arriving on
        the interface.

5)  It is now possible to use 'all+' in the SOURCE and DEST columns of
    /etc/shorewall[6]/policy file. It has the same meaning as in the
    rules file in that it can override default intra-zone ACCEPT

6)  Beginning with this release, most special handling of 'Auth' (TCP
    port 113) has been removed. In particular, the Drop default action
    will no longer default to silently REJECTing Auth requests but will 
    rather simply process them like other tcp packets.

7)  Traditionally, Shorewall has treated the loopback interface ('lo')
    as follows:

    - It deals with firewall-to-firewall, firewall-to-vserver,
      vserver-to-firewall, and vserver-to-vserver traffic.
    - All filtering is done in the OUTPUT flow; all traffic arriving on
      'lo' is silently accepted.
    - If no firewall-to-firewall policy or rules are defined, then
      a simple ACCEPT rule is also included in the OUTPUT chain for
      'lo' (after any vserver-oriented jumps).

    Beginning with this release, the handling of firewall-to-firewall
    traffic can be altered by adding a zone of type 'loopback'.

   - 'loopback' zones must be associated with the loopback device in
      the interfaces and/or hosts file.


      #ZONE     TYPE
      loop      loopback

      ?FORMAT 2
      loop    lo                ...

      When this is done, the ACCEPT jumps for 'lo' in the INPUT and
      OUTPUT chains are omitted and replaced with jumps to the loop2fw
      and fw2loop (loop-fw and fw-lop) chains respectively. This
      provides a model similar to other zones for fireall-to-firewall

8)  A new 'local' zone TYPE has been added to /etc/shorewall[6]/zones.
    A 'local' zone is similar to an 'ipv4' ('ipv6') zone, except that
    rules and policies to/from a 'local' zone may only be to/from the
    firewall zone and vserver zones.
2013-05-01 Shorewall 4.5.16
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, the TOS target and tos match did not work on older
    iptables versions such as 1.3.5 in RHEL5-based distributions. That
    has been corrected. To correct this problem, a new capability (New
    tos Match) was created, so users who utilize a capabilities file
    will need to regenerate the file. This applies to all distributions
    and not just the older ones.

2)  A_ACCEPT! is now recognized as a rules ACTION. Previously, it was
    documented in shorewall[6]-rules(5) but was not implemented.

3)  Previously, NFACCT accounting rules generated iptables rules with
    the matches in the incorrect order. That caused the counters to be
    incremented before all of the matches had been checked. Now, the
    counter in an NFACCT rule is incremented only if all of the other
    matches have been successful.

4)  A number of ipset-related modules were incorrectly included in
    /usr/share/shorewall/helpers. Those entries have now been removed.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  A new Shorewall6 interface option, 'accept_ra' has been added. The
    option value may be set as follows:


        Do not accept Router Advertisements.

	Accept Route Advertisements if forwarding is disabled.

	Overrule forwarding behavior. Accept Route Advertisements even
	if forwarding is enabled.

    If the option is specified without a value, then value 1 is

2)  Two new macros have been added:

      macro.Xymon contributed by T.J. Yang
      macro.VRRP contributed by James Shubin

3)  A new INLINE action has been added. This action allows defining
    arbitrary iptables rules in the blrules and rules files, as well as
    in action and macro bodies.

    The basic form of an INLINE rule is as follows:

    	INLINE	<src> <dst> <proto> ... ; <iptables matches and jump>

    The <iptables matches and jump> are added to the rule generated by
    the contents of the other supplied columns. Given the 'raw' nature
    of this action, you should examine the rule generated by the entry
    (e.g., 'shorewall check -r') prior to attempting a 'start' or
    'restart' operation.


        INLINE  $FW   net   tcp   1234  ; -j SECCTX --name foo

    This entry generates the following:

        -A fw2net -p 6 --dport 1234 -j SECCTX --name foo

    When multiple matches are specified, the compiler will keep them in
    the order in which they appear, but they will not necessarily be at
    the end of the generated rule. For example, if addresses are
    specified in the SOURCE and/or DEST columns, their generated matches
    will appear after those specified using ';'.

    Note: The following matches will always appear at the front of the
    rule in the order shown:

      state or conntrack --ctstate

    As part of this change, a new 'builtin' action type has been added.
    ip[6]tables targets not supported by Shorewall (such as 'SECCTX' in
    the example above), must be defined in your
    /etc/shorewall[6]/actions file:


       SECCTX	builtin

    Such builtin actions may only be used in INLINE action invocations;
    they may not appear in the ACTION column of a rule.

    If you want to use a standard Shorewall-supported action, you can
    pass it as a parameter to INLINE.


       INLINE(ACCEPT) $FW net ; -m foo --bar baz

    Note that if you include a log level with INLINE and do not pass a
    parameter, Shorewall will automatically assume that the parameter
    is LOG. That means that you must not specify a log level if you
    specify your own rule target with '-j'.

    The alternate input format may be used with INLINE, provided that
    the {....} form of alternate input is used.


       INLINE $FW net { owner=teastep } ; -j FOO --bar

4)  The INLINE action is also supported in the accounting and tcrules
    files. In the accounting file, INLINE is treated the same as COUNT
    in the with the exception that the freeform iptables input
    following the ';' is appended to any matches generated by the
    column contents. INLINE is treated similarly in the tcrules file;
    that is, the freeform input following ';' must specify the rule
    target, if any. In the accounting and tcrules files, INLINE does
    not accept a parameter.

5)  It is now possible to specify HELPERS=none in

    This setting has two consequences:

    a) All of the *_HELPER capabilities are set to off.
    b) No probing of helpers is performed, thus eliminating "xt_CT: No
       such helper XXX" warnings when the compiler is probing the
       system for capabilities.

6)  It is now possible to specify multiple nfacct objects in an NFACCT
    accounting rule. Where previously, the following rules were given:




    It is now possible to do the same thing as follows:




    To allow a nfobject to be incremented unconditionally, you may
    follow the object name with '!' (e.g., NFACCT(all!)). When
    '!' is omitted, the object is incremented only if all of the rule's
    matches succeed.

7)  It is now possible to increment an nfacct counter when a packet
    matches an ipset. To do that, simplly include the counter object's
    name in parentheses after the ipset specification.


    a)  Increment the mysetcounter nfacct object when a packet's source
	matches myset.


    b)  Increment the mysetcounter1 and mysetcounter2 nfacct objects
	when a packet's sourcematches myset.


    b)  In an accounting rule, increment the 'all' nfacct object
    	unconditionally and increment the 'mysetcounter' object only if
    	the packet source matches myset:

	NFACCT(all!)	  -	  +myset(mysetcounter)

8)  Prior to the availability of BEGIN PERL....END PERL in
    configuration files, the only way to execute a chain-specific
    script was to create a script file with the same name as the chain
    and place it in a directory on the CONFIG_PATH. That facility has
    the drawback that the compiler will attempt to run a non-script
    file just because it has the same name as a chain. To disable this
    facility, a new CHAIN_SCRIPTS option has been added to
    shorewall[6].conf. The facility is disabled by setting
    CHAIN_SCRIPTS=No. If not specified or specified as the empty value,
    CHAIN_SCRIPTS=Yes is assumed for backward compatibility.
2013-04-01 Shorewall 4.5.15
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, the Shorewall and Shorewall6 scripts did two
    things wrong with respect to the /etc/shorewall[6]/routes file:

    - The existing file was unconditionally removed.
    - A skeleton file was not installed when SPARSE was not set in
      the shorewallrc file.

    Additionally, the installer would remove /etc/shorewall[6]/tcstart.

2)  The Shorewall-init script previously refused to replace
    /sbin/ifup-local and /sbin/ifdown-local when those files has been
    installed by an earlier version of Shorewall-init.

3)  Previously, Shorewall-init's integration with NetworkManager was
    incomplete on SuSE with the result that NetworkManager interface
    change events were not processed. That has been corrected.

4)  Beginning with Shorewall 4.5.8, Shorewall6 has interpreted /32
    networks as hosts (/128). /32 IPv6 networks are once again handled

5)  Using service class names such as such as EF, BE, CS1, ... for DSCP
    didn't work previously. Thibaut Chèze has provided a fix.

6)  An incorrect range test prevented DSCP classes CS6 and CS7 from
    being accepted. The test has been corrected and those classes are
    now allowed.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Prior to this release, Shorewall has only supported blackhole null
    routing in the /etc/shorewall[6]/routes file and in the
    NULL_ROUTE_RFC1918 option.

    Beginning with this release, Shorewall also supports 'unreachable'
    and 'prohibit' routes.

    In /etc/shorewall/routes, the GATEWAY column may contain
    'blackhole', 'unreachable' or 'prohibit'.

    NULL_ROUTE_RFC1918 can also assume those values, in addition to
    'Yes' and 'No' (case-insensitive). 'Yes' is equivalent to
    'blackhole' for backward compatibility.

    Please see for
    details. That section was provided by Mr Dash Four.

2)  The 'ifupdown' script installed by Shorewall-init is now
    distribution-specific. Previously, the script determined the
    distribution at run-time.

3)  The ${VARDIR}/undo_<provider>_routing scripts no longer invoke
    a Shorewall internal function so that they may be processed
    directly by a shell.

4)  The compiler now detects multiple entries in
    /etc/shorewall[6]/routes with the same PROVIDER and DEST and raises
    an error. If an entry for the 'main' table in /etc/shorewall/routes
    has one of the RFC1918 networks as the DEST and if
    NULL_ROUTE_RFC1918=Yes, then a warning message is issued and the
    entry in /etc/shorewall/routes is used.

5)  Prior to now, the generated shell script has always used routing
    table (provider) numbers rather than names. To make the script more
    readable and to aid in debugging, a new USE_RT_NAMES option has
    been added to shorewall[6].conf.

    When set to 'Yes', Shorewall will use routing table (provider)
    names in the generated script rather than table numbers. When set
    to 'No' (the default), routing table numbers will be used.


    If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must
    insure that all of your providers have entries in
    /etc/iproute2/rt_tables as well as the following entries:

        255 local
	254 main
	253 default
	250 balance
	0 unspec

    Without these entries, the firewall will fail to start.
2013-03-11 Shorewall 4.5.14
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, a list of IPv6 host addresses where each address was
    enclosed in square brackets generated a fatal compile-time error.

    Such lists are now handled correctly.

2)  The Shorewall 'load', 'reload' and 'export' commands have now been
    modified to use a shorewallrc file in a remote system's export
    directory. If the directory layout of the remote system differs
    from that of the administrative system, then the remote system's
    export directory should contains a copy of that system's
    shorewallrc file.

3)  A syntax error in the Shorewall file has been

4)  The contents of the various configpath files have been corrected.

5)  The Shorewall script previously failed to remove the
    macro files from ${SHAREDIR}/shorewall. Those files are now

6)  The 'version -a' command now prints the correct shorewall-core
    version when it is run from shorewall6, shorewall-lite and

7)  It is now possible to specify a port or port range along with an
    address variable in the ADDRESSES column of /etc/shorewall/masq.


	#							PORT(S)
	eth0	&eth0:44	tcp	45

    Previously, this usage generated a fatal compilation error.

8)  Port numbers and service names may now be specified with the
    UDPLITE protocol. As part of this change, two new capabilities have
    been added.

    - Enhanced Multi-port Match
      Multi-port match ('-m multiport') can operate on SCTP and DCCP

    - UDPLITE Port Redirection
      Currently, neither DNAT nor REDIRECT support port redirection of
      UDPLITE. This capability is added to detect that support in the

9)  The SUBSYSLOCK setting in the default shorewall6.conf file has been
    changed from /var/lock/subsys/shorewall to

10) 'blackhole' routes are now copied to provider tables when
    USE_DEFAULT_RT=No. Previously, these routes were not copied with
    the result that packets could be routed to blackholed addresses.

11) Duplicate interface names could previously appear in a case
    statement in the generated script. These duplicates are now

12) Previously, a duplicate 'echo' command could appear in the
    generated script. Now only a single command appears.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Previously, when compiling for export to a Shorewall lite system,
    either /etc/shorewall/params was required to be readable by the
    user or the remote host's configuration directory was required to
    include a (possibly empty) params file.

    Beginning with this release, when a directory name is specified in
    a 'compile', 'check', 'load', 'reload' or 'export' command and the
    user is not root (euid is not zero), then /sbin/shorewall and
    /sbin/shorewall6 will only look in the specified directory for the
    params and shorewall[6].conf files.

2)  The BLACKLIST_LOGLEVEL option has been renamed BLACKLIST_LOG_LEVEL
    to be consistent with the other log-level option
    names. BLACKLIST_LOGLEVEL continues to be accepted as a synonym for
    BLACKLIST_LOG_LEVEL, but a 'shorewall update' or 'shorewall6
    update' command will replace BLACKLIST_LOGLEVEL with
    BLACKLIST_LOG_LEVEL in the new .conf file.

3)  Rules in the ESTABLISHED section are now placed in separate
    chains. Rules for traffic from zone Za to zone Zb and placed in
    ^Za2Zb or ^Za-Zb, depending on the setting of
    ZONE2ZONE. Previously, they were placed in Za2Zb (Za-Zb).

4)  When the effective VERBOSITY is 2, the compiler now produces a
    report as follows:

    Configuration uses these capabilities ('*' denotes required):
    Shorewall configuration verified

5)  While we understand the evils of NAT, it is required for proper
    failover handling in IPv6 multi-ISP configurations. To accommodate
    that limited use case, Shorewall6 now supports basic Masquerade,
    SNAT and DNAT.

    This feature requires a 3.7 or later kernel and iptables 1.4.17 or

    Note: The current Fedora 18 3.4.7 kernel does not support IPv6
    MASQUERADE, so you must specify one or more addresses in the
    ADDRESSES column. To approximate masquerade when running that
    kernel, use an address variable in the ADDRESS column.

    Example /etc/shorewall6/masq:

	p3p1		2001:470:b:227::0/24	&p3p1

    DNAT rules that specify a port number in the DEST column, must
    enclose the server address (if any) in square brackets.


	DNAT	net	fw:[2001:470:b:227::2]:22       tcp	1022

    As part of this change, a new 'MASQUERADE Target' capability as
    been added.

6)  'blackhole' routes may now be defined in /etc/shorewall[6]/routes.
    Simply place 'blackhole' in the GATEWAY column and leave the DEVICE
    column empty.

7)  The iptables/ip6tables 'multiport match' feature allows for
    matching either the source or the destination port against a list
    of port numbers. Up to this time, Shorewall did not allow users to
    take advantage of that capability.

    Beginning with this release, placing an equal sign in a SOURCE
    PORT(S) column is interpreted as 'match the list specified in the
    DEST PORT(S) column against both the packet source and destination
    port in the packet. If there is any match, then the packet matches
    the rule.

    Example from the accounting file:

      #	                                          PORT(S) PORT(S)
      COUNT	-	br0	  -	  tcp 	  80	  =

    This rule matches all TCP packets entering through br0 where either
    the source port or the destination port is 80.
2013-02-12 Shorewall 4.5.13
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  If a chain consisted of a single RETURN rule, optimize level 4
    would handle it incorrectly by moving the RETURN rule to the
    chain(s) that jumped to the single-rule chain. The optimizer now
    simply eliminates the chain and rule.

    As part of this change, the optimizer now deletes trailing RETURN
    rules from chains.

2)  If a default inline action was specified with parameters, the
    compiler would fail with an internal error.

3)  The compiler was mis-handling simple arithmetic expressions
    consisting of a single number, evaluating the number as '' rather
    than as its numberic value.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  A new DEFER_DNS_RESOLUTION option has been added to shorewall.conf.

    Up to this time, when a DNS name appears in the SOURCE, DEST or
    ORIGINAL DEST column of a configuration file, the compiler verifies
    that the name can be resolved and then passes the name on to the
    generated script. This means that ip[6]tables-restore must resolve
    the name when the script runs.

    When DEFER_DNS_RESOLUTION=Yes (the default) this old behavior is
    retained. When DEFER_DNS_RESOLUTION=No, the compiler resolves the
    name and uses the address(es) in the generated script.

2)  The '@' Shorewall variables are now writable using the ?SET directive.

    The variables are now also used when generating the contents of
    --log-prefix in logging rules. Within an action body, the two
    fields in the --log-prefix are:

        @chain       -- Existing variable.
	@disposition -- New variable.

    When either of these are undefined or empty, the compiler uses
    the same value as previously.

    When a non-inlined action is entered, @disposition is given the
    empty value. When an inline action is entered, @disposition is not

    Also added is a @caller variable which names the chain or action
    which invoked the action.

    When any action is exited, the variables revert to their values
    when the action was entered.

    When RESET, the named Shorewall variables are not removed from the
    variable table but are rather set to the empty value.

3)  Optimize level 8 now makes multiple passes of each table.

4)  There are now two new sections in the rules file:


	Allows definition of rules to be applied to packets in the
	INVALID connection state.


	Allows definition of rules to be applied to packets in the
	UNTRACKED connection state (due to entries in the conntrack

    The implementation of these sections is modeled after that of the
    RELATED section. There are options in shorewall.conf
    (shorewall6.conf) that control the disposition and logging of
    packets that fail to match any of the rules in the section.


	    Valid values are CONTINUE, DROP, REJECT, and A_DROP.

	    The default is CONTINUE, which provides compatibility with
	    earlier releases (the packets are subject to the rules in
	    the NEW section).


	    Determines logging of packets handled by
	    INVALID_DISPOSITION. Empty by default (no logginig).


	    and A_DROP.

	    The default is CONTINUE, which provides compatibility with
	    earlier releases (the packets are subject to the rules in
	    the NEW section).


	    Determines logging of packets handled by
	    NOTRACK_DISPOSITION. Empty by default (no logging).

    The new order of sections in the rules files is:


5)  There are now 'Related', 'Untracked', 'Established' and 'New'
    actions that match packets in the RELATED, UNTRACKED, ESTABLISHED
    and NEW states respectively.

    These actions are in-line and have a single parameter that
    specifies the action to be taken. The action may be anything that
    is valid in the ACTION column of the rules file.

    As part of this change, action.Invalid, action.NotSyn and
    action.RST are also inline and can accept an arbitrary action as an
    argument. The 'audit' parameter, while still accepted, is
    deprecated in favor of passing 'A_ACCEPT' etc. directly to the

    The TCPFlags action may also now be inlined, although it is not
    inlined by default.

6)  The preceding enhancement required infrastructure for allowing
    BEGIN PERL...END PERL to function in the body of an inline action.

    use Shorewall::Rules;

    	perl_action_helper( $target, $matches )

	$target is the target of the rule and may include log level and
	tag (e.g, 'DROP:info:foo').

	$matches is a string containing one or more ip[6]tables

	Example: "-m conntrack --state ESTABLISHED".

    The function returns true.

    This function may be called in both inline and regular actions. In
    an inline action, the matches from the invoking rule (SOURCE, DEST,
    etc) are applied (in addition to the match(s) passed). In a regular
    action only the passed matches are applied to the rule.

7)  To allow finer-grained selection of the connection-tracking states
    that are passed through blacklists (both dynamic and static), a
    BLACKLIST option has been added in shorewall.conf and

    The BLACKLISTNEWONLY option is now deprecated. A 'shorewall update'
    ( 'shorewall6 update' ) will replace the BLACKLISTNEWONLY option
    with the equivalent BLACKLIST option.

8)  The shorewallrc.archlinux file now assumes that systemd is
    installed (Evangelos Foutras).

9)  When the 'CONNTRACK match' capability is present (as it is in all
    current distros), optimize level 16 now combines adjacent rules
    that differ only in the conntrack states matched.

10) The legacy 'dropInvalid' and 'allowInvalid' builtin actions have
    been converted to inline actions that invoke the Invalid action.

11) Parameters may now be omitted in action invocations. The following
    two invocations are equivalent:

2013-01-19 Shorewall 4.5.12
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release contains the defect repairs from Shorewall

2)  Two defects associated with 'update -D' have been corrected.

    - shorewall.conf.bak is no longer deleted.
    - files that are not changed no longer have their mtime updated.

3)  Inline actions in the RELATED and ESTABLISHED sections now work

4)  The 'dropInvalid' built-in function now works correctly.

5)  The compiler now generates an error when a protocol list is used in
    a context where only a single protocol name/number is accepted.

6)  The generated script now correctly deletes Traffic Control
    configurations when CLEAR_TC=Yes. Previously, the configurations on
    interfaces with a '@xxxxxx' suffix in their names were not cleared.

7)  Under very rare circumstances, optimize level 4 could leave a rule
    that jumped to a non-existant chain, causing iptables-restore to

8)  If an error was raised while compiling a default action, a Perl
    diagnostic could appear and the Shorewall error message would not
    be printed.

9)  It is once again possible to use DNS names in rules without an
    interface name.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The rules compiler has traditionally issued a warning when the
    version of /etc/shorewall[6]/capabilities is less than the version
    supported by the compiler. This warning may be suppressed by
    setting the new option 'WARNOLDCAPVERSION' to 'No' in

2)  The compiler now ignores '-m comment' differences when deleting
    duplicate rules under optimization level 16.

3)  Support has been added for the FQ CODEL (Fair-queuing
    Controlled-delay) queuing discipline. See shorewall-tcclasses (5)
    and shorewall6-tcclasses (5) for details.

4)  Support for arptables has been added to Shorewall and Shorewall

    - Both classic arptables and arptables_jf (fork maintained by Jay

    - There is now an ARPTABLES option in the shorewall.conf file to
      specify the path to the arptables binary.

    - An arprules file has been added to allow specification of
      arptables rules. See shorewall-arprules (5) for details.

    - A 'show arptables' command has been added to show the active
      arptables rules.

    - arptables rules are saved and restored by the save and restore
      commands if the new option SAVE_ARPTABLES is set to Yes in

    - arptables rules are displayed in the 'dump' command.

    As part of this change, a new capability ('Arptables JF') has been
    added. If you use a capabilities file, you should regenerate it
    after installing this version.

5)  The interpretation of the log tag when LOGTAGONLY=Yes is changed.
    Previously, the log tag replaced the chain name in the generated
    log prefix. Now, the tag is interpreted as a chain name and a
    disposition separated by a comma.

    So this rule:


    will generate the following log prefix when using the default
    LOGFORMAT setting:



       LOG:info:,bar	net	fw

    will generate


6)  Rules generated by the RELATED section of the rules file are now in
    separate chains. For each pair of zones (za,zb), RELATED
    connections are handled by a chain whose name is "+za2zb"
    (ZONE_SEPARATOR=2) or "+za-zb" (ZONE_SEPARATOR='-'). This results
    in only one state match to jump to the new chain rather than a
    state match for every rule in the section.

7)  Protocol lists are now supported in the PROTO columns of the
    following additional files:


8)  When an terminating rule is added to the end of a chain, the
    Compiler now marks that chain as 'complete' and inhibits the
    appending of any additional rules.

    A terminating rule is one that has no matches and either uses '-g'
    (goto) or is a jump to one of the following:

       A chain with no RETURN statements and whose last rule is

    Additionally, when optimize level 4 is selected, chains that
    contain a single RETURN rule are optimized away.

9)  Eric Teeter has contributed macro.ActiveDir, a macro that handles
    Samba 4 active directory.
2012-12-26 Shorewall 4.5.11
          N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  This release expands upon the concept of 'Shorewall Variables'
    that was introduced in 4.5.10 with the creation of '@0' in SWITCH
    columns. Beginning with 4.5.10, '@0' (or '@{0}') in a SWITCH column
    expands to the name of the current chain.

    In this release, the Shorewall variables @loglevel and @logtag
    are added. These variables are only available within action bodies
    (both regular and in-line).

    Their contents are:

	The log level specified when the action was invoked. If no
	level was specified, @loglevel expands to 'none'.


	The log tag specified when the action was invoked. If no tag
	was specified, @logtag expands to an empty string.

    @1, @2, ...

    	Same as $1, $2, ...

    Additionally, @chain has been added as a synonym for @0. Remember
    that, unlike $0, non-alphanumeric charaters other than '_' have
    been removed from @0.

2)  Action variables ($0, $1,...$n) and Shorewall variables are now
    available in ?IF and ?ELSIF directives.

3)  A 'nolog' option has been added to /etc/shorewall[6]/actions. This
    option causes the compiler to forego adding the log level and log
    tag from the action invocation to those rules within the body that
    do not specify a tag and/or level.

3)  An 'IGNOREUNKNOWNVARIABLES' option has been added to
    /etc/shorewall[6]/shorewall[6].conf. When set to 'Yes', this option
    instructs the compiler to expand unknown shell variables and
    action parameters to an empty string rather than raising an error.

4)  ?SET and ?RESET directives are now available:

    	 ?SET <variable>   <value>
	 ?RESET <variable>

    To cater to both Shell and Perl programmers, the <variable> may
    be entered with or without leading '$'.

    The ?SET command sets the named <variable> to the specified
    <value> where <value> is a Perl-compatible expression.

    The ?RESET command deletes the named <variable> from the compiler's
    variable table.

    Shorewall variables (@chain, @loglevel,...) and action parameters
    ($1, $2,...) are read-only and their values may not be changed
    (although action parameter values may be changed using Embedded

5)  This release introduces user-defined address variables. Address
    variables are used at run-time rather than at compile-time. Prior
    to this release, two types of address variables were available:

       &<interface>  	 Expands to the primary IP address of

       %<interface>	 Expands to the IP address of the default
       			 gateway out of <interface>

    The two new types added in this release are distinguished by the
    use of "{....}".

    	&{<variable>}	 Address contained in run-time variable
			 <variable>. The named shell variable must
			 contain a valid IP address, either from the
			 generated script's environment or from having
			 been set in the generated script's 'init'
			 extension script. If the variable is empty or
			 if its contents are not a valid IP address, an
			 error is raised and the state of the firewall
			 is not changed.

        %{<variable>}	 Address contained in run-time variable
			 <variable>. If the named variable is empty,
			 the generated script sets it to the all-zeros
			 address ( in IPv4 and :: in IPv6). When
			 this variable appears in a SOURCE or
			 DESTINATION column of any configuration file,
			 or if it appears in the ADDRESSES column of
			 the masq file, then no rule is generated when
			 the address variable is empty. Otherwise, the
			 rule is generated with the all-zeros address
			 replacing the variable. As above, if the
			 variable is non-empty and if it does not
			 contain a valid IP address, an error is raised
			 and the firewall state is unchanged.

6)  The output of 'show [-f] capabities' is now sorted to make
    individual capabities easier to find.

7)  Beginning with this release, ?FORMAT is preferred over FORMAT for
    specifying the format of records in these configuration files:

        action.* files
	macro.* files

    While deprecated, FORMAT (without the '?') is still supported.

    Also, ?COMMENT is preferred over COMMENT for attaching comments to
    generated netfilter rules in the following files.

       	action.* files
       	blrules files
       	macro.* files

    When one of the deprecated forms is encountered, a warning message
    is issued.


       WARNING: 'FORMAT' is deprecated in favor of '?FORMAT' -
       		consider running 'shorewall update -D'.

    As the warning indicates, 'update -D' will traverse the CONFIG_PATH
    replacing FORMAT and COMMENT lines with ?FORMAT and ?COMMENT
    directives respectively. The original version of modified files
    will be saved with a .bak suffix.

    During the update, .bak files are skipped as are files in
    ${SHAREDIR}/shorewall and ${SHAREDIR}/shorewall6.
2012-12-08 Shorewall 4.5.10
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes all defect repair included in

2)  Under rare circumstances, optimize level 16 could produce invalid
    iptables-restore input which would cause start/restart to fail.

3)  Before this release, the 'started' script was run prior to copying
    the temporary script file (e.g., /var/lib/shorewall/.start) to
    /var/dir/shorewall/firewall. If the script failed, the copy would
    not take place even though the firewall had started
    successfully. The script is now copied before running the 'started'

    If you compare the script generated by this release with one
    generated by a prior release, We suggest that you ignore whitespace
    changes (e.g., use the '-w' option in diff); that way, you can see
    the actual change more clearly.

4)  AUTOCOMMENT=No now works correctly; previously, it behaved the same

5)  A harmless extraneous comma has been deleted from the rule
    generated by action.RST.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Shorewall now treats optional non-provider interfaces in a manner
    similar to provider interfaces.

    - They may have entries in /etc/shorewall/routes.
    - They may be enabled/disabled using the 'enable' and 'disable'
    - Shorewall-init will simply enable an optional interface when it
      comes up and disable it when it goes down.

2)  The /etc/shorewall/secmarks and /etc/shorewall6/secmarks files now
    support the UNTRACKED state. See the manpages for details.

3)  The /etc/shorewall/conntrack and /etc/shorewall6/conntrack files
    now support a DROP target.

    It is now possible to specify 'all-' in the SOURCE column which
    generates rules for all zones that are outside of the firewall

4)  A SWITCH column has been added to the /etc/shorewall/conntrack and
    /etc/shorewall/conntrack6 files.

5)  In a SWITCH column, the character '@' is replaced by the chain
    name (non-alphanumeric characters other than '-' and '_' are

6)  An AUDIT action has been added to the /etc/shorewall/rules and

7)  The audited targets (A_ACCEPT, A_DROP, etc.) are now supported in

8)  An additional format (3) has been added to the conntrack file. In
    this format, zone names are not used in the SOURCE column; rather,
    a suffix in the ACTION column determines which raw-table chain the
    generated Netfilter rule will be placed in. See the manpages for

9)  A ULOG ACTION has been added to /etc/shorewall/rules.

10) Within an action body, the variable $0 now expands to the action
    chain name (including leading '%' if present).

11) 'In-line' actions are now available. An action is designated as
    in-line within /etc/shorewall[6]/actions; that file has a
    new OPTIONS column and specifying 'inline' in that column
    designates the action as in-line.

    Normally, actions are expanded into their own chain with a
    unique chain being created for each unique invocation (considering
    log level, tag and parameters). An in-line actions is expanded
    inline within the chain that invokes it. In that sense,
    in-line actions are very similar to macros.

    In-line actions differ from macros in several ways:

    a) A zone may be specified in the SOURCE and DEST columns of a
       macro, while zone names are disallowed in these columns within
       an in-line action (same as in a regular action).

    b) The name of the current chain is available in $0 within the body
       of an in-line action (also within a regular action beginning with
       Beta 3).

    c) In-line actions accept multiple parameters which are available
       in$1, $2, etc (as they are in a regular action).

    d) PARAM has no special meaning in the body of an in-line action
       ($1 serves the same purpose in an in-line action).

    e) Only FORMAT 2 is available in an in-line action.

    f) In-line actions must be defined in
       /etc/shorewall[6]/actions. Those files have been extended to
       include an OPTIONS column. The only option currently supported
       is 'in-line'.

    In-line actions differ from normal actions in that:

    a) Obviously, they are expanded in-line like a macro rather than
       being in their own chain. That means that columns in the
       invocation are merged with those in the action body in the same
       way as they are in a macro.

    b) When AUTOCOMMENT=Yes, each generated rule is commented with the
       name of an in-line action.

    c) Within an in-line action, ?BEGIN PERL ... ?END PERL does not
       have access to the special features available in action a normal
       action body.

    The compiler allows overriding the setting of 'inline' on the
    Shorewall standard actions within
    /etc/shorewall[6]/actions. Beware, however, that some of them
    don't work when in-lined so the compiler will ignore the 'inline'
    option with a warning for those actions:


12) In SWITCH columns, the named switch can now be initialized by the
    'start' command (other commands do not change switch values).

    Initialization is accomplished by adding '=0' or '=1' to the
    switch name.

    Example (using alternative rule column specification):

    #ACTION 	   SOURCE      	    DEST   ...
    NFLOG	   all		    all	   ; switch:logall=1

    The above will cause the 'logall' switch
    (/proc/net/nf_condition/logall) to be initialized to 1 (on). Note
    that netfilter provides no atomic way to define and initialize a
    switch so the loading of the ruleset and the initialization of the
    switches are distinct operations.

13) Also in SWITCH columns, the name of the current Netfilter chain
    will be substituted for '@0' and '@{0}'.

    Example (using alternative rule column specification):

    #ACTION 	   SOURCE      	    DEST   ...
    NFLOG	   net		    fw	   ; switch:@{0}_logall

    The name of the switch will be 'net2fw_logall'.

    Note 1: Non-alphanumeric characters other than '_' and '-' will be
    deleted from the chain name before substitution.

    Note 2: The chain name substituted is the one to which the rule is
    initially added. The rule may end up in a different chain due to

14) Optimization level 16 now suppresses duplicate rules in chains from
    all tables (it previously only suppressed duplicates in the 'raw'

    Non-adjacent rules containing 'mark', 'connmark', 'dscp', 'ecn',
    'set', 'tos' or 'u32' matches are not suppressed:
2012-11-02 Shorewall 4.5.9
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release contains all defect repair from Shorewall

2)  A typo has been corrected in the shorewallrc.default file.

3)  Beginning with Shorewall, Shorewall unconditionally
    restores the provider mark as the first rule in the mangle table
    OUTPUT and PREROUTING chains. Previously, the provider mark was
    restored only if it was non-zero.

    It has become clear that some users need it one way while others
    need it the other way. To resolve this issue, a RESTORE_ROUTEMARKS
    option has been added to shorewall.conf and shorewall6.conf. When
    this option is set to Yes (the default), the approach is
    used (always restore the mark, even if it is zero); when it is set
    to No, the pre- behavior is retained (only restore the mark
    if it is non-zero).

4)  Two error messages produced by the RST action have been
    corrected. They previously referred to errors in the NotSyn action
    rather than RST.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Prior to this release, if a dynamic zone was associated with more
    than one interface, then Shorewall created a separate ipset for
    each interface. This meant that multiple 'add' and 'delete'
    commands might be required to change the zone composition.

    This release introduces a 'dynamic_shared' zone option. When that
    option is specified, a single ipset is generated regardless of the
    number of entries the zone has in the hosts file.

    The 'dynamic_shared' option may only be specified in the OPTIONS
    column of the zones file. 

    The syntax of the 'add' and 'delete' commands is changed for zones
    having the 'dynamic_shared' option:

    	   add <zone> <address>[,<address> ... ]

       	   delete <zone> <address>[,<address> ... ]


        shorewall add direct

    The syntax for 'add' and 'delete' for zones not having the
    'dynamic_shared' option is unchanged.

2)  Puppet and Teredo macros have been contributed by Paul Gear.

3)  The 'show' command now supports a -b (brief) option that suppresses
    listing of rules that have zero packet count and omits chains that
    have no rules listed (Paul Gear).

4)  A CHECKSUM action has been added to the tcrules files. This action
    computes and fills in the checksum in a packet that lacks one.
    This is particularly useful if you need to work around old
    applications, such as dhcp clients, that do not work well with
    checksum offloads, but you don't want to disable checksum offload
    in your device.

    As part of this change, a new 'Checksum Target' capability has been
    added, so if you use a capabilities file, it needs to be
    re-generated after you install this release.

5)  The 'shorewall6 show routing' command now sorts the contents of
    each routing table in the same way as 'shorewall show routing'.

6)  It is now possible to specify a mark range in the ACTION column of
    the tcrules file. This causes the generated ruleset to assign marks
    in the range in round-robin fashion. As part of this change, a
    STATE column is also added that allows marks to be assigned only to
    packets that are in one of the specified states (NEW, RELATED,
    ESTABLISHED, etc.). Specifying NEW in this column along with 
    a range in the ACTION column allows for load-balancing SNAT rules
    over a number of different external addresses.



    1-3:CF	eth1	; state=NEW


    eth0	; mark=1:C
    eth0	; mark=2:C
    eth0 ; mark=3:C

    Specifying a mark range require the 'Statistics Match' capability
    in your iptables and kernel.
2012-09-25 Shorewall 4.5.8
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes the defect repair from Shorewall

2)  The restriction that TTL and HL tcrules could only be placed in the
    FORWARD chain prevented these rules from being used to hide a router
    from traceroute[6]. It is now allowed to place these rules in the
    PREROUTING chain by following the specification with ':P' (e.g.,

3)  Previously, the macro.SNMP macro opened both UDP ports 161 and 162 
    from SOURCE to DEST. This is against the usual practice of opening
    these ports in the opposite direction. Beginning with this release,
    port 162 is opened in to SOURCE to DEST as before, while port 161
    is opened from DEST to SOURCE.

4)  Previously, when compiling for export, both
    /etc/shorewall/shorewall[6].conf and the shorewall[6].conf in the
    configuration directory were processed. Now, only the copy in the
    configuration directory is processed.

5)  The 'iptables_raw' module has been added to the modules.essential

6)  Several corrections have been made to the Fedora/Redhat SysV init
    script for Shorewall-init.

7)  The <directory> parameter to the 'try' command is now documented in
    the shorewall(8) and shorewall6(8) manpages.

8)  Some redundant interface-option rules have been removed in
    configurations with multiple zones configured on a single

9)  Previously, when compiling for export, the compilation would fail
    if the setting of SHAREDIR in the firewall's shorewallrc was
    different from the setting on the admin system. Such compilations
    now succeed.

10) Earlier versions of the compiler accepted ":" as the sole contents
    of a USER/GROUP column with the result that iptables-restore
    failed. This incorrect usage now generates a compile-time error.

11) The 4.5.7 Shorewall compiler unconditionally probes for all 
    helpers, causing their corresponding modules to be loaded. Now,
    this probing will only occur when LOAD_HELERS_ONLY=No.

12) The 'conntrack' files released in Shorewall 4.5.7 contained an
    incorrect control port number for  PPTP (1729 vs. 1723). The port
    number has been corrected.

13) A typo in the PPtP macro has been corrected.

14) The compiler previously accepted TTL(-0) and HL(-0) in the ACTION
    column of tcrules, leading to a failure of the generated script. +0
    was also accepted with the same result. Now, this incorrect usage
    is flagged as an error.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  This release attempts to alleviate the confusion that results
    from different usage of the VARDIR variable name.

    Beginning with Shorewall 4.5.2, 'VARDIR' became a variable in the
    shorewallrc file with the default value '/var/lib'. This was at
    odds with the usage of VARDIR in /etc/$product/vardir, where the
    variable VARDIR holds the state directory for a particular product
    (e.g., /var/lib/shorewall). This latter usage is reflected in the
    Shorewall code which has always used VARDIR to hold the individual
    product's state directory.

    To eliminate this issue going forward, a VARLIB variable has been
    added to shorewallrc to assume the role previously filled by
    VARDIR, while VARDIR now defaults to '${VARDIR}/${PRODUCT}'.

    When a pre-4.5.8 shorewallrc file is present, VARLIB is set to
    ${VARDIR} and VARDIR is set to ${VARLIB}/${PRODUCT}. If VARLIB is
    set in the shorewallrc file and VARDIR is not, then VARDIR also
    defaults to ${VARDIR}/${PRODUCT}. When using the tarball installer,
    the existing shorewallrc file (~/.shorewallrc or
    ${SHAREDIR}/shorewallrc) will be updated and the original will be
    saved as shorewallrc.bak.

    Note that since there is only a single shorewallrc file on a
    system, the only means for overriding the ${VARLIB}/${PRODUCT}
    default setting for VARDIR is still the /etc/$product/vardir file.

2)  A new 'stoppedrules' file has been added and the 'routestopped'
    file is now deprecated. The new file is processed when
    'routestopped' does not exist or is empty. 

    See stoppedrules(5) for details about the new file.

3)  When the -e option (compile for export) is specified in the 'check'
    and 'compile' commands, the current working directory is now
    automatically included in the CONFIG_PATH.

4)  When the -e option is specified in a 'compile' command that
    specifies no script name, the default is now 'firewall' in the
    current working directory. In other words:

       shorewall compile -e

    creates 'firewall' and 'firewall.conf' in the current working
    directory. This is consistent with the behavior of the 'load' and
    'reload' commands.

5)  Multiple UID/GIDs separated by commas may now be given in the
    USER/GROUP column of the rules files.

6)  A warning message is now issued if the 'blacklist' option is	
    specified for a zone (the 'blacklist' option has been deprecated
    for several releases).

7)  A PRIORITY column has been added to the tcfilter files. See
    shorewall-tcfilters(5) and shorewall6-tcfilters(5) for details.

    As part of this change, the method of assigning priorities to
    filters where the PRIORITY is not specified has changed.
    Previously, all ipv4 filters were assigned priority 10 while
    all ipv6 filters were assigned priority 11. Now, for each device,
    the compiler maintains a "high-water priority" that has an initial
    value of 0. When a filter has no priority specified, the high-water
    priority is incremented by 1 and assigned to the filter. When a
    priority greater than the high-water priority is entered in the
    PRIORITY column, the high-water priority is set to the specified
    An attempt to assign a priority value greater than 65535
    (explicitly or implicitly) raises an error.

8)  It is now possible to explicitly assign priorities to
    classification filters created by shorewall for the following:

    - Filter that classifies packets based on their firewall mark
    - Filter that classifies ACK packets via the 'tcp-ack' class
    - Filter that classifies packets based on TOS value.


       #	 	 DMAX:UMAX
       eth0      1:50    5*full/10 full	  1        tcp-ack:15,\

    In this example, the classifier filters would be evaluated in this

    - tcp-ack (priority 15)
    - tos-minimize-delay (priority 20)
    - Mark value 1 (priority 50)

    In other words, the filters are evaluated in ascending priority
    order. If one filter doesn't match, the packet is passed to the
    next filter.
    See shorewall-tcclasses(5) and shorewall6-tcclasses(5) for
    additional information.

9)  The PRIORITY column in the tcclasses file is now optional for HFSC
    classes. If that priority is omitted, then an explicit priority
    must be specified for the MARK value and for the 'tcp-ack' and
    'tos*' options if those are used.
2012-08-20 Shorewall 4.5.7
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes the defect repair from Shorewall

2)  The command 'shorewall enable pppX' could fail with the ip diagnostic

       Error: either "to" is duplicate, or "weight" is a garbage.

    Shorewall now generates the correct ip command.

3)  Optimize level 4 could previously combine two rules that each
    specified the 'policy' match, leading to this iptables-restore

       policy match: multiple elements but no --strict

    The optimizer now avoids combining such rules.

    While this is a long-standing defect in the optimizer, it was
    exposed by changes in Shorewall 4.5.6.

4)  There were several cases where hard-wired directory names appeared
    in the tarball installers. These have been replaced with the
    appropriate shorewallrc variables.

5)  A defect in RHEL 6.3 and derivatives causes 'shorewall show
    capabilities' to leave an empty ipset in the configuration. The
    same defect can cause the Shorewall compiler to similarly leave an
    empty ipset behind.

    This Shorewall release has a workaround for this problem.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  A new 'rpfilter' interface option has been added. Setting this 
    option requires kernel 3.4.0 or later and iptables 1.4.14. This
    option is similar to routefilter but without the disadvantages:

    - Works with both IPv4 and IPv6
    - Uses packet marks when doing reverse path lookup so works with
      all Multi-ISP configurations.
    - Uses standard Netfilter/Shorewall log messages controlled by the
    - RPFILTER_LOG_LEVEL setting in shorewall.conf (5).
    - Disposition and auditing may be controlled using the
    - RPFILTER_DISPOSITION option in shorewall.conf (5).

    This feature adds a new 'RPFilter Match' capability; if you use a
    capabilities file, you should regenerate it using this release.

2)  Beginning with the 3.3 kernels, Netfilter supports a form of
    accounting (nfacct) that is triggered by iptables rules but that
    survives purging and/or reloading the Netfilter ruleset. Shorewall
    support for this form of accounting was added in Shorewall 4.5.7.

    As of this writing, Fedora 17 has partial support for this feature
    but not all. It is necessary to download and build the following:

    - libnetfilter_acct

    - nfacct

    The following Fedora packages are also required:

    - libnetlink and libnetlink-dev

    - libmnl and libmnl-dev

    The tarballs are available from the Netfilter download sites.

    The nfacct utility can create, delete and display nfacct
    objects. These named objects consist of a packet and byte
    counter. Packets matching those netfilter rules that use the nfacct
    match cause the packet and byte count in the object named in the
    match to be incremented.

    To use nfaccnt with Shorewall, use the NFACCT target. See
    shorewall-accounting(5) for details.

    The 'shorewall show nfacct' command is a thin wrapper around the
    'nfacct list' command and displays all objects.

3)  With the addition of the CT action to the /etc/shorewall[6]/notrack
    file, the name of the file does not accurately reflect the file's
    purpose. In this release, the name of the file has been changed to

    The tarball installers will install 'conntrack' along side of an
    existing 'notrack' file. If the 'notrack' file is non-empty, a
    warning message is issued during compilation:

	WARNING: Non-empty notrack file (...);
	         please move its contents to the conntrack file

    This warning can be eliminated by removing the notrack file (if it
    has no entries), or by moving its entries to the conntrack file and
    removing the notrack file. Note that the conntrack file is always
    populated with rules (see enhancement 5).

    If the 'notrack' file exists and is empty, the first compilation
    will remove it with the warning:

        WARNING: Empty notrack file (...) removed

4)  'all' is now accepted as a zone name in the SOURCE column of
    shorewall-conntrack(5). As in the rules file, it means all zones.

5)  Because of the potential for attackers to subvert Netfilter helpers
    like the one for FTP, the Netfilter team are in the process of
    eliminating the automatic association of helpers to connections. In
    the 3.5 kernel, it is possible to disable this automatic
    association, and the team have announced that automatic association
    will eventually be eliminated. While it is certainly more secure to
    add explicit rules that create these associations, for Shorewall to
    require users to add those rules would present a gross
    inconvenience during a Shorewall upgrade.

    To make Shorewall and kernel upgrades as smooth as possible,
    several new features have been added in this release:

    - Shorewall will automatically disable the kernel's automatic
      association of helpers to connections on kernel 3.5 and later.

    - An automatic association of helpers with connections that
      performs the same function as in the pre-3.5 kernels has been
      added. This automatic association is controlled by the new
      AUTOHELPERS shorewall.conf option which is set to 'Yes' by

    - A HELPERS column has been added to the /etc/shorewall/rules

      In the NEW section:

        When the ACTION is ACCEPT, DNAT or REDIRECT, the specified
      	helper is automatically associated with the connection. HELPERS
      	may be specified in action files, macros and in the rules file

      In the RELATED section:

        The rule will only match related connections that have the
        named helper attached.

    - The standard Macros for applications requiring a helper (FTP,
      IRC, etc) have been modified to automatically specify the correct
      helper in the HELPER column.

    - HELPER is now a valid action in /etc/shorewall/rules. This action
      requires that a helper be present in the HELPER column and causes
      the specified helper to be associated with connections matching
      the rule. No destination zone should be specified in HELPER
      rules. HELPER rules allow specification of a helper for
      connections that are ACCEPTed by the applicable policy.


	loc->net policy is ACCEPT.

	In /etc/shorewall/rules:

	   FTP(HELPER)	   loc	-

        or equivalently

	   HELPER    loc     -      tcp      21 ; helper=ftp

    - The set of enabled helpers (either by AUTOHELPERS=Yes or by the
      HELPERS column) can be taylored using the new HELPERS option in

    By making AUTOHELPERS=Yes the default, users can upgrade their
    systems to a 3.5+ kernel without disrupting the operation of their
    firewalls. Beyond such upgrades, we suggest setting AUTOHELPERS=No
    and follow one of two strategies:

    - Use the HELPERS column in the rules file to enable helpers as
      needed (preferred); or

    - Taylor the conntrack file to enable helpers on only those
      connections that are required.

    With either of these approaches, the list if available helpers can
    be trimmed using the HELPERS option and rules can be added to the
    RELATED section of the rules file to further restrict the effect of

    The implementation of these new function places conditional rules
    in the /etc/shorewall[6]/conntrack file. These rules are included
    conditionally based in the setting of AUTOHELPERS.


       ?if $AUTOHELPERS && __CT_TARGET

       ?if __FTP_HELPER
       CT:helper:ftp	all	-	tcp	21

    __FTP_HELPER evaluates to false if the HELPERS setting is
    non-empty and 'ftp' is not listed in that setting.

    For example, if you only need FTP access from your 'loc' zone, then
    add this rule outside of the outer-most ?if....?endif shown above.

       CT:helper:ftp	loc	-	tcp	21

    For an overview of Netfilter Helpers and Shorewall's support for
    dealing with them, see


    for additional information.

6)  To make the spelling of the AUTO* shorewall[6].conf options
    consistent, the AUTO_COMMENT option has been renamed
    AUTOCOMMENT. AUTO_COMMENT is still accepted as an
    alias. 'shorewall[6] update' will rename the option in the updated
    .conf file.

7)  The CT:helper action in the /etc/shorewall[6]/conntrack file
    (formerly the notrack file) lacked flexibility. To allow different
    options to be specified for each helper, the syntax of the
    CT:helper action has been redesigned.


    where <option> is one of:

    - ctevents
    - expevents



    See shorewall-conntrack (5) for details.

8)  The deprecated /etc/shorewall[6]/blacklist files are no longer
    installed. Existing files are still processed by the compiler. Note
    that blacklist files may be converted to equivalent blrules files
    using 'shorewall[6] update -b'.

9)  "?IF", "?ELSE", "?ELSEIF" and "?END" are now case-insensitive so,
    for example, they can be entered as "?if", "?else", "elseif" AND

10) Optimization level 4 now locates short chains (3 rules or less)
    that have a single reference and replaces that single reference with
    the rules themselves.

    Optimization level 8 now eliminates duplicate rules in the raw
2012-07-09 Shorewall 4.5.6
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes the defect repairs from Shorewall through

2)  Previously, the tcrules file was not processed when
    TC_ENABLED=No. That meant that to use features like TPROXY, it was
    necessary to set TC_ENABLED=Yes and create a dummy
    /etc/shorewall/tcstart file. Now, only MANGLE_ENABLED=Yes is

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Support for size tables has been added in complex TC. 

    The OPTIONS column of /etc/shorewall/tcdevices now allows a
    'linklayer' option whose value may be 'ethernet', 'atm' or 'adsl';
    the last two are synonyms.

    When 'linklayer' is specified, it may be followed by additional

	mtu=<mtu> - The device MTU; default 2048 (will be rounded up to a
		     power of two)

    	mpu=<mpubytes> - Minimum packet size used in
    		         calculations. Smaller packets will be rounded up
    		         to this size

    	tsize=<tablesize> - Size table entries; default is 512

    	overhead=<overheadbytes> - Number of overhead bytes per packet.

    See tc-stab (8) for details about these options.

2)  It is now possible to specify the LS (linksharing) rate for an HFSC
    class in /etc/shorewall/tcclasses. See shorewall-tcclasses (5) for

3)  It is now possible to specify that a leaf class will use the RED
    (Random Early Detection) queuing discipline rather than SFQ or
    pfifo. A new class OPTION is defined:

      red=(<red option>=<value>, ...)

      	When specified on a leaf class, causes the class to use the RED
      	(Random Early Detection) queuing discipline rather than
      	SFQ. See tc-red (8) for additional information.

    	Allowable <red option>s are:

    	min <min>
            Average queue size in bytes at which marking becomes a
    	max <max>
	    At this average queue size, the marking probability is
	    maximal. Must be at least twice <min> to prevent
            synchronous retransmits, higher for low <min>.
   	probability <probability>
            Maximum probability for marking, specified as a floating
            point number from 0.0 to 1.0. Suggested values are 0.01 or
            0.02 (1 or 2%, respectively).
        limit <limit>
            Hard limit on the real (not average) queue size in bytes.
	    Further packets are dropped. Should be set higher than
            <max>+<burst>. It is advised to set this a few times higher
            than <max>. Shorewall requires that <limit> be at least
            twice <min>.
        burst <burst>
            Used for determining how fast the average queue size is
            influenced by the real queue size. Larger values make the
            calculation more sluggish, allowing longer bursts of
            traffic before marking starts. Real life experiments
            support the following guideline:
        avpkt <avpkt>
            Optional. Specified in bytes. Used with burst to determine
            the time constant for average queue size calculations. 1000
            is a good value and is the Shorewall default.
        bandwidth <bandwidth>
            Optional. This rate is used for calculating the average
            queue size after some idle time. Should be set to the
            bandwidth of your interface. Does not mean that RED will
            shape for you!
            RED can either 'mark' or 'drop'. Explicit Congestion
            Notification (ECN) allows RED to notify remote hosts that
            their rate exceeds the amount of bandwidth
            available. Non-ECN capable hosts can only be notified by
            dropping a packet. If this parameter is specified, packets
            which indicate that their hosts honor ECN will only be
            marked and not dropped, unless the queue size hits limit
            bytes. Needs a tc binary with RED support compiled
            in. Recommended.

4)  The handling of the USER/GROUP column of the rules file has been
    rewritten. As part of this rewrite:

    a)  The ability to specify a program name (e.g., +prog) has been
        eliminated. The kernel feature which that ability depended on
        was removed in kernel version 2.6.14.

    b)  It is now possible to specify UID and/or GID ranges of the form
    	'low-high' where 'low' and 'high' are integers and low <= high.

5)  It is now possible to use Perl-compatible expressions in ?IF
    directives. As before, variables must be environmental variables,
    options from shorewall.conf, shell variables set in the params file
    or capabilities. As previously, capabilities may be entered with
    leading '__' rather than '$'.



6)  The ?ELSIF directive has been added allowing more convenient
    expression of complex include scenarios.

    Example (column headings abbreviated to fit release notes format):

       ?IF $FALLBACK
       ComcastB  1   0x10000 -    COMB_IF   detect fallback
       ComcastC  2   0x20000 -    COMC_IF   detect fallback
       ComcastB  1   0x10000 -    COMB_IF   detect load=0.66666667
       ComcastC  2   0x20000 -    COMC_IF   detect load=0.33333333
       ComcastB  1   0x10000 -    COMB_IF   detect balance=2
       ComcastC  2   0x20000 -    COMC_IF   detect loose,balance

7)  And ORIGINAL DEST column has been added to the masq file, allowing
    SNAT rules to match only DNAT traffic to a particular original source
2012-06-09 Shorewall 4.5.5
             P R O B L E M S  C O R R E C T E D  I N  4 . 5 . 5

1)  This release includes all defect repair from Shorewall and

2)  The Shorewall compiler sometimes must defer generating a rule until
    runtime. This is done by placing shell commands in its internal
    representation of a chain. These commands are then executed at run
    time to create the final rule.

    If all of the following were true, then an incorrect ruleset could
    be generated:

    a)  Optimization level 4 was set.
    b)  A chain (chain A) containing shell commands had three or fewer
        rules and commands.
    c)  The last rule in a second chain was a conditional jump to
        chain A.

    Under these conditions, the rules and commands in Chain A replaced
    the conditional jump and the conditional part was lost.

    Example (Lines are folded to fit the release note format):

	Chain A:

           if [ $SW_ETH0_ADDRESS != ]; then
	      echo "-A net_dnat -d $SW_ETH0_ADDRESS\
                  -j DNAT --to-destination" >&3

       Chain B:

          -A dnat -i eth0 -j


          if [ $SW_ETH0_ADDRESS != ]; then
	      echo "-A dnat -d $SW_ETH0_ADDRESS\
                  -j DNAT --to-destination" >&3

       Notice that the '-i eth0' match has been lost.

3)  The Shorewall-core configure and script were treating
    SYSCONFDIR as a synonym for CONFDIR making it impossible to set

                    N E W  F E A T U R E S  I N  4 . 5 . 5

1)   It is now possible to include additional information in netfilter
     messages when using plain log levels (debug, info, ...). This is
     done by following the level with a parenthesized comma-separated
     list of "log options".

     Valid log options are:


       Log messages will include the option settings from the IP


       Decode the MAC address and protocol.


       Include TCP sequence numbers.


       Include options from the TCP header.


       Include the UID of the sending program; only effective for
       packets originating on the firewall itself.

     Example: info(tcp_options,tcp_sequence)

2)   The Shorewall-init configuration file (/etc/default/shorewall-init
     or /etc/sysconfig/shorewall-init) now contains a LOGFILE setting.
     When specified, all messages generated by interface updown events
     are logged there. The sample configuration file and the logrotate
     file configure this log as /var/log/shorewall-ifupdown.log.

3)   Previously, the 'ignore' interface option could only be specified
     by itself and could not be specified unless the ZONE column was
     empty (i.e, contained '-'). Now, it is allowed to specify
     'ignore=1' without these restrictions.

     With 'ignore=1', the generated script will still ignore
     Shorewall-init 'up' and 'down' events but the interface will still
     be subject to hairpin filtering unless it has the 'routefilter' or
     'routeback' option.

4)   Imbedded shell and Perl directives may now be optionally preceded
     by a question mark ('?').


         ?BEGIN PERL
	 use strict;

5)  To aid package maintainers for distributions that don't include the
    Digest::SHA Perl module, the Shorewall script looks for
    the DIGEST environmental variable and if the setting is not 'SHA',
    then the Shorewall::Chains module is modified to use $DIGEST as the
    module name.

    To specify SHA1

           DIGEST=SHA1 ./
2012-05-25 Shorewall 4.5.4
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes all defect repairs from Shorewall

2)  When EXPORTMODULES=No in shorewall.conf, the following errors were

    /usr/share/shorewall/modules: line 19: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 23: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 27: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 31: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 35: ?INCLUDE: command not found
    /usr/share/shorewall/modules: line 39: ?INCLUDE: command not found

    These messages have been eliminated.

3)  If the configuration settings in the PACKET MARK LAYOUT section of
    shorewall.conf (shorewall6.conf) had empty settings, the 'update'
    command would previously set them to their default settings. It now
    leaves them empty.

4)  Previously, Shorewall used 'unreachable' routes to null-route the
    RFC1918 subnets. This approach has two drawbacks:

    - It can cause problems for IPSEC in that it can cause packets to
      be rejected rather than encrypted and forwarded.

    - It can return 'host unreachable' ICMPs to other systems that
      attempt to route RFC1918 addresses through the firewall.

    To eliminate these problems, Shorewall now uses 'blackhole' routes.
    Such routes don't interfere with IPSEC and silently drop packets
    rather than return an ICMP.

5)  The 'default' routing table is now cleared if there are no
    'fallback' providers.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The TPROXY tcrules action introduced in Shorewall 4.4.7 was
    incomplete and required additional rules to be added in the 'start'
    or 'started' extension scripts.

    In this release, the TPROXY implementation has been changed and an
    additional DIVERT action has been created. Because the new TPROXY
    has a different set of parameters than the prior one, the tcrules
    file now supports two formats: 

    FORMAT 1 - (default, deprecated )

        The TPROXY action allows three arguments, the first of which
        ('mark') is required.

    FORMAT 2

    	The TPROXY action has two optional arguments; these are the
    	second and third arguments to the format-1 TPROXY:

	    port -- the port on which the proxy is listening. While
	    	    this argument is optional, it will normally be

 	    ip address -- The address on which the proxy is listening. 

    The file format is specified by a line like this:

    	FORMAT {1|2}

    The Sample configurations have been updated to use FORMAT 2.

    The format-2 tcrules file also supports the DIVERT action. The
    DIVERT action directs matching packets to the local system if there
    is a transparent socket in the local system that matches the
    destination of the packet. DIVERT is used to redirect response
    packets from remote web servers back to the proxy process
    running on the firewall rather than being routed directly back to
    the client.

    Finally, the providers file supports a new 'tproxy' option. When
    'tproxy' is specified:

    - It must be the only OPTION given
    - The MARK, DUPLICATE and GATEWAY columns must be empty.
    - The loopback device (lo) should be specified as the INTERFACE.

    The 'tproxy' option causes a reserved mark value to be associated
    with the provider and for its associated routing rule to have
    priority 1.

    Here is the TPROXY configuration at


      FORMAT 2
      net	eth0		...
      net	eth1		...
      loc	eth2		...
      -		lo		ignore


      FORMAT 2
      #							PORT(S) PORT(S)
      DIVERT			eth1	-	tcp	-	80
      DIVERT			eth0	-	tcp	-	80
      TPROXY(3129,	eth2	-	tcp	80

      Squid  3	    -	 -	    lo	     -		tproxy


	http_port tproxy

2)  With some misgivings, this release adds support for the geoip match
    feature available in xtables-addons. Geoip allows matching of the
    source or destination IP address by ISO 3661 country codes. The
    Shorewall support requires xtables-addons 1.33 or later.

    The support is implemented in the form of extended syntax in the
    SOURCE and DEST columns of the rules file.

    To specify a single country code, add a caret prefix ('^').
    Example: ^A1

    To specify multiple country codes, enter them as a
    comma-separated list enclosed in square brackets ('[...]') with a
    caret prefix ('^').

    Example: ^[A1,A2]

    A listing of two-character country codes is available at

    Example rule - Drop email from Anonymous Proxies and Satellite

    #		   					PORT(S)
    DROP:info	   net:^[A1,A2]		dmz	tcp	25

    The compiler determines the set of valid country codes by examining
    the geoip database which is normally installed in
    /usr/share/xt_geoip/. There are two sub-directories at that

        BE - The big-endian database.
	LE - The little-endian database.

    To accomodate both big-endian and little-endian machines and
    to allow the database to be installed elsewhere, a GEOIPDIR option
    has been added in shorewall.conf and shorewall6.conf. The default
    setting is "/usr/share/xt_geoip/LE" since Shorewall is normally
    installed on little-endian machines.

3)  OPTIMIZE level 4 now performs an additional optimization. If the
    last rule in a chain is an unqualified jump to a simple target,
    then all immediately preceding rules with the same simple target
    are omitted. 

    For example, consider this chain:

    	-A fw-net -p udp --dport 67:68 -j ACCEPT
	-A fw-net -p udp --sport 1194 -j ACCEPT
	-A fw-net -p 41 -j ACCEPT
	-A fw-net -j ACCEPT

    Since all of the rules are jumps to the simple target ACCEPT, this
    chain is totally optimized away and jumps to 'fw-net' are replaced
    with jumps to ACCEPT.

    As part of this enhancement, when both OPTIMIZE level 1 and level 4
    are selected, the level 1 optimization step is skipped because it
    is now a limited subset of level 4.

4)  Tuomo Soini contributed a macro for MS SQL (macro.MSSQL).
2012-05-10 Shorewall 4.5.3
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, nested conditionals did not work correctly in all
    cases. In particular:

        ?IF $FALSE
            ?IF $FALSE

    In this case, the lines 'baz' and 'bop' were incorrectly included
    when they should have beeen omitted.

2)  The 'balance' routing table is now cleared if there are no
    'balance' providers.

3)  Previously, the compiler generated an invalid 'ip add route'
    command if an IPv6 provider had '-' in the GATEWAY column.

4)  As noted in the Migration Considerations below, the generated
    firewall script maintains the interface .status files used by LSM
    and SWPING. Up to now, however, the 'disable' command did not
    update the .status file. That has been corrected. As part of the
    change, the 'isusable' script is no longer consulted by the
    'enable' command.

5)  The configure and scripts have not been outputting the
    setting of SPARSE, with the result that /etc/shorewall and
    /etc/shorewall6 are fully-populated on Debian systems. This has
    been corrected.

    For Debian users that want to remove the extra files from
    /etc/shorewall (/etc/shorewall6), the following script will
    do the job (replace 'shorewall' by 'shorewall6' to clean


       cd /etc/shorewall

       for f in *; do
           [ -f /usr/share/shorewall/configfiles/$f ] && \
           diff -q $f /usr/share/shorewall/configfiles/$f > /dev/null \
           && rm $f;

    Once you have done that, edit ~/.shorewallrc and add


    to the settings in that file.


1)  This version includes all defect repairs from Shorewall -

2)  The LOCKFILE setting in shorewall.conf and shorewall6.conf had
    inadvertently become undocumented. It is now documented again.

3)  In an initial installation of Shorewall, Shorewall6, Shorewall Lite
    or Shorewall6 Lite was done under Shorewall 4.5.2, then the
    firewall would not start up at boot even though the installer
    indicated that it would. That defect has been corrected.

4)  Previously, when per-IP rate limiting was invoked, the compiler
    would use the deprecated '--ratelimit' option, even if the
    preferred '--ratelimit-upto' option was available. Now, the
    compiler uses the preferred option if it is supported by the
    installed version of iptables.

5)  Prior to this release, using a manual chain in the ACTION column of
    a macro body generated an error:

    ERROR: Invalid Action (mychain) in macro, macro.FOO (line ...)

    This now works correctly and generates a jump to the specified
    manual chain.

6)  If SHAREDIR was other than /usr/share and $CONFDIR/shorewall/init
    did not exist, then an error message similar to this is emited:

      Processing /usr/local/share/shorewall/init ...
      Usage: /etc/init.d/shorewall

7)  Prevously, a line with the single word COMMENT in the tunnels file
    would generate the following error: 

        ERROR: Zone must be specified

    Now, such a line correctly resets the current rule comment.

8)  In Shorewall 4.5.2, the MARK column in the tcrules file was renamed
    to ACTION but only 'mark' was accepted in the alternate
    specification format. Now both 'mark' and 'action' are accepted.

9)  The alternative method of provider balancing using the statistic
    match feature of iptables/Netfilter was missing some logic, with
    the result that it was ineffective.

10) If a logical interface name was used by itself in the SOURCE column
    of the rtrules file, the generated routing rule would contain the
    logical name rather than the physical name.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

2)  Shorewall's TPROXY support is incomplete. A new and slightly
    different implementation of TPROXY will be available in Shorewall

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The '-T' option is now supported in the Shorewall and Shorewall6
    'load', 'reload', 'restart' and 'start' commands. As with the
    'check' command, it causes a Perl stack trace to be printed along
    with compiler WARNING and ERROR messages.

2)  The debuggability of assertion failures has been improved.

    - A Perl stack trace is now generated unconditionally on an
      assertion failure.

    - Relevant data is passed as additional arguments to assertion
      checks so that setting a breakpoint in
      Shorewall::Config::assert() can now allows examination of the
      data structures surrounding the failure.

3)  The GATEWAY column of the tunnels file has been renamed 'GATEWAYS'
    and now accepts a list of host and network addresses as well as IP

    Exclusion is not permitted.

    In the alternate specification format, both 'gateway' and
    'gateways' are accepted as the column name.

4)  The 'refresh' command now allows additional options:

    -d - Run the rules compiler under the Perl debugger.

    -n - Don't modify routing.

    -T - Produce a Perl Stack trace on errors and warnings.

    -D <directory> - Look in <directory> first for configuration files.

5)  The interfaces file now supports two formats:

    FORMAT 1 - (default, deprecated)

        Includes the BROADCAST column (UNICAST in Shorewall6).

    FORMAT 2

        Does not include the BROADCAST (UNICAST) column.

    The format is specified by a line line this:

    	FORMAT {1|2}

    The Sample configurations have been updated to use FORMAT 2.

6)  A change has been made in the packaging for Slackware. On
    Slackware, there is an /etc/rc.d/firewall.rc script that looks for
    /etc/rc.d/shorewall.rc and /etc/rc.d/shorewall6.rc and runs them,
    passing it's own arguments.

    The file installed as firewall.rc is named and has traditionally been included in
    the Shorewall package. Beginning with this release, it is moved to
    the Shorewall-core package. This opens the door for releasing
    Slackware versions of the -lite products in the future.

    The init scripts for Slackware are now described in slackware.rc

7)  Previously, errors reported in macros were hard to analyze.


       ERROR: Unknown destination zone (bar)
       	      /usr/share/shorewall/macro.SSH (line 11),

    In this case, we don't know where the SSH macro was invoked
    incorrectly. Beginning with this release, the stack of
    includes/opens will be included in ERROR and WARNING messages. 


       ERROR: Unknown destination zone (bar) 
          /usr/share/shorewall/macro.SSH (line 11)
	  from /etc/shorewall/rules (line 42)

    This shows that the SSH macro was invoked on line 42 of the rules

8)  There is now a BLACKLIST macro that works as follows:

    - If BLACKLIST_LOGLEVEL is set, then the macro invokes the
      'blacklog' action.
    - Otherwise, the macro invokes the BLACKLIST_DISPOSITION action.

9)  An RST action has been added which matches tcp packets with the RST
    flag set. The action accepts two optional parameters:

    - Action (DEFAULT, ACCEPT or DROP). Default is DROP.
    - Audit  ('audit' or omitted). Default is omitted.
2012-03-15 Shorewall 4.5.2
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes the defect repairs from Shorewall and (see below).

2)  The generated firewall script includes code to automatically create
    ipsets that are referenced but that don't exist. That code was
    broken in releases 4.4.22 and later. This defect has been
    corrected. As part of the fix, the generated script will now
    issue a warning message when it creates an ipset.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The 'mss' option is now supported in the /etc/shorewall[6]/hosts
    files. See the manpages for details.

2)  It is now possible to conditionally include or omit configuration
    entries based on the settings of shell variables. See
    for details.

3)  The MARK/CLASSIFY column in /etc/shorewall[6]/tcrules has been
    renamed ACTION to reflect the expanded set of actions that can be
    specified in the column.

4)  Some users are finding these ipset warnings objectionable:

    - Warning when a referenced ipset does not exist.
    - Warning when using [src] in a destination column or [dst] in a
      source column.

    These warnings may now be suppressed by setting IPSET_WARNINGS=No
    in shorewall.conf and/or shorewall6.conf.

5)  The evolution of the Shorewall installation process
    continues. Testers are invited to provide comments and suggestions
    about the following.

    Beginning with this release, the installers accept a configuration
    file as a parameter. Options set in the configuration file are as

    BUILD (optional)   -- Platform on which the installation is being
                          performed. Possible values are:

                          apple - OS X
                          archlinux - ArchLinux
                          cygwin - Cygwin running under Windows
                          debian - Debian and derivatives
                          linux - Generic Linux system
                          redhat - Fedora, RHEL and derivatives
                          suse - SLES and OpenSuSE
                          If no value is assigned, then the installer
                          will detect the platform.

    HOST (Optional)    -- Allowed values are same as for BUILD. If not
                          specified, the BUILD setting is used.

    CONFDIR (Req'd)    -- Directory where product configuration
                          directory is installed. Normally /etc.

    SHAREDIR (Req'd)   -- Directory where architecture-independent
                          product files are installed. Normally

    LIBEXECDIR (Req'd) -- Directory where product executables are
                          installed. Normally /usr/share or

    PERLLIBDIR (Req'd) -- Directory where Shorewall Perl modules are
                          to be installed. Traditionally
    SBINDIR (Req'd)    -- Directory where product CLI programs are
                          installed. Normally /sbin

    MANDIR (Req.d)     -- Directory where manpages are
                          installed. Mornally /usr/share/man.

    INITFILE (Optional)
                       -- Optional. If given, specifies the installed
                          filename of the initscript. Normally 
                          set to $PRODUCT which the installers expand
                          to the name of the product being installed.
                          If not specified, no init script will be

    INITSOURCE (Optional)
                       -- Must be specified if INITFILE is specified. 
                          Gives the name of the file to be installed
                          as the INITFILE. 

    INITDIR (Optional) -- Directory where SysV init scripts are
                          installed. Must be specified if INITFILE is

    ANNOTATED (Optional) 
                       -- If non-empty, indicates that the
                          configuration files are to be annotated with
                          manpage information. Normally empty.

    SYSTEMD (Optional) -- Name of the directory where .service files
                          are to be installed. Should only be specified
                          on systems running systemd.

    SYSCONFDIR (Optional)
                       -- Name of the directory where subsystem
                          init configuration information is stored. 
                          On Debian and derivates, this is
                          /etc/default.  On other systems, it is

    SYSCONFFILE (Optional) 
                       -- Name of the file to be installed in the
                          SYSCONFIGDIR. The installed name of the file
                          will always be the product name (shorewall,
                          shorewall-lite, etc.)

    SPARSE (Optional)  -- If non-empty, causes only the .conf file to
                          be installed in
                          ${CONFDIR}/${PRODUCT}/. Otherwise, all of 
                          the product's skeleton configuration files
                          will be installed.

    TEMPDIR (Optional) -- If non-empty, the generated firewall script
                          will export the variable TMPDIR with 
                          value $TEMPDIR.

    VARDIR (Required)  -- Directory where product state information
                          is stored. Normally /var/lib.

                          This setting was previously stored in the
                          optional vardir file in the product's 
                          configuration directory.

    Each of the product tarballs contains a set of configuration files
    for the various HOSTS: 
        shorewallrc.default (for HOST 'linux')

    To aid distribution packagers, a configure script has been added.
    The arguments to the script are the usual list of <option>=<value>
    assignments. The supported options are the same as those above,
    although they may be in lower case and may be optionally preceded
    by '--'.

    The configure script uses the setting of --host to select the
    appropriate rc file. It reads that file to establish default
    settings and then applies the values specified in the argument
    list. To allow use with the %configure RPM macro, only the last
    occurrence of a particular option setting is applied. The resulting
    settings are written to a file named 'shorewallrc' in the current
    working directory and are also written to standard out.

    When Shorewall-core is installed on a system (with no DESTDIR), it
    copies the specified configuration file into root's
    ~/.shorewallrc. The ~/.shorewallrc file is then used, by default,
    when installing the other packages.

    To further aid use with %configure, several aliases are supported:

       alias           option
       -----           ------
       sharedstatedir  vardir
       datadir         sharedir
       sysconfdir      confdir

    The configuration file is also copied to
    ${SHAREDIR}/shorewall/shorewallrc where the CLI programs and init
    scripts can find it. Those programs are modified by the installer
    when ${SHAREDIR} is not /usr/share.

    When using Shorewall-lite or Shorewall6-lite, if the remote
    firewall's shorewallrc file differs from that on the firewall, then
    a copy of the remote file should be placed in the firewall's
    configuration directory on the administrative system.

    Beginning with this release, using /etc/shorewall-lite/vardir
    and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in
    favor of the VARDIR setting in shorewallrc.

        NOTE: While the name of the variable remains VARDIR, the
              meaning is slightly different. When set in shorewallrc,
              each product (shorewall-lite, and shorewall6-lite) will
              create a directory under the specified path name to
              hold state information.



                  The state directory for shorewall-lite will be
                  /opt/var/lib/shorewall-lite/ and the directory for
                  shorewall6-lite will be /opt/var/lib/shorewall6-lite.

              When VARDIR is set in /etc/shorewall[6]-lite/vardir, the
              product will save its state in the specified directory.
2012-03-15 Shorewall 4.5.1
P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  The Shorewall Lite and Shorewall6 Lite installers have been 
    installing the wrong SysV init script on Debian and derivatives.
    The correct script is now installed.

2)  Nested TC classes could result in Perl diagnostics like this one:

    Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in
    numeric eq (==) at /usr/share/perl5/Shorewall/ line 1042,
    <$currentfile> line 13.

    These harmless messages have been eliminated.

3)  It is once again possible to omit the minimum length in the LENGTH
    column of the tcrules file.

4)  Under the following conditions, a compiler internal error was

    - Extended conntrack match support is available.
    - Repeat Match is not available.
    - A DNAT rule specifies a destination port, a server port and
      an original destination.

5)  Beginning with release 4.4.26, setting both 'nets=' and 'dhcp' on
    an interface does not work correctly. That issue has been resolved
    in this release.

1)  When checking or compiling for export (-e option), /sbin/shorewall
    would previously issue a warning message if the SHOREWALL_SHELL
    specified in the remote firewall's shorewall.conf did not exist.

2)  The changes to TOS handling in 4.5.1 are incompatible with older
    releases such as RHEL5 and derivatives. That has been corrected.

3)  The rules compiler now verifies that the protocol is TCP, UDP, SCTP
    or DCCP when checking a port range (low:high or low-high).

4)  Previously, start or restart using the init script would fail with
    an error message referencing 'SHOREWALL_INIT_SCRIPT'. This defect
    was not visible to users that set AUTOMAKE=Yes or that run


1)  This release includes all defect repair from versions

2)  The Shorewall-init installer now installs the proper init script on
    Redhat and Fedora.

3)  A typo has been corrected in the blrules man pages.

4)  Previously, if the interface appearing in the HOSTS column of
    /etc/shorewall6/hosts was not defined in
    /etc/shorewall6/interfaces, then the compiler would terminate with
    a Perl diagnostic:

      	   Can't use an undefined value as a HASH reference at
      	   /usr/share/shorewall/Shorewall/ line 1817,
      	   <$currentfile> line ...

5)  The handling of the LIBEXEC and PERLLIB variables was broken in the
    base 4.5.0 release. Simon Mater has supplied a fix which is
    included in this release.

6)  On systems running systemd, init scripts are no longer installed in

7)  The Shorewall Init installer now correctly detects the use of

8)  On systems running systemd, the installer now installs
    /sbin/shorewall-init. That file has not existed previously, even
    though shorewall-init.service is trying to use it.

9)  The compiler was previously failing to validate the contents of the
    LENGTH and TOS columns in /etc/shorewall/tcrules. The contents of
    those columns are now validated by the compiler and an appropriate
    error message is issued if validation fails.

10) The column headings in the tos files are now in the proper
    order. Previously, the SOURCE PORT and DEST PORT columns were

K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Support is now included for IMQ. This takes the form of of
    IMQ(<number>) in the MARK/CLASSIFY column of

2)  It is no longer necessary to specify a MARK value for the default
    class under a device that does not specify the 'classify'
    option. Simple set the MARK column to '-' in the default class.

3)  Previously, the install scripts included in the Shorewall packages
    were very restrictive. They could either be run to install directly
    onto the system in a distribution-dependent way, or they could
    install into a directory in a distribution-independent way. This
    limited their usefullness to packagers.

    Beginning with this release, the install scripts handle the install
    system and the target system independently. When running an
    installer, the following environmental variables can be set:

    a)  BUILD - Describes the system where the installer is
        running. Accepted values are:

	    cygwin    - Cygwin running under a Microsoft OS
	    apple     - OS X
	    debian    - Debian,Ubuntu,etc.
	    redhat    - Fedora,RHEL,Centos,Foobar,etc.
	    slackware - Slackware
	    archlinux - Arch Linux
	    linux     - Generic Linux
        If BUILD is not set, then the installer uses its existing
        algorithm for detecting the current OS and distribution.

    b)  HOST - Describes the system where the installed package
        will run.

	- For Shorewall and Shorewall6, the possible values are
          the same as for BUILD.

        - If HOST is not set, the value of BUILD (through setting or
          detection) is used.
        - For Shorewall-lite and Shorewall6-lite, the possible choices
          are debian,  redhat, suse, slackware, archlinux and

    	- For Shorewall-init, the possible choices are debian,
          redhat, and suse.

    c)  INITDIR - Gives the absolute path name of the directory
    	containing the init scripts.

    The choice of HOST and TARGET follow the naming of similar macros
    in rpm and autoconf.

    As part of these changes, LIBEXEC and PERLLIB must now hold an
    absolute pathname. So, for example, if you have been using


    you will need to change to


    Additionally, support has been added for sourcing a file containing
    option settings. The file name is 'shorewall-pkg.config' in the
    parent directory of the untar'ed package file.

5)  The .spec files included with each package have undergone
    considerable revision.

    When running the package ./ script:

    a) The setting for LIBEXEC is taken from the standard '_libexecdir'
       rpm macro.

    b) The setting for PERLLIB is taken from the standard
       'perl_privlib' rpm macro.

    c) The setting for INITDIR is taken from the standard
       '_initddir' rpm macro.

    d) The setting of BUILD is detected by the install script.

    e) The setting for TARGET is taken from the standard '_vendor' rpm

    The rpms included with Shorewall are built with these settings of
    the standard rpm-supplied macros:

    	%_libexecdir  	   	/usr/libexec
        %perl_privlib		/usr/share/shorewall
	%_initddir		/etc/init.d
	%_vendor		suse
    The setting of %perl_sitelib is chosen for portability, since there
    seems to be no common location for site-specific Perl modules among
    the rpm-based distributions.

6)  A SWITCH column has been added to /etc/shorewall/masq. This column
    allows for enabling and disabling a rule based on a setting in
    /proc/net/nf_condition. See shorewall-masq(5) for details.

7)  The rules compiler now issues a warning when the 'src' ipset flag
    is used in a destination column or the 'dst' ipset flag is used in
    a source column.

8)  Support has been added for matching and setting the "Differentiated
    Services Code Point" (DSCP) field in the IP header. See
    shorewall-tcrules(5) and shorewall6-tcrules(5) for details.

9)  "Run-time gateway variables" are now supported. These variables
    have names that are composed of a percent sign ('%') followed by
    the logical name of an interface defined in
    /etc/shorewall/interfaces. They are expanded to the IP address of
    the default gateway out of the corresponding interface.


    %eth0 expands to the IP address of the default gateway out of eth0.

    for details.

10) The 'update' command now omits non-default settings of
    WIDE_TC_MARKS and HIGH_ROUTE_MARKS from the updated .conf file.

11) The 'isusable' extension script is no longer installed by
    default. Users wishing to install it may simply copy it from

12) Support has been added for seting the "Type of Service" (TOS)
    header field in shorewall-tcrules(5) and shorewall6-tcrules(5). See
    the manpages for details. As part of this change, use of the
    shorewall-tos(5) and shorewall6-tos(5) files is deprecated and a
    warning is issued on the first rule in each file.
2012-02-12 Shorewall 4.5.0
P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes all defect repair included in

2)  The start and restart commands in Shorewall Lite and Shorewall6
    Lite now correctly handle the 'trace' and 'debug'
    keywords. Previously, those keywords were ignored.

3)  The 'ip route list' command on recent Linux systems (Ubuntu 11.10,
    for example) displays the IPv4 routing table in a seemingly random
    order. In the 'show routing' and 'dump' commands, Shorewall and
    Shorewall-lite now sort the output into the traditional
    'Most-specific to most-general' order.

4) Previously, specifying 'No' in the HAVEROUTE column of
    /etc/shorewall6/proxyndp resulted in a run-time error. The code has
    been corrected so that no error occurs.

K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The rules generated by the following interface options are now
    traversed after those generated by the blrules file.


    As part of this change, the BLACKLIST section in the rules file has
    been eliminated. If you have rules in that section, you must move
    them to the blrules file prior to installing this Shorewall

2)  The timeout interval after which the previous state is restored 
    may now be specified in the safe-start and safe-restart commands.

3)  The packing of the Shorewall products has been changed. Beginning
    with this release, the packages are:

    - Shorewall Core  -- Core libraries installed in

    - Shorewall       -- Requires Shorewall Core. Together with
                         Shorewall Core, provides IPv4 firewalling.

    - Shorewall6      -- Requires Shorewall. Provides IPv6 firewalling.

    - Shorewall Lite  -- Requires Shorewall Core. As before.

    - Shorewall6 Lite -- Requires Shorewall Core. As before.

    - Shorewall Init  -- As before.

4)  Shorewall and Shorewall6 now share a single file as do
    Shorewall Lite and Shorewall6 Lite.

5)  Functions common to both /usr/share/shorewall/prog.header and
    /usr/share/shorewall/prog.header6 are now in a new library -
    lib.core. The files /usr/share/shorewall/prog.footer is now used
    for both IPv4 and IPv6.

6)  Run-time address variables (e.g., &eth0) may now be used in the
    SOURCE column of the rtrules files.

7)  The route_rules file has been renamed to 'rtrules'. The Shorewall
    and Shorewall6 installers will perform the rename on an existing

    If both files exist, route_rules will be processed and rtrules 
    will be ignored with a warning.

8)  A 'PROBABILITY' column has been added to the tcrules files. It
    causes the rule to match randomly with the probability specified in
    the column. See shorewall-tcrules(5) and shorewall6-tcrules(5) for

9)  An alternative to the balance=<weight> option in the providers file
    is now available. This alternative works when there are multiple
    links to the same ISP where both links use an ethernet interface (as
    opposed to PPP0E) and have the same default gateway.

    As part of this change, the generated firewall script now
    automatically maintains the
    /var/lib/shorewall[6][-lite]/interface.status files used by SWPING
    and by LSM.

    See for additional

    Example that sends 1/3 of the connections to the ComcastC provider
    and the rest to ComcastB:




    ComcastB 1      -    -    eth1 loose,balance,load=0.66666667
    ComcastC 2      -    -    eth0  loose,fallback,load=0.33333333

    Note: The 'loose' option is specified so that the compiler will not
          generate and rules based on interface IP addresses. That way
          we have complete control over the priority of such rules 
          through entries in the rtrules file.


    #SOURCE             DEST  PROVIDER  PRIORITY    -     ComcastB  1000
    &eth0               -     ComcastC  1000

    Note: eth0 has a dynamic address, so &eth0 is used in the SOURCE

    Note: Priority = 1000 means that these rules will come before rules




    ComcastB 1      -    -    eth1 loose,balance,load=0.66666667
    ComcastC 2      -    -    eth0  loose,fallback,load=0.33333333

    Note: The 'loose' option is specified so that the compiler will not
          generate and rules based on interface IP addresses. That way
          we have complete control over the priority of such rules 
          through entries in the rtrules file.


    #SOURCE             DEST  PROVIDER  PRIORITY    -     ComcastB  1000
    &eth0               -     ComcastC  1000

    Note: eth0 has a dynamic address, so &eth0 is used in the SOURCE

    Note: Priority = 1000 means that these rules will come before rules
          that select a provider based on marks.

10) The Shorewall files in /etc/default and /etc/sysconfig now support
    two new options that affect how '/etc/init.d/shorewall start' 
    and '/etc/init.d/shorewall restart' behave:

    STARTOPTIONS   -- options to the start commmand.
    RESTARTOPTIONS -- options to the restart command.

    For example, if you always want 'start' to flush the conntrack
    table, then you would have:


11) The Git repository has been reorganized to place the samples and
    manpages under their corresponding product directories. For
    example, trunk/manpage6 was moved to trunk/Shorewall6/manpages.

M I G R A T I O N   I S S U E S

1)  If you are migrating from Shorewall 4.2.x or earlier, please see

2)  The BLACKLIST section of the rules file has been eliminated. 
    If you have entries in that file section, you must move them to the
    blrules file.

3)  This version of Shorewall requires the Digest::SHA1 Perl module.

        Debian: libdigest-sha1-perl
        Fedora: perl-Digest-SHA1
        OpenSuSE: perl-Digest-SHA1

4)  The generated firewall script now maintains the
    /var/lib/shorewall[6][-lite]/interface.status files used by SWPING
    and by LSM.
2011-12-30 Shorewall 4.4.27
    P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Shorewall 4.4.27 includes all defect corrections provider by

2)  When TC_ENABLED=Shared, CLASSIFY rules could not previously be used
    in the tcrules file. Thanks to a patch from Chris Boot, this now
    works as expected.

3)  When providers were used in an IPv6 configuration, each time that
    Shorewall6 was started or restarted, entries as follows would be
    added to the IPv4 (!) routing rules:

        32767:  from all lookup default

    One such entry would be added for each provider.

    Now, one such an entry is added to the IPv6 routing rules, only if
    that entry does not already exist.

4)  The formatting of the manpage info in the annotated configuration
    files has been improved dramatically.

5)  A blrules file generated by 'update -b' would fail the compilation
    step with 
	ERROR: Unknown ACTION (A_blacklog)

    if all the following were true:

    a) BLACKLIST_DISPOSITION did not specify an audited disposition.
    b) BLACKLIST_LOGLEVEL was specified
    c) The 'audit' option appeared in one or more blacklist entries.

         N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Up to this point, Shorewall has had a lot of very similar files in
    multiple products.

    Beginning with this release, the following files are identical.

    - /sbin/shorewall
    - /sbin/shorewall6
    - /sbin/shorewall-lite 
    - /sbin/shorewall6-lite

    The program uses it's own file name to determine which role it is
    to assume. It does that by initializing variables that are later
    used within the various libraries.

    Shorewall and Shorewall6 share use of /usr/share/shorewall/lib.base
    /usr/share/shorewall/lib.cli, and /usr/share/shorewall/lib.common.

    /usr/share/shorewall6/lib.base is a small file that sets variables
    and then sources /usr/share/shorewall/lib.base.

    As before, shorewall and shorewall-lite share the same libraries
    as do shorewall6 and shorwall6-lite.

    Shorewall includes a new library: /usr/share/shorewall/lib.cli-std.
    /usr/share/shorewall[6]/lib.cli contains everything needed by the
    Lite products.

2)  Shorewall now supports the CT target in the Netfilter 'raw'
    table. See 'man shorewall-notrack' for details.

    The main use of this target is described in this paper:

    The paper a product of the vulnerability described in the 4.4.20
    release note which introduced the 'sfilter' facility. In the paper,
    rules such as the following are recommended:

    	  iptables -A PREROUTING -t raw -p tcp --dport 2121 \
       	       -d -j CT --helper ftp

    The equivalent entry in /etc/shorewall/notrack would be:

	#                                   	  PORT(S)
	CT:helper:ftp  -	 tcp	  2121

    As part of this change, Shorewall now verifies the helper name in
    the HELPER column of the tcrules and tcpri files.

3)  The above-referenced paper also advocates careful control of
    RELATED rules. To allow such control, two new options have been
    introduced in shorewall[6].conf:


      compatibility with earlier releases, the default is ACCEPT.
      match any rule in the RELATED section of the rules file.


      Specifies a level for logging related packets. Default is empty
      which means that no logging occurs.

4)  The options in shorewall.conf (shorewall6.conf) may now be used as
    shell variables in other configuration files.

5)  A new option, USE_PHYSICAL_NAMES, has been added to shorewall.conf
    and shorewall6.conf. Normally, when the rules compiler creates a
    Netfilter chain that relates to an interface, the logical name of
    the interface is used as the base for the chain name. For example,
    if an interface has logical name OAKLAND and physical name eth0,
    then the primary chain for input arriving on that interface is
    normally 'OAKLAND_in'. When USE_PHYSICAL_NAMES=Yes, the name would
    be 'eth0_in'.

6)  CLASSIFY entries in tcrules may now be placed in the FORWARD or
    PREROUTING chain by following the class Id with :F or :P
2011-12-02 Shorewall 4.4.26
         P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 2 6

1)  The Perl module version numbers have now been updated to reflect
    changes in 4.4.26.

2)  The 4.4.26 rules compiler does not issue a warning when a
    capabilities file was generated with Shorewall 4.4.25, even though
    new capabilities were added in 4.4.26. This has been corrected so
    that a warning is generated.

3)  When TC_ENABLED=Shared, CLASSIFY rules could not be used in the
    tcrules file. Thanks to a patch from Chris Boot, this now works as

4)  The quoted part of the progress message 'Provider "..." compiled'
    was inadvertently omitted by a change in Shorewall 4.4.23. That
    text has now been restored.


1)  This release includes all corrections included in through

2)  In 4.4.25, ACCEPT behaved in the BLACKLIST section the same way as
    in the other rules file sections. This could lead to connections
    being accepted inadvertently.

    Now, ACCEPT behaves like WHITELIST; that is, it exempts the packet
    from the remaining rules in the BLACKLIST section.

3)  Previously, Shorewall did not detect the ULOG and NFLOG
    capabilities. This lead to run-time failures during 'start' and
    'restart' as well as confusing error messages during compilation
    when ULOG or NFLOG was used when the LOG target was not available.

    ULOG and NFLOG are now detected capabilities so, if you use a
    capabilities file, you will need to regenerate it in order to use
    these log levels.

4)  The SAME tcrules target was broken in Shorewall 4.4.22. It now
    works correctly again.

5)  Previously, 'shorewall6 update' did not update shorewall6.conf. The
    command now works as expected.

6)  In earlier releases, the compiler was attempting to process the
    params file before it was aware of the setting of CONFIG_PATH. This
    could cause the params file to be missed if it was not located in
    /etc/shorewall[6] or in the directory named in the start
    (restart,compile,check,...) command.

    Now, /sbin/shorewall[6] passes $CONFIG_PATH to the compiler
    (/usr/share/shorewall/ in the new '--config_path'

               N E W   F E A T U R E S   I N   4 . 4 . 2 6

1)  A new 'blrules' file has been added as an alternative to rules in
    the BLACKLIST section of the rules file. When rules are present in
    both the blrules file and in the BLACKLIST section, those in
    blrules are processed first.

2)  A '-b' option has been added to the 'update' command. In addition
    to updating the shorewall.conf file (shorewall6.conf), this option
    causes the compiler to convert your current legacy blacklist
    configuration to use the new blrules file.

    Changes include:

    a) blrules is populated with entries equivalent to your existing
       blacklist file.

    b) Your existing blacklist file is renamed blacklist.bak.

    c) The 'blacklist' keyword is removed from your zones, interfaces
       and hosts files. When one of these files is modified, the
       unmodified original is saved in a .bak file.

    As part of this change, the 'blacklog' target is permitted in the
    blrules file when BLACKLIST_LOG_LEVEL is specified in
    shorewall.conf (shorewall6.conf). It logs the packet at the
    specified level, then disposes of it based on the setting of

3)  The Debian init files (with the exception of Shorewall-init) now
    support the 'status' command.

4)  This release formalizes the feature that has long been
    documented at

    The WIDE_TC_MARKS and HIGH_ROUTE_MARKS options have traditionally
    been used to define the various fields in a packet/connection mark.
    But more flexible control is provided using these options.


           The number of bits at the least-significant end of the mark
           to be used for traffic shaping marking. May be zero.


           The number of bits in the mark to be used for provider
           marks. May be zero.


           The offset from the right (low-order end) of the provider
           number field. If non-zero, must be >= TC_BITS. Shorewall
           automatically adjusts PROVIDER OFFSETs value to inforce this
           restriction. May be zero, in which case the TC mark field
           and Provider mark field overlay.


           The number of low-order bits to be masked when clearing the
           traffic shaping mark. Must be >= TC_BITS and <=
           PROVIDER_OFFSET (provider that PROVIDER_OFFSET > 0).

    Beginning with Shorewall 4.4.12, the field between MASK_BITS and
    PROVIDER_OFFSET can be used for any purpose you want.

    Beginning with Shorewall 4.4.13, the first unused bit from the
    right is used by Shorewall as an 'exclusion mark' which allows
    exclusion in CONTINUE, NONAT and ACCEPT+ rules.

    It is actually the values of the above four options that determine
    how Packet/Connection Marks are layed out. Their default values are
    derived from the settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS as
    shown in the table at

    The 'shorewall update' ('shorewall6 update') command will supply
    values for these options based on the settings of WIDE_TC_MARKS and

    The 'shorewall show marks' ('shorewall6 show marks') command shows
    the range of each field in both decimal and hex.


    	Shorewall 4.4.26 -  Mark Layout at gw - Sun Nov 20
           2:08:23 PST 2011

        Traffic Shaping: Not Enabled
    	User:1-65535 (0x1-0xffff) mask 0xffff
    	Provider:65536-196608 (0x10000-0x30000) mask 0x30000
    	Zone:262144-3932160 (0x40000-0x3c0000) mask 0x3c0000
    	Exclusion:4194304 mask 0x400000

    As of this release WIDE_TC_MARKS and HIGH_ROUTE_MARKS are

5)  This release introduces limited support for using back-to-back veth
    devices to access a bridge.

    Consider this setup:

                                                 -- eth1 (zone1)
       WAN ---- eth0      veth0 <-> veth1-- br0 --- eth2 (zone2)
                                                 -- eth3 (zone3)

    In this configuration, it is veth0 that has an IP address; the
    bridge does not.

    Because veth1 is a port on br0, Netfilter allows filtering between
    that interface and each of the other ports. All connections from
    the firewall (fw) and the WAN ((net) enter the bridge through
    veth1. All traffic from zone1-zone3 enter the routing firewall
    through veth0.

    Note that, in this configuration, packets between zones1-zone3 and
    the rest of the world go through Netfilter twice. Assume that we
    associate veth0 with an ip zone called 'bridge' and veth1 with a
    bport zone called 'portal'. Then the two traversals of Netfilter

    a)  Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the
        destination zone is 'portal'.

    b)  Between veth0 and the final destination. The source zone is
        bridge and the destination zone is either fw or net.

    A similar scenario occurs with traffic originating in the net or
    firewall zones and  destined for zone1-zone3.

    As you can see, the problem here is that in the first traversal, we
    know the real source zone but not the real destination zone; and in
    the second traversal, we know the real destination zone but not the
    real source zone.

    The solution allows us to know the real source zone during the
    second traversal.

    A new ZONE_BITS option is added to shorewall.conf
    (shorewall6.conf). Its value determines the number of bits of the
    packet mark to use for zone marks. When ZONE_BITS is non-zero,
    Shorewall automatically assigns a mark value to each zone (the
    firewall zone always has value 0). Zone marks are assigned to all
    zones except those that specify 'nomark' in the OPTION column of
    their zones file entry. In the above example, the bridge and portal
    zones would have 'nomark' specified.

    With ZONE_BITS and 'nomark' specified appropriately, now each
    packet from the 'bridge' zone has a packet mark that lets us know
    which of the three bport zones (zone1-zone3) the packet originated

    Similarly, packets entering the bridge through veth1 have a mark
    value that records whether the packet is from the net zone or the
    fw zone.

    As part of these changes, the compiler now accepts a zone name in
    the MARK column of the rules file, when ZONE_BITS is non-zero. This
    permits rules of this type:

    	    ACCEPT   bridge	net ...	; mark=zone2

    to control connections from zone2 to the net, and rules such as

       	    ACCEPT   portal     zone1 ...; mark=net 

    to control connections from the net to zone1.

    One final note; DNAT rules should be placed in the first traversal
    (net->bridge on input).

    See for a fuller

6)  This release introduces optimization category 16. When this
    category is enabled, sequences of 'compatible' rules are combined
    into a single rule.

    A sequence of rules is considered compatible if the rules differ
    only in their destination ports and comments.

    A sequence of combatible rules is often generated when macros are
    invoked in sequence.

    The ability to combine adjacent rules is limited by two factors:

    - Destination port lists may only be combined up to a maximum of 15
      ports, where a port-pair counts as two ports.

    - Rules may only be combined until the length of their concatinated
      comments reach 255 characters.

    When either of these limits would be exceeded, the current combined
    rule is emitted and the compiler attemts to combine rules beginning
    with the one that would have exceeded the limit.

    Adjacent combined comments are separated by ', '. Empty comments at
    the front of a group of combined comments are replaced by 'Others
    and'. Empty comments at the end of a group of combined comments are
    replaced by 'and others'.

    Example 1: Rules with comments "FOO", <empty> and "BAR" would
    	       result in the combined comment "FOO and others, BAR".

    Example 2: Rules with comments <empty>, "FOO" and "BAR" would reult
    	       in the combined comment "Others and FOO, BAR".

    Note: Optimize level 16 requires "Extended Multi-port Match" in your
    	  iptables and kernel.

7)  The 'enable' and 'disable' commands, previously supported only by
    the compiled firewall script, are now supported by the CLI programs
    (/sbin/shorewall, /sbin/shorewall-lite, etc.) as well.

    In earlier releases, these commands only allowed the provider to be
    specified by its physical interface name, thus making it impossible
    to enable/disable individual providers sharing a single
    interface. The commands now accept a provider name for all optional
    providers. For those that share an interface, only the provider
    name is accepted.
2011-10-29 Shorewall 4.4.25
         P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 2 5

1)  Previously, if all the following were true:

    - AUTOMAKE=Yes
    - Current compiled script (/var/lib/shorewall/firewall or
      /var/lib/shorewall6/firewall) up to date
    - There was a saved configuration

    then rather than start the current configuration, 'shorewall start
    -f' or 'shorewall6 start -f' would incorrectly restore the saved

2)  The DropSmurfs and TCPFlags actions are now available in
    Shorewall6. They were previously omitted from the IPv6 actions.std

3)  The 'rawpost' table was previously omitted from the output of the
    'dump' command. It is now displayed.

4)  Previously, if a configuration contained more than one wildcard
    interface (physical name ending in '+'), then the generated script
    might not work properly with Shorewall-init. This defect dates back
    to the introduction of Shorewall-init.


    z1		eth+		-		optional
    z2		veth+		-		optional

    The script will contain a case statement of this form:

    	case $interface in

1)  A 'refresh' command with no chains or tables specified will now
    reload chains created by entries in the BLACKLIST section of the
    rules file. 

2)  The rules compiler previously failed to detect the 'Flow Filter'
    capability. That capability is now correctly detected.

3)  The IN_BANDWIDTH handling change in 4.4.25 was incompatible with
    moribund distributions such as RHEL4. Restoring IN_BANDWIDTH
    functionality on those releases required a new 'Basic Filter'

1)  A defect in the optimizer that allowed incompatible rules to be
    combined has been corrected.


        Rule1:            -i eth1 -j chainx
        Rule in chainx:   -i eth2 -j ACCEPT 
	Incorrect result: -i eth2 -j ACCEPT

    With the change in this release, Rule1 will remain as it is.

2)  Routes and rules added as a result of entries in
    /etc/shorewall6/providers were previously not deleted by 
    'stop' or 'restart'. Repeated 'restart' commands could therefore
    lead to an incorrect routing configuration.

3)  Previously, capital letters were disallowed in IPv6 addresses. They
    are now permitted.

4)  If the COPY column in /etc/shorewall6/providers was non-empty,
    previously a run-time error could occur when copying a table. The
    diagnostic produced by ip was:

       Either "to" is duplicate, or "cache" is garbage

5)  When copying IPv6 routes, the generated script previously attempted
    to copy 'cache' entries. Those entries are now omitted.

6)  Previously, the use of large provider numbers could cause some 
    Shorewall-generated routing rules to be ineffective.

    Example (provider numbers 110 and 120):

    	0:      from all lookup local 
	10109:  from all fwmark 0x6e/0xff lookup 110 
	10119:  from all fwmark 0x78/0xff lookup 120 
	11000:  from 2001:470:1f04:262::1/64 lookup 110 
	11001:  from 2001:470:c:316::1/64 lookup 120 
	32766:  from all lookup main 
	47904:  from 2001:470:8388::1 lookup 110 <===========
	50464:  from 2001:470:f032::1 lookup 120 <===========

    Now, all routing rules generated by provider interface IP (and IP6)
    addresses are created at priority 20000.

    	0:      from all lookup local 
	10109:  from all fwmark 0x6e/0xff lookup 110 
	10119:  from all fwmark 0x78/0xff lookup 120 
	11000:  from 2001:470:1f04:262::1/64 lookup 110 
	11001:  from 2001:470:c:316::1/64 lookup 120 
	20000:  from 2001:470:8388::1 lookup 110 <===========
	20000:  from 2001:470:f032::1 lookup 120 <===========
	32766:  from all lookup main 

7)  In some contexts, IPv6 addresses of the form ::i.j.k.l were
    incorrectly classified as invalid by the configuration compiler.

               N E W   F E A T U R E S   I N   4 . 4 . 2 5

1)  The original static blacklisting implementation was
    interface-oriented and only handled blacklisting by source
    address.  In Shorewall 4.4.12, the ability to blacklist by
    destination address was added and blacklisting could be specified
    as a ZONE option. This change, plus additional changes in
    subsequent releases has lead to an implementation that is complex
    and hard to extend.

    In this release, a new static blacklisting facility has been
    implemented. This facility is separate from the legacy facility, so
    existing configurations will continue to work without change.

    A BLACKLIST section has been added to the rules file. This section
    is now the first section, having been added ahead of the ALL
    section. The set of packets that are subject to blacklisting is
    still governed by the setting of BLACKLISTNEWONLY in
    shorewall.conf. The settings of BLACKLIST_LOGLEVEL and
    BLACKLIST_DISPOSITION are not relevant to the new implementation.
    Most of the actions available in other sections of the rules file
    are available in the BLACKLIST section and logging is specified on
    a rule-by-rule basis in the normal way.

    In addition to the other actions available, a WHITELIST action has
    been added which exempts matching packets from being passed to the
    remaining rules in the section.

    Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has
    a companion blacklisting chain. The name of the blacklisting chain
    is formed by appending "~" to the zone2zone chain. For example,
    'net2fw' blacklist rules appear in the chain net2fw~. 

    There is a likelihood that multiple blacklisting chains will have
    exactly the same rules. This is especially true when 'all' is used 
    as the zone name in the SOURCE and/or DEST columns. When 
    optimization level 8 is used, these identical chains are combined 
    into a single chain with the name ~blacklistN, where N is a number 
    (possibly with multiple digits).

    The 'nosurfs' and 'tcpflags' interface options generate rules that
    will be traversed prior to those in the BLACKLIST section. If you
    want similar rules to be travered on packets that were not dropped
    or rejected in the BLACKLIST chain, you can use the new
    'DropSmurfs' and/or 'TCPFlags' standard actions.

    The DropSmurfs action has a single parameter whose default value
    is  '-'. The action silently drops smurfs without auditing. If you 
    want to audit these drops, use DropSmurfs(audit). Logging can be 
    specified in the normal way (e.g., DropSmurfs:info).

    The TCPFlags action has two parameters whose default values are
    DROP and -. The first action determines what is to be done with
    matching packets and can have the values DROP, REJECT or ACCEPT. If
    you want the action to be audited, pass 'audit' in the second

    Example: TCPFlags(REJECT,audit)

    Again, logging is specified in the normal way.

    The 'maclist' interface option can also generate rules that are
    traversed prior to those in the BLACKLIST section. If you want them
    to come after the the blacklist rules, simply recode your maclist
    rules in the NEW section of the rules file. The 'macipmap' ipset
    type is ideally suited for this task.

    Example: assumes the ipset name is macipmap and that the
     	     zone to be verified is named wlan


		DROP:info	wlan:!+macipmap		all

2)  '6in4' has been added as a synonum for '6to4' in the TYPE column of
    the tunnels file.

3)  The handling of IN_BANDWIDTH in both /etc/shorewall/tcdevices and
    /etc/shorewall/tcinterfaces has been changed. Previously:

    a) Simple rate/burst policing was applied using the value(s)

    b) IPv4 and IPv6 were policed separately.

    Beginning with this release, you have the option of configuring a
    rate estimated policing filter. This type of filter is discussed at     

    You specify an estimeting filter by preceding the IN-BANDWIDTH with
    a tilde ('~').

    Example: ~40mbit

    This example limits incoming traffic to an *average* rate of 40mbit.

    There are two other other parameters that can be specified, in
    addition to the average rate - <interval> and
    <decay_interval>. There is an excellent description of these
    parameters in the document referenced above.

    Example: ~40mbit:1sec:8sec

    In that example, the <interval> is 1 second and the
    <decay_interval> is 8 seconds. If not given, the default values are
    250ms and 4 seconds. Both parameters must be supplied if either is

    Also in this release, the policing of IPv4 and IPv6 has been
    combined so a single filter is applied to all traffic on a
    configured interface.

4)  Shorewall6 now supports the 'balance' and 'fallback' provider
    options. These options are restricted to one interface per
    configuration for each option.

5)  The scripts generated by Shorewall6 now support the 'enable' and
    'disable' commands.

6)  A 'MARK' column has been added to the route_rules file. See
    shorewall-route_rules (5) and shorewall6-route_rules (5) for
2011-10-09 Shorewall 4.4.24
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes all problem corrections from releases

2)  The 'fallback' option without =<weight> previously produced invalid
    'ip' commands.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Stateless NAT is now available in Shorewall6. See
    shorewall6-netmap(5) for details. Beta 2 added the ability to use
    exclusion in the NET1 column.

2)  /sbin/shorewall6 now supports the 'show rawpost' command.

3)  This release includes support for 'Condition Match' which is
    included in xtables-addons. Condition match allows rules to be
    predicated on the setting of a named switch in

    for details.

4)  With the preceding change, the rules file now has 14 columns. That
    makes it awkward to specify the last column as you have to insert
    the correct number of '-' to get the right column.

    To make that easier, Shorewall now allows you to specify columns
    using several (column-name,value) formats. See for

5)  The generated script will now use the iptables/ip6tables -S command
    if available.

6)  The implementation of USE_DEFAULT_RT=Yes has been changed
    significantly. These changes include:

    a) A new BALANCE routing table with number 250 has been added.
    b) Routes to providers with the 'balance' option are added to the
       BALANCE table rather than the default table.
    c) This allows 'fallback' to work with USE_DEFAULT_RT.
    d) For optional interfaces, the 'fallback' option without a value
       now works the same as if 'fallback=1' had been specified.

    This change also corrected several problems with 'fallback' and

7)  Support has been added for TTL manipulation (HL in Shorewall6). 
    See shorewall-tcrules(5) or shorewall6-tcrules(5) for details.
2011-09-06 Shorewall 4.4.23
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  This release includes all problem corrections included in Shorewall -

2)  Previously, the contents of the NET1 and NET2 columns in
    /etc/shorewall/netmap were not validated by the rules compiler. As
    a result, invalid entries in those columns could cause the compiled
    script to fail while running iptables-restore.

3)  The 'hits' command could issue an 'invalid number' diagnostic when
    run under busybox ash. That diagnostic has been eliminated.

4)  If a zone had multiple interfaces and neither 'routefilter' nor
    'routeback' was specified on the interfaces, then traffic between
    the interfaces could fail with a log message such as this one:

    Sep  4 22:20:41 pilot kernel: [427181.381412] 
    Shorewall:sfilter1:DROP:IN=eth3 OUT=eth5 
    MAC=fe:ff:ff:ff:ff:ff:00:16:3e:7f:a0:b9:08:00 SRC= 
    DST= LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP 
    TYPE=8 CODE=0 ID=10893 SEQ=2

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The leading '#!/bin/sh' line has been deleted from non-executable
    shell modules.

2)  When 'shorewall update' or 'shorewall6 update' results in no change
    to the .conf file, a message is issued, the .bak file is removed
    and the command terminates without error.

    Note: This change was also included in Shorewall

3)  Support has been added for 'stateless NAT'. Stateless NAT is very
    simmilar to NATMAP but differs from it in a couple of ways:

    a. It does not rely on connection tracking, but is rather
       implemented in the Netfilter raw table.

    b. Both the source and destination address can be rewritten in all
       three raw table chains: PREROUTING, OUTPUT and POSTROUTING.

    When used together with stateful NAT, it allows a single router to
    handle a duplicate network address situation.

    Suppose that a VPN using interface tun0 is used to connect to
    another organization, and that both intranets have network

    To allow the two organizations to communicate, they decide to use to address the other's

    The following four entries are required in /etc/shorewall/netmap:

	#TYPE   NET1                INTERFACE        NET2
	SNAT	    tun0
	DNAT	    tun0
	DNAT:T	    tun0
	SNAT:P	    tun0

    Stateless NAT entries differ from NETMAP entries in the TYPE
    column. For stateless entries, both the type of address
    translation (DNAT or SNAT) and the chain (O for OUTPUT, P for
    PREROUTING and T for POSTROUTING) are given.

4)  A new section (ALL) has been added to /etc/shorewall/rules and to
    /etc/shorwall6/rules. When present, the NEW section must be the
    first section in the file and contains rules that are applied to
    packets regardless of their connection tracking state.

5)  The generated script now detects and removes stale lock files.

6)  Jonathan Underwood has contributed Fedora/Redhat init script and
    .service files. The .service files are used with systemd which
    manages the startup sequence in Fedora 16.

    When installing using the install scripts:

    a) If /lib/systemd/system exists, the .service files are installed
       there and are activated using /sbin/systemctl. When installing
       into a directory, setting the SYSTEMD environmental variable to
       a non-empty value will also trigger this behavior.

    b) If /etc/redhat-release exists, the Fedora/Redhat init script
       will be installed in /etc/init.d. When installing into a
       directory, setting the FEDORA environmental variable to a
       non-empty value will also trigger this behavior.

7)  Previously, when a provider interface went 'soft down' (UP and
    configured but not usable) or came back up from being 'soft down',
    the firewall had to be reloaded ('/var/lib/shorewall/firewall
    restart') to disable or enable the interface.

    Beginning with this release, the compiled IPv4 script supports two
    new commands:

    -	disable <interface>
    -	enable <interface>

    The 'disable' command removes all policy routing added as a result
    of the interface's entry in /etc/shorewall/providers and and any
    traffic shaping configuration on the interface. The 'enable'
    command restores policy routing and traffic shaping and refreshes the
    interfaces's entries in /proc.

8)  Shorewall now uses /sys/module/ to determine which modules are
    loaded, thus speeding up start/restart
2011-08-02 Shorewall 4.4.22
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  On older distributions where 'shorewall show capabilities'
    indicates 'Connection Tracking Match: Not Available', harmless Perl
    diagnostics like the following could be issued:

        Use of uninitialized value $list in pattern match (m//) 
        at /usr/share/shorewall/Shorewall/ line 1273,
        <$currentfile> line 14.

        Use of uninitialized value $list in split 
        at /usr/share/shorewall/Shorewall/ line 1275,
        <$currentfile> line 14.

2)  On older distributions where 'shorewall show capabilities'
    indicates 'Mangle FORWARD Chain: Not Available', entries in the ecn
    file generated the following Perl Diagnostic:

        Use of uninitialized value in hash element 
	at /usr/share/shorewall/Shorewall/ line 1119.

3)  Previously, if a provider interface was derived from an optional
    wildcard entry in /etc/shorewall/providers, then the interface was
    never considered to be usable.



	net	 ppp+	     -		  optionsl


	ISP1	   1	   1	 ppp0	   ...

1)  On older distributions where 'shorewall show capabilities'
    indicates 'Connection Tracking Match: Not Available', Shorewall
    4.4.22 and generated invalid iptables-restore input.

2)  Previously, the compiler always placed '#!/bin/sh' on the first
    line of the generated script. It now uses the setting of
    SHOREWALL_SHELL on that line rather than '/bin/sh'. Note that
    SHOREWALL_SHELL defaults to '/bin/sh' so this change only affects
    those who specify a different shell.

1)  Previously, if the name of a zone began with 'all', then entries
    for that zone in /etc/shorewall/rules and /etc/shorewall6/rules
    treated the name the same as 'all'.

    This defect is present in Shorewall 4.4.13 through 4.4.22.

2)  Previously, when LOAD_HELPERS_ONLY=No, harmless iptables-restore
    warnings as follows could be generated:

        Running /usr/local/sbin/iptables-restore...
	--set option deprecated, please use --match-set
	--set option deprecated, please use --match-set
	IPv4 Forwarding Enabled

3)  Potential SELinux issues have been corrected. From Orion Poplawski.


1)  Under rare conditions, long port lists (>15 ports) could result in
    the following failure when optimization level 4 was enabled.

       Use of uninitialized value in numeric gt (>) 
       at /usr/share/shorewall/Shorewall/ line 1264.

       ERROR: Internal error in
       Shorewall::Chains::decrement_reference_count at
       /usr/share/shorewall/Shorewall/ line 1264

2)  All corrections included in Shorewall (see below).

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  When 'shorewall update' or 'shorewall6 update' results in no change
    to the .conf file, a message is issued, the .bak file is removed
    and the command terminates without error.


1)  Three new parameterized standard actions are included in this release.

        Invalid    - Packets in the INVALID connection tracking state
        Broadcast  - Broadcast and Multicast Packets
        NotSyn     - TCP packets that have the SYN flag set and all
        	     other flags reset.
    The standard default Drop and Reject actions have been modified to
    use these new actions.

    Each accepts two parameters:

    a) Action to perform on matching packets. Must be ACCEPT, DROP or
       REJECT. Default is DROP.
    b) 'audit' flag. If 'audit', then the action will be audited.

    The new actions deprecate the following built-in actions:

    	allowBcast     - use Broadcast(ACCEPT)
	allowInvalid   - use Invalid(ACCEPT)
    	dropInvalid    - use Invalid(DROP)
	dropBroadcast  - use Broadcast(DROP)
	dropNotSyn     - use NotSyn(DROP)
	rejNotSyn      - use NotSyn(REJECT)

2)  Up to this point, the Perl-based compiler has stored rules
    internally in iptables/ip6tables command strings. This has
    made the optimizing the ruleset difficult and has made the
    optimizer the most defect-dense part of the code.
    This release marks to first step toward converting the compiler to
    use an internal rule representation that is easier to optimize and
    that is easy to convert to iptables/ip6tables commands effeciently.

    The parser still generates iptables/ip6table rules which are then
    converted into the internal form.

3)  Optimize level 8 causes chains that are identical to another chain
    to be deleted, and their references are replace by references to
    the other chain. This can lead to confusion when looking at the
    generated ruleset. For example, traffic going from the 'loc' zone
    to the 'dmz' zone may now be passing through a chain named

    To eliminate this confusion, the compiler now generates a
    synthetic name for the combined chains, consisting of "~comb"
    followed by an integer (e.g., "~comb1", "~comb2", etc.).
2011-06-05 Shorewall 4.4.21
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  All problems corrections included in Shorewall -
    (see below).

2)  The following error message

        FOREWARD_CLEAR_MARK=Yes requires MARK Target in your kernel
            and iptables

    has been corrected to read

        FORWARD_CLEAR_MARK=Yes requires MARK Target in your kernel
            and iptables

3)  The TPROXY target in the tcrules file could previously cause a
    failure during iptables restore like this:

       Running /usr/sbin/iptables-restore...
       Bad argument `3128'
       Error occurred at line: 110
       Try `iptables-restore -h' or 'iptables-restore --help' for more

          ERROR: iptables-restore Failed. Input is in

4)  The 'balance' and 'fallback' options in /etc/shorewall/providers
    have always been mutually exclusive but the compiler previously
    didn't enforce that restriction. Now it does.

5)  The Shorewall and Shorewall6 'load' and 'reload' commands
    previously used the setting of RSH_COMMAND and RCP_COMMAND from
    /etc/shorewall/shorewall.conf (/etc/shorewall6/shorewall6.conf).

    These commands now use the .conf file in the current working

6)  The ipset modules are now automatically loaded by Shorewall6 when
    LOAD_HELPERS_ONLY=No is specified in shorewall6.conf. Additionally,
    there is now a /usr/share/shorewall6/modules.ipset file that lists
    all of the required modules.

7)  TPROXY was previously not described in shorewall-tcrules(5) or
    shorewall6-tcrules(5). These descriptions have been added.

    In addition, Shorewall6 now correctly handles the third TPROXY
    parameter (<ip address>). Previously, the following error was

        ERROR: Invalid MARK (TPROXY(10,3128,::1)) :
               /etc/shorewall6/tcrules (line 4)

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  AUTOMAKE=Yes now causes all directories on the CONFIG_PATH to be
    searched for files newer than the script that last
    started/restarted the firewall. Previously, only /etc/shorewall
    (/etc/shorewall6) was searched.

2)  FORMAT-2 actions may now specify default parameter values using the
    DEFAULTS directive.

        DEFAULTS <def1>,<def2>,...

    Where <def1> is the default value for the first parameter, <def2>
    is the default value for the second parameter and so on. To specify
    an empty default, use '-'. Note that the corresponding parameter
    variable ($n) will still expand to '-' but will be treated as empty
    by the builtin actions such as dropInvalid.

    The DEFAULTS directive also determines the maximum number of
    parameters that an action may have. If more parameters are passed
    than have default values, an error message is issued.

3)  Parameterized macros may now specify a default parameter value
    using the DEFAULT directive.

        DEFAULT <default>

    Example macro.Foo -- by default, accepts connections on ficticous
                         tcp port 'foo'.

        PARAM   -       -       tcp     foo

4)  The standard Drop and Reject actions are now parameterized. Each 
    has 5 parameters:

    1) Pass 'audit' if you want all ACCEPTs, DROPs and REJECTs audited.
       Pass '-' otherwise.

    2) The action to be applied to Auth requests: 

              FIRST PARAMETER           DEFAULT
              -                         REJECT
              audit                     A_REJECT

    3) The action to be applied to SMB traffic. The default depends on
       the action and its first parameter:

              ACTION     FIRST PARAMETER                DEFAULT

              Reject     -                              REJECT
              Drop       -                              DROP
              Reject     audit                          A_REJECT
              Drop       audit                          A_DROP

    4)  The action to be applied to accepted ICMP packets.

              FIRST PARAMETER           DEFAULT

              -                         ACCEPT
              audit                     A_ACCEPT

    5)  The action to be applied to UPnP (udp port 1900) and late DNS
        replies (udp source port 53)

              FIRST PARAMETER           DEFAULT

              -                         DROP
              audit                     A_DROP

    The parameters can be passed in the POLICY column of the policy


        net     all     DROP:Drop(audit):audit  #Same as 

        net     all     DROP:Drop(-,DROP) #DROP rather than REJECT Auth

    The parameters can also be specified in shorewall.conf:



5)  An 'update' command has been added to /sbin/shorewall and
    /sbin/shorewall6. The command updates the shorewall.conf
    (shorewall6.conf) file then validates the configuration. The
    updated file will set any options not specified in the old file
    with their default values, and will move any deprecated options
    with non-default values to a 'deprecated options' section at the
    end of the file. Each such deprecated option will generate a
    warning message.

    Your original shorewall.conf (shorewall6.conf) file will be saved as
    shorewall.conf.bak (shorewall6.conf.bak).

    The 'update' command accepts the same options as the 'check'
    command plus a '-a' option that causes the updated file to be
    annotated with manpage documentation.

6)  Shorewall6 now supports ipsets. 

    Unlike iptables, which has separate configurations for IPv4 and
    IPv6, ipset has a single configuration that handles both. This
    means the SAVE_IPSETS=Yes in shorewall.conf or shorewall6.conf
    won't work correctly. To work around this issue, Shorewall-init is
    now capable restoring ipset contents during 'start' and saving them
    during 'stop'. 

    To direct Shorewall-init to save/restore ipset contents, set the
    SAVE_IPSETS option in /etc/sysconfig/shorewall-init
    (/etc/default/shorewall-init on Debian and derivatives). The value
    of the option is a file name where the contents of the ipsets will
    be saved to and restored from. Shorewall-init will create any
    parent directories during the first 'save' operation.

    If you configure Shorewall-init to save/restore ipsets, be sure to
    set SAVE_IPSETS=No in shorewall.conf and shorewall6.conf.

    As part of this change, Shorewall and Shorewall6 will only restore
    saved ipsets if SAVE_IPSETS=Yes in shorewall.conf

7)  Shorewall6 now supports dynamic zones:

    1) The nets=dynamic option is allowed in /etc/shorewall6/interfaces
    2) The HOSTS column of /etc/shorewall6/hosts may now contain
    3) /sbin/shorewall6 now supports the 'add' and 'delete' commands.
2011-06-05 Shorewall 4.4.20
      P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, when a device number was explicitly specified in
    /etc/shorewall/tcdevices, all unused numbers less than the one
    specified were unavailable for allocation to following entries that
    did not specify a number. Now, the compiler selects the lowest
    unallocated number when no device number is explicitly allocated.

2)  The obsolete PKTTYPE option has been removed from shorewall.conf
    and the associated manpage.

3)  The iptables 1.4.11 release produces an error when negative numbers
    are specified for IPMARK mask values. Shorewall now converts such
    numbers to their 32-bit hex equivalent.

4)  Previously, before /etc/shorewall6/params was processed, the
    IPv4 Shorewall libraries (/usr/share/shorewall/lib.*) were
    loaded rather that the IPv6 versions (/usr/share/shorewall6/lib.*).
    Now, the correct libraries are loaded.

5)  Shorewall now sets /proc/sys/net/bridge/bridge_nf_call_iptables or
    /proc/sys/net/bridge/bridge_nf_call_ip6tables when there are
    interfaces with the 'bridge' option. This insures that netfilter
    rules are invoked for bridged traffic. Previously, Shorewall was
    not setting these flags with the possible result that a
    bridge/firewall would not work properly.

6)  Problem corrections released in (see below)
    are also included in this release.

            K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The implementation of the environmental variables LIBEXEC and
    PERLLIB that was introduced in 4.4.19 has been changed
    slightly. The installers now allow absolute path names to be
    supplied in these variables so that the executables and/or Perl
    modules may be installed under a top-level directory other than
    /usr. The change is compatible with 4.4.19 in that if a relative
    path name is supplied, then '/usr/' is prepended to the supplied

2)  A new ACCOUNTING_TABLE option has been added to shorewall.conf and
    shorewall6.conf. The setting determines the Netfilter table (filter
    or mangle) where accounting rules are created.

    When ACCOUNTING_TABLE=mangle, the allowable accounting file
     sections are:


    Present sections must appear in that order.

3)  An NFLOG 'ACTION' has been added to the accounting file to allow
    sending matching packets (or the leading part of them) to backend
    accounting daemons via a netlink socket.

4)  A 'whitelist' option has been added to the blacklist file. When
    'whitelist' is specified, packets/connections matching the entry
    are not matched against the entries which follow. No logging of
    whitelisted packets/connections is performed.

5)  Support for the AUDIT target has been added. AUDIT is a feature of
    the 2.6.39 kernel and iptables 1.4.10 that allows security auditing
    of access decisions.

    The support involves the following:

    a)  A new "AUDIT Target" capability is added and is required for
        auditing support. To use AUDIT support with a capabilities
        file, that file must be generated using this or a later

        Use 'shorewall show capabilities' after installing this release
        to see if your kernel and iptables support the AUDIT target.

    b)  In /etc/shorewall/policy's POLICY column, the policy (and
        default action, if any) may be followed by ':audit' to cause
        applications of the policy to be audited. This means that any
        NEW connection that does not match any rule in the rules file
        or in the applicable 'default action' will be audited.

        Only ACCEPT, DROP and REJECT policies may be audited.


        #SOURCE DEST    POLICY          LOG
        #                               LEVEL
        net     fw      DROP:audit

        It is allowed to also specify a log level on audited policies
        resulting in both auditing and logging.

    c)  Three new builtin actions that may be used in the rules file,
        in macros and in other actions.

        A_ACCEPT - Audits and accepts the connection request
        A_DROP   - Audits and drops the connection request
        A_REJECT - Audits and rejects

        A log level may be supplied with these actions to
        provide both auditing and logging.


        A_ACCEPT:info   loc     net     ...

        TCP_FLAGS_DISPOSITION options may be set as follows:

                                      A_REJECT, unless

    e)  A SMURF_DISPOSITION option has been added to
        shorewall.conf. The default value is DROP; if the option is set
        to A_DROP, then dropped smurfs are audited.

    f)  An 'audit' option has been added to the
        /etc/shorewall/blacklist file which causes the packets matching
        the entry to be audited. 'audit' may not be specified together
        with 'whitelist'.

    g)  The builtin actions (dropBroadcast, rejNonSyn, etc.) now support
        an 'audit' parameter which causes all ACCEPT, DROP and REJECTs
        performed by the action to be audited.

        Note: The builtin actions are those actions listed in the
        output of 'shorewall show actions' with names that begin with a
        lower-case letter.


                #ACTION                 SOURCE          DEST
                rejNonSyn(audit)        net             all

    h)  There are audited versions of the standard Default Actions
        named A_Drop and A_Reject. Note that these audit everything
        that they do so you will probably want to make your own copies
        and modify them to only audit the packets that you care about. 

6)  Up to this release, the behaviors of 'start -f' and 'restart -f'
    has been inconsistent. The 'start -f' command  compares the
    modification times of /etc/shorewall[6] with
    /var/lib/shorewall[6]/restore while 'restart -f' compares with

    To make the two consistent, a new LEGACY_FASTSTART option has been
    added. The default value when the option isn't specified is
    LEGACY_FASTSTART=Yes which preserves the old behavior. When
    LEGACY_FASTSTART=No, 'start -f' and 'restart -f' both compare with

7)  A '-c' (compile) option has been added to the 'start' and 'restart'
    commands in both Shorewall and Shorewall6. It overrides the setting
    of AUTOMAKE and unconditionally forces a recompilation of the

    When both -c and -f are specified, the result is determined by the
    option that appears last.

8)  Shorewall and Shorewall6 no longer depend on 'make'.

9)  A '-T' (trace) option has been added to the 'check' and 'compile'
    commands. When a warning or error message is generated, a Perl
    stack trace is included to aid in isolating the source of the

10) The Shorewall and Shorewall6 configuration files (including the
    samples) may now be annotated with documentation from the associated

    The installers for these two packages support a -a (annotated)
    option that installs annotated versions of the packages. Both
    versions are available in the configfiles directory within the
    tarball and in the Sample directories.

11) The STATE subcolumn of the secmarks file now allows the values 'I'
    which will match packets in the INVALID state, and 'NI'
    which will match packets in either NEW or INVALID state.

12) Certain attacks can be best defended through use of one of these
    two measures.

    a)  rt_filter (Shorewall's routefilter). Only applicable to IPv4
        and can't be used with some multi-ISP configurations.

    b)  Insert a DROP rule that prevents hairpinning (routeback). The
        rule must be inserted before any ESTABLISHED,RELATED firewall
        rules. This approach is not appropriate for bridges and other
        cases, where the 'routeback' option is specified or implied.

    For non-routeback interfaces, Shorewall and Shorewall6 will now
    insert a hairpin rule, provided that the routefilter option is not
    specified. The rule will dispose of hairpins according to the
    setting of two new options in shorewall.conf and shorewall6.conf:

        Specifies the logging level; default is 'info'. To omit
        logging, specify FILTER_LOG_LEVEL=none.

        Specifies the disposition. Default is DROP and the possible
        values are DROP, A_DROP, REJECT and A_REJECT.

    To deal with bridges and other routeback interfaces , there is now
    an 'sfilter' option in /shorewall/interfaces and

    The value of the 'sfilter' option is a list of network addresses
    enclosed in in parentheses. Where only a single address is listed,
    the parentheses may be omitted. When a packet from a
    source-filtered address is received on the interface, it is
    disposed of based on the new SFILTER_ options described above.

   For a bridge or other routeback interface, you should list all of
    your other local networks (those networks not attached to the
    bridge) in the bridge's sfilter list.


        My DMZ is 2001:470:b:227::40/124

        My local interface (br1) is a bridge.

        In /etc/shorewall6/interfaces, I have:

        loc   br1       -         sfilter=2001:470:b:227::40/124
2011-04-12 Shorewall 4.4.19
      P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Corrected a problem in optimize level 4 that resulted in the
    following compile-time failure.

        Can't use an undefined value as an ARRAY reference at 
        /usr/share/shorewall/Shorewall/ line 862.

2)  If a DNAT or REDIRECT rule applied to a source zone with an
    interface defined with 'physical=+', then the nat table 'dnat'
    chain might have been created but not referenced. This prevented
    the DNAT or REDIRECT rule from working correctly.

3)  Previously, if a variable set in /etc/shorewall/params was given a
    value containing shell metacharacters, then the compiled script
    would contain syntax errors.

4)  The pathname of the 'conntrack' binary was erroneously printed in
    the output of 'shorewall6 show connections'.

5)  Correct a problem whereby incorrect Netfilter rules were generated
    when a bridge with ports was given a logical name.

6)  If a bridge interface had subordinate ports defined in
    /etc/shorewall/interface, then an ipsec entry (either ipsec zone or
    the 'ipsec' option specified) in /etc/shorewall/hosts resulted in
    the compiler generating an incorrect Netfilter configuration.

7)  Previously /var/log/shorewall*-init.log was created in the wrong
    Selinux context. The rpm's have been modified to correct that

8)  An issue with params processing on RHEL6 has been corrected. The
    problem manifested as the following type of warning:

       WARNING: Param line (export OLDPWD) ignored at 
                /usr/share/shorewall/Shorewall/ line 2993.

9)  A fatal error is now raised if '!0' appears in the PROTO column of
    files that have that column. This avoids an iptables-restore
    failure at run time.

            K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  When TC_ENABLED=Simple, ACK packets are now placed in the highest
    priority class. An ACK packet is a TCP packet with the ACK flag set
    and no data payload.

    Rationale: Entries in /etc/shorewall[6]/tcpri affect both incoming
    and outgoing connections. If a particular application, SMTP for
    example, is placed in priority class 3, then outgoing ACK packets
    for incoming email were previously placed in priority class 3 as
    well. This could have the effect of slowing down incoming mail when
    the goal was to give outgoing mail a lower priority. By
    unconditionally placing ACK packets in priority class 1, this issue
    is avoided.

2)  Up to this point, the Perl-based rules compiler has not accepted
    ICMP type lists. This is in contrast to the shell-based compiler
    which did support such lists. 

    Support for ICMP (and ICMPv6) type lists has now been restored.

3)  Distributions have different philosophies about the proper file
    hierarchy. Two issures are particularly contentious:

    - Executable files in /usr/share/shorewall*. These include;


    - Perl Modules in /usr/share/shorewall/Shorewall.

    To allow distributions to designate alternate locations for these
    files, the installers ( now support the following
    environmental variables:

    LIBEXEC -- determines where in /usr getparams,,
    wait4ifup, shorecap and ifupdown are installed. Shorewall and
    Shorewall6 must be installed with the same value of LIBEXEC. The
    listed executables are installed in /usr/${LIBEXEC}/shorewall*. The
    default value of LIBEXEC is 'share'. LIBEXEC is recognized by all
    installers and uninstallers.

    PERLLIB -- determines where in /usr the Shorewall perl modules are
    installed. Shorewall and Shorewall6 must be installed with the same
    value of PERLLIB. The modules are installed in
    /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is
    'share/shorewall'. PERLLIB is only recognized by the Shorewall and
    Shorewall6 installers and the same value must be passed to both

4)  Bridge/ports handling has been significantly improved, resulting in
    packets to/from bridges traversing fewer rules.

5)  A list of protocols is now permitted in the PROTO column of the
    rules file.

6)  The contents of the Netfilter mangle table are now included in the
    output from 'shorewall show tc'.

7)  Simple traffic shaping can now have a common configuration between
    IPv4 and IPv6. To do that:

    - Set TC_ENABLED=Simple in both /etc/shorewall/shorewall.conf and
    - Configure /etc/shorewall/tcinterfaces.
    - Leave /etc/shorewall6/tcinterfaces empty.
    - Configure /etc/shorewall/tcpri (if desired)
    - Configure /etc/shorewall6/tcpri (if desired)

    It should be noted that when IPv6 packets are encapsulated for
    transmission by 6to4/6in4, they retain their marks.   
2011-03-10 Shorewall 4.4.18
      P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

4.4.18 Final

1)  Previously, if an IPv6 host address (no "/<vlsm>") was used in a
    context where a network address is allowed, the compiler failed to
    supply the default <vlsm> of 128. This could lead to startup errors
    and/or Perl errors such as:

           Use of uninitialized value $mask in concatenation (.) or
           string at /usr/share/shorewall/Shorewall/ line 979,
           <$currentfile> line 11.

2)  The <burst> option for the IN-BANDWIDTH column of tcdevices was
    previously not recognized. That functionality has been restored.

3)  If an interface mentioned in the tcfilters file was not up when
    Shorewall was started or restarted, then the command would fail
    at run-time with a 'tc' error message.

4.4.18 RC 1

1)  None.

4.4.18 Beta 4

1)  Edting of the MARK column has been tighened to catch errors at
    compile time rather than at run time.

2)  The MODULE_SUFFIX default has been changed to "ko ko.gz o o.gz gz"
    to get the most common suffixes at the front of the list. It is
    still recommended that you modify this setting to include only the
    suffix(es) used on your system. Current distributions use 'ko'
    almost exclusively.

4.4.18 Beta 2

1)  Previously, the 'local' option in /etc/shorewall6/providers would
    produce an 'ip route add' command containing an IPv4 address. It now
    correctly uses the equivalent IPv6 address. Note that this option
    is still undocumented for use with IPv6.

2)  When optimize level 4 was set, the optimizer mis-handled rules of the

        -A <chain1> -j <chain2> -m comment ...

    when such a rule was the only rule in a chain.

4.4.18 Beta 1


            K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The modules files are now just a driver that INCLUDEs several new
    files and one old file:

    - /usr/share/shorewall[6]/modules.essential  # Essential modules
    - /usr/share/shorewall[6]/modules.xtables    # xt_ modules
    - /usr/share/shorewall[6]/helpers            # Existing file
    - /usr/share/shorewall/ipset                 # ipset modules
    - /usr/share/shorewall[6]/         # Traffic Shaping
    - /usr/share/shorewall[6]/modules.extensions # Other extensions

    This should make it easier to configure your own
    /etc/shorewall[6]/modules file that won't be obsolete when you
    upgrade your Shorewall/Shorewall6 installation.

    For example, if you don't use traffic shaping or ipsets, you can
    remove those from your copy of the modules file (copy in

2)  Traditionally, the root of the Shorewall accounting rules has been
    the 'accounting' chain. Having a single root chain has drawbacks:

    - Many rules are traversed needlessly (they could not possibly
      match traffic).
    - At any time, the Netfilter team could begin generating errors
      when loading those same rules.
    - MAC addresses may not be used in the accounting rules.
    - The 'accounting' chain cannot be optimized when

    In addition, currently the rules may be defined in any order so the
    rules compiler must post-process the ruleset to alert the user to
    unreferenced chains.

    Beginning with Shorewall 4.4.18, the accounting structure can be
    created with three root chains:

    - accountin:  Rules that are valid in the INPUT chain (may not
      specify an output interface). 
    - accountout: Rules that are valid in the OUTPUT chain (may not
      specify an input interface or a MAC address).
    - accountfwd: Other rules.

    The new structure is enabled by sectioning the accounting file in a
    manner similar to the rules file.  

    The sections are INPUT, OUTPUT and FORWARD and must appear in that
    order (although any of them may be omitted). The first
    non-commentary record in the accounting file must be a section
    header when sectioning is used.

    When sections are enabled:

    - You must jump to a user-defined accounting chain before you can
      add rules to that chain. This eliminates the possibility of
      unreferenced chains.
    - You may not specify an output interface in the INPUT section.
    - In the OUTPUT section:
      - You may not specify an input interface
      - You may not jump to a chain defined in the INPUT section that
        specifies an input interface
      - You may not specify a MAC address
      - You may not jump to a chain defined in the INPUT section that
        specifies specifies a MAC address.
    - The default value of the CHAIN column is:
      - 'accountin' in the INPUT section
      - 'accountout' in the OUTPUT section
      - 'accountfwd' in the FORWARD section
    - Traffic addressed to the firewall goes through the rules defined
      in the INPUT section.
    - Traffic originating on the firewall goes through the rules
      defined in the OUTPUT section.
    - Traffic being forwarded through the firewall goes through the
      rules defined in the FORWARD section.

    As part of this change, the USER/GROUP column must now be empty
    except in the OUTPUT section. This is consistent with recent
    Netfilter releases which disallow the owner match in rules
    reachable from the INPUT and FORWARD hooks.

3)  Internals Change: The module has been merged into the module
2011-02-10 Shorewall 4.4.17
P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, Shorewall did not check the length of the names of
    accounting chains and manual chains. This could result in 
    errors when loading the resulting ruleset. Now, the compiler issues
    an error for chain names longer than 29 characters.

    Additionally, the compiler now ensures that these chain names are
    composed only of letters, digits, underscores ('_') and dashes
    ("-"). This eliminates Perl runtime errors or other failures when a
    chain name is embedded within a regular expression.

2)  Several issues with complex traffic shaping have been resolved:

    a) Specifying IPv6 network addresses in the SOURCE or DEST columns
       of /etc/shorewall6/tcfilters now works correctly. Previously,
       Perl runtime warnings occurred and an invalid tc command was

    b) Previously, if flow= was specified on a parent class, a perl
       runtime warning occurred and an invalid tc command was
       generated. This combination is now flagged as an error at
       compile time.

    c) There is now an ipv6 tcfilters skeleton included with

3)  Several issues with accounting are corrected.

    a)  If an accounting rule of the form:

    	   chain1		 chain2

	was configured and neither chain was referenced again in the
	configuration, then an internal error was generated when
	optimize level 4 was selected and OPTIMIZE_ACCOUNTING=Yes.

    b)  If there was only a single accounting rule and that rule
    	specified an interface in the SOURCE or DEST columns, then the
    	generated ruleset would fail to load when

    c)  If a per-IP accounting table name appeared in more than one
    	rule and the specified network was not the same in all
    	occurrences, then the generated ruleset would fail to load.

	This is now flagged as an error at compile time.

4)  Two defects in compiler module loading have been corrected:

    a) Previously, the kernel/net/ipv6/netfilter/ directory was not
    b) A Perl diagnostic was issued when running on a monolithic kernel
       when the modutils package was installed.

5)  A line containing only 'INCLUDE' appearing in an extension script
    now generates a compile-time diagnostic rather than a run-time

6)  Previously, the scripts used insserv (if installed) on
    Debian-based systems. These scripts now use the preferred tool

7)  Beginning with 4.4.16, compilation would fail if an empty shell
    variable was referenced in a config file on a system where /bin/sh
    is the Bourne Again Shell (bash).

8)  In earlier versions. if OPTIMIZE=8 then the ruleset displayed by
    'check -r' was the same as when OPTIMIZE=0
    (unoptimized). Similarly, if OPTIMIZE=9 then the ruleset displayed
    was the same as when OPTIMIZE=1.

9)  Startup could previously fail on a system where kernel module
    autoloading was not available and where TC_ENABLED=Simple was
    specified in shorewall.conf or shorewall6.conf.

10) Previously, a 'done.' message could be printed at the end of
    command processing even when the command had failed. Now, such a
    message only appears if the command completed successfully.

K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  This release adds support for per-IP accounting using the ACCOUNT
    target. That target is only available when xtables-addons is
    installed. This support has been successfully tested with
    xtables-addons 1.32 on:

    - Fedora 14
    - Debian Squeeze
    - OpenSuSE 11.3

    It has also been tested with xtables-addons 1.21 on:

    - Debian Lenny

    Information about xtables-addons installation may be found at

    This feature required addition of the "ACCOUNT Target" capability
    so if you use a capabilities file, you will want to refresh it
    after installing this release.

    Per-IP accounting is configured in /etc/shorewall/accounting (it is
    not currently supported in IPv6). In the ACTION column, enter:



       <table> is the name of an accounting table (you choose the
       	       name). Rules specifying the same table will have their
       	       per-IP counters accumulated in that table.

       <network> is an IPv4 in CIDR format. May be as large as a /8.

    Example: Suppose your WAN interface is eth0 and your LAN interface
    	     is eth1 with network To account for all
    	     traffic between the WAN and LAN interfaces:

	#ACTION                        TABLE     SOURCE        DEST ...
	ACCOUNT(net-loc, -         eth0          eth1
	ACCOUNT(net-loc, -         eth0          eth1

    This will create a net-loc table for counting packets and
    bytes for traffic between the two interfaces. The table is dumped
    using the iptaccount utility:

    	iptaccount [-f] -l net-loc

    Example (output folded):

	gateway:~# iptaccount -l loc-net

	libxt_ACCOUNT_cl userspace accounting tool v1.3

	Showing table: loc-net
	Run #0 - 3 items found
	IP: SRC packets: 115 bytes: 131107
                         DST packets: 68 bytes: 20045
	IP: SRC packets: 47 bytes: 12729
                         DST packets: 38 bytes: 25304
	IP: SRC packets: 20747 bytes: 2779676
                         DST packets: 27050 bytes: 32286071
    For each local IP address with non-zero counters, the packet and
    byte count for both incoming traffic (IP is DST) and outgoing
    traffic (IP is SRC) are listed. The -f option causes the table to
    be flushed (reset all counters to zero).

    For a command synopsis, type:

    	iptaccount --help 

    One nice feature of per-IP accounting is that the counters survive
    'shorewall restart'. This has a downside, however. If you change
    the <network> associated with an accounting table, then you must
    "shorewall stop; shorewall start" to have a successful restart
    (counters will be cleared).

2)  A 'show ipa' command has been added to /sbin/shorewall. It
    displays each per-IP accounting table.  

3)  Traditionally, the -lite products have used the modules (or
    helpers) file on the firewall system unless there is a modules (or
    helpers) file in the configuration directory on the administrative
    system. This release introduces the USE_LOCAL_MODULES option in

    When USE_LOCAL_MODULES=Yes, the modules (helpers) file on the
    administrative system will be used to determine the set of modules
    loaded. This also implies that the modules (helpers) file will be
    read at compile time rather than at run-time when using Shorewall
    and Shorewall6 directly on a firewall system.

    As part of this change, the modules and helpers files are now
    secured for read access by non-root users.

4)  Given that shell variables are expanded at compile time, there was
    previously no way to cause such variables to be expanded at run
    time. This made it difficult (to impossible) to include dynamic IP
    addresses in a Shorewall-lite configuration.

    This release implements "Run-time address variables". In
    configuration files, these variables are expressed using an
    apersand ('&') followed by the name of an interface defined in
    /etc/shorewall/interfaces. Wild-card interfaces (those whose names
    end in '+') are not allowed to be used in this way.

    	     &eth0 would represent the primary IP address of eth0.

    Run-time address variables may be used in the SOURCE and DEST
    column of the following configuration files:

	   action files
	   macro files

    They may also appear in the ORIGINAL DEST column of

    	   action files
	   macro files

    They may also be used in the SOURCE and ADDRESS columns of the masq

    For optional interfaces, if the interface is not usable at the time
    that the firewall starts, the resulting Netfilter rule(s)
    containing the interface address are not added.

5)  The shell variables set in /etc/shorewall/params
    (/etc/shorewall6/params) are now available in the compiled script
    at run-time with EXPORTPARAMS=No. The EXPORTPARAMS option is now
    deprecated and the released /etc/shorewall/shorewall.conf and
    /etc/shorewall/shorewall6.conf have been modified to specify

6)  The INCLUDE directive may now be used in the following extension


    The directive is executed during compilation so that the INCLUDEd
    file(s) is(are) copied into the generated script. This same
    technique is also now used for INCLUDE directives in the params
    file when EXPORTPARAMS=Yes. Previously, INCLUDE directives in that
    file were strongly discouraged with EXPORTPARAMS=Yes because the
    INCLUDE was performed on the firewall system rather than on the
    administrative system.
2010-12-01 Shorewall 4.4.16
 P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  If the output of 'env' contained a multi-line value, then
    compilation failed with an Internal Error. The code has been
    changed so that the compiler now handles multi-line values

2)  In 4.4.15, output to Standard Out (FD 1) generated by
    /etc/shorewall/params (/etc/shorewall6/params) was redirected to
    /dev/null. It is now redirected to Standard Error (FD 2).

3)  If a params file did not appear in the CONFIG_PATH, compilation
    failed with the error:

           .: 31: Can't open /etc/shorewall6/params 
           ERROR: Processing of /etc/shorewall6/params failed

4)  Compilation no longer fails when /bin/sh is an older (e.g.,
    RHEL5.x) bash.

5)  Previously, proxy ARP with logical interface names did not
    work. Symptoms included numerous Perl runtime error messages. 

6)  Previously, the root of a wildcard name erroneously matched that
    name. For example 'eth' matched 'eth+'. Now there must be at least
    one additional character (e.g., 'eth5').

7)  Use of logical interface names in the notrack and ecn files
    resulted in perl runtime warning messages.

8)  The use of wildcard-matching names in certain contexts would result
    in anomalous behavior. Among the symptoms were:

     - Perl run-time messages similar to this one:

       Use of uninitialized value in numeric comparison (<=>) 
       at /usr/share/shorewall/Shorewall/ line 1334.

     - Failure to treat the interface as optional or required.

9)  Where two ISPs share the same interface, if one of the ISPs was not
    reachable, an iptables-restore error such as this occurred:

      iptables-restore v1.4.10: Bad mac address "-j"

10) Previously, under very rare circumstances, a chain would be
    optimized away while there were still jumps to the chain. This caused
    Shorewall start/restart to fail during iptables-restore.

11) Previously, the setting of BLACKLIST_DISPOSITION was not
    validated. Now, an error is raised unless the value is DROP or REJECT.

K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Shorewall-init now handles ppp devices.

2)  To support proxy NDP in a manner similar to Proxy ARP, an
    /etc/shorewall6/proxyndp file has been added. It should be noted
    that IPv6 implements a "strong host model" whereas Linux IPv4
    implements a "weak host model". In the strong model, IP addresses
    are associated with interfaces; in the weak model, they are
    associated with the host. This is relevant with respect to Proxy
    NDP in that a multi-homed Linux IPv6 host will only respond to
    neighbor discoverey requests for IPv6 addresses configured on the
    interface receiving the request. So if eth0 has address
    2001:470:b:227::44/128 and eth1 has address 2001:470:b:227::1/64
    then in order for eth1 to respond to neighbor discovery requests
    for 2001:470:b:227::44, the following entry in
    /etc/shorewall6/proxyndp is required:

    2001:470:b:227::44 -            eth1        Yes

    As part of this change, the INTERFACE column in
    /etc/shorewall/proxyarp is now optional and is only required when
    HAVEROUTE=No (the default).

3)  Shorewall 4.4.16 introduces format-2 Actions. Based on the similar
    feature of macros, format-2 actions allow the same column layout
    for macros, actions and rules.

    In the file, simply make the first non-commentary line:

       FORMAT 2

    This allows the lines which follow to have the same columns as
    those in the rules file.

    As part of this change, the earlier kludgy restrictions regarding
    Macros and Actions have been eliminated. For example, DNAT, DNAT-,
    REDIRECT, REDIRECT- and ACCEPT+ rules are now allowed in Actions
    and in macros invoked from Actions. Additionally, Macros used in
    Actions are now free to invoke other actions.

4)  Action processing has been largely re-implemented in this release.
    The prior implementation contained a lot of duplicated code which
    made maintainance difficult. The old implementation pre-processed
    all action files early in the compilation process and then
    post-processed the ones that had been actionally used after the
    rules file had been read. The new algorithm generates the chain for
    each unique action invocation at the time that the invocation is
    encountered in the rules file.

    Consideration was given to eliminating the
    /usr/share/shorewall/actions.std and /etc/shorewall/actions files,
    since it is possible to discover actions "on the fly" in the same
    way as macros are discovered. That change was ultimately rejected
    because it could cause migration issues for users with macros and
    actions with the same name (e.g., and If a
    new major release of Shorewall (e.g., 4.6) is created, that change
    will be reconsidered for inclusion at that time.

    Action names are now verified to be composed of alphanumeric
    characters, '_' and '-'.

    There is now support for parameterized actions. The parameters are
    a comma-separated list enclosed in parentheses following the
    action name (e.g., ACT(REDIRECT, Within the action
    body, the parameter values are available in $1, $2, etc.

    You can 'omit' a parameter in the list by using '-' (e,g,
    REDIRECT, would omit the second parameter (within the action
    body, $2 would expand to nothing). If you want to specify '-' as a
    parameter value, use '--'.
    Parameter values are also available to extensions scripts. See for more
2010-12-01 Shorewall 4.4.15
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, if 

    a) syn flood protection was enabled in a policy that
       specified 'all' for the SOURCE or DEST, and
    b) there was only one pair of zones matching that policy, and
    c) PROPAGATE_POLICIES=Yes in shorewall.conf, and
    d) logging was specified on the policy

    then the chain implementing the chain had "all" in its name while
    the logging rule did not.


        On a simple standalone configuration, /etc/shorewall/policy

             #SOURCE    DEST    POLICY  LOGGING
             net        all     DROP    info

        then the chain implementing syn flood protection would be named
        @net2all while the logging rule would indicate net2fw.

    Now, the chain will be named @net2fw.

2)  If the current environment exported the VERBOSE variable with a
    non-zero value, then startup would fail.

3)  If a route existed for an entire RFC1918 subnet (, or, then setting
    NULL_ROUTE_RFC1918=Yes would cause the route to be replaced with an
    'unreachable' one.

4)  Shorewall6 failed to start correctly if all the following were true:

    - Shorewall was installed using the tarball. It may have
      subsequently been installed using a distribution-specific package
      or the rpm from without first unstalling the
      tarball components.

    - Shorewall6 was installed using a distribution-specific package or
      the rpm from

    - The file /etc/shorewall6/init was not created.

5)  If an interface with physical='+' is given the 'optional' or
    'required' option, then invalid shell variables names were
    generated by the compiler.

6)  The contributed macro macro.JAP generated a fatal error when used.
    The root cause was a defect in parameter processing in nested
    macros (if 'PARAM' was passed to an nested macro invocation, it was
    not expanded to the current parameter value).

7)  Previously, if find_first_interface_address() failed when running
    shorewall-lite or shoreawll6-lite, the following unhelpful message
    was issued:

        /usr/share/shorewall-lite/lib.common: line 449: startup_error: command
                                              not found

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)   Munin and Squid macros have been contributed by Tuomo Soini.

2)   The Shorewall6 accounting, tcrules and rules files now include a
     HEADERS column which allows matching based on the IPv6 extension and
     protocol headers included in a packet.

     The contents of the column are:

         [any:|exactly:]<header list>

     where <header list> is a comma-separated list of headers from the

        Long Name       Short Name      Number
        auth            ah              51
        esp             esp             50
        hop-by-hop      hop             0
        route           ipv6-route      41
        frag            ipv6-frag       44
        none            ipv6-nonxt      59      
        protocol        proto           255

     If 'any:' is specified, the rule will match if any of the listed
     headers are present. If 'exactly:' is specified, the will match
     packets that exactly include all specified headers. If neither is
     given, 'any:' is assumed.

     This change adds a new capability (Header Match) so if you use a
     capabilities file, you will need to regenerate using this release.

3)  It is now possible to add explicit routes to individual provider
    routing tables using the /etc/shorewall/routes (/etc/shorewall6/routes)

    See the shorewall-routes (5) and/or the shorewall6-routes (5)  manpage.

4)  Previously, /usr/share/shorewall/ expected the contents
    of the params file to be passed in the environment. Now, the
    compiler invokes a small shell program
    (/usr/share/shorewall/getparams) to process the file and to pass
    the (variable,value) pairs back to the compiler.

    Shell variable expansion uses the value from the params file if the
    parameter was set in that file. Otherwise the current environment
    is used. If the variable does not appear in either place, an error
    message is generated.

5)  Shared IPv4/IPv6 traffic shaping configuraiton is now
    available. The device and class configuration can be included in
    either the Shorewall or the Shorewall6 configuration. To place it
    in the Shorewall configuration:

    a) Set TC_ENABLED=Internal in shorewall.conf
    b) Set TC_ENABLED=Shared in shorewall6.conf
    c) Create symbolic link /etc/shorewall6/tcdevices pointing to
    d) Create symbolic link /etc/shorewall6/tcclasses pointing to
    e) Entries for both IPv4 and IPv6 can be included in
       /etc/shorewall/tcfilters. This file has been extended to allow
       both IPv4 and IPv6 entries to be included in a single file.
    f) Packet marking rules are included in both configurations'
       tcrules file as needed. CLASSIFY rules in
       /etc/shorewall6/tcrules are validated against the Shorewall TC
    In this setup, the tcdevices and tcclasses will only be updated
    when Shorewall is restarted. The IPv6 marking rules are updated
    when Shorewall6 is restarted.

    The above configuration may be reversed to allow Shorewall6 to
    control the TC configuration.
2010-10-28 Shorewall 4.4.14
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, messages to the STARTUP_LOG had inconsistent date formats.

2)  The blacklisting change in 4.4.13 was broken in some simple
    configurations with the effect that blacklisting was not enabled.

3)  Previously, Shorewall6 produced an untidy sequence of error
    messages when an attempt was made to start it on a system running a
    kernel older than 2.6.24:

       [root@localhost shorewall6]# shorewall6 start
       Processing /etc/shorewall6/shorewall6.conf...
       Loading Modules...
       Compiling /etc/shorewall6/zones...
       Shorewall configuration compiled to /var/lib/shorewall6/.start
          ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
       /usr/share/shorewall6/lib.common: line 73:
             [: -lt: unary operator expected
          ERROR: Shorewall6 requires Linux kernel 2.6.24 or later
       [root@localhost shorewall6]#

    This has been corrected so that a single ERROR message is

4)  Previously, an ipset name appearing in the /etc/shorewall/hosts
    file could be qualified with a list of 'src' and/or 'dst' enclosed
    in quotes. This was virtually guaranteed not to work since the set
    must match when used to verify both a packet source and a
    packet destination. Now, the following error is raised:

    	   ERROR: ipset name qualification is disallowed in this file

    As part of this change, the ipset name is now verified to begin
    with a letter and be composed of letters, digits, underscores ("_")
    and hyphens ("-").

5)  The Shorewall-lite and Shorewall6-lite Debian init scripts contained a
    syntax error.

6)  If the -v or -q options were used in /sbin/shorewall-lite or
    /sbin/shorewall6-lite commands that involve the compiled firewall
    script and the resulting effective VERBOSITY was > 2 or < -1, then
    the command would fail.

7)  The log reading commands (show log, logwatch, and dump) returned no
    log records when run on one of the -lite products.

8)  To avoid future confusion, the following obsolete options have been
    deleted from the sample shorewall.conf files:


    They will still be recognized by the rules compiler.

9)  All sample .conf files have been changed to specify


    rather than


    That way, systems without MARK support will still be able to
    install the sample configurations and FORWARD_CLEAR_MARK will
    default to Yes on systems with MARK support.

10) The install scripts in the tarballs now correctly create init
    symlinks on recent Ubuntu releases.

11) Previously, this entry in the OPTIONS column of
    /etc/shorewall/interfaces incorrectly generated a syntax error.


    The error was:

    	ERROR: Invalid VLSM (24))

12) Previously, if 10 or more interfaces were configured in Complex
    Traffic Shaping (/etc/shorewall/tcdevices), the following
    compilation diagnostic was generated:

        Argument "a" isn't numeric in sprintf at
	/usr/share/shorewall/Shorewall/ line 893.
    and an invalid TC configuration was generated.

13) If the current environment exported the VERBOSITY variable with a
    non-zero value, startup would fail.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably secure
    the firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Multiple source or destination ipset matches can be generated by
    enclosing the ipset list in +[...].

    Example (/etc/shorewall/rules):

        ACCEPT $FW net:+[dest-ip-map,dest-port-map]

2)  Shorewall now uses the 'conntrack' utility for 'show connections'
    if that utility is installed. Going forward, the Netfilter team
    will be enhancing this interface rather than the /proc interface.

3)  The CPU time required for optimization has been reduced by 2/3.

4)  An 'scfilter' extension script has been added. This extension
    script differs from other such scripts in that it is invoked by the
    command line tools (/sbin/shorewall, /sbin/shorewall6,
    /sbin/shorewall-lite and /sbin/shorewall6-lite).

    The script acts as a filter for the output of the 'show
    connections' command. Each connection is piped through the filter
    which can modify and/or drop information as desired.


 	sed 's/secmark=0 //'

    That script will remove 'secmark=0 ' from each line.

    The default script is:

	cat -

    which passes the output through unmodified.

    If you are using Shorewall-lite and/or Shorewall6-lite, the
    scfilter file is kept on the administrative system. The compiler
    encapsulates the script into a shell function that is copied
    into the generated auxillary configuration file
    (firewall.conf). That function is then invoked by the 'show
    connections' command.
2010-09-21 Shorewall 4.4.13
  I.  P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Under rare circumstances where COMMENT is used to attach comments
    to rules, OPTIMIZE 8 through 15 could result in invalid
    iptables-restore (ip6tables-restore) input.

2)  Under rare circumstances involving exclusion, OPTIMIZE 8 through 15
    could result in invalid iptables-restore (ip6tables-restore) input.

3)  The change in 4.4.12 to detect and use the new ipset match syntax
    broke the ability to detect the old ipset match capability. Now,
    both versions of the capability can be correctly detected.

4)  Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail
    if the last optional interface tested was not available.

5)  Exclusion in the blacklist file was correctly validated but was then
    ignored when generating iptables (ip6tables) rules.

6)  Previously, non-trivial exclusion (more than one excluded
    address/net) in CONTINUE, NONAT and ACCEPT+ rules generated
    valid but incorrect iptables input. This has been corrected but
    requires that your iptables/kernel support marking rules in any
    Netfilter table (CONTINUE in the tcrules file does not require this

    This fix implements a new 'Mark in any table' capability; those
    who utilize a capabilities file should re-generate the file using
    this release.

7)  Interface handling has been extensively modified in this release
    to correct a number of problems with the earlier
    implementation. Among those problems:

    - Invalid shell variable names could be generated in the firewall
      script. The generated firewall script uses shell variables to
      track the availability of optional and required interfaces and
      to record detected gateways, detected addresses, etc.

    - The same shell variable name could be generated by two different
      interface names.

    - Entries in the interfaces file with a wildcard physical name
      (physical name ends with "+") and with the 'optional' option were
      handled strangely.

      o If there were references to specific interfaces that matched
        the wildcard, those entries were handled as if they had been
        defined as optional in the interfaces file.

      o If there were no references matching the wildcard, then the
        'optional' option was effectively ignored. 

    The new implementation:

    - Insures valid shell variable names.
    - Insures that shell variable names are unique.

    - Handles interface names appearing in the INTERFACE column of the
      providers file as a special case for 'optional'. If the name
      matches a wildcard entry in the interfaces file then the
      usability of the specific interface is tracked individually. 

    - Handles the availabilty of other interfaces matching a wildcard
      as a group; if there is one useable interface in the group then
      the wildcard itself is considered usable.

      The following example illustrates this use case:


        net     ppp+    -       optional



      If there is any usable PPP interface then the firewall will be
      allowed to start. Previously, the firewall would never be allowed
      to start.

8)  When a comma-separated list of 'src' and/or 'dst' was specified in
    an ipset invocation (e.g., "+fooset[src,src]), all but the first 'src'
    or 'dst' was previously ignored when generating the resulting
    iptables rule.

9)  Beginning with Shorewall 4.4.9, the SAME target in tcrules has
    generated invalid iptables (ip6tables) input. That target now
    generates correct input.

10) Ipsets associated with 'dynamic' zones were being created during
    'restart' but not during 'start'.

11) To work around an issue in Netfilter/iptables, Shorewall now uses
    state match rather than conntrack match for UNTRACKED state

12) If the routestopped files contains NOTRACK rules, 'shorewall* clear' 
    did not clear the raw table.

13) An error message was incorrectly generated if a port range of the
    form :<port> (e.g., :22) appeared.

14) An error is now generated if '*' appears in an interface name.

           I I.  K N O W N   P R O B L E M S   R E M A I N I N G

1)  On systems running Upstart, shorewall-init cannot reliably start the
    firewall before interfaces are brought up.

      I I I.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Entries in the rules file (both Shorewall and Shorewall6) may now
    contain zone lists in the SOURCE and DEST column. A zone list is a
    comma-separated list of zone names where each name appears in the
    zones file. A zone list may be optionally followed by a plus sign
    ("+") to indicate that the rule should apply to intra-zone traffic
    as well as to inter-zone traffic.

    Zone lists behave like 'all' and 'any' with respect to Optimization
    1. If the rule matches the applicable policy for a given (source
    zone, dest zone), then the rule will be suppessed for that pair of
    zones unless overridden by the '!' suffix on the target in the
    ACTION column (e.g., ACCEPT!, DROP!:info, etc.).

    Additionally, 'any', 'all' and zone lists may be qualified in the
    same way as a single zone.


    The 'all' and 'any' keywords now support exclusion in the form of a
    comma-separated list of excluded zones.


             all!fw         (same as all-).
             any+!dmz,loc   (All zones except 'dmz' and 'loc' and
                             include intra-zone rules).

2)  An IPSEC column has been added to the accounting file, allowing you
    to segregate IPSEC traffic from non-IPSEC traffic. See 'man
    shorewall-accounting' (man shorewall6-accounting) for details.

    With this change, there are now three trees of accounting chains:

    - The one rooted in the 'accounting' chain.
    - The one rooted in the 'accipsecin' chain. This tree handles
      traffic that has been decrypted on the firewall. Rules in this
      tree cannot specify an interface name in the DEST column.
    - The one rooted in the 'accipsecout' chain. This tree handles
      traffic that will be encrypted on the firewall. Rules in this
      tree cannot specify an interface name in the SOURCE column.

    In reality, when there are bridges defined in the configuration,
    there is a fourth tree rooted in the 'accountout' chain. That chain
    handles traffic that originates on the firewall (both IPSEC and

    This change also implements a couple of new warnings:

    - WARNING: Adding rule to unreferenced accounting chain <name>

      The first reference to user-defined accounting chain <name> is
      not a JUMP or COUNT from an already-defined chain.

    - WARNING: Accounting chain <name> has o references

      The named chain contains accounting rules but no JUMP or COUNT
      specifies that chain as the target.

3)  Shorewall now supports the SECMARK and CONNSECMARK targets for
    manipulating the SELinux context of packets.

    See the shorewall-secmarks and shorewall6-secmarks manpages for

    As part of this change, the tcrules file now accepts $FW in the
    DEST column for marking packets in the INPUT chain.

4)  Blacklisting has undergone considerable change in Shorewall 4.4.13.

    a) Blacklisting is now based on zones rather than on interfaces and
       host groups.

    b) Near compatibility with earlier releases is maintained.

    c) The keywords 'src' and 'dst' are now preferred in the OPTIONS
       column in /etc/shoreawll/blacklist, replacing 'from' and 'to'
       respectively. The old keywords are still supported.

    d) The 'blacklist' keyword may now appear in the OPTIONS,
       IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones.

       i)  In the IN_OPTIONS column, it indicates that packets received
           on the interface are checked against the 'src' entries in

       ii) In the OUT_OPTIONS column, it indicates that packets being
           sent to the interface are checked against the 'dst' entries.

       iii) Placing 'blacklist' in the OPTIONS column is equivalent to
           placing in in both the IN_OPTIONS and OUT_OPTIONS columns.

    e) The 'blacklist' option in the OPTIONS column of
       /etc/shorewall/interfaces or /etc/shorewall/hosts is now
       equivalent to placing it in the IN_OPTIONS column of the
       associates record in /etc/shorewall/zones. If no zone is given
       in the ZONE column of /etc/shorewall/interfaces, the 'blacklist'
       option is ignored with a warning (it was previously ignored

    f) The 'blacklist' option in the /etc/shorewall/interfaces and
       /etc/shorewall/hosts files is now deprecated but will continue
       to be supported for several releases. A warning will be added at
       least one release before support is removed.

5)  There is now an OUT-BANDWIDTH column in

    The format of this column is:


    These terms are described in tc-tbf(8). Shorewall supplies default
    values as follows:

           <burst>   = 10kb
           <latency> = 200ms

    The remaining options are defaulted by tc.

6)  The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
    /etc/shorewall/tcinterfaces now accepts an optional burst parameter.


    The default <burst> is 10kb. A larger <burst> can help make the
    <rate> more accurate; often for fast lines, the enforced rate is
    well below the specified <rate>.
2010-08-20 Shorewall 4.4.12
     P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Previously, the Shorewall6-lite version of shorecap was using
    iptables rather than ip6tables, with the result that many capabilities
    that are only available in IPv4 were being reported as available.

2)  In a number of cases, Shorewall6 generated incorrect rules
    involving the IPv6 multicast network. The rules specified
    ff00::/10 where they should have specified ff00::/8. Also, rules
    instantiated when the firewall was stopped used ff80::/10 rather
    than fe80::/10 (IPv6 Link Local network).

3)  Previously, using a destination port-range with :random produced a
    fatal compilation error in REDIRECT rules.

4)  A number of problems associated with Shorewall-init and Upstart
    have been corrected. 

    If you use Shorewall-init, then when upgrading to this version, be
    sure to recompile all firewall scripts before you take interfaces
    down or reboot.

5)  Previously, the Shorewall installer ( failed to install
    /usr/share/shorewall/configfiles/Makefile and rather issued the
    following message:

              install-file: command not found 

    This caused the Makefile to be omitted from RPMs as well.

6)  When 'any' was used in the SOURCE column, a duplicate rule was
    generated in all "fw2*" ("fw-* if ZONE2ZONE="-"). If 'any' was used
    in the DEST column, then a duplicate rule appeared in all "*2fw"
    (*-fw) chains.

7)  A port range that omitted the first port number (e.g., ":80") was
    rejected with the following error:

         ERROR: Invalid/Unknown tcp port/service (0) : ......

8)  AUTOMAKE=Yes has been broken for some time. It is now working

           N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Support has been added for ADD and DEL rules in
    /etc/shorewall/rules. ADD allows either the SOURCE or DESTINATION
    IP address to be added to an ipset; DEL deletes an address
    previously added.

2)  Per-ip log rate limiting has been added in the form of the LOGLIMIT
    option in shorewall.conf. When LOGLIMIT is specified, LOGRATE and
    LOGBURST are ignored. 

    LOGRATE and LOGBURST are now deprecated.

    LOGLIMIT value format is [{s|d}:]<rate>[/<unit>][:<burst>]

    If the value starts with 's:' then logging is limited per source
    IP. If the value starts with 'd:', then logging is limited per
    destination IP. Otherwise, the overall logging rate is limited.

    <unit> is one of sec, min, hour, day.

    If <burst> is not specified, then a value of 5 is assumed.

3)  The sample configurations now include a 'Universal' configuration
    that will start on any system and protect that system while
    allowing the system to forward traffic.

    As part of this change, several additional features were added:

    - You may now specify "physical=+" in the interfaces file.
    - A 'COMPLETE' option is added to shorewall.conf and
      shorewall6.conf. When you set this option to Yes, you are
      asserting that the configuration is complete so that your set of
      zones encompasses any hosts that can send or receive traffic
      to/from/through the firewall. This causes Shorewall to omit the
      rules that catch packets in which the source or destination IP
      address is outside of any of your zones. Default is No.  It is
      recommended that this option only be set to Yes if:

      o You have defined an interface whose effective physical setting
        is '+'
      o That interface is assigned to a zone.
      o You have no CONTINUE policies or rules.

4)  'icmp' is now accepted as a synonym for 'ipv6-icmp' in IPv6

5)  Shorewall now detects the presence of a recent ipset iptables
    module and uses its new syntax. This avoids a warning on iptables
    1.4.9. This change involves a new capabilities file version so if
    you use a capabilities file, be sure to regenerate it with 4.4.12
    shorewall-lite or shorewall6-lite.

6)  Blacklisting can now be done by destination IP address as well as
    by source address.

    The /etc/shorewall/blacklist and /etc/shorewall6/blacklist files
    now have an optional OPTIONS column. Initially, this column can
    contain either 'from' (the default) or 'to'; the latter causes the
    address(es) in the ADDRESS/SUBNET column to be interpreted as a
    DESTINATION address rather than a source address.

    Note that static blacklisting is still restricted to traffic
    ARRIVING on an interface that has the 'blacklist' option set. So to
    block traffic from your local network to an internet host, you must
    specify 'blacklist' on your internal interface.

    Similarly, dynamic blacklisting has been enhanced to recognize the
    'from' and 'to' keywords.


        shorewall drop to

    This command will silently drop connection requests to1.2.3.4.

    The reciprocal of that command would be:

        shorewall allow to

7)  The status command now displays the directory containing the .conf
    file (shorewall.conf or shorewall6.conf) when the running
    configuration was compiled.


        gateway:/etc/shorewall# shorewall status
        Shorewall-4.4.12-RC1 Status at gateway - Thu Aug 12 19:41:51 PDT 2010

        Shorewall is running
        State:Started (Thu Aug 12 19:41:48 PDT 2010) from /etc/shorewall/

2010-07-15 Shorewall 4.4.11
     P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  The IPv6 allowBcast action generated an invalid rule.

2)  If IPSET=<pathname> was specified in shorewall.conf, then when an
    ipset was used in a configuration file entry, the following
    fatal compilation error occurred:

    ERROR: ipset names in Shorewall configuration files require Ipset
    Match in your kernel and iptables : /etc/shorewall/rules (line nn)

    If you applied the workaround given in the "Known Problems", then
    you should remove /etc/shorewall/capabilities after installing
    this fix.

3)  The start priority of shorewall-init on Debian and Debian-based
    distributions was previously too low, making it start too late.

4)  The log output from IPv6 logs was almost unreadable due to display
    of IPv6 addresses in uncompressed format. A similar problem
    occurred with 'shorewall6 show connections'. This update makes the
    displays much clearer at the expense of opening the slight
    possibility of two '::' sequences being incorrectly shown in the
    same address.

5)  The new REQUIRE_INTERFACE was inadvertently omitted from
    shorewall.conf and shorewall6.conf. It has been added.

6)  Under some versions of Perl, a Perl run-time diagnostic was produced
    when options were omitted from shorewall.conf or shorewall6.conf. 

7) If the following options were specified in /etc/shorewall/interfaces
   for an interface with '-' in the ZONE column, then these options
   would be ignored if there was an entry in the hosts file for the
   interface with an explicit or implicit ( is
   implied when the host list begins with '!').


   Note: for IPv6, the network is ::/0 rather than

8) The generated script was missing a closing quote when

9) Previously, if nets= was specified under Shorewall6, this error
   would result:

         ERROR: Invalid IPv6 address ( : 
                /etc/shorewall6/interfaces (line 16)

            N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Beginning with this release, Shorewall supports a 'vserver'
    zone type. This zone type is used with Shorewall running on a
    Linux-vserver host system and allows you to define zones that
    represent a set of Linux-vserver hosts.

    See for details.

2)  A new FORWARD_CLEAR_MARK option has been added to shorewall.conf
    and shorewall6.conf. 

    Traditionally, Shorewall has cleared the packet mark in the first
    rule in the mangle FORWARD chain. This behavior is maintained with
    the default setting (FORWARD_CLEAR_MARK=Yes). If the new option is
    set to No, packet marks set in the PREROUTING chain are retained in
    the FORWARD chains.

    As part of this change, a new "fwmark route mask" capability has
    been added. If your version of iproute2 supports this capability,
    fwmark routing rules may specify a mask to be applied to the mark
    prior to comparison with the mark value in the rule. The presence
    of this capability allows Shorewall to relax the restriction that
    small mark values may not be set in the PREROUTING chain when
    HIGH_ROUTE_MARKS is in effect. If you take advantage of this
    capability, be sure that you logically OR mark values in PREROUTING
    makring rules rather then simply setting them unless you are able
    to set both the high and low bits in the mark in a single rule.

    As always when a new capability has been introduced, be sure to
    regenerate your capabilities file(s) after installing this release.

3)  A new column (NET3) has been added to the /etc/shorewall/netmap
    file. This new column can qualify the INTERFACE column by
    specifying a SOURCE network (DNAT rule) or DEST network (SNAT rule)
    associated with the interface.

4)  To accomodate systems with more than one version of Perl installed,
    the shorewall.conf and shorewall6.conf files now support a PERL
    option. If the program specified by that option does not exist or
    is not executable, Shorewall (and Shorewall6) fall back to
2010-06-11 Shorewall 4.4.10
    P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Startup Errors (those that are detected before the state of the
    system has been altered), were previously not sent to the

2)  A regression of sorts occurred in Shorewall 4.4.9. Previously, a
    Perl extension script could end with a call to add_rule(). Such a
    script fails under Shorewall 4.4.9 unless the 'trace' option is
    specified on the run line.

    While this issue has been corrected, users are advised to always
    end their Perl extension scripts with the following line to insure
    that the script returns a 'true' value:


3)  Under rare circumstances involving a complex configuration,
    OPTIMIZE=13 and OPTIMIZE=15 could cause invalid iptables-restore
    input to be generated. 

    Sample error message:

        iptables-restore v1.4.8: Couldn't load target
        cannot open shared object file: No such file or directory

4)  Previously, if the 'optional' option was given to an interface with
    a wildcard physical name, specific instances of the interface were
    never considered usable.



    net         ppp+            -               optional


    XYZTEL      1       -       main            ppp0

    The XYZTEL provider was never usable.

    This configuration now works correctly.

5)  The 'forget' command now correctly removes saved ipsets.

         V.  N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  Shorewall 4.4.10 includes a new 'Shorewall Init' package. This new
    package provides two related features:

    a)  It allows the firewall to be closed prior to bringing up
        network devices. This insures that unwanted connections are not
        allowed between the time that the network comes up and when the
        firewall is started.

    b)  It integrates with NetworkManager and distribution ifup/ifdown
        systems to allow for 'event-driven' startup and shutdown.

    The two facilities can be enabled separately.

    When Shorewall-init is first installed, it does nothing until you
    configure it.

    The configuration file is /etc/default/shorewall-init on
    Debian-based systems and /etc/sysconfig/shorewall-init otherwise.

    There are two settings in the file:

          PRODUCTS    - lists the Shorewall packages that you want to
                        integrate with Shorewall-init. Example:

                            PRODUCTS="shorewall shorewall6"

          IFUPDOWN      When set to 1, enables integration with
                        NetworkManager and the ifup/ifdown scripts.

    To close your firewall before networking starts:

    a)  in the Shorewall-init configuration file, set PRODUCTS to the
        firewall products installed on your system.

    b)  be sure that your current firewall script(s) (normally in
        /var/lib/<product>/firewall) is(are) compiled with the 4.4.10

        Shorewall and Shorewall6 users can execute these commands:

            shorewall compile
            shorewall6 compile

        Shorewall-lite and Shorewall6-lite users can execute these
        commands on the administrative system.

            shorewall export <firewall-name-or-ip-address>
            shorewall6 export <firewall-name-or-ip-address>

    That's all that is required.

    To integrate with NetworkManager and ifup/ifdown, additional steps
    are required. You probably don't want to enable this feature if you
    run a link status monitor like swping or LSM.

    a)  In the Shorewall-init configuration file, set IFUPDOWN=1.

    b)  In your Shorewall interfaces file(s), set the 'required' option
        on any interfaces that must be up in order for the firewall to
        start. At least one interface must have the 'required' or
        'optional' option if you perform the next optional step. If
        'required' is specified on an interface with a wildcard name
        (the physical name ends with '+'), then at least one interface
        that matches the name must be in a usable state for the
        firewall to start successfully.

    c)  (Optional) -- If you have specified at least one 'required'
        or 'optional interface, you can then disable automatic firewall
        startup at boot time.

        On Debian-based systems, set startup=0 in /etc/default/<product>.

        On other systems, use your service startup configuration tool
        (chkconfig, insserv, ...) to disable startup. 
    The following actions occur when an interface comes up:

        Any           Required      start
        stopped       Optional      start
        started          -          restart

    The following actions occur when an interface goes down:

    In the INTERFACE column, '-' indicates neither required nor

        Any           Required      stop
        stopped       Optional      start
        started          -          restart

    For optional interfaces, the /var/lib/<product>/<interface>.state
    files are maintained to reflect the state of the interface.

    Please note that the action is carried out using the current
    compiled script; the configuration is not recompiled.

    A new option has been added to shorewall.conf and
    shorewall6.conf. The REQUIRE_INTERFACE option determines the
    outcome when an attempt to start/restart/restore/refresh the
    firewall is made and none of the optional interfaces are available.
    With REQUIRE_INTERFACE=No (the default), the operation is
    performed. If REQUIRE_INTERFACE=Yes, then the operation fails and
    the firewall is placed in the stopped state. This option is
    suitable for a laptop with both ethernet and wireless
    interfaces. If either come up, the firewall starts. If neither
    comes up, the firewall remains in the stopped state. Similarly, if
    an optional interface goes down and there are no optional
    interfaces remaining in the up state, then the firewall is stopped.

    Shorewall-init may be installed on Debian-based systems, SuSE-based
    systems and RedHat-based systems.

    On Debian-based systems, during system shutdown the firewall is
    opened prior to network shutdown (/etc/init.d/shorewall stop
    performs a 'clear' operation rather than a 'stop'). This is
    required by Debian standards. You can change this default behavior
    by setting SAFESTOP=1 in /etc/default/shorewall
    (/etc/default/shorewall6, ...).

2)  All of the CLIs now support the -a option of the 'version' command.


        gateway:~# shorewall6 version -a
        shorewall: 4.4.10-RC1
        shorewall-lite: 4.4.10-RC1
        shorewall6-lite: 4.4.10-RC1
        shorewall-init: 4.4.10-RC1

3)  Beginning with this release, the 'restart' and 'refresh' commands
    now retain the contents of the dynamic blacklist as well as the
    current UPnP rules. The dynamic blacklist is also preserved over
2010-05-07 Shorewall 4.4.9
    P R O B L E M S   C O R R E C T E D   I N   T H I S  R E L E A S E

1)  Logical interface names in the EXTERNAL column of
    /etc/shorewall/proxyarp were previously not mapped to their
    corresponding physical interface names. This could cause 'start' or
    'restart' to fail.

2)  If find_first_interface_address() was unable to detect an address,
    then Shorewall 4.4.8 would issue an obscure message
    (startup_error: command not found) and continue.

    Now, a meaningful error message is produced and the calling process

3)  If LOG_VERBOSITY=0 in shorewall.conf, then when the compiled script
    was executed, messages such as the following would be issued:

       /var/lib/shorewall6/.restart: line 65: [: -gt: unary operator

4)  With optimize 4, if an unnecessary NONAT rule was included in
    /etc/shorewall/rules (there was no DNAT or REDIRECT rule with the
    same source zone), then 'shorewall start' and/or 'shorewall restart'
    could fail with invalid iptables-restore input.

5)  The tarball installers now check for the presence of the CLI
    program (/sbin/shorewall, /sbin/shorewall6, etc) to determine if a
    fresh install or an upgrade should be performed. Previously, the
    installers used the presense of the configuration directory
    (/etc/shorewall, /etc/shorewall6, etc.) which led to incomplete
    installations where there was an existing configuration directory.

6)  The scripts have been removed from Shorewall-lite,
    Shorewall6, and Shorewall6-lite. These scripts no longer work and
    should have been removed in 4.4.0.

7)  The -lite products previously were inconsistent in how they
    referred to their startup log. Some references included '-lite'
    where some did not. This was particularly bad in the case of the
    Shorewall-lite logrotate file which duplicated the name used by the
    Shorewall package. This inconsistency could cause logrotate to
    fail if both packages were installed.

8)  Two additional problems with optimize 4 have been corrected. One
    manifested as invalid iptables-restore input involving the 'tcpre'
    mangle chain. The other involved wildcard interface names (those
    ending in '+') and would likely also result in invalid
    iptables-restore input.

9)  Previously, Shorewall would set up infrastructure to handle traffic
    from the firewall to bport zones. Such infrastructure could never
    be used. Now, Shorewall avoids setting up these unneeded chains
    and/or rules.

10) If optimization level 2 and there were no OUTPUT rules and the only
    effective output policy was $FW->all ACCEPT, then the OUTPUT chain
    was empty and no packets could be sent.

11) If find_first_interface_address() was called in the params file, a
    fatal error occured on start/restart.

12) The following valid configuration produced invalid
    iptables-restore input with optimization level 4.


    vpn        tun+            -


    Use of tunN in the nat and netmap files also produced invalid
    iptables-restore input.

            N E W   F E A T U R E S   I N   T H I S  R E L E A S E

1)  The compiler now auto-detects bridges for the purpose of setting
    the 'routeback' option. Auto-detection is disabled when compiling
    for export (-e option); note that -e is implicit in the 'load' and
    'reload' commands.

2)  When 'trace' is specified on a command that involves the compiler
    (e.g., shorewall trace check), the compiler now creates a trace to
    standard output.

    Trace entries are of three types:

    Input  --- begin with IN===>.     Input read from configuration
                                      files. Comments have been
                                      stripped, continuation lines
                                      combined and shell variables

    Output --- begin with GS----->.   Text written to the generated

    Netfilter -- begin with NF-(x)->. Updates to the compiler's chain
                                      table, where 'x' is one of the

        N - Create a chain.
        A - Append a rule to a chain.
        R - Replace a rule in a chain.
        I - Inserted a rule into a chain.
        T - Shell source text appended/inserted into a chain --
            converted into rules at run-time.
        D - Deleted Rule from a chain; note that this causes the 
            following rules to be renumbered.
        X - Deleted a chain
        P - Change a built-in chains policy. Chains in the filter table
            are created with a DROP policy. All other builtin chains
            have policy ACCEPT.
        !   Followed by one or more of the following to indicate that
            the operation is not allowed on the chain.

            O - Optimize
            D - Delete
            M - Move rules

    Netfilter trace records indicate the table and chain being
    changed. If the change involves a particular rule, then the rule
    number is also included. 

    Example (append the first rule to the filter FORWARD chain):

        NF-(A)-> filter:FORWARD:1 ...

    If the trace record involves the chain itself, then no rule number
    is present.

    Example (Delete the mangle tcpost chain):

        NF-(X)-> mangle:tcpost

3)  Thanks to Vincent Smeets, there is now an IPv6 mDNS macro.

4)  Optimize 8 has been added. This optimization level eliminates
    duplicate chains. So to set all possible optimizations, specify

5)  The command-line tools now support 'show log <regex>' where <regex>
    is a regular expression to search for in the LOGFILE. The command
    searches the current LOGFILE for Netfilter messages matching the
    supplied regex.

6)  There are some instances where a bridge with no IP address is
    configured. Prior to Shorewall 4.4.9, this required the following:

    dummy       br0             -               routeback
    #SOURCE     DEST            POLICY
    dummy       all             DROP
    all         dummy           DROP

    Beginning in this release, a single entry will suffice:

    -           br0             -               bridge

7)  The generated ruleset now uses conntrack match for state matching,
    if it is available.

8)  In /etc/shorewall/routestopped, the 'routeback' option is assumed
    if the interface has 'routeback' specified (either explicitly or

9)  Apple Macs running OS X may now be used as a Shorewall
    administrative system. Simply install using the tarball installer.
2010-03-24 Shorewall 4.4.8
         P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 8

1)  A CONTINUE rule specifying a log level would cause the compiler to 
    generate an incorrect rule sequence. The packet would be logged
    but the CONTINUE action would not occur.

2)  If multiple entries were present in /etc/shorewall/tcdevices and
    globally unique class numbers were not explicitly specified in
    /etc/shorewall/tcclasses, then 'shorewall start' would fail with a
    diagnostic such as:

    Setting up Traffic Control...
    RTNETLINK answers: File exists
      ERROR: Command "tc qdisc add dev eth1 parent 2:2 handle 2: sfq quantum
             1500 limit 127 perturb 10" Failed
    Processing /etc/shorewall/stop ...

3)  Previously, when a low per-IP rate limit (such as 1/hour) was
    specified, the effective enforced rate was much higher
    (approximately 6/min). The Shorewall compiler now configures the
    hashlimit table idle timeout based on the rate units (min, hour,
    ...) so that the rate is more accurately enforced.

    As part of this change, a unique hash table name is assigned to
    each per-IP rate limiting rule that does not specify a table name
    in the rule. The assigned names are of the form 'shorewallN' where
    N is an integer. Previously, all such rules shared a single
    'shorewall' table which lead to unexpected results.

4)  All versions of Shorewall-perl mishandle per-IP rate limiting in
    REDIRECT, DNAT and ACCEPT+ rules. The effective rate and burst are
    1/2 of the values given in the rule.

5)  Detection of the 'Old hashlimit match' capability was broken in
    /sbin/shorewall, /sbin/shorewall-lite and in the IPv4 version of 

6)  On older distributions such as RHEL5 and derivatives, Shorewall
    would fail to start if a TYPE was specified in
    /etc/shorewall/tcinterfaces and LOAD_HELPERS_ONLY had been
    specified in /etc/shorewall/shorewall.conf.

7)  The Debian init scripts are modified to include $remote_fs in the 
    Required-start and Required-stop specifications.

8)  Previously, when a supported command failed, the Debian Shorewall
    init script would still return a success (zero) exit status. It now
    returns a failure status (1) when the command fails.

9)  Previously, if a queue number was specified in an NFQUEUE policy
    (e.g., NFQUEUE(0)), invalid iptables-restore input would be

10) Previously, with optimization 4, users of ipsec on older releases
    such as RHEL5 and CentOS, could encounter an error similar to this

    Running /sbin/iptables-restore...
    iptables-restore v1.3.5: Unknown arg `out'
    Error occurred at line: 93
    Try `iptables-restore -h' or 'iptables-restore --help' for more
        ERROR: iptables-restore Failed. Input is in

11) Previously, with optimization 4, the 'blacklst' chain could be
    optimized away. If the blacklist file was then changed and a
    'shorewall refresh' executed, those new changes would not be included
    in the active ruleset.

                N E W   F E A T U R E S   I N   4 . 4 . 8

1)  To avoid variable name collisions, a number of shell variable names
    that Shorewall uses and that are in all capital letters have been
    changed. The following variables are now safe to use in your
    /etc/shorewall/params file and in your extension scripts:

    See Migration Issue 14 above for additional information.

2)  The Shorewall and Shorewall6 installers now accept a '-s' (sparse)
    option. That option causes only shorewall.conf to be installed in

3)  An OpenPGP HTTP Keyserver Protocol (HKP) macro (macro.HKP) has been

4)  In an attempt to help those who don't read the documentation, the
    compiler now flags apparent use of '-' as a port range separator
    with an error message.



       #ACTION    SOURCE     DEST      PROTO    DEST
       #                                        PORT(S)
       ACCEPT     net        fw        tcp      21-22

    Resulting error message

       ERROR: The separator for a port range is ':', not '-' (21-22) : 
              /etc/shorewall/rules (line 3)

5)  Support has been added for UDPLITE (proto 136) in that DEST PORT(S)
    and SOURCE PORT(S) may now be specified for that protocol.

6)  If a runtime error occurs during a 'start' or 'restart' operation
    but a saved configuration is successfully restored, a subsequent
    'status' command now gives the detailed status as 'Restored from
    <filename>' rather than 'Started'; <filename> is the saved script
    used to restore the configuration.
2010-02-14 Shorewall 4.4.7
          P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 7

1)  The tcinterfaces and tcpri files are now installed by the
    installer and are included in the rpm.

2)  An invalid octal number (e.g., 080) appearing in a port list
    resulted in a perl error message. 

    As part of this fix, both hex and octal numbers are now accepted
    for protocol and port numbers.

3)  In 4.4.6, if a system:

    a) Had mangle table support.
    b) Had a FORWARD chain in the mangle table.
    c) Did not have MARK Target support.

    then 'shorewall start' would fail.

4)  Previously, the 'nosmurfs' option was ignored in IPv6
    compilations. As part of this fix, 'nosmurfs' handling when
    SMURF_LOG_LEVEL is specified has been improved for both IPv4 and

5)  Previously, specifying a TYPE in /etc/shorewall/tcinterfaces would
    cause start/restart to fail on systems lacking 'flow' classifier
    support. In Shorewall 4.4.7, we detect the ability of the 'tc'
    utility to support that classifier.

    There are two caveats:

    - 'tc' may support 'flow' but the kernel does not. In that case,
      start/restart will still fail.

    - If you use a capabilities file, you will need to regenerate the
      file using shorewall-lite 4.4.7 in order for 'flow' to be
      accurately detected. If you do not regenerate the file, the
      compiler will use other hints to try to determine if 'flow' is

                N E W   F E A T U R E S   I N   4 . 4 . 7

1)  The OPTIMIZE option value is now a bit-map with each bit
    controlling a separate set of optimizations.

    - The low-order bit (value 1) controls optimizations available in
      earlier releases. We refer to this optimization as "optimization

    - The next bit (value 2) suppresses superfluous ACCEPT rules in a
      policy chain that implements an ACCEPT policy. Any ACCEPT rules
      that immediately preceed the final blanket ACCEPT rule in the
      chain are now omitted. We refer to this optimization as
      "optimization 2".

    - The next bit (value 4 or "optimization 4") enables the following
      additional optimizations:

      a) Empty chains are optimized away.
      b) Chains with one rule are optimized away.
      c) If a built-in chain has a single rule that branches to a
         second chain, then the rules from the second chain are moved
         to the built-in chain and the target chain is omitted.
      d) Chains with no references are deleted.
      e) Accounting chains are subject to optimization if the new
         OPTIMIZE_ACCOUNTING option is set to 'Yes' (default is 'No').
      f) If a chain ends with an unconditional branch to a second chain
         (other than to 'reject'), then the branch is deleted from the
         first chain and the rules from the second chain are appended
         to it. 

      The following chains are exempted from optimization 4:

          action chains (user-created).
          accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
          rules chains (those of the form zonea2zoneb or zonea-zoneb).
          UPnP (nat table).

    To enable all possible optimizations, set OPTIMIZE to 7 (1 + 2 +

2)  Shorewall now combines identical logging chains. Previously, a
    separate chain was created for each logging rule.

3)  Beginning with Shorewall 4.4.7, accounting can be disabled by
    setting ACCOUNTING=No in shorewall.conf. This allows you to keep a
    set of accounting rules configured in /etc/shorewall/accounting and
    to then enable and disable them by simply toggling the setting of

    Similarly, dynamic blacklisting can be disabled by setting
    DYNAMIC_BLACKLIST=No. This saves a jump rule in the INPUT
    and FORWARD filter chains..

4)  Shorewall can now automatically assign mark values to providers in
    cases where 'track' is specified (or TRACK_PROVIDERS=Yes) but
    packet marking is otherwise not used for directing connections to a
    particular provider. Simply specify '-' in the MARK column and
    Shorewall will automatically assign a mark value.

5)  Support for TPROXY has been added. See

6)  Traditionally, Shorewall has loaded all modules that could possibly
    be needed twice; once in the compiler, and once when the generated
    script is initialized. The latter can be a time-consuming process
    on slow hardware.

    Beginning with 4.4.7, there is a LOAD_HELPERS_ONLY option in
    shorewall.conf. For existing users, LOAD_HELPERS_ONLY=No is the

    For new users that employ the sample configurations,
    LOAD_HELPERS_ONLY=Yes will be the default. That setting causes only
    a small subset of modules to be loaded; it is assumed that the
    remaining modules will be autoloaded. Additionally, capability
    detection in the compiler is deferred until each capability is
    actually used. As a consequence, no modules are autoloaded

    Modules loaded when LOAD_HELPERS_ONLY=Yes are the protocol
    helpers. These cannot be autoloaded.
    In addition, the nf_conntrack_sip module is loaded with
    sip_direct_media=0. This setting is slightly less secure than
    sip_direct_media=1, but it solves many VOIP problems that users
    routinely encounter.
2010-01-16 Shorewall 4.4.6
        P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 6

1)  A 'feature' of xtables-addons when applied to Debian Lenny causes
    extra /31 networks to appear for nethash sets in the output of
    "ipset -L" and "ipset -S". A hack has been added to prevent these
    from being saved when Shorewall is saving IPSETS during 'stop'.

    As part of this change, the generated script is more careful about
    verifying the existence of the correct ipset utility before using
    it to save the contents of the sets.

2)  The mDNS macro previously did not include IGMP (protocol 2) and it
    did not specify the mDNS multicast address ( These
    omissions have been corrected.

             K N O W N   P R O B L E M S   R E M A I N I N G


                N E W   F E A T U R E S   I N   4 . 4 . 6

1)  In kernel 2.6.31, the handling of the rp_filter interface option was
    changed incompatibly. Previously, the effective value was determined
    by the setting of logically ANDed with
    the setting of net.ipv4.config.all.rp_filter.

    Beginning with kernel 2.6.31, the value is the arithmetic MAX of
    those two values. 

    Given that Shorewall sets net.ipv4.config.all.rp_filter to 1 if
    there are any interfaces specifying 'routefilter', specifying
    'routefilter' on any interface has the effect of setting the option
    on all interfaces.

    To allow Shorewall to handle this issue, a number of changes were

    a)  There is no way to safely determine if a kernel supports the
        new semantics or the old so the Shorewall compiler uses the
        kernel version reported by uname.

    b)  This means that the kernel version is now recorded in
        the capabilities file. So if you use capabilities files, you
        need to regenerate the files with Shorewall[-lite] 4.4.6 or

    c)  If the capabilities file does not contain a kernel version,
        the compiler assumes version 2.6.30 (the old rp_filter

    d)  The ROUTE_FILTER option in shorewall.conf now accepts the
        following values:
        0 or No  - Shorewall sets net.ipv4.config.all.rp_filter to 0.
        1 or Yes - Shorewall sets net.ipv4.config.all.rp_filter to 1.
        2        - Shorewall sets net.ipv4.config.all.rp_filter to 2.
        Keep     - Shorewall does not change the setting of
                   net.ipv4.config.all.rp_filter if the kernel version
                   is 2.6.31 or later.
        The default remains Keep.

    e)  The 'routefilter' interface option can have values 0,1 or 2. If
        'routefilter' is specified without a value, the value 1 is

2)  SAVE_IPSETS=Yes has been resurrected but in a different form. With
    this setting, the contents of your ipsets are saved during 'shorewall
    stop' and 'shorewall save' and they are restored during 'shorewall
    start' and 'shorewall restore'. Note that the contents may only be
    restored during 'restore' if the firewall is currently in the
    stopped state and there are no ipsets currently in use. In
    particular, when 'restore' is being executed to recover from a
    failed start/restart, the contents of the ipsets are not changed.

    When SAVE_IPSETS=Yes, you may not include ipsets in your
    /etc/shorewall/routestopped configuration.

3)  IPv6 addresses following a colon (":") may either be surrounded by
    <..> or by the more standard [..].

4)  A DHCPfwd macro has been added that allows unicast DHCP traffic to
    be forwarded through the firewall. Courtesy of Tuomo Soini.

5)  Shorewall (/sbin/shorewall) now supports a 'show macro' command:

              shorewall show macro <macro>


              shorewall show macro LDAP

    The command displays the contents of the macro.<macro> file.

6)  You may now preview the generated ruleset by using the '-r' option
    to the 'check' command (e.g., "shorewall check -r").

    The output is a shell script fragment, similar to the way it
    appears in the generated script.

7)  It is now possible to enable a simplified traffic shaping
    facility by setting TC_ENABLED=Simple in shorewall.conf.

    See for

8)  Previously, when TC_EXPERT=No, packets arriving through 'tracked'
    provider interfaces were unconditionally passed to the PREROUTING
    tcrules. This was done so that tcrules could reset the packet mark
    to zero, thus allowing the packet to be routed using the 'main'
    routing table. Using the main table allowed dynamic routes (such as
    those added for VPNs) to be effective.

    The route_rules file was created to provide a better alternative
    to clearing the packet mark. As a consequence, passing these
    packets to PREROUTING complicates things without providing any real

    Beginning with this release, when TRACK_PROVIDERS=Yes and TC_EXPERT=No,
    packets arriving through 'tracked' interfaces will not be passed to
    the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in
    4.4.3, this change should be transparent to most, if not all, users.
2009-12-19 Shorewall 4.4.5
          P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 5

1)  The change which removed the 15 port limitation on
    /etc/shorewall/routestopped was incomplete. The result was that if
    more than 15 ports were listed, an error was generated.

2)  If any interfaces had the 'bridge' option specified, compilation
    failed with the error:

    Undefined subroutine &Shorewall::Rules::match_source_interface called 
    at /usr/share/shorewall/Shorewall/ line 2319.

3)  The compiler now flags port number 0 as an error in all
    contexts. Previously, port 0 was allowed with the result that
    invalid iptables-restore input could be generated in some cases.

4)  The 'show policies' command now works in Shorewall6 and

5)  Traffic shaping modules from /lib/modules/<version>/net/sched/ are
    now correctly loaded. Previously, that directory was not
    searched. Additionally, Shorewall6 now tries to load the cls_flow
    module; previously, only Shorewall attempts to load that module.

6)  The Shorewall6-lite shorecap program was previously including the
    IPv4 base library rather than the IPv6 version. Also, Shorewall6
    capability detection was determing the availablity of the mangle
    capability before it had determined if ip6tables was installed.

7)  The setting of MODULE_SUFFIX was previously ignored except when
    compiling for export.

8)  Detection of the Enhanced Reject capability in the compiler was
    broken for IPv4 compilations.

9)  The 'reload -c' command would ignore the setting of DONT_LOAD in
    shorewall.conf. The 'reload' command without '-c' worked as

             K N O W N   P R O B L E M S   R E M A I N I N G


                N E W   F E A T U R E S   I N   4 . 4 . 5

1)  Shorewall now allows DNAT rules that change only the destination


        DNAT    loc     net::456        udp     234

    That rule will modify the destination port in UDP packets received
    from the 'loc' zone from 456 to 234. Note that if the destination
    is the firewall itself, then the destination port will be rewritten
    but that no ACCEPT rule from the loc zone to the $FW zone will have
    been created to handle the request. So such rules should probably
    exclude the firewall's IP addresses in the ORIGINAL DEST column.

2)  Systems that do not log Netfilter messages locally can now set
    LOGFILE=/dev/null in shorewall.conf.

3)  The 'shorewall show connections' and 'shorewall dump' commands now
    display the current number of connections and the max supported


        shorewall show connections
        Shorewall 4.5.0 Connections (62 out of 65536) at gateway - Sat ...

    In that case, there were 62 current connections out of a maximum
    number supported of 65536.
2009-11-21 Shorewall 4.4.4
          P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 4

1)  In some simple one-interface configurations, the following Perl
    run-time error messages were issued:

      Generating Rule Matrix...
      Use of uninitialized value in concatenation (.) or string at
      /usr/share/shorewall/Shorewall/ line 649.
      Use of uninitialized value in concatenation (.) or string at
      /usr/share/shorewall/Shorewall/ line 649.
      Creating iptables-restore input...

2)  The Shorewall operations log (specified by STARTUP_LOG) is now
    secured 0600.

3)  Previously, the compiler generated an incorrect test for interface
    availability in the generated code for adding route rules. The
    result was that the rules were always added, regardless of the
    state of the provider's interface. Now, the rules are only added
    when the interface is available.

4)  When TC_WIDE_MARKS=Yes and class numbers are not explicitly
    specified in /etc/shorewall/tcclasses, duplicate class numbers
    result. A typical error message is:

            ERROR: Command "tc class add dev eth3 parent 1:1 classid
            1:1 htb rate 1024kbit ceil 100000kbit prio 1 quantum 1500"

    Note that the class ID of the class being added is a duplicate of
    the parent's class ID.

    Also, when TC_WIDE_MARKS=Yes, values > 255 in the MARK column of
    /etc/shorewall/tcclasses were rejected.

             K N O W N   P R O B L E M S   R E M A I N I N G


                N E W   F E A T U R E S   I N   4 . 4 . 4

1)  The Shorewall packages now include a logrotate configuration file.

2)  The limit of 15 entries in a port list has been relaxed in

3)  The following seemingly valid configuration produces a fatal
    error reporting "Duplicate interface name (p+)"


       #ZONE            TYPE    
       fw               firewall
       world            ipv4
       z1:world         bport4
       z2:world         bport4


       #ZONE            INTERFACE       BROADCAST       OPTIONS
       world            br0             -               bridge
       world            br1             -               bridge
       z1               br0:p+
       z2               br1:p+

    This error occurs because the Shorewall implementation requires
    that each bridge port must have a unique name.

    To work around this problem, a new 'physical' interface option has
    been created. The above configuration may be defined using the
    following in /etc/shorewall/interfaces:

       #ZONE            INTERFACE       BROADCAST       OPTIONS
       world            br0             -               bridge
       world            br1             -               bridge
       z1               br0:x+          -               physical=p+
       z2               br1:y+          -               physical=p+

    In this configuration, 'x+' is the logical name for ports p+ on
    bridge br0 while 'y+' is the logical name for ports p+ on bridge

    If you need to refer to a particular port on br1 (for example
    p1023), you write it as y1023; Shorewall will translate that name
    to p1023 when needed.

    It is allowed to have a physical name ending in '+' with a logical
    name that does not end with '+'. The reverse is not allowed; if the
    logical name ends in '+' then the physical name must also end in

    This feature is not restricted to bridge ports. Beginning with this
    release, the interface name in the INTERFACE column can be
    considered a logical name for the interface, and the actual
    interface name is specified using the 'physical' option. If no
    'physical' option is present, then the physical name is assumed to
    be the same as the logical name. As before, the logical interface
    name is used throughout the rest of the configuration to refer to
    the interface.

4)  Previously, Shorewall has used the character '2' to form the name
    of chains involving zones and/or the word 'all' (e.g., fw2net,
    all2all). When zones names are given numeric suffixes, these
    generated names are hard to read (e.g., foo1232bar). To make these
    names clearer, a ZONE2ZONE option has been added.

    ZONE2ZONE has a default value of "2" but can also be given the
    value "-" (e.g., ZONE2ZONE="-") which causes Shorewall to separate
    the two parts of the name with a hyphen (e.g., foo123-bar).

5)  Only one instance of the following warning is now generated;
    previously, one instance of a similar warning was generated for
    each COMMENT encountered.

        COMMENTs ignored -- require comment support in iptables/Netfilter

6)  The shorewall and shorewall6 utilities now support a 'show
    policies' command. Once Shorewall or Shorewall6 has been restarted
    using a script generated by this version, the 'show policies'
    command will list each pair of zones and give the applicable
    policy. If the policy is enforced in a chain, the name of the chain
    is given.


        net     =>      loc     DROP using chain net2all

    Note that implicit intrazone ACCEPT policies are not displayed for
    zones associated with a single network where that network
    doesn't specify 'routeback'.

7)  The 'show' and 'dump' commands now support an '-l' option which
    causes chain displays to include the rule number of each rule.

    (Type 'iptables -h' and look for '--line-number')
2009-11-01 Shorewall 4.4.3
          P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 3

1.  Previously, if 'routeback' was specified in /etc/shorewall/routestopped:

    a) 'shorewall check' produced an internal error
    b) The 'routeback' option didn't work

2)  If an alias IP address was added and RETAIN_ALIASES=No in
    shorewall.conf, then a compiler internal error resulted.

3)  Previously, the generated script would try to detect the values
    for all run-time variables (such as IP addresses), regardless of
    what command was being executed. Now, this information is only
    detected when it is needed.

4)  Nested zones where the parent zone was defined by a wildcard
    interface (name ends with +) in /etc/shorewall/interfaces did
    not work correctly in some cases.

5)  IPv4 addresses embedded in IPv6 (e.g., :: were
    incorrectly reported as invalid.

6)  Under certain circumstances, optional providers were not detected
    as being usable.

    Additionally, the messages issued when an optional provider was not
    usable were confusing; the message intended to be issued when the
    provider shared an interface ("WARNING: Gateway <gateway> is not
    reachable -- Provider <name> (<number>) not Added") was being
    issued when the provider did not share an interface. Similarly, the
    message intended to be issued when the provider did not share an
    interface ("WARNING: Interface <interface> is not usable --
    Provider <name> (<number>) not Added") was being issued when the
    provider did share an interface.

             K N O W N   P R O B L E M S   R E M A I N I N G


                N E W   F E A T U R E S   I N   4 . 4 . 3

1)  On Debian systems, a default installation will now set
    INITLOG=/dev/null in /etc/default/shorewall. In all configurations,
    the default values for the log variables are changed to:


    The effect is much the same as the old defaults, with the exception 

        a) Start, stop, etc. commands issued through /sbin/shorewall
           will be logged.
        b) Logging will occur at maximum verbosity.
        c) Log entries will be date/time stamped.

    On non-Debian systems, new installs will now log all Shorewall 
    commands to /var/log/shorewall-init.log.

2)  A new TRACK_PROVIDERS option has been added in shorewall.conf.
    The value of this option becomes the default for the 'track'
    provider option in /etc/shorewall/providers.

3)  A new 'limit' option has been added to
    /etc/shorewall/tcclasses. This option specifies the number of
    packets that are allowed to be queued within the class. Packets
    exceeding this limit are dropped. The default value is 127 which is
    the value that earlier versions of Shorewall used.  The option is
    ignored with a warning if the 'pfifo' option has been specified.
2009-10-02 Shorewall 4.4.2
          P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 2

1)  Detection of Persistent SNAT was broken in the rules compiler. 

2)  Initialization of the compiler's chain table was occurring before 
    shorewall.conf had been read and before the capabilities had been
    determined. This could lead to incorrect rules and Perl runtime

3)  The 'shorewall check' command previously did not detect errors in

4)  In earlier versions, if a file with the same name as a built-in
    action were present in the CONFIG_PATH, then the compiler would
    process that file like it was an extension script.

    The compiler now ignores the presence of such files.

5)  Several configuration issues which previously produced an error or
    warning are now handled differently.

    a)  MAPOLDACTIONS=Yes and MAPOLDACTIOSN= in shorewall.conf are now
        handled as they were by the old shell-based compiler. That is,
        they cause pre-3.0 built-in actions to be mapped automatically
        to the corresponding macro invocation.

    b)  SAVE_IPSETS=Yes no longer produces a fatal error -- it is now a

    c)  DYNAMIC_ZONES=Yes no longer produces a fatal error -- it is now
        a warning.

    d)  RFC1918_STRICT=Yes no loger produces a fatal error -- it is now
        a warning.

6)  Previously, it was not possible to specify an IP address range in
    ADDRESS column of /etc/shorewall/masq. Thanks go to Jessee Shrieve
    for the patch.

7)  The 'wait4ifup' script included for Debian compatibility now runs
    correctly with no PATH.

8)  The new per-IP LIMIT feature now works with ancient iptables
    releases (e.g., 1.3.5 as found on RHEL 5). This change required
    testing for an additional capability which means that those who use
    a capabilities file should regenerate that file after installing

9)  One unintended difference between Shorewall-shell and
    Shorewall-perl was that Shorewall-perl did not support the MARK
    column in action bodies. This has been corrected.

             K N O W N   P R O B L E M S   R E M A I N I N G


                N E W   F E A T U R E S   I N   4 . 4 . 2

1)  Prior to this release, line continuation has taken precedence over 
    #-style comments. This prevented us from doing the following:

            ACCEPT    net:,\   #Gateway
                ,\   #Mail
                \    #Server
    Now, unless a line ends with '\', any trailing comment is stripped
    off (including any white-space preceding the '#'). Then if the line
    ends with '\', it is treated as a continuation line as normal.

2)  Three new columns have been added to FORMAT-2 macro bodies.


    These three columns correspond to the similar columns in
    /etc/shorewall/rules and must be empty in macros invoked from an

3)  Accounting chains may now have extension scripts. Simply place your
    Perl script in the file /etc/shorewall/<chain> and when the
    accounting chain named <chain> is created, your script will be

    As usual, the variable $chainref will contain a reference to the
    chain's table entry.
2009-09-03 Shorewall 4.4.1
          P R O B L E M S   C O R R E C T E D   I N   4 . 4 . 1

1)  If ULOG was specified as the LOG LEVEL in the all->all policy, the
    rules at the end of the INPUT and OUTPUT chains would still use the
    LOG target rather than ULOG.

2)  Using CONTINUE policies with a nested IPSEC zone was still broken
    in some cases.

3)  The setting of IP_FORWARDING has been change to Off in the
    one-interface sample configuration since forwarding is typically
    not required with only a single interface.

4)  If MULTICAST=Yes in shorewall.conf, multicast traffic was
    incorrectly exempted from ACCEPT policies.

5)  Previously, the definition of a zone that specified "nets=" in
    /etc/shorewall/interfaces could not be extended by entries in

6)  Previously, "nets=" could be specified in a multi-zone interface
    definition ("-" in the ZONES column) in /etc/shorewall/zones. This
    now raises a fatal compilation error.

7)  MULTICAST=Yes generates an incorrect rule that limits its
    effectiveness to a small part of the multicast address space.

8)  Checking for zone membership has been tighened up. Previously, 
    a zone could contain <interface>: along with other hosts;
    now, if the zone has <interface>: (even with exclusions),
    then it may have no additional members in /etc/shorewall/hosts.

             K N O W N   P R O B L E M S   R E M A I N I N G


                N E W   F E A T U R E S   I N   4 . 4 . 1

1)  To replace the SAME keyword in /etc/shorewall/masq, support has
    been added for 'persistent' SNAT. Persistent SNAT is required when
    an address range is specified in the ADDRESS column and when you
    want a client to always receive the same source/destination IP
    pair. It replaces SAME: which was removed in Shorewall 4.4.0.

    To specify persistence, follow the address range with


    This feature requires Persistent SNAT support in your kernel and

    If you use a capabilities file, you will need to create a new one
    as a result of this feature.

    WARNING: Linux kernels beginning with 2.6.29 include persistent
    SNAT support. If your iptables supports persistent SNAT but your
    kernel does not, there is no way for Shorewall to determine that
    persistent SNAT isn't going to work. The kernel SNAT code blindly
    accepts all SNAT flags without verifying them and returns them to
    iptables when asked.

2)  A 'clean' target has been added to the Makefiles. It removes backup
    files (*~ and .*~). 

3)  The meaning of 'full' has been redefined when used in the context
    of a traffic shaping sub-class. Previously, 'full' always meant the
    OUT-BANDWIDTH of the device. In the case of a sub-class, however,
    that definition is awkward to use because the sub-class is limited
    by the parent class.

    Beginning with this release, 'full' in a sub-class definition
    refers to the specified rate defined for the parent class. So
    'full' used in the RATE column refers to the parent class's RATE;
    when used in the CEIL column, 'full' refers to the parent class's

    As part of this change, the compiler now issues a warning if the
    sum of the top-level classes' RATEs exceeds the OUT-BANDWIDTH of
    the device. Similarly, a warning is issued if the sum of the RATEs
    of a class's sub-classes exceeds the rate of the CLASS.

4)  When 'nets=<network>' or 'nets=(<net1>,<net2>,...) is specified in
    /etc/shorewall/interfaces, multicast traffic will now be sent to
    the zone along with limited broadcasts.

5)  A flaw in the parsing logic for the zones file allowed most zone
    types containing the character string 'ip' to be accepted as a
    synonym for 'ipv4' (or ipv6 if compiling an IPv6 configuration).
2009-08-14 Shorewall 4.4.0
               R E L E A S E  4 . 4  H I G H L I G H T S

1)  Support for Shorewall-shell has been discontinued. Shorewall-perl
    has been combined with Shorewall-common to produce a single
    Shorewall package.

2)  Support for the "Hierarchical Fair Service Curve" (HFSC) queuing
    discipline has been added. HFSC is superior to the "Hierarchical
    Token Bucket" queuing discipline where realtime traffic such as
    VOIP is being used.

3)  Support for the "flow" traffic classifier has been added. This
    classifier can help prevent multi-connection applications such as
    BitTorrent from using an unfair amount of bandwidth.

4)  The Shorewall documentation and man pages have been purged of
    information about earlier Shorewall releases. The documentation
    describes only the behavior of Shorewall 4.4 and later versions.

5)  The interfaces file OPTIONs have been extended to largely remove the
    need for the hosts file.

6)  It is now possible to define PREROUTING and OUTPUT marking rules
    that cause new connections to use the same provider as an existing
    connection of the same kind.

7)  Dynamic Zone support is once again available for IPv4; ipset support is
    required in your kernel and in iptables.

8)  A new AUTOMAKE option has been added to shorewall.conf and
    shorewall6.conf. Setting this option will allow Shorewall to skip
    the compilation phase during start/restart if no configuration
    changes have occurred since the last start/restart.

9)  The LIMIT:BURST column in /etc/shorewall/policy
    (/etc/shorewall6/policy) and the RATE LIMIT column in
    /etc/shorewall/rules (/etc/shorewall6/rules) may now be used to
    limit on a per source IP or per destination IP basis.

10) Support for per-IP traffic shaping classes has been added.

11) Support for netfilter's TRACE facility has been added. TRACE allows
    you to trace selected packets through Netfilter, including marking
    by tcrules. 


Frequently Used Articles

- FAQs - Manpages - Configuration File Basics - Beginner Documentation - Troubleshooting

Shorewall 4.4/4.5/4.6 Documentation

Shorewall 4.0/4.2 Documentation

Shorewall 5.0/5.1/5.2 HOWTOs and Other Articles

- 6to4 and 6in4 Tunnels - Accounting - Actions - Aliased (virtual) Interfaces (e.g., eth0:0) - Anatomy of Shorewall - Anti-Spoofing Measures - AUDIT Target support - Bandwidth Control - Blacklisting/Whitelisting - Bridge/Firewall - Building Shorewall from GIT - Commands - Compiled Programs - Configuration File Basics - DHCP - DNAT - Docker - Dynamic Zones - ECN Disabling by host or subnet - Events - Extension Scripts - Fallback/Uninstall - FAQs - Features - Fool's Firewall - Forwarding Traffic on the Same Interface - FTP and Shorewall - Helpers/Helper Modules - Installation/Upgrade - IPP2P - IPSEC - Ipsets - IPv6 Support - ISO 3661 Country Codes - Kazaa Filtering - Kernel Configuration - KVM (Kernel-mode Virtual Machine) - Limiting Connection Rates - Linux Containers (LXC) - Linux-vserver - Logging - Macros - MAC Verification - Manpages - Manual Chains - Masquerading - Multiple Internet Connections from a Single Firewall - Multiple Zones Through One Interface - My Shorewall Configuration - Netfilter Overview - Network Mapping - No firewalling of traffic between bridge port - One-to-one NAT - Operating Shorewall - OpenVPN - OpenVZ - Packet Marking - Packet Processing in a Shorewall-based Firewall - 'Ping' Management - Port Forwarding - Port Information - Port Knocking (deprecated) - Port Knocking, Auto Blacklisting and Other Uses of the 'Recent Match' - PPTP - Proxy ARP - QuickStart Guides - Release Model - Requirements - Routing and Shorewall - Routing on One Interface - Samba - Shared Shorewall/Shorewall6 Configuration - Shorewall Events - Shorewall Init - Shorewall Lite - Shorewall on a Laptop - Shorewall Perl - Shorewall Setup Guide - SMB - SNAT - Split DNS the Easy Way - Squid with Shorewall - Starting/stopping the Firewall - Static (one-to-one) NAT - Support - Tips and Hints - Traffic Shaping/QOS - Simple - Traffic Shaping/QOS - Complex - Transparent Proxy - UPnP - Upgrade Issues - Upgrading to Shorewall 4.4 (Upgrading Debian Lenny to Squeeze) - VPN - VPN Passthrough - White List Creation - Xen - Shorewall in a Bridged Xen DomU - Xen - Shorewall in Routed Xen Dom0

Top of Page