From 69f5334d77018a4033258eeb09d9a3f36f1f39e7 Mon Sep 17 00:00:00 2001 From: judas_iscariote Date: Fri, 23 Sep 2005 00:56:29 +0000 Subject: [PATCH] news file will only contain actual information, old news moved to oldnews.html git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2729 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-Website/News.htm | 10857 +----------------------------- Shorewall-Website/oldnews.html | 10992 +++++++++++++++++++++++++++++++ 2 files changed, 10996 insertions(+), 10853 deletions(-) create mode 100644 Shorewall-Website/oldnews.html diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index d984ca258..17fbb5227 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -154,7 +154,7 @@
To use 'loose', you also need to add two entries in /etc/shorewall/masq:
- + 
 #INTERFACE           SUBNET          ADDRESS

@@ -162,7 +162,7 @@
    $IF_ISP2             $IP_ISP1        $IP_ISP2
where:
- + 
         $IF_ISP1        is the interface to ISP 1.

         $IF_ISP2        is the interface to ISP 2.

@@ -185,7 +185,7 @@
       interfaces eth0, eth1 and eth2.

       
     
-     
+
     

 
     
07/17/2005
@@ -942,10856 +942,7 @@
       /bin/bash installed.

       
     
-    05/20/2005  Shorewall CVS
-    Repository has Moved to Sourceforge

-    

-    The CVS repository may now be accessed at http://sourceforge.net/cvs/?group_id=22587.

-
-    

-    05/20/2005 Shorewall 2.2.5

-    

-    This will be my last 2.2 release. It contains a couple
-    of small bug fixes that I hadn't yet released.

-    

-    -Tom

-    

-    Problems Corrected:

-
-    
    
-      
  1. Previously, if PKTTYPE=No in shorewall.conf then pkttype
-      match would still be used if the kernel supported it.
    2. 
-
-      
  2. A typo in the 'tunnel' script has been corrected (Thanks
-      to Patrik Varmecký).
    3. 
-
-      
  3. A warning is now generated if an invalid short zone name
-      is used in /etc/shorewall/zones.
    
-      
    4. 
-    

-    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:
    
-      
    
-             Error: No appropriate
-      chain for 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>
    2. 
-
-      
  2. 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>
    3. 
-    

-    New Features:

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

-
-    

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

-      

-
-      

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

-        

-                       
-        insert_forward_rules = yes

-                       
-        prerouting_chain_name = UPnP

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

-        

-                    
-        allowoutUPnP      
-        fw      loc

-        

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

-        

-                    
-        allowinUPnP       
-        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 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 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.
    
-      
    
-      
    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 /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=""
    
-      
    
-      
    3. 
-
-      
  3. 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 ADDRESSES column of /etc/shorewall/masq or in the
-      DEST column of /etc/shorewall/rules).
    
-      
    
-      If you use normal SNAT then multiple connections from a given
-      local host to hosts on the internet can be assigned different
-      source IP addresses. This confuses some applications that use
-      multiple connections. To correct this problem, prefix the
-      list of address ranges in the ADDRESS column with "SAME:"
    
-      
    
-               
-      Example:   SAME:206.124.146.176-206.124.146.180
    
-      
    
-      If you want each internal system to use the same IP address
-      from the list regardless of which internet host it is talking
-      to then prefix the ranges with "SAME:nodst:".
    
-      
    
-               
-      Example:  
-      SAME:nodst:206.124.146.176-206.124.146.180
    
-      
    
-      Note that it is not possible to map port numbers when using
-      SAME.
    
-      
    
-      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.
    
-      
    
-      
    4. 
-
-      
  4. A "shorewall show capabilities" command has been added to
-      report the capabilities of your kernel and iptables.
    
-      
    
-         Example:
    
-      
    
-            gateway:~# shorewall show
-      capabilities
    
-            Loading
-      /usr/share/shorewall/functions...
    
-            Processing
-      /etc/shorewall/params ...
    
-            Processing
-      /etc/shorewall/shorewall.conf...
    
-            Loading Modules...
    
-            Shorewall has detected the
-      following iptables/netfilter capabilities:
    
-                  
-      NAT: Available
    
-                  
-      Packet Mangling: Available
    
-                  
-      Multi-port Match: Available
    
-                  
-      Extended Multi-port Match: Available
    
-                  
-      Connection Tracking Match: Available
    
-                  
-      Packet Type Match: Not available
    
-                  
-      Policy Match: Available
    
-                  
-      Physdev Match: Available
    
-                  
-      IP range Match: Available
    
-                  
-      Recent Match: Available
    
-                  
-      Owner Match: Available
    
-            gateway:~#
    
-      
    
-      
    5. 
-
-      
  5. 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.
    
-      
    
-      
    6. 
-
-      
  6. 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:
    
-      
    
-      Example:
    
-      
    
-             
-      /etc/shorewall/rules:
    
-      
    
-                     
-      AllowFTP   
-      $FTP_CLIENTS        fw
    
-      
    
-              When FTP_CLIENTS
-      is set to 'none', the above rule is ignored.  Otherwise,
-      the rule is evaluated and generates Netfilter rules.
    
-      
    
-      
    7. 
-
-      
  7. The installer now detects that it is running on a
-      Slackware system and adjusts the DEST and INIT variables
-      accordingly.
    
-      
    8. 
-    

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

-    

-
-    
    
-      
  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 kernel lacked advanced routing support
-      (CONFIG_IP_ADVANCED_ROUTER),  then no routing
-      information was displayed.
    3. 
-    

-    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 /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'.
    
-      
    
-      Beginning with Shorewall version 2.2.3,
-      /etc/shorewall/routestopped will be processed TWICE during
-      'shorewall start' and during 'shorewall restart'. It will be
-      processed early in the command execution to add rules
-      allowing new connections while the command is running and it
-      will be processed again when the command is complete to
-      remove the rules 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.
    3. 
-
-      
  3. 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 'maclist' file lookup and thus reduce the
-      overhead associated with MAC Verification.
    
-      
    
-      When a new connection arrives from a 'maclist' interface, the
-      packet passes through then list of entries for that interface
-      in /etc/shorewall/maclist. If there is a match then the
-      source IP address is added to the 'Recent' set for that
-      interface. Subsequent connection attempts from that IP
-      address occuring within $MACLIST_TTL seconds will be accepted
-      without having to scan all of the entries. After $MACLIST_TTL
-      from the first accepted connection request from an IP
-      address, the next connection request from that IP address
-      will be 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.
    4. 
-
-      
  4. 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.
    
-      
    5. 
-    

-    03/31/2005 Shorewall
-    2.0.17

-    

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

-    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. 
-
-      
  2. 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.
    3. 
-
-      
  3. 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.
    4. 
-
-      
  4. The port numbers for UDP and TCP were previously reversed
-      in the /usr/share/shorewall/action.AllowPCA file.
    5. 
-
-      
  5. Previously, the 'install.sh' script did not update the
-      /usr/share/shorewall/action.* files.
    6. 
-
-      
  6. 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.
    
-      
    7. 
-    

-    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.
    
-      
    
-      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.
    5. 
-
-      
  5. 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
    
-      
    
-      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
    
-      
    
-      Setting RFC1918_STRICT=Yes in shorewall.conf will cause such
-      traffic to be logged and dropped since while the packet's
-      source matches the RETURN rule, the packet's destination
-      matches the 'logdrop' rule.
    
-      
    
-      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.
    
-      
    6. 
-    

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

-    

-
-    
    
-      
  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.
    
-      
    
-         Example:
    
-      
    
-                 
-      rejNotSyn:ULOG     
-      all    
-      all            
-      tcp
    
-      
    
-         produces the log message:
    
-      
    
-                 
-      Feb 12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...
    
-      
    
-         rather than
    
-      
    
-                 
-      Feb 12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...
    
-      
    
-      
    4. 
-
-      
  4. The comments regarding built-in actions in
-      /usr/share/shorewall/actions.std have been corrected.
    5. 
-
-      
  5. The /etc/shorewall/policy file in the LRP package was
-      missing the 'all->all' policy.
    
-      
    6. 
-    

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

-    

-    02/01/2005 Shorewall
-    2.0.16

-    

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

-
-    
02/01/2005 Shorewall
-    2.2.0

-    

-    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
-      additional options.
    
-      
    
-      Normally MASQUERADE/SNAT rules are evaluated after one-to-one
-      NAT rules defined in the /etc/shorewall/nat file. If you
-      preceed the interface name with a plus sign ("+") then the
-      rule will be evaluated before one-to-one NAT.
    
-      
    
-      Examples:
    
-      
    
-      +eth0
    
-      +eth1:192.0.2.32/27
    
-      
    
-      Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for
-      an entry by following the interface name by ":" but no
-      digit.
    
-      
    
-      Examples:
    
-      
    
-      eth0:
    
-      eth1::192.0.2.32/27
    
-      +eth3:
    
-      
    
-      
    3. 
-
-      
  3. 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.
    4. 
-
-      
  4. 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.
    5. 
-
-      
  5. 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:
    6. 
-
-      
  6. 
-        
      
-          
    • 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 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).
      
-          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!
      
-          
      
-          
      • 
-        
    
-      
    7. 
-    

-
-    

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

-      

-      /etc/shorewall/rules:

-         

-      acton:info: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:
    2. 
-
-      
  2. 
-        
      
-          
    • 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.
      
-          
      
-          
      • 
-        
    
-      
    3. 
-
-      
  3. 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:
    4. 
-
-      
  4. 
-        
      
-          
    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
      
-          
      
-          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
      
-          
      
-          /etc/shorewall/interfaces:
      
-          
      
-           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
      
-          
      
-          /etc/shorewall/interfaces:
      
-          
      
-           net   
-          eth0    ...
      
-          
      
-          /etc/shorewall/hosts:
      
-          
      
-           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
-            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
      
-            
      
-            /etc/shorewall/interfaces:
      
-            
      
-             net   
-            eth0    ...
      
-             loc   
-            eth1    ...
      
-            
      
-            /etc/shorewall/hosts:
      
-            
      
-             vpn   
-            eth0:0.0.0.0/0    ipsec,...
-          
      3. 
-        
    
-      
    5. 
-    

-
-    

-      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 available options are:

-    

-
-    

-      
    
-        
  • reqid[!]=<number> where <number> is
-        specified using setkey(8) using the 'unique:<number>'
-        option for the SPD level.
    • 
-
-        
  • spi[!]=<number> where <number> is the SPI
-        of the SA. Since different SAs are used to encrypt and
-        decrypt traffic, this option should only be listed in the
-        IN OPTIONS and OUT OPTIONS columns.
    • 
-
-        
  • proto[!]=ah|esp|ipcomp
    • 
-
-        
  • mss=<number> (sets the MSS value in TCP SYN
-        packets and is not related to policy matching)
    • 
-
-        
  • mode[!]=transport|tunnel
    • 
-
-        
  • tunnel-src[!]=<address>[/<mask>] (only
-        available with mode=tunnel)
    • 
-
-        
  • tunnel-dst[!]=<address>[/<mask>] (only
-        available with mode=tunnel). Because tunnel source and
-        destination are dependent on the direction of the traffic,
-        these options should only appear in the IN OPTIONS and OUT
-        OPTIONS columns.
    • 
-
-        
  • strict  (if specified, packets must match all
-        policies; policies are delimited by 'next').
    • 
-
-        
  • next    (only available with
-        strict)
    • 
-      

-    

-
-    

-      Examples:

-      

-      #ZONE   
-      IPSEC  OPTIONS       
-               
-      IN         
-      OUT

-      #       
-      ONLY           
-                
-           OPTIONS    
-      OPTIONS

-      vpn     
-      Yes    mode=tunnel,proto=esp   
-      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.

-    

-
-    
    
-      
  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 commands where -c was previously allowed now
-      permit you to specify a configuration directory after the
-      command:
    
-      
    
-            shorewall check   [
-      <configuration-directory> ]
    
-            shorewall restart [
-      <configuration-directory> ]
    
-            shorewall start   [
-      <configuration-directory> ]
    
-      
    
-      
    4. 
-
-      
  4. 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 port ranges ( < 512, 512-1023, and
-      > 1023). You may now specify an explicit range of source
-      ports to be used by following the address or address range
-      (if any) in the ADDRESS column with ":" and a port range in
-      the format <low-port>-<high-port>. You must
-      specify either "tcp" or "udp" in the PROTO column.
    
-      
    
-      Examples 1 -- MASQUERADE with tcp source ports 4000-5000:
    
-      
    
-          
-      #INTERFACE SUBNET         
-      ADDRESS        PROTO
    
-          
-      eth0       192.168.1.0/24 
-      :4000-5000     tcp
    
-      
    
-      Example 2 -- SNAT with udp source ports 7000-8000:
    
-      
    
-          #INTERFACE SUBNET   
-            ADDRESS   
-                  
-      PROTO
    
-         
-      eth0      
-      10.0.0.0/8     
-      192.0.2.44:7000-8000    udp
    
-      
    
-      
    5. 
-
-      
  5. 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.
    6. 
-
-      
  6. Shorewall now verifies that your kernel and iptables have
-      physdev match support if BRIDGING=Yes in shorewall.conf.
    7. 
-
-      
  7. 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.
    8. 
-
-      
  8. 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/     
-      SOURCE      
-      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.
    9. 
-
-      
  9. 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".
    10. 
-
-      
  10. 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".
    11. 
-
-      
  11. 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 specify a log tag will
-      substitute the tag for the chain name in the log prefix.
    
-      
    
-      Example -- file
-      /etc/shorewall/action.thisisaverylogactionname:
    
-      
    
-          Rule:
    
-      
    
-               DROP:info:ftp   
-      0.0.0.0/0    0.0.0.0/0   
-      tcp        21
    
-         
    
-          Log prefix with LOGTAGONLY=No:
    
-      
    
-               Shorewall:thisisaverylongacti
    
-
-      
    
-          Log prefix with LOGTAGONLY=Yes:
    
-      
    
-               Shorewall:ftp:DROP
    
-      
    
-      
    12. 
-
-      
  12. 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.
    13. 
-
-      
  13. 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)
    
-      
    
-      
    14. 
-
-      
  14. 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.
    15. 
-
-      
  15. 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 /etc/shorewall/shorewall.conf by
-      allowing that option to have a numeric value as well as the
-      values "Yes" and "No".
    
-      
    
-      Example:
    
-      
    
-          CLAMPMSS=1400
    
-      
    
-      
    16. 
-
-      
  16. 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":
    
-      
    
-             /etc/shorewall/rules
    
-            
-      /etc/shorewall/tcrules
    
-            
-      /etc/shorewall/accounting
    
-      
    
-      When the PROTO or PROTOCOL column contains "ipp2p" then the
-      DEST PORT(S) or PORT(S) column may contain a recognized ipp2p
-      option; for a list of the options and their meaning, at a
-      root prompt:
    
-      
    
-          iptables -m ipp2p --help
    
-      
    
-      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").
    17. 
-
-      
  17. Shorewall now has support for the CONNMARK target from
-      iptables. See the /etc/shorewall/tcrules file for
-      details.
    18. 
-
-      
  18. 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.
    
-      
    
-          - The table name is used as the chain name
-      in the log prefix.
    
-          - The chain name is used as the target in
-      the log prefix.
    
-      
    
-      Example: Using the default LOGFORMAT, the log prefix for
-      logging from the nat table's PREROUTING chain is:
    
-      
    
-           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 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.
    
-      
    
-      
    19. 
-
-      
  19. 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.
    20. 
-
-      
  20. The AllowNNTP action now also allows NNTP over SSL/TLS
-      (NNTPS).
    21. 
-
-      
  21. For consistency, the CLIENT PORT(S) column in the tcrules
-      file has been renamed SOURCE PORT(S).
    22. 
-
-      
  22. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
-      now shown in the output of "shorewall status".
    23. 
-
-      
  23. 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.
    24. 
-
-      
  24. 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 #
    
-      
    
-      
    25. 
-
-      
  25. Variable expansion may now be used with the INCLUDE
-      directive.
    
-      
    
-          Example:
    
-      
    
-          /etc/shorewall/params
    
-      
    
-              FILE=/etc/foo/bar
    
-      
    
-              Any other config
-      file:
    
-      
    
-              INCLUDE $FILE
    
-      
    
-      
    26. 
-
-      
  26. The output of "shorewall status" now includes the results
-      of "ip -stat link ls". This helps diagnose performance
-      problems caused by link errors.
    27. 
-
-      
  27. 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.
    28. 
-
-      
  28. 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
    
-
-      
    
-      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
    
-
-      
    
-      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.
    
-      
    
-      
    29. 
-
-      
  29. 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
    
-      
    
-          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
    
-        
    
-      
    30. 
-
-      
  30. 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 1194
    
-          
-      openvpn:3344       
-      net    1.2.3.4    # UDP on port
-      3344
    
-          
-      openvpn:tcp:4455    net   
-      1.2.3.4    # TCP on port 4455
    
-      
    
-      
    31. 
-
-      
  31. 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:
    32. 
-    

-
-    

-      
    
-        
  • Only one instance of the script may be used at a
-        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.
    • 
-      

-    

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

-
-    
01/17/2005 - Shorewall
-    2.2.0 RC5

-    

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

-    New Features:

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

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

-
-    
    
-      
  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:
    
-       
    
-            Bad argument `DROP'
    
-            Try `iptables -h' or 'iptables
-      --help' for more information.
    
-      
    3. 
-    

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

-    Problems Corrected.

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

-    01/03/2005 - Shorewall 2.0.14

-    

-    New Features:

-
-    
    
-      
  1. 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.
    
-      
    2. 
-    

-    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. The TYPE column for an IPIP tunnel should contain
-      "ipip" rather than "ip".
    
-      
    4. 
-    

-    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/

-
-    

-    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/

-
-    

-    Thanks, Simon!

-    

-    12/30/2004 - Shorewall 2.2.0 RC3

-    

-    Problems Corrected:

-
-    
    
-      
  1. The following error message could appear during
-      "shorewall stop" or "shorewall clear":
    
-                                                                                                                                                                                                                      
    
-
-                   
-      local: lo:: bad variable name
    
-      
    
-      
    2. 
-
-      
  2. The rate limiting example in /etc/shorewall/rules has
-      been changed to use the RATE LIMIT column.
    3. 
-
-      
  3. 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.
    4. 
-
-      
  4. A misleading typo in /etc/shorewall/tunnels has been
-      corrected.
    
-      
    5. 
-    

-     
-
-    


-    

-
-    
12/24/2004 - Shorewall
-    2.2.0 RC2

-    

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

-    12/19/2004 - Shorewall 2.2.0 RC1

-    

-    Problems Corrected:

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

-    New Features:

-
-    
    
-      
  1. 
-        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
-
    
-      
    2. 
-
-      
  2. 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:
    
-      
    
-          - Only one instance of the script may be
-      used at a 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.
    
-      
    3. 
-    

-    12/11/2004 - Shorewall 2.2.0 Beta 8

-    

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

-    New Features:

-
-    
    
-      
  1. 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
    
-      
    
-      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
    
-      
    
-      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.
    
-      
    
-      
    2. 
-
-      
  2. 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
    
-      
    
-      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
    
-        
    
-      
    3. 
-    

-    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:
    
-       
    
-                
-      shorewall add
-      <interface>[:<port>]:<address>
-      <zone>
    
-                
-      shorewall delete
-      <interface>[:<port>]:<address>
-      <zone>
    
-       
    
-         Examples:
    
-       
    
-                
-      shorewall add br0:eth2:192.168.1.3 OK
    
-                
-      shorewall delete br0:eth2:192.168.1.3 OK
    
-      
    
-      
    2. 
-
-      
  2. 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
-      at the end of the script.
    
-      
    
-      To accomplish this change, the "restore base" file
-      (/var/lib/shorewall/restore-base) has been split into two
-      files:
    
-       
    
-      /var/lib/shorewall/restore-base -- commands to be executed
-      before Netfilter the configuration is restored.
    
-       
    
-      /var/lib/shorewall/restore-tail -- commands to be executed
-      after the Netfilter configuration is restored.
    
-      
    
-      
    3. 
-
-      
  3. 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.
    4. 
-
-      
  4. 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.
    5. 
-    

-    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).
    
-       
    
-          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 #
    
-      
    
-      
    2. 
-
-      
  2. Variable expansion may now be used with the INCLUDE
-      directive.
    
-       
    
-          Example:
    
-       
    
-             
-      /etc/shorewall/params
    
-       
    
-                 
-      FILE=/etc/foo/bar
    
-       
    
-              Any other config
-      file:
    
-       
    
-                 
-      INCLUDE $FILE
    
-      
    
-      
    3. 
-
-      
  3. The output of "shorewall status" now includes the results
-      of "ip -stat link ls". This helps diagnose performance
-      problems caused by link errors.
    4. 
-
-      
  4. 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.
    
-      
    5. 
-    

-    12/02/2004 - Shorewall 2.0.13

-    

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

-    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:
    
-       
    
-            shorewall add
-      <interface>[:<bridge port>][:<address>]
-      <zone>
    
-            shorewall delete
-      <interface>[:<bridge port>][:<address>]
-      <zone>
    
-       
    
-      Examples:
    
-       
    
-            shorewall add
-      br0:eth2:192.168.1.3 OK
    
-            shorewall delete
-      br0:eth2:192.168.1.3 OK
    
-      
    
-      
    3. 
-
-      
  3. 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
-      at the end of the script.
    
-       
    
-      To accomplish this change, the "restore base" file
-      (/var/lib/shorewall/restore-base) has been split into two
-      files:
    
-       
    
-         /var/lib/shorewall/restore-base -- commands to
-      be executed before the Netfilter configuration is
-      restored.
    
-       
    
-         /var/lib/shorewall/restore-tail -- commands to
-      be executed after the Netfilter configuration is
-      restored.
    
-      
    
-      
    4. 
-
-      
  4. 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.
    5. 
-    

-    New Features:

-
-    
    
-      
  1. Variable expansion may now be used with the INCLUDE
-      directive.
    
-       
    
-      Example:
    
-       
    
-             
-      /etc/shorewall/params
    
-       
    
-                 
-      FILE=/etc/foo/bar
    
-       
    
-              Any other config
-      file:
    
-       
    
-                 
-      INCLUDE $FILE
    
-      
    2. 
-    

-    11/26/2004 - Shorewall 2.2.0 Beta 6

-    

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

-    

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

-    11/26/2004 - Shorewall 2.2.0 Beta 5

-    

-    Problems corrected:

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

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

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

-    New Features:

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

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

-    New Features:

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

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

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

-    11/02/2004 - Shorewall 2.2.0 Beta 2

-    

-    Problems Corrected:

-
-    
    
-      
  1. The "shorewall check" command results in the (harmless)
-      error message:
    
-       
    
-             
-      /usr/share/shorewall/firewall: line 2753:
    
-                
-      check_dupliate_zones: command not found
    
-      
    
-      
    2. 
-
-      
  2. The AllowNTP standard action now allows outgoing
-      responses to broadcasts.
    3. 
-
-      
  3. 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.
    4. 
-    

-    New Features:

-
-    
    
-      
  1. 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.
    
-      
    2. 
-    

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

-    New Features:

-
-    
    
-      
  1. The "shorewall status" command has been enhanced to
-      include the values of key /proc settings:
    
-      
    
-      Example from a two-interface firewall:
    
-      
    
-      /proc
    
-      
    
-         /proc/sys/net/ipv4/ip_forward = 1
    
-         /proc/sys/net/ipv4/conf/all/proxy_arp = 0
    
-         /proc/sys/net/ipv4/conf/all/arp_filter = 0
    
-         /proc/sys/net/ipv4/conf/all/rp_filter = 0
    
-         /proc/sys/net/ipv4/conf/default/proxy_arp =
-      0
    
-         /proc/sys/net/ipv4/conf/default/arp_filter =
-      0
    
-         /proc/sys/net/ipv4/conf/default/rp_filter =
-      0
    
-         /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
    
-         /proc/sys/net/ipv4/conf/eth0/arp_filter = 0
    
-         /proc/sys/net/ipv4/conf/eth0/rp_filter = 0
    
-         /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0
    
-         /proc/sys/net/ipv4/conf/eth1/arp_filter = 0
    
-         /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
    
-      
    2. 
-    

-    

-    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

-
-    

-
-    
The features available in this release and the migration
-    considerations are covered in the 
-    release 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. 
-    

-
-    
9/23/2004 - Shorewall 2.0.9

-    

-    Problems Corrected:

-    

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

-    New Features:

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

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

-
-    
    
-      
  1. 
-        
    Entries in the USER/GROUP column of an action file (made
-        from action.template) may be ignored or cause odd
-        errors.
    
-      
    2. 
-    

-
-    
7/29/2004 - Shorewall 2.0.7

-    

-    Problems Corrected:

-
-    
    
-      
  1. 
-        
    The PKTTYPE option
-        introduced in version 2.0.6 is now used when generating
-        rules to REJECT packets. Broadcast packets are silently
-        dropped rather than being rejected with an ICMP (which is a
-        protocol violation) and users whose kernels have broken
-        packet type match support are likely to see messages
-        reporting this violation. Setting PKTTYPE=No should cause
-        these messages to cease.
    
-      
    2. 
-
-      
  2. 
-        
    Multiple interfaces with the
-        'blacklist' option no longer result in an error message at
-        startup.
    
-      
    3. 
-
-      
  3. 
-        
    The following has been added to
-        /etc/shorewall/bogons:
    
-        
    
-               0.0.0.0  
-        RETURN
    
-        
    
-        This prevents the 'nobogons' option from logging DHCP
-        'DISCOVER' broadcasts.
    
-      
    4. 
-    

-
-    
New Features:

-
-    
    
-      
  1. 
-        
    To improve supportability, the "shorewall status"
-        command now includes IP and Route configuration
-        information.
    
-        
    
-           Example:
    
-        
    
-           IP
-        Configuration
    
-        
    
-           1: lo:
-        <LOOPBACK,UP> mtu 16436 qdisc noqueue
    
-              link/loopback 00:00:00:00:00:00 brd
-        00:00:00:00:00:00
    
-              inet
-        127.0.0.1/8 brd 127.255.255.255 scope host lo
    
-              inet6
-        ::1/128 scope host
    
-           2: eth0:
-        <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
-        pfifo_fast qlen 1000
    
-              link/ether 00:a0:c9:15:39:78 brd
-        ff:ff:ff:ff:ff:ff
    
-              inet6
-        fe80::2a0:c9ff:fe15:3978/64 scope link
    
-           3: eth1:
-        <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
-        pfifo_fast qlen 1000
    
-              link/ether 00:a0:c9:a7:d7:bf brd
-        ff:ff:ff:ff:ff:ff
    
-              inet6
-        fe80::2a0:c9ff:fea7:d7bf/64 scope link
    
-           5: sit0@NONE:
-        <NOARP> mtu 1480 qdisc noop
    
-              link/sit 0.0.0.0 brd 0.0.0.0
    
-           6: eth2:
-        <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
-        pfifo_fast qlen 1000
    
-              link/ether 00:40:d0:07:3a:1b brd
-        ff:ff:ff:ff:ff:ff
    
-              inet6
-        fe80::240:d0ff:fe07:3a1b/64 scope link
    
-           7: br0:
-        <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc
-        noqueue
    
-              link/ether 00:40:d0:07:3a:1b brd
-        ff:ff:ff:ff:ff:ff
    
-              inet
-        192.168.1.3/24 brd 192.168.1.255 scope global
-        br0
    
-              inet6
-        fe80::240:d0ff:fe07:3a1b/64 scope link
    
-        
    
-           Routing
-        Rules
    
-        
    
-           0:      from all
-        lookup local
    
-           32765:  from all
-        fwmark       ca lookup
-        www.out
    
-           32766:  from all
-        lookup main
    
-           32767:  from all
-        lookup default
    
-        
    
-           Table local:
    
-        
    
-           broadcast 192.168.1.0
-        dev br0  proto kernel  scope link  src
-        192.168.1.3
    
-           broadcast
-        127.255.255.255 dev lo  proto kernel  scope
-        link  src 127.0.0.1
    
-           local 192.168.1.3 dev
-        br0  proto kernel  scope host  src
-        192.168.1.3
    
-           broadcast 192.168.1.255
-        dev br0  proto kernel  scope link  src
-        192.168.1.3
    
-           broadcast 127.0.0.0 dev
-        lo  proto kernel  scope link  src
-        127.0.0.1
    
-           local 127.0.0.1 dev
-        lo  proto kernel  scope host  src
-        127.0.0.1
    
-           local 127.0.0.0/8 dev
-        lo  proto kernel  scope host  src
-        127.0.0.1
    
-        
    
-           Table
-        www.out:
    
-        
    
-           default via 192.168.1.3
-        dev br0
    
-        
    
-           Table main:
    
-        
    
-           192.168.1.0/24 dev
-        br0  proto kernel  scope link  src
-        192.168.1.3
    
-           default via
-        192.168.1.254 dev br0
    
-        
    
-           Table
-        default:
    
-      
    2. 
-    

-
-    
7/16/2004 - Shorewall 2.0.6

-    

-    Problems Corrected:

-
-    
    
-      
  • 
-        
    Some users have reported the
-        packet type match option in iptables/Netfilter failing to
-        match certain broadcast packets. The result is that the
-        firewall log shows a lot of broadcast packets.
    
-        
    
-        Other users have complained of the following message when
-        starting Shorewall:
    
-        
    
-                   
-        modprobe: cant locate module ipt_pkttype
    
-        
    
-        Users experiencing either of these problems can use
-        PKTTYPE=No in shorewall.conf to cause Shorewall to use IP
-        address filtering of broadcasts rather than packet
-        type.
    
-      
    • 
-
-      
  • 
-        
    The shorewall.conf and zones
-        file are no longer given execute permission by the
-        installer script.
    
-      
    • 
-
-      
  • 
-        
    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.
    
-      
    • 
-    

-
-    
7/10/2004 - Shorewall 2.0.5

-    

-    Problems Corrected:

-
-    
    
-      
  • 
-        
    If DISABLE_IPV6=Yes in
-        shorewall.conf then harmless error messages referring to
-        $RESTOREBASE are generated during shorewall
-        stop.
    
-      
    • 
-
-      
  • 
-        
    An anachronistic comment concerning a mangle option has
-        been removed from shorewall.conf.
    
-      
    • 
-    

-
-    
7/06/2004 - Shorewall 2.0.4

-    

-    Problems Corrected:

-
-    
    
-      
  • 
-        
    Rules with $FW as the source zone and that specify
-        logging can cause "shorewall start" to fail.
    
-      
    • 
-    

-
-    
7/03/2004 - New Shorewall
-    Release Model

-    

-    Effective today, Shorewall is adopting a new release model
-    which takes ideas from the one used in the Linux Kernel and
-    from the release model for Postfix.

-
-    
    
-      
  1. 
-        
    Releases continue to have a
-        three-level identification x.y.z (e.g., 2.0.3).
    
-      
    2. 
-
-      
  2. 
-        
    The first two levels
-        (x.y) designate the Major Release Number
-        (e.g., 2.0)
    
-      
    3. 
-
-      
  3. 
-        
    The third level (z)
-        designates the Minor Release Number.
    
-      
    4. 
-
-      
  4. 
-        
    Even numbered major releases
-        (e.g., 1.4, 2.0, 2.2, ...) are Stable
-        Releases. No new features are added to stable releases
-        and new minor releases of a stable release will only
-        contain bug fixes. Installing a new minor release for the
-        major release that you are currently running involves no
-        migration issues (for example, if you are running 1.4.10
-        and I release 1.4.11, your current configuration is 100%
-        compatible with the new release).
    
-      
    5. 
-
-      
  5. 
-        
    Support is available through
-        the Mailing List
-        for the two most recent Stable Releases.
    
-      
    6. 
-
-      
  6. 
-        
    Odd numbered major releases
-        (e.g., 2.1, 2.3, ...) are Development Releases.
-        Development releases are where new functionality is
-        introduced. Documentation for new features will be
-        available but it may not be up to the standards of the
-        stable release documentation. Sites running Development
-        Releases should be prepared to play an active role in
-        testing new features. Bug fixes and problem resolution for
-        the development release take a back seat to support of the
-        stable releases. Problem reports for the current
-        development release should be sent to the Shorewall
-        Development Mailing List.
    
-      
    7. 
-
-      
  7. 
-        
    When the level of
-        functionality of the current development release is judged
-        adaquate, the Beta period for a new Stable release will
-        begin. Beta releases have identifications of the form
-        x.y.0-BetaN where x.y is the number of the
-        next Stable Release and N=1,2,3... . Betas are
-        expected to occur rougly once per year. Beta releases may
-        contain new functionality not present in the previous beta
-        release (e.g., 2.2.0-Beta4 may contain functionality not
-        present in 2.2.0-Beta3). When I'm confident that the
-        current Beta release is stable, I will release the first
-        Release Candidate. Release candidates have
-        identifications of the form x.y.0-RCn where
-        x.y is the number of the next Stable Release and
-        n=1,2,3... . Release candidates contain no new
-        functionailty -- they only contain bug fixes. When the
-        stability of the current release candidate is judged to be
-        sufficient then that release candidate will be released as
-        the new stable release (e.g., 2.2.0). At that time, the new
-        stable release and the prior stable release are those that
-        are supported.
    
-      
    8. 
-
-      
  8. 
-        
    What does it mean for a
-        major release to be supported? It means that I will
-        answer questions about the release and that if a bug is
-        found, I will fix the bug and include the fix in the next
-        minor release.
    
-      
    9. 
-
-      
  9. 
-        
    Between minor releases, bug fixes will continue to be
-        made available through the Errata page for each major
-        release.
    
-      
    10. 
-    

-
-    
The immediate implications of this change are as
-    follows:

-
-    
    
-      
  1. 
-        
    The functionality of the 2.0
-        major release is frozen at the level of minor release
-        2.0.3.
    
-      
    2. 
-
-      
  2. 
-        
    The two major releases
-        currently supported are 1.4 and 2.0.
    
-      
    3. 
-
-      
  3. 
-        
    I will be opening the 2.1
-        development release shortly with the release of 2.1.0.
    
-      
    4. 
-
-      
  4. 
-        
    Bug-fix releases with identifications of the form
-        x.y.zX where X=a,b,c,... (e.g., 2.0.3c) will not be
-        seen in the future.
    
-      
    5. 
-    

-
-    
7/02/2004 - Shorewall 2.0.3c

-    

-    Problems Corrected:

-
-    
    
-      
  1. 
-        
    Error messages regarding
-        $RESTOREBASE occur during shorewall stop
    
-      
    2. 
-
-      
  2. 
-        
    If CLEAR_TC=Yes in shorewall.conf, shorewall
-        stop fails without removing the lock file.
    
-      
    3. 
-    

-
-    


-    6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g

-    

-    Problems Corrected:

-
-    
    
-      
  1. 
-        
    The security vulnerability
-        fix released in Shorewall 2.0.3a failed under Slackware
-        9.1.
    
-      
    2. 
-
-      
  2. 
-        
    The security vulnerability fix released in Shorewall
-        2.0.3a failed if mktemp was not installed.
    
-      
    3. 
-    

-
-    
6/28/2004 - Shorewall 2.0.3a and
-    Shorewall 1.4.10f

-    

-    Problems Corrected:

-
-    
    
-      
  1. 
-        
    Javier Fernández-Sanguino
-        Peña has discovered an exploitable vulnerability in the way
-        that Shorewall handles temporary files and directories. The
-        vulnerability can allow a non-root user to cause arbitrary
-        files on the system to be overwritten. LEAF Bering and
-        Bering uClibc users are generally not at risk due to the
-        fact that LEAF boxes do not typically allow logins by
-        non-root users.
    
-      
    2. 
-
-      
  2. 
-        
    (2.0.3a only) A non-empty DEST entry in
-        /etc/shorewall/tcrules will generate an error and Shorewall
-        fails to start.
    
-      
    3. 
-    

-
-    
Note:: Slackware users may need
-    the '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).

-
-    
6/23/2004 - Shorewall 2.0.3

-    

-    Problems Corrected:

-
-    
    
-      
  1. 
-        
    The 'firewall' script is not
-        purging temporary restore files in /var/lib/shorewall.
-        These files have names of the form "restore-nnnnn".
    
-      
    2. 
-
-      
  2. 
-        
    The
-        /var/lib/shorewall/restore script did not load the kernel
-        modules specified in /etc/shorewall/modules.
    
-      
    3. 
-
-      
  3. 
-        
    Specifying a null common
-        action in /etc/shorewall/actions (e.g., :REJECT) results in
-        a startup error.
    
-      
    4. 
-
-      
  4. 
-        
    If /var/lib/shorewall does
-        not exist, shorewall start fails.
    
-      
    5. 
-
-      
  5. 
-        
    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.
    
-      
    6. 
-
-      
  6. 
-        
    The install.sh script
-        reported installing some files in /etc/shorewall when the
-        files were actually installed in /usr/share/shorewall.
    
-      
    7. 
-
-      
  7. 
-        
    Shorewall checks netfilter
-        capabilities before loading kernel modules. Hence if kernel
-        module autoloading isn't enabled, the capabilities will be
-        misdetected.
    
-      
    8. 
-
-      
  8. 
-        
    The 'newnotsyn' option in
-        /etc/shorewall/hosts has no effect.
    
-      
    9. 
-
-      
  9. 
-        
    The file
-        /etc/init.d/shorewall now gets proper ownership when the
-        RPM is built by a non-root user.
    
-      
    10. 
-
-      
  10. 
-        
    Rules that specify bridge
-        ports in both the SOURCE and DEST columns no longer cause
-        "shorewall start" to fail.
    
-      
    11. 
-
-      
  11. 
-        
    Comments in the rules file
-        have been added to advise users that "all" in the SOURCE or
-        DEST column does not affect intra-zone traffic.
    
-      
    12. 
-
-      
  12. 
-        
    With BLACKLISTNEWONLY=Yes, ICMP packets with state
-        INVALID are now passed through the blacklisting chains.
-        Without this change, it is not possible to blacklist hosts
-        that are mounting certain types of ICMP-based DOS
-        attacks.
    
-      
    13. 
-    

-
-    
Issues when migrating from Shorewall 2.0.2 to Shorewall
-    2.0.3:

-
-    
    
-      
  1. 
-        
    The 'dropNonSyn' standard builtin action has been
-        replaced with the 'dropNotSyn' standard builtin action. The
-        old name can still be used but will generate a warning.
    
-      
    2. 
-    

-
-    
New Features:

-
-    
    
-      
  1. 
-        
    Shorewall now supports
-        multiple saved configurations.
    
-
-        
      
-          
    1. 
-            
      The default saved
-            configuration (restore script) in /var/lib/shorewall is
-            now specified using the RESTOREFILE option in
-            shorewall.conf. If this variable isn't set then to
-            maintain backward compatibility, 'restore' is
-            assumed.
      
-            
      
-            The value of RESTOREFILE must be a simple file name; no
-            slashes ("/") may be included.
      
-          
      2. 
-
-          
    2. 
-            
      The "save" command has
-            been extended to be able to specify the name of a saved
-            configuration.
      
-            
      
-                      
-            shorewall save [ <file name> ]
      
-            
      
-            The current state is saved to
-            /var/lib/shorewall/<file name>. If no <file
-            name> is given, the configuration is saved to the
-            file determined by the RESTOREFILE setting.
      
-          
      3. 
-
-          
    3. 
-            
      The "restore" command
-            has been extended to be able to specify the name of a
-            saved configuration:
      
-            
      
-                     
-            shorewall restore [ <file name> ]
      
-            
      
-            The firewall state is restored from
-            /var/lib/shorewall/<file name>. If no <file
-            name> is given, the firewall state is restored from
-            the file determined by the RESTOREFILE setting.
      
-          
      4. 
-
-          
    4. 
-            
      The "forget" command has
-            changed. Previously, the command unconditionally
-            removed the /var/lib/shorewall/save file which records
-            the current dynamic blacklist. The "forget" command now
-            leaves that file alone.
      
-            
      
-            Also, the "forget" command has been extended to be able
-            to specify the name of a saved configuration:
      
-            
      
-                         
-            shorewall forget [ <file name> ]
      
-            
      
-            The file /var/lib/shorewall/<file name> is
-            removed. If no <file name> is given, the file
-            determined by the RESTOREFILE setting is removed.
      
-          
      5. 
-
-          
    5. 
-            
      The "shorewall -f start"
-            command restores the state from the file determined by
-            the RESTOREFILE setting.
      
-          
      6. 
-        
    
-      
    2. 
-
-      
  2. 
-        
    "!" is now allowed in
-        accounting rules.
    
-      
    3. 
-
-      
  3. 
-        
    Interface names appearing
-        within the configuration are now verified. Interface names
-        must match the name of an entry in
-        /etc/shorewall/interfaces (or if bridging is enabled, they
-        must match the name of an entry in
-        /etc/shorewall/interfaces or the name of a bridge port
-        appearing in /etc/shorewall/hosts).
    
-      
    4. 
-
-      
  4. 
-        
    A new 'rejNotSyn' built-in
-        standard action has been added. This action responds to
-        "New not SYN" packets with an RST.
    
-        
    
-        The 'dropNonSyn' action has been superceded by the new
-        'dropNotSyn' action. The old name will be accepted until
-        the next major release of Shorewall but will generate a
-        warning.
    
-        
    
-        Several new logging actions involving "New not SYN" packets
-        have been added:
    
-        
    
-               
-        logNewNotSyn  -- logs the packet with disposition =
-        LOG
    
-                dLogNewNotSyn --
-        logs the packet with disposition = DROP
    
-                rLogNewNotSyn --
-        logs the packet with disposition = REJECT
    
-        
    
-        The packets are logged at the log level specified in the
-        LOGNEWNOTSYN option in shorewall.conf. If than option is
-        empty or not specified, then 'info' is assumed.
    
-        
    
-        Examples (In all cases, set NEWNOTSYN=Yes in
-        shorewall.conf):
    
-
-        
      
-          
    1. 
-            
      To simulate the behavior
-            of NEWNOTSYN=No:
      
-
-            
        
-              
      1. 
-                
        Add 'NoNewNotSyn' to
-                /etc/shorewall/actions.
        
-              
        2. 
-
-              
      2. 
-                
        Create /etc/shorewall/action.NoNewNotSyn
-                containing:
        
-                
        
-                           
-                dLogNotSyn
        
-                           
-                dropNotSyn
        
-              
        3. 
-
-              
      3. 
-                
        Early in your rules file, place:
        
-                
        
-                        
-                NoNewNotSyn   all  
-                all     tcp
        
-              
        4. 
-            
      
-          
      2. 
-
-          
    2. 
-            
      Drop 'New not SYN'
-            packets from the net only. Don't log them:
      
-
-            
        
-              
      1. 
-                
        Early in your rules file, place:
        
-                
        
-                        
-                dropNotSyn   
-                net       
-                all   tcp
        
-              
        2. 
-            
      
-          
      3. 
-        
    
-      
    5. 
-
-      
  5. 
-        
    Slackware users no longer have to modify the install.sh
-        script before installation. Tuomo Soini has provided a
-        change that allows the INIT and FIREWALL variables to be
-        specified outside the script as in:
    
-        
    
-              DEST=/etc/rc.d
-        INIT=rc.firewall ./install.sh
    
-      
    6. 
-    

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

-
-    
6/2/2004 - Shorewall 2.0.2e

-    

-
-    
One problem corrected:

-    

-
-    
    
-      
  1. LOG rules within an action generate two Netfilter logging
-      rules.
    
-      
    2. 
-    

-
-    
5/28/2004 - Shorewall 2.0.2d

-    

-    One problem corrected:

-    

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

-
-    
5/21/2004 - Shorewall 2.0.2c

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

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

-
-    
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
-      (/usr/share/shorewall/wait4ifup). That file is not part of
-      the normal Shorewall distribution and is provided by the
-      Debian maintainer.
    2. 
-
-      
  2. A meaningless warning message out of the proxyarp file
-      processing has been eliminated.
    3. 
-
-      
  3. The "shorewall delete" command now correctly removes all
-      dynamic rules pertaining to the host(s) being deleted. Thanks
-      to Stefan Engel for this correction.
    4. 
-    

-    Issues when migrating from Shorewall 2.0.1 to Shorewall
-    2.0.2:

-
-    
    
-      
  1. 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 iptables then those commands
-      must also be written to the restore file (a temporary file in
-      /var/lib/shorewall that is renamed
-      /var/lib/shorewall/restore-base at the end of the
-      operation).
    
-      
    
-      The following functions should be of help:
    
-      
    
-      A. save_command() -- saves the passed command to the restore
-      file.
    
-      
    
-          Example:
    
-      
    
-              save_command echo
-      Operation Complete
    
-      
    
-         That command would simply write "echo Operation
-      Complete" to the restore file.
    
-      
    
-      B. run_and_save_command() -- saves the passed command to the
-      restore file then executes it. The return value is the exit
-      status of the command.
    
-      
    
-          Example:
    
-      
    
-             run_and_save_command
-      "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"
    
-      
    
-          Note that as in this example, when the
-      command involves file redirection then the entire command
-      must be enclosed in 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.
    
-      
    
-      
    2. 
-
-      
  2. 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.
    3. 
-    

-    New Features:

-
-    
    
-      
  1. 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:
    
-      
    
-      a) The 'shorewall save' command now saves the current
-      configuration in addition to the current dynamic blacklist.
-      If you have dynamic zones, you will want to issue 'shorewall
-      save' when the zones are empty or the current contents of the
-      zones will be restored by the 'shorewall restore' and
-      'shorewall -f start' commands.
    
-      
    
-      b) The 'shorewall restore' command has been added. This
-      command restores the configuration at the time of the last
-      'save'.
    
-      
    
-      c) The -f (fast) option has been added to 'shorewall start'.
-      When specified (e.g. 'shorewall -f start'), shorewall will
-      perform a 'shorewall restore' if there is a saved
-      configuration. If there is no saved configuration, a normal
-      'shorewall start' is performed.
    
-      
    
-      d) The /etc/init.d/shorewall script now translates the
-      'start' command into 'shorewall -f start' so that fast
-      restart is possible.
    
-      
    
-      e) When a state-changing command encounters an error and
-      there is current saved configuration, that configuration will
-      be restored (currently, the firewall is placed in the
-      'stopped' state).
    
-      
    
-      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.
    
-      
    
-      
    2. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-      b) /etc/shorewall
    
-      c) /usr/share/shorewall
    
-      
    
-      In this release, the CONFIG_PATH option is added to
-      shorewall.conf. CONFIG_PATH contains a list of directory
-      names separated by colons (":"). If not set or set to a null
-      value (e.g., CONFIG_PATH="") then
-      "CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
-      Now Shorewall searches for shorewall.conf according to the
-      old rules and for other configuration files as follows:
    
-      
    
-      a) The directory specified in a 'try' command or specified
-      using the -c option.
    
-      b) Each directory in $CONFIG_PATH is searched in
-      sequence.
    
-      
    
-      In case it is not obvious, your CONFIG_PATH should include
-      /usr/share/shorewall and your shorewall.conf file must be in
-      the directory specified via -c or in a try command, in
-      /etc/shorewall or in /usr/share/shorewall.
    
-      
    
-      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.
    
-      
    
-      
    4. 
-
-      
  4. 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.
    
-      
    
-      
    5. 
-
-      
  5. 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".
    
-      
    
-      
    6. 
-
-      
  6. An updated bogons file is included in this release.
    
-      
    
-      
    7. 
-
-      
  7. 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 log tag.
    
-      
    
-      Example:
    
-      
    
-              ACCEPT:info:ftp
-      net     dmz    
-      tcp     21
    
-      
    
-      The log tag is appended to the log prefix generated by the
-      LOGPREFIX variable in /etc/shorewall/conf. If "ACCEPT:info"
-      generates the log 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.
    
-      
    
-      
    8. 
-
-      
  8. 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).
    
-      
    
-      
    9. 
-
-      
  9. Shorewall now uses 'modprobe' to load kernel modules if
-      that utility is available in the PATH; otherwise, 'insmod' is
-      used.
    
-      
    
-      
    10. 
-
-      
  10. 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.
    
-      
    
-      Example:
    
-      
    
-      You want all outgoing SMTP traffic entering the firewall on
-      eth1 to be sent from eth0 with source IP address
-      206.124.146.177. You want all other outgoing traffic from
-      eth1 to be sent from eth0 with source IP address
-      206.124.146.176.
    
-      
    
-             
-      eth0    eth1    206.124.146.177
-      tcp     25
    
-             
-      eth0    eth1   
-      206.124.146.176
    
-      
    
-      THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
    
-      
    
-      Assuming that 10.0.0.0/8 is the only host/network connected
-      to eth1, the progress message at "shorewall start" would
-      be:
    
-      
    
-          Masqueraded Networks and Hosts:
    
-             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
    
-      
    
-      
    11. 
-
-      
  11. 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.
    
-      
    
-      
    12. 
-
-      
  12. 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).
    
-      
    
-      
    13. 
-
-      
  13. 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.
    14. 
-    

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

-    

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

-    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.
    
-      
    
-      The rfc1918 file released with Shorewall now contains entries
-      for only those three address ranges reserved by RFC 1918. A
-      'nobogons' interface option has been added which handles
-      bogon source addresses (those which are reserved by the IANA,
-      those reserved for DHCP auto-configuration and the class C
-      test-net reserved for testing and documentation examples).
-      This will allow users to perform RFC 1918 filtering without
-      having to deal with out of date data from IANA. Those who are
-      willing to update their /usr/share/shorewall/bogons file
-      regularly can specify the 'nobogons' option in addition to
-      'norfc1918'.
    
-      
    
-      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.
    2. 
-    

-    New Features:

-    

-
-    
    
-      
  1. Support for Bridging Firewalls has been added. For
-      details, see
    
-      
    
-       http://shorewall.net/bridge.html
    
-
-      
    
-      
    2. 
-
-      
  2. Support for NETMAP has been added. NETMAP allows NAT to
-      be defined between two network:
    
-      
    
-                
-      a.b.c.1    -> x.y.z.1
    
-                
-      a.b.c.2    -> x.y.z.2
    
-                
-      a.b.c.3    -> x.y.z.3
    
-                
-      ...
    
-      
    
-        http://shorewall.net/netmap.htm
    
-
-      
    
-      
    3. 
-
-      
  3. 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:
    
-      
    
-                 
-      shorewall -x show [ <chain>[ <chain> ...] ]
    
-                 
-      shorewall -x show tos|mangle
    
-                 
-      shorewall -x show nat
    
-                 
-      shorewall -x status
    
-                 
-      shorewall -x monitor [ <interval> ]
    
-      
    
-      
    4. 
-
-      
  4. 
-        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.
      
-          
      
-          
      • 
-        
    
-      
    5. 
-
-      
  5. 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
    
-      
    
-      
    6. 
-
-      
  6. To support bridging, the following options have been
-      added to entries in /etc/shorewall/hosts:
    
-      
    
-                
-      norfc1918
    
-                
-      nobogons
    
-                
-      blacklist
    
-                
-      tcpflags
    
-                
-      nosmurfs
    
-                
-      newnotsyn
    
-      
    
-      With the exception of 'newnotsyn', these options are only
-      useful when the entry refers to a bridge port.
    
-      
    
-         Example:
    
-      
    
-         #ZONE  
-      HOST(S)      OPTIONS
    
-         net    
-      br0:eth0    
-      norfc1918,nobogons,blacklist,tcpflags,nosmurfs
    7. 
-    

-
-    
3/14/2004 - Shorewall 2.0.0b 

-    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
-      /etc/shorewall/nat is documented as 'No' but the default
-      continued to be 'Yes' as it was in Shorewall 1.4.
    
-      
    3. 
-    

-
-    
3/14/2004 - Shorewall 2.0.0a 

-
-    
Corrects one problem:

-    

-
-    
    
-      
  • Rules of the form:
    
-      
    
-      <action>    
-      zone1      zone2
    
-      
    
-      generated a warning stating that the rule was a policy.
    
-      
    • 
-    

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

-    

-
-    
    
-      
  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:
    
-      
    
-      DNAT  z1!z2,z3      
-      z4...
    
-      
    6. 
-    

-
-    
Problems Corrected since RC2

-    

-    

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

-
-    
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:
    
-      /etc/shorewall/common.def
    
-      /etc/shorewall/common
    
-      /etc/shorewall/icmpdef
    
-      /etc/shorewall/action.template (Moved to
-      /usr/share/shorewall)
    
-      /etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).
    
-      
    
-      The /etc/shorewall/action file now allows an action to be
-      designated as the "common" action for a particular policy
-      type by following the action name with ":" and the policy
-      (DROP, REJECT or ACCEPT).
    
-      
    
-      The file /usr/share/shorewall/actions.std has been added to
-      define those actions that are released as part of Shorewall.
-      In that file are two actions as follows:
    
-      
    
-          Drop:DROP
    
-         Reject:REJECT
    
-      
    
-      The "Drop" action is the common action for DROP policies
-      while the "Reject" action is the default action for "REJECT"
-      policies. These actions will be performed on packets prior to
-      applying the DROP or REJECT policy respectively. In the first
-      release, the difference between "Reject" and "Drop" is that
-      "Reject" REJECTs SMB traffic while "Drop" silently drops such
-      traffic.
    
-      
    
-      As described above, Shorewall allows a common action for
-      ACCEPT policies but does not specify such an action in the
-      default configuration.
    
-      
    
-      If for some reason, you don't wish to have a common DROP or
-      REJECT action, just include :DROP or :REJECT respectively in
-      your /etc/shorewall/actions file.
    
-      
    
-      The file /usr/share/shorewall/actions.std catalogs the
-      standard actions and is processed prior to
-      /etc/shorewall/actions. This causes a large number of actions
-      to be defined. The files which define these aactions are also
-      located in /usr/share/shorewall as is the he action template
-      file (action.template).
    
-      
    
-      These actions may be used in the ACTION column of the rules
-      column. So for example, to allow FTP from your loc zone to
-      your firewall, you would place this rule in
-      /etc/shorewall/rules:
    
-      
    
-        #ACTION    
-      SOURCE       DEST
    
-        AllowFTP    
-      loc          
-              fw
    
-      
    
-      If you want to redefine any of the Shorewall-defined actions,
-      simply copy the appropriate action file from
-      /usr/share/shorewall to /etc/shorewall and modify the copy as
-      desired. Your modified copy will be used rather than the
-      original one in /usr/share/shorewall.
    
-      
    
-      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.
    
-      
    
-      
    5. 
-
-      
  5. 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 name/id in the final column just like in the rules
-      file (see below). It is thus possible to create actions that
-      control traffic from a list of users and/or groups.
    
-      
    
-      The last column in /etc/shorewall/rules is now labeled
-      USER/GROUP and may contain:
    
-      
    
-          [!]<user number>[:]
    
-          [!]<user name>[:]
    
-          [!]:<group number>
    
-          [!]:<group name>
    
-          [!]<user number>:<group
-      number>
    
-          [!]<user number>:<group
-      name>
    
-          [!]<user name>:<group
-      number>
    
-          [!]<user name>:<group
-      name>
    
-       
    
-      
    6. 
-
-      
  6. It is no longer possible to specify rate limiting in the
-      ACTION column of /etc/shorewall/rules -- you must use the
-      RATE LIMIT column.
    
-      
    
-      
    7. 
-
-      
  7. 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.
    8. 
-    

-
-    
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
-      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.
    
-      
    
-      
    6. 
-
-      
  6. 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).
    7. 
-
-      
  7. 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".
    8. 
-
-      
  8. 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.
    9. 
-    

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

-    

-
-    
    
-      
  • In the /etc/shorewall/masq entry “eth0:!10.1.1.150    0.0.0.0/0!10.1.0.0/16
-          10.1.2.16”, the “!10.1.0.0/16” is ignored.
    • 
-    

-
-    
2/8/2004 - Shorewall 1.4.10a 

-
-    
Corrects two problems:

-    

-
-    
    
-      
  • A problem which can cause [re]start to fail inexplicably
-      while processing /etc/shorewall/masq.
    • 
-
-      
  • Interfaces using the Atheros WiFi card to use the
-      'maclist' option.
    • 
-    

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

-    Migragion Issues:

-    

-        None.

-    

-    New Features:

-
-    
    
-      
  1. The INTERFACE column in the /etc/shorewall/masq file may
-      now specify a destination list.
    
-      
    
-      Example:
    
-      
    
-          #INTERFACE   
-             
-      SUBNET        ADDRESS
    
-         
-      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.
    
-      
    
-      
    2. 
-
-      
  2. 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 :
    
-      
    
-            [<user name or
-      number>]:[<group name or number>]
    
-      
    
-      The colon is optionnal when specifying only a user.
    
-      
    
-             Examples : john: / john
-      / :users / john:users
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-      
    
-       WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
-      INTERFACE!   
    4. 
-    

-
-    
1/27/2004 - Shorewall 1.4.10 RC3

-
-    
http://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. 
-    

-    Migragion Issues:

-    

-        None.

-    

-    New Features:

-
-    
    
-      
  1. The INTERFACE column in the /etc/shorewall/masq file may
-      now specify a destination list.
    
-      
    
-      Example:
    
-      
    
-          #INTERFACE   
-             
-      SUBNET        ADDRESS
    
-         
-      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.
    
-      
    
-      
    2. 
-
-      
  2. 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 :
    
-      
    
-            [<user name or
-      number>]:[<group name or number>]
    
-      
    
-      The colon is optionnal when specifying only a user.
    
-      
    
-             Examples : john: / john
-      / :users / john:users
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-      
    
-       WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
-      INTERFACE!   
    4. 
-    

-
-    
1/24/2004 - Shorewall 1.4.10 RC2 

-
-    
http://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. 
-    

-    Migragion Issues:

-    

-        None.

-    

-    New Features:

-
-    
    
-      
  1. The INTERFACE column in the /etc/shorewall/masq file may
-      now specify a destination list.
    
-      
    
-      Example:
    
-      
    
-          #INTERFACE   
-             
-      SUBNET        ADDRESS
    
-         
-      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.
    
-      
    
-      
    2. 
-
-      
  2. 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 :
    
-      
    
-            [<user name or
-      number>]:[<group name or number>]
    
-      
    
-      The colon is optionnal when specifying only a user.
    
-      
    
-             Examples : john: / john
-      / :users / john:users
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-      
    
-       WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
-      INTERFACE!
    4. 
-    

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

-    Migragion Issues:

-    

-        None.

-    

-    New Features:

-
-    
    
-      
  1. The INTERFACE column in the /etc/shorewall/masq file may
-      now specify a destination list.
    
-      
    
-      Example:
    
-      
    
-          #INTERFACE   
-             
-      SUBNET        ADDRESS
    
-         
-      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.
    
-      
    
-      
    2. 
-
-      
  2. 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 :
    
-      
    
-            [<user name or
-      number>]:[<group name or number>]
    
-      
    
-      The colon is optionnal when specifying only a user.
    
-      
    
-             Examples : john: / john
-      / :users / john:users   
    
-      
    3. 
-    

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

-
-    
Migration Issues:

-    

-        None.

-    

-    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".
    
-      
    
-      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.
    
-      
    
-      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"
    5. 
-
-      
  5. 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.
    
-      
    
-      Example: You want an action that logs a packet at the 'info'
-      level and accepts the connection.
    
-      
    
-      In /etc/shorewall/actions, you would add:
    
-      
    
-           LogAndAccept
    
-      
    
-      You would then copy /etc/shorewall/action.template to
-      /etc/shorewall/action.LogAndAccept and in that file, you
-      would add the two rules:
    
-              LOG:info
    
-              ACCEPT
    6. 
-
-      
  6. 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 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.
    7. 
-
-      
  7. 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.
    8. 
-    

-
-    
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.
-      Previously, there were cases where the SNAT specification was
-      effectively ignored.
    
-      
    5. 
-    

-
-    
Migration Issues:

-
-    
    None.

-    

-    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".
    
-      
    
-      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.
    
-      
    
-      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"
    5. 
-
-      
  5. 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.
    
-      
    
-      Example: You want an action that logs a packet at the 'info'
-      level and accepts the connection.
    
-      
    
-      In /etc/shorewall/actions, you would add:
    
-      
    
-           LogAndAccept
    
-      
    
-      You would then copy /etc/shorewall/action.template to
-      /etc/shorewall/action.LogAndAccept and in that file, you
-      would add the two rules:
    
-              LOG:info
    
-              ACCEPT
    
-      
    6. 
-
-      
  6. 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 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.
    
-      
    
-      
    7. 
-    

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

-
-    
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".
    
-      
    
-      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.
    
-      
    
-      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"
    4. 
-
-      
  4. 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.
    
-      
    
-      Example: You want an action that logs a packet at the 'info'
-      level and accepts the connection.
    
-      
    
-      In /etc/shorewall/actions, you would add:
    
-      
    
-           LogAndAccept
    
-      
    
-      You would then copy /etc/shorewall/action.template to
-      /etc/shorewall/action.LogAndAccept and in that file, you
-      would add the two rules:
    
-              LOG:info
    
-              ACCEPT
    
-      
    5. 
-
-      
  5. 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 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.
    6. 
-    

-
-    
12/03/2003 - Support Torch Passed

-    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. 
-
-    
11/07/2003 - Shorewall 1.4.8

-    

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

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

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

-
-    
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.
    
-         
    
-      The firewall script has been modified to eliminate the error
-      messages
    
-      
    5. 
-    

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

-
-    
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 tcrules file. Previously, these addresses resulted in
-      an invalid iptables command.
    
-      
    3. 
-    

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

-
-    
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 tcrules file. Previously, these addresses resulted in
-      an invalid iptables command.
    
-      
    3. 
-    

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

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

-    

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

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

-    

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

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

-
-    
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. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. Corrected a problem in Beta 1 where DNS names containing
-      a "-" were mis-handled when they appeared in the DEST column
-      of a rule.
    
-      
    
-      
    4. 
-
-      
  4. 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.
    
-      
    
-      
    5. 
-
-      
  5. The message "Adding rules for DHCP" is now suppressed if
-      there are no DHCP rules to add.
    
-      
    6. 
-    

-
-    
Migration Issues:

-    

-
-    
    
-      
  1. 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:
    
-      
    
-          z  
-      eth1:192.168.1.0/24,192.168.2.0/24
    
-      
    
-      
    2. 
-
-      
  2. 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).
    
-      
    3. 
-    

-
-    
New Features:

-    

-
-    
    
-      
  1. 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.
    
-      
    
-      
    2. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. Shorewall can now add IP addresses to subnets other than
-      the first one on an interface.
    
-      
    
-      
    4. 
-
-      
  4. 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
    
-      
    
-      
    5. 
-
-      
  5. 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...
    
-      
    
-      
    6. 
-
-      
  6. 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:
    7. 
-
-      
  7. 
-        
      
-          
    • 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.
      
-          
      
-          
      • 
-        
    
-      
    8. 
-
-      
  8. The shell used to interpret the firewall script
-      (/usr/share/shorewall/firewall) may now be specified using
-      the SHOREWALL_SHELL parameter in shorewall.conf.
    
-      
    
-      
    9. 
-
-      
  9. 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
    
-            [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
    
-            [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.
    
-      
    
-      
    10. 
-
-      
  10. An 'iprange' command has been added to
-      /sbin/shorewall.
    
-      
    
-            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.
    
-      
    
-      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
    
-            192.168.1.4/30
    
-            192.168.1.8/29
    
-            192.168.1.16/28
    
-            192.168.1.32/27
    
-            192.168.1.64/26
    
-            192.168.1.128/25
    
-            192.168.2.0/23
    
-            192.168.4.0/22
    
-            192.168.8.0/22
    
-            192.168.12.0/29
    
-            192.168.12.8/31
    
-            [root@gateway root]#
    
-      
    
-      
    11. 
-
-      
  11. 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
    
-      
    
-      
    12. 
-
-      
  12. The "shorewall check" command now includes the chain name
-      when printing the applicable policy for each pair of
-      zones.
    
-       
    
-          Example:
    
-       
    
-              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.
    
-      
    
-      
    13. 
-
-      
  13. Support for the 2.6 Kernel series has been added.
    
-      
    14. 
-    

-
-    
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. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. Corrected a problem in Beta 1 where DNS names containing
-      a "-" were mis-handled when they appeared in the DEST column
-      of a rule.
    
-      
    
-      
    4. 
-
-      
  4. 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.
    
-      
    5. 
-    

-
-    
Migration Issues:

-    

-
-    
    
-      
  1. 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:
    
-      
    
-          z  
-      eth1:192.168.1.0/24,192.168.2.0/24
    
-      
    
-      
    2. 
-
-      
  2. 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).
    
-      
    3. 
-    

-
-    
New Features:

-    

-
-    
    
-      
  1. 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.
    
-      
    
-      
    2. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. Shorewall can now add IP addresses to subnets other than
-      the first one on an interface.
    
-      
    
-      
    4. 
-
-      
  4. 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
    
-      
    
-      
    5. 
-
-      
  5. 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...
    
-      
    
-      
    6. 
-
-      
  6. 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:
    7. 
-
-      
  7. 
-        
      
-          
    • 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.
      
-          
      
-          
      • 
-        
    
-      
    8. 
-
-      
  8. The shell used to interpret the firewall script
-      (/usr/share/shorewall/firewall) may now be specified using
-      the SHOREWALL_SHELL parameter in shorewall.conf.
    
-      
    
-      
    9. 
-
-      
  9. 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
    
-            [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
    
-            [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.
    
-      
    
-      
    10. 
-
-      
  10. An 'iprange' command has been added to
-      /sbin/shorewall.
    
-      
    
-            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.
    
-      
    
-      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
    
-            192.168.1.4/30
    
-            192.168.1.8/29
    
-            192.168.1.16/28
    
-            192.168.1.32/27
    
-            192.168.1.64/26
    
-            192.168.1.128/25
    
-            192.168.2.0/23
    
-            192.168.4.0/22
    
-            192.168.8.0/22
    
-            192.168.12.0/29
    
-            192.168.12.8/31
    
-            [root@gateway root]#
    
-      
    
-      
    11. 
-
-      
  11. 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
    12. 
-    

-
-    
7/7/2003 - Shorewall-1.4.6 Beta 2

-
-    
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. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. Corrected a problem in Beta 1 where DNS names containing
-      a "-" were mis-handled when they appeared in the DEST column
-      of a rule.
    
-      
    4. 
-    

-
-    
Migration Issues:

-    

-
-    
    
-      
  1. 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:
    
-      
    
-          z  
-      eth1:192.168.1.0/24,192.168.2.0/24
    
-      
    
-      
    2. 
-
-      
  2. 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).
    
-      
    3. 
-    

-
-    
New Features:

-    

-
-    
    
-      
  1. 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.
    
-      
    
-      
    2. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. Shorewall can now add IP addresses to subnets other than
-      the first one on an interface.
    
-      
    
-      
    4. 
-
-      
  4. 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
    
-      
    
-      
    5. 
-
-      
  5. 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...
    
-      
    
-      
    6. 
-
-      
  6. 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:
    7. 
-
-      
  7. 
-        
      
-          
    • 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.
      
-          
      
-          
      • 
-        
    
-      
    8. 
-
-      
  8. The shell used to interpret the firewall script
-      (/usr/share/shorewall/firewall) may now be specified using
-      the SHOREWALL_SHELL parameter in shorewall.conf.
    
-      
    
-      
    9. 
-
-      
  9. 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
    
-            [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
    
-            [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.
    
-      
    
-      
    10. 
-
-      
  10. An 'iprange' command has been added to
-      /sbin/shorewall.
    
-      
    
-            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.
    
-      
    
-      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
    
-            192.168.1.4/30
    
-            192.168.1.8/29
    
-            192.168.1.16/28
    
-            192.168.1.32/27
    
-            192.168.1.64/26
    
-            192.168.1.128/25
    
-            192.168.2.0/23
    
-            192.168.4.0/22
    
-            192.168.8.0/22
    
-            192.168.12.0/29
    
-            192.168.12.8/31
    
-            [root@gateway root]#
    
-      
    
-      
    11. 
-
-      
  11. 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
    
-      
    
-      
    12. 
-    

-
-    
7/4/2003 - Shorewall-1.4.6 Beta 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. 
-
-      
  2. 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.
    
-      
    3. 
-    

-
-    
New Features:

-    

-
-    
    
-      
  1. 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.
    
-      
    
-      
    2. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. Shorewall can now add IP addresses to subnets other than
-      the first one on an interface.
    
-      
    
-      
    4. 
-
-      
  4. 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:
    
-      
    
-          DNAT net loc:192.168.10.2-192.168.10.5 tcp
-      80
    
-      
    
-      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.
    
-      
    
-      
    5. 
-
-      
  5. 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...
    
-      
    
-      
    6. 
-
-      
  6. 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:
    7. 
-
-      
  7. 
-        
      
-          
    • 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.
      
-          
      
-          
      • 
-        
    
-      
    8. 
-
-      
  8. The shell used to interpret the firewall script
-      (/usr/share/shorewall/firewall) may now be specified using
-      the SHOREWALL_SHELL parameter in shorewall.conf.
    
-      
    9. 
-    

-
-    
6/17/2003 - Shorewall-1.4.5

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

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

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

-    

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

-    

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

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

-    

-        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. 
-
-      
  2. 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.
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-      
    4. 
-    

-
-    
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:
    
-         a) tcp - RST
    
-         b) udp - ICMP port unreachable
    
-         c) icmp - ICMP host unreachable
    
-         d) Otherwise - ICMP host prohibited
    
-      If you are running earlier software, Shorewall will follow
-      it's traditional convention:
    
-         a) tcp - RST
    
-         b) Otherwise - ICMP port unreachable
    2. 
-
-      
  2. 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.
    
-      
    3. 
-    

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

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

-
-    
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 Francesca Smith, the sample configurations are now
-    upgraded to Shorewall version 1.4.2.

-
-    
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. 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 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.
    
-       
    
-         Examples:
    
-         shorewall/params.mgmt:
    
-         MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    
-         TIME_SERVERS=4.4.4.4
    
-         BACKUP_SERVERS=5.5.5.5
    
-         ----- end params.mgmt -----
    
-       
    
-       
    
-         shorewall/params:
    
-         # Shorewall 1.3 /etc/shorewall/params
    
-         [..]
    
-         #######################################
    
-       
    
-         INCLUDE params.mgmt   
    
-       
    
-         # params unique to this host here
    
-         #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE -
-      DO NOT REMOVE
    
-         ----- end params -----
    
-       
    
-       
    
-         shorewall/rules.mgmt:
    
-         ACCEPT
-      net:$MGMT_SERVERS         
-      $FW    tcp    22
    
-         ACCEPT
-      $FW         
-      net:$TIME_SERVERS    udp   
-      123
    
-         ACCEPT
-      $FW         
-      net:$BACKUP_SERVERS  tcp    22
    
-         ----- end rules.mgmt -----
    
-       
    
-         shorewall/rules:
    
-         # Shorewall version 1.3 - Rules File
    
-         [..]
    
-         #######################################
    
-       
    
-         INCLUDE rules.mgmt    
    
-       
    
-         # rules unique to this host here
    
-         #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.
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-       
    
-      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').
    
-       
    
-      See the 'Upgrade Issues' for
-      information about how this new option may affect your
-      configuration.
    
-      
    4. 
-    

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

-    

-
-    
    
-      
  1. 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.
    2. 
-    

-    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

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

-    

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

-
-    
    
-      
  • There may be no rules created that govern connections
-      from Z1 to Z2.
    • 
-
-      
  • Shorewall will not create any infrastructure to handle
-      traffic 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.
-    

-    

-    IMPORTANT: Shorewall 1.4.0 requires the iproute
-    package ('ip' utility).

-    

-    Function from 1.3 that has been omitted from this version
-    include:

-
-    
    
-      
  1. 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.
    
-      
    
-      
    2. 
-
-      
  2. Interface names of the form
-      <device>:<integer> in /etc/shorewall/interfaces
-      now generate an error.
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-      
    
-      
    4. 
-
-      
  4. 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.
    
-      
    
-      
    5. 
-
-      
  5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is
-      no longer accepted.
    
-      
    
-      
    6. 
-
-      
  6. The ALLOWRELATED variable in shorewall.conf is no longer
-      supported. Shorewall 1.4 behavior is the same as 1.3 with
-      ALLOWRELATED=Yes.
    
-      
    
-      
    7. 
-
-      
  7. The icmp.def file has been removed.
    
-      
    8. 
-    

-    Changes for 1.4 include:

-
-    
    
-      
  1. The /etc/shorewall/shorewall.conf file has been
-      completely reorganized into logical sections.
    
-      
    
-      
    2. 
-
-      
  2. LOG is now a valid action for a rule
-      (/etc/shorewall/rules).
    
-      
    
-      
    3. 
-
-      
  3. The firewall script and version file are now installed in
-      /usr/share/shorewall.
    
-      
    
-      
    4. 
-
-      
  4. Late arriving DNS replies are now silently dropped in the
-      common chain by default.
    
-      
    
-      
    5. 
-
-      
  5. 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.
    
-      
    
-      
    6. 
-
-      
  6. CONTINUE is now a valid action for a rule
-      (/etc/shorewall/rules).
    
-      
    
-      
    7. 
-
-      
  7. 802.11b devices with names of the form wlan<n> now
-      support the 'maclist' option.
    
-      
    
-      
    8. 
-
-      
  8. 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.
    
-      
    
-      
    9. 
-
-      
  9. The /etc/shorewall/params file is now processed first so
-      that variables may be used in the
-      /etc/shorewall/shorewall.conf file.
    
-      
    
-      
    10. 
-
-      
  10. Shorewall now gives a more helpful diagnostic
-      when the 'ipchains' compatibility kernel module is loaded and
-      a 'shorewall start' command is issued.
    
-      
    
-      
    11. 
-
-      
  11. 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.
    
-      
    
-      
    12. 
-
-      
  12. Shorewall now ignores 'default' routes when detecting
-      masq'd networks.
    13. 
-    

-
-    
3/10/2003 - Shoreall 1.3.14a

-
-    
A roleup of the following bug fixes and other updates:

-
-    
    
-      
  • There is an updated rfc1918 file that reflects the resent
-      allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • 
-    

-
-    
    
-      
  • The documentation for the routestopped file claimed that
-      a comma-separated list could appear in the second column
-      while the code only supported a single host or network
-      address.
    • 
-
-      
  • Log messages produced by 'logunclean' and 'dropunclean'
-      were not rate-limited.
    • 
-
-      
  • 802.11b devices with names of the form
-      wlan<n> don't support the 'maclist' interface
-      option.
    • 
-
-      
  • Log messages generated by RFC 1918 filtering are not rate
-      limited.
    • 
-
-      
  • The firewall fails to start in the case where you have
-      "eth0 eth1" in /etc/shorewall/masq and the default route is
-      through eth1
    • 
-    

-
-    
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).
    
-      
    
-      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.
    
-      
    
-      
    2. 
-
-      
  2. 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
    
-       
    3. 
-
-      
  3. Support for OpenVPN Tunnels.
    
-      
    
-      
    4. 
-
-      
  4. Support for VLAN devices with names of the form $DEV.$VID
-      (e.g., eth0.0)
    
-      
    
-      
    5. 
-
-      
  5. 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.
    
-      
    
-      
    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.
    
-         
    
-        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.
    
-         
    
-        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.
    
-         
    
-        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. 
-    

-
-    


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

-    

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

-    

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

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

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

-    

-
-    
    
-      
  1. 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.
    
-      
    
-         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
    
-              ACCEPT net 
-      dmz:206.124.146.177 tcp www,smtp,ftp,...
    
-      
    
-         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.
    
-      
    
-              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,....
    
-      
    
-      
    2. 
-
-      
  2. The 'shorewall check' command now prints out the
-      applicable policy between each pair of zones.
    
-      
    
-      
    3. 
-
-      
  3. 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.
    
-      
    
-      
    4. 
-
-      
  4. 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.
    
-      
    5. 
-    

-
-    
1/6/2003 -
-    BURNOUT

-
-    
Until further notice, I will not be involved in either
-    Shorewall Development or Shorewall Support

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

-
-    
    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/

-
-        http://slovakia.shorewall.net/pub/shorewall/pdf/

-
-    

-
-    
12/27/2002 - Shorewall 1.3.12 Released

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

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

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

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

-    You may download the Beta from:

-
-    

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

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

-    

-
-    
12/12/2002 - Mandrake Multi Network Firewall -
-    

-    Shorewall is at the center of MandrakeSoft's recently-announced
-    
-    Multi Network Firewall (MNF) product. Here is the 
-    press 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.

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

-
-    
    
-      
  • A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces.
-      This option causes Shorewall to make a set of sanity check on
-      TCP packet header flags.
    • 
-
-      
  • It is now allowed to use 'all' in the SOURCE or DEST
-      column in a rule. When
-      used, 'all' must appear by itself (in may not be qualified)
-      and it does not enable intra-zone traffic. For example, the
-      rule
    
-      
    
-          ACCEPT loc all tcp 80
    
-      
    
-      does not enable http traffic from 'loc' to 'loc'.
    • 
-
-      
  • Shorewall's use of the 'echo' command is now compatible
-      with bash clones such as ash and dash.
    • 
-
-      
  • fw->fw policies now generate a startup error.
-      fw->fw rules generate a warning and are ignored
    • 
-    

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

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

-    

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

-
-    
-    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/9/2002 - Shorewall 1.3.9b

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

-    

-    9/30/2002 - Shorewall 1.3.9a

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

-
-    
9/28/2002 - Shorewall 1.3.9

-
-    
In this version:

-    

-
-    
    
-      
  • DNS
-      Names are now allowed in Shorewall config files (although
-      I recommend against using them).
    • 
-
-      
  • The connection SOURCE may now be qualified by both
-      interface and IP address in a Shorewall rule.
    • 
-
-      
  • Shorewall startup is now disabled after initial
-      installation until the file /etc/shorewall/startup_disabled
-      is removed. This avoids nasty surprises during reboot for
-      users who install Shorewall but don't configure it.
    • 
-
-      
  • The 'functions' and 'version' files and the 'firewall'
-      symbolic link have been moved from /var/lib/shorewall to
-      /usr/lib/shorewall to appease the LFS police at Debian.
    
-      
    • 
-    

-
-    
9/23/2002 - Full Shorewall Site/Mailing List Archive
-    Search 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:

-
-    
    
-      
  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/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:

-    

-
-    
    
-      
  • A NEWNOTSYN option
-      has been added to shorewall.conf. This option determines
-      whether Shorewall accepts TCP packets which are not part of
-      an established connection and that are not 'SYN' packets (SYN
-      flag on and ACK flag off).
    • 
-
-      
  • The need for the 'multi' option to communicate between
-      zones za and zb on the same interface is removed in the case
-      where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will
-      exist if:
    • 
-
-      
  • 
-        
      
-          
    • There is a policy for za to zb; or
      • 
-
-          
    • There is at least one rule for za to zb.
      • 
-        
    
-      
    • 
-    

-
-    
    
-      
  • The /etc/shorewall/blacklist file now contains three
-      columns. In addition to the SUBNET/ADDRESS column, there are
-      optional PROTOCOL and PORT columns to block only certain
-      applications from the blacklisted addresses.
    
-      
    • 
-    

-
-    
9/11/2002 - Debian 1.3.7c Packages Available

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

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

-
-    
8/26/2002 - French FTP Mirror is Operational

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

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

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

-
-    
    
-      
  • The 'icmp.def' file is now empty! The rules in that file
-      were required in ipchains firewalls but are not required in
-      Shorewall. Users who have ALLOWRELATED=No in shorewall.conf should see the Upgrade Issues.
    • 
-
-      
  • A 'FORWARDPING' option has been added to shorewall.conf. The effect of
-      setting this variable to Yes is the same as the effect of
-      adding an ACCEPT rule for ICMP echo-request in /etc/shorewall/icmpdef.
-      Users who have such a rule in icmpdef are encouraged to
-      switch to FORWARDPING=Yes.
    • 
-
-      
  • The loopback CLASS A Network (127.0.0.0/8) has been added
-      to the rfc1918 file.
    • 
-
-      
  • Shorewall now works with iptables 1.2.7
    • 
-
-      
  • The documentation and web site no longer uses FrontPage
-      themes.
    • 
-    

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

-
-    
8/7/2002 - Upgrade
-    Issues 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:

-
-    
-
-    
7/30/2002 - Shorewall 1.3.5b Released

-
-    
This interim release:

-
-    
    
-      
  • Causes the firewall script to remove the lock file if it
-      is killed.
    • 
-
-      
  • Once again allows lists in the second column of the /etc/shorewall/hosts
-      file.
    • 
-
-      
  • Includes the latest QuickStart Guides.
    • 
-    

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

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

-
-    
7/27/2002 - Shorewall 1.3.5a Released

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

-
-    
    
-      
  • Empty and invalid source and destination qualifiers are
-      now detected in the rules file. It is a good idea to use the
-      'shorewall check' command before you issue a 'shorewall
-      restart' command be be sure that you don't have any
-      configuration problems that will prevent a successful
-      restart.
    • 
-
-      
  • Added MERGE_HOSTS variable in shorewall.conf to provide saner
-      behavior of the /etc/shorewall/hosts file.
    • 
-
-      
  • The time that the counters were last reset is now
-      displayed in the heading of the 'status' and 'show'
-      commands.
    • 
-
-      
  • A proxyarp option has been added for entries in /etc/shorewall/interfaces.
-      This option facilitates Proxy ARP sub-netting as described in
-      the Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/).
-      Specifying the proxyarp option for an interface causes
-      Shorewall to set
-      /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
    • 
-
-      
  • The Samples have been updated to reflect the new
-      capabilities in this release.
    • 
-    

-
-    
7/16/2002 - New Mirror in Argentina

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

-
-    
    
-      
  • A new /etc/shorewall/routestopped
-      file has been added. This file is intended to eventually
-      replace the routestopped option in the
-      /etc/shorewall/interface and /etc/shorewall/hosts files. This
-      new file makes remote firewall administration easier by
-      allowing any IP or subnet to be enabled while Shorewall is
-      stopped.
    • 
-
-      
  • An /etc/shorewall/stopped extension script has been
-      added. This script is invoked after Shorewall has
-      stopped.
    • 
-
-      
  • A DETECT_DNAT_ADDRS option has been added to /etc/shoreall/shorewall.conf.
-      When this option is selected, DNAT rules only apply when the
-      destination address is the external interface's primary IP
-      address.
    • 
-
-      
  • The QuickStart
-      Guide has been broken into three guides and has been
-      almost entirely rewritten.
    • 
-
-      
  • The Samples have been updated to reflect the new
-      capabilities in this release.
    • 
-    

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

-
-    
7/6/2002 - Shorewall 1.3.3 Released

-
-    
In this version:

-
-    
    
-      
  • Entries in /etc/shorewall/interface that use the wildcard
-      character ("+") now have the "multi" option assumed.
    • 
-
-      
  • The 'rfc1918' chain in the mangle table has been renamed
-      'man1918' to make log messages generated from that chain
-      distinguishable from those generated by the 'rfc1918' chain
-      in the filter table.
    • 
-
-      
  • Interface names appearing in the hosts file are now
-      validated against the interfaces file.
    • 
-
-      
  • The TARGET column in the rfc1918 file is now checked for
-      correctness.
    • 
-
-      
  • The chain structure in the nat table has been changed to
-      reduce the number of rules that a packet must traverse and to
-      correct problems with NAT_BEFORE_RULES=No
    • 
-
-      
  • The "hits" command has been enhanced.
    • 
-    

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

-
-    
6/19/2002 - Documentation Available in PDF Format

-
-    
Thanks to Mike Martinez, the Shorewall Documentation is now
-    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:

-
-    
    
-      
  • Ignore robot.txt files.
    • 
-
-      
  • Recursively copy everything that they find.
    • 
-
-      
  • Should be classified as weapons rather than 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.

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

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

-
-    
6/1/2002 - Shorewall 1.3.1 Released

-
-    
Hot on the heels of 1.3.0, this release:

-
-    
    
-      
  • Corrects a serious problem with "all <zone>
-      CONTINUE" policies. This problem is present in all versions
-      of Shorewall that support the CONTINUE policy. These previous
-      versions optimized away the "all2<zone>" chain
-      and replaced it with the "all2all" chain with the usual
-      result that a policy of REJECT was enforced rather than the
-      intended CONTINUE policy.
    • 
-
-      
  • Adds an /etc/shorewall/rfc1918 file
-      for defining the exact behavior of the 'norfc1918' interface
-      option.
    • 
-    

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

-
-    
    
-      
  • A 'filterping' interface option that allows ICMP
-      echo-request (ping) requests addressed to the firewall to be
-      handled by entries in /etc/shorewall/rules and
-      /etc/shorewall/policy.
    • 
-    

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

-
-    
    
-      
  • Support for the /etc/shorewall/whitelist file has been
-      withdrawn. If you need whitelisting, see these
-      instructions.
    • 
-    

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

-
-    
    
-      
  • The structure of the firewall is changed markedly. There
-      is now an INPUT and a FORWARD chain for each interface; this
-      reduces the number of rules that a packet must traverse,
-      especially in complicated setups.
    • 
-
-      
  • Sub-zones may now be
-      excluded from DNAT and REDIRECT rules.
    • 
-
-      
  • The names of the columns in a number of the configuration
-      files have been changed to be more consistent and
-      self-explanatory and the documentation has been updated
-      accordingly.
    • 
-
-      
  • The sample configurations have been updated for 1.3.
    • 
-    

-
-    
5/17/2002 - Shorewall 1.3 Beta 1 Available

-
-    
Beta 1 carries the version designation 1.2.90 and implements
-    the following features:

-
-    
    
-      
  • Simplified rule syntax which makes the intent of each
-      rule clearer and hopefully makes Shorewall easier to
-      learn.
    • 
-
-      
  • Upward compatibility with 1.2 configuration files has
-      been maintained so that current users can migrate to the new
-      syntax at their convenience.
    • 
-
-      
  • WARNING:  Compatibility
-      with the old parameterized sample configurations has NOT been
-      maintained. Users still running those configurations should
-      migrate to the new sample configurations before upgrading to
-      1.3 Beta 1.
    • 
-    

-
-    
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
-    Testing Branch and the Debian
-    Unstable Branch.

-
-    
4/20/2002 - Shorewall 1.2.12 is Available

-
-    
    
-      
  • The 'try' command works again
    • 
-
-      
  • There is now a single RPM that also works with SuSE.
    • 
-    

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

-
-    
4/13/2002 - Shorewall 1.2.11 Available

-
-    
In this version:

-
-    
    
-      
  • The 'try' command now accepts an optional timeout. If the
-      timeout is given in the command, the standard configuration
-      will automatically be restarted after the new configuration
-      has been running for that length of time. This prevents a
-      remote admin from being locked out of the firewall in the
-      case where the new configuration starts but prevents
-      access.
    • 
-
-      
  • Kernel route filtering may now be enabled globally using
-      the new ROUTE_FILTER parameter in /etc/shorewall/shorewall.conf.
    • 
-
-      
  • Individual IP source addresses and/or subnets may now be
-      excluded from masquerading/SNAT.
    • 
-
-      
  • Simple "Yes/No" and "On/Off" values are now
-      case-insensitive in /etc/shorewall/shorewall.conf.
    • 
-    

-
-    
4/13/2002 - Hamburg Mirror now has FTP

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

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

-
-    
Version 1.0 of the
-    QuickStart Guide is now available. This Guide and its
-    accompanying sample configurations are expected to provide a
-    replacement for the recently withdrawn parameterized
-    samples.

-
-    
4/8/2002 - Parameterized Samples Withdrawn

-
-    
Although the parameterized
-    samples have allowed people to get a firewall up and
-    running quickly, they have unfortunately set the wrong level of
-    expectation among those who have used them. I am therefore
-    withdrawing support 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.

-
-    
3/30/2002 - Shorewall Website Search Improvements

-
-    
The quick search on the home page now excludes the mailing
-    list 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)

-
-    
-
-    
3/25/2002 - Log Parser Available

-
-    
John Lodge has
-    provided a CGI-based log
-    parser for Shorewall. Thanks John.

-
-    
3/20/2002 - Shorewall 1.2.10 Released

-
-    
In this version:

-
-    
    
-      
  • A "shorewall try" command has been added (syntax:
-      shorewall try <configuration directory>). This
-      command attempts "shorewall -c <configuration
-      directory> start" and if that results in the firewall
-      being stopped due to an error, a "shorewall start" command is
-      executed. The 'try' command allows you to create a new configuration and
-      attempt to start it; if there is an error that leaves your
-      firewall in the stopped state, it will automatically be
-      restarted using the default configuration (in
-      /etc/shorewall).
    • 
-
-      
  • A new variable ADD_SNAT_ALIASES has been added to /etc/shorewall/shorewall.conf.
-      If this variable is set to "Yes", Shorewall will
-      automatically add IP addresses listed in the third column of
-      the /etc/shorewall/masq
-      file.
    • 
-
-      
  • Copyright notices have been added to the
-      documenation.
    • 
-    

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

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

-
-    
2/22/2002 - Shorewall 1.2.7 Released

-
-    
In this version:

-
-    
    
-      
  • UPnP probes (UDP destination port 1900) are now silently
-      dropped in the common chain
    • 
-
-      
  • RFC 1918 checking in the mangle table has been
-      streamlined to no longer require packet marking. RFC 1918
-      checking in the filter table has been changed to require half
-      as many rules as previously.
    • 
-
-      
  • A 'shorewall check' command has been added that does a
-      cursory validation of the zones, interfaces, hosts, rules and
-      policy files.
    • 
-    

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

-
-    
    
-      
  • $-variables may now be used anywhere in the configuration
-      files except /etc/shorewall/zones.
    • 
-
-      
  • The interfaces and hosts files now have their contents
-      validated before any changes are made to the existing
-      Netfilter configuration. The appearance of a zone name that
-      isn't defined in /etc/shorewall/zones causes "shorewall
-      start" and "shorewall restart" to abort without changing the
-      Shorewall state. Unknown options in either file cause a
-      warning to be issued.
    • 
-
-      
  • A problem occurring when BLACKLIST_LOGLEVEL was not set
-      has been corrected.
    • 
-    

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

-
-    
In version 1.2.5:

-
-    
    
-      
  • The installation problems have been corrected.
    • 
-
-      
  • SNAT is now
-      supported.
    • 
-
-      
  • A "shorewall version" command has been added
    • 
-
-      
  • The default value of the STATEDIR variable in
-      /etc/shorewall/shorewall.conf has been changed to
-      /var/lib/shorewall in order to conform to the GNU/Linux File
-      Hierarchy Standard, Version 2.2.
    • 
-    

-
-    
1/28/2002 - Shorewall 1.2.4 Released

-
-    
    
-      
  • The "fw" zone may now be
-      given a different name.
    • 
-
-      
  • You may now place end-of-line comments (preceded by '#')
-      in any of the configuration files
    • 
-
-      
  • There is now protection against against two state
-      changing operations occuring concurrently. This is
-      implemented using the 'lockfile' utility if it is available
-      (lockfile is part of procmail); otherwise, a less robust
-      technique is used. The lockfile is created in the STATEDIR
-      defined in /etc/shorewall/shorewall.conf and has the name
-      "lock".
    • 
-
-      
  • "shorewall start" no longer fails if "detect" is
-      specified in /etc/shorewall/interfaces
-      for an interface with subnet mask 255.255.255.255.
    • 
-    

-
-    
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 errata for details.

-
-    
1/19/2002 - Shorewall 1.2.3 Released

-
-    
This is a minor feature and bugfix release. The single new
-    feature is:

-
-    
    
-      
  • Support for TCP MSS Clamp to PMTU -- This support is
-      usually required when the internet connection is via PPPoE or
-      PPTP and may be enabled using the CLAMPMSS option in
-      /etc/shorewall/shorewall.conf.
    • 
-    

-
-    
The following problems were corrected:

-
-    
    
-      
  • The "shorewall status" command no longer hangs.
    • 
-
-      
  • The "shorewall monitor" command now displays the icmpdef
-      chain
    • 
-
-      
  • The CLIENT PORT(S) column in tcrules is no longer
-      ignored
    • 
-    

-
-    
1/18/2002 - Shorewall 1.2.2 packaged with new 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
-    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 download page.

-
-    
1/9/2002 - Updated 1.2.2 /sbin/shorewall available -
-    This corrected
-    version restores the "shorewall status" command to
-    health.

-
-    
1/8/2002 - Shorewall 1.2.2 Released

-
-    
In version 1.2.2

-
-    
    
-      
  • 
-        Support for IP blacklisting has been added 
-
-        
      
-          
    • You specify whether you want packets from blacklisted
-          hosts dropped or rejected using the BLACKLIST_DISPOSITION
-          setting in /etc/shorewall/shorewall.conf
      • 
-
-          
    • You specify whether you want packets from blacklisted
-          hosts logged and at what syslog level using the BLACKLIST_LOGLEVEL
-          setting in /etc/shorewall/shorewall.conf
      • 
-
-          
    • You list the IP addresses/subnets that you wish to
-          blacklist in /etc/shorewall/blacklist
      • 
-
-          
    • You specify the interfaces you want checked against
-          the blacklist using the new "blacklist" option in
-          /etc/shorewall/interfaces.
      • 
-
-          
    • The black list is refreshed from
-          /etc/shorewall/blacklist by the "shorewall refresh"
-          command.
      • 
-        
    
-      
    • 
-
-      
  • 
-        Use of TCP RST replies has been expanded  
-
-        
      
-          
    • TCP connection requests rejected because of a REJECT
-          policy are now replied with a TCP RST packet.
      • 
-
-          
    • TCP connection requests rejected because of a
-          protocol=all rule in /etc/shorewall/rules are now replied
-          with a TCP RST packet.
      • 
-        
    
-      
    • 
-
-      
  • A LOGFILE
-      specification has been added to
-      /etc/shorewall/shorewall.conf. LOGFILE is used to tell the
-      /sbin/shorewall program where to look for Shorewall
-      messages.
    • 
-    

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

-
-    
    
-      
  • Unless you have explicitly enabled Auth connections (tcp
-      port 113) to your firewall, these connections will be
-      REJECTED rather than DROPPED. This speeds up connection
-      establishment to some servers.
    • 
-
-      
  • Orphan DNS replies are now silently dropped.
    • 
-    

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

-
-    
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 1.2.0:

-
-    

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

-
-    
11/30/2001 - A new set of the parameterized Sample
-    Configurations has been released. In this version:

-
-    
    
-      
  • Ping is now allowed between the zones.
    • 
-
-      
  • In the three-interface configuration, it is now possible
-      to configure the internet services that are to be available
-      to servers in the DMZ. 
    • 
-    

-
-    
11/20/2001 - The current version of Shorewall is
-    1.1.18. 

-
-    
In this version:

-
-    
    
-      
  • The spelling of ADD_IP_ALIASES has been corrected in the
-      shorewall.conf file
    • 
-
-      
  • The logic for deleting user-defined chains has been
-      simplified so that it avoids a bug in the LRP version of the
-      'cut' utility.
    • 
-
-      
  • The /var/lib/lrpkg/shorwall.conf file has been corrected
-      to properly display the NAT entry in that file.
    • 
-    

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

-
-    
11/2/2001 - Announcing Shorewall Parameter-driven Sample
-    Configurations. There are three sample configurations:

-
-    
    
-      
  • One Interface -- for a standalone system.
    • 
-
-      
  • Two Interfaces -- A masquerading firewall.
    • 
-
-      
  • Three Interfaces -- A masquerading firewall with
-      DMZ.
    • 
-    

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

-
-    
In this version:

-
-    
-
-    
10/22/2001 - The current version of Shorewall is
-    1.1.16. In this version:

-
-    
    
-      
  • A new "shorewall show connections" command has been
-      added.
    • 
-
-      
  • In the "shorewall monitor" output, the currently tracked
-      connections are now shown on a separate page.
    • 
-
-      
  • Prior to this release, Shorewall unconditionally added
-      the external IP adddress(es) specified in /etc/shorewall/nat.
-      Beginning with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be set to
-      "no" (or "No") to inhibit this behavior. This allows IP
-      aliases created using your distribution's network
-      configuration tools to be used in static NAT. 
    • 
-    

-
-    
10/15/2001 - The current version of Shorewall is
-    1.1.15. In this version:

-
-    
    
-      
  • Support for nested zones has been improved. See the documentation for
-      details
    • 
-
-      
  • Shorewall now correctly checks the alternate
-      configuration directory for the 'zones' file.
    • 
-    

-
-    
10/4/2001 - The current version of Shorewall is
-    1.1.14. In this version

-
-    
    
-      
  • Shorewall now supports alternate configuration
-      directories. When an alternate directory is specified when
-      starting or restarting Shorewall (e.g., "shorewall -c
-      /etc/testconf restart"), Shorewall will first look for
-      configuration files in the alternate directory then in
-      /etc/shorewall. To create an alternate configuration
-      simply:
    
-      1. Create a New Directory
    
-      2. Copy to that directory any of your configuration files
-      that you want to change.
    
-      3. Modify the copied files as needed.
    
-      4. Restart Shorewall specifying the new directory.
    • 
-
-      
  • The rules for allowing/disallowing icmp echo-requests
-      (pings) are now moved after rules created when processing the
-      rules file. This allows you to add rules that selectively
-      allow/deny ping based on source or destination address.
    • 
-
-      
  • Rules that specify multiple client ip addresses or
-      subnets no longer cause startup failures.
    • 
-
-      
  • Zone names in the policy file are now validated against
-      the zones file.
    • 
-
-      
  • If you have packet mangling support
-      enabled, the "norfc1918" interface
-      option now logs and drops any incoming packets on the
-      interface that have an RFC 1918 destination address.
    • 
-    

-
-    
9/12/2001 - The current version of Shorewall is
-    1.1.13. In this version

-
-    
    
-      
  • Shell variables can now be used to parameterize Shorewall
-      rules.
    • 
-
-      
  • The second column in the hosts file may now contain a
-      comma-separated list.
    
-      
    
-      Example:
    
-          sea   
-      eth0:130.252.100.0/24,206.191.149.0/24
    • 
-
-      
  • Handling of multi-zone interfaces has been improved. See
-      the documentation for
-      the /etc/shorewall/interfaces file.
    • 
-    

-
-    
8/28/2001 - The current version of Shorewall is
-    1.1.12. In this version

-
-    
    
-      
  • Several columns in the rules file may now contain
-      comma-separated lists.
    • 
-
-      
  • Shorewall is now more rigorous in parsing the options in
-      /etc/shorewall/interfaces.
    • 
-
-      
  • Complementation using "!" is now supported in rules.
    • 
-    

-
-    
7/28/2001 - The current version of Shorewall is
-    1.1.11. In this version

-
-    
    
-      
  • A "shorewall refresh" command has been added to allow for
-      refreshing the rules associated with the broadcast address on
-      a dynamic interface. This command should be used in place of
-      "shorewall restart" when the internet interface's IP address
-      changes.
    • 
-
-      
  • The /etc/shorewall/start file (if any) is now processed
-      after all temporary rules have been deleted. This change
-      prevents the accidental removal of rules added during the
-      processing of that file.
    • 
-
-      
  • The "dhcp" interface option is now applicable to firewall
-      interfaces used by a DHCP server running on the
-      firewall.
    • 
-
-      
  • The RPM can now be built from the .tgz file using "rpm
-      -tb" 
    • 
-    

-
-    
7/6/2001 - The current version of Shorewall is
-    1.1.10. In this version

-
-    
    
-      
  • Shorewall now enables Ipv4 Packet Forwarding by default.
-      Packet forwarding may be disabled by specifying
-      IP_FORWARD=Off in /etc/shorewall/shorewall.conf. If you don't
-      want Shorewall to enable or disable packet forwarding, add
-      IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf
-      file.
    • 
-
-      
  • The "shorewall hits" command no longer lists extraneous
-      service names in its last report.
    • 
-
-      
  • Erroneous instructions in the comments at the head of the
-      firewall script have been corrected.
    • 
-    

-
-    
6/23/2001 - The current version of Shorewall is
-    1.1.9. In this version

-
-    
    
-      
  • The "tunnels" file really is in the RPM now.
    • 
-
-      
  • SNAT can now be applied to port-forwarded
-      connections.
    • 
-
-      
  • A bug which would cause firewall start failures in some
-      dhcp configurations has been fixed.
    • 
-
-      
  • The firewall script now issues a message if you have the
-      name of an interface in the second column in an entry in
-      /etc/shorewall/masq and that interface is not up.
    • 
-
-      
  • You can now configure Shorewall so that it doesn't require the NAT and/or
-      mangle netfilter modules.
    • 
-
-      
  • Thanks to Alex  Polishchuk, the "hits" command from
-      seawall is now in shorewall.
    • 
-
-      
  • Support for IPIP tunnels has been
-      added.
    • 
-    

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

-
-    
    
-      
  • The TOS rules are now deleted when the firewall is
-      stopped.
    • 
-
-      
  • The .rpm will now install regardless of which version of
-      iptables is installed.
    • 
-
-      
  • The .rpm will now install without iproute2 being
-      installed.
    • 
-
-      
  • The documentation has been cleaned up.
    • 
-
-      
  • The sample configuration files included in Shorewall have
-      been formatted to 80 columns for ease of editing on a VGA
-      console.
    • 
-    

-
-    
5/25/2001 - The current version of Shorewall is
-    1.1.6. In this version

-
-    
    
-      
  • You may now
-      rate-limit the packet log.
    • 
-
-      
  • Previous versions of Shorewall have an implementation of
-      Static NAT which violates the principle of least
-      surprise.  NAT only occurs for packets arriving at
-      (DNAT) or send from (SNAT) the interface named in the
-      INTERFACE column of /etc/shorewall/nat. Beginning with
-      version 1.1.6, NAT effective regardless of which interface
-      packets come from or are destined to. To get compatibility
-      with prior versions, I have added a new "ALL "ALL INTERFACES"  column to
-      /etc/shorewall/nat. By placing "no" or "No" in the new
-      column, the NAT behavior of prior versions may be
-      retained. 
    • 
-
-      
  • The treatment of IPSEC
-      Tunnels where the remote gateway is a standalone system has
-      been improved. Previously, it was necessary to include an
-      additional rule allowing UDP port 500 traffic to pass through
-      the tunnel. Shorewall will now create this rule automatically
-      when you place the name of the remote peer's zone in a new
-      GATEWAY ZONE column in /etc/shorewall/tunnels. 
    • 
-    

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

-
-    
    
-      
  • Accepting RELATED
-      connections is now optional.
    • 
-
-      
  • Corrected problem where if "shorewall start" aborted
-      early (due to kernel configuration errors for example),
-      superfluous 'sed' error messages were reported.
    • 
-
-      
  • Corrected rules generated for port redirection.
    • 
-
-      
  • The order in which iptables kernel modules are loaded has
-      been corrected (Thanks to Mark Pavlidis). 
    • 
-    

-
-    
4/28/2001 - The current version of Shorewall is
-    1.1.3. In this version

-
-    
    
-      
  • Correct message issued when Proxy ARP address added
-      (Thanks to Jason Kirtland).
    • 
-
-      
  • /tmp/shorewallpolicy-$$ is now removed if there is an
-      error while starting the firewall.
    • 
-
-      
  • /etc/shorewall/icmp.def and /etc/shorewall/common.def are
-      now used to define the icmpdef and common chains unless
-      overridden by the presence of /etc/shorewall/icmpdef or
-      /etc/shorewall/common.
    • 
-
-      
  • In the .lrp, the file /var/lib/lrpkg/shorwall.conf has
-      been corrected. An extra space after "/etc/shorwall/policy"
-      has been removed and "/etc/shorwall/rules" has been
-      added.
    • 
-
-      
  • When a sub-shell encounters a fatal error and has stopped
-      the firewall, it now kills the main shell so that the main
-      shell will not continue.
    • 
-
-      
  • A problem has been corrected where a sub-shell stopped
-      the firewall and main shell continued resulting in a
-      perplexing error message referring to "common.so"
-      resulted.
    • 
-
-      
  • Previously, placing "-" in the PORT(S) column in
-      /etc/shorewall/rules resulted in an error message during
-      start. This has been corrected.
    • 
-
-      
  • The first line of "install.sh" has been corrected -- I
-      had inadvertently deleted the initial "#".
    • 
-    

-
-    
4/12/2001 - The current version of Shorewall is
-    1.1.2. In this version

-
-    
    
-      
  • Port redirection now works again.
    • 
-
-      
  • The icmpdef and common chains may now be user-defined.
    • 
-
-      
  • The firewall no longer fails to start if "routefilter" is
-      specified for an interface that isn't started. A warning
-      message is now issued in this case.
    • 
-
-      
  • The LRP Version is renamed "shorwall" for 8,3 MSDOS file
-      system compatibility.
    • 
-
-      
  • A couple of LRP-specific problems were corrected.
    • 
-    

-
-    
4/8/2001 - Shorewall is now affiliated with the Leaf Project Leaf Logo

-
-    
4/5/2001 - The current version of Shorewall is 1.1.1. In
-    this version:

-
-    
    
-      
  • The common chain is traversed from INPUT, OUTPUT and
-      FORWARD before logging occurs
    • 
-
-      
  • The source has been cleaned up dramatically
    • 
-
-      
  • DHCP DISCOVER packets with RFC1918 source addresses no
-      longer generate log messages. Linux DHCP clients generate
-      such packets and it's annoying to see them logged. 
    • 
-    

-
-    
3/25/2001 - The current version of Shorewall is 1.1.0. In
-    this version:

-
-    
    
-      
  • Log messages now indicate the packet disposition.
    • 
-
-      
  • Error messages have been improved.
    • 
-
-      
  • The ability to define zones consisting of an enumerated
-      set of hosts and/or subnetworks has been added.
    • 
-
-      
  • The zone-to-zone chain matrix is now sparse so that only
-      those chains that contain meaningful rules are defined.
    • 
-
-      
  • 240.0.0.0/4 and 169.254.0.0/16 have been added to the
-      source subnetworks whose packets are dropped under the
-      norfc1918 interface option.
    • 
-
-      
  • Exits are now provided for executing an user-defined
-      script when a chain is defined, when the firewall is
-      initialized, when the firewall is started, when the firewall
-      is stopped and when the firewall is cleared.
    • 
-
-      
  • The Linux kernel's route filtering facility can now be
-      specified selectively on network interfaces.
    • 
-    

-
-    
3/19/2001 - The current version of Shorewall is 1.0.4.
-    This version:

-
-    
    
-      
  • Allows user-defined zones. Shorewall now has only one
-      pre-defined zone (fw) with the remaining zones being defined
-      in the new configuration file /etc/shorewall/zones. The
-      /etc/shorewall/zones file released in this version provides
-      behavior that is compatible with Shorewall 1.0.3. 
    • 
-
-      
  • Adds the ability to specify logging in entries in the
-      /etc/shorewall/rules file.
    • 
-
-      
  • Correct handling of the icmp-def chain so that only ICMP
-      packets are sent through the chain.
    • 
-
-      
  • Compresses the output of "shorewall monitor" if awk is
-      installed. Allows the command to work if awk isn't installed
-      (although it's not pretty).
    • 
-    

-
-    
3/13/2001 - The current version of Shorewall is 1.0.3.
-    This is a bug-fix release with no new features.

-
-    
    
-      
  • The PATH variable in the firewall script now includes
-      /usr/local/bin and /usr/local/sbin.
    • 
-
-      
  • DMZ-related chains are now correctly deleted if the DMZ
-      is deleted.
    • 
-
-      
  • The interface OPTIONS for "gw" interfaces are no longer
-      ignored.
    • 
-    

-
-    
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 also a .lrp available now.

+Old News here

   
 
 
diff --git a/Shorewall-Website/oldnews.html b/Shorewall-Website/oldnews.html
new file mode 100644
index 000000000..7104d6421
--- /dev/null
+++ b/Shorewall-Website/oldnews.html
@@ -0,0 +1,10992 @@
+
+
+
+  
+    
+
+     Old News 
+  
+
+  
+    05/20/2005  Shorewall CVS
+    Repository has Moved to Sourceforge

+    

+     The CVS repository may now be accessed at http://sourceforge.net/cvs/?group_id=22587.

+
+     

+     05/20/2005 Shorewall 2.2.5

+    

+     This will be my last 2.2 release. It contains a couple
+    of small bug fixes that I hadn't yet released.

+     

+     -Tom

+     

+     Problems Corrected:

+     
+
+    
    
+      
  1. Previously, if PKTTYPE=No in shorewall.conf then pkttype
+      match would still be used if the kernel supported it.
    2. 
+
+      
  2. A typo in the 'tunnel' script has been corrected (Thanks
+      to Patrik Varmecký).
    3. 
+
+      
  3. A warning is now generated if an invalid short zone name
+      is used in /etc/shorewall/zones.
    
+      
    4. 
+    

+    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:
    
+      
    
+              Error: No appropriate
+      chain for 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>
    2. 
+
+      
  2. 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>
    3. 
+    

+    New Features:

+     
+
+    
    
+      
  1. 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. 
+    

+
+    

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

+      

+
+      

+        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:

+        

+                        
+        insert_forward_rules = yes

+                        
+        prerouting_chain_name = UPnP

+                        
+        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:

+        

+                     
+        allowoutUPnP      
+        fw      loc

+        

+         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:

+        

+                     
+        allowinUPnP       
+        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 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 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.
    
+      
    
+      
    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 /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=""
    
+      
    
+      
    3. 
+
+      
  3. 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 ADDRESSES column of /etc/shorewall/masq or in the
+      DEST column of /etc/shorewall/rules).
    
+      
    
+       If you use normal SNAT then multiple connections from a
+      given local host to hosts on the internet can be assigned
+      different source IP addresses. This confuses some
+      applications that use multiple connections. To correct this
+      problem, prefix the list of address ranges in the ADDRESS
+      column with "SAME:"
    
+      
    
+                
+      Example:   SAME:206.124.146.176-206.124.146.180
    
+      
    
+       If you want each internal system to use the same IP address
+      from the list regardless of which internet host it is talking
+      to then prefix the ranges with "SAME:nodst:".
    
+      
    
+                
+      Example:  
+      SAME:nodst:206.124.146.176-206.124.146.180
    
+      
    
+       Note that it is not possible to map port numbers when using
+      SAME.
    
+      
    
+       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.
    
+      
    
+      
    4. 
+
+      
  4. A "shorewall show capabilities" command has been added to
+      report the capabilities of your kernel and iptables.
    
+      
    
+          Example:
    
+      
    
+             gateway:~# shorewall show
+      capabilities
    
+             Loading
+      /usr/share/shorewall/functions...
    
+             Processing
+      /etc/shorewall/params ...
    
+             Processing
+      /etc/shorewall/shorewall.conf...
    
+             Loading Modules...
    
+             Shorewall has detected the
+      following iptables/netfilter capabilities:
    
+                   
+      NAT: Available
    
+                   
+      Packet Mangling: Available
    
+                   
+      Multi-port Match: Available
    
+                   
+      Extended Multi-port Match: Available
    
+                   
+      Connection Tracking Match: Available
    
+                   
+      Packet Type Match: Not available
    
+                   
+      Policy Match: Available
    
+                   
+      Physdev Match: Available
    
+                   
+      IP range Match: Available
    
+                   
+      Recent Match: Available
    
+                   
+      Owner Match: Available
    
+             gateway:~#
    
+      
    
+      
    5. 
+
+      
  5. 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.
    
+      
    
+      
    6. 
+
+      
  6. 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:
    
+      
    
+       Example:
    
+      
    
+              
+      /etc/shorewall/rules:
    
+      
    
+                      
+      AllowFTP   
+      $FTP_CLIENTS        fw
    
+      
    
+               When FTP_CLIENTS
+      is set to 'none', the above rule is ignored.  Otherwise,
+      the rule is evaluated and generates Netfilter rules.
    
+      
    
+      
    7. 
+
+      
  7. The installer now detects that it is running on a
+      Slackware system and adjusts the DEST and INIT variables
+      accordingly.
    
+      
    8. 
+    

+
+    
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:

+    

+
+    
    
+      
  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 kernel lacked advanced routing support
+      (CONFIG_IP_ADVANCED_ROUTER),  then no routing
+      information was displayed.
    3. 
+    

+    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 /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'.
    
+      
    
+       Beginning with Shorewall version 2.2.3,
+      /etc/shorewall/routestopped will be processed TWICE during
+      'shorewall start' and during 'shorewall restart'. It will be
+      processed early in the command execution to add rules
+      allowing new connections while the command is running and it
+      will be processed again when the command is complete to
+      remove the rules 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.
    3. 
+
+      
  3. 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 'maclist' file lookup and thus reduce the
+      overhead associated with MAC Verification.
    
+      
    
+       When a new connection arrives from a 'maclist' interface,
+      the packet passes through then list of entries for that
+      interface in /etc/shorewall/maclist. If there is a match then
+      the source IP address is added to the 'Recent' set for that
+      interface. Subsequent connection attempts from that IP
+      address occuring within $MACLIST_TTL seconds will be accepted
+      without having to scan all of the entries. After $MACLIST_TTL
+      from the first accepted connection request from an IP
+      address, the next connection request from that IP address
+      will be 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.
    4. 
+
+      
  4. 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.
    
+      
    5. 
+    

+    03/31/2005 Shorewall
+    2.0.17

+    

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

+    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. 
+
+      
  2. 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.
    3. 
+
+      
  3. 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.
    4. 
+
+      
  4. The port numbers for UDP and TCP were previously reversed
+      in the /usr/share/shorewall/action.AllowPCA file.
    5. 
+
+      
  5. Previously, the 'install.sh' script did not update the
+      /usr/share/shorewall/action.* files.
    6. 
+
+      
  6. 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.
    
+      
    7. 
+    

+    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.
    
+      
    
+       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.
    5. 
+
+      
  5. 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
    
+      
    
+       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
    
+      
    
+       Setting RFC1918_STRICT=Yes in shorewall.conf will cause such
+      traffic to be logged and dropped since while the packet's
+      source matches the RETURN rule, the packet's destination
+      matches the 'logdrop' rule.
    
+      
    
+       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.
    
+      
    6. 
+    

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

+    

+
+    
    
+      
  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.
    
+      
    
+          Example:
    
+      
    
+                  
+      rejNotSyn:ULOG     
+      all    
+      all            
+      tcp
    
+      
    
+          produces the log message:
    
+      
    
+                  
+      Feb 12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...
    
+      
    
+          rather than
    
+      
    
+                  
+      Feb 12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...
    
+      
    
+      
    4. 
+
+      
  4. The comments regarding built-in actions in
+      /usr/share/shorewall/actions.std have been corrected.
    5. 
+
+      
  5. The /etc/shorewall/policy file in the LRP package was
+      missing the 'all->all' policy.
    
+      
    6. 
+    

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

+     

+     02/01/2005 Shorewall
+    2.0.16

+     

+     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 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
    
+      
    
+       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
    
+      
    
+       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.
    2. 
+    

+
+    
02/01/2005 Shorewall
+    2.2.0

+    

+     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
+      additional options.
    
+      
    
+       Normally MASQUERADE/SNAT rules are evaluated after
+      one-to-one NAT rules defined in the /etc/shorewall/nat file.
+      If you preceed the interface name with a plus sign ("+") then
+      the rule will be evaluated before one-to-one NAT.
    
+      
    
+       Examples:
    
+      
    
+       +eth0
    
+       +eth1:192.0.2.32/27
    
+      
    
+       Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for
+      an entry by following the interface name by ":" but no
+      digit.
    
+      
    
+       Examples:
    
+      
    
+       eth0:
    
+       eth1::192.0.2.32/27
    
+       +eth3:
    
+      
    
+      
    3. 
+
+      
  3. 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.
    4. 
+
+      
  4. 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.
    5. 
+
+      
  5. 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:
    6. 
+
+      
  6. 
+        
      
+          
    • 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 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).
      
+           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!
      
+          
      
+          
      • 
+        
    
+      
    7. 
+    

+
+    

+      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:

+      

+       /etc/shorewall/rules:

+          

+       acton:info: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:
    2. 
+
+      
  2. 
+        
      
+          
    • 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.
      
+          
      
+          
      • 
+        
    
+      
    3. 
+
+      
  3. 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:
    4. 
+
+      
  4. 
+        
      
+          
    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
      
+          
      
+           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
      
+          
      
+           /etc/shorewall/interfaces:
      
+          
      
+           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
      
+          
      
+           /etc/shorewall/interfaces:
      
+          
      
+           net   
+          eth0    ...
      
+          
      
+           /etc/shorewall/hosts:
      
+          
      
+           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
+            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
      
+            
      
+             /etc/shorewall/interfaces:
      
+            
      
+             net   
+            eth0    ...
      
+             loc   
+            eth1    ...
      
+            
      
+             /etc/shorewall/hosts:
      
+            
      
+             vpn   
+            eth0:0.0.0.0/0    ipsec,...
+          
      3. 
+        
    
+      
    5. 
+    

+
+    

+      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 available options are:

+    

+
+    

+      
    
+        
  • reqid[!]=<number> where <number> is
+        specified using setkey(8) using the 'unique:<number>'
+        option for the SPD level.
    • 
+
+        
  • spi[!]=<number> where <number> is the SPI
+        of the SA. Since different SAs are used to encrypt and
+        decrypt traffic, this option should only be listed in the
+        IN OPTIONS and OUT OPTIONS columns.
    • 
+
+        
  • proto[!]=ah|esp|ipcomp
    • 
+
+        
  • mss=<number> (sets the MSS value in TCP SYN
+        packets and is not related to policy matching)
    • 
+
+        
  • mode[!]=transport|tunnel
    • 
+
+        
  • tunnel-src[!]=<address>[/<mask>] (only
+        available with mode=tunnel)
    • 
+
+        
  • tunnel-dst[!]=<address>[/<mask>] (only
+        available with mode=tunnel). Because tunnel source and
+        destination are dependent on the direction of the traffic,
+        these options should only appear in the IN OPTIONS and OUT
+        OPTIONS columns.
    • 
+
+        
  • strict  (if specified, packets must match all
+        policies; policies are delimited by 'next').
    • 
+
+        
  • next    (only available with
+        strict)
    • 
+      

+    

+
+    

+      Examples:

+      

+       #ZONE    IPSEC 
+      OPTIONS       
+               
+      IN         
+      OUT

+       #       
+      ONLY           
+                
+           OPTIONS    
+      OPTIONS

+       vpn     
+      Yes    mode=tunnel,proto=esp   
+      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.

+    

+
+    
    
+      
  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 commands where -c was previously allowed now
+      permit you to specify a configuration directory after the
+      command:
    
+      
    
+             shorewall check   [
+      <configuration-directory> ]
    
+             shorewall restart [
+      <configuration-directory> ]
    
+             shorewall start   [
+      <configuration-directory> ]
    
+      
    
+      
    4. 
+
+      
  4. 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 port ranges ( < 512, 512-1023, and
+      > 1023). You may now specify an explicit range of source
+      ports to be used by following the address or address range
+      (if any) in the ADDRESS column with ":" and a port range in
+      the format <low-port>-<high-port>. You must
+      specify either "tcp" or "udp" in the PROTO column.
    
+      
    
+       Examples 1 -- MASQUERADE with tcp source ports
+      4000-5000:
    
+      
    
+          
+      #INTERFACE SUBNET         
+      ADDRESS        PROTO
    
+          
+      eth0       192.168.1.0/24 
+      :4000-5000     tcp
    
+      
    
+       Example 2 -- SNAT with udp source ports 7000-8000:
    
+      
    
+           #INTERFACE SUBNET   
+            ADDRESS   
+                  
+      PROTO
    
+         
+      eth0      
+      10.0.0.0/8     
+      192.0.2.44:7000-8000    udp
    
+      
    
+      
    5. 
+
+      
  5. 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.
    6. 
+
+      
  6. Shorewall now verifies that your kernel and iptables have
+      physdev match support if BRIDGING=Yes in shorewall.conf.
    7. 
+
+      
  7. 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.
    8. 
+
+      
  8. 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/     
+      SOURCE      
+      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.
    9. 
+
+      
  9. 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".
    10. 
+
+      
  10. 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".
    11. 
+
+      
  11. 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 specify a log tag will
+      substitute the tag for the chain name in the log prefix.
    
+      
    
+       Example -- file
+      /etc/shorewall/action.thisisaverylogactionname:
    
+      
    
+           Rule:
    
+      
    
+                DROP:info:ftp   
+      0.0.0.0/0    0.0.0.0/0   
+      tcp        21
    
+          
    
+           Log prefix with LOGTAGONLY=No:
    
+      
    
+                Shorewall:thisisaverylongacti
    
+
+      
    
+           Log prefix with LOGTAGONLY=Yes:
    
+      
    
+                Shorewall:ftp:DROP
    
+      
    
+      
    12. 
+
+      
  12. 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.
    13. 
+
+      
  13. 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)
    
+      
    
+      
    14. 
+
+      
  14. 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.
    15. 
+
+      
  15. 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 /etc/shorewall/shorewall.conf by
+      allowing that option to have a numeric value as well as the
+      values "Yes" and "No".
    
+      
    
+       Example:
    
+      
    
+           CLAMPMSS=1400
    
+      
    
+      
    16. 
+
+      
  16. 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":
    
+      
    
+             
+      /etc/shorewall/rules
    
+             
+      /etc/shorewall/tcrules
    
+             
+      /etc/shorewall/accounting
    
+      
    
+       When the PROTO or PROTOCOL column contains "ipp2p" then the
+      DEST PORT(S) or PORT(S) column may contain a recognized ipp2p
+      option; for a list of the options and their meaning, at a
+      root prompt:
    
+      
    
+           iptables -m ipp2p --help
    
+      
    
+       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").
    17. 
+
+      
  17. Shorewall now has support for the CONNMARK target from
+      iptables. See the /etc/shorewall/tcrules file for
+      details.
    18. 
+
+      
  18. 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.
    
+      
    
+           - The table name is used as the chain
+      name in the log prefix.
    
+           - The chain name is used as the target in
+      the log prefix.
    
+      
    
+       Example: Using the default LOGFORMAT, the log prefix for
+      logging from the nat table's PREROUTING chain is:
    
+      
    
+            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 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.
    
+      
    
+      
    19. 
+
+      
  19. 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.
    20. 
+
+      
  20. The AllowNNTP action now also allows NNTP over SSL/TLS
+      (NNTPS).
    21. 
+
+      
  21. For consistency, the CLIENT PORT(S) column in the tcrules
+      file has been renamed SOURCE PORT(S).
    22. 
+
+      
  22. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
+      now shown in the output of "shorewall status".
    23. 
+
+      
  23. 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.
    24. 
+
+      
  24. 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 #
    
+      
    
+      
    25. 
+
+      
  25. Variable expansion may now be used with the INCLUDE
+      directive.
    
+      
    
+           Example:
    
+      
    
+           /etc/shorewall/params
    
+      
    
+               FILE=/etc/foo/bar
    
+      
    
+               Any other config
+      file:
    
+      
    
+               INCLUDE $FILE
    
+      
    
+      
    26. 
+
+      
  26. The output of "shorewall status" now includes the results
+      of "ip -stat link ls". This helps diagnose performance
+      problems caused by link errors.
    27. 
+
+      
  27. 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.
    28. 
+
+      
  28. 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
    
+
+      
    
+       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
    
+
+      
    
+       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.
    
+      
    
+      
    29. 
+
+      
  29. 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
    
+      
    
+           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
    
+         
    
+      
    30. 
+
+      
  30. 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 1194
    
+          
+      openvpn:3344       
+      net    1.2.3.4    # UDP on port
+      3344
    
+          
+      openvpn:tcp:4455    net   
+      1.2.3.4    # TCP on port 4455
    
+      
    
+      
    31. 
+
+      
  31. 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:
    32. 
+    

+
+    

+      
    
+        
  • Only one instance of the script may be used at a
+        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.
    • 
+      

+    

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

+
+    
01/17/2005 - Shorewall
+    2.2.0 RC5

+    

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

+    New Features:

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

+    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:

+     
+
+    
    
+      
  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:
    
+        
    
+             Bad argument `DROP'
    
+             Try `iptables -h' or
+      'iptables --help' for more information.
    
+      
    3. 
+    

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

+    Problems Corrected.

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

+    01/03/2005 - Shorewall 2.0.14

+     

+     New Features:

+     
+
+    
    
+      
  1. 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.
    
+      
    2. 
+    

+    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. The TYPE column for an IPIP tunnel should contain
+      "ipip" rather than "ip".
    
+      
    4. 
+    

+    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/

+
+     

+     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/

+
+     

+     Thanks, Simon!

+     

+     12/30/2004 - Shorewall 2.2.0 RC3

+     

+     Problems Corrected:

+     
+
+    
    
+      
  1. The following error message could appear during
+      "shorewall stop" or "shorewall clear":
    
+                                                                                                                                                                                                                       
    
+
+                    
+      local: lo:: bad variable name
    
+      
    
+      
    2. 
+
+      
  2. The rate limiting example in /etc/shorewall/rules has
+      been changed to use the RATE LIMIT column.
    3. 
+
+      
  3. 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.
    4. 
+
+      
  4. A misleading typo in /etc/shorewall/tunnels has been
+      corrected.
    
+      
    5. 
+    

+
+    


+    

+
+    
12/24/2004 - Shorewall
+    2.2.0 RC2

+    

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

+    12/19/2004 - Shorewall 2.2.0 RC1

+    

+     Problems Corrected:

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

+    New Features:

+     
+
+    
    
+      
  1. 
+        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
+
    
+      
    2. 
+
+      
  2. 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:
    
+      
    
+           - Only one instance of the script may be
+      used at a 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.
    
+      
    3. 
+    

+    12/11/2004 - Shorewall 2.2.0 Beta 8

+    

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

+    New Features:

+     
+
+    
    
+      
  1. 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
    
+      
    
+       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
    
+      
    
+       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.
    
+      
    
+      
    2. 
+
+      
  2. 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
    
+      
    
+       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
    
+         
    
+      
    3. 
+    

+    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:
    
+        
    
+                 
+      shorewall add
+      <interface>[:<port>]:<address>
+      <zone>
    
+                 
+      shorewall delete
+      <interface>[:<port>]:<address>
+      <zone>
    
+        
    
+          Examples:
    
+        
    
+                 
+      shorewall add br0:eth2:192.168.1.3 OK
    
+                 
+      shorewall delete br0:eth2:192.168.1.3 OK
    
+      
    
+      
    2. 
+
+      
  2. 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
+      at the end of the script.
    
+      
    
+       To accomplish this change, the "restore base" file
+      (/var/lib/shorewall/restore-base) has been split into two
+      files:
    
+        
    
+       /var/lib/shorewall/restore-base -- commands to be executed
+      before Netfilter the configuration is restored.
    
+        
    
+       /var/lib/shorewall/restore-tail -- commands to be executed
+      after the Netfilter configuration is restored.
    
+      
    
+      
    3. 
+
+      
  3. 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.
    4. 
+
+      
  4. 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.
    5. 
+    

+    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).
    
+        
    
+           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 #
    
+      
    
+      
    2. 
+
+      
  2. Variable expansion may now be used with the INCLUDE
+      directive.
    
+        
    
+           Example:
    
+        
    
+              
+      /etc/shorewall/params
    
+        
    
+                  
+      FILE=/etc/foo/bar
    
+        
    
+               Any other config
+      file:
    
+        
    
+                  
+      INCLUDE $FILE
    
+      
    
+      
    3. 
+
+      
  3. The output of "shorewall status" now includes the results
+      of "ip -stat link ls". This helps diagnose performance
+      problems caused by link errors.
    4. 
+
+      
  4. 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.
    
+      
    5. 
+    

+    12/02/2004 - Shorewall 2.0.13

+    

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

+    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:
    
+        
    
+             shorewall add
+      <interface>[:<bridge port>][:<address>]
+      <zone>
    
+             shorewall delete
+      <interface>[:<bridge port>][:<address>]
+      <zone>
    
+        
    
+       Examples:
    
+        
    
+             shorewall add
+      br0:eth2:192.168.1.3 OK
    
+             shorewall delete
+      br0:eth2:192.168.1.3 OK
    
+      
    
+      
    3. 
+
+      
  3. 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
+      at the end of the script.
    
+        
    
+       To accomplish this change, the "restore base" file
+      (/var/lib/shorewall/restore-base) has been split into two
+      files:
    
+        
    
+          /var/lib/shorewall/restore-base -- commands to
+      be executed before the Netfilter configuration is
+      restored.
    
+        
    
+          /var/lib/shorewall/restore-tail -- commands to
+      be executed after the Netfilter configuration is
+      restored.
    
+      
    
+      
    4. 
+
+      
  4. 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.
    5. 
+    

+    New Features:

+     
+
+    
    
+      
  1. Variable expansion may now be used with the INCLUDE
+      directive.
    
+        
    
+       Example:
    
+        
    
+              
+      /etc/shorewall/params
    
+        
    
+                  
+      FILE=/etc/foo/bar
    
+        
    
+               Any other config
+      file:
    
+        
    
+                  
+      INCLUDE $FILE
    
+      
    2. 
+    

+    11/26/2004 - Shorewall 2.2.0 Beta 6

+    

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

+     

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

+    11/26/2004 - Shorewall 2.2.0 Beta 5

+     

+     Problems corrected:

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

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

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

+    New Features:

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

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

+    New Features:

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

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

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

+    11/02/2004 - Shorewall 2.2.0 Beta 2

+    

+     Problems Corrected:

+     
+
+    
    
+      
  1. The "shorewall check" command results in the (harmless)
+      error message:
    
+        
    
+              
+      /usr/share/shorewall/firewall: line 2753:
    
+                 
+      check_dupliate_zones: command not found
    
+      
    
+      
    2. 
+
+      
  2. The AllowNTP standard action now allows outgoing
+      responses to broadcasts.
    3. 
+
+      
  3. 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.
    4. 
+    

+    New Features:

+     
+
+    
    
+      
  1. 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.
    
+      
    2. 
+    

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

+    New Features:

+     
+
+    
    
+      
  1. The "shorewall status" command has been enhanced to
+      include the values of key /proc settings:
    
+      
    
+       Example from a two-interface firewall:
    
+      
    
+       /proc
    
+      
    
+          /proc/sys/net/ipv4/ip_forward = 1
    
+          /proc/sys/net/ipv4/conf/all/proxy_arp = 0
    
+          /proc/sys/net/ipv4/conf/all/arp_filter = 0
    
+          /proc/sys/net/ipv4/conf/all/rp_filter = 0
    
+          /proc/sys/net/ipv4/conf/default/proxy_arp =
+      0
    
+          /proc/sys/net/ipv4/conf/default/arp_filter =
+      0
    
+          /proc/sys/net/ipv4/conf/default/rp_filter =
+      0
    
+          /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
    
+          /proc/sys/net/ipv4/conf/eth0/arp_filter = 0
    
+          /proc/sys/net/ipv4/conf/eth0/rp_filter = 0
    
+          /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0
    
+          /proc/sys/net/ipv4/conf/eth1/arp_filter = 0
    
+          /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
    
+      
    2. 
+    

+    

+     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

+
+    

+
+    
The features available in this release and the migration
+    considerations are covered in the 
+    release 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. 
+    

+
+    
9/23/2004 - Shorewall 2.0.9

+    

+     Problems Corrected:

+    

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

+    New Features:

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

+
+    
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:

+
+    
    
+      
  1. 
+        
    Entries in the USER/GROUP column of an action file (made
+        from action.template) may be ignored or cause odd
+        errors.
    
+      
    2. 
+    

+
+    
7/29/2004 - Shorewall 2.0.7

+    

+     Problems Corrected:

+
+    
    
+      
  1. 
+        
    The PKTTYPE option
+        introduced in version 2.0.6 is now used when generating
+        rules to REJECT packets. Broadcast packets are silently
+        dropped rather than being rejected with an ICMP (which is a
+        protocol violation) and users whose kernels have broken
+        packet type match support are likely to see messages
+        reporting this violation. Setting PKTTYPE=No should cause
+        these messages to cease.
    
+      
    2. 
+
+      
  2. 
+        
    Multiple interfaces with the
+        'blacklist' option no longer result in an error message at
+        startup.
    
+      
    3. 
+
+      
  3. 
+        
    The following has been added to
+        /etc/shorewall/bogons:
    
+        
    
+                0.0.0.0  
+        RETURN
    
+        
    
+         This prevents the 'nobogons' option from logging DHCP
+        'DISCOVER' broadcasts.
    
+      
    4. 
+    

+
+    
New Features:

+
+    
    
+      
  1. 
+        
    To improve supportability, the "shorewall status"
+        command now includes IP and Route configuration
+        information.
    
+        
    
+            Example:
    
+        
    
+            IP
+        Configuration
    
+        
    
+            1: lo:
+        <LOOPBACK,UP> mtu 16436 qdisc noqueue
    
+               link/loopback 00:00:00:00:00:00 brd
+        00:00:00:00:00:00
    
+               inet
+        127.0.0.1/8 brd 127.255.255.255 scope host lo
    
+               inet6 ::1/128 scope host
    
+            2: eth0:
+        <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
+        pfifo_fast qlen 1000
    
+               link/ether 00:a0:c9:15:39:78 brd
+        ff:ff:ff:ff:ff:ff
    
+               inet6 fe80::2a0:c9ff:fe15:3978/64 scope
+        link
    
+            3: eth1:
+        <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
+        pfifo_fast qlen 1000
    
+               link/ether 00:a0:c9:a7:d7:bf brd
+        ff:ff:ff:ff:ff:ff
    
+               inet6 fe80::2a0:c9ff:fea7:d7bf/64 scope
+        link
    
+            5: sit0@NONE:
+        <NOARP> mtu 1480 qdisc noop
    
+               link/sit 0.0.0.0 brd 0.0.0.0
    
+            6: eth2:
+        <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
+        pfifo_fast qlen 1000
    
+               link/ether 00:40:d0:07:3a:1b brd
+        ff:ff:ff:ff:ff:ff
    
+               inet6 fe80::240:d0ff:fe07:3a1b/64 scope
+        link
    
+            7: br0:
+        <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc
+        noqueue
    
+               link/ether 00:40:d0:07:3a:1b brd
+        ff:ff:ff:ff:ff:ff
    
+               inet
+        192.168.1.3/24 brd 192.168.1.255 scope global
+        br0
    
+               inet6 fe80::240:d0ff:fe07:3a1b/64 scope
+        link
    
+        
    
+            Routing
+        Rules
    
+        
    
+            0:      from all
+        lookup local
    
+            32765:  from all
+        fwmark       ca lookup
+        www.out
    
+            32766:  from all
+        lookup main
    
+            32767:  from all
+        lookup default
    
+        
    
+            Table
+        local:
    
+        
    
+            broadcast 192.168.1.0
+        dev br0  proto kernel  scope link  src
+        192.168.1.3
    
+            broadcast
+        127.255.255.255 dev lo  proto kernel  scope
+        link  src 127.0.0.1
    
+            local 192.168.1.3 dev
+        br0  proto kernel  scope host  src
+        192.168.1.3
    
+            broadcast
+        192.168.1.255 dev br0  proto kernel  scope
+        link  src 192.168.1.3
    
+            broadcast 127.0.0.0
+        dev lo  proto kernel  scope link  src
+        127.0.0.1
    
+            local 127.0.0.1 dev
+        lo  proto kernel  scope host  src
+        127.0.0.1
    
+            local 127.0.0.0/8 dev
+        lo  proto kernel  scope host  src
+        127.0.0.1
    
+        
    
+            Table
+        www.out:
    
+        
    
+            default via
+        192.168.1.3 dev br0
    
+        
    
+            Table main:
    
+        
    
+            192.168.1.0/24 dev
+        br0  proto kernel  scope link  src
+        192.168.1.3
    
+            default via
+        192.168.1.254 dev br0
    
+        
    
+            Table
+        default:
    
+      
    2. 
+    

+
+    
7/16/2004 - Shorewall 2.0.6

+    

+     Problems Corrected:

+
+    
    
+      
  • 
+        
    Some users have reported the
+        packet type match option in iptables/Netfilter failing to
+        match certain broadcast packets. The result is that the
+        firewall log shows a lot of broadcast packets.
    
+        
    
+         Other users have complained of the following message when
+        starting Shorewall:
    
+        
    
+                    
+        modprobe: cant locate module ipt_pkttype
    
+        
    
+         Users experiencing either of these problems can use
+        PKTTYPE=No in shorewall.conf to cause Shorewall to use IP
+        address filtering of broadcasts rather than packet
+        type.
    
+      
    • 
+
+      
  • 
+        
    The shorewall.conf and zones
+        file are no longer given execute permission by the
+        installer script.
    
+      
    • 
+
+      
  • 
+        
    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.
    
+      
    • 
+    

+
+    
7/10/2004 - Shorewall 2.0.5

+    

+     Problems Corrected:

+
+    
    
+      
  • 
+        
    If DISABLE_IPV6=Yes in
+        shorewall.conf then harmless error messages referring to
+        $RESTOREBASE are generated during shorewall
+        stop.
    
+      
    • 
+
+      
  • 
+        
    An anachronistic comment concerning a mangle option has
+        been removed from shorewall.conf.
    
+      
    • 
+    

+
+    
7/06/2004 - Shorewall 2.0.4

+    

+     Problems Corrected:

+
+    
    
+      
  • 
+        
    Rules with $FW as the source zone and that specify
+        logging can cause "shorewall start" to fail.
    
+      
    • 
+    

+
+    
7/03/2004 - New Shorewall
+    Release Model

+    

+     Effective today, Shorewall is adopting a new release model
+    which takes ideas from the one used in the Linux Kernel and
+    from the release model for Postfix.

+
+    
    
+      
  1. 
+        
    Releases continue to have a
+        three-level identification x.y.z (e.g., 2.0.3).
    
+      
    2. 
+
+      
  2. 
+        
    The first two levels
+        (x.y) designate the Major Release Number
+        (e.g., 2.0)
    
+      
    3. 
+
+      
  3. 
+        
    The third level (z)
+        designates the Minor Release Number.
    
+      
    4. 
+
+      
  4. 
+        
    Even numbered major releases
+        (e.g., 1.4, 2.0, 2.2, ...) are Stable
+        Releases. No new features are added to stable releases
+        and new minor releases of a stable release will only
+        contain bug fixes. Installing a new minor release for the
+        major release that you are currently running involves no
+        migration issues (for example, if you are running 1.4.10
+        and I release 1.4.11, your current configuration is 100%
+        compatible with the new release).
    
+      
    5. 
+
+      
  5. 
+        
    Support is available through
+        the Mailing List
+        for the two most recent Stable Releases.
    
+      
    6. 
+
+      
  6. 
+        
    Odd numbered major releases
+        (e.g., 2.1, 2.3, ...) are Development Releases.
+        Development releases are where new functionality is
+        introduced. Documentation for new features will be
+        available but it may not be up to the standards of the
+        stable release documentation. Sites running Development
+        Releases should be prepared to play an active role in
+        testing new features. Bug fixes and problem resolution for
+        the development release take a back seat to support of the
+        stable releases. Problem reports for the current
+        development release should be sent to the Shorewall
+        Development Mailing List.
    
+      
    7. 
+
+      
  7. 
+        
    When the level of
+        functionality of the current development release is judged
+        adaquate, the Beta period for a new Stable release will
+        begin. Beta releases have identifications of the form
+        x.y.0-BetaN where x.y is the number of the
+        next Stable Release and N=1,2,3... . Betas are
+        expected to occur rougly once per year. Beta releases may
+        contain new functionality not present in the previous beta
+        release (e.g., 2.2.0-Beta4 may contain functionality not
+        present in 2.2.0-Beta3). When I'm confident that the
+        current Beta release is stable, I will release the first
+        Release Candidate. Release candidates have
+        identifications of the form x.y.0-RCn where
+        x.y is the number of the next Stable Release and
+        n=1,2,3... . Release candidates contain no new
+        functionailty -- they only contain bug fixes. When the
+        stability of the current release candidate is judged to be
+        sufficient then that release candidate will be released as
+        the new stable release (e.g., 2.2.0). At that time, the new
+        stable release and the prior stable release are those that
+        are supported.
    
+      
    8. 
+
+      
  8. 
+        
    What does it mean for a
+        major release to be supported? It means that I will
+        answer questions about the release and that if a bug is
+        found, I will fix the bug and include the fix in the next
+        minor release.
    
+      
    9. 
+
+      
  9. 
+        
    Between minor releases, bug fixes will continue to be
+        made available through the Errata page for each major
+        release.
    
+      
    10. 
+    

+
+    
The immediate implications of this change are as
+    follows:

+
+    
    
+      
  1. 
+        
    The functionality of the 2.0
+        major release is frozen at the level of minor release
+        2.0.3.
    
+      
    2. 
+
+      
  2. 
+        
    The two major releases
+        currently supported are 1.4 and 2.0.
    
+      
    3. 
+
+      
  3. 
+        
    I will be opening the 2.1
+        development release shortly with the release of 2.1.0.
    
+      
    4. 
+
+      
  4. 
+        
    Bug-fix releases with identifications of the form
+        x.y.zX where X=a,b,c,... (e.g., 2.0.3c) will not be
+        seen in the future.
    
+      
    5. 
+    

+
+    
7/02/2004 - Shorewall 2.0.3c

+    

+     Problems Corrected:

+
+    
    
+      
  1. 
+        
    Error messages regarding
+        $RESTOREBASE occur during shorewall stop
    
+      
    2. 
+
+      
  2. 
+        
    If CLEAR_TC=Yes in shorewall.conf, shorewall
+        stop fails without removing the lock file.
    
+      
    3. 
+    

+
+    


+     6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g

+    

+     Problems Corrected:

+
+    
    
+      
  1. 
+        
    The security vulnerability
+        fix released in Shorewall 2.0.3a failed under Slackware
+        9.1.
    
+      
    2. 
+
+      
  2. 
+        
    The security vulnerability fix released in Shorewall
+        2.0.3a failed if mktemp was not installed.
    
+      
    3. 
+    

+
+    
6/28/2004 - Shorewall 2.0.3a and
+    Shorewall 1.4.10f

+    

+     Problems Corrected:

+
+    
    
+      
  1. 
+        
    Javier Fernández-Sanguino
+        Peña has discovered an exploitable vulnerability in the way
+        that Shorewall handles temporary files and directories. The
+        vulnerability can allow a non-root user to cause arbitrary
+        files on the system to be overwritten. LEAF Bering and
+        Bering uClibc users are generally not at risk due to the
+        fact that LEAF boxes do not typically allow logins by
+        non-root users.
    
+      
    2. 
+
+      
  2. 
+        
    (2.0.3a only) A non-empty DEST entry in
+        /etc/shorewall/tcrules will generate an error and Shorewall
+        fails to start.
    
+      
    3. 
+    

+
+    
Note:: Slackware users may need
+    the '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).

+
+    
6/23/2004 - Shorewall 2.0.3

+    

+     Problems Corrected:

+
+    
    
+      
  1. 
+        
    The 'firewall' script is not
+        purging temporary restore files in /var/lib/shorewall.
+        These files have names of the form "restore-nnnnn".
    
+      
    2. 
+
+      
  2. 
+        
    The
+        /var/lib/shorewall/restore script did not load the kernel
+        modules specified in /etc/shorewall/modules.
    
+      
    3. 
+
+      
  3. 
+        
    Specifying a null common
+        action in /etc/shorewall/actions (e.g., :REJECT) results in
+        a startup error.
    
+      
    4. 
+
+      
  4. 
+        
    If /var/lib/shorewall does
+        not exist, shorewall start fails.
    
+      
    5. 
+
+      
  5. 
+        
    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.
    
+      
    6. 
+
+      
  6. 
+        
    The install.sh script
+        reported installing some files in /etc/shorewall when the
+        files were actually installed in /usr/share/shorewall.
    
+      
    7. 
+
+      
  7. 
+        
    Shorewall checks netfilter
+        capabilities before loading kernel modules. Hence if kernel
+        module autoloading isn't enabled, the capabilities will be
+        misdetected.
    
+      
    8. 
+
+      
  8. 
+        
    The 'newnotsyn' option in
+        /etc/shorewall/hosts has no effect.
    
+      
    9. 
+
+      
  9. 
+        
    The file
+        /etc/init.d/shorewall now gets proper ownership when the
+        RPM is built by a non-root user.
    
+      
    10. 
+
+      
  10. 
+        
    Rules that specify bridge
+        ports in both the SOURCE and DEST columns no longer cause
+        "shorewall start" to fail.
    
+      
    11. 
+
+      
  11. 
+        
    Comments in the rules file
+        have been added to advise users that "all" in the SOURCE or
+        DEST column does not affect intra-zone traffic.
    
+      
    12. 
+
+      
  12. 
+        
    With BLACKLISTNEWONLY=Yes, ICMP packets with state
+        INVALID are now passed through the blacklisting chains.
+        Without this change, it is not possible to blacklist hosts
+        that are mounting certain types of ICMP-based DOS
+        attacks.
    
+      
    13. 
+    

+
+    
Issues when migrating from Shorewall 2.0.2 to Shorewall
+    2.0.3:

+
+    
    
+      
  1. 
+        
    The 'dropNonSyn' standard builtin action has been
+        replaced with the 'dropNotSyn' standard builtin action. The
+        old name can still be used but will generate a warning.
    
+      
    2. 
+    

+
+    
New Features:

+
+    
    
+      
  1. 
+        
    Shorewall now supports
+        multiple saved configurations.
    
+
+        
      
+          
    1. 
+            
      The default saved
+            configuration (restore script) in /var/lib/shorewall is
+            now specified using the RESTOREFILE option in
+            shorewall.conf. If this variable isn't set then to
+            maintain backward compatibility, 'restore' is
+            assumed.
      
+            
      
+             The value of RESTOREFILE must be a simple file name;
+            no slashes ("/") may be included.
      
+          
      2. 
+
+          
    2. 
+            
      The "save" command has
+            been extended to be able to specify the name of a saved
+            configuration.
      
+            
      
+                       
+            shorewall save [ <file name> ]
      
+            
      
+             The current state is saved to
+            /var/lib/shorewall/<file name>. If no <file
+            name> is given, the configuration is saved to the
+            file determined by the RESTOREFILE setting.
      
+          
      3. 
+
+          
    3. 
+            
      The "restore" command
+            has been extended to be able to specify the name of a
+            saved configuration:
      
+            
      
+                      
+            shorewall restore [ <file name> ]
      
+            
      
+             The firewall state is restored from
+            /var/lib/shorewall/<file name>. If no <file
+            name> is given, the firewall state is restored from
+            the file determined by the RESTOREFILE setting.
      
+          
      4. 
+
+          
    4. 
+            
      The "forget" command has
+            changed. Previously, the command unconditionally
+            removed the /var/lib/shorewall/save file which records
+            the current dynamic blacklist. The "forget" command now
+            leaves that file alone.
      
+            
      
+             Also, the "forget" command has been extended to be
+            able to specify the name of a saved configuration:
      
+            
      
+                          
+            shorewall forget [ <file name> ]
      
+            
      
+             The file /var/lib/shorewall/<file name> is
+            removed. If no <file name> is given, the file
+            determined by the RESTOREFILE setting is removed.
      
+          
      5. 
+
+          
    5. 
+            
      The "shorewall -f start"
+            command restores the state from the file determined by
+            the RESTOREFILE setting.
      
+          
      6. 
+        
    
+      
    2. 
+
+      
  2. 
+        
    "!" is now allowed in
+        accounting rules.
    
+      
    3. 
+
+      
  3. 
+        
    Interface names appearing
+        within the configuration are now verified. Interface names
+        must match the name of an entry in
+        /etc/shorewall/interfaces (or if bridging is enabled, they
+        must match the name of an entry in
+        /etc/shorewall/interfaces or the name of a bridge port
+        appearing in /etc/shorewall/hosts).
    
+      
    4. 
+
+      
  4. 
+        
    A new 'rejNotSyn' built-in
+        standard action has been added. This action responds to
+        "New not SYN" packets with an RST.
    
+        
    
+         The 'dropNonSyn' action has been superceded by the new
+        'dropNotSyn' action. The old name will be accepted until
+        the next major release of Shorewall but will generate a
+        warning.
    
+        
    
+         Several new logging actions involving "New not SYN"
+        packets have been added:
    
+        
    
+                
+        logNewNotSyn  -- logs the packet with disposition =
+        LOG
    
+                 dLogNewNotSyn
+        -- logs the packet with disposition = DROP
    
+                 rLogNewNotSyn
+        -- logs the packet with disposition = REJECT
    
+        
    
+         The packets are logged at the log level specified in the
+        LOGNEWNOTSYN option in shorewall.conf. If than option is
+        empty or not specified, then 'info' is assumed.
    
+        
    
+         Examples (In all cases, set NEWNOTSYN=Yes in
+        shorewall.conf):
    
+
+        
      
+          
    1. 
+            
      To simulate the behavior
+            of NEWNOTSYN=No:
      
+
+            
        
+              
      1. 
+                
        Add 'NoNewNotSyn' to
+                /etc/shorewall/actions.
        
+              
        2. 
+
+              
      2. 
+                
        Create /etc/shorewall/action.NoNewNotSyn
+                containing:
        
+                
        
+                            
+                dLogNotSyn
        
+                            
+                dropNotSyn
        
+              
        3. 
+
+              
      3. 
+                
        Early in your rules file, place:
        
+                
        
+                         
+                NoNewNotSyn   all  
+                all     tcp
        
+              
        4. 
+            
      
+          
      2. 
+
+          
    2. 
+            
      Drop 'New not SYN'
+            packets from the net only. Don't log them:
      
+
+            
        
+              
      1. 
+                
        Early in your rules file, place:
        
+                
        
+                         
+                dropNotSyn   
+                net       
+                all   tcp
        
+              
        2. 
+            
      
+          
      3. 
+        
    
+      
    5. 
+
+      
  5. 
+        
    Slackware users no longer have to modify the install.sh
+        script before installation. Tuomo Soini has provided a
+        change that allows the INIT and FIREWALL variables to be
+        specified outside the script as in:
    
+        
    
+               DEST=/etc/rc.d
+        INIT=rc.firewall ./install.sh
    
+      
    6. 
+    

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

+
+    
6/2/2004 - Shorewall 2.0.2e

+    

+
+    
One problem corrected:

+    

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

+
+    
5/28/2004 - Shorewall 2.0.2d

+    

+     One problem corrected:

+    

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

+
+    
5/21/2004 - Shorewall 2.0.2c

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

+
+    
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:
    
+      
    
+           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. 
+    

+
+    
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
+      (/usr/share/shorewall/wait4ifup). That file is not part of
+      the normal Shorewall distribution and is provided by the
+      Debian maintainer.
    2. 
+
+      
  2. A meaningless warning message out of the proxyarp file
+      processing has been eliminated.
    3. 
+
+      
  3. The "shorewall delete" command now correctly removes all
+      dynamic rules pertaining to the host(s) being deleted. Thanks
+      to Stefan Engel for this correction.
    4. 
+    

+    Issues when migrating from Shorewall 2.0.1 to Shorewall
+    2.0.2:

+     
+
+    
    
+      
  1. 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 iptables then those commands
+      must also be written to the restore file (a temporary file in
+      /var/lib/shorewall that is renamed
+      /var/lib/shorewall/restore-base at the end of the
+      operation).
    
+      
    
+       The following functions should be of help:
    
+      
    
+       A. save_command() -- saves the passed command to the restore
+      file.
    
+      
    
+           Example:
    
+      
    
+               save_command echo
+      Operation Complete
    
+      
    
+          That command would simply write "echo Operation
+      Complete" to the restore file.
    
+      
    
+       B. run_and_save_command() -- saves the passed command to the
+      restore file then executes it. The return value is the exit
+      status of the command.
    
+      
    
+           Example:
    
+      
    
+              run_and_save_command
+      "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"
    
+      
    
+           Note that as in this example, when the
+      command involves file redirection then the entire command
+      must be enclosed in 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.
    
+      
    
+      
    2. 
+
+      
  2. 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.
    3. 
+    

+    New Features:

+     
+
+    
    
+      
  1. 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:
    
+      
    
+       a) The 'shorewall save' command now saves the current
+      configuration in addition to the current dynamic blacklist.
+      If you have dynamic zones, you will want to issue 'shorewall
+      save' when the zones are empty or the current contents of the
+      zones will be restored by the 'shorewall restore' and
+      'shorewall -f start' commands.
    
+      
    
+       b) The 'shorewall restore' command has been added. This
+      command restores the configuration at the time of the last
+      'save'.
    
+      
    
+       c) The -f (fast) option has been added to 'shorewall start'.
+      When specified (e.g. 'shorewall -f start'), shorewall will
+      perform a 'shorewall restore' if there is a saved
+      configuration. If there is no saved configuration, a normal
+      'shorewall start' is performed.
    
+      
    
+       d) The /etc/init.d/shorewall script now translates the
+      'start' command into 'shorewall -f start' so that fast
+      restart is possible.
    
+      
    
+       e) When a state-changing command encounters an error and
+      there is current saved configuration, that configuration will
+      be restored (currently, the firewall is placed in the
+      'stopped' state).
    
+      
    
+       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.
    
+      
    
+      
    2. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+       b) /etc/shorewall
    
+       c) /usr/share/shorewall
    
+      
    
+       In this release, the CONFIG_PATH option is added to
+      shorewall.conf. CONFIG_PATH contains a list of directory
+      names separated by colons (":"). If not set or set to a null
+      value (e.g., CONFIG_PATH="") then
+      "CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
+      Now Shorewall searches for shorewall.conf according to the
+      old rules and for other configuration files as follows:
    
+      
    
+       a) The directory specified in a 'try' command or specified
+      using the -c option.
    
+       b) Each directory in $CONFIG_PATH is searched in
+      sequence.
    
+      
    
+       In case it is not obvious, your CONFIG_PATH should include
+      /usr/share/shorewall and your shorewall.conf file must be in
+      the directory specified via -c or in a try command, in
+      /etc/shorewall or in /usr/share/shorewall.
    
+      
    
+       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.
    
+      
    
+      
    4. 
+
+      
  4. 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.
    
+      
    
+      
    5. 
+
+      
  5. 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".
    
+      
    
+      
    6. 
+
+      
  6. An updated bogons file is included in this release.
    
+      
    
+      
    7. 
+
+      
  7. 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 log tag.
    
+      
    
+       Example:
    
+      
    
+               ACCEPT:info:ftp
+      net     dmz    
+      tcp     21
    
+      
    
+       The log tag is appended to the log prefix generated by the
+      LOGPREFIX variable in /etc/shorewall/conf. If "ACCEPT:info"
+      generates the log 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.
    
+      
    
+      
    8. 
+
+      
  8. 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).
    
+      
    
+      
    9. 
+
+      
  9. Shorewall now uses 'modprobe' to load kernel modules if
+      that utility is available in the PATH; otherwise, 'insmod' is
+      used.
    
+      
    
+      
    10. 
+
+      
  10. 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.
    
+      
    
+       Example:
    
+      
    
+       You want all outgoing SMTP traffic entering the firewall on
+      eth1 to be sent from eth0 with source IP address
+      206.124.146.177. You want all other outgoing traffic from
+      eth1 to be sent from eth0 with source IP address
+      206.124.146.176.
    
+      
    
+              
+      eth0    eth1    206.124.146.177
+      tcp     25
    
+              
+      eth0    eth1   
+      206.124.146.176
    
+      
    
+       THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
    
+      
    
+       Assuming that 10.0.0.0/8 is the only host/network connected
+      to eth1, the progress message at "shorewall start" would
+      be:
    
+      
    
+           Masqueraded Networks and Hosts:
    
+              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
    
+      
    
+      
    11. 
+
+      
  11. 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.
    
+      
    
+      
    12. 
+
+      
  12. 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).
    
+      
    
+      
    13. 
+
+      
  13. 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.
    14. 
+    

+
+    
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

+     

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

+    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.
    
+      
    
+       The rfc1918 file released with Shorewall now contains
+      entries for only those three address ranges reserved by RFC
+      1918. A 'nobogons' interface option has been added which
+      handles bogon source addresses (those which are reserved by
+      the IANA, those reserved for DHCP auto-configuration and the
+      class C test-net reserved for testing and documentation
+      examples). This will allow users to perform RFC 1918
+      filtering without having to deal with out of date data from
+      IANA. Those who are willing to update their
+      /usr/share/shorewall/bogons file regularly can specify the
+      'nobogons' option in addition to 'norfc1918'.
    
+      
    
+       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.
    2. 
+    

+    New Features:

+     

+     
+
+    
    
+      
  1. Support for Bridging Firewalls has been added. For
+      details, see
    
+      
    
+       http://shorewall.net/bridge.html
    
+
+      
    
+      
    2. 
+
+      
  2. Support for NETMAP has been added. NETMAP allows NAT to
+      be defined between two network:
    
+      
    
+                 
+      a.b.c.1    -> x.y.z.1
    
+                 
+      a.b.c.2    -> x.y.z.2
    
+                 
+      a.b.c.3    -> x.y.z.3
    
+                 
+      ...
    
+      
    
+         http://shorewall.net/netmap.htm
    
+
+      
    
+      
    3. 
+
+      
  3. 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:
    
+      
    
+                  
+      shorewall -x show [ <chain>[ <chain> ...] ]
    
+                  
+      shorewall -x show tos|mangle
    
+                  
+      shorewall -x show nat
    
+                  
+      shorewall -x status
    
+                  
+      shorewall -x monitor [ <interval> ]
    
+      
    
+      
    4. 
+
+      
  4. 
+        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.
      
+          
      
+          
      • 
+        
    
+      
    5. 
+
+      
  5. 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
    
+      
    
+      
    6. 
+
+      
  6. To support bridging, the following options have been
+      added to entries in /etc/shorewall/hosts:
    
+      
    
+                 
+      norfc1918
    
+                 
+      nobogons
    
+                 
+      blacklist
    
+                 
+      tcpflags
    
+                 
+      nosmurfs
    
+                 
+      newnotsyn
    
+      
    
+       With the exception of 'newnotsyn', these options are only
+      useful when the entry refers to a bridge port.
    
+      
    
+          Example:
    
+      
    
+          #ZONE  
+      HOST(S)      OPTIONS
    
+          net    
+      br0:eth0    
+      norfc1918,nobogons,blacklist,tcpflags,nosmurfs
    7. 
+    

+
+    
3/14/2004 - Shorewall 2.0.0b 

+    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
+      /etc/shorewall/nat is documented as 'No' but the default
+      continued to be 'Yes' as it was in Shorewall 1.4.
    
+      
    3. 
+    

+
+    
3/14/2004 - Shorewall 2.0.0a 

+
+    
Corrects one problem:

+    

+
+    
    
+      
  • Rules of the form:
    
+      
    
+       <action>    
+      zone1      zone2
    
+      
    
+       generated a warning stating that the rule was a policy.
    
+      
    • 
+    

+
+    
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

+    

+
+    
    
+      
  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:
    
+      
    
+       DNAT  z1!z2,z3      
+      z4...
    
+      
    6. 
+    

+
+    
Problems Corrected since RC2

+    

+    

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

+
+    
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:
    
+       /etc/shorewall/common.def
    
+       /etc/shorewall/common
    
+       /etc/shorewall/icmpdef
    
+       /etc/shorewall/action.template (Moved to
+      /usr/share/shorewall)
    
+       /etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).
    
+      
    
+       The /etc/shorewall/action file now allows an action to be
+      designated as the "common" action for a particular policy
+      type by following the action name with ":" and the policy
+      (DROP, REJECT or ACCEPT).
    
+      
    
+       The file /usr/share/shorewall/actions.std has been added to
+      define those actions that are released as part of Shorewall.
+      In that file are two actions as follows:
    
+      
    
+           Drop:DROP
    
+          Reject:REJECT
    
+      
    
+       The "Drop" action is the common action for DROP policies
+      while the "Reject" action is the default action for "REJECT"
+      policies. These actions will be performed on packets prior to
+      applying the DROP or REJECT policy respectively. In the first
+      release, the difference between "Reject" and "Drop" is that
+      "Reject" REJECTs SMB traffic while "Drop" silently drops such
+      traffic.
    
+      
    
+       As described above, Shorewall allows a common action for
+      ACCEPT policies but does not specify such an action in the
+      default configuration.
    
+      
    
+       If for some reason, you don't wish to have a common DROP or
+      REJECT action, just include :DROP or :REJECT respectively in
+      your /etc/shorewall/actions file.
    
+      
    
+       The file /usr/share/shorewall/actions.std catalogs the
+      standard actions and is processed prior to
+      /etc/shorewall/actions. This causes a large number of actions
+      to be defined. The files which define these aactions are also
+      located in /usr/share/shorewall as is the he action template
+      file (action.template).
    
+      
    
+       These actions may be used in the ACTION column of the rules
+      column. So for example, to allow FTP from your loc zone to
+      your firewall, you would place this rule in
+      /etc/shorewall/rules:
    
+      
    
+         #ACTION    
+      SOURCE       DEST
    
+         AllowFTP    
+      loc          
+              fw
    
+      
    
+       If you want to redefine any of the Shorewall-defined
+      actions, simply copy the appropriate action file from
+      /usr/share/shorewall to /etc/shorewall and modify the copy as
+      desired. Your modified copy will be used rather than the
+      original one in /usr/share/shorewall.
    
+      
    
+       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.
    
+      
    
+      
    5. 
+
+      
  5. 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 name/id in the final column just like in the rules
+      file (see below). It is thus possible to create actions that
+      control traffic from a list of users and/or groups.
    
+      
    
+       The last column in /etc/shorewall/rules is now labeled
+      USER/GROUP and may contain:
    
+      
    
+           [!]<user number>[:]
    
+           [!]<user name>[:]
    
+           [!]:<group number>
    
+           [!]:<group name>
    
+           [!]<user number>:<group
+      number>
    
+           [!]<user number>:<group
+      name>
    
+           [!]<user name>:<group
+      number>
    
+           [!]<user name>:<group
+      name>
    
+        
    
+      
    6. 
+
+      
  6. It is no longer possible to specify rate limiting in the
+      ACTION column of /etc/shorewall/rules -- you must use the
+      RATE LIMIT column.
    
+      
    
+      
    7. 
+
+      
  7. 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.
    8. 
+    

+
+    
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
+      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.
    
+      
    
+      
    6. 
+
+      
  6. 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).
    7. 
+
+      
  7. 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".
    8. 
+
+      
  8. 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.
    9. 
+    

+
+    
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:

+    

+
+    
    
+      
  • In the /etc/shorewall/masq entry “eth0:!10.1.1.150    0.0.0.0/0!10.1.0.0/16
+          10.1.2.16”, the “!10.1.0.0/16” is ignored.
    • 
+    

+
+    
2/8/2004 - Shorewall 1.4.10a 

+
+    
Corrects two problems:

+    

+
+    
    
+      
  • A problem which can cause [re]start to fail inexplicably
+      while processing /etc/shorewall/masq.
    • 
+
+      
  • Interfaces using the Atheros WiFi card to use the
+      'maclist' option.
    • 
+    

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

+    Migragion Issues:

+     

+         None.

+     

+     New Features:

+     
+
+    
    
+      
  1. The INTERFACE column in the /etc/shorewall/masq file may
+      now specify a destination list.
    
+      
    
+       Example:
    
+      
    
+           #INTERFACE   
+             
+      SUBNET        ADDRESS
    
+          
+      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.
    
+      
    
+      
    2. 
+
+      
  2. 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 :
    
+      
    
+             [<user name or
+      number>]:[<group name or number>]
    
+      
    
+       The colon is optionnal when specifying only a user.
    
+      
    
+              Examples : john: / john
+      / :users / john:users
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+      
    
+        WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
+      INTERFACE!   
    4. 
+    

+
+    
1/27/2004 - Shorewall 1.4.10 RC3

+
+    
http://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. 
+    

+    Migragion Issues:

+     

+         None.

+     

+     New Features:

+     
+
+    
    
+      
  1. The INTERFACE column in the /etc/shorewall/masq file may
+      now specify a destination list.
    
+      
    
+       Example:
    
+      
    
+           #INTERFACE   
+             
+      SUBNET        ADDRESS
    
+          
+      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.
    
+      
    
+      
    2. 
+
+      
  2. 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 :
    
+      
    
+             [<user name or
+      number>]:[<group name or number>]
    
+      
    
+       The colon is optionnal when specifying only a user.
    
+      
    
+              Examples : john: / john
+      / :users / john:users
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+      
    
+        WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
+      INTERFACE!   
    4. 
+    

+
+    
1/24/2004 - Shorewall 1.4.10 RC2 

+
+    
http://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. 
+    

+    Migragion Issues:

+     

+         None.

+     

+     New Features:

+     
+
+    
    
+      
  1. The INTERFACE column in the /etc/shorewall/masq file may
+      now specify a destination list.
    
+      
    
+       Example:
    
+      
    
+           #INTERFACE   
+             
+      SUBNET        ADDRESS
    
+          
+      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.
    
+      
    
+      
    2. 
+
+      
  2. 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 :
    
+      
    
+             [<user name or
+      number>]:[<group name or number>]
    
+      
    
+       The colon is optionnal when specifying only a user.
    
+      
    
+              Examples : john: / john
+      / :users / john:users
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+      
    
+        WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
+      INTERFACE!
    4. 
+    

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

+    Migragion Issues:

+     

+         None.

+     

+     New Features:

+     
+
+    
    
+      
  1. The INTERFACE column in the /etc/shorewall/masq file may
+      now specify a destination list.
    
+      
    
+       Example:
    
+      
    
+           #INTERFACE   
+             
+      SUBNET        ADDRESS
    
+          
+      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.
    
+      
    
+      
    2. 
+
+      
  2. 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 :
    
+      
    
+             [<user name or
+      number>]:[<group name or number>]
    
+      
    
+       The colon is optionnal when specifying only a user.
    
+      
    
+              Examples : john: / john
+      / :users / john:users   
    
+      
    3. 
+    

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

+
+    
Migration Issues:

+    

+         None.

+    

+     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".
    
+      
    
+       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.
    
+      
    
+       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"
    5. 
+
+      
  5. 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.
    
+      
    
+       Example: You want an action that logs a packet at the 'info'
+      level and accepts the connection.
    
+      
    
+       In /etc/shorewall/actions, you would add:
    
+      
    
+            LogAndAccept
    
+      
    
+       You would then copy /etc/shorewall/action.template to
+      /etc/shorewall/action.LogAndAccept and in that file, you
+      would add the two rules:
    
+               LOG:info
    
+               ACCEPT
    6. 
+
+      
  6. 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 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.
    7. 
+
+      
  7. 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.
    8. 
+    

+
+    
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.
+      Previously, there were cases where the SNAT specification was
+      effectively ignored.
    
+      
    5. 
+    

+
+    
Migration Issues:

+
+    
    None.

+    

+     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".
    
+      
    
+       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.
    
+      
    
+       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"
    5. 
+
+      
  5. 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.
    
+      
    
+       Example: You want an action that logs a packet at the 'info'
+      level and accepts the connection.
    
+      
    
+       In /etc/shorewall/actions, you would add:
    
+      
    
+            LogAndAccept
    
+      
    
+       You would then copy /etc/shorewall/action.template to
+      /etc/shorewall/action.LogAndAccept and in that file, you
+      would add the two rules:
    
+               LOG:info
    
+               ACCEPT
    
+      
    6. 
+
+      
  6. 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 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.
    
+      
    
+      
    7. 
+    

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

+
+    
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".
    
+      
    
+       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.
    
+      
    
+       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"
    4. 
+
+      
  4. 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.
    
+      
    
+       Example: You want an action that logs a packet at the 'info'
+      level and accepts the connection.
    
+      
    
+       In /etc/shorewall/actions, you would add:
    
+      
    
+            LogAndAccept
    
+      
    
+       You would then copy /etc/shorewall/action.template to
+      /etc/shorewall/action.LogAndAccept and in that file, you
+      would add the two rules:
    
+               LOG:info
    
+               ACCEPT
    
+      
    5. 
+
+      
  5. 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 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.
    6. 
+    

+
+    
12/03/2003 - Support Torch Passed

+    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. 
+
+    
11/07/2003 - Shorewall 1.4.8

+    

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

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

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

+
+    
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.
    
+          
    
+       The firewall script has been modified to eliminate the error
+      messages
    
+      
    5. 
+    

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

+
+    
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 tcrules file. Previously, these addresses resulted in
+      an invalid iptables command.
    
+      
    3. 
+    

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

+
+    
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 tcrules file. Previously, these addresses resulted in
+      an invalid iptables command.
    
+      
    3. 
+    

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

+
+    
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:

+    

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

+
+    
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:

+    

+    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:

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

+
+    
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. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. Corrected a problem in Beta 1 where DNS names containing
+      a "-" were mis-handled when they appeared in the DEST column
+      of a rule.
    
+      
    
+      
    4. 
+
+      
  4. 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.
    
+      
    
+      
    5. 
+
+      
  5. The message "Adding rules for DHCP" is now suppressed if
+      there are no DHCP rules to add.
    
+      
    6. 
+    

+
+    
Migration Issues:

+    

+
+    
    
+      
  1. 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:
    
+      
    
+           z  
+      eth1:192.168.1.0/24,192.168.2.0/24
    
+      
    
+      
    2. 
+
+      
  2. 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).
    
+      
    3. 
+    

+
+    
New Features:

+    

+
+    
    
+      
  1. 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.
    
+      
    
+      
    2. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. Shorewall can now add IP addresses to subnets other than
+      the first one on an interface.
    
+      
    
+      
    4. 
+
+      
  4. 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
    
+      
    
+      
    5. 
+
+      
  5. 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...
    
+      
    
+      
    6. 
+
+      
  6. 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:
    7. 
+
+      
  7. 
+        
      
+          
    • 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.
      
+          
      
+          
      • 
+        
    
+      
    8. 
+
+      
  8. The shell used to interpret the firewall script
+      (/usr/share/shorewall/firewall) may now be specified using
+      the SHOREWALL_SHELL parameter in shorewall.conf.
    
+      
    
+      
    9. 
+
+      
  9. 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
    
+             [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
    
+             [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.
    
+      
    
+      
    10. 
+
+      
  10. An 'iprange' command has been added to
+      /sbin/shorewall.
    
+      
    
+             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.
    
+      
    
+       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
    
+             192.168.1.4/30
    
+             192.168.1.8/29
    
+             192.168.1.16/28
    
+             192.168.1.32/27
    
+             192.168.1.64/26
    
+             192.168.1.128/25
    
+             192.168.2.0/23
    
+             192.168.4.0/22
    
+             192.168.8.0/22
    
+             192.168.12.0/29
    
+             192.168.12.8/31
    
+             [root@gateway root]#
    
+      
    
+      
    11. 
+
+      
  11. 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
    
+      
    
+      
    12. 
+
+      
  12. The "shorewall check" command now includes the chain name
+      when printing the applicable policy for each pair of
+      zones.
    
+        
    
+           Example:
    
+        
    
+               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.
    
+      
    
+      
    13. 
+
+      
  13. Support for the 2.6 Kernel series has been added.
    
+      
    14. 
+    

+
+    
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. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. Corrected a problem in Beta 1 where DNS names containing
+      a "-" were mis-handled when they appeared in the DEST column
+      of a rule.
    
+      
    
+      
    4. 
+
+      
  4. 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.
    
+      
    5. 
+    

+
+    
Migration Issues:

+    

+
+    
    
+      
  1. 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:
    
+      
    
+           z  
+      eth1:192.168.1.0/24,192.168.2.0/24
    
+      
    
+      
    2. 
+
+      
  2. 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).
    
+      
    3. 
+    

+
+    
New Features:

+    

+
+    
    
+      
  1. 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.
    
+      
    
+      
    2. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. Shorewall can now add IP addresses to subnets other than
+      the first one on an interface.
    
+      
    
+      
    4. 
+
+      
  4. 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
    
+      
    
+      
    5. 
+
+      
  5. 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...
    
+      
    
+      
    6. 
+
+      
  6. 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:
    7. 
+
+      
  7. 
+        
      
+          
    • 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.
      
+          
      
+          
      • 
+        
    
+      
    8. 
+
+      
  8. The shell used to interpret the firewall script
+      (/usr/share/shorewall/firewall) may now be specified using
+      the SHOREWALL_SHELL parameter in shorewall.conf.
    
+      
    
+      
    9. 
+
+      
  9. 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
    
+             [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
    
+             [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.
    
+      
    
+      
    10. 
+
+      
  10. An 'iprange' command has been added to
+      /sbin/shorewall.
    
+      
    
+             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.
    
+      
    
+       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
    
+             192.168.1.4/30
    
+             192.168.1.8/29
    
+             192.168.1.16/28
    
+             192.168.1.32/27
    
+             192.168.1.64/26
    
+             192.168.1.128/25
    
+             192.168.2.0/23
    
+             192.168.4.0/22
    
+             192.168.8.0/22
    
+             192.168.12.0/29
    
+             192.168.12.8/31
    
+             [root@gateway root]#
    
+      
    
+      
    11. 
+
+      
  11. 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
    12. 
+    

+
+    
7/7/2003 - Shorewall-1.4.6 Beta 2

+
+    
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. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. Corrected a problem in Beta 1 where DNS names containing
+      a "-" were mis-handled when they appeared in the DEST column
+      of a rule.
    
+      
    4. 
+    

+
+    
Migration Issues:

+    

+
+    
    
+      
  1. 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:
    
+      
    
+           z  
+      eth1:192.168.1.0/24,192.168.2.0/24
    
+      
    
+      
    2. 
+
+      
  2. 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).
    
+      
    3. 
+    

+
+    
New Features:

+    

+
+    
    
+      
  1. 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.
    
+      
    
+      
    2. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. Shorewall can now add IP addresses to subnets other than
+      the first one on an interface.
    
+      
    
+      
    4. 
+
+      
  4. 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
    
+      
    
+      
    5. 
+
+      
  5. 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...
    
+      
    
+      
    6. 
+
+      
  6. 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:
    7. 
+
+      
  7. 
+        
      
+          
    • 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.
      
+          
      
+          
      • 
+        
    
+      
    8. 
+
+      
  8. The shell used to interpret the firewall script
+      (/usr/share/shorewall/firewall) may now be specified using
+      the SHOREWALL_SHELL parameter in shorewall.conf.
    
+      
    
+      
    9. 
+
+      
  9. 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
    
+             [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
    
+             [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.
    
+      
    
+      
    10. 
+
+      
  10. An 'iprange' command has been added to
+      /sbin/shorewall.
    
+      
    
+             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.
    
+      
    
+       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
    
+             192.168.1.4/30
    
+             192.168.1.8/29
    
+             192.168.1.16/28
    
+             192.168.1.32/27
    
+             192.168.1.64/26
    
+             192.168.1.128/25
    
+             192.168.2.0/23
    
+             192.168.4.0/22
    
+             192.168.8.0/22
    
+             192.168.12.0/29
    
+             192.168.12.8/31
    
+             [root@gateway root]#
    
+      
    
+      
    11. 
+
+      
  11. 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
    
+      
    
+      
    12. 
+    

+
+    
7/4/2003 - Shorewall-1.4.6 Beta 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. 
+
+      
  2. 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.
    
+      
    3. 
+    

+
+    
New Features:

+    

+
+    
    
+      
  1. 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.
    
+      
    
+      
    2. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. Shorewall can now add IP addresses to subnets other than
+      the first one on an interface.
    
+      
    
+      
    4. 
+
+      
  4. 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:
    
+      
    
+           DNAT net loc:192.168.10.2-192.168.10.5 tcp
+      80
    
+      
    
+       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.
    
+      
    
+      
    5. 
+
+      
  5. 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...
    
+      
    
+      
    6. 
+
+      
  6. 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:
    7. 
+
+      
  7. 
+        
      
+          
    • 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.
      
+          
      
+          
      • 
+        
    
+      
    8. 
+
+      
  8. The shell used to interpret the firewall script
+      (/usr/share/shorewall/firewall) may now be specified using
+      the SHOREWALL_SHELL parameter in shorewall.conf.
    
+      
    9. 
+    

+
+    
6/17/2003 - Shorewall-1.4.5

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

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

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

+    

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

+    

+
+    
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'. 

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

+     

+         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. 
+
+      
  2. 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.
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+      
    4. 
+    

+
+    
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:
    
+          a) tcp - RST
    
+          b) udp - ICMP port unreachable
    
+          c) icmp - ICMP host unreachable
    
+          d) Otherwise - ICMP host prohibited
    
+       If you are running earlier software, Shorewall will follow
+      it's traditional convention:
    
+          a) tcp - RST
    
+          b) Otherwise - ICMP port unreachable
    2. 
+
+      
  2. 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.
    
+      
    3. 
+    

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

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

+
+    
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 Francesca Smith, the sample configurations are now
+    upgraded to Shorewall version 1.4.2.

+
+    
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. 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 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.
    
+        
    
+          Examples:
    
+          shorewall/params.mgmt:
    
+          MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    
+          TIME_SERVERS=4.4.4.4
    
+          BACKUP_SERVERS=5.5.5.5
    
+          ----- end params.mgmt -----
    
+        
    
+        
    
+          shorewall/params:
    
+          # Shorewall 1.3 /etc/shorewall/params
    
+          [..]
    
+          #######################################
    
+        
    
+          INCLUDE params.mgmt   
    
+        
    
+          # params unique to this host here
    
+          #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE -
+      DO NOT REMOVE
    
+          ----- end params -----
    
+        
    
+        
    
+          shorewall/rules.mgmt:
    
+          ACCEPT
+      net:$MGMT_SERVERS         
+      $FW    tcp    22
    
+          ACCEPT
+      $FW         
+      net:$TIME_SERVERS    udp   
+      123
    
+          ACCEPT
+      $FW         
+      net:$BACKUP_SERVERS  tcp    22
    
+          ----- end rules.mgmt -----
    
+        
    
+          shorewall/rules:
    
+          # Shorewall version 1.3 - Rules File
    
+          [..]
    
+          #######################################
    
+        
    
+          INCLUDE rules.mgmt    
    
+        
    
+          # rules unique to this host here
    
+          #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.
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+        
    
+       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').
    
+        
    
+       See the 'Upgrade Issues'
+      for information about how this new option may affect your
+      configuration.
    
+      
    4. 
+    

+
+    
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:

+    

+
+    
    
+      
  1. 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.
    2. 
+    

+    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

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

+    

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

+
+    
    
+      
  • There may be no rules created that govern connections
+      from Z1 to Z2.
    • 
+
+      
  • Shorewall will not create any infrastructure to handle
+      traffic 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.
+    

+     

+     IMPORTANT: Shorewall 1.4.0 requires the iproute
+    package ('ip' utility).

+     

+     Function from 1.3 that has been omitted from this version
+    include:

+     
+
+    
    
+      
  1. 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.
    
+      
    
+      
    2. 
+
+      
  2. Interface names of the form
+      <device>:<integer> in /etc/shorewall/interfaces
+      now generate an error.
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+      
    
+      
    4. 
+
+      
  4. 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.
    
+      
    
+      
    5. 
+
+      
  5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is
+      no longer accepted.
    
+      
    
+      
    6. 
+
+      
  6. The ALLOWRELATED variable in shorewall.conf is no longer
+      supported. Shorewall 1.4 behavior is the same as 1.3 with
+      ALLOWRELATED=Yes.
    
+      
    
+      
    7. 
+
+      
  7. The icmp.def file has been removed.
    
+      
    8. 
+    

+    Changes for 1.4 include:

+     
+
+    
    
+      
  1. The /etc/shorewall/shorewall.conf file has been
+      completely reorganized into logical sections.
    
+      
    
+      
    2. 
+
+      
  2. LOG is now a valid action for a rule
+      (/etc/shorewall/rules).
    
+      
    
+      
    3. 
+
+      
  3. The firewall script and version file are now installed in
+      /usr/share/shorewall.
    
+      
    
+      
    4. 
+
+      
  4. Late arriving DNS replies are now silently dropped in the
+      common chain by default.
    
+      
    
+      
    5. 
+
+      
  5. 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.
    
+      
    
+      
    6. 
+
+      
  6. CONTINUE is now a valid action for a rule
+      (/etc/shorewall/rules).
    
+      
    
+      
    7. 
+
+      
  7. 802.11b devices with names of the form wlan<n> now
+      support the 'maclist' option.
    
+      
    
+      
    8. 
+
+      
  8. 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.
    
+      
    
+      
    9. 
+
+      
  9. The /etc/shorewall/params file is now processed first so
+      that variables may be used in the
+      /etc/shorewall/shorewall.conf file.
    
+      
    
+      
    10. 
+
+      
  10. Shorewall now gives a more helpful diagnostic
+      when the 'ipchains' compatibility kernel module is loaded and
+      a 'shorewall start' command is issued.
    
+      
    
+      
    11. 
+
+      
  11. 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.
    
+      
    
+      
    12. 
+
+      
  12. Shorewall now ignores 'default' routes when detecting
+      masq'd networks.
    13. 
+    

+
+    
3/10/2003 - Shoreall 1.3.14a

+
+    
A roleup of the following bug fixes and other updates:

+
+    
    
+      
  • There is an updated rfc1918 file that reflects the resent
+      allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • 
+    

+
+    
    
+      
  • The documentation for the routestopped file claimed that
+      a comma-separated list could appear in the second column
+      while the code only supported a single host or network
+      address.
    • 
+
+      
  • Log messages produced by 'logunclean' and 'dropunclean'
+      were not rate-limited.
    • 
+
+      
  • 802.11b devices with names of the form
+      wlan<n> don't support the 'maclist' interface
+      option.
    • 
+
+      
  • Log messages generated by RFC 1918 filtering are not rate
+      limited.
    • 
+
+      
  • The firewall fails to start in the case where you have
+      "eth0 eth1" in /etc/shorewall/masq and the default route is
+      through eth1
    • 
+    

+
+    
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).
    
+      
    
+       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.
    
+      
    
+      
    2. 
+
+      
  2. 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
    
+        
    3. 
+
+      
  3. Support for OpenVPN Tunnels.
    
+      
    
+      
    4. 
+
+      
  4. Support for VLAN devices with names of the form $DEV.$VID
+      (e.g., eth0.0)
    
+      
    
+      
    5. 
+
+      
  5. 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.
    
+      
    
+      
    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.
    
+          
    
+         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.
    
+          
    
+         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.
    
+          
    
+         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. 
+    

+
+    


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

+     

+     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:

+    

+
+    
    
+      
  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).
    
+      
    
+       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.
    
+      
    
+      
    2. 
+
+      
  2. 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
    
+        
    3. 
+
+      
  3. 
+        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.
    
+          
    
+         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.
    
+          
    
+         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.
    
+          
    
+         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
+
+
    
+      
    4. 
+    

+
+    
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 

+
+    
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:

+    

+
+    
    
+      
  1. 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.
    
+      
    
+          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
    
+               ACCEPT net 
+      dmz:206.124.146.177 tcp www,smtp,ftp,...
    
+      
    
+          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.
    
+      
    
+               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,....
    
+      
    
+      
    2. 
+
+      
  2. The 'shorewall check' command now prints out the
+      applicable policy between each pair of zones.
    
+      
    
+      
    3. 
+
+      
  3. 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.
    
+      
    
+      
    4. 
+
+      
  4. 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.
    
+      
    5. 
+    

+
+    
1/6/2003 -
+    BURNOUT

+
+    
Until further notice, I will not be involved in either
+    Shorewall Development or Shorewall Support

+
+    
-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

+
+    
    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/

+
+         http://slovakia.shorewall.net/pub/shorewall/pdf/

+
+    

+
+    
12/27/2002 - Shorewall 1.3.12 Released

+
+    
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.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.
    
+      
    9. 
+    

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

+     
+
+    
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:

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

+    You may download the Beta from:

+     
+
+    

+      http://www.shorewall.net/pub/shorewall/Beta

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

+    

+
+    
12/12/2002 - Mandrake Multi Network Firewall +
+    

+    Shorewall is at the center of MandrakeSoft's recently-announced
+    
+    Multi Network Firewall (MNF) product. Here is the 
+    press 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.

+
+    
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 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:

+
+    
    
+      
  • A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces.
+      This option causes Shorewall to make a set of sanity check on
+      TCP packet header flags.
    • 
+
+      
  • It is now allowed to use 'all' in the SOURCE or DEST
+      column in a rule. When
+      used, 'all' must appear by itself (in may not be qualified)
+      and it does not enable intra-zone traffic. For example, the
+      rule
    
+      
    
+           ACCEPT loc all tcp 80
    
+      
    
+       does not enable http traffic from 'loc' to 'loc'.
    • 
+
+      
  • Shorewall's use of the 'echo' command is now compatible
+      with bash clones such as ash and dash.
    • 
+
+      
  • fw->fw policies now generate a startup error.
+      fw->fw rules generate a warning and are ignored
    • 
+    

+
+    
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

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

+    

+
+    
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:

+     
+
+    
+    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/9/2002 - Shorewall 1.3.9b

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

+     

+     9/30/2002 - Shorewall 1.3.9a

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

+     
+
+    
9/28/2002 - Shorewall 1.3.9

+
+    
In this version:

+    

+
+    
    
+      
  • DNS
+      Names are now allowed in Shorewall config files (although
+      I recommend against using them).
    • 
+
+      
  • The connection SOURCE may now be qualified by both
+      interface and IP address in a Shorewall rule.
    • 
+
+      
  • Shorewall startup is now disabled after initial
+      installation until the file /etc/shorewall/startup_disabled
+      is removed. This avoids nasty surprises during reboot for
+      users who install Shorewall but don't configure it.
    • 
+
+      
  • The 'functions' and 'version' files and the 'firewall'
+      symbolic link have been moved from /var/lib/shorewall to
+      /usr/lib/shorewall to appease the LFS police at Debian.
    
+      
    • 
+    

+
+    
9/23/2002 - Full Shorewall Site/Mailing List Archive
+    Search 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:

+     
+
+    
    
+      
  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/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:

+    

+
+    
    
+      
  • A NEWNOTSYN option
+      has been added to shorewall.conf. This option determines
+      whether Shorewall accepts TCP packets which are not part of
+      an established connection and that are not 'SYN' packets (SYN
+      flag on and ACK flag off).
    • 
+
+      
  • The need for the 'multi' option to communicate between
+      zones za and zb on the same interface is removed in the case
+      where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will
+      exist if:
    • 
+
+      
  • 
+        
      
+          
    • There is a policy for za to zb; or
      • 
+
+          
    • There is at least one rule for za to zb.
      • 
+        
    
+      
    • 
+    

+
+    
    
+      
  • The /etc/shorewall/blacklist file now contains three
+      columns. In addition to the SUBNET/ADDRESS column, there are
+      optional PROTOCOL and PORT columns to block only certain
+      applications from the blacklisted addresses.
    
+      
    • 
+    

+
+    
9/11/2002 - Debian 1.3.7c Packages Available

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

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

+
+    
8/26/2002 - French FTP Mirror is Operational

+
+    
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

+
+    
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

+
+    
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:

+
+    
    
+      
  • The 'icmp.def' file is now empty! The rules in that file
+      were required in ipchains firewalls but are not required in
+      Shorewall. Users who have ALLOWRELATED=No in shorewall.conf should see the Upgrade Issues.
    • 
+
+      
  • A 'FORWARDPING' option has been added to shorewall.conf. The effect of
+      setting this variable to Yes is the same as the effect of
+      adding an ACCEPT rule for ICMP echo-request in /etc/shorewall/icmpdef.
+      Users who have such a rule in icmpdef are encouraged to
+      switch to FORWARDPING=Yes.
    • 
+
+      
  • The loopback CLASS A Network (127.0.0.0/8) has been added
+      to the rfc1918 file.
    • 
+
+      
  • Shorewall now works with iptables 1.2.7
    • 
+
+      
  • The documentation and web site no longer uses FrontPage
+      themes.
    • 
+    

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

+
+    
8/7/2002 - Upgrade
+    Issues 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:

+
+    
+
+    
7/30/2002 - Shorewall 1.3.5b Released

+
+    
This interim release:

+
+    
    
+      
  • Causes the firewall script to remove the lock file if it
+      is killed.
    • 
+
+      
  • Once again allows lists in the second column of the /etc/shorewall/hosts
+      file.
    • 
+
+      
  • Includes the latest QuickStart Guides.
    • 
+    

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

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

+
+    
7/27/2002 - Shorewall 1.3.5a Released

+
+    
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:

+
+    
    
+      
  • Empty and invalid source and destination qualifiers are
+      now detected in the rules file. It is a good idea to use the
+      'shorewall check' command before you issue a 'shorewall
+      restart' command be be sure that you don't have any
+      configuration problems that will prevent a successful
+      restart.
    • 
+
+      
  • Added MERGE_HOSTS variable in shorewall.conf to provide saner
+      behavior of the /etc/shorewall/hosts file.
    • 
+
+      
  • The time that the counters were last reset is now
+      displayed in the heading of the 'status' and 'show'
+      commands.
    • 
+
+      
  • A proxyarp option has been added for entries in /etc/shorewall/interfaces.
+      This option facilitates Proxy ARP sub-netting as described in
+      the Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/).
+      Specifying the proxyarp option for an interface causes
+      Shorewall to set
+      /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
    • 
+
+      
  • The Samples have been updated to reflect the new
+      capabilities in this release.
    • 
+    

+
+    
7/16/2002 - New Mirror in Argentina

+
+    
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:

+
+    
    
+      
  • A new /etc/shorewall/routestopped
+      file has been added. This file is intended to eventually
+      replace the routestopped option in the
+      /etc/shorewall/interface and /etc/shorewall/hosts files. This
+      new file makes remote firewall administration easier by
+      allowing any IP or subnet to be enabled while Shorewall is
+      stopped.
    • 
+
+      
  • An /etc/shorewall/stopped extension script has been
+      added. This script is invoked after Shorewall has
+      stopped.
    • 
+
+      
  • A DETECT_DNAT_ADDRS option has been added to /etc/shoreall/shorewall.conf.
+      When this option is selected, DNAT rules only apply when the
+      destination address is the external interface's primary IP
+      address.
    • 
+
+      
  • The QuickStart
+      Guide has been broken into three guides and has been
+      almost entirely rewritten.
    • 
+
+      
  • The Samples have been updated to reflect the new
+      capabilities in this release.
    • 
+    

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

+
+    
7/6/2002 - Shorewall 1.3.3 Released

+
+    
In this version:

+
+    
    
+      
  • Entries in /etc/shorewall/interface that use the wildcard
+      character ("+") now have the "multi" option assumed.
    • 
+
+      
  • The 'rfc1918' chain in the mangle table has been renamed
+      'man1918' to make log messages generated from that chain
+      distinguishable from those generated by the 'rfc1918' chain
+      in the filter table.
    • 
+
+      
  • Interface names appearing in the hosts file are now
+      validated against the interfaces file.
    • 
+
+      
  • The TARGET column in the rfc1918 file is now checked for
+      correctness.
    • 
+
+      
  • The chain structure in the nat table has been changed to
+      reduce the number of rules that a packet must traverse and to
+      correct problems with NAT_BEFORE_RULES=No
    • 
+
+      
  • The "hits" command has been enhanced.
    • 
+    

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

+
+    
6/19/2002 - Documentation Available in PDF Format

+
+    
Thanks to Mike Martinez, the Shorewall Documentation is now
+    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:

+
+    
    
+      
  • Ignore robot.txt files.
    • 
+
+      
  • Recursively copy everything that they find.
    • 
+
+      
  • Should be classified as weapons rather than 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.

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

+
+    
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 samples.

+
+    
6/1/2002 - Shorewall 1.3.1 Released

+
+    
Hot on the heels of 1.3.0, this release:

+
+    
    
+      
  • Corrects a serious problem with "all <zone>
+      CONTINUE" policies. This problem is present in all versions
+      of Shorewall that support the CONTINUE policy. These previous
+      versions optimized away the "all2<zone>" chain
+      and replaced it with the "all2all" chain with the usual
+      result that a policy of REJECT was enforced rather than the
+      intended CONTINUE policy.
    • 
+
+      
  • Adds an /etc/shorewall/rfc1918 file
+      for defining the exact behavior of the 'norfc1918' interface
+      option.
    • 
+    

+
+    
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:

+
+    
    
+      
  • A 'filterping' interface option that allows ICMP
+      echo-request (ping) requests addressed to the firewall to be
+      handled by entries in /etc/shorewall/rules and
+      /etc/shorewall/policy.
    • 
+    

+
+    
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:

+
+    
    
+      
  • Support for the /etc/shorewall/whitelist file has been
+      withdrawn. If you need whitelisting, see these
+      instructions.
    • 
+    

+
+    
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:

+
+    
    
+      
  • The structure of the firewall is changed markedly. There
+      is now an INPUT and a FORWARD chain for each interface; this
+      reduces the number of rules that a packet must traverse,
+      especially in complicated setups.
    • 
+
+      
  • Sub-zones may now be
+      excluded from DNAT and REDIRECT rules.
    • 
+
+      
  • The names of the columns in a number of the configuration
+      files have been changed to be more consistent and
+      self-explanatory and the documentation has been updated
+      accordingly.
    • 
+
+      
  • The sample configurations have been updated for 1.3.
    • 
+    

+
+    
5/17/2002 - Shorewall 1.3 Beta 1 Available

+
+    
Beta 1 carries the version designation 1.2.90 and implements
+    the following features:

+
+    
    
+      
  • Simplified rule syntax which makes the intent of each
+      rule clearer and hopefully makes Shorewall easier to
+      learn.
    • 
+
+      
  • Upward compatibility with 1.2 configuration files has
+      been maintained so that current users can migrate to the new
+      syntax at their convenience.
    • 
+
+      
  • WARNING:  Compatibility
+      with the old parameterized sample configurations has NOT been
+      maintained. Users still running those configurations should
+      migrate to the new sample configurations before upgrading to
+      1.3 Beta 1.
    • 
+    

+
+    
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
+    Testing Branch and the Debian
+    Unstable Branch.

+
+    
4/20/2002 - Shorewall 1.2.12 is Available

+
+    
    
+      
  • The 'try' command works again
    • 
+
+      
  • There is now a single RPM that also works with SuSE.
    • 
+    

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

+
+    
4/13/2002 - Shorewall 1.2.11 Available

+
+    
In this version:

+
+    
    
+      
  • The 'try' command now accepts an optional timeout. If the
+      timeout is given in the command, the standard configuration
+      will automatically be restarted after the new configuration
+      has been running for that length of time. This prevents a
+      remote admin from being locked out of the firewall in the
+      case where the new configuration starts but prevents
+      access.
    • 
+
+      
  • Kernel route filtering may now be enabled globally using
+      the new ROUTE_FILTER parameter in /etc/shorewall/shorewall.conf.
    • 
+
+      
  • Individual IP source addresses and/or subnets may now be
+      excluded from masquerading/SNAT.
    • 
+
+      
  • Simple "Yes/No" and "On/Off" values are now
+      case-insensitive in /etc/shorewall/shorewall.conf.
    • 
+    

+
+    
4/13/2002 - Hamburg Mirror now has FTP

+
+    
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

+
+    
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

+
+    
Version 1.0 of the
+    QuickStart Guide is now available. This Guide and its
+    accompanying sample configurations are expected to provide a
+    replacement for the recently withdrawn parameterized
+    samples.

+
+    
4/8/2002 - Parameterized Samples Withdrawn

+
+    
Although the parameterized
+    samples have allowed people to get a firewall up and
+    running quickly, they have unfortunately set the wrong level of
+    expectation among those who have used them. I am therefore
+    withdrawing support 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.

+
+    
3/30/2002 - Shorewall Website Search Improvements

+
+    
The quick search on the home page now excludes the mailing
+    list 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)

+
+    
+
+    
3/25/2002 - Log Parser Available

+
+    
John Lodge has
+    provided a CGI-based log
+    parser for Shorewall. Thanks John.

+
+    
3/20/2002 - Shorewall 1.2.10 Released

+
+    
In this version:

+
+    
    
+      
  • A "shorewall try" command has been added (syntax:
+      shorewall try <configuration directory>). This
+      command attempts "shorewall -c <configuration
+      directory> start" and if that results in the firewall
+      being stopped due to an error, a "shorewall start" command is
+      executed. The 'try' command allows you to create a new configuration and
+      attempt to start it; if there is an error that leaves your
+      firewall in the stopped state, it will automatically be
+      restarted using the default configuration (in
+      /etc/shorewall).
    • 
+
+      
  • A new variable ADD_SNAT_ALIASES has been added to /etc/shorewall/shorewall.conf.
+      If this variable is set to "Yes", Shorewall will
+      automatically add IP addresses listed in the third column of
+      the /etc/shorewall/masq
+      file.
    • 
+
+      
  • Copyright notices have been added to the
+      documenation.
    • 
+    

+
+    
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

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

+
+    
2/22/2002 - Shorewall 1.2.7 Released

+
+    
In this version:

+
+    
    
+      
  • UPnP probes (UDP destination port 1900) are now silently
+      dropped in the common chain
    • 
+
+      
  • RFC 1918 checking in the mangle table has been
+      streamlined to no longer require packet marking. RFC 1918
+      checking in the filter table has been changed to require half
+      as many rules as previously.
    • 
+
+      
  • A 'shorewall check' command has been added that does a
+      cursory validation of the zones, interfaces, hosts, rules and
+      policy files.
    • 
+    

+
+    
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:

+
+    
    
+      
  • $-variables may now be used anywhere in the configuration
+      files except /etc/shorewall/zones.
    • 
+
+      
  • The interfaces and hosts files now have their contents
+      validated before any changes are made to the existing
+      Netfilter configuration. The appearance of a zone name that
+      isn't defined in /etc/shorewall/zones causes "shorewall
+      start" and "shorewall restart" to abort without changing the
+      Shorewall state. Unknown options in either file cause a
+      warning to be issued.
    • 
+
+      
  • A problem occurring when BLACKLIST_LOGLEVEL was not set
+      has been corrected.
    • 
+    

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

+
+    
In version 1.2.5:

+
+    
    
+      
  • The installation problems have been corrected.
    • 
+
+      
  • SNAT is now
+      supported.
    • 
+
+      
  • A "shorewall version" command has been added
    • 
+
+      
  • The default value of the STATEDIR variable in
+      /etc/shorewall/shorewall.conf has been changed to
+      /var/lib/shorewall in order to conform to the GNU/Linux File
+      Hierarchy Standard, Version 2.2.
    • 
+    

+
+    
1/28/2002 - Shorewall 1.2.4 Released

+
+    
    
+      
  • The "fw" zone may now be
+      given a different name.
    • 
+
+      
  • You may now place end-of-line comments (preceded by '#')
+      in any of the configuration files
    • 
+
+      
  • There is now protection against against two state
+      changing operations occuring concurrently. This is
+      implemented using the 'lockfile' utility if it is available
+      (lockfile is part of procmail); otherwise, a less robust
+      technique is used. The lockfile is created in the STATEDIR
+      defined in /etc/shorewall/shorewall.conf and has the name
+      "lock".
    • 
+
+      
  • "shorewall start" no longer fails if "detect" is
+      specified in /etc/shorewall/interfaces
+      for an interface with subnet mask 255.255.255.255.
    • 
+    

+
+    
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 errata for details.

+
+    
1/19/2002 - Shorewall 1.2.3 Released

+
+    
This is a minor feature and bugfix release. The single new
+    feature is:

+
+    
    
+      
  • Support for TCP MSS Clamp to PMTU -- This support is
+      usually required when the internet connection is via PPPoE or
+      PPTP and may be enabled using the CLAMPMSS option in
+      /etc/shorewall/shorewall.conf.
    • 
+    

+
+    
The following problems were corrected:

+
+    
    
+      
  • The "shorewall status" command no longer hangs.
    • 
+
+      
  • The "shorewall monitor" command now displays the icmpdef
+      chain
    • 
+
+      
  • The CLIENT PORT(S) column in tcrules is no longer
+      ignored
    • 
+    

+
+    
1/18/2002 - Shorewall 1.2.2 packaged with new 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
+    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 download page.

+
+    
1/9/2002 - Updated 1.2.2 /sbin/shorewall available -
+    This corrected
+    version restores the "shorewall status" command to
+    health.

+
+    
1/8/2002 - Shorewall 1.2.2 Released

+
+    
In version 1.2.2

+
+    
    
+      
  • 
+        Support for IP blacklisting has been added 
+
+        
      
+          
    • You specify whether you want packets from blacklisted
+          hosts dropped or rejected using the BLACKLIST_DISPOSITION
+          setting in /etc/shorewall/shorewall.conf
      • 
+
+          
    • You specify whether you want packets from blacklisted
+          hosts logged and at what syslog level using the BLACKLIST_LOGLEVEL
+          setting in /etc/shorewall/shorewall.conf
      • 
+
+          
    • You list the IP addresses/subnets that you wish to
+          blacklist in /etc/shorewall/blacklist
      • 
+
+          
    • You specify the interfaces you want checked against
+          the blacklist using the new "blacklist" option in
+          /etc/shorewall/interfaces.
      • 
+
+          
    • The black list is refreshed from
+          /etc/shorewall/blacklist by the "shorewall refresh"
+          command.
      • 
+        
    
+      
    • 
+
+      
  • 
+        Use of TCP RST replies has been expanded  
+
+        
      
+          
    • TCP connection requests rejected because of a REJECT
+          policy are now replied with a TCP RST packet.
      • 
+
+          
    • TCP connection requests rejected because of a
+          protocol=all rule in /etc/shorewall/rules are now replied
+          with a TCP RST packet.
      • 
+        
    
+      
    • 
+
+      
  • A LOGFILE
+      specification has been added to
+      /etc/shorewall/shorewall.conf. LOGFILE is used to tell the
+      /sbin/shorewall program where to look for Shorewall
+      messages.
    • 
+    

+
+    
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:

+
+    
    
+      
  • Unless you have explicitly enabled Auth connections (tcp
+      port 113) to your firewall, these connections will be
+      REJECTED rather than DROPPED. This speeds up connection
+      establishment to some servers.
    • 
+
+      
  • Orphan DNS replies are now silently dropped.
    • 
+    

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

+
+    
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 1.2.0:

+
+    

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

+
+    
11/30/2001 - A new set of the parameterized Sample
+    Configurations has been released. In this version:

+
+    
    
+      
  • Ping is now allowed between the zones.
    • 
+
+      
  • In the three-interface configuration, it is now possible
+      to configure the internet services that are to be available
+      to servers in the DMZ. 
    • 
+    

+
+    
11/20/2001 - The current version of Shorewall is
+    1.1.18. 

+
+    
In this version:

+
+    
    
+      
  • The spelling of ADD_IP_ALIASES has been corrected in the
+      shorewall.conf file
    • 
+
+      
  • The logic for deleting user-defined chains has been
+      simplified so that it avoids a bug in the LRP version of the
+      'cut' utility.
    • 
+
+      
  • The /var/lib/lrpkg/shorwall.conf file has been corrected
+      to properly display the NAT entry in that file.
    • 
+    

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

+
+    
11/2/2001 - Announcing Shorewall Parameter-driven Sample
+    Configurations. There are three sample configurations:

+
+    
    
+      
  • One Interface -- for a standalone system.
    • 
+
+      
  • Two Interfaces -- A masquerading firewall.
    • 
+
+      
  • Three Interfaces -- A masquerading firewall with
+      DMZ.
    • 
+    

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

+
+    
In this version:

+
+    
+
+    
10/22/2001 - The current version of Shorewall is
+    1.1.16. In this version:

+
+    
    
+      
  • A new "shorewall show connections" command has been
+      added.
    • 
+
+      
  • In the "shorewall monitor" output, the currently tracked
+      connections are now shown on a separate page.
    • 
+
+      
  • Prior to this release, Shorewall unconditionally added
+      the external IP adddress(es) specified in /etc/shorewall/nat.
+      Beginning with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be set to
+      "no" (or "No") to inhibit this behavior. This allows IP
+      aliases created using your distribution's network
+      configuration tools to be used in static NAT. 
    • 
+    

+
+    
10/15/2001 - The current version of Shorewall is
+    1.1.15. In this version:

+
+    
    
+      
  • Support for nested zones has been improved. See the documentation for
+      details
    • 
+
+      
  • Shorewall now correctly checks the alternate
+      configuration directory for the 'zones' file.
    • 
+    

+
+    
10/4/2001 - The current version of Shorewall is
+    1.1.14. In this version

+
+    
    
+      
  • Shorewall now supports alternate configuration
+      directories. When an alternate directory is specified when
+      starting or restarting Shorewall (e.g., "shorewall -c
+      /etc/testconf restart"), Shorewall will first look for
+      configuration files in the alternate directory then in
+      /etc/shorewall. To create an alternate configuration
+      simply:
    
+       1. Create a New Directory
    
+       2. Copy to that directory any of your configuration files
+      that you want to change.
    
+       3. Modify the copied files as needed.
    
+       4. Restart Shorewall specifying the new directory.
    • 
+
+      
  • The rules for allowing/disallowing icmp echo-requests
+      (pings) are now moved after rules created when processing the
+      rules file. This allows you to add rules that selectively
+      allow/deny ping based on source or destination address.
    • 
+
+      
  • Rules that specify multiple client ip addresses or
+      subnets no longer cause startup failures.
    • 
+
+      
  • Zone names in the policy file are now validated against
+      the zones file.
    • 
+
+      
  • If you have packet mangling support
+      enabled, the "norfc1918" interface
+      option now logs and drops any incoming packets on the
+      interface that have an RFC 1918 destination address.
    • 
+    

+
+    
9/12/2001 - The current version of Shorewall is
+    1.1.13. In this version

+
+    
    
+      
  • Shell variables can now be used to parameterize Shorewall
+      rules.
    • 
+
+      
  • The second column in the hosts file may now contain a
+      comma-separated list.
    
+      
    
+       Example:
    
+           sea   
+      eth0:130.252.100.0/24,206.191.149.0/24
    • 
+
+      
  • Handling of multi-zone interfaces has been improved. See
+      the documentation for
+      the /etc/shorewall/interfaces file.
    • 
+    

+
+    
8/28/2001 - The current version of Shorewall is
+    1.1.12. In this version

+
+    
    
+      
  • Several columns in the rules file may now contain
+      comma-separated lists.
    • 
+
+      
  • Shorewall is now more rigorous in parsing the options in
+      /etc/shorewall/interfaces.
    • 
+
+      
  • Complementation using "!" is now supported in rules.
    • 
+    

+
+    
7/28/2001 - The current version of Shorewall is
+    1.1.11. In this version

+
+    
    
+      
  • A "shorewall refresh" command has been added to allow for
+      refreshing the rules associated with the broadcast address on
+      a dynamic interface. This command should be used in place of
+      "shorewall restart" when the internet interface's IP address
+      changes.
    • 
+
+      
  • The /etc/shorewall/start file (if any) is now processed
+      after all temporary rules have been deleted. This change
+      prevents the accidental removal of rules added during the
+      processing of that file.
    • 
+
+      
  • The "dhcp" interface option is now applicable to firewall
+      interfaces used by a DHCP server running on the
+      firewall.
    • 
+
+      
  • The RPM can now be built from the .tgz file using "rpm
+      -tb" 
    • 
+    

+
+    
7/6/2001 - The current version of Shorewall is
+    1.1.10. In this version

+
+    
    
+      
  • Shorewall now enables Ipv4 Packet Forwarding by default.
+      Packet forwarding may be disabled by specifying
+      IP_FORWARD=Off in /etc/shorewall/shorewall.conf. If you don't
+      want Shorewall to enable or disable packet forwarding, add
+      IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf
+      file.
    • 
+
+      
  • The "shorewall hits" command no longer lists extraneous
+      service names in its last report.
    • 
+
+      
  • Erroneous instructions in the comments at the head of the
+      firewall script have been corrected.
    • 
+    

+
+    
6/23/2001 - The current version of Shorewall is
+    1.1.9. In this version

+
+    
    
+      
  • The "tunnels" file really is in the RPM now.
    • 
+
+      
  • SNAT can now be applied to port-forwarded
+      connections.
    • 
+
+      
  • A bug which would cause firewall start failures in some
+      dhcp configurations has been fixed.
    • 
+
+      
  • The firewall script now issues a message if you have the
+      name of an interface in the second column in an entry in
+      /etc/shorewall/masq and that interface is not up.
    • 
+
+      
  • You can now configure Shorewall so that it doesn't require the NAT and/or
+      mangle netfilter modules.
    • 
+
+      
  • Thanks to Alex  Polishchuk, the "hits" command from
+      seawall is now in shorewall.
    • 
+
+      
  • Support for IPIP tunnels has been
+      added.
    • 
+    

+
+    
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

+
+    
    
+      
  • The TOS rules are now deleted when the firewall is
+      stopped.
    • 
+
+      
  • The .rpm will now install regardless of which version of
+      iptables is installed.
    • 
+
+      
  • The .rpm will now install without iproute2 being
+      installed.
    • 
+
+      
  • The documentation has been cleaned up.
    • 
+
+      
  • The sample configuration files included in Shorewall have
+      been formatted to 80 columns for ease of editing on a VGA
+      console.
    • 
+    

+
+    
5/25/2001 - The current version of Shorewall is
+    1.1.6. In this version

+
+    
    
+      
  • You may now
+      rate-limit the packet log.
    • 
+
+      
  • Previous versions of Shorewall have an implementation of
+      Static NAT which violates the principle of least
+      surprise.  NAT only occurs for packets arriving at
+      (DNAT) or send from (SNAT) the interface named in the
+      INTERFACE column of /etc/shorewall/nat. Beginning with
+      version 1.1.6, NAT effective regardless of which interface
+      packets come from or are destined to. To get compatibility
+      with prior versions, I have added a new "ALL "ALL INTERFACES"  column to
+      /etc/shorewall/nat. By placing "no" or "No" in the new
+      column, the NAT behavior of prior versions may be
+      retained. 
    • 
+
+      
  • The treatment of IPSEC
+      Tunnels where the remote gateway is a standalone system has
+      been improved. Previously, it was necessary to include an
+      additional rule allowing UDP port 500 traffic to pass through
+      the tunnel. Shorewall will now create this rule automatically
+      when you place the name of the remote peer's zone in a new
+      GATEWAY ZONE column in /etc/shorewall/tunnels. 
    • 
+    

+
+    
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

+
+    
    
+      
  • Accepting RELATED
+      connections is now optional.
    • 
+
+      
  • Corrected problem where if "shorewall start" aborted
+      early (due to kernel configuration errors for example),
+      superfluous 'sed' error messages were reported.
    • 
+
+      
  • Corrected rules generated for port redirection.
    • 
+
+      
  • The order in which iptables kernel modules are loaded has
+      been corrected (Thanks to Mark Pavlidis). 
    • 
+    

+
+    
4/28/2001 - The current version of Shorewall is
+    1.1.3. In this version

+
+    
    
+      
  • Correct message issued when Proxy ARP address added
+      (Thanks to Jason Kirtland).
    • 
+
+      
  • /tmp/shorewallpolicy-$$ is now removed if there is an
+      error while starting the firewall.
    • 
+
+      
  • /etc/shorewall/icmp.def and /etc/shorewall/common.def are
+      now used to define the icmpdef and common chains unless
+      overridden by the presence of /etc/shorewall/icmpdef or
+      /etc/shorewall/common.
    • 
+
+      
  • In the .lrp, the file /var/lib/lrpkg/shorwall.conf has
+      been corrected. An extra space after "/etc/shorwall/policy"
+      has been removed and "/etc/shorwall/rules" has been
+      added.
    • 
+
+      
  • When a sub-shell encounters a fatal error and has stopped
+      the firewall, it now kills the main shell so that the main
+      shell will not continue.
    • 
+
+      
  • A problem has been corrected where a sub-shell stopped
+      the firewall and main shell continued resulting in a
+      perplexing error message referring to "common.so"
+      resulted.
    • 
+
+      
  • Previously, placing "-" in the PORT(S) column in
+      /etc/shorewall/rules resulted in an error message during
+      start. This has been corrected.
    • 
+
+      
  • The first line of "install.sh" has been corrected -- I
+      had inadvertently deleted the initial "#".
    • 
+    

+
+    
4/12/2001 - The current version of Shorewall is
+    1.1.2. In this version

+
+    
    
+      
  • Port redirection now works again.
    • 
+
+      
  • The icmpdef and common chains may now be user-defined.
    • 
+
+      
  • The firewall no longer fails to start if "routefilter" is
+      specified for an interface that isn't started. A warning
+      message is now issued in this case.
    • 
+
+      
  • The LRP Version is renamed "shorwall" for 8,3 MSDOS file
+      system compatibility.
    • 
+
+      
  • A couple of LRP-specific problems were corrected.
    • 
+    

+
+    
4/8/2001 - Shorewall is now affiliated with the Leaf Project Leaf Logo

+
+    
4/5/2001 - The current version of Shorewall is 1.1.1. In
+    this version:

+
+    
    
+      
  • The common chain is traversed from INPUT, OUTPUT and
+      FORWARD before logging occurs
    • 
+
+      
  • The source has been cleaned up dramatically
    • 
+
+      
  • DHCP DISCOVER packets with RFC1918 source addresses no
+      longer generate log messages. Linux DHCP clients generate
+      such packets and it's annoying to see them logged. 
    • 
+    

+
+    
3/25/2001 - The current version of Shorewall is 1.1.0. In
+    this version:

+
+    
    
+      
  • Log messages now indicate the packet disposition.
    • 
+
+      
  • Error messages have been improved.
    • 
+
+      
  • The ability to define zones consisting of an enumerated
+      set of hosts and/or subnetworks has been added.
    • 
+
+      
  • The zone-to-zone chain matrix is now sparse so that only
+      those chains that contain meaningful rules are defined.
    • 
+
+      
  • 240.0.0.0/4 and 169.254.0.0/16 have been added to the
+      source subnetworks whose packets are dropped under the
+      norfc1918 interface option.
    • 
+
+      
  • Exits are now provided for executing an user-defined
+      script when a chain is defined, when the firewall is
+      initialized, when the firewall is started, when the firewall
+      is stopped and when the firewall is cleared.
    • 
+
+      
  • The Linux kernel's route filtering facility can now be
+      specified selectively on network interfaces.
    • 
+    

+
+    
3/19/2001 - The current version of Shorewall is 1.0.4.
+    This version:

+
+    
    
+      
  • Allows user-defined zones. Shorewall now has only one
+      pre-defined zone (fw) with the remaining zones being defined
+      in the new configuration file /etc/shorewall/zones. The
+      /etc/shorewall/zones file released in this version provides
+      behavior that is compatible with Shorewall 1.0.3. 
    • 
+
+      
  • Adds the ability to specify logging in entries in the
+      /etc/shorewall/rules file.
    • 
+
+      
  • Correct handling of the icmp-def chain so that only ICMP
+      packets are sent through the chain.
    • 
+
+      
  • Compresses the output of "shorewall monitor" if awk is
+      installed. Allows the command to work if awk isn't installed
+      (although it's not pretty).
    • 
+    

+
+    
3/13/2001 - The current version of Shorewall is 1.0.3.
+    This is a bug-fix release with no new features.

+
+    
    
+      
  • The PATH variable in the firewall script now includes
+      /usr/local/bin and /usr/local/sbin.
    • 
+
+      
  • DMZ-related chains are now correctly deleted if the DMZ
+      is deleted.
    • 
+
+      
  • The interface OPTIONS for "gw" interfaces are no longer
+      ignored.
    • 
+    

+
+    
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 also a .lrp available now.

+  
+
+