From 2cdb52aa5025d2f54b40c1fad2ca51133848a49f Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 19 May 2005 22:17:37 +0000 Subject: [PATCH] Under New Management changes git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2141 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-Website/News.htm | 11963 +++++++++++------------- Shorewall-Website/shorewall_index.htm | 17 +- 2 files changed, 5481 insertions(+), 6499 deletions(-) diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index f6dd73c95..902367f39 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -1,32 +1,59 @@ - + - + + Shorewall News - - - - -

Shorewall News and Announcements

-

Tom Eastep
+ +

Shorewall News and Announcements
+

+Tom Eastep

-Copyright © 2001-2005 Thomas M. -Eastep

+Copyright © 2001-2005 Thomas M. Eastep

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

-

2005-05-15

-
-

05/02/2005 Shorewall 2.2.4

-

Problems Corrected:

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

+

2005-05-18
+

+
05/18/2005  +Tom stepping away from Shorewall development and support
+
+It is with regret that I announce that my involvement in Shorewall +development and support is officially +ending.
+
+Unlike the originators of other successful open source projects, I have +not been able to attract a core of people who believe in Shorewall and +who are willing to make sacrifices to ensure it's success. That is my +weakness and I accept it. But is means that I have been left with +trying to develop, document, and support Shorewall almost +single-handedly. I cannot do it +any more.
+
+I will clean up what I have for a 2.3 release and place it on the +server as my last Shorewall release -- Shorewall 2.4.0.
+
+Discussions aimed at continuing Shorewall development under new +leadership are continuing.
+
+Shorewall will always be a part of my life that I look back on with +fondness.
+
+Regards,
+
+-Tom
+

05/02/2005 Shorewall 2.2.4
+

+

Problems Corrected:
+

    -
  1. -

    The error message:
    +

  2. The error message:

           Error: No appropriate chain for zone <z1> to zone <z2>
    @@ -34,101 +61,92 @@ zone <z1> to zone <z2>
    has been changed to one that is more self-explanatory:

           Error: No policy defined for zone -<z1> to zone <z2>

    -
    3. -
  3. -

    When only an interface name appeared in the HOST(S) column of an +<z1> to zone <z2>

    4. +
  4. When only an interface name appeared in the HOST(S) column of an /etc/shorewall/hosts file entry, a misleading iptables error message resulted. Now the following message is generated:

           Error: Invalid HOST(S) column -contents: <column contents>

    -
    5. +contents: <column contents>
-

New Features:

+New Features:
    -
  1. -

    Support has been added for UPnP using linux-igd  (Support has been added for UPnP using linux-igd  (http://linux-idg.sourceforge.net). -UPnP is required by a number of popular applications including MSN IM.

    -
    2. +UPnP is required by a number of popular applications including MSN IM.
-

WARNING:

-

From a security architecture -viewpoint, UPnP is a disaster. It assumes that:

-
    -
  1. -

    All local systems and their users -are completely trustworthy.

    -
    2. -
  2. -

    No local system is infected with any worm or trojan.

    -
    3. +
    WARNING:
    +
    From a security architecture viewpoint, +UPnP is a disaster. It assumes that:
    +
      +
    1. All local systems and their users are completely trustworthy.
      2. +
    2. No local system is infected with any worm or trojan.
    -

    If either of these -assumptions are not true then UPnP can be used to totally defeat your -firewall and to allow incoming connections to arbitrary local systems -on any port whatsoever.
    -In short: USE UPnP AT YOUR OWN RISK.

    -


    -

    -

    WARNING:

    -

    The linux-igd project appears to be -inactive and the web site does not display correctly on any open -source browser that I've tried.
    +

    +
    If either of these assumptions are not +true then UPnP can be used to totally defeat your firewall and to allow +incoming connections to arbitrary local systems on any port whatsoever.
    +In short: USE UPnP AT YOUR OWN RISK.
    +
    +

    +
    +
    +
    WARNING:
    +
    The linux-igd project appears to be +inactive and the web site does not display correctly on any open source +browser that I've tried.

    -Building and installing -linux-igd is not for the faint of heart. You must download the source -from CVS and be prepared to do quite a bit of fiddling with the -include files from libupnp (which is required to build and/or run -linux-igd).

    -

    Configuring -linux-igd:

    -

    In /etc/upnpd.conf, you will -want:
    +Building and installing linux-igd is not for the faint of heart. You +must download the source from CVS and be prepared to do quite a bit of +fiddling with the include files from libupnp (which is required to +build and/or run linux-igd).
    +
    +

    +
    +
    Configuring linux-igd:
    +
    In /etc/upnpd.conf, you will want:

                    insert_forward_rules = yes
                    prerouting_chain_name = UPnP
                    -forward_chain_name = forwardUPnP

    -

    Shorewall -Configuration:

    -

    In /etc/shorewall/interfaces, you need +forward_chain_name = forwardUPnP
    +
    +

    +
    +
    Shorewall Configuration:
    +
    In /etc/shorewall/interfaces, you need the 'upnp' option on your external interface.

    -If your fw->loc -policy is not ACCEPT then you need this rule:
    +If your fw->loc policy is not ACCEPT then you need this rule:

                 allowoutUPnP       -fw      -loc
    +fw      loc

    -Note: To use 'allowoutUPnP', your iptables and kernel must -support the 'owner match' feature (see the output of "shorewall -check").
    +Note: To use 'allowoutUPnP', your iptables and kernel must support the +'owner match' feature (see the output of "shorewall check").

    -If your loc->fw policy is not ACCEPT then you -need this rule:
    +If your loc->fw policy is not ACCEPT then you need this rule:

                 allowinUPnP        -loc     -fw
    +loc     fw

    You MUST have this rule:

                 forwardUPnP        -net     -loc

    -

       You must also ensure that -you have a route to 224.0.0.0/4 on you internal (local) interface.

    -
      -
    1. -

      A new 'started' extension script has been added.  The +net     loc
      +
      +

    +
    +
       You must also ensure that +you have a route to 224.0.0.0/4 on you internal (local) interface.
    +
    +
      +
    1. A new 'started' extension script has been added.  The difference between this extension script and /etc/shorewall/start is that this one is invoked after delayed loading of the blacklist (DELAYBLACKLISTLOAD=Yes) and after the 'shorewall' chain has been @@ -136,22 +154,22 @@ created (thus signaling that the firewall is completely up.

      /etc/shorewall/started should not change the firewall configuration directly but may do so indirectly by running /sbin/shorewall with the -'nolock' option.

      +'nolock' option.
      +
      2. -
    2. -

      By default, shorewall is started with the "-f" (fast) option -when your system boots. You can override that setting by setting the -OPTIONS variable in /etc/sysconfig/shorewall (SuSE/Redhat) or +

    3. By default, shorewall is started with the "-f" (fast) option when +your system boots. You can override that setting by setting the OPTIONS +variable in /etc/sysconfig/shorewall (SuSE/Redhat) or /etc/default/shorewall (Debian/Bering). If neither file exists, feel free to create one or the other.

      Example: If you want Shorewall to always use the config files even if there is a saved configuration, then specify:

      -      OPTIONS=""

      +      OPTIONS=""
      +
      4. -
    4. -

      Shorewall now has support for the SAME target. This change +

    5. Shorewall now has support for the SAME target. This change affects the /etc/shorewall/masq and /etc/shorewall/rules file.

      SAME is useful when you specify multiple target IP addresses (in the @@ -180,10 +198,10 @@ In the rules file, when multiple connections from an internet host match a SAME rule then all of the connections will be sent to the same internal server. SAME rules are very similar to DNAT rules with the keyword SAME replacing DNAT. As in the masq file, changing the port -number is not supported.

      +number is not supported.
      +
      6. -
    6. -

      A "shorewall show capabilities" command has been added to report +

    7. A "shorewall show capabilities" command has been added to report the capabilities of your kernel and iptables.

         Example:
      @@ -218,17 +236,17 @@ IP range Match: Available
      Recent Match: Available
                   Owner Match: Available
      -      gateway:~#

      +      gateway:~#
      +
      8. -
    8. -

      A "-v" option has been added to /sbin/shorewall. Currently, this +

    9. A "-v" option has been added to /sbin/shorewall. Currently, this option only affects the "show log" command (e.g., "shorewall -v show log") and the "monitor" command. In these commands, it causes the MAC address in the log message (if any) to be displayed. As previously, -when "-v" is omitted, the MAC address is suppressed.

      +when "-v" is omitted, the MAC address is suppressed.
      +
      10. -
    10. -

      In /etc/shorewall/rules, a value of 'none' in either the SOURCE +

    11. In /etc/shorewall/rules, a value of 'none' in either the SOURCE or DEST columns now causes the rule to be ignored. This is most useful when used with shell variables:

      @@ -242,55 +260,49 @@ $FTP_CLIENTS        fw

              When FTP_CLIENTS is set to 'none', the above rule is ignored.  Otherwise, the rule is -evaluated and generates Netfilter rules.

      +evaluated and generates Netfilter rules.
      +
      12. -
    12. -

      The installer now detects that it is running on a Slackware -system and adjusts the DEST and INIT variables accordingly.

      +
    13. The installer now detects that it is running on a Slackware +system and adjusts the DEST and INIT variables accordingly.
    -

    05/01/2005 Tom spoke at LinuxFest NW 2005 -- Bellingham -Technical College, Bellingham Washington
    -
    -Tom's -presentation was entitled "Shorewall and Native IPSEC" and -is available for download here -(PDF Format).
    +

    05/01/2005 Tom +spoke at LinuxFest NW 2005 -- Bellingham Technical College, +Bellingham Washington
    +
    +Tom's presentation was entitled "Shorewall and Native IPSEC" and is +available for download here +(PDF Format).
    -04/07/2005 Shorewall 2.2.3
    -
    -Problems -Corrected:

    +
    +04/07/2005 +Shorewall 2.2.3
    +
    +Problems Corrected:
    +

      -
    1. -

      If a zone is defined in -/etc/shorewall/hosts using <interface>:!<network> in the -HOSTS column then startup errors occur on "shorewall [re]start".

      -
      2. -
    2. -

      Previously, if "shorewall status" was run on a system whose +

    3. If a zone is defined in /etc/shorewall/hosts using +<interface>:!<network> in the HOSTS column then startup +errors occur on "shorewall [re]start".
      4. +
    4. Previously, if "shorewall status" was run on a system whose kernel lacked advanced routing support (CONFIG_IP_ADVANCED_ROUTER),  then no routing information was -displayed.

      -
      5. +displayed.
    -

    New Features:

    +New Features:
      -
    1. -

      A new extension script "continue" -has been added. This script is invoked after Shorewall has set the -built-in filter chains policy to DROP, deleted any existing Netfilter -rules and user chains and has enabled existing connections. It is -useful for enabling certain communication while Shorewall is being -[re]started. Be sure to delete any rules that you add here in your -/etc/shorewall/start file.

      -
      2. -
    2. -

      There has been ongoing confusion -about how the /etc/shorewall/routestopped file works. People understand -how it works with the 'shorewall stop' command but when they read that -'shorewall restart' is logically equivalent to 'shorewall stop' -followed by 'shorewall start' then they erroneously conclude that +

    3. A new extension script "continue" has been added. This script is +invoked after Shorewall has set the built-in filter chains policy to +DROP, deleted any existing Netfilter rules and user chains and has +enabled existing connections. It is useful for enabling certain +communication while Shorewall is being [re]started. Be sure to delete +any rules that you add here in your /etc/shorewall/start file.
      4. +
    4. There has been ongoing confusion about how the +/etc/shorewall/routestopped file works. People understand how it works +with the 'shorewall stop' command but when they read that 'shorewall +restart' is logically equivalent to 'shorewall stop' followed by +'shorewall start' then they erroneously conclude that /etc/shorewall/routestopped can be used to enable new connections during 'shorewall restart'. Up to now, it cannot -- that file is not processed during either 'shorewall start' or 'shorewall restart'.
      @@ -304,13 +316,10 @@ added earlier.

      The result of this change will be that during most of [re]start, new connections will be allowed in accordance with the contents of -/etc/shorewall/routestopped.

      -
      5. -
    5. -

      The performance of configurations -with a large numbers of entries in /etc/shorewall/maclist can be -improved by setting the new MACLIST_TTL variable in -/etc/shorewall/shorewall.conf.
      +/etc/shorewall/routestopped.

      6. +
    6. The performance of configurations with a large numbers of entries +in /etc/shorewall/maclist can be improved by setting the new +MACLIST_TTL variable in /etc/shorewall/shorewall.conf.

      If your iptables and kernel support the "Recent Match" (see the output of "shorewall check" near the top), you can cache the results of a @@ -329,110 +338,89 @@ checked against the entire list.

      If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not -be cached.

      -
      7. -
    7. -

      You can now specify QUEUE as a policy and you can designate a +be cached.

      8. +
    8. You can now specify QUEUE as a policy and you can designate a common action for QUEUE policies in /etc/shorewall/actions. This is -useful for sending packets to something like Snort Inline.

      +useful for sending packets to something like Snort Inline.
    -

    03/31/2005 Shorewall 2.0.17
    +03/31/2005 +Shorewall 2.0.17

    -    Problems Corrected:

    +Problems Corrected:
      -
    1. -

      Invoking the 'rejNotSyn' action -results in an error at startup.

      -
      2. -
    2. -

      The UDP and TCP port numbers in -/usr/share/shorewall/action.AllowPCA were reversed.

      -
      3. -
    3. -

      If a zone is defined in /etc/shorewall/hosts using <interface>:!<network> -in the HOSTS column then startup errors occur on "shorewall [re]start".

      +
    4. Invoking the 'rejNotSyn' action results in an error at startup.
      5. +
    5. The UDP and TCP port numbers in +/usr/share/shorewall/action.AllowPCA were reversed.
      6. +
    6. If a zone is defined in /etc/shorewall/hosts using <interface>:!<network> in the HOSTS column +then startup errors occur on "shorewall [re]start".
    -

    03/12/2005 Shorewall 2.2.2
    -
    -Problems Corrected:

    +03/12/2005 +Shorewall 2.2.2
    +
    +Problems Corrected:
      -
    1. -

      The SOURCE column in the -/etc/shorewall/tcrules file now correctly allows IP ranges (assuming -that your iptables and kernel support ranges).

      +
    2. The SOURCE column in the /etc/shorewall/tcrules file now +correctly allows IP ranges (assuming that your iptables and kernel +support ranges).
      3. -
    3. -

      If A is a user-defined action and -you have file /etc/shorewall/A then when that file is invoked by -Shorewall during [re]start, the $TAG value may be incorrect.

      -
      4. -
    4. -

      Previously, if an iptables command -generating a logging rule failed, the Shorewall [re]start was still -successful. This error is now considered fatal and Shorewall will be -either restored from the last save (if any) or it will be stopped.

      -
      5. -
    5. -

      The port numbers for UDP and TCP -were previously reversed in the /usr/share/shorewall/action.AllowPCA -file.

      -
      6. -
    6. -

      Previously, the 'install.sh' script -did not update the /usr/share/shorewall/action.* files.

      -
      7. -
    7. -

      Previously, when an interface name appeared in the DEST column -of /etc/shorewall/tcrules, the name was not validated against the set -of defined interfaces and bridge ports.

      +
    8. If A is a user-defined action and you have file /etc/shorewall/A +then when that file is invoked by Shorewall during [re]start, the $TAG +value may be incorrect.
      9. +
    9. Previously, if an iptables command generating a logging rule +failed, the Shorewall [re]start was still successful. This error is now +considered fatal and Shorewall will be either restored from the last +save (if any) or it will be stopped.
      10. +
    10. The port numbers for UDP and TCP were previously reversed in the +/usr/share/shorewall/action.AllowPCA file.
      11. +
    11. Previously, the 'install.sh' script did not update the +/usr/share/shorewall/action.* files.
      12. +
    12. Previously, when an interface name appeared in the DEST column of +/etc/shorewall/tcrules, the name was not validated against the set of +defined interfaces and bridge ports.
    -

    New Features:

    +New Features:
      -
    1. -

      The SOURCE column in the -/etc/shorewall/tcrules file now allows $FW to be optionally followed by -":" and a host/network address or address range.

      -
      2. -
    2. -

      Shorewall now clears the output -device only if it is a terminal. This avoids ugly control sequences -being placed in files when /sbin/shorewall output is redirected.

      -
      3. -
    3. -

      The output from 'arp -na' has been -added to the 'shorewall status' display.

      -
      4. -
    4. -

      The 2.6.11 Linux kernel and iptables -1.3.0 now allow port ranges to appear in port lists handled by -"multiport match". If Shorewall detects this capability, it will use -"multiport match" for port lists containing port ranges. Be cautioned -that each port range counts for TWO ports and a port list handled with -"multiport match" can still specify a maximum of 15 ports.
      +

    5. The SOURCE column in the /etc/shorewall/tcrules file now allows +$FW to be optionally followed by ":" and a host/network address or +address range.
      6. +
    6. Shorewall now clears the output device only if it is a terminal. +This avoids ugly control sequences being placed in files when +/sbin/shorewall output is redirected.
      7. +
    7. The output from 'arp -na' has been added to the 'shorewall +status' display.
      8. +
    8. The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges +to appear in port lists handled by "multiport match". If Shorewall +detects this capability, it will use "multiport match" for port lists +containing port ranges. Be cautioned that each port range counts for +TWO ports and a port list handled with "multiport match" can still +specify a maximum of 15 ports.

      As always, if a port list in /etc/shorewall/rules is incompatible with "multiport match", a separate iptables rule will be generated for each -element in the list.

      -
      9. -
    9. -

      Traditionally, the RETURN target in the 'rfc1918' file has -caused 'norfc1918' processing to cease for a packet if the packet's -source IP address matches the rule. Thus, if you have:
      +element in the list.

      10. +
    10. Traditionally, the RETURN target in the 'rfc1918' file has caused +'norfc1918' processing to cease for a packet if the packet's source IP +address matches the rule. Thus, if you have:

      -   SUBNETS          -TARGET
      -   192.168.1.0/24   RETURN
      +    +SUBNETS          TARGET
      +    +192.168.1.0/24   RETURN

      then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you also have:

      -   SUBNETS          -TARGET
      -   10.0.0.0/8       -logdrop
      +    +SUBNETS          TARGET
      +    +10.0.0.0/8       logdrop

      Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to be logged and dropped since while the packet's source matches the @@ -442,28 +430,24 @@ If not specified or specified as empty (e.g., RFC1918_STRICT="") then RFC1918_STRICT=No is assumed.

      WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables -support 'Connection Tracking' match.

      +support 'Connection Tracking' match.
    -

    02/15/2005 Shorewall 2.2.1
    + +

    02/15/2005 +Shorewall 2.2.1

    -    This release rolls up the -fixes for bugs found in the first 2-3 weeks of deployment of -Shorewall 2.2.

    +This release rolls up the fixes for bugs found in the first 2-3 +weeks of deployment of Shorewall 2.2.
    +

      -
    1. -

      The /etc/shorewall/policy file -contained a misleading comment and both that file and the -/etc/shorewall/zones file lacked examples.

      -
      2. -
    2. -

      Shorewall previously used root's -default umask which could cause files in /var/lib/shorewall to be -world-readable. Shorewall now uses umask 0177.

      -
      3. -
    3. -

      In log messages produced by logging a built-in action, the -packet disposition was displayed incorrectly.
      +

    4. The /etc/shorewall/policy file contained a misleading comment and +both that file and the /etc/shorewall/zones file lacked examples.
      5. +
    5. Shorewall previously used root's default umask which could cause +files in /var/lib/shorewall to be world-readable. Shorewall now uses +umask 0177.
      6. +
    6. In log messages produced by logging a built-in action, the packet +disposition was displayed incorrectly.

         Example:

      @@ -481,31 +465,29 @@ tcp
         rather than

                  Feb -12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...

      +12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...
      +
      7. -
    7. -

      The comments regarding built-in -actions in /usr/share/shorewall/actions.std have been corrected.

      -
      8. -
    8. -

      The /etc/shorewall/policy file in the LRP package was missing -the 'all->all' policy.

      +
    9. The comments regarding built-in actions in +/usr/share/shorewall/actions.std have been corrected.
      10. +
    10. The /etc/shorewall/policy file in the LRP package was missing the +'all->all' policy.
    -

    02/05/2005 End of Support for Shorewall 1.4
    +02/05/2005 +End of Support for Shorewall 1.4

    -    Effective -today, support for Shorewall 1.4 has been discontinued. See the link -at the top of this article for  upgrade information.
    +Effective today, support for Shorewall 1.4 has been +discontinued. See the link at the top of this article for  upgrade +information.

    -02/01/2005 +02/01/2005 Shorewall 2.0.16
    -
    -This release back-ports the DROPINVALID -shorewall.conf option from 2.2.0.

    +
    +This release back-ports the DROPINVALID shorewall.conf option from +2.2.0.
      -
    1. -

      Recent 2.6 kernels include code that evaluates TCP packets based +

    2. Recent 2.6 kernels include code that evaluates TCP packets based on TCP Window analysis. This can cause packets that were previously classified as NEW or ESTABLISHED to be classified as INVALID.

      @@ -524,21 +506,19 @@ DROPINVALID option allows INVALID packets to be passed through the normal rules chains by setting DROPINVALID=No.

      If not specified or if specified as empty (e.g., DROPINVALID="") then -DROPINVALID=Yes is assumed.

      -
      3. +DROPINVALID=Yes is assumed.
    -

    02/01/2005 Shorewall 2.2.0
    +

    02/01/2005 +Shorewall 2.2.0

    -    New Features:

    +New Features:
    +

      -
    1. -

      ICMP packets that are in the INVALID -state are now dropped by the Reject and Drop default actions. They do -so using the new 'dropInvalid' builtin action. An 'allowInvalid' -builtin action is also provided which accepts packets in that state.

      -
      2. -
    2. -

      The /etc/shorewall/masq file INTERFACE column now allows +

    3. ICMP packets that are in the INVALID state are now dropped by the +Reject and Drop default actions. They do so using the new 'dropInvalid' +builtin action. An 'allowInvalid' builtin action is also provided which +accepts packets in that state.
      4. +
    4. The /etc/shorewall/masq file INTERFACE column now allows additional options.

      Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules @@ -558,328 +538,299 @@ Examples:

      eth0:
      eth1::192.0.2.32/27
      -+eth3:

      ++eth3:
      +
      5. -
    5. -

      Similar to 2), the -/etc/shorewall/nat file INTERFACE column now allows you to override the -setting of ADD_IP_ALIASES=Yes by following the interface name with ":" -but no digit.

      -
      6. -
    6. -

      All configuration files in the -Shorewall distribution with the exception of shorewall.conf are now -empty. In particular, the /etc/shorewall/zones, /etc/shorewall/policy -and /etc/shorewall/tos files now have no active entries. Hopefully this -will stop the questions on the support and development lists regarding -why the default entries are the way they are.

      -
      7. -
    7. -

      Previously, including a log level -(and optionally a log tag) on a rule that specified a user-defined (or -Shorewall-defined) action would log all traffic passed to the action. -Beginning with this release, specifying a log level in a rule that -specifies a user- or Shorewall-defined action will cause each rule in -the action to be logged with the specified level (and tag).
      +

    8. Similar to 2), the /etc/shorewall/nat file INTERFACE column now +allows you to override the setting of ADD_IP_ALIASES=Yes by following +the interface name with ":" but no digit.
      9. +
    9. All configuration files in the Shorewall distribution with the +exception of shorewall.conf are now empty. In particular, the +/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos +files now have no active entries. Hopefully this will stop the +questions on the support and development lists regarding why the +default entries are the way they are.
      10. +
    10. Previously, including a log level (and optionally a log tag) on a +rule that specified a user-defined (or Shorewall-defined) action would +log all traffic passed to the action. Beginning with this release, +specifying a log level in a rule that specifies a user- or +Shorewall-defined action will cause each rule in the action to be +logged with the specified level (and tag).

      The extent to which logging of action rules occurs is goverend by the -following:

      -
        -
      • -

        When you invoke an action and specify a log level, only -those rules in the action that have no log level will be changed to log -at the level specified at the action invocation.
        -
        +following:

        • +
          +
        • When you invoke an action and specify a log level, only those +rules in the action that have no log level will be changed to log at +the level specified at the action invocation.
          +
          Example:
          -
          +
          /etc/shorewall/action.foo:
          -
          +
          ACCEPT    -    -    tcp    22
          bar:info
          -
          +
          /etc/shorewall/rules:
          -
          +
          foo:debug    fw    net
          -
          +
          Logging in the invoked 'foo' action will be:
          -
          +
          ACCEPT:debug    -    -    tcp    22
          -bar:info

          -
          • -
        • -

          If you follow the log level with "!" then logging will be at +bar:info
          +
          +

          • +
        • If you follow the log level with "!" then logging will be at that level for all rules recursively invoked by the action
          -
          +
          Example: /etc/shorewall/action.foo:
          -
          - Update: I've been informed by Mandrake Development that -this problem has been corrected in Mandrake 10.0 Final (the problem -still exists in the 10.0 Community release).
          +
          + Update: I've been +informed by Mandrake Development that this problem has been corrected +in Mandrake 10.0 Final (the problem still exists in the 10.0 +Community release).
          ACCEPT    -    -    tcp    22
          bar:info
          -
          +
          /etc/shorewall/rules:
          -
          +
          foo:debug!    fw    net
          -
          +
          Logging in the invoke 'foo' action will be:
          -
          +
          ACCEPT:debug    -    -    tcp    22
          -bar:debug!

          -
          • -
        - +bar:debug!
        +
        + +
    -

    This change has an effect on extension -scripts used with user-defined actions. If you define an action -'acton' and you have an /etc/shorewall/acton script then when that -script is invoked, the following three variables will be set for use -by the script:

    -

    $CHAIN = the name of the chain where +

    This change has an effect on extension +scripts used with user-defined actions. If you define an action 'acton' +and you have an /etc/shorewall/acton script then when that script is +invoked, the following three variables will be set for use by the +script:
    +
    +
    $CHAIN = the name of the chain where your rules are to be placed. When logging is used on an action invocation, Shorewall creates a chain with a slightly different name from the action itself.
    -$LEVEL = Log level. If empty, no logging -was specified.
    -$TAG   = Log Tag.

    -

    Example:
    +$LEVEL = Log level. If empty, no logging was specified.
    +$TAG   = Log Tag.
    +
    +

    +Example:

    /etc/shorewall/rules:
    -    -
    +   
    acton:info:test

    -Your /etc/shorewall/acton file will be run -with:

    -

    $CHAIN="%acton1
    -$LEVEL="info"
    -$TAG="test"

    -


    +Your /etc/shorewall/acton file will be run with:
    +
    +

    $CHAIN="%acton1
    +$LEVEL="info"
    +$TAG="test"
    +
    +

    -

      -
    1. -

      The /etc/shorewall/startup_disabled -file is no longer created when Shorewall is first installed. Rather, -the variable STARTUP_ENABLED is set to 'No' in -/etc/shorewall/shorewall.conf. In order to get Shorewall to start, that -variable's value must be set to 'Yes'. This change accomplishes two -things:

      -
        -
      • -

        It prevents Shorewall from being -started prematurely by the user's initialization scripts.

        -
        • -
      • -

        It causes /etc/shorewall/shorewall.conf to be modified so -that it won't be replaced by upgrades using RPM.

        -
        • -
      -
      2. -
    2. -

      Support has been added for the 2.6 -Kernel IPSEC implementation. To use this support, you must have -installed the IPSEC policy match patch and the four IPSEC/Netfilter -patches from Patch-0-Matic-ng. The policy match patch affects both your -kernel and iptables. There are two ways to specify that IPSEC is to be -used when communicating with a set of hosts; both methods involve the -new /etc/shorewall/ipsec file:

      -
        -
      • -

        If encrypted communication is used with all hosts in a zone, +

      • The /etc/shorewall/startup_disabled file is no longer created +when +Shorewall is first installed. Rather, the variable STARTUP_ENABLED is +set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall +to start, that variable's value must be set to 'Yes'. This change +accomplishes two things:
        • +
          +
        • It prevents Shorewall from being started prematurely by the +user's initialization scripts.
          • +
        • It causes /etc/shorewall/shorewall.conf to be modified so that +it won't be replaced by upgrades using RPM.
          +
          +
          • +
        +
      • Support has been added for the 2.6 Kernel IPSEC implementation. +To use this support, you must have installed the IPSEC policy match +patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The +policy match patch affects both your kernel and iptables. There are two +ways to specify that IPSEC is to be used when communicating with a set +of hosts; both methods involve the new /etc/shorewall/ipsec file:
        • +
          +
        1. If encrypted communication is used with all hosts in a zone, then you can designate the zone as an "ipsec" zone by placing 'Yes" in the IPSEC ONLY column in /etc/shorewall/ipsec:
          -
          - #ZONE    -    IPSEC    OPTIONS ...
          - #    -        ONLY
          - vpn    -      Yes
          -
          +
          + #ZONE    +    IPSEC    OPTIONS ...
          + #    +        ONLY
          + vpn    +      Yes
          +
          The hosts in the zone (if any) must be specified in /etc/shorewall/hosts but you do not need to specify the 'ipsec' option on the entries in that file (see below). Dynamic zones involving IPSEC must use that technique.
          -
          +
          Example:Under 2.4 Kernel FreeS/Wan:
          -
          +
          /etc/shorewall/zones:
          -
          - net    -Net    The big bad Internet
          - vpn    -VPN    Remote Network
          -
          +
          + net    +Net    The big bad Internet
          + vpn    +VPN    Remote Network
          +
          /etc/shorewall/interfaces:
          -
          - net    -eth0    ...
          - vpn    -ipsec0    ...
          -
          +
          + net    +eth0    ...
          + vpn    +ipsec0    ...
          +
          Under 2.6 Kernel with this new support:
          -
          +
          /etc/shorewall/zones:
          -
          - net    -Net    The big bad Internet
          - vpn    -VPN    Remote Network
          -
          +
          + net    +Net    The big bad Internet
          + vpn    +VPN    Remote Network
          +
          /etc/shorewall/interfaces:
          -
          - net    -eth0    ...
          -
          +
          + net    +eth0    ...
          +
          /etc/shorewall/hosts:
          -
          - vpn    eth0:0.0.0.0/0
          -
          +
          + vpn    +eth0:0.0.0.0/0
          +
          /etc/shorewall/ipsec
          -
          - vpn    Yes

          -
          2. -
        2. -

          If only part of the hosts in a zone require encrypted +
          + vpn    Yes
          +
          +

          3. +
        3. If only part of the hosts in a zone require encrypted communication, you may use of the new 'ipsec' option in /etc/shorewall/hosts to designate those hosts.
          -
          +
          Example:
          -
          +
          Under 2.4 Kernel FreeS/Wan:
          -
          -/etc/shorewall/zones:

          - 
          net Net The big bad Internet
          loc Local Extended local zone
          -

          /etc/shorewall/interfaces:
          -
          - net    -eth0    ...
          - loc    -eth1    ...
          - loc    -ipsec0    ...
          -
          -Under 2.6 Kernel with this new support:
          -
          +
          /etc/shorewall/zones:
          -
          - net        -Net    The big bad Internet
          - vpn        -VPN    Remote Network
          -
          + 

          net    Net    The big bad Internet
          loc    Local  Extended local zone
          /etc/shorewall/interfaces:
          -
          - net    -eth0    ...
          - loc    -eth1    ...
          -
          +
          + net    +eth0    ...
          + loc    +eth1    ...
          + loc    +ipsec0    ...
          +
          +Under 2.6 Kernel with this new support:
          +
          +/etc/shorewall/zones:
          +
          + net    +    Net    The big bad Internet
          + vpn      +  VPN    Remote Network
          +
          +/etc/shorewall/interfaces:
          +
          + net    +eth0    ...
          + loc    +eth1    ...
          +
          /etc/shorewall/hosts:
          -
          - vpn    -eth0:0.0.0.0/0    ipsec,...

          -
          4. -
      -
      3. +
      + vpn    +eth0:0.0.0.0/0    ipsec,... +
-

Regardless of which technique you +

Regardless of which technique you choose, you can specify additional SA options for the zone in the /etc/shorewall/ipsec entry.

-The OPTIONS, IN OPTIONS and OUT -OPTIONS columns specify the input-output, input and output -characteristics of the security associations to be used to decrypt -(input) or encrypt (output) traffic to/from the zone.
+The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the +input-output, input and output characteristics of the security +associations to be used to decrypt (input) or encrypt (output) traffic +to/from the zone.

-The -available options are:

+The available options are:
+
-

Examples:
+

Examples:

-#ZONE    +#ZONE    IPSEC  OPTIONS                  -IN          OUT
-#        +IN    +      OUT
+#        ONLY            -   -             -OPTIONS     -OPTIONS
-vpn      +                +OPTIONS     OPTIONS
+vpn      Yes    mode=tunnel,proto=esp    -spi=1000    spi=1001
-loc      -No     reqid=44,mode=transport
+spi=1000    spi=1001
+loc      +No     reqid=44,mode=transport

-The -/etc/shorewall/masq file has a new IPSEC column added. If you specify -Yes or yes in that column then the unencrypted packets will have -their source address changed. Otherwise, the unencrypted packets will -not have their source addresses changed. This column may also contain -a comma-separated list of the options specified above in which case -only those packets that will be encrypted by an SA matching the given -options will have their source address changed.

+The /etc/shorewall/masq file has a new IPSEC column added. If you +specify Yes or yes in that column then the unencrypted packets will +have their source address changed. Otherwise, the unencrypted packets +will not have their source addresses changed. This column may also +contain a comma-separated list of the options specified above in which +case only those packets that will be encrypted by an SA matching the +given options will have their source address changed.
+
    -
  1. -

    To improve interoperability, tunnels -of type 'ipsec' no longer enforce the use of source port 500 for ISAKMP -and OpenVPN tunnels no longer enforce use of the specified port as both -the source and destination ports.

    -
    2. -
  2. -

    A new 'allowBcast' builtin action -has been added -- it silently allows broadcasts and multicasts.

    -
    3. -
  3. -

    The -c option in /sbin/shorewall commands is now deprecated. The +

  4. To improve interoperability, tunnels of type 'ipsec' no longer +enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no +longer enforce use of the specified port as both the source and +destination ports.
    5. +
  5. A new 'allowBcast' builtin action has been added -- it silently +allows broadcasts and multicasts.
    6. +
  6. The -c option in /sbin/shorewall commands is now deprecated. The commands where -c was previously allowed now permit you to specify a configuration directory after the command:

    @@ -888,10 +839,10 @@ configuration directory after the command:
          shorewall restart [ <configuration-directory> ]
          shorewall start   [ -<configuration-directory> ]

    +<configuration-directory> ]
    +
    7. -
  7. -

    Normally, when SNAT or MASQUERADE is applied to a tcp or udp +

  8. Normally, when SNAT or MASQUERADE is applied to a tcp or udp connection, Netfilter attempts to retain the source port number. If it has to change to port number to avoid  <source address>,<source port> conflicts, it tries to do so within @@ -903,91 +854,83 @@ specify either "tcp" or "udp" in the PROTO column.

    Examples 1 -- MASQUERADE with tcp source ports 4000-5000:

    -    #INTERFACE +     #INTERFACE SUBNET          -ADDRESS        PROTO
    -    eth0       -192.168.1.0/24  :4000-5000     tcp
    +ADDRESS        PROTO
    +     +eth0       192.168.1.0/24  +:4000-5000     tcp

    Example 2 -- SNAT with udp source ports 7000-8000:

    -    #INTERFACE +    #INTERFACE SUBNET          ADDRESS                 -PROTO
    -   eth0       +PROTO
    +    +eth0       10.0.0.0/8      -192.0.2.44:7000-8000    udp

    -
    9. -
  9. -

    You may now account by user/group ID -for outbound traffic from the firewall itself with entries in -/etc/shorewall/accounting. Such accounting rules must be placed in the -OUTPUT chain. See the comments at the top of /etc/shorewall/accounting -for details.

    -
    10. -
  10. -

    Shorewall now verifies that your -kernel and iptables have physdev match support if BRIDGING=Yes in -shorewall.conf.

    -
    11. -
  11. -

    Beginning with this release, if your -kernel and iptables have iprange match support (see the output from -"shorewall check"), then with the exception of the -/etc/shorewall/netmap file, anywhere that a network address may appear -an IP address range of the form <low address>-<high -address> may also appear.

    -
    12. -
  12. -

    Support has been added for the -iptables CLASSIFY target. That target allows you to classify packets -for traffic shaping directly rather than indirectly through fwmark. -Simply enter the <major>:<minor> classification in the -first column of /etc/shorewall/tcrules:
    +192.0.2.44:7000-8000    udp
    +
    +

    13. +
  13. You may now account by user/group ID for outbound traffic from +the firewall itself with entries in /etc/shorewall/accounting. Such +accounting rules must be placed in the OUTPUT chain. See the comments +at the top of /etc/shorewall/accounting for details.
    14. +
  14. Shorewall now verifies that your kernel and iptables have physdev +match support if BRIDGING=Yes in shorewall.conf.
    15. +
  15. Beginning with this release, if your kernel and iptables have +iprange match support (see the output from "shorewall check"), then +with the exception of the /etc/shorewall/netmap file, anywhere that a +network address may appear an IP address range of the form <low +address>-<high address> may also appear.
    16. +
  16. Support has been added for the iptables CLASSIFY target. That +target allows you to classify packets for traffic shaping directly +rather than indirectly through fwmark. Simply enter the +<major>:<minor> classification in the first column of +/etc/shorewall/tcrules:

    Example:

    - #MARK/      + #MARK/      SOURCE       -DEST      PROTO     PORT(S)
    - #CLASSIFY
    - 1:30        --            -eth0      tcp       25
    +DEST      PROTO     PORT(S)
    + #CLASSIFY
    + 1:30    +    -        +    eth0      tcp    +   25

    Note that when using this form of rule, it is acceptable to include the name of an interface in the DEST column.

    Marking using the CLASSIFY target always occurs in the POSTROUTING chain of the mangle table and is not affected by the setting of -MARK_IN_FORWARD_CHAIN in shorewall.conf.

    -
    17. -
  17. -

    During "shorewall start", IP -addresses to be added as a consequence of ADD_IP_ALIASES=Yes and -ADD_SNAT_ALIASES=Yes are quietly deleted when /etc/shorewall/nat and -/etc/shorewall/masq are processed then they are re-added later. This is -done to help ensure that the addresses can be added with the specified -labels but can have the undesirable side effect of causing routes to be -quietly deleted. A new RETAIN_ALIASES option has been added to -shorewall.conf; when this option is set to Yes, existing addresses will -not be deleted. Regardless of the setting of RETAIN_ALIASES, addresses -added during "shorewall start" are still deleted at a subsequent -"shorewall stop" or "shorewall restart".

    -
    18. -
  18. -

    Users with a large black list (from -/etc/shorewall/blacklist) may want to set the new DELAYBLACKLISTLOAD -option in shorewall.conf. When DELAYBLACKLISTLOAD=Yes, Shorewall will -enable new connections before loading the blacklist rules. While this -may allow connections from blacklisted hosts to slip by during -construction of the blacklist, it can substantially reduce the time -that all new connections are disabled during "shorewall [re]start".

    -
    19. -
  19. -

    Using the default LOGFORMAT, chain names longer than 11 +MARK_IN_FORWARD_CHAIN in shorewall.conf.

    20. +
  20. During "shorewall start", IP addresses to be added as a +consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly +deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed +then they are re-added later. This is done to help ensure that the +addresses can be added with the specified labels but can have the +undesirable side effect of causing routes to be quietly deleted. A new +RETAIN_ALIASES option has been added to shorewall.conf; when this +option is set to Yes, existing addresses will not be deleted. +Regardless of the setting of RETAIN_ALIASES, addresses added during +"shorewall start" are still deleted at a subsequent "shorewall stop" or +"shorewall restart".
    21. +
  21. Users with a large black list (from /etc/shorewall/blacklist) may +want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When +DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before +loading the blacklist rules. While this may allow connections from +blacklisted hosts to slip by during construction of the blacklist, it +can substantially reduce the time that all new connections are disabled +during "shorewall [re]start".
    22. +
  22. Using the default LOGFORMAT, chain names longer than 11 characters (such as in user-defined actions) may result in log prefix truncation. A new shorewall.conf action  LOGTAGONLY has been added to deal with this problem. When LOGTAGONLY=Yes, logging rules that @@ -998,42 +941,40 @@ Example -- file /etc/shorewall/action.thisisaverylogactionname:

        Rule:

    -         DROP:info:ftp    +         DROP:info:ftp    0.0.0.0/0    0.0.0.0/0    -tcp        21
    +tcp        21
       
        Log prefix with LOGTAGONLY=No:

    -         Shorewall:thisisaverylongacti
    +         Shorewall:thisisaverylongacti

        Log prefix with LOGTAGONLY=Yes:

    -         Shorewall:ftp:DROP

    +         Shorewall:ftp:DROP
    +
    23. -
  23. -

    Shorewall now resets the -'accept_source_route' flag for all interfaces. If you wish to accept -source routing on an interface, you must specify the new 'sourceroute' -interface option in /etc/shorewall/interfaces.

    -
    24. -
  24. -

    The default Drop and Reject actions now invoke the new standard +

  25. Shorewall now resets the 'accept_source_route' flag for all +interfaces. If you wish to accept source routing on an interface, you +must specify the new 'sourceroute' interface option in +/etc/shorewall/interfaces.
    26. +
  26. The default Drop and Reject actions now invoke the new standard action 'AllowICMPs'. This new action accepts critical ICMP types:
       
        Type 3 code 4 (fragmentation needed)
        Type 11       (TTL -exceeded)

    +exceeded)
    +
    27. -
  27. -

    Explicit control over the kernel's -Martian logging is now provided using the new 'logmartians' interface -option. If you include 'logmartians' in the interface option list then -logging of Martian packets on will be enabled on the specified -interface. If you wish to globally enable martian logging, you can set -LOG_MARTIANS=Yes in shorewall.conf.

    -
    28. -
  28. -

    You may now cause Shorewall to use the '--set-mss' option of the +

  29. Explicit control over the kernel's Martian logging is now +provided using the new 'logmartians' interface option. If you include +'logmartians' in the interface option list then logging of Martian +packets on will be enabled on the specified interface. If you wish to +globally enable martian logging, you can set LOG_MARTIANS=Yes in +shorewall.conf.
    30. +
  30. You may now cause Shorewall to use the '--set-mss' option of the TCPMSS target. In other words, you can cause Shorewall to set the MSS field of SYN packets passing through the firewall to the value you specify. This feature extends the existing CLAMPMSS option in @@ -1042,15 +983,15 @@ value as well as the values "Yes" and "No".

    Example:

    -    CLAMPMSS=1400

    +    CLAMPMSS=1400
    +
    31. -
  31. -

    Shorewall now includes support for -the ipp2p match facility. This is a departure from my usual policy in -that the ipp2p match facility is included in Patch-O-Matic-NG and is -unlikely to ever be included in the kernel.org source tree. Questions -about how to install the patch or how to build your kernel and/or -iptables should not be posted on the Shorewall mailing lists.
    +

  32. Shorewall now includes support for the ipp2p match facility. This +is a departure from my usual policy in that the ipp2p match facility is +included in Patch-O-Matic-NG and is unlikely to ever be included in the +kernel.org source tree. Questions about how to install the patch or how +to build your kernel and/or iptables should not be posted on the +Shorewall mailing lists.

    In the following files, the "PROTO" or "PROTOCOL" column may contain "ipp2p":
    @@ -1067,15 +1008,10 @@ list of the options and their meaning, at a root prompt:

    You must not include the leading "--" on the option; Shorewall will supply those characters for you. If you do not include an option then -"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").

    -
    33. -
  33. -

    Shorewall now has support for the -CONNMARK target from iptables. See the /etc/shorewall/tcrules file for -details.

    -
    34. -
  34. -

    A new debugging option LOGALLNEW has been added to +"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").

    35. +
  35. Shorewall now has support for the CONNMARK target from iptables. +See the /etc/shorewall/tcrules file for details.
    36. +
  36. A new debugging option LOGALLNEW has been added to shorewall.conf. When set to a log level, this option causes Shorewall to generaate a logging rule as the first rule in each builtin chain.

    @@ -1087,7 +1023,7 @@ prefix.
    Example: Using the default LOGFORMAT, the log prefix for logging from the nat table's PREROUTING chain is:

    -     Shorewall:nat:PREROUTING
    +     Shorewall:nat:PREROUTING

    IMPORTANT: There is no rate limiting on these logging rules so use LOGALLNEW at your own risk; it may cause high CPU and disk utilization @@ -1095,363 +1031,320 @@ and you may not be able to control your firewall after you enable this option.

    DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE -SENT TO ANOTHER SYSTEM.

    +SENT TO ANOTHER SYSTEM.
    +
    37. -
  37. -

    The SUBNET column in -/etc/shorewall/rfc1918 has been renamed SUBNETS and it is now possible -to specify a list of addresses in that column.

    -
    38. -
  38. -

    The AllowNNTP action now also allows -NNTP over SSL/TLS (NNTPS).

    -
    39. -
  39. -

    For consistency, the CLIENT PORT(S) -column in the tcrules file has been renamed SOURCE PORT(S).

    -
    40. -
  40. -

    The contents of -/proc/sys/net/ip4/icmp_echo_ignore_all is now shown in the output of -"shorewall status".

    -
    41. -
  41. -

    A new IPTABLES option has been added -to shorewall.conf. IPTABLES can be used to designate the iptables -executable to be used by Shorewall. If not specified, the iptables -executable determined by the PATH setting is used.

    -
    42. -
  42. -

    You can now use the "shorewall show zones" command to display -the current contents of the zones. This is particularly useful if you -use dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
    +

  43. The SUBNET column in /etc/shorewall/rfc1918 has been renamed +SUBNETS and it is now possible to specify a list of addresses in that +column.
    44. +
  44. The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).
    45. +
  45. For consistency, the CLIENT PORT(S) column in the tcrules file +has been renamed SOURCE PORT(S).
    46. +
  46. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now +shown in the output of "shorewall status".
    47. +
  47. A new IPTABLES option has been added to shorewall.conf. IPTABLES +can be used to designate the iptables executable to be used by +Shorewall. If not specified, the iptables executable determined by the +PATH setting is used.
    48. +
  48. You can now use the "shorewall show zones" command to display the +current contents of the zones. This is particularly useful if you use +dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).

        Example:

    -      ursa:/etc/shorewall -# shorewall show zones
    -    Shorewall-2.2.0-Beta7 Zones -at ursa - Sat Nov 27 11:18:25 PST 2004
    - 
    -    loc
    -       eth0:192.168.1.0/24
    -       eth1:1.2.3.4
    -    net    -  
    -       eth0:0.0.0.0/0
    -    WiFi
    -       eth1:0.0.0.0/0
    -    sec
    -       eth1:0.0.0.0/0
    - 
    -    ursa:/etc/shorewall #

    +      ursa:/etc/shorewall +# shorewall show zones
    +     +Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004
    +  
    +     loc
    +     +   eth0:192.168.1.0/24
    +     +   eth1:1.2.3.4
    +     +net      
    +     +   eth0:0.0.0.0/0
    +     WiFi
    +     +   eth1:0.0.0.0/0
    +     sec
    +     +   eth1:0.0.0.0/0
    +  
    +     +ursa:/etc/shorewall #
    +
    49. -
  49. -

    Variable expansion may now be used with the INCLUDE directive.
    +

  50. Variable expansion may now be used with the INCLUDE directive.

        Example:

        /etc/shorewall/params

    -        FILE=/etc/foo/bar
    +        FILE=/etc/foo/bar

            Any other config file:

    -        INCLUDE -$FILE

    +        INCLUDE $FILE
    +
    51. -
  51. -

    The output of "shorewall status" now -includes the results of "ip -stat link ls". This helps diagnose -performance problems caused by link errors.

    -
    52. -
  52. -

    Previously, when rate-limiting was -specified in /etc/shorewall/policy (LIMIT:BURST column), any traffic -which exceeded the specified rate was silently dropped. Now, if a log -level is given in the entry (LEVEL column) then drops are logged at -that level at a rate of 5/min with a burst of 5.

    -
    53. -
  53. -

    Recent 2.6 kernels include code that evaluates TCP packets based +

  54. The output of "shorewall status" now includes the results of "ip +-stat link ls". This helps diagnose performance problems caused by link +errors.
    55. +
  55. Previously, when rate-limiting was specified in +/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded +the specified rate was silently dropped. Now, if a log level is given +in the entry (LEVEL column) then drops are logged at that level at a +rate of 5/min with a burst of 5.
    56. +
  56. Recent 2.6 kernels include code that evaluates TCP packets based on TCP Window analysis. This can cause packets that were previously classified as NEW or ESTABLISHED to be classified as INVALID.

    The new kernel code can be disabled by including this command in your /etc/shorewall/init file:

    -    echo 1 > -/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
    +    echo 1 > +/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

    Additional kernel logging about INVALID TCP packets may be obtained by adding this command to /etc/shorewall/init:

    -    echo 1 > -/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
    +    echo 1 > +/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

    Traditionally, Shorewall has dropped INVALID TCP packets early. The new DROPINVALID option allows INVALID packets to be passed through the normal rules chains by setting DROPINVALID=No.

    If not specified or if specified as empty (e.g., DROPINVALID="") then -DROPINVALID=Yes is assumed.

    +DROPINVALID=Yes is assumed.
    +
    57. -
  57. -

    The "shorewall add" and "shorewall -delete" commands now accept a list of hosts to add or delete.
    +

  58. The "shorewall add" and "shorewall delete" commands now accept a +list of hosts to add or delete.

    Examples:

    -    shorewall add eth1:1.2.3.4 -eth1:2.3.4.5 z12
    -   shorewall delete eth1:1.2.3.4 -eth1:2.3.4.5 z12
    +    shorewall add +eth1:1.2.3.4 eth1:2.3.4.5 z12
    +    shorewall delete +eth1:1.2.3.4 eth1:2.3.4.5 z12

        The above commands may also be written:

    -    shorewall add -eth1:1.2.3.4,2.3.4.5 z12
    -   shorewall delete -eth1:1.2.3.4,2.3.4.5 z12
    -  

    +    shorewall add +eth1:1.2.3.4,2.3.4.5 z12
    +    shorewall delete +eth1:1.2.3.4,2.3.4.5 z12
    +  
    59. -
  59. -

    TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel +

  60. TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type. OpenVPN entries in /etc/shorewall/tunnels have this format:

    -    openvpn[:{tcp|udp}][:<port>]    -<zone>        <gateway>
    +    openvpn[:{tcp|udp}][:<port>]    +<zone>        <gateway>

    Examples:

    -      openvpn:tcp    +      openvpn:tcp         net    -1.2.3.4    # TCP tunnel on port 1194
    -    openvpn:3344    -    net    1.2.3.4    # -UDP on port 3344
    -    openvpn:tcp:4455    -net    1.2.3.4    # TCP on port 4455

    +1.2.3.4    # TCP tunnel on port 1194
    +     +openvpn:3344        net    +1.2.3.4    # UDP on port 3344
    +     +openvpn:tcp:4455    net    +1.2.3.4    # TCP on port 4455
    +
    61. -
  61. -

    A new 'ipsecvpn' script is included in the tarball and in the +

  62. A new 'ipsecvpn' script is included in the tarball and in the RPM. The RPM installs the file in the Documentation directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).

    This script is intended for use on Roadwarrior laptops for establishing -an IPSEC SA to/from remote networks. The script has some limitations:

    -
    63. +an IPSEC SA to/from remote networks. The script has some limitations:
    -
  1. -

    The output of "shorewall status" now -lists the loaded netfilter kernel modules.

    -
    2. -
  2. -

    The range of UDP ports opened by the -AllowTrcrt action has been increased to 33434:33524.

    -
    3. -
  3. -

    The IANA has recently registered port 1194 for use by OpenVPN. -In previous versions of Shorewall (and OpenVPN), the default port was -5000 but has been changed to 1194 to conform to the new OpenVPN -default.

    -
    4. +
  4. The output of "shorewall status" now lists the loaded netfilter +kernel modules.
    5. +
  5. The range of UDP ports opened by the AllowTrcrt action has been +increased to 33434:33524.
    6. +
  6. The IANA has recently registered port 1194 for use by OpenVPN. In +previous versions of Shorewall (and OpenVPN), the default port was 5000 +but has been changed to 1194 to conform to the new OpenVPN default.
-

01/17/2005 - Shorewall 2.2.0 RC5
+

01/17/2005 - +Shorewall 2.2.0 RC5

-Problems Corrected:

+Problems Corrected:
+

    -
  1. -

    The AllowTrcrt action has been -changed to allow up to 30 hops (same as default for 'traceroute'). -Previously, the action was documented as allowing 20 hops but actually -only allowed for 6 hops.

    -
    2. -
  2. -

    Using some lightweight shells, valid entries in -/etc/shorewall/ecn produce startup errors.

    +
  3. The AllowTrcrt action has been changed to allow up to 30 hops +(same as default for 'traceroute'). Previously, the action was +documented as allowing 20 hops but actually only allowed for 6 hops.
    4. +
  4. Using some lightweight shells, valid entries in +/etc/shorewall/ecn produce startup errors.
-

New Features:

+New Features:
    -
  1. -

    A new AllowInvalid standard built-in action has been added. This +

  2. A new AllowInvalid standard built-in action has been added. This action accepts packets that are in the INVALID connection-tracking -state.

    -
    3. +state.
-

01/16/2005 - New +01/16/2005 - New Shorewall Mirrors

-Thanks to Lorenzo Martignoni and Nick -Slikey, there are now Shorewall mirrors -in Milan Italy and in Austin Texas. Thanks Lorenzo and -Nick!
-
-01/12/2005 - Shorewall 2.0.15
-
-Problems -Corrected:

+Thanks to Lorenzo Martignoni and Nick Slikey, there are now +Shorewall mirrors in Milan Italy +and in Austin Texas. Thanks Lorenzo +and Nick!
+
+01/12/2005 - +Shorewall 2.0.15
+
+Problems Corrected:
    -
  1. -

    The range of ports opened by the -AllowTrcrt action has been expanded to 33434:33524 to allow for a -maximum of 30 hops.

    -
    2. -
  2. -

    Code mis-ported from 2.2.0 in release 2.0.14 caused the -following error during "shorewall start" where SYN rate-limiting is -present in /etc/shorewall/policy:
    +

  3. The range of ports opened by the AllowTrcrt action has been +expanded to 33434:33524 to allow for a maximum of 30 hops.
    4. +
  4. Code mis-ported from 2.2.0 in release 2.0.14 caused the following +error during "shorewall start" where SYN rate-limiting is present in +/etc/shorewall/policy:
     
          Bad argument `DROP'
          Try `iptables -h' or 'iptables --help' -for more information.

    +for more information.
-

01/06/2005 - Shorewall 2.2.0 RC4
-
-New -Features:

+01/06/2005 - +Shorewall 2.2.0 RC4
+
+New Features:
    -
  1. -

    A listing of loaded iptables kernel modules is now included in -the output of "shorewall status".

    +
  2. A listing of loaded iptables kernel modules is now included in +the output of "shorewall status".
-

Problems Corrected.

+Problems Corrected.
    -
  1. -

    Several problems associated with processing the IPSEC colummn in -/etc/shorewall/masq have been corrected.

    +
  2. Several problems associated with processing the IPSEC colummn in +/etc/shorewall/masq have been corrected.
-

01/03/2005 - Shorewall 2.0.14
-
-New -Features:

+01/03/2005 - +Shorewall 2.0.14
+
+New Features:
    -
  1. -

    Previously, when rate-limiting was specified in +

  2. Previously, when rate-limiting was specified in /etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded the specified rate was silently dropped. Now, if a log level is given in the entry (LEVEL column) then drops are logged at that level at a -rate of 5/min with a burst of 5.

    +rate of 5/min with a burst of 5.
-

Problems Corrected:

+Problems Corrected:
    -
  1. -

    A typo in the -/etc/shorewall/interfaces file has been fixed.

    -
    2. -
  2. -

    "bad variable" error messages -occurring during "shorewall stop" and "shorewall clear" have been -eliminated.

    -
    3. -
  3. -

    A misleading typo in /etc/shorewall/tunnels has been corrected. +

  4. A typo in the /etc/shorewall/interfaces file has been fixed.
    5. +
  5. "bad variable" error messages occurring during "shorewall stop" +and "shorewall clear" have been eliminated.
    6. +
  6. A misleading typo in /etc/shorewall/tunnels has been corrected. The TYPE column for an IPIP tunnel should contain "ipip" rather than -"ip".

    +"ip".
-

-12/31/2004 - Mandrake-specific RPMs available
+12/31/2004 +- Mandrake-specific RPMs available

-Jack -Coates has generously volunteered to provide Shorewall RPMs for use -under Mandrake. You can download Jack's RPMs from -http://www.monkeynoodle.org/tmp/
+Jack Coates has generously volunteered to provide Shorewall RPMs +for use under Mandrake. You can download Jack's RPMs from http://www.monkeynoodle.org/tmp/

-12/31/2004 +12/31/2004 - Redhat/Fedora-specific RPMs available
-
-Simon Matter has -graciously volunteered to provide RPMs taylored for Redhat and -Fedora. You can download Simon's RPMs from -http://www.invoca.ch/pub/packages/shorewall/
+
+Simon Matter has graciously volunteered to provide RPMs taylored for +Redhat and Fedora. You can download Simon's RPMs from http://www.invoca.ch/pub/packages/shorewall/

-Thanks, -Simon!
+Thanks, Simon!

-12/30/2004 - Shorewall 2.2.0 RC3
-
-Problems -Corrected:

+12/30/2004 - +Shorewall 2.2.0 RC3
+
+Problems Corrected:
    -
  1. -

    The following error message could appear during "shorewall stop" +

  2. The following error message could appear during "shorewall stop" or "shorewall clear":
                                                                                                                                                                                                                    
                  -local: lo:: bad variable name

    +local: lo:: bad variable name
    +
    3. -
  3. -

    The rate limiting example in -/etc/shorewall/rules has been changed to use the RATE LIMIT column.

    -
    4. -
  4. -

    Entries in /etc/shorewall/masq with -the INTERFACE column containing <ifname>:: (e.g., "eth0::") would -generate a progress message but would not generate an iptables rule.

    -
    5. -
  5. -

    A misleading typo in /etc/shorewall/tunnels has been corrected.

    +
  6. The rate limiting example in /etc/shorewall/rules has been +changed to use the RATE LIMIT column.
    7. +
  7. Entries in /etc/shorewall/masq with the INTERFACE column +containing <ifname>:: (e.g., "eth0::") would generate a progress +message but would not generate an iptables rule.
    8. +
  8. A misleading typo in /etc/shorewall/tunnels has been corrected.
+


-

-

12/24/2004 - Shorewall 2.2.0 RC2
+

12/24/2004 - +Shorewall 2.2.0 RC2

-New Features:

+New Features:
+

    -
  1. -

    By popular demand, the default port for Open VPN tunnels is now -1194 (the IANA-reserved port number for Open VPN).

    -
    2. +
  2. By popular demand, the default port for Open VPN tunnels is now +1194 (the IANA-reserved port number for Open VPN).
-

12/19/2004 - Shorewall 2.2.0 -RC1
+12/19/2004 - +Shorewall 2.2.0 RC1

-Problems Corrected:

+Problems Corrected:
    -
  1. -

    The syntax of the add and delete command has been clarified in -the help summary produced by /sbin/shorewall.

    -
    2. +
  2. The syntax of the add and delete command has been clarified in +the help summary produced by /sbin/shorewall.
-

New Features:

+New Features:
    -
  1. -

    TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel +

  2. TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type. OpenVPN entries in /etc/shorewall/tunnels have this format:

        openvpn[:{tcp|udp}][:<port>]    <zone>        <gateway>

    -Examples:

    - 
     openvpn:tcp   net 1.2.3.4    # TCP tunnel on port 5000
        openvpn:3344  net 1.2.3.4    # UDP on port 3344
        openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455
    +Examples:
    + 
        openvpn:tcp         net    1.2.3.4    # TCP tunnel on port 5000
        openvpn:3344        net    1.2.3.4    # UDP on port 3344
        openvpn:tcp:4455    net    1.2.3.4    # TCP on port 4455
    3. -
  3. -

    A new 'ipsecvpn' script is included in the tarball and in the +

  4. A new 'ipsecvpn' script is included in the tarball and in the RPM. The RPM installs the file in the Documentation directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).

    @@ -1463,27 +1356,21 @@ time.
        - Only the first SPD accessed will be instantiated at the remote gateway. So while the script creates SPDs to/from the remote gateway and each network listed in the NETWORKS setting at the -front of the script, only one of these may be used at a time.

    +front of the script, only one of these may be used at a time.
-

12/11/2004 - Shorewall 2.2.0 Beta -8
+12/11/2004 - +Shorewall 2.2.0 Beta 8

-Problems Corrected:

+Problems Corrected:
    -
  1. -

    A typo in the -/etc/shorewall/interfaces file has been corrected.

    -
    2. -
  2. -

    Previously, the "add" and "delete" commands were generating -incorrect policy matches when policy match support was available.

    -
    3. +
  3. A typo in the /etc/shorewall/interfaces file has been corrected.
    4. +
  4. Previously, the "add" and "delete" commands were generating +incorrect policy matches when policy match support was available.
-

New Features:

+New Features:
    -
  1. -

    Recent 2.6 kernels include code that evaluates TCP packets based +

  2. Recent 2.6 kernels include code that evaluates TCP packets based on TCP Window analysis. This can cause packets that were previously classified as NEW or ESTABLISHED to be classified as INVALID.

    @@ -1504,10 +1391,10 @@ DROPINVALID option allows INVALID packets to be passed through the normal rules chains by setting DROPINVALID=No.

    If not specified or if specified as empty (e.g., DROPINVALID="") then -DROPINVALID=Yes is assumed.

    +DROPINVALID=Yes is assumed.
    +
    3. -
  3. -

    The "shorewall add" and "shorewall delete" commands now accept a +

  4. The "shorewall add" and "shorewall delete" commands now accept a list of hosts to add or delete.

    Examples:
    @@ -1519,17 +1406,16 @@ The above commands may also be written:

        shorewall add eth1:1.2.3.4,2.3.4.5 z12
        shorewall delete eth1:1.2.3.4,2.3.4.5 z12
    -  

    +  
-

12/04/2004 - Shorewall 2.2.0 Beta -7
-
-Problems Corrected:

+12/04/2004 - +Shorewall 2.2.0 Beta 7
+
+Problems Corrected:
    -
  1. -

    The "shorewall add" and "shorewall delete" commands now work in -a bridged environment. The syntax is:
    +

  2. The "shorewall add" and "shorewall delete" commands now work in a +bridged environment. The syntax is:
     
               shorewall add <interface>[:<port>]:<address> <zone>
    @@ -1541,10 +1427,10 @@ delete <interface>[:<port>]:<address> <zone>
               shorewall add br0:eth2:192.168.1.3 OK
               shorewall -delete br0:eth2:192.168.1.3 OK

    +delete br0:eth2:192.168.1.3 OK
    +
    3. -
  3. -

    Previously, "shorewall save" created an out-of-sequence restore +

  4. Previously, "shorewall save" created an out-of-sequence restore script. The commands saved in the user's /etc/shorewall/start script were executed prior to the Netfilter configuration being restored. This has been corrected so that "shorewall save" now places those commands @@ -1557,29 +1443,24 @@ To accomplish this change, the "restore base" file Netfilter the configuration is restored.
     
    /var/lib/shorewall/restore-tail -- commands to be executed after the -Netfilter configuration is restored.

    +Netfilter configuration is restored.
    +
    5. -
  5. -

    Previously, traffic from the -firewall to a dynamic zone member host did not need to match the -interface specified when the host was added to the zone. For example, -if eth0:1.2.3.4 is added to dynamic zone Z then traffic out of any -firewall interface to 1.2.3.4 will obey the fw->Z policies and -rules. This has been corrected.

    -
    6. -
  6. -

    Shorewall uses the temporary chain 'fooX1234' to probe iptables +

  7. Previously, traffic from the firewall to a dynamic zone member +host did not need to match the interface specified when the host was +added to the zone. For example, if eth0:1.2.3.4 is added to dynamic +zone Z then traffic out of any firewall interface to 1.2.3.4 will obey +the fw->Z policies and rules. This has been corrected.
    8. +
  8. Shorewall uses the temporary chain 'fooX1234' to probe iptables for detrmining which features are supported. Previously, if that chain happened to exist when Shorewall was run, capabilities were -mis-detected.

    -
    9. +mis-detected.
-

New Features:

+New Features:
    -
  1. -

    You can now use the "shorewall show zones" command to display -the current contents of the zones. This is particularly useful if you -use dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
    +

  2. You can now use the "shorewall show zones" command to display the +current contents of the zones. This is particularly useful if you use +dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
     
        Example:
     
    @@ -1603,10 +1484,10 @@ eth1:0.0.0.0/0
               eth1:0.0.0.0/0
     
    -        ursa:/etc/shorewall #

    +        ursa:/etc/shorewall #
    +
    3. -
  3. -

    Variable expansion may now be used with the INCLUDE directive.
    +

  4. Variable expansion may now be used with the INCLUDE directive.
     
        Example:
     
    @@ -1618,44 +1499,37 @@ FILE=/etc/foo/bar
            Any other config file:
     
                -INCLUDE $FILE

    +INCLUDE $FILE
    +
    5. -
  5. -

    The output of "shorewall status" now -includes the results of "ip -stat link ls". This helps diagnose -performance problems caused by link errors.

    -
    6. -
  6. -

    Previously, when rate-limiting was specified in +

  7. The output of "shorewall status" now includes the results of "ip +-stat link ls". This helps diagnose performance problems caused by link +errors.
    8. +
  8. Previously, when rate-limiting was specified in /etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded the specified rate was silently dropped. Now, if a log
    level is given in the entry (LEVEL column) then drops are logged at -that level at a rate of 5/min with a burst of 5.

    +that level at a rate of 5/min with a burst of 5.
-

12/02/2004 - Shorewall 2.0.13
+12/02/2004 - +Shorewall 2.0.13

-Problems -Corrected:

+Problems Corrected:
    -
  1. -

    A typo in /usr/share/shorewall/firewall caused the "shorewall -add" to issue an error message:

    - 
    /usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found
    +
  2. A typo in /usr/share/shorewall/firewall caused the "shorewall +add" to issue an error message:
    + 
    /usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found
-

12/01/2004 - Shorewall 2.0.12
-
-Problems -Corrected:

+12/01/2004 - +Shorewall 2.0.12
+
+Problems Corrected:
    -
  1. -

    A typo in shorewall.conf (NETNOTSYN) -has been corrected.

    -
    2. -
  2. -

    The "shorewall add" and "shorewall delete" commands now work in -a bridged environment. The syntax is:
    +

  3. A typo in shorewall.conf (NETNOTSYN) has been corrected.
    4. +
  4. The "shorewall add" and "shorewall delete" commands now work in a +bridged environment. The syntax is:
     
          shorewall add <interface>[:<bridge port>][:<address>] <zone>
    @@ -1665,10 +1539,10 @@ a bridged environment. The syntax is:
    Examples:
     
          shorewall add br0:eth2:192.168.1.3 OK
    -      shorewall delete br0:eth2:192.168.1.3 OK

    +      shorewall delete br0:eth2:192.168.1.3 OK
    +
    5. -
  5. -

    Previously, "shorewall save" created an out-of-sequence restore +

  6. Previously, "shorewall save" created an out-of-sequence restore script. The commands saved in the user's /etc/shorewall/start script were executed prior to the Netfilter configuration being restored. This has been corrected so that "shorewall save" now places those commands @@ -1681,20 +1555,18 @@ To accomplish this change, the "restore base" file before the Netfilter configuration is restored.
     
       /var/lib/shorewall/restore-tail -- commands to be executed -after the Netfilter configuration is restored.

    +after the Netfilter configuration is restored.
    +
    7. -
  7. -

    Previously, traffic from the firewall to a dynamic zone member +

  8. Previously, traffic from the firewall to a dynamic zone member host did not need to match the interface specified when the host was added to the zone. For example, if eth0:1.2.3.4 is added to dynamic zone Z then traffic out of any firewall interface to 1.2.3.4 will obey -the fw->Z policies and rules. This has been corrected.

    -
    9. +the fw->Z policies and rules. This has been corrected.
-

New Features:

+New Features:
    -
  1. -

    Variable expansion may now be used with the INCLUDE directive.
    +

  2. Variable expansion may now be used with the INCLUDE directive.
     
    Example:
     
    @@ -1706,194 +1578,139 @@ FILE=/etc/foo/bar
            Any other config file:
     
                -INCLUDE $FILE

    +INCLUDE $FILE
-

11/26/2004 - Shorewall 2.2.0 Beta -6
+11/26/2004 - +Shorewall 2.2.0 Beta 6

-Beta 5 was more or less DOA. Here's Beta 6.
+Beta 5 was more or less DOA. Here's Beta 6.

-Problems -Corrected:

+Problems Corrected:
    -
  1. -

    Fixed a number of problems -associated with not having an IPTABLES value assigned in shorewall.conf -

    -
    2. -
  2. -

    Corrected a 'duplicate chain' error on "shorewall add" when the -'mss' option is present in /etc/shorewall/ipsec.

    +
  3. Fixed a number of problems associated with not having an IPTABLES +value assigned in shorewall.conf
    4. +
  4. Corrected a 'duplicate chain' error on "shorewall add" when the +'mss' option is present in /etc/shorewall/ipsec.
-

11/26/2004 - Shorewall 2.2.0 Beta -5
-
-Problems corrected:

+11/26/2004 - +Shorewall 2.2.0 Beta 5
+
+Problems corrected:
    -
  1. -

    A typo in shorewall.conf (NETNOTSYN) has been corrected.

    -
    2. +
  2. A typo in shorewall.conf (NETNOTSYN) has been corrected.
-

New Features:

+New Features:
    -
  1. -

    For consistency, the CLIENT PORT(S) -column in the tcrules file has been renamed SOURCE PORT(S).

    -
    2. -
  2. -

    The contents of -/proc/sys/net/ip4/icmp_echo_ignore_all is now shown in the output of -"shorewall status".

    -
    3. -
  3. -

    A new IPTABLES option has been added to shorewall.conf. IPTABLES +

  4. For consistency, the CLIENT PORT(S) column in the tcrules file +has been renamed SOURCE PORT(S).
    5. +
  5. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now +shown in the output of "shorewall status".
    6. +
  6. A new IPTABLES option has been added to shorewall.conf. IPTABLES can be used to designate the iptables executable to be used by Shorewall. If not specified, the iptables executable determined by the -PATH setting is used.

    +PATH setting is used.
-

11/23/2004 - Shorewall 2.0.11
-
-Problems -corrected:

+11/23/2004 - +Shorewall 2.0.11
+
+Problems corrected:
    -
  1. -

    The INSTALL file now include special -instructions for Slackware users.

    -
    2. -
  2. -

    The bogons file has been updated.

    -
    3. -
  3. -

    Service names are replaced by port -numbers in /etc/shorewall/tos.

    -
    4. -
  4. -

    A typo in the install.sh file that caused an error during a new -install has been corrected.

    -
    5. +
  5. The INSTALL file now include special instructions for Slackware +users.
    6. +
  6. The bogons file has been updated.
    7. +
  7. Service names are replaced by port numbers in /etc/shorewall/tos.
    8. +
  8. A typo in the install.sh file that caused an error during a new +install has been corrected.
-

New Features:

+New Features:
    -
  1. -

    The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).

    +
  2. The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).
-

11/19/2004 - Shorewall 2.2.0 Beta -4
-
-Problems Corrected:

+11/19/2004 - +Shorewall 2.2.0 Beta 4
+
+Problems Corrected:
    -
  1. -

    A cut and paste error resulted in -some nonsense in the description of the IPSEC column in -/etc/shorewall/masq.

    -
    2. -
  2. -

    A typo in /etc/shorewall/rules has -been corrected.

    -
    3. -
  3. -

    The bogons file has been updated.

    -
    4. -
  4. -

    The "shorewall add" command previously reported success but did -nothing -- now it works.

    -
    5. +
  5. A cut and paste error resulted in some nonsense in the +description of the IPSEC column in /etc/shorewall/masq.
    6. +
  6. A typo in /etc/shorewall/rules has been corrected.
    7. +
  7. The bogons file has been updated.
    8. +
  8. The "shorewall add" command previously reported success but did +nothing -- now it works.
-

New Features:

+New Features:
    -
  1. -

    The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).

    +
  2. The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).
-

11/09/2004 - Shorewall 2.2.0 Beta -3
-
-Problems Corrected:

+11/09/2004 - +Shorewall 2.2.0 Beta 3
+
+Problems Corrected:
    -
  1. -

    Missing '#' in the rfc1918 file has -been corrected.

    -
    2. -
  2. -

    The INSTALL file now includes special instructions for Slackware -users.

    -
    3. +
  3. Missing '#' in the rfc1918 file has been corrected.
    4. +
  4. The INSTALL file now includes special instructions for Slackware +users.
-

New Features:

+New Features:
    -
  1. -

    In CLASSIFY rules (/etc/shorewall/tcrules), an interface name -may now appear in the DEST column as in:

    - 
     #MARK/ SOURCE DEST PROTO PORT(S)
            #CLASSIFY
            1:30 - eth0 tcp 25
    +
  2. In CLASSIFY rules (/etc/shorewall/tcrules), an interface name may +now appear in the DEST column as in:
    + 
            #MARK/      SOURCE       DEST      PROTO     PORT(S)
            #CLASSIFY
            1:30        -            eth0      tcp       25
-

11/02/2004 - Shorewall 2.2.0 Beta -2
+11/02/2004 - +Shorewall 2.2.0 Beta 2

-Problems Corrected:

+Problems Corrected:
    -
  1. -

    The "shorewall check" command results in the (harmless) error +

  2. The "shorewall check" command results in the (harmless) error message:
     
            /usr/share/shorewall/firewall: line 2753:
               -check_dupliate_zones: command not found

    +check_dupliate_zones: command not found
    +
    3. -
  3. -

    The AllowNTP standard action now -allows outgoing responses to broadcasts.

    -
    4. -
  4. -

    A clarification has been added to the hosts file's description -of the 'ipsec' option pointing out that the option is redundent if the +

  5. The AllowNTP standard action now allows outgoing responses to +broadcasts.
    6. +
  6. A clarification has been added to the hosts file's description of +the 'ipsec' option pointing out that the option is redundent if the zone named in the ZONE column has been designated an IPSEC zone in the -/etc/shorewall/ipsec file.

    -
    7. +/etc/shorewall/ipsec file.
-

New Features:

+New Features:
    -
  1. -

    The SUBNET column in /etc/shorewall/rfc1918 has been renamed +

  2. The SUBNET column in /etc/shorewall/rfc1918 has been renamed SUBNETS and it is now possible to specify a list of addresses in that -column.

    +column.
-

10/25/2004 - Shorewall 2.0.10
-
-Problems -Corrected:

+10/25/2004 - +Shorewall 2.0.10
+
+Problems Corrected:
    -
  1. -

    The GATEWAY column was previously -ignored in 'pptpserver' entries in /etc/shorewall/tunnels.

    -
    2. -
  2. -

    When log rule numbers are included -in the LOGFORMAT, duplicate rule numbers could previously be generated. -

    -
    3. -
  3. -

    The /etc/shorewall/tcrules file now -includes a note to the effect that rule evaluation continues after a -match.

    -
    4. -
  4. -

    The error message produced if Shorewall couldn't obtain the -routes through an interface named in the SUBNET column of -/etc/shorewall/masq was less than helpful since it didn't include the -interface name.

    +
  5. The GATEWAY column was previously ignored in 'pptpserver' entries +in /etc/shorewall/tunnels.
    6. +
  6. When log rule numbers are included in the LOGFORMAT, duplicate +rule numbers could previously be generated.
    7. +
  7. The /etc/shorewall/tcrules file now includes a note to the effect +that rule evaluation continues after a match.
    8. +
  8. The error message produced if Shorewall couldn't obtain the +routes +through an interface named in the SUBNET column of /etc/shorewall/masq +was less than helpful since it didn't include the interface name.
-

New Features:

+New Features:
    -
  1. -

    The "shorewall status" command has been enhanced to include the +

  2. The "shorewall status" command has been enhanced to include the values of key /proc settings:

    Example from a two-interface firewall:
    @@ -1915,102 +1732,84 @@ Example from a two-interface firewall:
       /proc/sys/net/ipv4/conf/eth1/rp_filter = 0
       /proc/sys/net/ipv4/conf/lo/proxy_arp = 0
       /proc/sys/net/ipv4/conf/lo/arp_filter = 0
    -   /proc/sys/net/ipv4/conf/lo/rp_filter = 0

    +   /proc/sys/net/ipv4/conf/lo/rp_filter = 0
-


-10/24/2004 - Shorewall 2.2.0 -Beta1

-The first beta in the 2.2 series is now available. -Download location is:

-

10/24/2004 - +Shorewall 2.2.0 Beta1
+
+The first beta in the 2.2 series is now available. Download +location is:
+
+

http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1
-ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1

+ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1
+

The features available in this release and the migration considerations are covered in the release -notes. Highlights include:

+notes. Highlights include:
+

    -
  1. -

    The behavior produced by specifying -a log level in an action invocation is now much more rational. -Previously, all packets sent to the action were logged; now each rule -within the invoked action behaves as if logging had been specified on -it.

    -
    2. -
  2. -

    Support for the 2.6 Kernel's native -IPSEC implementation is now available.

    -
    3. -
  3. -

    Support for ipp2p is included.

    -
    4. -
  4. -

    Support for the iptables CONNMARK -facility is now included in Shorewall.

    -
    5. -
  5. -

    A new LOGALLNEW option facilitates -problem analysis.

    -
    6. -
  6. -

    Users with a large static blacklist -can now defer loading the blacklist until after the rest of the ruleset -has been enabled. Doing so can decrease substantially the amount of -time that connections are disabled during shorewall [re]start.

    -
    7. -
  7. -

    Support for the iptables 'iprange -match' feature has been enabled. Users whose kernel and iptables -contain this feature can use ip address ranges in most places in their -Shorewall configuration where a CIDR netowrk can be used.

    -
    8. -
  8. -

    Accepting of source routing and -martian logging may now be enabled/disabled on each interface.

    -
    9. -
  9. -

    Shorewall now supports the CLASSIFY iptable target.

    -
    10. +
  10. The behavior produced by specifying a log level in an action +invocation is now much more rational. Previously, all packets sent to +the action were logged; now each rule within the invoked action behaves +as if logging had been specified on it.
    11. +
  11. Support for the 2.6 Kernel's native IPSEC implementation is now +available.
    12. +
  12. Support for ipp2p is included.
    13. +
  13. Support for the iptables CONNMARK facility is now included in +Shorewall.
    14. +
  14. A new LOGALLNEW option facilitates problem analysis.
    15. +
  15. Users with a large static blacklist can now defer loading the +blacklist until after the rest of the ruleset has been enabled. Doing +so can decrease substantially the amount of time that connections are +disabled during shorewall [re]start.
    16. +
  16. Support for the iptables 'iprange match' feature has been +enabled. Users whose kernel and iptables contain this feature can use +ip address ranges in most places in their Shorewall configuration where +a CIDR netowrk can be used.
    17. +
  17. Accepting of source routing and martian logging may now be +enabled/disabled on each interface.
    18. +
  18. Shorewall now supports the CLASSIFY iptable target.
-

9/23/2004 - Shorewall 2.0.9
-
-Problems -Corrected:

+

9/23/2004 - +Shorewall 2.0.9
+
+Problems Corrected:
+

    -
  1. -

    Previously, an empty PROTO column or a value of "all" in that +

  2. Previously, an empty PROTO column or a value of "all" in that column would cause errors when processing the /etc/shorewall/tcrules -file.

    -
    3. +file.
-

New Features:

+New Features:
    -
  1. -

    The "shorewall status" command now includes the output of "brctl -show" if the bridge tools are installed.

    +
  2. The "shorewall status" command now includes the output of "brctl +show" if the bridge tools are installed.
-

9/20/2004 – Change in Shorewall -Support

-

Friends,

-

The demands that my job and my personal life are currently placing -on me are such that supporing Shorewall to the extent that I have -been doing is just not possible any more.

-

I will continue to be active on the development list and will -continue to develop Shorewall if at all possible.

-

I will also continue to read the user's list and will help with -problems that interest me. But I am no longer going to hop on every -problem as soon as I see it.

-

This change means that I'm going to have to depend on you folks to -help each other; I'm confident that we can make this work.

-

8/22/2004 - Shorewall 2.0.8
+

9/20/2004 – Change in Shorewall Support

+

Friends,

+

The demands that my job and my +personal life are currently placing on me are such that supporing +Shorewall to the extent that I have been doing is just not possible +any more.

+

I will continue to be active on the +development list and will continue to develop Shorewall if at all +possible.

+

I will also continue to read the +user's list and will help with problems that interest me. But I am no +longer going to hop on every problem as soon as I see it.

+

This change means that I'm going to +have to depend on you folks to help each other; I'm confident that we +can make this work.

+

8/22/2004 - +Shorewall 2.0.8

-Problems -Corrected:

+Problems Corrected:

  1. Entries in the USER/GROUP column of an action file (made from @@ -2339,7 +2138,7 @@ will generate an error and Shorewall fails to start.

    'functions' file from CVS (STABLE/ project for 1.4.10f and STABLE2/ project for 2.0.3a) to prevent startup errors with these versions installed. These updatged files are also available from the Errata -(2.0, 1.4).

    +(2.0, 1.4).

    6/23/2004 - Shorewall 2.0.3

    Problems @@ -2555,96 +2354,91 @@ INIT and FIREWALL variables to be specified outside the script as in:
    ./install.sh

-

6/3/2004 - Shorewall 2.0.2f

-

Fixes one problem:

+

6/3/2004 - Shorewall 2.0.2f
+

+

Fixes one problem:
+

    -
  1. -

    Versions 2.0.2d and 2.0.2e fail to load kernel modules unless -MODULE_SUFFIX is set in shorewall.conf

    +
  2. Versions 2.0.2d and 2.0.2e fail to load kernel modules unless +MODULE_SUFFIX is set in shorewall.conf
-

6/2/2004 - Shorewall 2.0.2e

-

One problem corrected:

+

6/2/2004 - Shorewall 2.0.2e
+

+

One problem corrected:
+

    -
  1. -

    LOG rules within an action generate two Netfilter logging rules.

    +
  2. LOG rules within an action generate two Netfilter logging rules.

5/28/2004 - Shorewall 2.0.2d

-One problem corrected:

+One problem corrected:
+

    -
  1. -

    Shorewall was checking capabilities before loading kernel +

  2. Shorewall was checking capabilities before loading kernel modules. Consequently, if kernel module autoloading was disabled, the -capabilities were mis-detected.

    +capabilities were mis-detected.

5/21/2004 - Shorewall 2.0.2c

-

One problem corrected:

+One problem corrected:
    -
  1. -

     DNAT rules with a dynamic source zone don't work properly. -When used, these rules cause the rule to be checked against ALL -input,  not just input from the designated zone.

    +
  2.  DNAT rules with a dynamic source zone don't work +properly. When used, these rules cause the rule to be checked against +ALL input,  not just input from the designated zone.
-

5/18/2004 - Shorewall 2.0.2b 

+

5/18/2004 - Shorewall 2.0.2b 

Corrects two problems:

    -
  1. -

    Specifying a null common action in /etc/shorewall/actions (e.g., -:REJECT) results in a startup error.

    -
    2. -
  2. -

    If /var/lib/shorewall does not exist, shorewall start fails.

    -
    3. -
-

5/15/2004 - Shorewall 2.0.2a

-

Corrects two problems:

-
    -
  1. -

    Temporary restore files were not being removed from -/var/lib/shorewall. These files have names of the form -'restore-nnnnn'.  You can remove files that have accumulated with -the command:
    +

  2. Specifying a null common action in /etc/shorewall/actions +(e.g., :REJECT) results in a startup error.

    -    rm -f /var/lib/shorewall/restore-[0-9]*

    3. -
  3. -

    The restore script did not load kernel modules. The result was -that after a cold load, applications like FTP and IRC DCC didn't work.
    +

  4. If /var/lib/shorewall does not exist, shorewall start fails.
    +
    5. +
+

5/15/2004 - Shorewall 2.0.2a
+

+

Corrects two problems:
+

+
    +
  1. Temporary restore files were not being removed from +/var/lib/shorewall. These files have names of the form +'restore-nnnnn'.  +You can remove files that have accumulated with the command:
    +
    +    rm -f /var/lib/shorewall/restore-[0-9]*
    +
    +
    2. +
  2. The restore script did not load kernel modules. The result +was that after a cold load, applications like FTP and IRC DCC didn't +work.

    To correct:

        1) Install 2.0.2a
        2) "shorewall restart"
    -    3) "shorewall save"

    -
    3. +    3) "shorewall save"
-

5/13/2004 - Shorewall 2.0.2 

-

Problems Corrected since 2.0.1

+

5/13/2004 - Shorewall 2.0.2 

+

Problems Corrected since 2.0.1
+

    -
  1. -

    The /etc/init.d/shorewall script -installed on Debian by install.sh failed silently due to a missing file +

  2. The /etc/init.d/shorewall script installed on Debian by +install.sh failed silently due to a missing file (/usr/share/shorewall/wait4ifup). That file is not part of the normal -Shorewall distribution and is provided by the Debian maintainer.

    -
    3. -
  3. -

    A meaningless warning message out of -the proxyarp file processing has been eliminated.

    -
    4. -
  4. -

    The "shorewall delete" command now correctly removes all dynamic -rules pertaining to the host(s) being deleted. Thanks to Stefan Engel -for this correction.

    -
    5. +Shorewall distribution and is provided by the Debian maintainer. +
  5. A meaningless warning message out of the proxyarp file +processing has been eliminated.
    6. +
  6. The "shorewall delete" command now correctly removes all +dynamic rules pertaining to the host(s) being deleted. Thanks to Stefan +Engel for this correction.
-

Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:

+Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:
    -
  1. -

    Extension Scripts -- In order for extension scripts to work +

  2. Extension Scripts -- In order for extension scripts to work properly with the new iptables-save/restore integration (see New Feature 1 below), some change may be required to your extension scripts. If your extension scripts are executing commands other than @@ -2680,18 +2474,16 @@ quotes. This applies to all of the functions described here.
    C. ensure_and_save_command() -- runs the passed command. If the command fails, the firewall is restored to it's prior saved state and the operation is terminated. If the command succeeds, the command is -written to the restore file.

    -
    3. -
  3. -

    Dynamic Zone support -- If you don't need to use the "shorewall -add" and "shorewall delete commands, you should set DYNAMIC_ZONES=No in -/etc/shorewall/shorewall.conf.

    +written to the restore file.
    +
    4. +
  4. Dynamic Zone support -- If you don't need to use the +"shorewall add" and "shorewall delete commands, you should set +DYNAMIC_ZONES=No in /etc/shorewall/shorewall.conf.
-

New Features:

+New Features:
    -
  1. -

    Shorewall has now been integrated with +

  2. Shorewall has now been integrated with iptables-save/iptables-restore to provide very fast start and restart. The elements of this integration are as follows:

    @@ -2720,17 +2512,17 @@ f) If you have previously saved the running configuration and want Shorewall to discard it, use the 'shorewall forget' command. WARNING: iptables 1.2.9 is broken with respect to iptables-save; if your kernel has connection tracking match support, you must patch iptables 1.2.9 -with the iptables patch availale from the Shorewall errata page.

    +with the iptables patch availale from the Shorewall errata page.
    +
    3. -
  3. -

    The previous implementation of dynamic zones was difficult to -maintain. I have changed the code to make dynamic zones optional under -the control of the DYNAMIC_ZONES option in -/etc/shorewall/shorewall.conf.

    +
  4. The previous implementation of dynamic zones was difficult +to maintain. I have changed the code to make dynamic zones optional +under the control of the DYNAMIC_ZONES option in +/etc/shorewall/shorewall.conf.
    +
    5. -
  5. -

    In earlier Shorewall 2.0 releases, Shorewall searches in order -the following directories for configuration files.
    +

  6. In earlier Shorewall 2.0 releases, Shorewall searches in +order the following directories for configuration files.

    a) The directory specified in a 'try' command or specified using the -c option.
    @@ -2755,25 +2547,26 @@ directory specified via -c or in a try command, in /etc/shorewall or in
    For distribution packagers, the default CONFIG_PATH is set in /usr/share/shorewall/configpath. You can customize this file to have a -default that differs from mine.

    +default that differs from mine.
    +
    7. -
  7. -

    Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL -column would only take effect if the ALL INTERFACES column also +

  8. Previously, in /etc/shorewall/nat a Yes (or yes) in the +LOCAL column would only take effect if the ALL INTERFACES column also contained Yes or yes. Now, the LOCAL columns contents are treated -independently of the contents of the ALL INTERFACES column.

    +independently of the contents of the ALL INTERFACES column.
    +
    9. -
  9. -

    The folks at Mandrake have created yet another kernel module -naming convention (module names end in "ko.gz"). As a consequence, -beginning with this release, if MODULE_SUFFIX isn't specified in -shorewall.conf, then the default value is "o gz ko o.gz ko.gz".

    +
  10. The folks at Mandrake have created yet another kernel +module naming convention (module names end in "ko.gz"). As a +consequence, beginning with this release, if MODULE_SUFFIX isn't +specified in shorewall.conf, then the default value is "o gz ko o.gz +ko.gz".
    +
    11. -
  11. -

    An updated bogons file is included in this release.

    +
  12. An updated bogons file is included in this release.
    +
    13. -
  13. -

    In /etc/shorewall/rules and in action files generated from +

  14. In /etc/shorewall/rules and in action files generated from /usr/share/shorewall/action.template, rules that perform logging can specify an optional "log tag". A log tag is a string of alphanumeric characters and is specified by following the log level with ":" and the @@ -2791,21 +2584,21 @@ prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate "Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum length of a log prefix supported by iptables is 29 characters; if a larger prefix is generated, Shorewall will issue a warning message and -will truncate the prefix to 29 characters.

    +will truncate the prefix to 29 characters.
    +
    15. -
  15. -

    A new "-q" option has been added to /sbin/shorewall commands. It -causes the start, restart, check and refresh commands to produce much -less output so that warning messages are more visible (when testing -this change, I discovered a bug where a bogus warning message was being -generated).

    +
  16. A new "-q" option has been added to /sbin/shorewall +commands. It causes the start, restart, check and refresh commands to +produce much less output so that warning messages are more visible +(when testing this change, I discovered a bug where a bogus warning +message was being generated).
    +
    17. -
  17. -

    Shorewall now uses 'modprobe' to load kernel modules if that -utility is available in the PATH; otherwise, 'insmod' is used.

    +
  18. Shorewall now uses 'modprobe' to load kernel modules if +that utility is available in the PATH; otherwise, 'insmod' is used.
    +
    19. -
  19. -

    It is now possible to restrict entries in the +

  20. It is now possible to restrict entries in the /etc/shorewall/masq file to particular protocols and destination port(s). Two new columns (PROTO and PORT(S)) have been added to the file.
    @@ -2831,70 +2624,66 @@ the progress message at "shorewall start" would be:
           To 0.0.0.0/0 (tcp 25) from 10.0.0.0/8 through eth0 using 206.124.146.177
           To 0.0.0.0/0 (all) from 10.0.0.0/8 -through eth0 using 206.124.146.176

    +through eth0 using 206.124.146.176
    +
    21. -
  21. -

    Two new actions are available in the /etc/shorewall/rules file.
    +

  22. Two new actions are available in the /etc/shorewall/rules +file.

        ACCEPT+    -- Behaves like ACCEPT with the exception that it exempts matching connections from subsequent DNAT[-] and REDIRECT[-] rules.
        NONAT      -- Exempts -matching connections from subsequent DNAT[-] and REDIRECT[-] rules.

    +matching connections from subsequent DNAT[-] and REDIRECT[-] rules.
    +
    23. -
  23. -

    A new extension script 'initdone' has been added. This script is -invoked at the same point as the 'common' script was previously and is -useful for users who mis-used that script under Shorewall 1.x (the -script was intended for adding rules to the 'common' chain but many -users treated it as a script for adding rules before Shorewall's).

    +
  24. A new extension script 'initdone' has been added. This +script is invoked at the same point as the 'common' script was +previously and is useful for users who mis-used that script under +Shorewall 1.x (the script was intended for adding rules to the 'common' +chain but many users treated it as a script for adding rules before +Shorewall's).
    +
    25. -
  25. -

    Installing/Upgrading Shorewall on Slackware has been improved. -Slackware users must use the tarball and must modify settings in the -install.sh script before running it as follows:
    +

  26. Installing/Upgrading Shorewall on Slackware has been +improved. Slackware users must use the tarball and must modify settings +in the install.sh script before running it as follows:

        DEST="/etc/rc.d"
        INIT="rc.firewall"

    -Thanks to Alex Wilms for helping with this change.

    -
    27. +Thanks to Alex Wilms for helping with this change.
-

4/17/2004 - Presentation at LinuxFest NW

-

Today I gave a presentation at LinuxFest NW in Bellingham. The +

4/17/2004 - Presentation at +LinuxFest NW
+

+Today I gave a presentation at LinuxFest NW in Bellingham. The presentation was entitled "Shorewall -and the Enterprise" and described the history of Shorewall -and gave an overview of its features.

-

4/5/2004 - Shorewall 2.0.1

-

Problems Corrected since 2.0.0

+and the Enterprise" and described the history of Shorewall and gave +an overview of its features. +

4/5/2004 - Shorewall 2.0.1
+

+Problems Corrected since 2.0.0
+
    -
  1. -

    Using actions in the manner -recommended in the documentation results in a Warning that the rule is -a policy.

    -
    2. -
  2. -

    When a zone on a single interface is -defined using /etc/shorewall/hosts, superfluous rules are generated in -the <zone>_frwd chain.

    -
    3. -
  3. -

    Thanks to Sean Mathews, a -long-standing problem with Proxy ARP and IPSEC has been corrected. -Thanks Sean!!!

    -
    4. -
  4. -

    The "shorewall show log" and "shorewall logwatch" commands -incorrectly displayed type 3 ICMP packets.

    +
  5. Using actions in the manner recommended in the +documentation results in a Warning that the rule is a policy.
    6. +
  6. When a zone on a single interface is defined using +/etc/shorewall/hosts, superfluous rules are generated in the +<zone>_frwd chain.
    7. +
  7. Thanks to Sean Mathews, a long-standing problem with Proxy +ARP and IPSEC has been corrected. Thanks Sean!!!
    8. +
  8. The "shorewall show log" and "shorewall logwatch" commands +incorrectly displayed type 3 ICMP packets.
-

Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:

+Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:
+
    -
  1. -

    The function of 'norfc1918' is now split between that option and -a new 'nobogons' option.
    +

  2. The function of 'norfc1918' is now split between that +option and a new 'nobogons' option.

    The rfc1918 file released with Shorewall now contains entries for only those three address ranges reserved by RFC 1918. A 'nobogons' interface @@ -2910,18 +2699,18 @@ The level at which bogon packets are logged is specified in the new BOGON_LOG_LEVEL variable in shorewall.conf. If that option is not specified or is specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon packets whose TARGET is 'logdrop' in /usr/share/shorewall/bogons are -logged at the 'info' level.

    -
    3. +logged at the 'info' level.
-

New Features:

+New Features:
+
    -
  1. -

    Support for Bridging Firewalls has been added. For details, see
    +

  2. Support for Bridging Firewalls has been added. For details, +see
    +
    + http://shorewall.net/bridge.html

    - http://shorewall.net/bridge.html

    3. -
  3. -

    Support for NETMAP has been added. NETMAP allows NAT to be +

  4. Support for NETMAP has been added. NETMAP allows NAT to be defined between two network:

               @@ -2932,12 +2721,12 @@ a.b.c.2    -> x.y.z.2
    a.b.c.3    -> x.y.z.3
               ...

    -  http://shorewall.net/netmap.htm

    +  http://shorewall.net/netmap.htm
    +
    5. -
  5. -

    The /sbin/shorewall program now accepts a "-x" option to cause -iptables to print out the actual packet and byte counts rather than -abbreviated counts such as "13MB".
    +

  6. The /sbin/shorewall program now accepts a "-x" option to +cause iptables to print out the actual packet and byte counts rather +than abbreviated counts such as "13MB".

    Commands affected by this are:

    @@ -2950,35 +2739,31 @@ shorewall -x show nat
                shorewall -x status
                -shorewall -x monitor [ <interval> ]

    +shorewall -x monitor [ <interval> ]
    +
    7. -
  7. -

    Shorewall now traps two common zone -definition errors:

    +
  8. Shorewall now traps two common zone definition errors:
      -
    • -

      Including the firewall zone in a -/etc/shorewall/hosts record.

      -
      • -
    • -

      Defining an interface for a zone in both -/etc/shorewall/interfaces and /etc/shorewall/hosts.

      +
    • Including the firewall zone in a /etc/shorewall/hosts +record.
      • +
    • Defining an interface for a zone in both +/etc/shorewall/interfaces and /etc/shorewall/hosts.
      +
    9. -
  9. -

    In the second case, the following will appear during "shorewall -[re]start" or "shorewall check":
    +

  10. In the second case, the following will appear during +"shorewall [re]start" or "shorewall check":

       Determining Hosts in Zones...
          ...
          Error: Invalid zone definition for zone <name of zone>
    -   Terminated

    +   Terminated
    +
    11. -
  11. -

    To support bridging, the following options have been added to -entries in /etc/shorewall/hosts:
    +

  12. To support bridging, the following options have been added +to entries in /etc/shorewall/hosts:

               norfc1918
               nobogons
    @@ -2996,93 +2781,74 @@ the entry refers to a bridge port.
    OPTIONS
       net     br0:eth0     -norfc1918,nobogons,blacklist,tcpflags,nosmurfs

    -
    13. +norfc1918,nobogons,blacklist,tcpflags,nosmurfs

3/14/2004 - Shorewall 2.0.0b 

-

Corrects two problems:

+Corrects two problems:
    -
  1. -

    Thanks to Sean Mathews, the -long-standing problem with Proxy ARP and IPSEC has been eliminated!

    -
    2. -
  2. -

    The default value of the ALL INTERFACES column in +

  3. Thanks to Sean Mathews, the long-standing problem with +Proxy ARP and IPSEC has been eliminated!
    4. +
  4. The default value of the ALL INTERFACES column in /etc/shorewall/nat is documented as 'No' but the default continued to -be 'Yes' as it was in Shorewall 1.4.

    +be 'Yes' as it was in Shorewall 1.4.
-

3/14/2004 - Shorewall 2.0.0a 

-

Corrects one problem:

+

3/14/2004 - Shorewall 2.0.0a 

+

Corrects one problem:
+

-

3/14/2004 - Shorewall 2.0.0 +

3/14/2004 - Shorewall 2.0.0
+

+

Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February +23, 2004
+

+

Problems Corrected since 1.4.10

-

Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February 23, -2004

-

Problems Corrected since 1.4.10

    -
  1. -

    A blank USER/GROUP column in -/etc/shorewall/tcrules no longer causes a [re]start error.

    -
    2. -
  2. -

    The 'fgrep' utility is no longer -required (caused startup problems on LEAF/Bering).

    -
    3. -
  3. -

    The "shorewall add" command no -longer inserts rules before checking of the blacklist.

    -
    4. -
  4. -

    The 'detectnets' and 'routeback' -options may now be used together with the intended effect.

    -
    5. -
  5. -

    The following syntax previously produced an error:
    +

  6. A blank USER/GROUP column in /etc/shorewall/tcrules no +longer causes a [re]start error.
    7. +
  7. The 'fgrep' utility is no longer required (caused startup +problems on LEAF/Bering).
    8. +
  8. The "shorewall add" command no longer inserts rules before +checking of the blacklist.
    9. +
  9. The 'detectnets' and 'routeback' options may now be used +together with the intended effect.
    10. +
  10. The following syntax previously produced an error:

    -DNAT  z1!z2,z3       z4...

    +DNAT  z1!z2,z3       z4...
-

Problems Corrected since RC2

+

Problems Corrected since RC2
+
+

    -
  1. -

    CONTINUE rules now work again.

    -
    2. -
  2. -

    A comment in the rules file has been corrected.

    +
  3. CONTINUE rules now work again.
    4. +
  4. A comment in the rules file has been corrected.
-

Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:

+

Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:
+

    -
  1. -

    The 'dropunclean' and 'logunclean' -interface options are no longer supported. If either option is -specified in /etc/shorewall/interfaces, an threatening message will be -generated.

    -
    2. -
  2. -

    The NAT_BEFORE_RULES option has been -removed from shorewall.conf. The behavior of Shorewall is as if -NAT_BEFORE_RULES=No had been specified. In other words, DNAT rules now -always take precidence over one-to-one NAT specifications.

    -
    3. -
  3. -

    The default value for the ALL -INTERFACES column in /etc/shorewall/nat has changed. In Shorewall 1.*, -if the column was left empty, a value of "Yes" was assumed. This has -been changed so that a value of "No" is now assumed.

    -
    4. -
  4. -

    The following files don't exist in Shorewall 2.0:
    +

  5. The 'dropunclean' and 'logunclean' interface options are no +longer supported. If either option is specified in +/etc/shorewall/interfaces, an threatening message will be generated.
    6. +
  6. The NAT_BEFORE_RULES option has been removed from +shorewall.conf. The behavior of Shorewall is as if NAT_BEFORE_RULES=No +had been specified. In other words, DNAT rules now always take +precidence over one-to-one NAT specifications.
    7. +
  7. The default value for the ALL INTERFACES column in +/etc/shorewall/nat has changed. In Shorewall 1.*, if the column was +left empty, a value of "Yes" was assumed. This has been changed so that +a value of "No" is now assumed.
    8. +
  8. The following files don't exist in Shorewall 2.0:
    /etc/shorewall/common.def
    /etc/shorewall/common
    /etc/shorewall/icmpdef
    @@ -3140,12 +2906,12 @@ Note: The 'dropBcast' and 'dropNonSyn' actions are built into Shorewall and may not be changed.

    Beginning with version 2.0.0-Beta2, Shorewall will only create a chain -for those actions that are actually used.

    +for those actions that are actually used.
    +
    9. -
  9. -

    The /etc/shorewall directory no -longer contains a 'users' file or a 'usersets' file. Similar -functionality is now available using user-defined actions.
    +

  10. The /etc/shorewall directory no longer contains a 'users' +file or a 'usersets' file. Similar functionality is now available using +user-defined actions.

    Now, action files created by copying /usr/share/shorewall/action.template may specify a USER and or GROUP @@ -3164,144 +2930,111 @@ may contain:
        [!]<user number>:<group name>
        [!]<user name>:<group number>
        [!]<user name>:<group name>
    - 

    + 
    11. -
  11. -

    It is no longer possible to specify rate limiting in the ACTION -column of /etc/shorewall/rules -- you must use the RATE LIMIT column.

    +
  12. It is no longer possible to specify rate limiting in the +ACTION column of /etc/shorewall/rules -- you must use the RATE LIMIT +column.
    +
    13. -
  13. -

    Depending on which method you use to upgrade, if you have your -own version of /etc/shorewall/rfc1918, you may have to take special -action to restore it after the upgrade. Look for +

  14. Depending on which method you use to upgrade, if you have +your own version of /etc/shorewall/rfc1918, you may have to take +special action to restore it after the upgrade. Look for /etc/shorewall/rfc1918*, locate the proper file and rename it back to /etc/shorewall/rfc1918. The contents of that file will supercede the -contents of /usr/share/shorewall/rfc1918.

    -
    15. +contents of /usr/share/shorewall/rfc1918.
-

New Features:

+

New Features:
+

    -
  1. -

    The INCLUDE directive now allows -absolute file names.

    -
    2. -
  2. -

    A 'nosmurfs' interface option has -been added to /etc/shorewall/interfaces. When specified for an -interface, this option causes smurfs (packets with a broadcast address -as their source) to be dropped and optionally logged (based on the -setting of a new SMURF_LOG_LEVEL option in shorewall.conf).

    -
    3. -
  3. -

    fw->fw traffic may now be -controlled by Shorewall. There is no need to define the loopback -interface in /etc/shorewall/interfaces; you simply add a fw->fw -policy and fw->fw rules. If you have neither a fw->fw policy nor -fw->fw rules, all fw->fw traffic is allowed.

    -
    4. -
  4. -

    There is a new PERSISTENT column in -the proxyarp file. A value of "Yes" in this column means that the route -added by Shorewall for this host will remain after a "shorewall stop" -or "shorewall clear".

    -
    5. -
  5. -

    "trace" is now a synonym for "debug" in /sbin/shorewall +

  6. The INCLUDE directive now allows absolute file names.
    7. +
  7. A 'nosmurfs' interface option has been added to +/etc/shorewall/interfaces. When specified for an interface, this option +causes smurfs (packets with a broadcast address as their source) to be +dropped and optionally logged (based on the setting of a new +SMURF_LOG_LEVEL option in shorewall.conf).
    8. +
  8. fw->fw traffic may now be controlled by Shorewall. There +is no need to define the loopback interface in +/etc/shorewall/interfaces; you simply add a fw->fw policy and +fw->fw rules. If you have neither a fw->fw policy nor fw->fw +rules, all fw->fw traffic is allowed.
    9. +
  9. There is a new PERSISTENT column in the proxyarp file. A +value of "Yes" in this column means that the route added by Shorewall +for this host will remain after a "shorewall stop" or "shorewall clear".
    10. +
  10. "trace" is now a synonym for "debug" in /sbin/shorewall commands. So to trace the "start" command, you could enter:

    shorewall trace start 2> /tmp/trace

    -The trace information would be written to the file /tmp/trace.

    +The trace information would be written to the file /tmp/trace.
    +
    11. -
  11. -

    When defining an ipsec tunnel in -/etc/shorewall/tunnels, if you follow the tunnel type ("ipsec" or -"ipsecnet") with ":noah" (e.g., "ipsec:noah"), then Shorewall will only -create rules for ESP (protocol 50) and will not create rules for AH -(protocol 51).

    -
    12. -
  12. -

    A new DISABLE_IPV6 option has been -added to shorewall.conf. When this option is set to "Yes", Shorewall -will set the policy for the IPv6 INPUT, OUTPUT and FORWARD chains to -DROP during "shorewall [re]start" and "shorewall stop". Regardless of -the setting of this variable, "shorewall clear" will silently attempt -to set these policies to ACCEPT.
    +

  13. When defining an ipsec tunnel in /etc/shorewall/tunnels, if +you follow the tunnel type ("ipsec" or "ipsecnet") with ":noah" (e.g., +"ipsec:noah"), then Shorewall will only create rules for ESP (protocol +50) and will not create rules for AH (protocol 51).
    14. +
  14. A new DISABLE_IPV6 option has been added to shorewall.conf. +When this option is set to "Yes", Shorewall will set the policy for the +IPv6 INPUT, OUTPUT and FORWARD chains to DROP during "shorewall +[re]start" and "shorewall stop". Regardless of the setting of this +variable, "shorewall clear" will silently attempt to set these policies +to ACCEPT.

    If this option is not set in your existing shorewall.conf then a setting of DISABLE_IPV6=No is assumed in which case, Shorewall will not -touch any IPv6 settings except during "shorewall clear".

    -
    15. -
  15. -

    The CONTINUE target is now available in action definitions. +touch any IPv6 settings except during "shorewall clear".

    16. +
  16. The CONTINUE target is now available in action definitions. CONTINUE terminates processing of the current action and returns to the -point where that action was invoked.

    -
    17. +point where that action was invoked.

2/15/2004 - Shorewall 1.4.10c 

-

Corrects one problem:

-

Entries in /etc/shorewall/tcrules with an empty USER/GROUP column -would cause a startup error.

-

2/12/2004 - Shorewall 1.4.10b 

-

Corrects one problem:

+

Corrects one problem:
+

+Entries in /etc/shorewall/tcrules with an empty USER/GROUP column would +cause a startup error. +

2/12/2004 - Shorewall 1.4.10b 

+

Corrects one problem:
+

-

2/8/2004 - Shorewall 1.4.10a 

-

Corrects two problems:

+

2/8/2004 - Shorewall 1.4.10a 

+

Corrects two problems:
+

1/30/2004 - Shorewall 1.4.10

Problems Corrected since version 1.4.9

    -
  1. -

    The column descriptions in the -action.template file did not match the column headings. That has been -corrected.

    -
    2. -
  2. -

    The presence of IPV6 addresses on -devices generated error messages during [re]start if ADD_IP_ALIASES=Yes -or ADD_SNAT_ALIASES=Yes are specified in /etc/shorewall/shorewall.conf. -These messages have been eliminated.

    -
    3. -
  3. -

    The CONTINUE action in -/etc/shorewall/rules now works correctly. A couple of problems -involving rate limiting have been corrected. These bug fixes courtesy -of Steven Jan Springl.

    -
    4. -
  4. -

    Shorewall now tried to avoid sending -an ICMP response to broadcasts and smurfs.

    -
    5. -
  5. -

    Specifying "-" or "all" in the PROTO column of an action no -longer causes a startup error.

    -
    6. +
  6. The column descriptions in the action.template file did not +match the column headings. That has been corrected.
    7. +
  7. The presence of IPV6 addresses on devices generated error +messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes +are specified in /etc/shorewall/shorewall.conf. These messages have +been eliminated.
    8. +
  8. The CONTINUE action in /etc/shorewall/rules now +works +correctly. A couple of problems involving rate limiting have been +corrected. These bug fixes courtesy of Steven Jan Springl.
    9. +
  9. Shorewall now tried to avoid sending an ICMP response to +broadcasts and smurfs.
    10. +
  10. Specifying "-" or "all" in the PROTO column of an action no +longer causes a startup error.
-

Migragion Issues:
+Migragion Issues:

    None.

-New -Features:

+New Features:
    -
  1. -

    The INTERFACE column in the /etc/shorewall/masq file may now -specify a destination list.
    +

  2. The INTERFACE column in the /etc/shorewall/masq file may +now specify a destination list.

    Example:

    @@ -3310,10 +3043,11 @@ Example:
        eth0:192.0.2.3,192.0.2.16/28    eth1

    If the list begins with "!" then SNAT will occur only if the -destination IP address is NOT included in the list.

    +destination IP address is NOT included in the list.
    +
    3. -
  3. -

    Output traffic control rules (those with the firewall as the +

  4. Output traffic control rules (those with the firewall as +the source) may now be qualified by the effective userid and/or effective group id of the program generating the output. This feature is courtesy of  Frédéric LESPEZ.
    @@ -3327,57 +3061,47 @@ name or number>]
    The colon is optionnal when specifying only a user.

           Examples : john: / john / :users / -john:users

    +john:users
    +
    5. -
  5. -

    A "detectnets" interface option has been added for entries in +

  6. A "detectnets" interface option has been added for entries +in /etc/shorewall/interfaces. This option automatically taylors the definition of the zone named in the ZONE column to include just  -those hosts that have routes through the interface named in the -INTERFACE column. The named interface must be UP when Shorewall is -[re]started.
    +those +hosts that have routes through the interface named in the INTERFACE +column. The named interface must be UP when Shorewall is [re]started.

     WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE! -  

    -
    7. +  

1/27/2004 - Shorewall 1.4.10 RC3

http://shorewall.net/pub/shorewall/Beta
-ftp://shorewall.net/pub/shorewall/Beta

+ftp://shorewall.net/pub/shorewall/Beta
+

Problems Corrected since version 1.4.9

    -
  1. -

    The column descriptions in the -action.template file did not match the column headings. That has been -corrected.

    -
    2. -
  2. -

    The presence of IPV6 addresses on -devices generated error messages during [re]start if ADD_IP_ALIASES=Yes -or ADD_SNAT_ALIASES=Yes are specified in /etc/shorewall/shorewall.conf. -These messages have been eliminated.

    -
    3. -
  3. -

    The CONTINUE action in -/etc/shorewall/rules now works correctly. A couple of problems -involving rate limiting have been corrected. These bug fixes courtesy -of Steven Jan Springl.

    -
    4. -
  4. -

    Shorewall now tried to avoid sending an ICMP response to -broadcasts and smurfs.

    +
  5. The column descriptions in the action.template file did not +match the column headings. That has been corrected.
    6. +
  6. The presence of IPV6 addresses on devices generated error +messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes +are specified in /etc/shorewall/shorewall.conf. These messages have +been eliminated.
    7. +
  7. The CONTINUE action in /etc/shorewall/rules now works +correctly. A couple of problems involving rate limiting have been +corrected. These bug fixes courtesy of Steven Jan Springl.
    8. +
  8. Shorewall now tried to avoid sending an ICMP response to +broadcasts and smurfs.
-

Migragion Issues:
+Migragion Issues:

    None.

-New -Features:

+New Features:
    -
  1. -

    The INTERFACE column in the /etc/shorewall/masq file may now -specify a destination list.
    +

  2. The INTERFACE column in the /etc/shorewall/masq file may +now specify a destination list.

    Example:

    @@ -3386,10 +3110,11 @@ Example:
        eth0:192.0.2.3,192.0.2.16/28    eth1

    If the list begins with "!" then SNAT will occur only if the -destination IP address is NOT included in the list.

    +destination IP address is NOT included in the list.
    +
    3. -
  3. -

    Output traffic control rules (those with the firewall as the +

  4. Output traffic control rules (those with the firewall as +the source) may now be qualified by the effective userid and/or effective group id of the program generating the output. This feature is courtesy of  Frédéric LESPEZ.
    @@ -3403,47 +3128,41 @@ name or number>]
    The colon is optionnal when specifying only a user.

           Examples : john: / john / :users / -john:users

    +john:users
    +
    5. -
  5. -

    A "detectnets" interface option has been added for entries in +

  6. A "detectnets" interface option has been added for entries +in /etc/shorewall/interfaces. This option automatically taylors the definition of the zone named in the ZONE column to include just  -those hosts that have routes through the interface named in the -INTERFACE column. The named interface must be UP when Shorewall is -[re]started.
    +those +hosts that have routes through the interface named in the INTERFACE +column. The named interface must be UP when Shorewall is [re]started.

     WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE! -  

    -
    7. +  
-

1/24/2004 - Shorewall 1.4.10 RC2 

+

1/24/2004 - Shorewall 1.4.10 RC2 

http://shorewall.net/pub/shorewall/Beta
-ftp://shorewall.net/pub/shorewall/Beta

+ftp://shorewall.net/pub/shorewall/Beta
+

Problems Corrected since version 1.4.9

    -
  1. -

    The column descriptions in the -action.template file did not match the column headings. That has been -corrected.

    -
    2. -
  2. -

    The presence of IPV6 addresses on devices generated error +

  3. The column descriptions in the action.template file did not +match the column headings. That has been corrected.
    4. +
  4. The presence of IPV6 addresses on devices generated error messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are specified in /etc/shorewall/shorewall.conf. These messages have -been eliminated.

    -
    5. +been eliminated.
-

Migragion Issues:
+Migragion Issues:

    None.

-New -Features:

+New Features:
    -
  1. -

    The INTERFACE column in the /etc/shorewall/masq file may now -specify a destination list.
    +

  2. The INTERFACE column in the /etc/shorewall/masq file may +now specify a destination list.

    Example:

    @@ -3452,13 +3171,13 @@ Example:
        eth0:192.0.2.3,192.0.2.16/28    eth1

    If the list begins with "!" then SNAT will occur only if the -destination IP address is NOT included in the list.

    +destination IP address is NOT included in the list.
    +
    3. -
  3. -

    Output traffic control rules (those with the firewall as the -source) may now be qualified by the effective userid and/or effective -group id of the program generating the output. This feature is courtesy -of  Frédéric LESPEZ.
    +

  4. Output traffic control rules (those with the firewall as +the source) may now be qualified by the effective userid and/or +effective group id of the program generating the output. This feature +is courtesy of  Frédéric LESPEZ.

    A new USER column has been added to /etc/shorewall/tcrules. It may contain :
    @@ -3469,43 +3188,35 @@ name or number>]
    The colon is optionnal when specifying only a user.

           Examples : john: / john / :users / -john:users

    +john:users
    +
    5. -
  5. -

    A "detectnets" interface option has been added for entries in +

  6. A "detectnets" interface option has been added for entries in /etc/shorewall/interfaces. This option automatically taylors the definition of the zone named in the ZONE column to include just  -those hosts that have routes through the interface named in the -INTERFACE column. The named interface must be UP when Shorewall is -[re]started.
    +those +hosts that have routes through the interface named in the INTERFACE +column. The named interface must be UP when Shorewall is [re]started.

    - WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!

    -
    7. + WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
-

1/22/2004 - Shorewall 1.4.10 RC1 

+

1/22/2004 - Shorewall 1.4.10 RC1 

Problems Corrected since version 1.4.9

    -
  1. -

    The column descriptions in the -action.template file did not match the column headings. That has been -corrected.

    -
    2. -
  2. -

    The presence of IPV6 addresses on devices generated error +

  3. The column descriptions in the action.template file did not match +the column headings. That has been corrected.
    4. +
  4. The presence of IPV6 addresses on devices generated error messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are specified in /etc/shorewall/shorewall.conf. These messages have -been eliminated.

    -
    5. +been eliminated.
-

Migragion Issues:
+Migragion Issues:

    None.

-New -Features:

+New Features:
    -
  1. -

    The INTERFACE column in the /etc/shorewall/masq file may now +

  2. The INTERFACE column in the /etc/shorewall/masq file may now specify a destination list.

    Example:
    @@ -3515,10 +3226,10 @@ Example:
        eth0:192.0.2.3,192.0.2.16/28    eth1

    If the list begins with "!" then SNAT will occur only if the -destination IP address is NOT included in the list.

    +destination IP address is NOT included in the list.
    +
    3. -
  3. -

    Output traffic control rules (those with the firewall as the +

  4. Output traffic control rules (those with the firewall as the source) may now be qualified by the effective userid and/or effective group id of the program generating the output. This feature is courtesy of  Frédéric LESPEZ.
    @@ -3532,96 +3243,85 @@ name or number>]
    The colon is optionnal when specifying only a user.

           Examples : john: / john / :users / -john:users   

    +john:users   
-

1/13/2004 - Shorewall 1.4.9

-

Problems Corrected since version 1.4.8:

+

1/13/2004 - Shorewall 1.4.9
+

+

Problems Corrected since version 1.4.8:
+

    -
  1. -

    There has been a low continuing -level of confusion over the terms "Source NAT" (SNAT) and "Static NAT". -To avoid future confusion, all instances of "Static NAT" have been -replaced with "One-to-one NAT" in the documentation and configuration -files.

    -
    2. -
  2. -

    The description of NEWNOTSYN in -shorewall.conf has been reworded for clarity.

    -
    3. -
  3. -

    Wild-card rules (those involving -"all" as SOURCE or DEST) will no longer produce an error if they -attempt to add a rule that would override a NONE policy. The logic for -expanding these wild-card rules now simply skips those (SOURCE,DEST) -pairs that have a NONE policy.

    -
    4. -
  4. -

    DNAT rules that also specified SNAT now work reliably. -Previously, there were cases where the SNAT specification was -effectively ignored.

    -
    5. +
  5. There has been a low continuing level of confusion over the +terms "Source NAT" (SNAT) and "Static NAT". To avoid future +confusion, all instances of "Static NAT" have been replaced with +"One-to-one NAT" in the documentation and configuration files.
    6. +
  6. The description of NEWNOTSYN in shorewall.conf has been +reworded for clarity.
    7. +
  7. Wild-card rules (those involving "all" as SOURCE or DEST) +will +no longer produce an error if they attempt to add a rule that would +override a NONE policy. The logic for expanding these wild-card +rules now simply skips those (SOURCE,DEST) pairs that have a NONE +policy.
    8. +
  8. DNAT rules that also specified SNAT now work reliably. +Previously, +there were cases where the SNAT specification was effectively ignored.

Migration Issues:

    None.

-New -Features:

+New Features:
+

    -
  1. -

    The documentation has been -completely rebased to Docbook XML. The documentation is now released as -separate HTML and XML packages.

    -
    2. -
  2. -

    To cut down on the number of "Why -are these ports closed rather than stealthed?" questions, the -SMB-related rules in /etc/shorewall/common.def have been changed from -'reject' to 'DROP'.

    -
    3. -
  3. -

    For easier identification, packets -logged under the 'norfc1918' interface option are now logged out of -chains named 'rfc1918'. Previously, such packets were logged under -chains named 'logdrop'.

    -
    4. -
  4. -

    Distributors and developers seem to -be regularly inventing new naming conventions for kernel modules. To -avoid the need to change Shorewall code for each new convention, the -MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX -may be set to the suffix for module names in your particular -distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall -will use the list "o gz ko o.gz".
    +

  5. The documentation has been completely rebased to Docbook +XML. The +documentation is now released as separate HTML and XML packages.
    6. +
  6. To cut down on the number of "Why are these ports closed +rather +than stealthed?" questions, the SMB-related rules in +/etc/shorewall/common.def have been changed from 'reject' to +'DROP'.
    7. +
  7. For easier identification, packets logged under the +'norfc1918' +interface option are now logged out of chains named 'rfc1918'. +Previously, such packets were logged under chains named +'logdrop'.
    8. +
  8. Distributors and developers seem to be regularly inventing +new +naming conventions for kernel modules. To avoid the need to change +Shorewall code for each new convention, the MODULE_SUFFIX option +has been added to shorewall.conf. MODULE_SUFFIX may be set to the +suffix for module names in your particular distribution. If +MODULE_SUFFIX is not set in shorewall.conf, Shorewall will use the +list "o gz ko o.gz".

    To see what suffix is used by your distribution:

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

    -All of the files listed should have the same suffix (extension). Set -MODULE_SUFFIX to that suffix.
    +All of the files listed should have the same suffix (extension). +Set MODULE_SUFFIX to that suffix.

    Examples:

         If all files end in ".kzo" then set MODULE_SUFFIX="kzo"
         If all files end in ".kz.o" then set -MODULE_SUFFIX="kz.o"

    -
    9. -
  9. -

    Support for user defined rule -ACTIONS has been implemented through two new files:
    +MODULE_SUFFIX="kz.o"

    10. +
  10. Support for user defined rule ACTIONS has been implemented +through two new files:

    /etc/shorewall/actions - used to list the user-defined ACTIONS.
    -/etc/shorewall/action.template - For each user defined <action>, -copy this file to /etc/shorewall/action.<action> and add the -appropriate rules for that <action>. Once an <action> has -been defined, it may be used like any of the builtin ACTIONS (ACCEPT, -DROP, etc.) in /etc/shorewall/rules.
    +/etc/shorewall/action.template - For each user defined +<action>, copy this file to +/etc/shorewall/action.<action> and add the appropriate rules +for that <action>. Once an <action> has been defined, +it may be used like any of the builtin ACTIONS (ACCEPT, DROP, etc.) +in /etc/shorewall/rules.

    -Example: You want an action that logs a packet at the 'info' level and -accepts the connection.
    +Example: You want an action that logs a packet at the 'info' level +and accepts the connection.

    In /etc/shorewall/actions, you would add:

    @@ -3629,15 +3329,15 @@ In /etc/shorewall/actions, you would add:

    You would then copy /etc/shorewall/action.template to /etc/shorewall/action.LogAndAccept and in that file, you would add the -two rules:
    +two +rules:
            LOG:info
    -        ACCEPT

    -
    11. -
  11. -

    The default value for NEWNOTSYN in -shorewall.conf is now "Yes" (non-syn TCP packets that are not part of -an existing connection are filtered according to the rules and policies -rather than being dropped). I have made this change for two reasons:
    +        ACCEPT

    12. +
  12. The default value for NEWNOTSYN in shorewall.conf is now +"Yes" (non-syn +TCP packets that are not part of an existing connection are filtered +according to the rules and policies rather than being dropped). I have +made this change for two reasons:

    a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any timeout during TCP session tear down results in the firewall @@ -3646,44 +3346,34 @@ dropping all of the retries.
    b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots of confusing messages when a connection got "stuck". While I could have changed the default value of LOGNEWNOTSYN to suppress logging, I -dislike defaults that silently throw away packets.

    -
    13. -
  13. -

    The common.def file now contains an entry that silently drops -ICMP packets with a null source address. Ad Koster reported a case -where these were occuring frequently as a result of a broken system on -his external network.

    -
    14. +dislike defaults that silently throw away packets. +
  14. The common.def file now contains an entry that silently drops +ICMP +packets with a null source address. Ad Koster reported a case where +these were occuring frequently as a result of a broken system on his +external network.
-

12/29/2003 - Shorewall 1.4.9 Beta 2

-

12/29/2003 - Shorewall 1.4.9 Beta 2

+
http://shorewall.net/pub/shorewall/Beta
ftp://shorewall.net/pub/shorewall/Beta -

+

Problems Corrected since version 1.4.8:

    -
  1. -

    There has been a low continuing -level of confusion over the terms "Source NAT" (SNAT) and "Static NAT". -To avoid future confusion, all instances of "Static NAT" have been -replaced with "One-to-one NAT" in the documentation and configuration -files.

    -
    2. -
  2. -

    The description of NEWNOTSYN in -shorewall.conf has been reworded for clarity.

    -
    3. -
  3. -

    Wild-card rules (those involving -"all" as SOURCE or DEST) will no longer produce an error if they -attempt to add a rule that would override a NONE policy. The logic for -expanding these wild-card rules now simply skips those (SOURCE,DEST) -pairs that have a NONE policy.

    -
    4. -
  4. -

    DNAT rules that also specified SNAT now work reliably. +

  5. There has been a low continuing level of confusion over the +terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, +all instances of "Static NAT" have been replaced with "One-to-one NAT" +in the documentation and configuration files.
    6. +
  6. The description of NEWNOTSYN in shorewall.conf has been +reworded for clarity.
    7. +
  7. Wild-card rules (those involving "all" as SOURCE or DEST) +will no longer produce an error if they attempt to add a rule that +would override a NONE policy. The logic for expanding these wild-card +rules now simply skips those (SOURCE,DEST) pairs that have a NONE +policy.
    8. +
  8. DNAT rules that also specified SNAT now work reliably. Previously, there were cases where the SNAT specification was -effectively ignored.

    +effectively ignored.

Migration Issues:

@@ -3691,31 +3381,23 @@ effectively ignored.


New Features:

    -
  1. -

    The documentation has been -completely rebased to Docbook XML. The documentation is now released as -separate HTML and XML packages.

    +
  2. The documentation has been completely rebased to Docbook +XML. The documentation is now released as separate HTML and XML +packages.
    3. -
  3. -

    To cut down on the number of "Why -are these ports closed rather than stealthed?" questions, the -SMB-related rules in /etc/shorewall/common.def have been changed from -'reject' to 'DROP'.

    -
    4. -
  4. -

    For easier identification, packets -logged under the 'norfc1918' interface option are now logged out of -chains named 'rfc1918'. Previously, such packets were logged under -chains named 'logdrop'.

    -
    5. -
  5. -

    Distributors and developers seem to -be regularly inventing new naming conventions for kernel modules. To -avoid the need to change Shorewall code for each new convention, the -MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX -may be set to the suffix for module names in your particular -distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall -will use the list "o gz ko o.gz".
    +

  6. To cut down on the number of "Why are these ports closed +rather than stealthed?" questions, the SMB-related rules in +/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.
    7. +
  7. For easier identification, packets logged under the +'norfc1918' interface option are now logged out of chains named +'rfc1918'. Previously, such packets were logged under chains named +'logdrop'.
    8. +
  8. Distributors and developers seem to be regularly inventing +new naming conventions for kernel modules. To avoid the need to change +Shorewall code for each new convention, the MODULE_SUFFIX option has +been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix +for module names in your particular distribution. If MODULE_SUFFIX is +not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".

    To see what suffix is used by your distribution:

    @@ -3729,11 +3411,9 @@ Examples:
         If all files end in ".kzo" then set MODULE_SUFFIX="kzo"
         If all files end in ".kz.o" then set -MODULE_SUFFIX="kz.o"

    -
    9. -
  9. -

    Support for user defined rule -ACTIONS has been implemented through two new files:
    +MODULE_SUFFIX="kz.o"

    10. +
  10. Support for user defined rule ACTIONS has been implemented +through two new files:

    /etc/shorewall/actions - used to list the user-defined ACTIONS.
    /etc/shorewall/action.template - For each user defined <action>, @@ -3751,14 +3431,14 @@ In /etc/shorewall/actions, you would add:

    You would then copy /etc/shorewall/action.template to /etc/shorewall/action.LogAndAccept and in that file, you would add the -two rules:
    +two +rules:
            LOG:info
    -        ACCEPT

    +        ACCEPT
    11. -
  11. -

    The default value for NEWNOTSYN in shorewall.conf is now "Yes" -(non-syn TCP packets that are not part of an existing connection are -filtered according to the rules and policies rather than being +

  12. The default value for NEWNOTSYN in shorewall.conf is now +"Yes" (non-syn TCP packets that are not part of an existing connection +are filtered according to the rules and policies rather than being dropped). I have made this change for two reasons:

    a) NEWNOTSYN=No tends to result in lots of "stuck" connections since @@ -3768,64 +3448,53 @@ dropping all of the retries.
    b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots of confusing messages when a connection got "stuck". While I could have changed the default value of LOGNEWNOTSYN to suppress logging, I -dislike defaults that silently throw away packets.

    +dislike defaults that silently throw away packets.
    +
-

12/28/2003 - www.shorewall.net/ftp.shorewall.net Back On-line -

-

Our high-capacity server has been restored to service -- please -let us know if you find -any problems.

-

12/29/2003 - Shorewall 1.4.9 Beta 1

-

12/28/2003 - www.shorewall.net/ftp.shorewall.net Back +On-line
+

+

Our high-capacity server has been restored to service -- +please let us know if you +find any problems.

+

12/29/2003 - Shorewall 1.4.9 Beta 1

+
http://shorewall.net/pub/shorewall/Beta
ftp://shorewall.net/pub/shorewall/Beta -

+

Problems Corrected since version 1.4.8:

    -
  1. -

    There has been a low continuing -level of confusion over the terms "Source NAT" (SNAT) and "Static NAT". -To avoid future confusion, all instances of "Static NAT" have been -replaced with "One-to-one NAT" in the documentation and configuration -files.

    -
    2. -
  2. -

    The description of NEWNOTSYN in -shorewall.conf has been reworded for clarity.

    -
    3. -
  3. -

    Wild-card rules (those involving "all" as SOURCE or DEST) will -no longer produce an error if they attempt to add a rule that would -override a NONE policy. The logic for expanding these wild-card rules -now simply skips those (SOURCE,DEST) pairs that have a NONE policy.

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

Migration Issues:

    None.

New Features:

    -
  1. -

    To cut down on the number of "Why -are these ports closed rather than stealthed?" questions, the -SMB-related rules in /etc/shorewall/common.def have been changed from -'reject' to 'DROP'.

    -
    2. -
  2. -

    For easier identification, packets -logged under the 'norfc1918' interface option are now logged out of -chains named 'rfc1918'. Previously, such packets were logged under -chains named 'logdrop'.

    -
    3. -
  3. -

    Distributors and developers seem to -be regularly inventing new naming conventions for kernel modules. To -avoid the need to change Shorewall code for each new convention, the -MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX -may be set to the suffix for module names in your particular -distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall -will use the list "o gz ko o.gz".
    +

  4. To cut down on the number of "Why are these ports closed +rather than stealthed?" questions, the SMB-related rules in +/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.
    5. +
  5. For easier identification, packets logged under the +'norfc1918' interface option are now logged out of chains named +'rfc1918'. Previously, such packets were logged under chains named +'logdrop'.
    6. +
  6. Distributors and developers seem to be regularly inventing +new naming conventions for kernel modules. To avoid the need to change +Shorewall code for each new convention, the MODULE_SUFFIX option has +been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix +for module names in your particular distribution. If MODULE_SUFFIX is +not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".

    To see what suffix is used by your distribution:

    @@ -3839,11 +3508,9 @@ Examples:
         If all files end in ".kzo" then set MODULE_SUFFIX="kzo"
         If all files end in ".kz.o" then set -MODULE_SUFFIX="kz.o"

    -
    7. -
  7. -

    Support for user defined rule -ACTIONS has been implemented through two new files:
    +MODULE_SUFFIX="kz.o"

    8. +
  8. Support for user defined rule ACTIONS has been implemented +through two new files:

    /etc/shorewall/actions - used to list the user-defined ACTIONS.
    /etc/shorewall/action.template - For each user defined <action>, @@ -3861,14 +3528,14 @@ In /etc/shorewall/actions, you would add:

    You would then copy /etc/shorewall/action.template to /etc/shorewall/action.LogAndAccept and in that file, you would add the -two rules:
    +two +rules:
            LOG:info
    -        ACCEPT

    +        ACCEPT
    9. -
  9. -

    The default value for NEWNOTSYN in shorewall.conf is now "Yes" -(non-syn TCP packets that are not part of an existing connection are -filtered according to the rules and policies rather than being +

  10. The default value for NEWNOTSYN in shorewall.conf is now +"Yes" (non-syn TCP packets that are not part of an existing connection +are filtered according to the rules and policies rather than being dropped). I have made this change for two reasons:

    a) NEWNOTSYN=No tends to result in lots of "stuck" connections since @@ -3878,1372 +3545,449 @@ dropping all of the retries.
    b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots of confusing messages when a connection got "stuck". While I could have changed the default value of LOGNEWNOTSYN to suppress logging, I -dislike defaults that silently throw away packets.

    -
    11. +dislike defaults that silently throw away packets.

12/03/2003 - Support Torch Passed

-

Effective today, I am reducing my participation in the day-to-day +Effective today, I am reducing my participation in the day-to-day support of Shorewall. As part of this shift to community-based Shorewall support a new Shorewall Newbies mailing list has been established to field questions and problems from new users. I will not monitor that list personally. I -will continue my active development of Shorewall and will be -available via the development list to handle development issues -- -Tom.

+will continue my active development of Shorewall and will be available +via the development list to handle development issues -- Tom.

11/07/2003 - Shorewall 1.4.8

-Problems Corrected -since version 1.4.7:

+Problems Corrected since version 1.4.7:
+

    -
  1. -

    Tuomo Soini has supplied a -correction to a problem that occurs using some versions of 'ash'. The -symptom is that "shorewall start" fails with:
    - 
    -   local: --limit: bad variable name
    -   iptables v1.2.8: Couldn't load match -`-j':/lib/iptables/libipt_-j.so:
    -   cannot open shared object file: No such file or directory
    -   Try `iptables -h' or 'iptables --help' for more -information.

    -
    2. -
  2. -

    Andres Zhoglo has supplied a correction that avoids trying to -use the multiport match iptables facility on ICMP rules.
    - 
    -   Example of rule that previously caused "shorewall start" -to fail:
    - 
    -           -ACCEPT      loc  $FW  -icmp    0,8,11,12

    -
    3. -
  3. -

    Previously, if the following error message was issued, Shorewall -was left in an inconsistent state.
    - 
    -   Error: Unable to determine the routes through interface xxx

    -
    4. -
  4. -

    Handling of the LOGUNCLEAN option in -shorewall.conf has been corrected.

    -
    5. -
  5. -

    In Shorewall 1.4.2, an optimization -was added. This optimization involved creating a chain named -"<zone>_frwd" for most zones defined using the -/etc/shorewall/hosts file. It has since been discovered that in many -cases these new chains contain redundant rules and that the -"optimization" turns out to be less than optimal. The implementation -has now been corrected.

    -
    6. -
  6. -

    When the MARK value in a tcrules -entry is followed by ":F" or ":P", the ":F" or ":P" was previously only -applied to the first Netfilter rule generated by the entry. It is now -applied to all entries.

    -
    7. -
  7. -

    An incorrect comment concerning -Debian's use of the SUBSYSLOCK option has been removed from -shorewall.conf.

    -
    8. -
  8. -

    Previously, neither the -'routefilter' interface option nor the ROUTE_FILTER parameter were -working properly. This has been corrected (thanks to Eric Bowles for -his analysis and patch). The definition of the ROUTE_FILTER option has -changed however. Previously, ROUTE_FILTER=Yes was documented as -enabling route filtering on all interfaces (which didn't work). -Beginning with this release, setting ROUTE_FILTER=Yes will enable route -filtering of all interfaces brought up while Shorewall is started. As a -consequence, ROUTE_FILTER=Yes can coexist with the use of the -'routefilter' option in the interfaces file.

    -
    9. -
  9. -

    If MAC verification was enabled on -an interface with a /32 address and a broadcast address then an error -would occur during startup.

    -
    10. -
  10. -

    The NONE policy's intended use is to -suppress the generating of rules that can't possibly be traversed. This -means that a policy of NONE is inappropriate where the source or -destination zone is $FW or "all". Shorewall now generates an error -message if such a policy is given in /etc/shorewall/policy. Previously -such a policy caused "shorewall start" to fail.

    -
    11. -
  11. -

    The 'routeback' option was broken for wildcard interfaces (e.g., -"tun+"). This has been corrected so that 'routeback' now works as -expected in this case.

    -
    12. -
-

Migration Issues:

-
    -
  1. -

    The definition of the ROUTE_FILTER option in shorewall.conf has -changed as described in item 8) above.

    -
    2. -
-

New Features:

-
    -
  1. -

    A new QUEUE action has been -introduced for rules. QUEUE allows you to pass connection requests to a -user-space filter such as ftwall (http://p2pwall.sourceforge.net). The -ftwall program allows for effective filtering of p2p applications such -as Kazaa. For example, to use ftwall to filter P2P clients in the 'loc' -zone, you would add the following rules:
    -
    -   QUEUE   loc    -     net    tcp
    -   QUEUE   loc    -     net    udp
    -   QUEUE   loc    -     fw     udp
    -
    -You would normally want to place those three rules BEFORE any ACCEPT -rules for loc->net udp or tcp.
    -
    -Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), -Shorewall will only pass connection requests (SYN packets) to user -space. This is for compatibility with ftwall.

    -
    2. -
  2. -

    A BLACKLISTNEWNONLY option has been -added to shorewall.conf. When this option is set to "Yes", the -blacklists (dynamic and static) are only consulted for new connection -requests. When set to "No" (the default if the variable is not set), -the blacklists are consulted on every packet.
    -
    -Setting this option to "No" allows blacklisting to stop existing -connections from a newly blacklisted host but is more expensive in -terms of packet processing time. This is especially true if the -blacklists contain a large number of entries.

    -
    3. -
  3. -

    Chain names used in the /etc/shorewall/accounting file may now -begin with a digit ([0-9]) and may contain embedded dashes ("-").

    -
    4. -
-

10/30/2003 - Shorewall 1.4.8 RC1

-

Given the small number of new features and the relatively few -lines of code that were changed, there will be no Beta for 1.4.8.

-

http://shorewall.net/pub/shorewall/Beta
-ftp://shorewall.net/pub/shorewall/Beta
-
-Problems -Corrected since version 1.4.7:

-
    -
  1. -

    Tuomo Soini has supplied a -correction to a problem that occurs using some versions of 'ash'. The -symptom is that "shorewall start" fails with:
    - 
    -   local: --limit: bad variable name
    -   iptables v1.2.8: Couldn't load match -`-j':/lib/iptables/libipt_-j.so:
    -   cannot open shared object file: No such file or directory
    -   Try `iptables -h' or 'iptables --help' for more -information.

    -
    2. -
  2. -

    Andres Zhoglo has supplied a correction that avoids trying to -use the multiport match iptables facility on ICMP rules.
    - 
    -   Example of rule that previously caused "shorewall start" -to fail:
    - 
    -           -ACCEPT      loc  $FW  -icmp    0,8,11,12

    -
    3. -
  3. -

    Previously, if the following error message was issued, Shorewall -was left in an inconsistent state.
    - 
    -   Error: Unable to determine the routes through interface xxx

    -
    4. -
  4. -

    Handling of the LOGUNCLEAN option in -shorewall.conf has been corrected.

    -
    5. -
  5. -

    In Shorewall 1.4.2, an optimization -was added. This optimization involved creating a chain named -"<zone>_frwd" for most zones defined using the -/etc/shorewall/hosts file. It has since been discovered that in many -cases these new chains contain redundant rules and that the -"optimization" turns out to be less than optimal. The implementation -has now been corrected.

    -
    6. -
  6. -

    When the MARK value in a tcrules -entry is followed by ":F" or ":P", the ":F" or ":P" was previously only -applied to the first Netfilter rule generated by the entry. It is now -applied to all entries.

    -
    7. -
  7. -

    An incorrect comment concerning -Debian's use of the SYBSYSLOCK option has been removed from -shorewall.conf.

    -
    8. -
  8. -

    Previously, neither the 'routefilter' interface option nor the -ROUTE_FILTER parameter were working properly. This has been corrected -(thanks to Eric Bowles for his analysis and patch). The definition of -the ROUTE_FILTER option has changed however. Previously, -ROUTE_FILTER=Yes was documented as enabling route filtering on all -interfaces (which didn't work). Beginning with this release, setting -ROUTE_FILTER=Yes will enable route filtering of all interfaces brought -up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can -coexist with the use of the 'routefilter' option in the interfaces -file.

    -
    9. -
-

Migration Issues:

-
    -
  1. -

    The definition of the ROUTE_FILTER option in shorewall.conf has -changed as described in item 8) above.

    -
    2. -
-

New Features:

-
    -
  1. -

    A new QUEUE action has been -introduced for rules. QUEUE allows you to pass connection requests to a -user-space filter such as ftwall (http://p2pwall.sourceforge.net). The -ftwall program allows for effective filtering of p2p applications such -as Kazaa. For example, to use ftwall to filter P2P clients in the 'loc' -zone, you would add the following rules:
    -
    -   QUEUE   loc    -     net    tcp
    -   QUEUE   loc    -     net    udp
    -   QUEUE   loc    -     fw     udp
    -
    -You would normally want to place those three rules BEFORE any ACCEPT -rules for loc->net udp or tcp.
    -
    -Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), -Shorewall will only pass connection requests (SYN packets) to user -space. This is for compatibility with ftwall.

    -
    2. -
  2. -

    A BLACKLISTNEWNONLY option has been -added to shorewall.conf. When this option is set to "Yes", the -blacklists (dynamic and static) are only consulted for new connection -requests. When set to "No" (the default if the variable is not set), -the blacklists are consulted on every packet.
    -
    -Setting this option to "No" allows blacklisting to stop existing -connections from a newly blacklisted host but is more expensive in -terms of packet processing time. This is especially true if the -blacklists contain a large number of entries.

    -
    3. -
  3. -

    Chain names used in the /etc/shorewall/accounting file may now -begin with a digit ([0-9]) and may contain embedded dashes ("-").

    -
    4. -
-

10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag -awards Shorewall -1.4.7c released.

-
    -
  1. -

    The saga with "<zone>_frwd" chains continues. The 1.4.7c -script produces a ruleset that should work for everyone even if it is -not quite optimal. My apologies for this ongoing mess.

    -
    2. -
-

10/24/2003 - Shorewall 1.4.7b

-

This is a bugfx rollup of the 1.4.7a fixes plus:

-
    -
  1. -

    The fix for problem 5 in 1.4.7a was wrong with the result that -"<zone>_frwd" chains might contain too few rules. That wrong code -is corrected in this release.

    -
    2. -
-

10/21/2003 - Shorewall 1.4.7a

-

This is a bugfix rollup of the following problem corrections:

-
    -
  1. -

    Tuomo Soini has supplied a correction to a problem that occurs +

  2. Tuomo Soini has supplied a correction to a problem that occurs using some versions of 'ash'. The symptom is that "shorewall start" fails with:
     
       local: --limit: bad variable name
       iptables v1.2.8: Couldn't load match `-j':/lib/iptables/libipt_-j.so:
    -   cannot open shared object file: No such file or directory
    +   cannot open shared object file: No such file or +directory
       Try `iptables -h' or 'iptables --help' for more -information.

    -
    3. -
  3. -

    Andres Zhoglo has supplied a correction that avoids trying to +information.

    4. +
  4. Andres Zhoglo has supplied a correction that avoids trying to use the multiport match iptables facility on ICMP rules.
     
    -   Example of rule that previously caused "shorewall start" -to fail:
    +   Example of rule that previously caused "shorewall +start" to fail:
     
               ACCEPT      loc  $FW  -icmp    0,8,11,12

    +icmp    0,8,11,12
    +
    5. -
  5. -

    Previously, if the following error message was issued, Shorewall -was left in an inconsistent state.
    +

  6. Previously, if the following error message was issued, +Shorewall was left in an inconsistent state.
     
    -   Error: Unable to determine the routes through interface xxx

    +   Error: Unable to determine the routes through +interface xxx
    +
    7. -
  7. -

    Handling of the LOGUNCLEAN option in -shorewall.conf has been corrected.

    -
    8. -
  8. -

    In Shorewall 1.4.2, an optimization -was added. This optimization involved creating a chain named -"<zone>_frwd" for most zones defined using the -/etc/shorewall/hosts file. It has since been discovered that in many -cases these new chains contain redundant rules and that the -"optimization" turns out to be less than optimal. The implementation -has now been corrected.

    -
    9. -
  9. -

    When the MARK value in a tcrules entry is followed by ":F" or +

  10. Handling of the LOGUNCLEAN option in shorewall.conf has been +corrected.
    11. +
  11. In Shorewall 1.4.2, an optimization was added. This +optimization involved creating a chain named "<zone>_frwd" +for most zones defined using the /etc/shorewall/hosts file. It has +since been discovered that in many cases these new chains contain +redundant rules and that the "optimization" turns out to be less +than optimal. The implementation has now been corrected.
    12. +
  12. When the MARK value in a tcrules entry is followed by ":F" or ":P", the ":F" or ":P" was previously only applied to the first -Netfilter rule generated by the entry. It is now applied to all entries.

    +Netfilter rule generated by the entry. It is now applied to all +entries.
    13. +
  13. An incorrect comment concerning Debian's use of the SUBSYSLOCK +option has been removed from shorewall.conf.
    14. +
  14. Previously, neither the 'routefilter' interface option nor the +ROUTE_FILTER parameter were working properly. This has been +corrected (thanks to Eric Bowles for his analysis and patch). The +definition of the ROUTE_FILTER option has changed however. +Previously, ROUTE_FILTER=Yes was documented as enabling route +filtering on all interfaces (which didn't work). Beginning with +this release, setting ROUTE_FILTER=Yes will enable route filtering +of all interfaces brought up while Shorewall is started. As a +consequence, ROUTE_FILTER=Yes can coexist with the use of the +'routefilter' option in the interfaces file.
    15. +
  15. If MAC verification was enabled on an interface with a /32 +address and a broadcast address then an error would occur during +startup.
    16. +
  16. The NONE policy's intended use is to suppress the generating of +rules that can't possibly be traversed. This means that a policy of +NONE is inappropriate where the source or destination zone is $FW +or "all". Shorewall now generates an error message if such a policy +is given in /etc/shorewall/policy. Previously such a policy caused +"shorewall start" to fail.
    17. +
  17. The 'routeback' option was broken for wildcard interfaces +(e.g., "tun+"). This has been corrected so that 'routeback' now +works as expected in this case.
-

10/06/2003 - Shorewall 1.4.7

-

Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 RC2).

+Migration Issues:
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 -caused error messages during "shorewall [re]start" when -ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP -interface; the addresses were successfully added in spite of the -messages.
    -   
    -The firewall script has been modified to eliminate the error messages

    -
    5. -
  5. -

    Interface-specific dynamic -blacklisting chains are now displayed by "shorewall monitor" on the -"Dynamic Chains" page (previously named "Dynamic Chain").

    -
    6. -
  6. -

    Thanks to Henry Yang, LOGRATE and -LOGBURST now work again.

    -
    7. -
  7. -

    The 'shorewall reject' and -'shorewall drop' commands now delete any existing rules for the subject -IP address before adding a new DROP or REJECT rule. Previously, there -could be many rules for the same IP address in the dynamic chain so -that multiple 'allow' commands were required to re-enable traffic -to/from the address.

    -
    8. -
  8. -

    When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry -in /etc/shorewall/masq resulted in a startup error:
    - 
    -   eth0 eth1     -206.124.146.20-206.124.146.24

    -
    9. -
  9. -

    Shorewall previously choked over -IPV6 addresses configured on interfaces in contexts where Shorewall -needed to detect something about the interface (such as when "detect" -appears in the BROADCAST column of the /etc/shorewall/interfaces file). -

    -
    10. -
  10. -

    Shorewall will now load module files -that are formed from the module name by appending ".o.gz".

    -
    11. -
  11. -

    When Shorewall adds a route to a -proxy ARP host and such a route already exists, two routes resulted -previously. This has been corrected so that the existing route is -replaced if it already exists.

    -
    12. -
  12. -

    The rfc1918 file has been updated to -reflect recent allocations.

    -
    13. -
  13. -

    The documentation of the USER SET -column in the rules file has been corrected.

    -
    14. -
  14. -

    If there is no policy defined for the zones specified in a rule, -the firewall script previously encountered a shell syntax error:
    -                                                                                                                                                                                   
    -        [: NONE: unexpected operator
    -                                                                                                                                                                                   
    -Now, the absence of a policy generates an error message and the -firewall is stopped:
    -                                                                                                                                                                                   
    -        No policy defined from zone -<source> to zone <dest>

    -
    15. -
  15. -

    Previously, if neither -/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall -would fail to start and would not remove the lock file. Failure to -remove the lock file resulted in the following during subsequent -attempts to start:
    -                                                                                                                                                                                   
    -    Loading /usr/share/shorewall/functions...
    -    Processing /etc/shorewall/params ...
    -    Processing /etc/shorewall/shorewall.conf...
    -    Giving up on lock file /var/lib/shorewall/lock
    -    Shorewall Not Started
    -
    -Shorewall now reports a fatal error if neither of these two files exist -and correctly removes the lock fille.

    -
    16. -
  16. -

    The order of processing the various -options has been changed such that blacklist entries now take -precedence over the 'dhcp' interface setting.

    -
    17. -
  17. -

    The log message generated from the -'logunclean' interface option has been changed to reflect a disposition -of LOG rather than DROP.

    -
    18. -
  18. -

    When a user name and/or a group name was specified in the -USER SET column and the destination zone was qualified with a IP -address, the user and/or group name was not being used to qualify the -rule.
    - 
    -    Example:
    - 
    -    ACCEPT fw  net:192.0.2.12 tcp 23 - - - vladimir:

    -
    19. -
  19. -

    The /etc/shorewall/masq file has had the spurious "/" -character at the front removed.

    +
  20. The definition of the ROUTE_FILTER option in shorewall.conf has +changed as described in item 8) above.
-

Migration Issues:

+New Features:
    -
  1. -

    Shorewall IP Traffic Accounting has -changed since snapshot 20030813 -- see the Accounting Page for details.

    -
    2. -
  2. -

    The Uset Set capability introduced -in SnapShot 20030821 has changed -- see the User Set page for details.

    -
    3. -
  3. -

    The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had too -many idiosyncrasies for dial-up users to be a viable part of Shorewall.

    -
    4. +
  4. A new QUEUE action has been introduced for rules. QUEUE allows +you to pass connection requests to a user-space filter such as +ftwall (http://p2pwall.sourceforge.net). The ftwall program allows +for effective filtering of p2p applications such as Kazaa. For +example, to use ftwall to filter P2P clients in the 'loc' zone, you +would add the following rules:
    +
    +   QUEUE   loc    +     net    tcp
    +   QUEUE   loc    +     net    udp
    +   QUEUE   loc    +     fw     udp
    +
    +You would normally want to place those three rules BEFORE any +ACCEPT rules for loc->net udp or tcp.
    +
    +Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), +Shorewall will only pass connection requests (SYN packets) to user +space. This is for compatibility with ftwall.
    5. +
  5. A BLACKLISTNEWNONLY option has been added to shorewall.conf. +When this option is set to "Yes", the blacklists (dynamic and +static) are only consulted for new connection requests. When set to +"No" (the default if the variable is not set), the blacklists are +consulted on every packet.
    +
    +Setting this option to "No" allows blacklisting to stop existing +connections from a newly blacklisted host but is more expensive in +terms of packet processing time. This is especially true if the +blacklists contain a large number of entries.
    6. +
  6. Chain names used in the /etc/shorewall/accounting file may now +begin with a digit ([0-9]) and may contain embedded dashes +("-").
-

New Features:

-
    -
  1. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    2. -
  2. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    3. -
  3. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    4. -
  4. -

    An 'arp_filter' option has been -added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    -
    5. -
  5. -

    The ADDRESS column in -/etc/shorewall/masq may now include a comma-separated list of addresses -and/or address ranges. Netfilter will use all listed addresses/ranges -in round-robin fashion. \

    -
    6. -
  6. -

    An /etc/shorewall/accounting file -has been added to allow for traffic accounting.  See the accounting documentation for a -description of this facility.

    -
    7. -
  7. -

    Bridge interfaces (br[0-9]) may now -be used in /etc/shorewall/maclist.

    -
    8. -
  8. -

    ACCEPT, DNAT[-], REDIRECT[-] and LOG -rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT -and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; -the corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    - 
    - Warning: When rate limiting is specified on a rule with -"all" in the SOURCE or DEST fields, the limit will apply to each pair -of zones individually rather than as a single limit for all pairs of -covered by the rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the /etc/shorewall/rules -file. You may specify the rate limit there in the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
    -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.

    -
    9. -
  9. -

    Multiple chains may now be displayed -in one "shorewall show" command (e.g., shorewall show INPUT FORWARD -OUTPUT).

    -
    10. -
  10. -

    Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html -for details.

    -
    11. -
-

10/02/2003 - Shorewall 1.4.7 RC2

+

10/30/2003 - Shorewall 1.4.8 RC1
+

+Given the small number of new features and the relatively few lines +of code that were changed, there will be no Beta for 1.4.8.

http://shorewall.net/pub/shorewall/Beta
-ftp://shorewall.net/pub/shorewall/Beta

-

Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 RC 1).

+ftp://shorewall.net/pub/shorewall/Beta
+
+Problems Corrected since version 1.4.7:
+

    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    +
  2. Tuomo Soini has supplied a correction to a problem that occurs +using some versions of 'ash'. The symptom is that "shorewall start" +fails with:
    + 
    +   local: --limit: bad variable name
    +   iptables v1.2.8: Couldn't load match +`-j':/lib/iptables/libipt_-j.so:
    +   cannot open shared object file: No such file or +directory
    +   Try `iptables -h' or 'iptables --help' for more +information.
    3. +
  3. Andres Zhoglo has supplied a correction that avoids trying to +use the multiport match iptables facility on ICMP rules.
    + 
    +   Example of rule that previously caused "shorewall +start" to fail:
    + 
    +           +ACCEPT      loc  $FW  +icmp    0,8,11,12
    +
    4. -
  4. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    +
  5. Previously, if the following error message was issued, +Shorewall was left in an inconsistent state.
    + 
    +   Error: Unable to determine the routes through +interface xxx
    +
    6. -
  6. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    +
  7. Handling of the LOGUNCLEAN option in shorewall.conf has been +corrected.
    8. +
  8. In Shorewall 1.4.2, an optimization was added. This +optimization involved creating a chain named "<zone>_frwd" +for most zones defined using the /etc/shorewall/hosts file. It has +since been discovered that in many cases these new chains contain +redundant rules and that the "optimization" turns out to be less +than optimal. The implementation has now been corrected.
    9. +
  9. When the MARK value in a tcrules entry is followed by ":F" or +":P", the ":F" or ":P" was previously only applied to the first +Netfilter rule generated by the entry. It is now applied to all +entries.
    10. +
  10. An incorrect comment concerning Debian's use of the SYBSYSLOCK +option has been removed from shorewall.conf.
    11. +
  11. Previously, neither the 'routefilter' interface option nor the +ROUTE_FILTER parameter were working properly. This has been +corrected (thanks to Eric Bowles for his analysis and patch). The +definition of the ROUTE_FILTER option has changed however. +Previously, ROUTE_FILTER=Yes was documented as enabling route +filtering on all interfaces (which didn't work). Beginning with +this release, setting ROUTE_FILTER=Yes will enable route filtering +of all interfaces brought up while Shorewall is started. As a +consequence, ROUTE_FILTER=Yes can coexist with the use of the +'routefilter' option in the interfaces file.
    12. +
+Migration Issues:
+
    +
  1. The definition of the ROUTE_FILTER option in shorewall.conf has +changed as described in item 8) above.
    2. -
  2. -

    A change introduced in version 1.4.6 -caused error messages during "shorewall [re]start" when -ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP -interface; the addresses were successfully added in spite of the -messages.
    +

+New Features:
+
    +
  1. A new QUEUE action has been introduced for rules. QUEUE allows +you to pass connection requests to a user-space filter such as +ftwall (http://p2pwall.sourceforge.net). The ftwall program allows +for effective filtering of p2p applications such as Kazaa. For +example, to use ftwall to filter P2P clients in the 'loc' zone, you +would add the following rules:
    +
    +   QUEUE   loc    +     net    tcp
    +   QUEUE   loc    +     net    udp
    +   QUEUE   loc    +     fw     udp
    +
    +You would normally want to place those three rules BEFORE any +ACCEPT rules for loc->net udp or tcp.
    +
    +Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), +Shorewall will only pass connection requests (SYN packets) to user +space. This is for compatibility with ftwall.
    2. +
  2. A BLACKLISTNEWNONLY option has been added to shorewall.conf. +When this option is set to "Yes", the blacklists (dynamic and +static) are only consulted for new connection requests. When set to +"No" (the default if the variable is not set), the blacklists are +consulted on every packet.
    +
    +Setting this option to "No" allows blacklisting to stop existing +connections from a newly blacklisted host but is more expensive in +terms of packet processing time. This is especially true if the +blacklists contain a large number of entries.
    3. +
  3. Chain names used in the /etc/shorewall/accounting file may now +begin with a digit ([0-9]) and may contain embedded dashes +("-").
    +
    4. +
+

10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag +awards Shorewall +1.4.7c released.

+
    +
  1. The saga with "<zone>_frwd" chains continues. The 1.4.7c +script produces a ruleset that should work for everyone even if it +is not quite optimal. My apologies for this ongoing mess.
    +
    2. +
+

10/24/2003 - Shorewall 1.4.7b

+This is a bugfx rollup of the 1.4.7a fixes plus:
+
    +
  1. The fix for problem 5 in 1.4.7a was wrong with the result that +"<zone>_frwd" chains might contain too few rules. That wrong +code is corrected in this release.
    +
    2. +
+

10/21/2003 - Shorewall 1.4.7a
+

+

This is a bugfix rollup of the following problem +corrections:
+

+
    +
  1. Tuomo Soini has supplied a correction to a problem that occurs +using some versions of 'ash'. The symptom is that "shorewall start" +fails with:
    + 
    +   local: --limit: bad variable name
    +   iptables v1.2.8: Couldn't load match +`-j':/lib/iptables/libipt_-j.so:
    +   cannot open shared object file: No such file or +directory
    +   Try `iptables -h' or 'iptables --help' for more +information.
    +
    +
    2. +
  2. Andres Zhoglo has supplied a correction that avoids trying to +use the multiport match iptables facility on ICMP rules.
    + 
    +   Example of rule that previously caused "shorewall +start" to fail:
    + 
    +           +ACCEPT      loc  $FW  +icmp    0,8,11,12
    +
    +
    3. +
  3. Previously, if the following error message was issued, +Shorewall was left in an inconsistent state.
    + 
    +   Error: Unable to determine the routes through +interface xxx
    +
    +
    4. +
  4. Handling of the LOGUNCLEAN option in shorewall.conf has been +corrected.
    5. +
  5. In Shorewall 1.4.2, an optimization was added. This +optimization involved creating a chain named "<zone>_frwd" +for most zones defined using the /etc/shorewall/hosts file. It has +since been discovered that in many cases these new chains contain +redundant rules and that the "optimization" turns out to be less +than optimal. The implementation has now been corrected.
    6. +
  6. When the MARK value in a tcrules entry is followed by ":F" or +":P", the ":F" or ":P" was previously only applied to the first +Netfilter rule generated by the entry. It is now applied to all +entries.
    +
    7. +
+

10/06/2003 - Shorewall 1.4.7
+

+Problems Corrected since version 1.4.6 (Those in bold font were +corrected since 1.4.7 RC2).
+
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
       
    -The firewall script has been modified to eliminate the error messages

    -
    5. -
  5. -

    Interface-specific dynamic -blacklisting chains are now displayed by "shorewall monitor" on the -"Dynamic Chains" page (previously named "Dynamic Chain").

    -
    6. -
  6. -

    Thanks to Henry Yang, LOGRATE and -LOGBURST now work again.

    -
    7. -
  7. -

    The 'shorewall reject' and -'shorewall drop' commands now delete any existing rules for the subject -IP address before adding a new DROP or REJECT rule. Previously, there -could be many rules for the same IP address in the dynamic chain so -that multiple 'allow' commands were required to re-enable traffic -to/from the address.

    -
    8. -
  8. -

    When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry -in /etc/shorewall/masq resulted in a startup error:
    - 
    -   eth0 eth1     -206.124.146.20-206.124.146.24

    -
    9. -
  9. -

    Shorewall previously choked over -IPV6 addresses configured on interfaces in contexts where Shorewall -needed to detect something about the interface (such as when "detect" -appears in the BROADCAST column of the /etc/shorewall/interfaces file). -

    -
    10. -
  10. -

    Shorewall will now load module files -that are formed from the module name by appending ".o.gz".

    -
    11. -
  11. -

    When Shorewall adds a route to a -proxy ARP host and such a route already exists, two routes resulted -previously. This has been corrected so that the existing route is -replaced if it already exists.

    -
    12. -
  12. -

    The rfc1918 file has been updated to -reflect recent allocations.

    -
    13. -
  13. -

    The documentation of the USER SET -column in the rules file has been corrected.

    -
    14. -
  14. -

    If there is no policy defined for the zones specified in a -rule, the firewall script previously encountered a shell syntax error:
    -                                                                                                                                                                                   
    -        [: NONE: unexpected operator
    -                                                                                                                                                                                   
    -Now, the absence of a policy generates an error message and the -firewall is stopped:
    -                                                                                                                                                                                   
    -        No policy defined from zone -<source> to zone <dest>

    -
    15. -
  15. -

    Previously, if neither -/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall -would fail to start and would not remove the lock file. Failure to -remove the lock file resulted in the following during subsequent -attempts to start:
    -                                                                                                                                                                                   
    -    Loading /usr/share/shorewall/functions...
    -    Processing /etc/shorewall/params ...
    -    Processing /etc/shorewall/shorewall.conf...
    -    Giving up on lock file /var/lib/shorewall/lock
    -    Shorewall Not Started
    -
    -Shorewall now reports a fatal error if neither of these two files exist -and correctly removes the lock fille.

    -
    16. -
  16. -

    The order of processing the -various options has been changed such that blacklist entries now take -precedence over the 'dhcp' interface setting.

    -
    17. -
  17. -

    The log message generated from -the 'logunclean' interface option has been changed to reflect a -disposition of LOG rather than DROP.

    -
    18. -
  18. -

    The RFC1918 file has been updated to reflect recent IANA -allocations.

    -
    19. -
-

Migration Issues:

-
    -
  1. -

    Shorewall IP Traffic Accounting has -changed since snapshot 20030813 -- see the Accounting Page for details.

    -
    2. -
  2. -

    The Uset Set capability introduced -in SnapShot 20030821 has changed -- see the User Set page for details.

    -
    3. -
  3. -

    The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had too -many idiosyncrasies for dial-up users to be a viable part of Shorewall.

    -
    4. -
-

New Features:

-
    -
  1. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    2. -
  2. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    3. -
  3. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    4. -
  4. -

    An 'arp_filter' option has been -added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    -
    5. -
  5. -

    The ADDRESS column in -/etc/shorewall/masq may now include a comma-separated list of addresses -and/or address ranges. Netfilter will use all listed addresses/ranges -in round-robin fashion. \

    -
    6. -
  6. -

    An /etc/shorewall/accounting file -has been added to allow for traffic accounting.  See the accounting documentation for a -description of this facility.

    -
    7. -
  7. -

    Bridge interfaces (br[0-9]) may now -be used in /etc/shorewall/maclist.

    -
    8. -
  8. -

    ACCEPT, DNAT[-], REDIRECT[-] and LOG -rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT -and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; -the corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    - 
    - Warning: When rate limiting is specified on a rule with -"all" in the SOURCE or DEST fields, the limit will apply to each pair -of zones individually rather than as a single limit for all pairs of -covered by the rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the /etc/shorewall/rules -file. You may specify the rate limit there in the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
    -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.

    -
    9. -
  9. -

    Multiple chains may now be displayed -in one "shorewall show" command (e.g., shorewall show INPUT FORWARD -OUTPUT).

    -
    10. -
  10. -

    Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html -for details.

    -
    11. -
-

9/18/2003 - Shorewall 1.4.7 RC 1

-

http://shorewall.net/pub/shorewall/Beta
-ftp://shorewall.net/pub/shorewall/Beta

-

Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 Beta 1).

-
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 -caused error messages during "shorewall [re]start" when -ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP -interface; the addresses were successfully added in spite of the -messages.
    -   
    -The firewall script has been modified to eliminate the error messages

    -
    5. -
  5. -

    Interface-specific dynamic -blacklisting chains are now displayed by "shorewall monitor" on the -"Dynamic Chains" page (previously named "Dynamic Chain").

    -
    6. -
  6. -

    Thanks to Henry Yang, LOGRATE and -LOGBURST now work again.

    -
    7. -
  7. -

    The 'shorewall reject' and -'shorewall drop' commands now delete any existing rules for the subject -IP address before adding a new DROP or REJECT rule. Previously, there -could be many rules for the same IP address in the dynamic chain so -that multiple 'allow' commands were required to re-enable traffic -to/from the address.

    -
    8. -
  8. -

    When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry -in /etc/shorewall/masq resulted in a startup error:
    - 
    -   eth0 eth1     -206.124.146.20-206.124.146.24

    -
    9. -
  9. -

    Shorewall previously choked over -IPV6 addresses configured on interfaces in contexts where Shorewall -needed to detect something about the interface (such as when "detect" -appears in the BROADCAST column of the /etc/shorewall/interfaces file). -

    -
    10. -
  10. -

    Shorewall will now load module files -that are formed from the module name by appending ".o.gz".

    -
    11. -
  11. -

    When Shorewall adds a route to a -proxy ARP host and such a route already exists, two routes resulted -previously. This has been corrected so that the existing route is -replaced if it already exists.

    -
    12. -
  12. -

    The rfc1918 file has been updated to reflect recent -allocations.

    -
    13. -
-

Migration Issues:

-
    -
  1. -

    Shorewall IP Traffic Accounting has -changed since snapshot 20030813 -- see the Accounting Page for details.

    -
    2. -
  2. -

    The Uset Set capability introduced -in SnapShot 20030821 has changed -- see the User Set page for details.

    -
    3. -
  3. -

    The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had too -many idiosyncrasies for dial-up users to be a viable part of Shorewall.

    -
    4. -
-

New Features:

-
    -
  1. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    2. -
  2. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    3. -
  3. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    4. -
  4. -

    An 'arp_filter' option has been -added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    -
    5. -
  5. -

    The ADDRESS column in -/etc/shorewall/masq may now include a comma-separated list of addresses -and/or address ranges. Netfilter will use all listed addresses/ranges -in round-robin fashion. \

    -
    6. -
  6. -

    An /etc/shorewall/accounting file -has been added to allow for traffic accounting.  See the accounting documentation for a -description of this facility.

    -
    7. -
  7. -

    Bridge interfaces (br[0-9]) may now -be used in /etc/shorewall/maclist.

    -
    8. -
  8. -

    ACCEPT, DNAT[-], REDIRECT[-] and LOG -rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT -and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; -the corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    - 
    - Warning: When rate limiting is specified on a rule with -"all" in the SOURCE or DEST fields, the limit will apply to each pair -of zones individually rather than as a single limit for all pairs of -covered by the rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the /etc/shorewall/rules -file. You may specify the rate limit there in the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
    -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.

    -
    9. -
  9. -

    Multiple chains may now be displayed -in one "shorewall show" command (e.g., shorewall show INPUT FORWARD -OUTPUT).

    -
    10. -
  10. -

    Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html -for details.

    -
    11. -
-

9/15/2003 - Shorewall 1.4.7 Beta 2

-

http://shorewall.net/pub/shorewall/Beta
-ftp://shorewall.net/pub/shorewall/Beta

-

Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 Beta 1).

-
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 -caused error messages during "shorewall [re]start" when -ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP -interface; the addresses were successfully added in spite of the -messages.
    -   
    -The firewall script has been modified to eliminate the error messages

    -
    5. -
  5. -

    Interface-specific dynamic -blacklisting chains are now displayed by "shorewall monitor" on the -"Dynamic Chains" page (previously named "Dynamic Chain").

    -
    6. -
  6. -

    Thanks to Henry Yang, LOGRATE and -LOGBURST now work again.

    -
    7. -
  7. -

    The 'shorewall reject' and -'shorewall drop' commands now delete any existing rules for the subject -IP address before adding a new DROP or REJECT rule. Previously, there -could be many rules for the same IP address in the dynamic chain so -that multiple 'allow' commands were required to re-enable traffic -to/from the address.

    -
    8. -
  8. -

    When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following +The firewall script has been modified to eliminate the error +messages

    9. +
  9. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    10. +
  10. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    11. +
  11. The 'shorewall reject' and 'shorewall drop' commands +now delete any existing rules for the subject IP address before +adding a new DROP or REJECT rule. Previously, there could be many +rules for the same IP address in the dynamic chain so that multiple +'allow' commands were required to re-enable traffic to/from the +address.
    12. +
  12. When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in /etc/shorewall/masq resulted in a startup error:
     
       eth0 eth1     -206.124.146.20-206.124.146.24

    +206.124.146.20-206.124.146.24
    +
    13. -
  13. -

    Shorewall previously choked over -IPV6 addresses configured on interfaces in contexts where Shorewall -needed to detect something about the interface (such as when "detect" -appears in the BROADCAST column of the /etc/shorewall/interfaces file). -

    +
  14. Shorewall previously choked over IPV6 addresses configured on +interfaces in contexts where Shorewall needed to detect something +about the interface (such as when "detect" appears in the BROADCAST +column of the /etc/shorewall/interfaces file).
    15. +
  15. Shorewall will now load module files that are formed from the +module name by appending ".o.gz".
    16. +
  16. When Shorewall adds a route to a proxy ARP host and such a +route already exists, two routes resulted previously. This has been +corrected so that the existing route is replaced if it already +exists.
    17. +
  17. The rfc1918 file has been updated to reflect recent +allocations.
    18. +
  18. The documentation of the USER SET column in the rules file has +been corrected.
    19. +
  19. If there is no policy defined for the zones specified in a +rule, the firewall script previously encountered a shell syntax +error:
    +                                                                                                                                                                                   
    +        [: NONE: unexpected +operator
    +                                                                                                                                                                                   
    +Now, the absence of a policy generates an error message and the +firewall is stopped:
    +                                                                                                                                                                                   
    +        No policy defined from +zone <source> to zone <dest>
    +
    20. -
  20. -

    Shorewall will now load module files that are formed from the -module name by appending ".o.gz".

    +
  21. Previously, if neither /etc/shorewall/common nor +/etc/shorewall/common.def existed, Shorewall would fail to start +and would not remove the lock file. Failure to remove the lock file +resulted in the following during subsequent attempts to start:
    +                                                                                                                                                                                   
    +    Loading /usr/share/shorewall/functions...
    +    Processing /etc/shorewall/params ...
    +    Processing /etc/shorewall/shorewall.conf...
    +    Giving up on lock file +/var/lib/shorewall/lock
    +    Shorewall Not Started
    +
    +Shorewall now reports a fatal error if neither of these two files +exist and correctly removes the lock fille.
    22. +
  22. The order of processing the various options has been changed +such that blacklist entries now take precedence over the 'dhcp' interface setting.
    23. +
  23. The log message generated from the 'logunclean' interface +option has been changed to reflect a disposition of LOG rather than +DROP.
    24. +
  24. When a user name and/or a +group name was specified in the USER SET column and the destination +zone was qualified with a IP address, the user and/or group name +was not being used to qualify the rule.
    + 
    +    Example:
    + 
    +    ACCEPT fw  net:192.0.2.12 tcp 23 - - - +vladimir:
    +
    +
    25. +
  25. The /etc/shorewall/masq file +has had the spurious "/" character at the front removed.
    +
    +
    26. +
+Migration Issues:
+
    +
  1. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page +for details.
    2. +
  2. The Uset Set capability introduced in SnapShot 20030821 has +changed -- see the User Set page for +details.
    3. +
  3. The per-interface Dynamic Blacklisting facility introduced in +the first post-1.4.6 Snapshot has been removed. The facility had +too many idiosyncrasies for dial-up users to be a viable part of +Shorewall.
-

Migration Issues:

+New Features:
    -
  1. -

    Shorewall IP Traffic Accounting has -changed since snapshot 20030813 -- see the Accounting Page for details.

    -
    2. -
  2. -

    The Uset Set capability introduced -in SnapShot 20030821 has changed -- see the User Set page for details.

    -
    3. -
  3. -

    The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had too -many idiosyncrasies for dial-up users to be a viable part of Shorewall.

    -
    4. -
-

New Features:

-
    -
  1. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    2. -
  2. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    +

  3. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    4. +
  4. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.

    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:

    -   a) All traffic originating from the firewall itself; and
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.

    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.

    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.

     Example:

    @@ -5257,833 +4001,1491 @@ eth0:0    192.168.1.5   
       ACCEPT    net    loc:192.168.1.5    tcp    22
       ACCEPT    loc    -fw        tcp    22
    +fw        tcp    +22

    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    5. -
  5. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!

    6. +
  6. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:

    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
     
    where:
     
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    7. -
  7. -

    An 'arp_filter' option has been -added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    -
    8. -
  8. -

    The ADDRESS column in -/etc/shorewall/masq may now include a comma-separated list of addresses -and/or address ranges. Netfilter will use all listed addresses/ranges -in round-robin fashion. \

    -
    9. -
  9. -

    An /etc/shorewall/accounting file -has been added to allow for traffic accounting.  See the accounting documentation for a -description of this facility.

    -
    10. -
  10. -

    Bridge interfaces (br[0-9]) may now -be used in /etc/shorewall/maclist.

    -
    11. -
  11. -

    ACCEPT, DNAT[-], REDIRECT[-] and LOG -rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT -and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; -the corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    - 
    - Warning: When rate limiting is specified on a rule with -"all" in the SOURCE or DEST fields, the limit will apply to each pair -of zones individually rather than as a single limit for all pairs of -covered by the rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the /etc/shorewall/rules -file. You may specify the rate limit there in the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
    -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.

    -
    12. -
  12. -

    Multiple chains may now be displayed -in one "shorewall show" command (e.g., shorewall show INPUT FORWARD -OUTPUT).

    -
    13. -
  13. -

    Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html -for details.

    -
    14. -
-

8/27/2003 - Shorewall Mirror in Australia

-

Thanks to Dave Kempe and Solutions First -(http://www.solutionsfirst.com.au), -there is now a Shorewall Mirror in Australia:

-

http://www.shorewall.com.au
-ftp://ftp.shorewall.com.au

-

8/26/2003 - French Version of the Shorewall Setup Guide 

-

Thanks to Fabien Demassieux, there is now a French -translation of the Shorewall Setup Guide. Merci Beacoup, Fabien!

-

8/25/2003 - Shorewall 1.4.7 Beta 1

-

http://shorewall.net/pub/shorewall/Beta
-ftp://shorewall.net/pub/shorewall/Beta

-

Problems Corrected since version 1.4.6

-
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 -caused error messages during "shorewall [re]start" when -ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP -interface; the addresses were successfully added in spite of the -messages.
    -   
    -The firewall script has been modified to eliminate the error messages

    -
    5. -
  5. -

    Interface-specific dynamic -blacklisting chains are now displayed by "shorewall monitor" on the -"Dynamic Chains" page (previously named "Dynamic Chain").

    -
    6. -
  6. -

    Thanks to Henry Yang, LOGRATE and LOGBURST now work again.

    -
    7. -
-

Migration Issues:

-
    -
  1. -

    Shorewall IP Traffic Accounting has -changed since snapshot 20030813 -- see the Accounting Page for details.

    -
    2. -
  2. -

    The Uset Set capability introduced -in SnapShot 20030821 has changed -- see the User Set page for details.

    -
    3. -
  3. -

    The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had too -many idiosyncrasies for dial-up users to be a viable part of Shorewall.

    -
    4. -
-

New Features:

-
    -
  1. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    2. -
  2. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    3. -
  3. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    4. -
  4. -

    An 'arp_filter' option has been -added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    -
    5. -
  5. -

    The ADDRESS column in -/etc/shorewall/masq may now include a comma-separated list of addresses -and/or address ranges. Netfilter will use all listed addresses/ranges -in round-robin fashion. \

    -
    6. -
  6. -

    An /etc/shorewall/accounting file -has been added to allow for traffic accounting.  See the accounting documentation for a -description of this facility.

    -
    7. -
  7. -

    Bridge interfaces (br[0-9]) may now -be used in /etc/shorewall/maclist.

    -
    8. -
  8. -

    ACCEPT, DNAT[-], REDIRECT[-] and LOG -rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT -and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; -the corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    - 
    - Warning: When rate limiting is specified on a rule with -"all" in the SOURCE or DEST fields, the limit will apply to each pair -of zones individually rather than as a single limit for all pairs of -covered by the rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the /etc/shorewall/rules -file. You may specify the rate limit there in the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
    -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.

    -
    9. -
  9. -

    Multiple chains may now be displayed -in one "shorewall show" command (e.g., shorewall show INPUT FORWARD -OUTPUT).

    -
    10. -
  10. -

    Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html -for details.

    -
    11. -
-

8/23/2003 - Snapshot 1.4.6_20030823

-
http://shorewall.net/pub/shorewall/Snapshots/
- ftp://shorewall.net/pub/shorewall/Snapshots/
-

Problems Corrected since version 1.4.6

-
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 -caused error messages during "shorewall [re]start" when -ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP -interface; the addresses were successfully added in spite of the -messages.
    -   
    -The firewall script has been modified to eliminate the error messages

    -
    5. -
  5. -

    Interface-specific dynamic -blacklisting chains are now displayed by "shorewall monitor" on the -"Dynamic Chains" page (previously named "Dynamic Chain").

    -
    6. -
  6. -

    Thanks to Henry Yang, LOGRATE and LOGBURST now work again.

    -
    7. -
-

Migration Issues:

-
    -
  1. -

    Once you have installed this version -of Shorewall, you must restart Shorewall before you may use the 'drop', -'reject', 'allow' or 'save' commands.

    -
    2. -
  2. -

    To maintain strict compatibility -with previous versions, current uses of "shorewall drop" and "shorewall -reject" should be replaced with "shorewall dropall" and "shorewall -rejectall"

    -
    3. -
  3. -

    Shorewall IP Traffic Accounting has -changed since snapshot 20030813 -- see the Accounting Page for details.

    -
    4. -
  4. -

    The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page -for details.

    -
    5. -
-

New Features:

-
    -
  1. -

    Shorewall now creates a dynamic -blacklisting chain for each interface defined in -/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the -routing table to determine which of these chains is to be used for -blacklisting the specified IP address(es).
    -
    -Two new commands ('dropall' and 'rejectall') have been introduced that -do what 'drop' and 'reject' used to do; namely, when an address is -blacklisted using these new commands, it will be blacklisted on all of -your firewall's interfaces.

    -
    2. -
  2. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    3. -
  3. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    4. -
  4. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    5. -
  5. -

    An 'arp_filter' option has been -added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    -
    6. -
  6. -

    The ADDRESS column in -/etc/shorewall/masq may now include a comma-separated list of addresses -and/or address ranges. Netfilter will use all listed addresses/ranges -in round-robin fashion. \

    -
    7. -
  7. -

    An /etc/shorewall/accounting file -has been added to allow for traffic accounting.  See the accounting documentation for a -description of this facility.

    -
    8. -
  8. -

    Bridge interfaces (br[0-9]) may now -be used in /etc/shorewall/maclist.

    -
    9. -
  9. -

    ACCEPT, DNAT[-], REDIRECT[-] and LOG -rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT -and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; -the corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    - 
    - Warning: When rate limiting is specified on a rule with -"all" in the SOURCE or DEST fields, the limit will apply to each pair -of zones individually rather than as a single limit for all pairs of -covered by the rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the /etc/shorewall/rules -file. You may specify the rate limit there in the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
    -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.

    -
    10. -
  10. -

    Multiple chains may now be displayed -in one "shorewall show" command (e.g., shorewall show INPUT FORWARD -OUTPUT).

    -
    11. -
  11. -

    Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html -for details.

    -
    12. -
-

8/13/2003 - Snapshot 1.4.6_20030813 

-
http://shorewall.net/pub/shorewall/Snapshots/
- ftp://shorewall.net/pub/shorewall/Snapshots/
-

Problems Corrected since version 1.4.6

-
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 -caused error messages during "shorewall [re]start" when -ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP -interface; the addresses were successfully added in spite of the -messages.
    -   
    -The firewall script has been modified to eliminate the error messages

    -
    5. -
  5. -

     Interface-specific dynamic blacklisting chains are now -displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").

    -
    6. -
-

Migration Issues:

-
    -
  1. -

    Once you have installed this version -of Shorewall, you must restart Shorewall before you may use the 'drop', -'reject', 'allow' or 'save' commands.

    -
    2. -
  2. -

    To maintain strict compatibility with previous versions, current -uses of "shorewall drop" and "shorewall reject" should be replaced with -"shorewall dropall" and "shorewall rejectall"

    -
    3. -
-

New Features:

-
    -
  1. -

    Shorewall now creates a dynamic -blacklisting chain for each interface defined in -/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the -routing table to determine which of these chains is to be used for -blacklisting the specified IP address(es).
    -
    -Two new commands ('dropall' and 'rejectall') have been introduced that -do what 'drop' and 'reject' used to do; namely, when an address is -blacklisted using these new commands, it will be blacklisted on all of -your firewall's interfaces.

    -
    2. -
  2. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    3. -
  3. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    4. -
  4. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    5. -
  5. -

    An 'arp_filter' option has been -added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    -
    6. -
  6. -

    The ADDRESS column in -/etc/shorewall/masq may now include a comma-separated list of addresses -and/or address ranges. Netfilter will use all listed addresses/ranges -in round-robin fashion. \

    -
    7. -
  7. -

    An /etc/shorewall/accounting file -has been added to allow for traffic accounting.  See the accounting documentation for a -description of this facility.

    -
    8. -
  8. -

    Bridge interfaces (br[0-9]) may now -be used in /etc/shorewall/maclist.

    -
    9. -
  9. -

    ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.

    10. +
  10. An 'arp_filter' option has been added to the +/etc/shorewall/interfaces file. This option causes +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    11. +
  11. The ADDRESS column in /etc/shorewall/masq may now include a +comma-separated list of addresses and/or address ranges. Netfilter +will use all listed addresses/ranges in round-robin fashion. \
    12. +
  12. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting +documentation for a description of +this facility.
    13. +
  13. Bridge interfaces (br[0-9]) may now be used in +/etc/shorewall/maclist.
    14. +
  14. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
     
    - Warning: When rate limiting is specified on a rule with -"all" in the SOURCE or DEST fields, the limit will apply to each pair -of zones individually rather than as a single limit for all pairs of -covered by the rule.
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
     
    -To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    +To specify a rate limit,
    +
    +a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    + 
    +      < +<rate>/<interval>[:<burst>] >
    + 
    +  where
    + 
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
    +      <burst> is the largest burst +accepted within an <interval>. If not given, the default of 5 +is assumed.
    + 
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +
    +b) A new RATE LIMIT column has been added to the +/etc/shorewall/rules file. You may specify the rate limit there in +the format:
    +
    +      +<rate>/<interval>[:<burst>]
    + 
    +Let's take an example:
    + 
    +         +ACCEPT<2/sec:4>        +net     dmz     +tcp     80
    +   
    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
    +
    15. +
  15. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    16. +
  16. Output rules (those with $FW as the SOURCE) may now be limited +to a set of local users and/or groups. See http://shorewall.net/UserSets.html +for +details.
    17. +
+

10/02/2003 - Shorewall 1.4.7 RC2
+

+

http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+

+Problems Corrected since version 1.4.6 (Those in bold font were +corrected since 1.4.7 RC 1).
+
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +   
    +The firewall script has been modified to eliminate the error +messages
    5. +
  5. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    6. +
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    7. +
  7. The 'shorewall reject' and 'shorewall drop' commands +now delete any existing rules for the subject IP address before +adding a new DROP or REJECT rule. Previously, there could be many +rules for the same IP address in the dynamic chain so that multiple +'allow' commands were required to re-enable traffic to/from the +address.
    8. +
  8. When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following +entry in /etc/shorewall/masq resulted in a startup error:
    + 
    +   eth0 eth1     +206.124.146.20-206.124.146.24
    +
    +
    9. +
  9. Shorewall previously choked over IPV6 addresses configured on +interfaces in contexts where Shorewall needed to detect something +about the interface (such as when "detect" appears in the BROADCAST +column of the /etc/shorewall/interfaces file).
    10. +
  10. Shorewall will now load module files that are formed from the +module name by appending ".o.gz".
    11. +
  11. When Shorewall adds a route to a proxy ARP host and such a +route already exists, two routes resulted previously. This has been +corrected so that the existing route is replaced if it already +exists.
    12. +
  12. The rfc1918 file has been updated to reflect recent +allocations.
    13. +
  13. The documentation of the USER +SET column in the rules file has been corrected.
    14. +
  14. If there is no policy defined +for the zones specified in a rule, the firewall script previously +encountered a shell syntax error:
    +                                                                                                                                                                                   
    +        [: NONE: unexpected +operator
    +                                                                                                                                                                                   
    +Now, the absence of a policy generates an error message and the +firewall is stopped:
    +                                                                                                                                                                                   
    +        No policy defined from +zone <source> to zone <dest>
    +
    +
    15. +
  15. Previously, if neither +/etc/shorewall/common nor /etc/shorewall/common.def existed, +Shorewall would fail to start and would not remove the lock file. +Failure to remove the lock file resulted in the following during +subsequent attempts to start:
    +                                                                                                                                                                                   
    +    Loading /usr/share/shorewall/functions...
    +    Processing /etc/shorewall/params ...
    +    Processing /etc/shorewall/shorewall.conf...
    +    Giving up on lock file +/var/lib/shorewall/lock
    +    Shorewall Not Started
    +
    +Shorewall now reports a fatal error if neither of these two files +exist and correctly removes the lock fille.
    16. +
  16. The order of processing the +various options has been changed such that blacklist entries now +take precedence over the 'dhcp' interface setting.
    17. +
  17. The log message generated from +the 'logunclean' interface option has been changed to reflect a +disposition of LOG rather than DROP.
    18. +
  18. The RFC1918 file has been +updated to reflect recent IANA allocations.
    +
    19. +
+Migration Issues:
+
    +
  1. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page +for details.
    2. +
  2. The Uset Set capability introduced in SnapShot 20030821 has +changed -- see the User Set page for +details.
    3. +
  3. The per-interface Dynamic Blacklisting facility introduced in +the first post-1.4.6 Snapshot has been removed. The facility had +too many idiosyncrasies for dial-up users to be a viable part of +Shorewall.
    +
    4. +
+New Features:
+
    +
  1. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    2. +
  2. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    +With ADMINISABSENTMINDED=Yes (the default for new installs), in +addition to traffic to/from the hosts listed in +/etc/shorewall/routestopped, Shorewall will allow:
    +
    +   a) All traffic originating from the firewall itself; +and
    +   b) All traffic that is part of or related to an +already-existing connection.
    +
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.
    +
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.
    +
    + Example:
    +
    + /etc/shorewall/nat:
    +
    +     206.124.146.178    +eth0:0    192.168.1.5   
    +
    + /etc/shorewall/rules:
    +
    +   ACCEPT    net    +loc:192.168.1.5    tcp    22
    +   ACCEPT    loc    +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    3. +
  3. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
    + 
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
    + 
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:
    +
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
    + 
    +where:
    + 
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
    +       <ip address> is the IP +address of the remote tunnel gateway.
    +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    4. +
  4. An 'arp_filter' option has been added to the +/etc/shorewall/interfaces file. This option causes +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    5. +
  5. The ADDRESS column in /etc/shorewall/masq may now include a +comma-separated list of addresses and/or address ranges. Netfilter +will use all listed addresses/ranges in round-robin fashion. \
    6. +
  6. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting +documentation for a description of +this facility.
    7. +
  7. Bridge interfaces (br[0-9]) may now be used in +/etc/shorewall/maclist.
    8. +
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in +/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT +rules, rate limiting occurs in the nat table DNAT rule; the +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
    + 
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
    + 
    +To specify a rate limit,
    +
    +a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    + 
    +      < +<rate>/<interval>[:<burst>] >
    + 
    +  where
    + 
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
    +      <burst> is the largest burst +accepted within an <interval>. If not given, the default of 5 +is assumed.
    + 
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +
    +b) A new RATE LIMIT column has been added to the +/etc/shorewall/rules file. You may specify the rate limit there in +the format:
    +
    +      +<rate>/<interval>[:<burst>]
    + 
    +Let's take an example:
    + 
    +         +ACCEPT<2/sec:4>        +net     dmz     +tcp     80
    +   
    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
    +
    9. +
  9. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. +
  10. Output rules (those with $FW as the SOURCE) may now be limited +to a set of local users and/or groups. See http://shorewall.net/UserSets.html +for +details.
    11. +
+

9/18/2003 - Shorewall 1.4.7 RC 1
+

+

http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+

+Problems Corrected since version 1.4.6 (Those in bold font were +corrected since 1.4.7 Beta 1).
+
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +   
    +The firewall script has been modified to eliminate the error +messages
    5. +
  5. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    6. +
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    7. +
  7. The 'shorewall reject' and 'shorewall drop' commands +now delete any existing rules for the subject IP address before +adding a new DROP or REJECT rule. Previously, there could be many +rules for the same IP address in the dynamic chain so that multiple +'allow' commands were required to re-enable traffic to/from the +address.
    8. +
  8. When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following +entry in /etc/shorewall/masq resulted in a startup error:
    + 
    +   eth0 eth1     +206.124.146.20-206.124.146.24
    +
    +
    9. +
  9. Shorewall previously choked over IPV6 addresses configured on +interfaces in contexts where Shorewall needed to detect something +about the interface (such as when "detect" appears in the BROADCAST +column of the /etc/shorewall/interfaces file).
    10. +
  10. Shorewall will now load module files that are formed from the +module name by appending ".o.gz".
    11. +
  11. When Shorewall adds a route to a +proxy ARP host and such a route already exists, two routes resulted +previously. This has been corrected so that the existing route is +replaced if it already exists.
    12. +
  12. The rfc1918 file has been +updated to reflect recent allocations.
    +
    13. +
+Migration Issues:
+
    +
  1. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page +for details.
    2. +
  2. The Uset Set capability introduced in SnapShot 20030821 has +changed -- see the User Set page for +details.
    3. +
  3. The per-interface Dynamic Blacklisting facility introduced in +the first post-1.4.6 Snapshot has been removed. The facility had +too many idiosyncrasies for dial-up users to be a viable part of +Shorewall.
    +
    4. +
+New Features:
+
    +
  1. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    2. +
  2. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    +With ADMINISABSENTMINDED=Yes (the default for new installs), in +addition to traffic to/from the hosts listed in +/etc/shorewall/routestopped, Shorewall will allow:
    +
    +   a) All traffic originating from the firewall itself; +and
    +   b) All traffic that is part of or related to an +already-existing connection.
    +
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.
    +
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.
    +
    + Example:
    +
    + /etc/shorewall/nat:
    +
    +     206.124.146.178    +eth0:0    192.168.1.5   
    +
    + /etc/shorewall/rules:
    +
    +   ACCEPT    net    +loc:192.168.1.5    tcp    22
    +   ACCEPT    loc    +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    3. +
  3. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
    + 
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
    + 
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:
    +
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
    + 
    +where:
    + 
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
    +       <ip address> is the IP +address of the remote tunnel gateway.
    +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    4. +
  4. An 'arp_filter' option has been added to the +/etc/shorewall/interfaces file. This option causes +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    5. +
  5. The ADDRESS column in /etc/shorewall/masq may now include a +comma-separated list of addresses and/or address ranges. Netfilter +will use all listed addresses/ranges in round-robin fashion. \
    6. +
  6. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting +documentation for a description of +this facility.
    7. +
  7. Bridge interfaces (br[0-9]) may now be used in +/etc/shorewall/maclist.
    8. +
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in +/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT +rules, rate limiting occurs in the nat table DNAT rule; the +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
    + 
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
    + 
    +To specify a rate limit,
    +
    +a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    + 
    +      < +<rate>/<interval>[:<burst>] >
    + 
    +  where
    + 
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
    +      <burst> is the largest burst +accepted within an <interval>. If not given, the default of 5 +is assumed.
    + 
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +
    +b) A new RATE LIMIT column has been added to the +/etc/shorewall/rules file. You may specify the rate limit there in +the format:
    +
    +      +<rate>/<interval>[:<burst>]
    + 
    +Let's take an example:
    + 
    +         +ACCEPT<2/sec:4>        +net     dmz     +tcp     80
    +   
    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
    +
    9. +
  9. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. +
  10. Output rules (those with $FW as the SOURCE) may now be limited +to a set of local users and/or groups. See http://shorewall.net/UserSets.html +for +details.
    11. +
+

9/15/2003 - Shorewall 1.4.7 Beta 2
+

+

http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+

+Problems Corrected since version 1.4.6 (Those in bold font were +corrected since 1.4.7 Beta 1).
+
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +   
    +The firewall script has been modified to eliminate the error +messages
    5. +
  5. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    6. +
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    7. +
  7. The 'shorewall reject' and +'shorewall drop' commands now delete any existing rules for the +subject IP address before adding a new DROP or REJECT rule. +Previously, there could be many rules for the same IP address in +the dynamic chain so that multiple 'allow' commands were required +to re-enable traffic to/from the address.
    8. +
  8. When ADD_SNAT_ALIASES=Yes in +shorewall.conf, the following entry in /etc/shorewall/masq resulted +in a startup error:
    + 
    +   eth0 eth1     +206.124.146.20-206.124.146.24
    +
    +
    9. +
  9. Shorewall previously choked over +IPV6 addresses configured on interfaces in contexts where Shorewall +needed to detect something about the interface (such as when +"detect" appears in the BROADCAST column of the +/etc/shorewall/interfaces file).
    10. +
  10. Shorewall will now load module +files that are formed from the module name by appending +".o.gz".
    +
    11. +
+Migration Issues:
+
    +
  1. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page +for details.
    2. +
  2. The Uset Set capability introduced in SnapShot 20030821 has +changed -- see the User Set page for +details.
    3. +
  3. The per-interface Dynamic Blacklisting facility introduced in +the first post-1.4.6 Snapshot has been removed. The facility had +too many idiosyncrasies for dial-up users to be a viable part of +Shorewall.
    +
    4. +
+New Features:
+
    +
  1. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    2. +
  2. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    +With ADMINISABSENTMINDED=Yes (the default for new installs), in +addition to traffic to/from the hosts listed in +/etc/shorewall/routestopped, Shorewall will allow:
    +
    +   a) All traffic originating from the firewall itself; +and
    +   b) All traffic that is part of or related to an +already-existing connection.
    +
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.
    +
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.
    +
    + Example:
    +
    + /etc/shorewall/nat:
    +
    +     206.124.146.178    +eth0:0    192.168.1.5   
    +
    + /etc/shorewall/rules:
    +
    +   ACCEPT    net    +loc:192.168.1.5    tcp    22
    +   ACCEPT    loc    +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    3. +
  3. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
    + 
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
    + 
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:
    +
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
    + 
    +where:
    + 
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
    +       <ip address> is the IP +address of the remote tunnel gateway.
    +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    4. +
  4. An 'arp_filter' option has been added to the +/etc/shorewall/interfaces file. This option causes +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    5. +
  5. The ADDRESS column in /etc/shorewall/masq may now include a +comma-separated list of addresses and/or address ranges. Netfilter +will use all listed addresses/ranges in round-robin fashion. \
    6. +
  6. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting +documentation for a description of +this facility.
    7. +
  7. Bridge interfaces (br[0-9]) may now be used in +/etc/shorewall/maclist.
    8. +
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in +/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT +rules, rate limiting occurs in the nat table DNAT rule; the +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
    + 
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
    + 
    +To specify a rate limit,
    +
    +a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    + 
    +      < +<rate>/<interval>[:<burst>] >
    + 
    +  where
    + 
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
    +      <burst> is the largest burst +accepted within an <interval>. If not given, the default of 5 +is assumed.
    + 
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +
    +b) A new RATE LIMIT column has been added to the +/etc/shorewall/rules file. You may specify the rate limit there in +the format:
    +
    +      +<rate>/<interval>[:<burst>]
    + 
    +Let's take an example:
    + 
    +         +ACCEPT<2/sec:4>        +net     dmz     +tcp     80
    +   
    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
    +
    9. +
  9. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. +
  10. Output rules (those with $FW as the SOURCE) may now be limited +to a set of local users and/or groups. See http://shorewall.net/UserSets.html +for +details.
    11. +
+

8/27/2003 - Shorewall Mirror in Australia

+

Thanks to Dave Kempe and Solutions First (http://www.solutionsfirst.com.au), +there is now a +Shorewall Mirror in Australia:

+
http://www.shorewall.com.au
+ftp://ftp.shorewall.com.au
+

8/26/2003 - French Version of the Shorewall Setup +Guide 

+Thanks to Fabien Demassieux, there is now a French translation of the +Shorewall +Setup Guide. Merci Beacoup, Fabien! +

8/25/2003 - Shorewall 1.4.7 Beta 1
+

+

http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+

+Problems Corrected since version 1.4.6
+
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +   
    +The firewall script has been modified to eliminate the error +messages
    5. +
  5. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    6. +
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    +
    +
    7. +
+Migration Issues:
+
    +
  1. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page +for details.
    2. +
  2. The Uset Set capability introduced in SnapShot 20030821 has +changed -- see the User Set page for +details.
    3. +
  3. The per-interface Dynamic Blacklisting facility introduced in +the first post-1.4.6 Snapshot has been removed. The facility had +too many idiosyncrasies for dial-up users to be a viable part of +Shorewall.
    +
    4. +
+New Features:
+
    +
  1. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    2. +
  2. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    +With ADMINISABSENTMINDED=Yes (the default for new installs), in +addition to traffic to/from the hosts listed in +/etc/shorewall/routestopped, Shorewall will allow:
    +
    +   a) All traffic originating from the firewall itself; +and
    +   b) All traffic that is part of or related to an +already-existing connection.
    +
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.
    +
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.
    +
    + Example:
    +
    + /etc/shorewall/nat:
    +
    +     206.124.146.178    +eth0:0    192.168.1.5   
    +
    + /etc/shorewall/rules:
    +
    +   ACCEPT    net    +loc:192.168.1.5    tcp    22
    +   ACCEPT    loc    +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    3. +
  3. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
    + 
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
    + 
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:
    +
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
    + 
    +where:
    + 
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
    +       <ip address> is the IP +address of the remote tunnel gateway.
    +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    4. +
  4. An 'arp_filter' option has been added to the +/etc/shorewall/interfaces file. This option causes +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    5. +
  5. The ADDRESS column in /etc/shorewall/masq may now include a +comma-separated list of addresses and/or address ranges. Netfilter +will use all listed addresses/ranges in round-robin fashion. \
    6. +
  6. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting +documentation for a description of +this facility.
    7. +
  7. Bridge interfaces (br[0-9]) may now be used in +/etc/shorewall/maclist.
    8. +
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in +/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT +rules, rate limiting occurs in the nat table DNAT rule; the +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
    + 
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
    + 
    +To specify a rate limit,
    +
    +a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    + 
    +      < +<rate>/<interval>[:<burst>] >
    + 
    +  where
    + 
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
    +      <burst> is the largest burst +accepted within an <interval>. If not given, the default of 5 +is assumed.
    + 
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +
    +b) A new RATE LIMIT column has been added to the +/etc/shorewall/rules file. You may specify the rate limit there in +the format:
    +
    +      +<rate>/<interval>[:<burst>]
    + 
    +Let's take an example:
    + 
    +         +ACCEPT<2/sec:4>        +net     dmz     +tcp     80
    +   
    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
    +
    9. +
  9. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. +
  10. Output rules (those with $FW as the SOURCE) may now be limited +to a set of local users and/or groups. See http://shorewall.net/UserSets.html +for +details.
    +
    11. +
+

8/23/2003 - Snapshot 1.4.6_20030823

+
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+Problems Corrected since version 1.4.6
+
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +   
    +The firewall script has been modified to eliminate the error +messages
    5. +
  5. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    6. +
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    +
    +
    7. +
+Migration Issues:
+
    +
  1. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    2. +
  2. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
    3. +
  3. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page +for details.
    4. +
  4. The Uset Set capability introduced in SnapShot 20030821 has +changed -- see the User Set page for +details.
    5. +
+New Features:
+
    +
  1. Shorewall now creates a dynamic blacklisting chain for each +interface defined in /etc/shorewall/interfaces. The 'drop' and +'reject' commands use the routing table to determine which of these +chains is to be used for blacklisting the specified IP +address(es).
    +
    +Two new commands ('dropall' and 'rejectall') have been introduced +that do what 'drop' and 'reject' used to do; namely, when an +address is blacklisted using these new commands, it will be +blacklisted on all of your firewall's interfaces.
    2. +
  2. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    3. +
  3. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    +With ADMINISABSENTMINDED=Yes (the default for new installs), in +addition to traffic to/from the hosts listed in +/etc/shorewall/routestopped, Shorewall will allow:
    +
    +   a) All traffic originating from the firewall itself; +and
    +   b) All traffic that is part of or related to an +already-existing connection.
    +
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.
    +
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.
    +
    + Example:
    +
    + /etc/shorewall/nat:
    +
    +     206.124.146.178    +eth0:0    192.168.1.5   
    +
    + /etc/shorewall/rules:
    +
    +   ACCEPT    net    +loc:192.168.1.5    tcp    22
    +   ACCEPT    loc    +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    4. +
  4. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
    + 
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
    + 
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:
    +
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
    + 
    +where:
    + 
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
    +       <ip address> is the IP +address of the remote tunnel gateway.
    +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    5. +
  5. An 'arp_filter' option has been added to the +/etc/shorewall/interfaces file. This option causes +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    6. +
  6. The ADDRESS column in /etc/shorewall/masq may now include a +comma-separated list of addresses and/or address ranges. Netfilter +will use all listed addresses/ranges in round-robin fashion. \
    7. +
  7. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting +documentation for a description of +this facility.
    8. +
  8. Bridge interfaces (br[0-9]) may now be used in +/etc/shorewall/maclist.
    9. +
  9. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in +/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT +rules, rate limiting occurs in the nat table DNAT rule; the +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
    + 
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
    + 
    +To specify a rate limit,
    +
    +a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    + 
    +      < +<rate>/<interval>[:<burst>] >
    + 
    +  where
    + 
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
    +      <burst> is the largest burst +accepted within an <interval>. If not given, the default of 5 +is assumed.
    + 
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +
    +b) A new RATE LIMIT column has been added to the +/etc/shorewall/rules file. You may specify the rate limit there in +the format:
    +
    +      +<rate>/<interval>[:<burst>]
    + 
    +Let's take an example:
    + 
    +         +ACCEPT<2/sec:4>        +net     dmz     +tcp     80
    +   
    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
    +
    10. +
  10. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    11. +
  11. Output rules (those with $FW as the SOURCE) may now be limited +to a set of local users and/or groups. See http://shorewall.net/UserSets.html +for +details.
    +
    12. +
+

8/13/2003 - Snapshot 1.4.6_20030813  +

+
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+Problems Corrected since version 1.4.6
+
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +   
    +The firewall script has been modified to eliminate the error +messages
    5. +
  5.  Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    +
    +
    6. +
+Migration Issues:
+
    +
  1. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    2. +
  2. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
    3. +
+New Features:
+
    +
  1. Shorewall now creates a dynamic blacklisting chain for each +interface defined in /etc/shorewall/interfaces. The 'drop' and +'reject' commands use the routing table to determine which of these +chains is to be used for blacklisting the specified IP +address(es).
    +
    +Two new commands ('dropall' and 'rejectall') have been introduced +that do what 'drop' and 'reject' used to do; namely, when an +address is blacklisted using these new commands, it will be +blacklisted on all of your firewall's interfaces.
    2. +
  2. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    3. +
  3. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    +With ADMINISABSENTMINDED=Yes (the default for new installs), in +addition to traffic to/from the hosts listed in +/etc/shorewall/routestopped, Shorewall will allow:
    +
    +   a) All traffic originating from the firewall itself; +and
    +   b) All traffic that is part of or related to an +already-existing connection.
    +
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.
    +
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.
    +
    + Example:
    +
    + /etc/shorewall/nat:
    +
    +     206.124.146.178    +eth0:0    192.168.1.5   
    +
    + /etc/shorewall/rules:
    +
    +   ACCEPT    net    +loc:192.168.1.5    tcp    22
    +   ACCEPT    loc    +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    4. +
  4. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
    + 
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
    + 
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:
    +
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
    + 
    +where:
    + 
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
    +       <ip address> is the IP +address of the remote tunnel gateway.
    +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    5. +
  5. An 'arp_filter' option has been added to the +/etc/shorewall/interfaces file. This option causes +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    6. +
  6. The ADDRESS column in /etc/shorewall/masq may now include a +comma-separated list of addresses and/or address ranges. Netfilter +will use all listed addresses/ranges in round-robin fashion. \
    7. +
  7. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting +documentation for a description of +this facility.
    8. +
  8. Bridge interfaces (br[0-9]) may now be used in +/etc/shorewall/maclist.
    9. +
  9. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in +/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT +rules, rate limiting occurs in the nat table DNAT rule; the +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
    + 
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
    + 
    +To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG +with
     
          < <rate>/<interval>[:<burst>] >
     
       where
     
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
          <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    +accepted within an <interval>. If not given, the default of 5 +is assumed.
     
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
     
    Let's take an example:
     
    @@ -6092,98 +5494,87 @@ ACCEPT<2/sec:4>        net     dmz     tcp     80
       
    -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
    -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.

    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
-

8/9/2003 - Snapshot 1.4.6_20030809 

-
http://shorewall.net/pub/shorewall/Snapshots/
- ftp://shorewall.net/pub/shorewall/Snapshots/
-

Problems Corrected since version 1.4.6

+

8/9/2003 - Snapshot 1.4.6_20030809  +

+
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+Problems Corrected since version 1.4.6
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses -were being added to a PPP interface; the addresses were successfully -added in spite of the messages.
    +

  5. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    6. +
  6. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    7. +
  7. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    8. +
  8. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
       
    -The firewall script has been modified to eliminate the error messages

    +The firewall script has been modified to eliminate the error +messages
-

Migration Issues:

+Migration Issues:
    -
  1. -

    Once you have installed this version -of Shorewall, you must restart Shorewall before you may use the 'drop', -'reject', 'allow' or 'save' commands.

    -
    2. -
  2. -

    To maintain strict compatibility with previous versions, current -uses of "shorewall drop" and "shorewall reject" should be replaced with -"shorewall dropall" and "shorewall rejectall"

    -
    3. +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. +
  4. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
-

New Features:

+New Features:
    -
  1. -

    Shorewall now creates a dynamic -blacklisting chain for each interface defined in -/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the -routing table to determine which of these chains is to be used for -blacklisting the specified IP address(es).
    +

  2. Shorewall now creates a dynamic blacklisting chain for each +interface defined in /etc/shorewall/interfaces. The 'drop' and +'reject' commands use the routing table to determine which of these +chains is to be used for blacklisting the specified IP +address(es).

    -Two new commands ('dropall' and 'rejectall') have been introduced that -do what 'drop' and 'reject' used to do; namely, when an address is -blacklisted using these new commands, it will be blacklisted on all of -your firewall's interfaces.

    -
    3. -
  3. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    4. -
  4. -

    A new option "ADMINISABSENTMINDED" -has been added to /etc/shorewall/shorewall.conf. This option has a -default value of "No" for existing users which causes Shorewall's -'stopped' state  to continue as it has been; namely, in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped is accepted.
    +Two new commands ('dropall' and 'rejectall') have been introduced +that do what 'drop' and 'reject' used to do; namely, when an +address is blacklisted using these new commands, it will be +blacklisted on all of your firewall's interfaces.

    5. +
  5. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    6. +
  6. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.

    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:

    -   a) All traffic originating from the firewall itself; and
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.

    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.

    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.

     Example:

    @@ -6197,182 +5588,164 @@ eth0:0    192.168.1.5   
       ACCEPT    net    loc:192.168.1.5    tcp    22
       ACCEPT    loc    -fw        tcp    22
    +fw        tcp    +22

    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    7. -
  7. -

    Given the wide range of VPN -software, I can never hope to add specific support for all of it. I -have therefore decided to add "generic" tunnel support.
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!

    8. +
  8. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    +In the /etc/shorewall/tunnels file, you can have entries of the +form:

    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +generic:<protocol>[:<port>]  <zone>  +<ip address>    <gateway zones>
     
    where:
     
    -       <protocol> is the protocol -used by the tunnel
    -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
    -       <zone>  is the zone of -the remote tunnel gateway
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.

    -
    9. -
  9. -

    An 'arp_filter' option has been added to the +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.

    10. +
  10. An 'arp_filter' option has been added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.

    +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
-

8/5/2003 - Shorewall-1.4.6b 

-

Problems Corrected since version 1.4.6:

+

8/5/2003 - Shorewall-1.4.6b 
+

+Problems Corrected since version 1.4.6:
    -
  1. -

    Previously, if TC_ENABLED is set to -yes in shorewall.conf then Shorewall would fail to start with the error -"ERROR:  Traffic Control requires Mangle"; that problem has been -corrected.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses -were being added to a PPP interface; the addresses were successfully -added in spite of the messages.
    -  
    -The firewall script has been modified to eliminate the error messages.

    -
    5. -
-

8/5/2003 - Shorewall-1.4.6b

-

Problems Corrected since version 1.4.6:

-
    -
  1. -

    Previously, if TC_ENABLED is set to -yes in shorewall.conf then Shorewall would fail to start with the error -"ERROR:  Traffic Control requires Mangle"; that problem has been -corrected.

    -
    2. -
  2. -

    Corrected handling of MAC addresses -in the SOURCE column of the tcrules file. Previously, these addresses -resulted in an invalid iptables command.

    -
    3. -
  3. -

    The "shorewall stop" command is now -disabled when /etc/shorewall/startup_disabled exists. This prevents -people from shooting themselves in the foot prior to having configured -Shorewall.

    -
    4. -
  4. -

    A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses -were being added to a PPP interface; the addresses were successfully -added in spite of the messages.
    -  
    -The firewall script has been modified to eliminate the error messages.

    -
    5. -
-

7/31/2003 - Snapshot 1.4.6_20030731

-
http://shorewall.net/pub/shorewall/Snapshots/
- ftp://shorewall.net/pub/shorewall/Snapshots/
-

Problems Corrected since version 1.4.6:

-
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses in the SOURCE column of the +

  3. Previously, if TC_ENABLED is set to yes in shorewall.conf then +Shorewall would fail to start with the error "ERROR:  Traffic +Control requires Mangle"; that problem has been corrected.
    4. +
  4. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid -iptables command.

    +iptables command.
    5. +
  5. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    6. +
  6. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +  
    +The firewall script has been modified to eliminate the error +messages.
    7. +
+

8/5/2003 - Shorewall-1.4.6b
+

+Problems Corrected since version 1.4.6:
+
    +
  1. Previously, if TC_ENABLED is set to yes in shorewall.conf then +Shorewall would fail to start with the error "ERROR:  Traffic +Control requires Mangle"; that problem has been corrected.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    3. +
  3. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    4. +
  4. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +  
    +The firewall script has been modified to eliminate the error +messages.
-

Migration Issues:

+

7/31/2003 - Snapshot 1.4.6_20030731

+
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+

Problems Corrected since version 1.4.6:
+

    -
  1. -

    Once you have installed this version -of Shorewall, you must restart Shorewall before you may use the 'drop', -'reject', 'allow' or 'save' commands.

    -
    2. -
  2. -

    To maintain strict compatibility with previous versions, current -uses of "shorewall drop" and "shorewall reject" should be replaced with -"shorewall dropall" and "shorewall rejectall"

    +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
-

New Features:

+

Migration Issues:
+

    -
  1. -

    Shorewall now creates a dynamic -blacklisting chain for each interface defined in -/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the -routing table to determine which of these chains is to be used for -blacklisting the specified IP address(es).
    +

  2. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    3. +
  3. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
    4. +
+

New Features:
+

+
    +
  1. Shorewall now creates a dynamic blacklisting chain for each +interface defined in /etc/shorewall/interfaces. The 'drop' and +'reject' commands use the routing table to determine which of these +chains is to be used for blacklisting the specified IP +address(es).

    -Two new commands ('dropall' and 'rejectall') have been introduced that -do what 'drop' and 'reject' used to do; namely, when an address is -blacklisted using these new commands, it will be blacklisted on all of -your firewall's interfaces.

    -
    2. -
  2. -

    Thanks to Steve Herber, the 'help' -command can now give command-specific help (e.g., shorewall help -<command>).

    -
    3. -
  3. -

    A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of "No" -for existing users which causes Shorewall's 'stopped' state  to -continue as it has been; namely, in the stopped state only traffic -to/from hosts listed in /etc/shorewall/routestopped is accepted.
    +Two new commands ('dropall' and 'rejectall') have been introduced +that do what 'drop' and 'reject' used to do; namely, when an +address is blacklisted using these new commands, it will be +blacklisted on all of your firewall's interfaces.

    4. +
  4. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).
    5. +
  5. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.

    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:

    -   a) All traffic originating from the firewall itself; and
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.

    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    + In particular, with ADMINISABSENTMINDED=Yes, a "shorewall +stop" entered through an ssh session will not kill the session.

    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    + Note though that even with ADMINISABSENTMINDED=Yes, it is +still possible for people to shoot themselves in the foot.

     Example:

    @@ -6386,281 +5759,286 @@ eth0:0    192.168.1.5   
       ACCEPT    net    loc:192.168.1.5    tcp    22
       ACCEPT    loc    -fw        tcp    22
    +fw        tcp    +22

    -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection from that computer to the firewall and confidently type -"shorewall stop". As part of its stop processing, Shorewall removes -eth0:0 which kills my SSH connection to 192.168.1.5!!!

    -
    6. +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
-

7/27/2003 - Snapshot 1.4.6_20030727

-
http://shorewall.net/pub/shorewall/Snapshots/
- ftp://shorewall.net/pub/shorewall/Snapshots/
-

Problems Corrected since version 1.4.6

+

7/27/2003 - Snapshot 1.4.6_20030727

+
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+Problems Corrected since version 1.4.6
    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses in the SOURCE column of the +

  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. +
  4. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid -iptables command.

    +iptables command.
-

Migration Issues:

+Migration Issues:
    -
  1. -

    Once you have installed this version -of Shorewall, you must restart Shorewall before you may use the 'drop', -'reject', 'allow' or 'save' commands.

    -
    2. -
  2. -

    To maintain strict compatibility with previous versions, current -uses of "shorewall drop" and "shorewall reject" should be replaced with -"shorewall dropall" and "shorewall rejectall"

    -
    3. +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. +
  4. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
-

New Features:

+New Features:
    -
  1. -

    Shorewall now creates a dynamic -blacklisting chain for each interface defined in -/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the -routing table to determine which of these chains is to be used for -blacklisting the specified IP address(es).
    +

  2. Shorewall now creates a dynamic blacklisting chain for each +interface defined in /etc/shorewall/interfaces. The 'drop' and +'reject' commands use the routing table to determine which of these +chains is to be used for blacklisting the specified IP +address(es).

    -Two new commands ('dropall' and 'rejectall') have been introduced that -do what 'drop' and 'reject' used to do; namely, when an address is -blacklisted using these new commands, it will be blacklisted on all of -your firewall's interfaces.

    -
    3. -
  3. -

    Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).

    +Two new commands ('dropall' and 'rejectall') have been introduced +that do what 'drop' and 'reject' used to do; namely, when an +address is blacklisted using these new commands, it will be +blacklisted on all of your firewall's interfaces.
    4. +
  4. Thanks to Steve Herber, the 'help' command can now give +command-specific help (e.g., shorewall help <command>).

7/26/2003 - Snapshot 1.4.6_20030726

-
http://shorewall.net/pub/shorewall/Snapshots/
- ftp://shorewall.net/pub/shorewall/Snapshots/
-

Problems Corrected since version 1.4.6:

+
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+

Problems Corrected since version 1.4.6:
+

    -
  1. -

    Corrected problem in 1.4.6 where the -MANGLE_ENABLED variable was being tested before it was set.

    -
    2. -
  2. -

    Corrected handling of MAC addresses in the SOURCE column of the +

  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. +
  4. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid -iptables command.

    +iptables command.
-

Migration Issues:

+

Migration Issues:
+

    -
  1. -

    Once you have installed this version -of Shorewall, you must restart Shorewall before you may use the 'drop', -'reject', 'allow' or 'save' commands.

    -
    2. -
  2. -

    To maintain strict compatibility with previous versions, current -uses of "shorewall drop" and "shorewall reject" should be replaced with -"shorewall dropall" and "shorewall rejectall"

    -
    3. +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. +
  4. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
-

New Features:

-

Shorewall now creates a dynamic blacklisting chain for each +

New Features:
+

+Shorewall now creates a dynamic blacklisting chain for each interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use the routing table to determine which of these chains is to be used for blacklisting the specified IP address(es).

-Two new commands ('dropall' and 'rejectall') have -been introduced that do what 'drop' and 'reject' used to do; namely, -when an address is blacklisted using these new commands, it will be -blacklisted on all of your firewall's interfaces.

-

7/22/2003 - Shorewall-1.4.6a

-

Problems Corrected:

+Two new commands ('dropall' and 'rejectall') have been introduced +that do what 'drop' and 'reject' used to do; namely, when an +address is blacklisted using these new commands, it will be +blacklisted on all of your firewall's interfaces. +

7/22/2003 - Shorewall-1.4.6a
+

+Problems Corrected:
    -
  1. -

    Previously, if TC_ENABLED is set to yes in shorewall.conf then +

  2. Previously, if TC_ENABLED is set to yes in shorewall.conf then Shorewall would fail to start with the error "ERROR:  Traffic -Control requires Mangle"; that problem has been corrected.

    -
    3. +Control requires Mangle"; that problem has been corrected.
-

7/20/2003 - Shorewall-1.4.6

-

Problems Corrected:

+

7/20/2003 - Shorewall-1.4.6
+

+

Problems Corrected:
+

    -
  1. -

    A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been worked -around.

    +
  2. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    3. -
  3. -

    Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the -nat table (one for each element in the list). Shorewall now correctly -creates a single DNAT rule with multiple "--to-destination" clauses.

    +
  4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in +the nat table (one for each element in the list). Shorewall now +correctly creates a single DNAT rule with multiple +"--to-destination" clauses.
    +
    5. -
  5. -

    Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a rule.

    +
  6. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a +rule.
    +
    7. -
  7. -

    A number of problems with rule parsing have been corrected. +

  8. A number of problems with rule parsing have been corrected. Corrections involve the handling of "z1!z2" in the SOURCE column as -well as lists in the ORIGINAL DESTINATION column.

    +well as lists in the ORIGINAL DESTINATION column.
    +
    9. -
  9. -

    The message "Adding rules for DHCP" is now suppressed if there -are no DHCP rules to add.

    +
  10. The message "Adding rules for DHCP" is now suppressed if there +are no DHCP rules to add.
-

Migration Issues:

+

Migration Issues:
+

    -
  1. -

    In earlier versions, an undocumented feature allowed entries in +

  2. In earlier versions, an undocumented feature allowed entries in the host file as follows:

        z    eth1:192.168.1.0/24,eth2:192.168.2.0/24

    -This capability was never documented and has been removed in 1.4.6 to -allow entries of the following format:
    +This capability was never documented and has been removed in 1.4.6 +to allow entries of the following format:
    +
    +    z   eth1:192.168.1.0/24,192.168.2.0/24

    -    z   eth1:192.168.1.0/24,192.168.2.0/24

    3. -
  3. -

    The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now -automatically detected by Shorewall (see below).

    +
  4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are +now automatically detected by Shorewall (see below).
-

New Features:

+

New Features:
+

    -
  1. -

    A 'newnotsyn' interface option has been added. This option may +

  2. A 'newnotsyn' interface option has been added. This option may be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.

    +NEWNOTSYN=No for packets arriving on the associated interface.
    +
    3. -
  3. -

    The means for specifying a range of IP addresses in +

  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. -ADD_SNAT_ALIASES=Yes is enabled for address ranges.

    +ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    +
    5. -
  5. -

    Shorewall can now add IP addresses to subnets other than the -first one on an interface.

    +
  6. Shorewall can now add IP addresses to subnets other than the +first one on an interface.
    +
    7. -
  7. -

    DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses -given as <first address>-<last address>.
    +

  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of +addresses given as <first address>-<last address>.

    Example:

    -    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80

    -
    9. -
  9. -

    The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report the outcome:
    +    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    10. +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    -Verifying Configuration...

    -
    11. -
  11. -

    Support for the Connection Tracking -Match Extension has been added. This extension is available in recent -kernel/iptables releases and allows for rules which match against -elements in netfilter's connection tracking table. Shorewall -automatically detects the availability of this extension and reports -its availability in the output of the start, restart and check commands.
    +Verifying Configuration...

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    12. +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in +netfilter's connection tracking table. Shorewall automatically +detects the availability of this extension and reports its +availability in the output of the start, restart and check +commands.
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
       Connection Tracking Match: Available
    Verifying Configuration...

    -If this extension is available, the ruleset generated by Shorewall is -changed in the following ways:

    +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
    13. +
    13. -
    • -

      To handle 'norfc1918' filtering, -Shorewall will not create chains in the mangle table but will rather do -all 'norfc1918' filtering in the filter table (rfc1918 chain).

      -
      • -
    • -

      Recall that Shorewall DNAT rules generate two netfilter -rules; one in the nat table and one in the filter table. If the -Connection Tracking Match Extension is available, the rule in the -filter table is extended to check that the original destination address -was the same as specified (or defaulted to) in the DNAT rule.

      +
    • To handle 'norfc1918' filtering, Shorewall will not create +chains in the mangle table but will rather do all 'norfc1918' +filtering in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter +rules; +one in the nat table and one in the filter table. If the Connection +Tracking Match Extension is available, the rule in the filter table +is extended to check that the original destination address was the +same as specified (or defaulted to) in the DNAT rule.
      +
    14. -
  14. -

    The shell used to interpret the firewall script +

  15. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the -SHOREWALL_SHELL parameter in shorewall.conf.

    -
    16. -
  16. -

    An 'ipcalc' command has been added to /sbin/shorewall.
    +SHOREWALL_SHELL parameter in shorewall.conf.

    -      ipcalc [ <address> <netmask> -| <address>/<vlsm> ]
    +

    17. +
  17. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +      ipcalc [ <address> +<netmask> | <address>/<vlsm> ]

    Examples:

          [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#

          [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#

    Warning:

    If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP addresses -128.0.0.0-1 and for /1 networks. Bash should produce correct -information for all valid IP addresses.

    +then the ipcalc command produces incorrect information for IP +addresses 128.0.0.0-1 and for /1 networks. Bash should produce +correct information for all valid IP addresses.
    +
    18. -
  18. -

    An 'iprange' command has been added to /sbin/shorewall.
    +

  19. An 'iprange' command has been added to /sbin/shorewall.

    -      iprange <address>-<address>
    +      iprange +<address>-<address>

    -This command decomposes a range of IP addressses into a list of network -and host addresses. The command can be useful if you need to construct -an efficient set of rules that accept connections from a range of -network addresses.
    +This command decomposes a range of IP addressses into a list of +network and host addresses. The command can be useful if you need +to construct an efficient set of rules that accept connections from +a range of network addresses.

    Note: If your shell only supports 32-bit signed arithmetic (ash or dash) then the range may not span 128.0.0.0.

    Example:

    -      [root@gateway root]# shorewall iprange -192.168.1.4-192.168.12.9
    +      [root@gateway root]# shorewall +iprange 192.168.1.4-192.168.12.9
          192.168.1.4/30
          192.168.1.8/29
          192.168.1.16/28
    @@ -6672,19 +6050,19 @@ Example:
          192.168.8.0/22
          192.168.12.0/29
          192.168.12.8/31
    -      [root@gateway root]#

    +      [root@gateway root]#
    +
    20. -
  20. -

    A list of host/net addresses is now allowed in an entry in +

  21. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.

    Example:

        foo    -eth1:192.168.1.0/24,192.168.2.0/24

    +eth1:192.168.1.0/24,192.168.2.0/24
    +
    22. -
  22. -

    The "shorewall check" command now includes the chain name when +

  23. The "shorewall check" command now includes the chain name when printing the applicable policy for each pair of zones.
     
        Example:
    @@ -6692,185 +6070,201 @@ printing the applicable policy for each pair of zones.
            Policy for dmz to net is REJECT using chain all2all
     
    -This means that the policy for connections from the dmz to the internet -is REJECT and the applicable entry in the /etc/shorewall/policy was the -all->all policy.

    +This means that the policy for connections from the dmz to the +internet is REJECT and the applicable entry in the +/etc/shorewall/policy was the all->all policy.
    +
    24. -
  24. -

    Support for the 2.6 Kernel series has been added.

    +
  25. Support for the 2.6 Kernel series has been added.
-

7/15/2003 - New Mirror in Brazil

-

Thanks to the folks at securityopensource.org.br, there is now a -Shorewall -mirror in Brazil.

-

7/15/2003 - Shorewall-1.4.6 RC 1

-

Problems Corrected:

+

7/15/2003 - New Mirror in Brazil
+

+Thanks to the folks at securityopensource.org.br, there is now a Shorewall +mirror in Brazil. +

7/15/2003 - Shorewall-1.4.6 RC 1
+

+

Problems Corrected:
+

    -
  1. -

    A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been worked -around.

    +
  2. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    3. -
  3. -

    Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the -nat table (one for each element in the list). Shorewall now correctly -creates a single DNAT rule with multiple "--to-destination" clauses.

    +
  4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in +the nat table (one for each element in the list). Shorewall now +correctly creates a single DNAT rule with multiple +"--to-destination" clauses.
    +
    5. -
  5. -

    Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a rule.

    +
  6. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a +rule.
    +
    7. -
  7. -

    A number of problems with rule parsing have been corrected. +

  8. A number of problems with rule parsing have been corrected. Corrections involve the handling of "z1!z2" in the SOURCE column as -well as lists in the ORIGINAL DESTINATION column.

    +well as lists in the ORIGINAL DESTINATION column.
-

Migration Issues:

+

Migration Issues:
+

    -
  1. -

    In earlier versions, an undocumented feature allowed entries in +

  2. In earlier versions, an undocumented feature allowed entries in the host file as follows:

        z    eth1:192.168.1.0/24,eth2:192.168.2.0/24

    -This capability was never documented and has been removed in 1.4.6 to -allow entries of the following format:
    +This capability was never documented and has been removed in 1.4.6 +to allow entries of the following format:
    +
    +    z   eth1:192.168.1.0/24,192.168.2.0/24

    -    z   eth1:192.168.1.0/24,192.168.2.0/24

    3. -
  3. -

    The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now -automatically detected by Shorewall (see below).

    +
  4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are +now automatically detected by Shorewall (see below).
-

New Features:

+

New Features:
+

    -
  1. -

    A 'newnotsyn' interface option has been added. This option may +

  2. A 'newnotsyn' interface option has been added. This option may be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.

    +NEWNOTSYN=No for packets arriving on the associated interface.
    +
    3. -
  3. -

    The means for specifying a range of IP addresses in +

  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. -ADD_SNAT_ALIASES=Yes is enabled for address ranges.

    +ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    +
    5. -
  5. -

    Shorewall can now add IP addresses to subnets other than the -first one on an interface.

    +
  6. Shorewall can now add IP addresses to subnets other than the +first one on an interface.
    +
    7. -
  7. -

    DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses -given as <first address>-<last address>.
    +

  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of +addresses given as <first address>-<last address>.

    Example:

    -    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80

    -
    9. -
  9. -

    The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report the outcome:
    +    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    10. +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    -Verifying Configuration...

    -
    11. -
  11. -

    Support for the Connection Tracking -Match Extension has been added. This extension is available in recent -kernel/iptables releases and allows for rules which match against -elements in netfilter's connection tracking table. Shorewall -automatically detects the availability of this extension and reports -its availability in the output of the start, restart and check commands.
    +Verifying Configuration...

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    12. +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in +netfilter's connection tracking table. Shorewall automatically +detects the availability of this extension and reports its +availability in the output of the start, restart and check +commands.
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
       Connection Tracking Match: Available
    Verifying Configuration...

    -If this extension is available, the ruleset generated by Shorewall is -changed in the following ways:

    +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
    13. +
    13. -
    • -

      To handle 'norfc1918' filtering, -Shorewall will not create chains in the mangle table but will rather do -all 'norfc1918' filtering in the filter table (rfc1918 chain).

      -
      • -
    • -

      Recall that Shorewall DNAT rules generate two netfilter -rules; one in the nat table and one in the filter table. If the -Connection Tracking Match Extension is available, the rule in the -filter table is extended to check that the original destination address -was the same as specified (or defaulted to) in the DNAT rule.

      +
    • To handle 'norfc1918' filtering, Shorewall will not create +chains in the mangle table but will rather do all 'norfc1918' +filtering in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter +rules; +one in the nat table and one in the filter table. If the Connection +Tracking Match Extension is available, the rule in the filter table +is extended to check that the original destination address was the +same as specified (or defaulted to) in the DNAT rule.
      +
    14. -
  14. -

    The shell used to interpret the firewall script +

  15. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the -SHOREWALL_SHELL parameter in shorewall.conf.

    -
    16. -
  16. -

    An 'ipcalc' command has been added to /sbin/shorewall.
    +SHOREWALL_SHELL parameter in shorewall.conf.

    -      ipcalc [ <address> <netmask> -| <address>/<vlsm> ]
    +

    17. +
  17. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +      ipcalc [ <address> +<netmask> | <address>/<vlsm> ]

    Examples:

          [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#

          [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#

    Warning:

    If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP addresses -128.0.0.0-1 and for /1 networks. Bash should produce correct -information for all valid IP addresses.

    +then the ipcalc command produces incorrect information for IP +addresses 128.0.0.0-1 and for /1 networks. Bash should produce +correct information for all valid IP addresses.
    +
    18. -
  18. -

    An 'iprange' command has been added to /sbin/shorewall.
    +

  19. An 'iprange' command has been added to /sbin/shorewall.

    -      iprange <address>-<address>
    +      iprange +<address>-<address>

    -This command decomposes a range of IP addressses into a list of network -and host addresses. The command can be useful if you need to construct -an efficient set of rules that accept connections from a range of -network addresses.
    +This command decomposes a range of IP addressses into a list of +network and host addresses. The command can be useful if you need +to construct an efficient set of rules that accept connections from +a range of network addresses.

    Note: If your shell only supports 32-bit signed arithmetic (ash or dash) then the range may not span 128.0.0.0.

    Example:

    -      [root@gateway root]# shorewall iprange -192.168.1.4-192.168.12.9
    +      [root@gateway root]# shorewall +iprange 192.168.1.4-192.168.12.9
          192.168.1.4/30
          192.168.1.8/29
          192.168.1.16/28
    @@ -6882,180 +6276,193 @@ Example:
          192.168.8.0/22
          192.168.12.0/29
          192.168.12.8/31
    -      [root@gateway root]#

    +      [root@gateway root]#
    +
    20. -
  20. -

    A list of host/net addresses is now allowed in an entry in +

  21. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.

    Example:

        foo    -eth1:192.168.1.0/24,192.168.2.0/24

    -
    22. +eth1:192.168.1.0/24,192.168.2.0/24

7/7/2003 - Shorewall-1.4.6 Beta 2

-

Problems Corrected:

+

Problems Corrected:
+

    -
  1. -

    A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been worked -around.

    +
  2. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    3. -
  3. -

    Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the -nat table (one for each element in the list). Shorewall now correctly -creates a single DNAT rule with multiple "--to-destination" clauses.

    +
  4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in +the nat table (one for each element in the list). Shorewall now +correctly creates a single DNAT rule with multiple +"--to-destination" clauses.
    +
    5. -
  5. -

    Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a rule.

    +
  6. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a +rule.
-

Migration Issues:

+

Migration Issues:
+

    -
  1. -

    In earlier versions, an undocumented feature allowed entries in +

  2. In earlier versions, an undocumented feature allowed entries in the host file as follows:

        z    eth1:192.168.1.0/24,eth2:192.168.2.0/24

    -This capability was never documented and has been removed in 1.4.6 to -allow entries of the following format:
    +This capability was never documented and has been removed in 1.4.6 +to allow entries of the following format:
    +
    +    z   eth1:192.168.1.0/24,192.168.2.0/24

    -    z   eth1:192.168.1.0/24,192.168.2.0/24

    3. -
  3. -

    The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now -automatically detected by Shorewall (see below).

    +
  4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are +now automatically detected by Shorewall (see below).
-

New Features:

+

New Features:
+

    -
  1. -

    A 'newnotsyn' interface option has been added. This option may +

  2. A 'newnotsyn' interface option has been added. This option may be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.

    +NEWNOTSYN=No for packets arriving on the associated interface.
    +
    3. -
  3. -

    The means for specifying a range of IP addresses in +

  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. -ADD_SNAT_ALIASES=Yes is enabled for address ranges.

    +ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    +
    5. -
  5. -

    Shorewall can now add IP addresses to subnets other than the -first one on an interface.

    +
  6. Shorewall can now add IP addresses to subnets other than the +first one on an interface.
    +
    7. -
  7. -

    DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses -given as <first address>-<last address>.
    +

  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of +addresses given as <first address>-<last address>.

    Example:

    -    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80

    -
    9. -
  9. -

    The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report the outcome:
    +    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    10. +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    -Verifying Configuration...

    -
    11. -
  11. -

    Support for the Connection Tracking -Match Extension has been added. This extension is available in recent -kernel/iptables releases and allows for rules which match against -elements in netfilter's connection tracking table. Shorewall -automatically detects the availability of this extension and reports -its availability in the output of the start, restart and check commands.
    +Verifying Configuration...

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    12. +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in +netfilter's connection tracking table. Shorewall automatically +detects the availability of this extension and reports its +availability in the output of the start, restart and check +commands.
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
       Connection Tracking Match: Available
    Verifying Configuration...

    -If this extension is available, the ruleset generated by Shorewall is -changed in the following ways:

    +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
    13. +
    13. -
    • -

      To handle 'norfc1918' filtering, -Shorewall will not create chains in the mangle table but will rather do -all 'norfc1918' filtering in the filter table (rfc1918 chain).

      -
      • -
    • -

      Recall that Shorewall DNAT rules generate two netfilter -rules; one in the nat table and one in the filter table. If the -Connection Tracking Match Extension is available, the rule in the -filter table is extended to check that the original destination address -was the same as specified (or defaulted to) in the DNAT rule.

      +
    • To handle 'norfc1918' filtering, Shorewall will not create +chains in the mangle table but will rather do all 'norfc1918' +filtering in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter +rules; +one in the nat table and one in the filter table. If the Connection +Tracking Match Extension is available, the rule in the filter table +is extended to check that the original destination address was the +same as specified (or defaulted to) in the DNAT rule.
      +
    14. -
  14. -

    The shell used to interpret the firewall script +

  15. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the -SHOREWALL_SHELL parameter in shorewall.conf.

    -
    16. -
  16. -

    An 'ipcalc' command has been added to /sbin/shorewall.
    +SHOREWALL_SHELL parameter in shorewall.conf.

    -      ipcalc [ <address> <netmask> -| <address>/<vlsm> ]
    +

    17. +
  17. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +      ipcalc [ <address> +<netmask> | <address>/<vlsm> ]

    Examples:

          [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#

          [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#

    Warning:

    If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP addresses -128.0.0.0-1 and for /1 networks. Bash should produce correct -information for all valid IP addresses.

    +then the ipcalc command produces incorrect information for IP +addresses 128.0.0.0-1 and for /1 networks. Bash should produce +correct information for all valid IP addresses.
    +
    18. -
  18. -

    An 'iprange' command has been added to /sbin/shorewall.
    +

  19. An 'iprange' command has been added to /sbin/shorewall.

    -      iprange <address>-<address>
    +      iprange +<address>-<address>

    -This command decomposes a range of IP addressses into a list of network -and host addresses. The command can be useful if you need to construct -an efficient set of rules that accept connections from a range of -network addresses.
    +This command decomposes a range of IP addressses into a list of +network and host addresses. The command can be useful if you need +to construct an efficient set of rules that accept connections from +a range of network addresses.

    Note: If your shell only supports 32-bit signed arithmetic (ash or dash) then the range may not span 128.0.0.0.

    Example:

    -      [root@gateway root]# shorewall iprange -192.168.1.4-192.168.12.9
    +      [root@gateway root]# shorewall +iprange 192.168.1.4-192.168.12.9
          192.168.1.4/30
          192.168.1.8/29
          192.168.1.16/28
    @@ -7067,53 +6474,56 @@ Example:
          192.168.8.0/22
          192.168.12.0/29
          192.168.12.8/31
    -      [root@gateway root]#

    +      [root@gateway root]#
    +
    20. -
  20. -

    A list of host/net addresses is now allowed in an entry in +

  21. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.

    Example:

        foo    -eth1:192.168.1.0/24,192.168.2.0/24

    +eth1:192.168.1.0/24,192.168.2.0/24
    +

7/4/2003 - Shorewall-1.4.6 Beta 1

-

Problems Corrected:

+

Problems Corrected:
+

    -
  1. -

    A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been worked -around.

    +
  2. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    3. -
  3. -

    Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the -nat table (one for each element in the list). Shorewall now correctly -creates a single DNAT rule with multiple "--to-destination" clauses.

    +
  4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in +the nat table (one for each element in the list). Shorewall now +correctly creates a single DNAT rule with multiple +"--to-destination" clauses.
-

New Features:

+

New Features:
+

    -
  1. -

    A 'newnotsyn' interface option has been added. This option may +

  2. A 'newnotsyn' interface option has been added. This option may be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.

    +NEWNOTSYN=No for packets arriving on the associated interface.
    +
    3. -
  3. -

    The means for specifying a range of IP addresses in +

  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. -ADD_SNAT_ALIASES=Yes is enabled for address ranges.

    +ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    +
    5. -
  5. -

    Shorewall can now add IP addresses to subnets other than the -first one on an interface.

    +
  6. Shorewall can now add IP addresses to subnets other than the +first one on an interface.
    +
    7. -
  7. -

    DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Up to 256 servers may be specified in a range of -addresses given as <first address>-<last address>.
    +

  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Up to 256 servers may be specified in a +range of addresses given as <first address>-<last +address>.

    Example:

    @@ -7121,155 +6531,159 @@ Example:

    Note that this capability has previously been available using a combination of a DNAT- rule and one or more ACCEPT rules. That -technique is still preferable for load-balancing over a large number of -servers (> 16) since specifying a range in the DNAT rule causes one -filter table ACCEPT rule to be generated for each IP address in the -range.

    -
    9. -
  9. -

    The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report the outcome:
    +technique is still preferable for load-balancing over a large +number of servers (> 16) since specifying a range in the DNAT +rule causes one filter table ACCEPT rule to be generated for each +IP address in the range.

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    10. +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    -Verifying Configuration...

    -
    11. -
  11. -

    Support for the Connection Tracking -Match Extension has been added. This extension is available in recent -kernel/iptables releases and allows for rules which match against -elements in netfilter's connection tracking table. Shorewall -automatically detects the availability of this extension and reports -its availability in the output of the start, restart and check commands.
    +Verifying Configuration...

    -Shorewall has detected the following iptables/netfilter capabilities:
    +

    12. +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in +netfilter's connection tracking table. Shorewall automatically +detects the availability of this extension and reports its +availability in the output of the start, restart and check +commands.
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
       Connection Tracking Match: Available
    Verifying Configuration...

    -If this extension is available, the ruleset generated by Shorewall is -changed in the following ways:

    +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
    13. +
    13. -
    • -

      To handle 'norfc1918' filtering, -Shorewall will not create chains in the mangle table but will rather do -all 'norfc1918' filtering in the filter table (rfc1918 chain).

      -
      • -
    • -

      Recall that Shorewall DNAT rules generate two netfilter -rules; one in the nat table and one in the filter table. If the -Connection Tracking Match Extension is available, the rule in the -filter table is extended to check that the original destination address -was the same as specified (or defaulted to) in the DNAT rule.

      +
    • To handle 'norfc1918' filtering, Shorewall will not create +chains in the mangle table but will rather do all 'norfc1918' +filtering in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter +rules; +one in the nat table and one in the filter table. If the Connection +Tracking Match Extension is available, the rule in the filter table +is extended to check that the original destination address was the +same as specified (or defaulted to) in the DNAT rule.
      +
    14. -
  14. -

    The shell used to interpret the firewall script +

  15. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the -SHOREWALL_SHELL parameter in shorewall.conf.

    +SHOREWALL_SHELL parameter in shorewall.conf.

6/17/2003 - Shorewall-1.4.5

-

Problems Corrected:

+

Problems Corrected:
+

    -
  1. -

    The command "shorewall debug try -<directory>" now correctly traces the attempt.

    -
    2. -
  2. -

    The INCLUDE directive now works -properly in the zones file; previously, INCLUDE in that file was -ignored.

    -
    3. -
  3. -

    /etc/shorewall/routestopped records with an empty second column -are no longer ignored.

    +
  4. The command "shorewall debug try <directory>" now +correctly traces the attempt.
    5. +
  5. The INCLUDE directive now works properly in the zones file; +previously, INCLUDE in that file was ignored.
    6. +
  6. /etc/shorewall/routestopped records with an empty second column +are no longer ignored.
-

New Features:

+

New Features:
+

    -
  1. -

    The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may -now contain a list of addresses. If the list begins with "!' then the -rule will take effect only if the original destination address in the -connection request does not match any of the addresses listed.

    -
    2. +
  2. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may +now contain a list of addresses. If the list begins with "!' then +the rule will take effect only if the original destination address +in the connection request does not match any of the addresses +listed.
-

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

+

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables +1.2.8

The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems have been encountered with this set of software. The Shorewall version is 1.4.4b plus the accumulated -changes for 1.4.5.

+changes for 1.4.5.
+

6/8/2003 - Updated Samples

Thanks to Francesca Smith, the samples have been updated to Shorewall version 1.4.4.

5/29/2003 - Shorewall-1.4.4b

Groan -- This version corrects a problem whereby the --log-level -was not being set when logging via syslog. The most commonly reported -symptom was that Shorewall messages were being written to the console -even though console logging was correctly configured per FAQ 16.

+was not being set when logging via syslog. The most commonly +reported symptom was that Shorewall messages were being written to +the console even though console logging was correctly configured +per FAQ 16.
+

5/27/2003 - Shorewall-1.4.4a

-

The Fireparse --log-prefix fiasco continues. Tuomo Soini has -pointed out that the code in 1.4.4 restricts the length of short zone -names to 4 characters. I've produced version 1.4.4a that restores the -previous 5-character limit by conditionally omitting the log rule -number when the LOGFORMAT doesn't contain '%d'.

+The Fireparse --log-prefix fiasco continues. Tuomo Soini has +pointed out that the code in 1.4.4 restricts the length of short +zone names to 4 characters. I've produced version 1.4.4a that +restores the previous 5-character limit by conditionally omitting +the log rule number when the LOGFORMAT doesn't contain '%d'.

5/23/2003 - Shorewall-1.4.4

-

I apologize for the rapid-fire releases but since there is a -potential configuration change required to go from 1.4.3a to 1.4.4, I -decided to make it a full release rather than just a bug-fix release. +I apologize for the rapid-fire releases but since there is a +potential configuration change required to go from 1.4.3a to 1.4.4, +I decided to make it a full release rather than just a bug-fix +release.

-
-    Problems corrected:

-
None.
-

    New Features:

+    Problems corrected:
+
None.
+
+    New Features:
+
    -
  1. -

    A REDIRECT- rule target has been added. This target behaves for -REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter -nat table REDIRECT rule is added but not the companion filter table -ACCEPT rule.

    +
  2. A REDIRECT- rule target has been added. This target behaves for +REDIRECT in the same way as DNAT- does for DNAT in that the +Netfilter nat table REDIRECT rule is added but not the companion +filter table ACCEPT rule.
    +
    3. -
  3. -

    The LOGMARKER variable has been renamed LOGFORMAT and has been -changed to a 'printf' formatting template which accepts three arguments -(the chain name, logging rule number and the disposition). To use -LOGFORMAT with fireparse (http://www.fireparse.com), -set it as:
    +

  4. The LOGMARKER variable has been renamed LOGFORMAT and has been +changed to a 'printf' formatting template which accepts three +arguments (the chain name, logging rule number and the +disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it +as:
     
           LOGFORMAT="fp=%s:%d a=%s "
     
    CAUTION: /sbin/shorewall uses the leading part of the -LOGFORMAT string (up to but not including the first '%') to find log -messages in the 'show log', 'status' and 'hits' commands. This part -should not be omitted (the LOGFORMAT should not begin with "%") and the -leading part should be sufficiently unique for /sbin/shorewall to -identify Shorewall messages.

    +LOGFORMAT string (up to but not including the first '%') to find +log messages in the 'show log', 'status' and 'hits' commands. This +part should not be omitted (the LOGFORMAT should not begin with +"%") and the leading part should be sufficiently unique for +/sbin/shorewall to identify Shorewall messages.
    +
    5. -
  5. -

    When logging is specified on a DNAT[-] or REDIRECT[-] rule, the +

  6. When logging is specified on a DNAT[-] or REDIRECT[-] rule, the logging now takes place in the nat table rather than in the filter -table. This way, only those connections that actually undergo DNAT or -redirection will be logged.

    +table. This way, only those connections that actually undergo DNAT +or redirection will be logged.
-

5/20/2003 - Shorewall-1.4.3a

-

This version primarily corrects the documentation included in the -.tgz and in the .rpm. In addition:

+

5/20/2003 - Shorewall-1.4.3a
+

+This version primarily corrects the documentation included in the +.tgz and in the .rpm. In addition:
    -
  1. -

    (This change is in 1.4.3 but is not -documented) If you are running iptables 1.2.7a and kernel 2.4.20, then -Shorewall will return reject replies as follows:
    +

  2. (This change is in 1.4.3 but is not documented) If you are +running iptables 1.2.7a and kernel 2.4.20, then Shorewall will +return reject replies as follows:
       a) tcp - RST
       b) udp - ICMP port unreachable
       c) icmp - ICMP host unreachable
    @@ -7277,79 +6691,76 @@ Shorewall will return reject replies as follows:
    If you are running earlier software, Shorewall will follow it's traditional convention:
       a) tcp - RST
    -   b) Otherwise - ICMP port unreachable

    -
    3. -
  3. -

    UDP port 135 is now silently dropped in the common.def chain. +   b) Otherwise - ICMP port unreachable

    4. +
  4. UDP port 135 is now silently dropped in the common.def chain. Remember that this chain is traversed just before a DROP or REJECT -policy is enforced.

    +policy is enforced.
-

5/18/2003 - Shorewall 1.4.3

-

    Problems Corrected:

+

5/18/2003 - Shorewall 1.4.3
+

+    Problems Corrected:
+
    -
  1. -

    There were several cases where -Shorewall would fail to remove a temporary directory from /tmp. These -cases have been corrected.

    -
    2. -
  2. -

    The rules for allowing all traffic via the loopback interface -have been moved to before the rule that drops status=INVALID packets. -This insures that all loopback traffic is allowed even if Netfilter -connection tracking is confused.

    -
    3. +
  3. There were several cases where Shorewall would fail to remove a +temporary directory from /tmp. These cases have been +corrected.
    4. +
  4. The rules for allowing all traffic via the loopback interface +have been moved to before the rule that drops status=INVALID +packets. This insures that all loopback traffic is allowed even if +Netfilter connection tracking is confused.
-

    New Features:

+    New Features:
+
    -
  1. -

     IPV6-IPV4 (6to4) tunnels are -now supported in the /etc/shorewall/tunnels file.

    -
    2. -
  2. -

    You may now change the leading portion of the --log-prefix used -by Shorewall using the LOGMARKER variable in shorewall.conf. By -default, "Shorewall:" is used.

    +
  3.  IPV6-IPV4 (6to4) tunnels are now supported in the +/etc/shorewall/tunnels file.
    4. +
  4. You may now change the leading portion of the +--log-prefix used by Shorewall using the LOGMARKER variable in +shorewall.conf. By default, "Shorewall:" is used.
-

5/10/2003 - Shorewall Mirror in Asia

-

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!

+

5/10/2003 - Shorewall Mirror in Asia
+

+

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
+

5/8/2003 - Shorewall Mirror in Chile

-

Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago -Chile.

-

4/21/2003 - Samples updated for Shorewall version 1.4.2

+Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago +Chile. +

4/21/2003 - Samples updated for Shorewall version +1.4.2

Thanks to Francesca Smith, the sample configurations are now upgraded to Shorewall version 1.4.2.

-

4/9/2003 - Shorewall 1.4.2

-

    Problems Corrected:

+

4/9/2003 - Shorewall 1.4.2
+

+

    Problems Corrected:

+
+
    +
  1. TCP connection requests rejected out of the common +chain +are now properly rejected with TCP RST; previously, some of these +requests were rejected with an ICMP port-unreachable response.
    2. +
  2. 'traceroute -I' from behind the firewall previously timed out +on the first hop (e.g., to the firewall). This has been worked +around.
    3. +
+
+

    New Features:

    -
  1. -
    TCP connection requests -rejected out of the common chain are now properly rejected with -TCP RST; previously, some of these requests were rejected with an ICMP -port-unreachable response.
    +
  2. Where an entry in the/etc/shorewall/hosts file specifies a +particular host or network, Shorewall now creates an intermediate +chain for handling input from the related zone. This can +substantially reduce the number of rules traversed by connections +requests from such zones.
    +
    3. -
  3. -
    'traceroute -I' from behind the firewall previously -timed out on the first hop (e.g., to the firewall). This has been -worked around.
    -
    4. -
-

    New Features:

-
    -
  1. -

    Where an entry in the/etc/shorewall/hosts file specifies a -particular host or network, Shorewall now creates an intermediate chain -for handling input from the related zone. This can substantially reduce -the number of rules traversed by connections requests from such zones.

    -
    2. -
  2. -

    Any file may include an INCLUDE directive. An INCLUDE directive +

  3. Any file may include an INCLUDE directive. An INCLUDE directive consists of the word INCLUDE followed by a file name and causes the contents of the named file to be logically included into the file -containing the INCLUDE. File names given in an INCLUDE directive are -assumed to reside in /etc/shorewall or in an alternate configuration -directory if one has been specified for the command.
    +containing the INCLUDE. File names given in an INCLUDE directive +are assumed to reside in /etc/shorewall or in an alternate +configuration directory if one has been specified for the +command.
     
       Examples:
       shorewall/params.mgmt:
    @@ -7392,1349 +6803,1204 @@ net:$BACKUP_SERVERS  tcp    22
       INCLUDE rules.mgmt    
     
       # rules unique to this host here
    -   #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT -REMOVE
    +   #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO +NOT REMOVE
       ----- end rules -----
     
    INCLUDE's may be nested to a level of 3 -- further nested INCLUDE -directives are ignored with a warning message.

    +directives are ignored with a warning message.
    +
    4. -
  4. -

    Routing traffic from an interface back out that interface +

  5. Routing traffic from an interface back out that interface continues to be a problem. While I firmly believe that this should never happen, people continue to want to do it. To limit the damage -that such nonsense produces, I have added a new 'routeback' option in -/etc/shorewall/interfaces and /etc/shorewall/hosts. When used in -/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; in -other words, 'routeback' can't be used as an option for a multi-zone -interface. The 'routeback' option CAN be specified however on -individual group entries in /etc/shorewall/hosts.
    +that such nonsense produces, I have added a new 'routeback' option +in /etc/shorewall/interfaces and /etc/shorewall/hosts. When used in +/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; +in other words, 'routeback' can't be used as an option for a +multi-zone interface. The 'routeback' option CAN be specified +however on individual group entries in /etc/shorewall/hosts.
     
    -The 'routeback' option is similar to the old 'multi' option with two -exceptions:
    +The 'routeback' option is similar to the old 'multi' option with +two exceptions:
     
       a) The option pertains to a particular zone,interface,address tuple.
     
    -   b) The option only created infrastructure to pass traffic -from (zone,interface,address) tuples back to themselves (the 'multi' -option affected all (zone,interface,address) tuples associated with the -given 'interface').
    +   b) The option only created infrastructure to pass +traffic from (zone,interface,address) tuples back to themselves +(the 'multi' option affected all (zone,interface,address) tuples +associated with the given 'interface').
     
    See the 'Upgrade Issues' for -information about how this new option may affect your configuration.

    +information about how this new option may affect your +configuration.
-

3/24/2003 - Shorewall 1.4.1

-

This release follows up on 1.4.0. It corrects a problem introduced -in 1.4.0 and removes additional warts.
+

3/24/2003 - Shorewall 1.4.1

+ +

This release follows up on 1.4.0. It corrects a problem +introduced in 1.4.0 and removes additional warts.

-Problems Corrected:

+Problems Corrected:
+

    -
  1. -

    When Shorewall 1.4.0 is run under the ash shell (such as on +

  2. When Shorewall 1.4.0 is run under the ash shell (such as on Bering/LEAF), it can attempt to add ECN disabling rules even if the -/etc/shorewall/ecn file is empty. That problem has been corrected so -that ECN disabling rules are only added if there are entries in -/etc/shorewall/ecn.

    -
    3. +/etc/shorewall/ecn file is empty. That problem has been corrected +so that ECN disabling rules are only added if there are entries in +/etc/shorewall/ecn.
-

New Features:

+New Features:
Note: In the list that follows, the term group -refers to a particular network or subnetwork (which may be 0.0.0.0/0 -or it may be a host address) accessed through a particular interface. -Examples:
-
eth0:0.0.0.0/0
+refers to a particular network or subnetwork (which may be +0.0.0.0/0 or it may be a host address) accessed through a +particular interface. Examples:
+
eth0:0.0.0.0/0
eth2:192.168.1.0/24
-eth3:192.0.2.123
-
You can use the "shorewall check" command to -see the groups associated with each of your zones.
+eth3:192.0.2.123
+
+You can use the "shorewall check" command to see the groups +associated with each of your zones.
+
    -
  1. -

    Beginning with Shorewall 1.4.1, if a -zone Z comprises more than one group then if there is no explicit Z to -Z policy and there are no rules governing traffic from Z to Z then -Shorewall will permit all traffic between the groups in the zone.

    -
    2. -
  2. -

    Beginning with Shorewall 1.4.1, -Shorewall will never create rules to handle traffic from a group to -itself.

    -
    3. -
  3. -

    A NONE policy is introduced in 1.4.1. When a policy of NONE is -specified from Z1 to Z2:

    -
    4. +
  4. Beginning with Shorewall 1.4.1, if a zone Z comprises more than +one group then if there is no explicit Z to Z policy and +there are no rules governing traffic from Z to Z then Shorewall +will permit all traffic between the groups in the zone.
    5. +
  5. Beginning with Shorewall 1.4.1, Shorewall will never create +rules to handle traffic from a group to itself.
    6. +
  6. A NONE policy is introduced in 1.4.1. When a policy of NONE is +specified from Z1 to Z2:
-

See the upgrade issues for a -discussion of how these changes may affect your configuration.

-

3/17/2003 - Shorewall 1.4.0

-

Shorewall 1.4 represents the next step in the evolution of -Shorewall. The main thrust of the initial release is simply to remove -the cruft that has accumulated in Shorewall over time.
+See the upgrade issues for a +discussion of how these changes may affect your configuration. +

3/17/2003 - Shorewall 1.4.0

+Shorewall 1.4 represents the next step in the evolution of +Shorewall. The main thrust of the initial release is simply to +remove the cruft that has accumulated in Shorewall over time.

-IMPORTANT: -Shorewall 1.4.0 requires the iproute package ('ip' -utility).
+IMPORTANT: Shorewall 1.4.0 requires the iproute package +('ip' utility).

-Function from 1.3 that has been omitted from -this version include:

+Function from 1.3 that has been omitted from this version +include:
    -
  1. -

    The MERGE_HOSTS variable in shorewall.conf is no longer +

  2. The MERGE_HOSTS variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with -MERGE_HOSTS=Yes.

    +MERGE_HOSTS=Yes.
    +
    3. -
  3. -

    Interface names of the form <device>:<integer> in -/etc/shorewall/interfaces now generate an error.

    +
  4. Interface names of the form <device>:<integer> in +/etc/shorewall/interfaces now generate an error.
    +
    5. -
  5. -

    Shorewall 1.4 implements behavior consistent with -OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error at -startup as will specification of the 'noping' or 'filterping' interface -options.

    +
  6. Shorewall 1.4 implements behavior consistent with +OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error +at startup as will specification of the 'noping' or 'filterping' +interface options.
    +
    7. -
  7. -

    The 'routestopped' option in the /etc/shorewall/interfaces and -/etc/shorewall/hosts files is no longer supported and will generate an -error at startup if specified.

    +
  8. The 'routestopped' option in the /etc/shorewall/interfaces and +/etc/shorewall/hosts files is no longer supported and will generate +an error at startup if specified.
    +
    9. -
  9. -

    The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no -longer accepted.

    +
  10. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no +longer accepted.
    +
    11. -
  11. -

    The ALLOWRELATED variable in shorewall.conf is no longer +

  12. The ALLOWRELATED variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with -ALLOWRELATED=Yes.

    +ALLOWRELATED=Yes.
    +
    13. -
  13. -

    The icmp.def file has been removed.

    +
  14. The icmp.def file has been removed.
-

Changes for 1.4 include:

+Changes for 1.4 include:
    -
  1. -

    The /etc/shorewall/shorewall.conf file has been completely -reorganized into logical sections.

    +
  2. The /etc/shorewall/shorewall.conf file has been completely +reorganized into logical sections.
    +
    3. -
  3. -

    LOG is now a valid action for a rule (/etc/shorewall/rules).

    +
  4. LOG is now a valid action for a rule +(/etc/shorewall/rules).
    +
    5. -
  5. -

    The firewall script and version file are now installed in -/usr/share/shorewall.

    +
  6. The firewall script and version file are now installed in +/usr/share/shorewall.
    +
    7. -
  7. -

    Late arriving DNS replies are now silently dropped in the common -chain by default.

    +
  8. Late arriving DNS replies are now silently dropped in the +common chain by default.
    +
    9. -
  9. -

    In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 -no longer unconditionally accepts outbound ICMP packets. So if you want -to 'ping' from the firewall, you will need the appropriate rule or -policy.

    +
  10. In addition to behaving like OLD_PING_HANDLING=No, Shorewall +1.4 no longer unconditionally accepts outbound ICMP packets. So if +you want to 'ping' from the firewall, you will need the appropriate +rule or policy.
    +
    11. -
  11. -

    CONTINUE is now a valid action for a rule (/etc/shorewall/rules).

    +
  12. CONTINUE is now a valid action for a rule +(/etc/shorewall/rules).
    +
    13. -
  13. -

    802.11b devices with names of the form wlan<n> now support -the 'maclist' option.

    +
  14. 802.11b devices with names of the form wlan<n> now +support the 'maclist' option.
    +
    15. -
  15. -

    Explicit Congestion Notification (ECN - RFC 3168) may now be -turned off on a host or network basis using the new /etc/shorewall/ecn -file. To use this facility:
    +

  16. Explicit Congestion Notification (ECN - RFC 3168) may now be +turned off on a host or network basis using the new +/etc/shorewall/ecn file. To use this facility:

       a) You must be running kernel 2.4.20
       b) You must have applied the patch in
       http://www.shorewall/net/pub/shorewall/ecn/patch.
    -   c) You must have iptables 1.2.7a installed.

    +   c) You must have iptables 1.2.7a installed.
    +
    17. -
  17. -

    The /etc/shorewall/params file is now processed first so that -variables may be used in the /etc/shorewall/shorewall.conf file.

    +
  18. The /etc/shorewall/params file is now processed first so that +variables may be used in the /etc/shorewall/shorewall.conf +file.
    +
    19. -
  19. -

    Shorewall now gives a more helpful diagnostic when the -'ipchains' compatibility kernel module is loaded and a 'shorewall -start' command is issued.

    +
  20. Shorewall now gives a more helpful diagnostic when +the 'ipchains' compatibility kernel module is loaded and a +'shorewall start' command is issued.
    +
    21. -
  21. -

    The SHARED_DIR variable has been removed from shorewall.conf. -This variable was for use by package maintainers and was not documented -for general use.

    -
    22. -
  22. -

    Shorewall now ignores 'default' routes when detecting masq'd -networks.

    +
  23. The SHARED_DIR variable has been removed from shorewall.conf. +This variable was for use by package maintainers and was not +documented for general use.
    +
    24. +
  24. Shorewall now ignores 'default' routes when detecting masq'd +networks.

3/10/2003 - Shoreall 1.3.14a

A roleup of the following bug fixes and other updates:

2/8/2003 - Shoreawall 1.3.14

New features include

    -
  1. -

    An OLD_PING_HANDLING option has been added to shorewall.conf. -When set to Yes, Shorewall ping handling is as it has always been (see -http://www.shorewall.net/ping.html).
    +

  2. An OLD_PING_HANDLING option has been added to shorewall.conf. +When set to Yes, Shorewall ping handling is as it has always been +(see http://www.shorewall.net/ping.html).
    +
    +When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules +and policies just like any other connection request. The +FORWARDPING=Yes option in shorewall.conf and the 'noping' and +'filterping' options in /etc/shorewall/interfaces will all generate +an error.

    -When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and -policies just like any other connection request. The FORWARDPING=Yes -option in shorewall.conf and the 'noping' and 'filterping' options in -/etc/shorewall/interfaces will all generate an error.

    3. -
  3. -

    It is now possible to direct -Shorewall to create a "label" such as  "eth0:0" for IP addresses -that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This -is done by specifying the label instead of just the interface name:
    +

  4. It is now possible to direct Shorewall to create a "label" such +as  "eth0:0" for IP addresses that it creates under +ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by +specifying the label instead of just the interface name:
     
       a) In the INTERFACE column of /etc/shorewall/masq
       b) In the INTERFACE column of /etc/shorewall/nat
    - 

    + 
    5. +
  5. Support for OpenVPN Tunnels.
    +
    6. -
  6. -

    Support for OpenVPN Tunnels.

    +
  7. Support for VLAN devices with names of the form $DEV.$VID +(e.g., eth0.0)
    +
    8. -
  8. -

    Support for VLAN devices with names of the form $DEV.$VID (e.g., -eth0.0)

    -
    9. -
  9. -

    In /etc/shorewall/tcrules, the MARK value may be optionally +

  10. In /etc/shorewall/tcrules, the MARK value may be optionally followed by ":" and either 'F' or 'P' to designate that the marking -will occur in the FORWARD or PREROUTING chains respectively. If this -additional specification is omitted, the chain used to mark packets -will be determined by the setting of the MARK_IN_FORWARD_CHAIN option -in shorewall.conf.

    +will occur in the FORWARD or PREROUTING chains respectively. If +this additional specification is omitted, the chain used to mark +packets will be determined by the setting of the +MARK_IN_FORWARD_CHAIN option in shorewall.conf.
    +
    11. -
  11. -

    When an interface name is entered in the SUBNET column of the -/etc/shorewall/masq file, Shorewall previously masqueraded traffic from -only the first subnet defined on that interface. It did not masquerade -traffic from:
    +

  12. When an interface name is entered in the SUBNET column of the +/etc/shorewall/masq file, Shorewall previously masqueraded traffic +from only the first subnet defined on that interface. It did not +masquerade traffic from:
     
       a) The subnets associated with other addresses on the interface.
       b) Subnets accessed through local routers.
     
    -Beginning with Shorewall 1.3.14, if you enter an interface name in the -SUBNET column, shorewall will use the firewall's routing table to -construct the masquerading/SNAT rules.
    +Beginning with Shorewall 1.3.14, if you enter an interface name in +the SUBNET column, shorewall will use the firewall's routing table +to construct the masquerading/SNAT rules.
     
    Example 1 -- This is how it works in 1.3.14.
    -  

    - 
       [root@gateway test]# cat /etc/shorewall/masq

       #INTERFACE              SUBNET                  ADDRESS

       eth0                    eth2                    206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        
       [root@gateway test]# ip route show dev eth2

       192.168.1.0/24  scope link

       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254

        
       [root@gateway test]# shorewall start

       ...

       Masqueraded Subnets and Hosts:

           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176

           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176

       Processing /etc/shorewall/tos...
    -

     
    -When upgrading to Shorewall 1.3.14, if you have multiple local subnets -connected to an interface that is specified in the SUBNET column of an -/etc/shorewall/masq entry, your /etc/shorewall/masq file will need -changing. In most cases, you will simply be able to remove redundant -entries. In some cases though, you might want to change from using the -interface name to listing specific subnetworks if the change described -above will cause masquerading to occur on subnetworks that you don't -wish to masquerade.
    +  
    + 

       [root@gateway test]# cat /etc/shorewall/masq
    
+   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    eth2                    206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    + 
       [root@gateway test]# ip route show dev eth2
    
+   192.168.1.0/24  scope link
    
+   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
+
    + 
       [root@gateway test]# shorewall start
    
+   ...
    
+   Masqueraded Subnets and Hosts:
    
+       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
    
+       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
    
+   Processing /etc/shorewall/tos...
+
    + 
    +When upgrading to Shorewall 1.3.14, if you have multiple local +subnets connected to an interface that is specified in the SUBNET +column of an /etc/shorewall/masq entry, your /etc/shorewall/masq +file will need changing. In most cases, you will simply be able to +remove redundant entries. In some cases though, you might want to +change from using the interface name to listing specific +subnetworks if the change described above will cause masquerading +to occur on subnetworks that you don't wish to masquerade.
     
    Example 2 -- Suppose that your current config is as follows:
    -  

    - 
       [root@gateway test]# cat /etc/shorewall/masq

       #INTERFACE              SUBNET                  ADDRESS

       eth0                    eth2                    206.124.146.176

       eth0                    192.168.10.0/24         206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        
       [root@gateway test]# ip route show dev eth2

       192.168.1.0/24  scope link

       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254

       [root@gateway test]#
    -

     
    -   In this case, the second entry in /etc/shorewall/masq is -no longer required.
    +  
    + 

       [root@gateway test]# cat /etc/shorewall/masq
    
+   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    eth2                    206.124.146.176
    
+   eth0                    192.168.10.0/24         206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    + 
       [root@gateway test]# ip route show dev eth2
    
+   192.168.1.0/24  scope link
    
+   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
+   [root@gateway test]#
+
    + 
    +   In this case, the second entry in /etc/shorewall/masq +is no longer required.
     
    Example 3 -- What if your current configuration is like this?
    - 

    - 
       [root@gateway test]# cat /etc/shorewall/masq

       #INTERFACE              SUBNET                  ADDRESS

       eth0                    eth2                    206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        
       [root@gateway test]# ip route show dev eth2

       192.168.1.0/24  scope link

       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254

       [root@gateway test]#
    -

     
    -   In this case, you would want to change the entry in  -/etc/shorewall/masq to:

    - 
       #INTERFACE              SUBNET                  ADDRESS

       eth0                    192.168.1.0/24          206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + 
    + 
       [root@gateway test]# cat /etc/shorewall/masq
    
+   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    eth2                    206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    + 
       [root@gateway test]# ip route show dev eth2
    
+   192.168.1.0/24  scope link
    
+   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
+   [root@gateway test]#
+
    + 
    +   In this case, you would want to change the entry +in  /etc/shorewall/masq to:
    + 
       #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    192.168.1.0/24          206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+


2/5/2003 - Shorewall Support included in Webmin 1.060

Webmin version 1.060 now has Shorewall support included as -standard. See http://www.webmin.com.
+standard. See http://www.webmin.com.

-2/4/2003 -- Shorewall 1.3.14-RC1

-

Includes the Beta 2 content plus support for OpenVPN tunnels.

+2/4/2003 - Shorewall 1.3.14-RC1

+

Includes the Beta 2 content plus support for OpenVPN +tunnels.

1/28/2003 - Shorewall 1.3.14-Beta2

-

Includes the Beta 1 content plus restores VLAN device names of the -form $dev.$vid (e.g., eth0.1)

-

1/25/2003 - Shorewall 1.3.14-Beta1

-

The Beta includes the following changes:

+

Includes the Beta 1 content plus restores VLAN device names of +the form $dev.$vid (e.g., eth0.1)

+

1/25/2003 - Shorewall 1.3.14-Beta1
+

+

The Beta includes the following changes:
+

    -
  1. -

    An OLD_PING_HANDLING option has been added to shorewall.conf. -When set to Yes, Shorewall ping handling is as it has always been (see -http://www.shorewall.net/ping.html).
    +

  2. An OLD_PING_HANDLING option has been added to shorewall.conf. +When set to Yes, Shorewall ping handling is as it has always been +(see http://www.shorewall.net/ping.html).
    +
    +When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules +and policies just like any other connection request. The +FORWARDPING=Yes option in shorewall.conf and the 'noping' and +'filterping' options in /etc/shorewall/interfaces will all generate +an error.

    -When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and -policies just like any other connection request. The FORWARDPING=Yes -option in shorewall.conf and the 'noping' and 'filterping' options in -/etc/shorewall/interfaces will all generate an error.

    3. -
  3. -

    It is now possible to direct -Shorewall to create a "label" such as  "eth0:0" for IP addresses -that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This -is done by specifying the label instead of just the interface name:
    +

  4. It is now possible to direct Shorewall to create a "label" such +as  "eth0:0" for IP addresses that it creates under +ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by +specifying the label instead of just the interface name:
     
       a) In the INTERFACE column of /etc/shorewall/masq
       b) In the INTERFACE column of /etc/shorewall/nat
    - 

    -
    5. -
  5. -

    When an interface name is entered in the SUBNET column of the -/etc/shorewall/masq file, Shorewall previously masqueraded traffic from -only the first subnet defined on that interface. It did not masquerade -traffic from:
    + 

    6. +
  6. When an interface name is entered in the SUBNET column of the +/etc/shorewall/masq file, Shorewall previously masqueraded traffic +from only the first subnet defined on that interface. It did not +masquerade traffic from:
     
       a) The subnets associated with other addresses on the interface.
       b) Subnets accessed through local routers.
     
    -Beginning with Shorewall 1.3.14, if you enter an interface name in the -SUBNET column, shorewall will use the firewall's routing table to -construct the masquerading/SNAT rules.
    +Beginning with Shorewall 1.3.14, if you enter an interface name in +the SUBNET column, shorewall will use the firewall's routing table +to construct the masquerading/SNAT rules.
     
    Example 1 -- This is how it works in 1.3.14.
    -  

    - 
       [root@gateway test]# cat /etc/shorewall/masq

       #INTERFACE              SUBNET                  ADDRESS

       eth0                    eth2                    206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        
       [root@gateway test]# ip route show dev eth2

       192.168.1.0/24  scope link

       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254

        
       [root@gateway test]# shorewall start

       ...

       Masqueraded Subnets and Hosts:

           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176

           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176

       Processing /etc/shorewall/tos...
    -

     
    -When upgrading to Shorewall 1.3.14, if you have multiple local subnets -connected to an interface that is specified in the SUBNET column of an -/etc/shorewall/masq entry, your /etc/shorewall/masq file will need -changing. In most cases, you will simply be able to remove redundant -entries. In some cases though, you might want to change from using the -interface name to listing specific subnetworks if the change described -above will cause masquerading to occur on subnetworks that you don't -wish to masquerade.
    +  
    + 

       [root@gateway test]# cat /etc/shorewall/masq
    
+   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    eth2                    206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    + 
       [root@gateway test]# ip route show dev eth2
    
+   192.168.1.0/24  scope link
    
+   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
+
    + 
       [root@gateway test]# shorewall start
    
+   ...
    
+   Masqueraded Subnets and Hosts:
    
+       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
    
+       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
    
+   Processing /etc/shorewall/tos...
+
    + 
    +When upgrading to Shorewall 1.3.14, if you have multiple local +subnets connected to an interface that is specified in the SUBNET +column of an /etc/shorewall/masq entry, your /etc/shorewall/masq +file will need changing. In most cases, you will simply be able to +remove redundant entries. In some cases though, you might want to +change from using the interface name to listing specific +subnetworks if the change described above will cause masquerading +to occur on subnetworks that you don't wish to masquerade.
     
    Example 2 -- Suppose that your current config is as follows:
    -  

    - 
       [root@gateway test]# cat /etc/shorewall/masq

       #INTERFACE              SUBNET                  ADDRESS

       eth0                    eth2                    206.124.146.176

       eth0                    192.168.10.0/24         206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        
       [root@gateway test]# ip route show dev eth2

       192.168.1.0/24  scope link

       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254

       [root@gateway test]#
    -

     
    -   In this case, the second entry in /etc/shorewall/masq is -no longer required.
    +  
    + 

       [root@gateway test]# cat /etc/shorewall/masq
    
+   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    eth2                    206.124.146.176
    
+   eth0                    192.168.10.0/24         206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    + 
       [root@gateway test]# ip route show dev eth2
    
+   192.168.1.0/24  scope link
    
+   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
+   [root@gateway test]#
+
    + 
    +   In this case, the second entry in /etc/shorewall/masq +is no longer required.
     
    Example 3 -- What if your current configuration is like this?
    - 

    - 
       [root@gateway test]# cat /etc/shorewall/masq

       #INTERFACE              SUBNET                  ADDRESS

       eth0                    eth2                    206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        
       [root@gateway test]# ip route show dev eth2

       192.168.1.0/24  scope link

       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254

       [root@gateway test]#
    -

     
    -   In this case, you would want to change the entry in  -/etc/shorewall/masq to:

    - 
       #INTERFACE              SUBNET                  ADDRESS

       eth0                    192.168.1.0/24          206.124.146.176

       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    7. + 
    + 
       [root@gateway test]# cat /etc/shorewall/masq
    
+   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    eth2                    206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    + 
       [root@gateway test]# ip route show dev eth2
    
+   192.168.1.0/24  scope link
    
+   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
+   [root@gateway test]#
+
    + 
    +   In this case, you would want to change the entry +in  /etc/shorewall/masq to:
    + 
       #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    192.168.1.0/24          206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    +
-

1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format

-

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 -documenation. the PDF may be downloaded from

-

    -1/18/2003 - Shorewall 1.3.13 Documentation in PDF +Format

+

Juraj Ontkanin has produced a PDF containing the Shorewall +1.3.13 documenation. the PDF may be downloaded from

+    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-    -http://slovakia.shorewall.net/pub/shorewall/pdf/ -

-

1/17/2003 - shorewall.net has MOVED 

+    http://slovakia.shorewall.net/pub/shorewall/pdf/ +

1/17/2003 - shorewall.net has MOVED 

Thanks to the generosity of Alex Martin and Rett -Consulting, www.shorewall.net and ftp.shorewall.net are now -hosted on a system in Bellevue, Washington. A big thanks to Alex for -making this happen.

-

1/13/2003 - Shorewall 1.3.13

-

Just includes a few things that I had on the burner:

+ href="http://www.rettc.com">Rett Consulting, www.shorewall.net and +ftp.shorewall.net are now hosted on a system in Bellevue, +Washington. A big thanks to Alex for making this happen.
+

+

1/13/2003 - Shorewall 1.3.13
+

+

Just includes a few things that I had on the burner:
+

    -
  1. -

    A new 'DNAT-' action has been added for entries in the +

  2. A new 'DNAT-' action has been added for entries in the /etc/shorewall/rules file. DNAT- is intended for advanced users who wish to minimize the number of rules that connection requests must traverse.

    -A Shorewall DNAT rule actually generates two iptables rules: a header -rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter' -table. A DNAT- rule only generates the first of these rules. This is -handy when you have several DNAT rules that would generate the same -ACCEPT rule.
    +A Shorewall DNAT rule actually generates two iptables rules: a +header rewriting rule in the 'nat' table and an ACCEPT rule in the +'filter' table. A DNAT- rule only generates the first of these +rules. This is handy when you have several DNAT rules that would +generate the same ACCEPT rule.

       Here are three rules from my previous rules file:

    -        DNAT   net  -dmz:206.124.146.177 tcp smtp - 206.124.146.178
    -        DNAT   net  -dmz:206.124.146.177 tcp smtp - 206.124.146.179
    +        DNAT   +net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
    +        DNAT   +net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
            ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...

    -   These three rules ended up generating _three_ copies of
    +   These three rules ended up generating _three_ copies +of

             ACCEPT net  dmz:206.124.146.177 tcp smtp

    -   By writing the rules this way, I end up with only one copy -of the ACCEPT rule.
    +   By writing the rules this way, I end up with only one +copy of the ACCEPT rule.

            DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
            DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
            ACCEPT net  -dmz:206.124.146.177 tcp www,smtp,ftp,....

    +dmz:206.124.146.177 tcp www,smtp,ftp,....
    +
    3. -
  3. -

    The 'shorewall check' command now prints out the applicable -policy between each pair of zones.

    +
  4. The 'shorewall check' command now prints out the applicable +policy between each pair of zones.
    +
    5. -
  5. -

    A new CLEAR_TC option has been added to shorewall.conf. If this -option is set to 'No' then Shorewall won't clear the current traffic -control rules during [re]start. This setting is intended for use by -people that prefer to configure traffic shaping when the network -interfaces come up rather than when the firewall is started. If that is -what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not -supply an /etc/shorewall/tcstart file. That way, your traffic shaping -rules can still use the 'fwmark' classifier based on packet marking -defined in /etc/shorewall/tcrules.

    +
  6. A new CLEAR_TC option has been added to shorewall.conf. If this +option is set to 'No' then Shorewall won't clear the current +traffic control rules during [re]start. This setting is intended +for use by people that prefer to configure traffic shaping when the +network interfaces come up rather than when the firewall is +started. If that is what you want to do, set TC_ENABLED=Yes and +CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That +way, your traffic shaping rules can still use the 'fwmark' +classifier based on packet marking defined in +/etc/shorewall/tcrules.
    +
    7. -
  7. -

    A new SHARED_DIR variable has been added that allows +

  8. A new SHARED_DIR variable has been added that allows distribution packagers to easily move the shared directory (default -/usr/lib/shorewall). Users should never have a need to change the value -of this shorewall.conf setting.

    +/usr/lib/shorewall). Users should never have a need to change the +value of this shorewall.conf setting.
-

1/6/2003 - BURNOUT

+

1/6/2003 - BURNOUT +

Until further notice, I will not be involved in either Shorewall Development or Shorewall Support

-

-Tom Eastep

+

-Tom Eastep
+

12/30/2002 - Shorewall Documentation in PDF Format

-

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 -documenation. the PDF may be downloaded from

-

    -Juraj Ontkanin has produced a PDF containing the Shorewall +1.3.12 documenation. the PDF may be downloaded from

+

    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-    -http://slovakia.shorewall.net/pub/shorewall/pdf/

+    http://slovakia.shorewall.net/pub/shorewall/pdf/
+

12/27/2002 - Shorewall 1.3.12 Released

-

Features include:

+

Features include:
+

    -
  1. -

    "shorewall refresh" now reloads the -traffic shaping rules (tcrules and tcstart).

    -
    2. -
  2. -

    "shorewall debug [re]start" now -turns off debugging after an error occurs. This places the point of the -failure near the end of the trace rather than up in the middle of it.

    -
    3. -
  3. -

    "shorewall [re]start" has been -speeded up by more than 40% with my configuration. Your milage may -vary.

    -
    4. -
  4. -

    A "shorewall show classifiers" -command has been added which shows the current packet classification -filters. The output from this command is also added as a separate page -in "shorewall monitor"

    -
    5. -
  5. -

    ULOG (must be all caps) is now -accepted as a valid syslog level and causes the subject packets to be -logged using the ULOG target rather than the LOG target. This allows -you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) -and log all Shorewall messages to a -separate log file.

    -
    6. -
  6. -

    If you are running a kernel that has -a FORWARD chain in the mangle table ("shorewall show mangle" will show -you the chains in the mangle table), you can set -MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. -This allows for marking input packets based on their destination even -when you are using Masquerading or SNAT.

    -
    7. -
  7. -

    I have cluttered up the -/etc/shorewall directory with empty 'init', 'start', 'stop' and -'stopped' files. If you already have a file with one of these names, -don't worry -- the upgrade process won't overwrite your file.

    -
    8. -
  8. -

    I have added a new RFC1918_LOG_LEVEL variable to "shorewall refresh" now reloads the traffic shaping rules +(tcrules and tcstart).

    9. +
  9. "shorewall debug [re]start" now turns off debugging after an +error occurs. This places the point of the failure near the end of +the trace rather than up in the middle of it.
    10. +
  10. "shorewall [re]start" has been speeded up by more than 40% with +my configuration. Your milage may vary.
    11. +
  11. A "shorewall show classifiers" command has been added which +shows the current packet classification filters. The output from +this command is also added as a separate page in "shorewall +monitor"
    12. +
  12. ULOG (must be all caps) is now accepted as a valid syslog level +and causes the subject packets to be logged using the ULOG target +rather than the LOG target. This allows you to run ulogd (available +from http://www.gnumonks.org/projects/ulogd) +and log all Shorewall messages to +a separate log file.
    13. +
  13. If you are running a kernel that has a FORWARD chain in the +mangle table ("shorewall show mangle" will show you the chains in +the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for +marking input packets based on their destination even when you are +using Masquerading or SNAT.
    14. +
  14. I have cluttered up the /etc/shorewall directory with empty +'init', 'start', 'stop' and 'stopped' files. If you already have a +file with one of these names, don't worry -- the upgrade process +won't overwrite your file.
    15. +
  15. I have added a new RFC1918_LOG_LEVEL variable to shorewall.conf. This variable -specifies the syslog level at which packets are logged as a result of -entries in the /etc/shorewall/rfc1918 file. Previously, these packets -were always logged at the 'info' level.

    +specifies the syslog level at which packets are logged as a result +of entries in the /etc/shorewall/rfc1918 file. Previously, these +packets were always logged at the 'info' level.
-

12/20/2002 - Shorewall 1.3.12 Beta 3

-

This version corrects a problem with Blacklist logging. In Beta 2, +

12/20/2002 - Shorewall 1.3.12 Beta 3
+

+This version corrects a problem with Blacklist logging. In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall -would fail to start and "shorewall refresh" would also -fail.

+would fail to start and "shorewall refresh" would also fail.

12/20/2002 - Shorewall 1.3.12 Beta 2

-

The first public Beta version of Shorewall 1.3.12 is now available -(Beta 1 was made available only to a limited audience).

-

Features include:

+

The first public Beta version of Shorewall 1.3.12 is now +available (Beta 1 was made available only to a limited +audience).
+

+Features include:
    -
  1. -

    "shorewall refresh" now reloads the -traffic shaping rules (tcrules and tcstart).

    -
    2. -
  2. -

    "shorewall debug [re]start" now -turns off debugging after an error occurs. This places the point of the -failure near the end of the trace rather than up in the middle of it.

    -
    3. -
  3. -

    "shorewall [re]start" has been -speeded up by more than 40% with my configuration. Your milage may -vary.

    -
    4. -
  4. -

    A "shorewall show classifiers" -command has been added which shows the current packet classification -filters. The output from this command is also added as a separate page -in "shorewall monitor"

    -
    5. -
  5. -

    ULOG (must be all caps) is now -accepted as a valid syslog level and causes the subject packets to be -logged using the ULOG target rather than the LOG target. This allows -you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) -and log all Shorewall messages to a -separate log file.

    -
    6. -
  6. -

    If you are running a kernel that has -a FORWARD chain in the mangle table ("shorewall show mangle" will show -you the chains in the mangle table), you can set -MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for marking -input packets based on their destination even when you are using -Masquerading or SNAT.

    -
    7. -
  7. -

    I have cluttered up the /etc/shorewall directory with empty -'init', 'start', 'stop' and 'stopped' files. If you already have a file -with one of these names, don't worry -- the upgrade process won't -overwrite your file.

    -
    8. +
  8. "shorewall refresh" now reloads the traffic shaping rules +(tcrules and tcstart).
    9. +
  9. "shorewall debug [re]start" now turns off debugging after an +error occurs. This places the point of the failure near the end of +the trace rather than up in the middle of it.
    10. +
  10. "shorewall [re]start" has been speeded up by more than 40% with +my configuration. Your milage may vary.
    11. +
  11. A "shorewall show classifiers" command has been added which +shows the current packet classification filters. The output from +this command is also added as a separate page in "shorewall +monitor"
    12. +
  12. ULOG (must be all caps) is now accepted as a valid syslog level +and causes the subject packets to be logged using the ULOG target +rather than the LOG target. This allows you to run ulogd (available +from http://www.gnumonks.org/projects/ulogd) +and log all Shorewall messages to +a separate log file.
    13. +
  13. If you are running a kernel that has a FORWARD chain in the +mangle table ("shorewall show mangle" will show you the chains in +the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in +shorewall.conf. This allows for marking input packets based on +their destination even when you are using Masquerading or +SNAT.
    14. +
  14. I have cluttered up the /etc/shorewall directory with empty +'init', 'start', 'stop' and 'stopped' files. If you already have a +file with one of these names, don't worry -- the upgrade process +won't overwrite your file.
-

You may download the Beta from:

+You may download the Beta from:
http://www.shorewall.net/pub/shorewall/Beta
- ftp://ftp.shorewall.net/pub/shorewall/Beta
+ ftp://ftp.shorewall.net/pub/shorewall/Beta
+

12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux + href="http://www.mandrakesoft.com">Powered by Mandrake Linux

-

Shorewall is at the center of MandrakeSoft's recently-announced -Multi -Network Firewall (MNF) product. Here is the +Multi Network Firewall (MNF) product. Here is the press -release.

+release.

12/7/2002 - Shorewall Support for Mandrake 9.0

-

Two months and 3 days after I ordered Mandrake 9.0, it was finally -delivered. I have installed 9.0 on one of my systems and I am now in -a position to support Shorewall users who run Mandrake 9.0.

-

12/6/2002 - Debian 1.3.11a Packages Available

-

Apt-get sources listed at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+

Two months and 3 days after I ordered Mandrake 9.0, it was +finally delivered. I have installed 9.0 on one of my systems and I +am now in a position to support Shorewall users who run Mandrake +9.0.

+

12/6/2002 - Debian 1.3.11a Packages Available
+

+

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

12/3/2002 - Shorewall 1.3.11a

-

This is a bug-fix roll up which includes Roger Aich's fix for DNAT -with excluded subnets (e.g., "DNAT foo!bar ..."). Current +

This is a bug-fix roll up which includes Roger Aich's fix for +DNAT with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users who don't need rules of this type need not upgrade to 1.3.11.

11/24/2002 - Shorewall 1.3.11

In this version:

11/14/2002 - Shorewall Documentation in PDF Format

-

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 -documenation. the PDF may be downloaded from

-

    -Juraj Ontkanin has produced a PDF containing the Shorewall +1.3.10 documenation. the PDF may be downloaded from

+

    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-    -http://slovakia.shorewall.net/pub/shorewall/pdf/

-

11/09/2002 - Shorewall is Back at SourceForge

-

The main Shorewall 1.3 web site is now back at SourceForge at -http://shorewall.sf.net.

+    http://slovakia.shorewall.net/pub/shorewall/pdf/
+

+

11/09/2002 - Shorewall is Back at SourceForge

+

The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
+

11/09/2002 - Shorewall 1.3.10

In this version:

-

10/24/2002 - Shorewall is now in Gentoo Linux

-

Alexandru Hartmann reports that his Shorewall package is now a -part of the Gentoo Linux -distribution. Thanks Alex!

-

10/23/2002 - Shorewall 1.3.10 Beta 1

-

In this version:

+

10/24/2002 - Shorewall is now in Gentoo Linux
+

+Alexandru Hartmann reports that his Shorewall package is now a part +of the Gentoo Linux +distribution. Thanks Alex!
+

10/23/2002 - Shorewall 1.3.10 Beta 1

+In this version:
-

You may download the Beta from:

+You may download the Beta from:
-

10/10/2002 -  Debian 1.3.9b Packages Available

-

Apt-get sources listed at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+

10/10/2002 -  Debian 1.3.9b Packages Available
+

+

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

10/9/2002 - Shorewall 1.3.9b

-

This release rolls up fixes to the installer and to the firewall -script.

+This release rolls up fixes to the installer and to the firewall +script.

10/6/2002 - Shorewall.net now running on RH8.0

-The -firewall and server here at shorewall.net are now running RedHat -release 8.0.
+The firewall and server here at shorewall.net are now running +RedHat release 8.0.

9/30/2002 - Shorewall 1.3.9a

-

Roles up the fix for broken tunnels.

+Roles up the fix for broken tunnels.

9/30/2002 - TUNNELS Broken in 1.3.9!!!

-

There is an updated firewall script at -ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall --- copy that file to /usr/lib/shorewall/firewall.

+-- copy that file to /usr/lib/shorewall/firewall.

9/28/2002 - Shorewall 1.3.9

-

In this version:

+

In this version:
+

9/23/2002 - Full Shorewall Site/Mailing List Archive Search -Capability Restored

-

Brown Paper BagA -couple of recent configuration changes at www.shorewall.net broke the -Search facility:

-
    -
  1. -
    Mailing List Archive Search -was not available.
    -
    2. -
  2. -
    The Site Search index was -incomplete
    -
    3. -
  3. -
    Only one page of matches was presented.
    -
    4. -
-

Hopefully these problems are now corrected.

+Capability Restored
+

+Brown Paper Bag A couple of recent configuration changes +at www.shorewall.net broke the Search facility:
+
+
    +
  1. Mailing List Archive Search was not available.
    2. +
  2. The Site Search index was incomplete
    3. +
  3. Only one page of matches was presented.
    4. +
+
+Hopefully these problems are now corrected.

9/23/2002 - Full Shorewall Site/Mailing List Archive Search -Capability Restored

-

A couple of recent configuration changes at www.shorewall.net had -the negative effect of breaking the Search facility:

+Capability Restored
+

+A couple of recent configuration changes at www.shorewall.net had +the negative effect of breaking the Search facility:
    -
  1. -

    Mailing List Archive Search was not -available.

    -
    2. -
  2. -

    The Site Search index was incomplete -

    -
    3. -
  3. -

    Only one page of matches was presented.

    -
    4. +
  4. Mailing List Archive Search was not available.
    5. +
  5. The Site Search index was incomplete
    6. +
  6. Only one page of matches was presented.
-

Hopefully these problems are now corrected.

-

9/18/2002 -  Debian 1.3.8 Packages Available

-

Apt-get sources listed at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+Hopefully these problems are now corrected.
+

9/18/2002 -  Debian 1.3.8 Packages Available
+

+

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

9/16/2002 - Shorewall 1.3.8

-

In this version:

+

In this version:
+

9/11/2002 - Debian 1.3.7c Packages Available

-

Apt-get sources listed at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

9/2/2002 - Shorewall 1.3.7c

-

This is a role up of a fix for "DNAT" rules where the -source zone is $FW (fw).

+

This is a role up of a fix for "DNAT" rules where the source +zone is $FW (fw).

8/31/2002 - I'm not available

I'm currently on vacation  -- please respect my need for a couple of weeks free of Shorewall problem reports.

-Tom

8/26/2002 - Shorewall 1.3.7b

-

This is a role up of the "shorewall refresh" bug fix and -the change which reverses the order of "dhcp" and -"norfc1918" checking.

+

This is a role up of the "shorewall refresh" bug fix and the +change which reverses the order of "dhcp" and "norfc1918" +checking.

8/26/2002 - French FTP Mirror is Operational

-

ftp://france.shorewall.net/pub/mirrors/shorewall +

ftp://france.shorewall.net/pub/mirrors/shorewall is now available.

8/25/2002 - Shorewall Mirror in France

-

Thanks to a Shorewall user in Paris, the Shorewall web site is now -mirrored at http://france.shorewall.net.

-

8/25/2002 - Shorewall 1.3.7a Debian Packages Available

+

Thanks to a Shorewall user in Paris, the Shorewall web site is +now mirrored at http://france.shorewall.net.

+

8/25/2002 - Shorewall 1.3.7a Debian Packages +Available

Lorenzo Martignoni reports that the packages for version 1.3.7a are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author -- Shorewall 1.3.7a releasedBrown Paper Bag Graphic

+ alt="Brown Paper Bag Graphic" align="middle" border="0" height="80" + width="50">

1.3.7a corrects problems occurring in rules file processing when starting Shorewall 1.3.7.

8/22/2002 - Shorewall 1.3.7 Released 8/13/2002

Features in this release include:

I would like to thank John Distler for his valuable input -regarding TCP SYN and ICMP treatment in Shorewall. That input has led -to marked improvement in Shorewall in the last two releases.

-

8/13/2002 - Documentation in the CVS +regarding TCP SYN and ICMP treatment in Shorewall. That input has +led to marked improvement in Shorewall in the last two +releases.

+

8/13/2002 - Documentation in the CVS Repository

The Shorewall-docs project now contains just the HTML and image files - the Frontpage files have been removed.

8/7/2002 - STABLE branch added to CVS + target="_top" href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS Repository

-

This branch will only be updated after I release a new version of -Shorewall so you can always update from this branch to get the latest -stable tree.

+

This branch will only be updated after I release a new version +of Shorewall so you can always update from this branch to get the +latest stable tree.

8/7/2002 - Upgrade Issues -section added to the Errata Page

+section added to the Errata Page

Now there is one place to go to look for issues involved with upgrading to recent versions of Shorewall.

8/7/2002 - Shorewall 1.3.6

-

This is primarily a bug-fix rollup with a couple of new features:

+

This is primarily a bug-fix rollup with a couple of new +features:

7/30/2002 - Shorewall 1.3.5b Released

This interim release:

7/29/2002 - New Shorewall Setup Guide Available

-

The first draft of this guide is available at -http://www.shorewall.net/shorewall_setup_guide.htm. -The guide is intended for use by people who are setting up Shorewall -to manage multiple public IP addresses and by people who want to -learn more about Shorewall than is described in the single-address -guides. Feedback on the new guide is welcome.

+

The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm. +The guide is intended for use by people who are setting up +Shorewall to manage multiple public IP addresses and by people who +want to learn more about Shorewall than is described in the +single-address guides. Feedback on the new guide is welcome.

7/28/2002 - Shorewall 1.3.5 Debian Package Available

Lorenzo Martignoni reports that the packages are version 1.3.5a -and are available at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+and are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

7/27/2002 - Shorewall 1.3.5a Released

-

This interim release restores correct handling of REDIRECT rules.

+

This interim release restores correct handling of REDIRECT +rules.

7/26/2002 - Shorewall 1.3.5 Released

-

This will be the last Shorewall release for a while. I'm going to -be focusing on rewriting a lot of the documentation.

-

  In this version:

+

This will be the last Shorewall release for a while. I'm going +to be focusing on rewriting a lot of the documentation.

+

  In this version:

7/16/2002 - New Mirror in Argentina

-

Thanks to Arturo "Buanzo" Busleiman, there is now a -Shorewall mirror in Argentina. Thanks Buanzo!!!

+

Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall +mirror in Argentina. Thanks Buanzo!!!

7/16/2002 - Shorewall 1.3.4 Released

In this version:

7/8/2002 - Shorewall 1.3.3 Debian Package Available

-

Lorenzo Marignoni reports that the packages are available at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+

Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

7/6/2002 - Shorewall 1.3.3 Released

In this version:

6/25/2002 - Samples Updated for 1.3.2

The comments in the sample configuration files have been updated to reflect new features introduced in Shorewall 1.3.2.

6/25/2002 - Shorewall 1.3.1 Debian Package Available

-

Lorenzo Marignoni reports that the package is available at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+

Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

6/19/2002 - Documentation Available in PDF Format

Thanks to Mike Martinez, the Shorewall Documentation is now -available for download in Adobe -PDF format.

+available for download in Adobe PDF format.

6/16/2002 - Shorewall 1.3.2 Released

In this version:

6/6/2002 - Why CVS Web access is Password Protected

Last weekend, I installed the CVS Web package to provide brower-based access to the Shorewall CVS repository. Since then, I -have had several instances where my server was almost unusable due to -the high load generated by website copying tools like HTTrack and -WebStripper. These mindless tools:

+have had several instances where my server was almost unusable due +to the high load generated by website copying tools like HTTrack +and WebStripper. These mindless tools:

These tools/weapons are particularly damaging when combined with -CVS Web because they doggedly follow every link in the cgi-generated -HTML resulting in 1000s of executions of the cvsweb.cgi script. -Yesterday, I spend several hours implementing measures to block these -tools but unfortunately, these measures resulted in my server OOM-ing -under even moderate load.

-

Until I have the time to understand the cause of the OOM (or until -I buy more RAM if that is what is required), CVS Web access will -remain Password Protected.

+CVS Web because they doggedly follow every link in the +cgi-generated HTML resulting in 1000s of executions of the +cvsweb.cgi script. Yesterday, I spend several hours implementing +measures to block these tools but unfortunately, these measures +resulted in my server OOM-ing under even moderate load.

+

Until I have the time to understand the cause of the OOM (or +until I buy more RAM if that is what is required), CVS Web access +will remain Password Protected.

6/5/2002 - Shorewall 1.3.1 Debian Package Available

-

Lorenzo Marignoni reports that the package is available at -http://security.dsi.unimi.it/~lorenzo/debian.html.

+

Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

6/2/2002 - Samples Corrected

-

The 1.3.0 samples configurations had several serious problems that -prevented DNS and SSH from working properly. These problems have been -corrected in the 1.3.1 +

The 1.3.0 samples configurations had several serious problems +that prevented DNS and SSH from working properly. These problems +have been corrected in the 1.3.1 samples.

6/1/2002 - Shorewall 1.3.1 Released

Hot on the heels of 1.3.0, this release:

5/29/2002 - Shorewall 1.3.0 Released

In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 includes:

5/23/2002 - Shorewall 1.3 RC1 Available

In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) incorporates the following:

5/19/2002 - Shorewall 1.3 Beta 2 Available

In addition to the changes in Beta 1, this release which carries the designation 1.2.91 adds:

5/17/2002 - Shorewall 1.3 Beta 1 Available

Beta 1 carries the version designation 1.2.90 and implements the following features:

5/4/2002 - Shorewall 1.2.13 is Available

In this version:

4/30/2002 - Shorewall Debian News

-

Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the -Debian +

Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both +the Debian Testing Branch and the Debian Unstable Branch.

4/20/2002 - Shorewall 1.2.12 is Available

4/17/2002 - Shorewall Debian News

Lorenzo Marignoni reports that:

Thanks, Lorenzo!

4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE

-

Thanks to Stefan Mohr, -there is now a Shorewall 1.2.11 SuSE -RPM available.

+

Thanks to Stefan +Mohr, there is now a Shorewall 1.2.11 +SuSE RPM available.

4/13/2002 - Shorewall 1.2.11 Available

In this version:

4/13/2002 - Hamburg Mirror now has FTP

-

Stefan now has an FTP mirror at -ftp://germany.shorewall.net/pub/shorewall.  +

Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  Thanks Stefan!

4/12/2002 - New Mirror in Hamburg

-

Thanks to Stefan Mohr, -there is now a mirror of the Shorewall website at -http://germany.shorewall.net.

-

4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available

+

Thanks to Stefan +Mohr, there is now a mirror of the Shorewall website at http://germany.shorewall.net.

+

4/10/2002 - Shorewall QuickStart Guide Version 1.1 +Available

Version 1.1 of the -QuickStart Guide is now available. Thanks to those who have read -version 1.0 and offered their suggestions. Corrections have also been -made to the sample scripts.

-

4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available

+QuickStart Guide is now available. Thanks to those who have +read version 1.0 and offered their suggestions. Corrections have +also been made to the sample scripts.

+

4/9/2002 - Shorewall QuickStart Guide Version 1.0 +Available

Version 1.0 of the QuickStart Guide is now available. This Guide and its accompanying sample configurations are expected to provide a @@ -8749,903 +8015,616 @@ for the samples and I am recommending that they not be used in new Shorewall installations.

4/2/2002 - Updated Log Parser

John Lodge has provided -an updated version of his CGI-based -log parser with corrected date handling.

+an updated version of his CGI-based +log parser with corrected +date handling.

3/30/2002 - Shorewall Website Search Improvements

The quick search on the home page now excludes the mailing list -archives. The Extended Search +archives. The Extended Search allows excluding the archives or restricting the search to just the archives. An archive search form is also available on the mailing -list information page.

-

3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)

+ href="http://lists.shorewall.net/mailing_list.htm">mailing list +information page.

+

3/28/2002 - Debian Shorewall News (From Lorenzo +Martignoni)

3/25/2002 - Log Parser Available

-

John Lodge has provided a -CGI-based log parser for +

John Lodge has provided +a CGI-based log parser for Shorewall. Thanks John.

3/20/2002 - Shorewall 1.2.10 Released

In this version:

3/11/2002 - Shorewall 1.2.9 Released

In this version:

3/1/2002 - 1.2.8 Debian Package is Available

See http://security.dsi.unimi.it/~lorenzo/debian.html

2/25/2002 - New Two-interface Sample

I've enhanced the two interface sample to allow access from the -firewall to servers in the local zone - -http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

+firewall to servers in the local zone - +http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

2/23/2002 - Shorewall 1.2.8 Released

Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects problems associated with the lock file used to prevent multiple state-changing operations from occuring simultaneously. My -apologies for any inconvenience my carelessness may have caused.

+apologies for any inconvenience my carelessness may have +caused.

2/22/2002 - Shorewall 1.2.7 Released

In this version:

2/18/2002 - 1.2.6 Debian Package is Available

See http://security.dsi.unimi.it/~lorenzo/debian.html

2/8/2002 - Shorewall 1.2.6 Released

In this version:

2/4/2002 - Shorewall 1.2.5 Debian Package Available

see http://security.dsi.unimi.it/~lorenzo/debian.html

2/1/2002 - Shorewall 1.2.5 Released

-

Due to installation problems with Shorewall 1.2.4, I have released -Shorewall 1.2.5. Sorry for the rapid-fire development.

+

Due to installation problems with Shorewall 1.2.4, I have +released Shorewall 1.2.5. Sorry for the rapid-fire development.

In version 1.2.5:

1/28/2002 - Shorewall 1.2.4 Released

-

1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see -http://security.dsi.unimi.it/~lorenzo/debian.html

+

1/27/2002 - Shorewall 1.2.3 Debian Package Available -- +see http://security.dsi.unimi.it/~lorenzo/debian.html

1/20/2002 - Corrected firewall script available 

-

Corrects a problem with BLACKLIST_LOGLEVEL. See the +

Corrects a problem with BLACKLIST_LOGLEVEL. See the errata for details.

1/19/2002 - Shorewall 1.2.3 Released

-

This is a minor feature and bugfix release. The single new feature -is:

+

This is a minor feature and bugfix release. The single new +feature is:

The following problems were corrected:

1/18/2002 - Shorewall 1.2.2 packaged with new LEAF -release

+ href="http://leaf.sourceforge.net">LEAF release

Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF -distribution that includes Shorewall 1.2.2. See -http://leaf.sourceforge.net/devel/jnilo +distribution that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo for details.

-

1/11/2002 - Debian Package (.deb) Now Available - Thanks to -Lorenzo Martignoni, -a 1.2.2 Shorewall Debian package is now available. There is a link to -Lorenzo's site from the Shorewall +

1/11/2002 - Debian Package (.deb) Now Available - Thanks +to Lorenzo +Martignoni, a 1.2.2 Shorewall Debian package is now available. +There is a link to Lorenzo's site from the Shorewall download page.

1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This -corrected version restores the "shorewall status" -command to health.

+ href="/pub/shorewall/errata/1.2.2/shorewall">This corrected +version restores the "shorewall status" command to health.

1/8/2002 - Shorewall 1.2.2 Released

In version 1.2.2

1/5/2002 - New Parameterized Samples (version -1.2.0) released. These are minor updates to the -previously-released samples. There are two new rules added:

+ target="_blank">version 1.2.0) released. These are minor +updates +to the previously-released samples. There are two new rules +added:

See the README file for upgrade instructions.

1/1/2002 - Shorewall Mailing List Moving

The Shorewall mailing list hosted at Sourceforge -is moving to Shorewall.net. If you are a current subscriber to the -list at Sourceforge, please see -these instructions. If you would like to subscribe to the new -list, visit -http://www.shorewall.net/mailman/listinfo/shorewall-users.

+ href="http://sourceforge.net">Sourceforge is moving to +Shorewall.net. If you are a current subscriber to the list at +Sourceforge, please see +these instructions. +If you would like to subscribe to the new list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.

12/31/2001 - Shorewall 1.2.1 Released

In version 1.2.1:

12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing 1.2 on 12/21/2001

Version 1.2 contains the following new features:

For the next month or so, I will continue to provide corrections to version 1.1.18 as necessary so that current version 1.1.x users -will not be forced into a quick upgrade to 1.2.0 just to have access -to bug fixes.

-

For those of you who have installed one of the Beta RPMS, you will -need to use the "--oldpackage" option when upgrading to +will not be forced into a quick upgrade to 1.2.0 just to have +access to bug fixes.

+

For those of you who have installed one of the Beta RPMS, you +will need to use the "--oldpackage" option when upgrading to 1.2.0:

-
rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm
+
+

rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

+

12/19/2001 - Thanks to Steve -Cowles, there is now a Shorewall mirror in Texas. This web -site is mirrored at http://www.infohiiway.com/shorewall -and the ftp site is at -ftp://ftp.infohiiway.com/pub/mirrors/shorewall. - 

+Cowles, there is now a +Shorewall mirror in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall +and the ftp site is +at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. + 

11/30/2001 - A new set of the parameterized Sample Configurations has been released. In this version:

-

11/20/2001 - The current version of Shorewall is 1.1.18. 

+

11/20/2001 - The current version of Shorewall is +1.1.18. 

In this version:

11/19/2001 - Thanks to Juraj -Ontkanin, there is now a Shorewall mirror in the Slovak Republic. -The website is now mirrored at http://www.nrg.sk/mirror/shorewall -and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

+Ontkanin, there is now a +Shorewall mirror in the Slovak Republic. The website is now +mirrored at http://www.nrg.sk/mirror/shorewall +and the FTP site is +mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. There are three sample configurations:

-

Samples may be downloaded from -ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 +

Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 . See the README file for instructions.

-

11/1/2001 - The current version of Shorewall is 1.1.17.  -I intend this to be the last of the 1.1 Shorewall releases.

+

11/1/2001 - The current version of Shorewall is +1.1.17.  I intend this to be the last of the 1.1 Shorewall +releases.

In this version:

-

10/22/2001 - The current version of Shorewall is 1.1.16. In -this version:

+

10/22/2001 - The current version of Shorewall is 1.1.16. +In this version:

-

10/15/2001 - The current version of Shorewall is 1.1.15. In -this version:

+

10/15/2001 - The current version of Shorewall is 1.1.15. +In this version:

-

10/4/2001 - The current version of Shorewall is 1.1.14. In -this version

+

10/4/2001 - The current version of Shorewall is 1.1.14. +In this version

-

9/12/2001 - The current version of Shorewall is 1.1.13. In -this version

+

9/12/2001 - The current version of Shorewall is 1.1.13. +In this version

-

8/28/2001 - The current version of Shorewall is 1.1.12. In -this version

+

8/28/2001 - The current version of Shorewall is 1.1.12. +In this version

-

7/28/2001 - The current version of Shorewall is 1.1.11. In -this version

+

7/28/2001 - The current version of Shorewall is 1.1.11. +In this version

7/6/2001 - The current version of Shorewall is 1.1.10. In this version

6/23/2001 - The current version of Shorewall is 1.1.9. In this version

6/18/2001 - The current version of Shorewall is 1.1.8. In this version

6/2/2001 - The current version of Shorewall is 1.1.7. In this version

5/25/2001 - The current version of Shorewall is 1.1.6. In this version

5/20/2001 - The current version of Shorewall is 1.1.5. In this version

5/10/2001 - The current version of Shorewall is 1.1.4. In this version

4/28/2001 - The current version of Shorewall is 1.1.3. In this version

4/12/2001 - The current version of Shorewall is 1.1.2. In this version

4/8/2001 - Shorewall is now affiliated with the Leaf -Project Leaf Logo

+ href="http://leaf.sourceforge.net">Leaf Project Leaf Logo

4/5/2001 - The current version of Shorewall is 1.1.1. In this version:

-

3/25/2001 - The current version of Shorewall is 1.1.0. In this -version:

+

3/25/2001 - The current version of Shorewall is 1.1.0. In +this version:

3/19/2001 - The current version of Shorewall is 1.0.4. This version:

-

3/13/2001 - The current version of Shorewall is 1.0.3. This is -a bug-fix release with no new features.

+

3/13/2001 - The current version of Shorewall is 1.0.3. This +is a bug-fix release with no new features.

3/8/2001 - The current version of Shorewall is 1.0.2. It -supports an additional "gw" (gateway) zone for tunnels and -it supports IPSEC tunnels with end-points on the firewall. There is +supports an additional "gw" (gateway) zone for tunnels and it +supports IPSEC tunnels with end-points on the firewall. There is also a .lrp available now.

diff --git a/Shorewall-Website/shorewall_index.htm b/Shorewall-Website/shorewall_index.htm index 7d06a8e50..872bce8ee 100644 --- a/Shorewall-Website/shorewall_index.htm +++ b/Shorewall-Website/shorewall_index.htm @@ -10,8 +10,11 @@

Shorewall 2.x

-

Tom Eastep
-
+

NEWS: +Tom Eastep ends his involvement with Shorewall.

+

NEWS: Tom Eastep
+
The information on this site applies only to 2.x releases of Shorewall. For older versions: