From 30a1f79488d405c83f742e836d273320c134da45 Mon Sep 17 00:00:00 2001 From: teastep Date: Sat, 13 Dec 2003 00:18:24 +0000 Subject: [PATCH] Modify New.htm for HTML 4.01 Transitional Compatibility git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@836 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/News.htm | 8151 +++++++++++++++++++++++---------------- 1 file changed, 4733 insertions(+), 3418 deletions(-) diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index d748a1cc8..c47758cab 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -1,540 +1,639 @@ - - Shorewall News + + +Shorewall News

Shorewall News Archive

+

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 +
  2. Tuomo Soini has supplied a correction to a problem that occurs using some versions of 'ash'. The symptom is that "shorewall start" fails with:
     
       local: --limit: bad variable name
       iptables v1.2.8: Couldn't load match `-j':/lib/iptables/libipt_-j.so:
    -   cannot open shared object file: No such file or directory
    +   cannot open shared object file: No such file or +directory
       Try `iptables -h' or 'iptables --help' for more information.
    3. -
  3. Andres Zhoglo has supplied a correction that avoids trying to use -the multiport match iptables facility on ICMP rules.
    + +
  4. Andres Zhoglo has supplied a correction that avoids trying to +use the multiport match iptables facility on ICMP rules.
     
    -   Example of rule that previously caused "shorewall start" -to fail:
    +   Example of rule that previously caused "shorewall +start" to fail:
     
               ACCEPT      loc  $FW  icmp    0,8,11,12
    -
    -
    5. -
  5. Previously, if the following error message was issued, Shorewall -was left in an inconsistent state.
    - 
    -   Error: Unable to determine the routes through interface xxx
    -
    -
    6. -
  6. Handling of the LOGUNCLEAN option in shorewall.conf has been -corrected.
    7. -
  7. 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.
    8. -
  8. 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.
    9. -
  9. An incorrect comment concerning Debian's use of the SUBSYSLOCK -option has been removed from shorewall.conf.
    10. -
  10. 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.
    11. -
  11. If MAC verification was enabled on an interface with a /32 -address and a broadcast address then an error would occur during -startup.
    12. -
  12. 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.
    13. -
  13. 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.
    -
    14. -
-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.
    +
    4. + +
  4. Previously, if the following error message was issued, +Shorewall was left in an inconsistent state.
     
       Error: Unable to determine the routes through interface xxx
    -
    -
    5. -
  5. Handling of the LOGUNCLEAN option in shorewall.conf has been +
    +
    6. + +
  6. Handling of the LOGUNCLEAN option in shorewall.conf has been corrected.
    7. -
  7. 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.
    8. -
  8. When the MARK value in a tcrules entry is followed by ":F" or + +
  9. 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.
    10. + +
  10. 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.
    -
    11. +Netfilter rule generated by the entry. It is now applied to all +entries. + +
  11. An incorrect comment concerning Debian's use of the SUBSYSLOCK +option has been removed from shorewall.conf.
    12. + +
  12. 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.
    13. + +
  13. If MAC verification was enabled on an interface with a /32 +address and a broadcast address then an error would occur during +startup.
    14. + +
  14. 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.
    15. + +
  15. 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.
    +
+ +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 +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables command.
    5. -
  5. The "shorewall stop" command is now disabled when + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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
    8. -
  8. Interface-specific dynamic blacklisting chains are -now displayed by "shorewall monitor" on the "Dynamic Chains" page +shooting themselves in the foot prior to having configured +Shorewall.
    9. + +
  9. 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
    10. + +
  10. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page (previously named "Dynamic Chain").
    11. -
  11. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    12. -
  12. 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.
    13. -
  13. When ADD_SNAT_ALIASES=Yes in -shorewall.conf, the following entry in /etc/shorewall/masq resulted in -a startup error:
    + +
  14. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    15. + +
  15. 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.
    16. + +
  16. 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
    -
    -
    17. -
  17. 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).
    18. -
  18. Shorewall will now load module -files that are formed from the module name by appending ".o.gz".
    19. -
  19. 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.
    20. -
  20. The rfc1918 file has been -updated to reflect recent allocations.
    21. -
  21. The documentation of the USER -SET column in the rules file has been corrected.
    22. -
  22. 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
    -                                                                                                                                                                                    -
    +
    +
    23. + +
  23. 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).
    24. + +
  24. Shorewall will now load module files that are formed from the +module name by appending ".o.gz".
    25. + +
  25. 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.
    26. + +
  26. The rfc1918 file has been updated to reflect recent +allocations.
    27. + +
  27. The documentation of the USER SET column in the rules file has +been corrected.
    28. + +
  28. 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>
    -
    -
    29. -
  29. 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:
    -                                                                                                                                                                                    -
    +                                                                                                                                                                                   
    + +        No policy defined from +zone <source> to zone <dest>
    +
    +
    30. + +
  30. 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
    +    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.
    31. -
  31. The order of processing the -various options has been changed such that blacklist entries now take -precedence over the 'dhcp' interface -setting.
    32. -
  32. The log message generated from -the 'logunclean' interface option has been changed to reflect a -disposition of LOG rather than DROP.
    33. -
  33. 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.
    +
    +Shorewall now reports a fatal error if neither of these two files +exist and correctly removes the lock fille.
    34. + +
  34. The order of processing the various options has been changed +such that blacklist entries now take precedence over the 'dhcp' +interface setting.
    35. + +
  35. The log message generated from the 'logunclean' interface +option has been changed to reflect a disposition of LOG rather than +DROP.
    36. + +
  36. 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:
    +     Example:
     
    -    ACCEPT fw  net:192.0.2.12 tcp 23 - - - vladimir:
    -
    -
    37. -
  37. The /etc/shorewall/masq file has -had the spurious "/" character at the front removed.
    -
    -
    38. +     ACCEPT fw  net:192.0.2.12 tcp 23 - - - +vladimir:
    +
    + + +
  38. The /etc/shorewall/masq file +has had the spurious "/" character at the front removed.
    +
    +
+ 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 +
  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. -
  5. 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.
    -
    6. + +
  6. 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.
    +
+ New Features:
    -
  1. Thanks to Steve Herber, the 'help' command can now give +
  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.
    -
    + +
  4. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    5. -
  5. Given the wide range of VPN software, I can never hope to -add specific support for all of it. I have therefore decided to add +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    6. + +
  6. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add "generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +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
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.
    7. -
  7. An 'arp_filter' option has been added to the +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    8. + +
  8. 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.
    9. -
  9. 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. \
    10. -
  10. An /etc/shorewall/accounting file has been added to allow -for traffic accounting.  See the accounting -documentation for a description of this facility.
    11. -
  11. Bridge interfaces (br[0-9]) may now be used in +/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.
    12. + +
  12. 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. \
    13. + +
  13. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting documentation for a description of +this facility.
    14. + +
  14. Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.
    15. -
  15. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in + +
  16. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
     
    - Warning: When rate + 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.
    +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,
    -
    +To specify a rate limit,
    +
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
     
          < <rate>/<interval>[:<burst>] >
     
    -  -where
    +  where
     
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
          <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    +accepted within an <interval>. If not given, the default of 5 +is assumed.
     
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -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:
    -
    +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>]
     
    @@ -544,262 +643,309 @@ 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.
    -
    17. -
  17. Multiple chains may now be displayed in one "shorewall -show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
    18. -
  18. 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.
    19. +   
    +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.
    + + +
  19. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    20. + +
  20. 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.
+

10/02/2003 - Shorewall 1.4.7 RC2

-

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

+ +

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 +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables command.
    5. -
  5. The "shorewall stop" command is now disabled when + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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
    8. -
  8. Interface-specific dynamic blacklisting chains are -now displayed by "shorewall monitor" on the "Dynamic Chains" page +shooting themselves in the foot prior to having configured +Shorewall.
    9. + +
  9. 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
    10. + +
  10. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page (previously named "Dynamic Chain").
    11. -
  11. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    12. -
  12. 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.
    13. -
  13. When ADD_SNAT_ALIASES=Yes in -shorewall.conf, the following entry in /etc/shorewall/masq resulted in -a startup error:
    + +
  14. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    15. + +
  15. 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.
    16. + +
  16. 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
    -
    -
    17. -
  17. 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).
    18. -
  18. Shorewall will now load module -files that are formed from the module name by appending ".o.gz".
    19. -
  19. 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.
    20. -
  20. The rfc1918 file has been -updated to reflect recent allocations.
    21. -
  21. The documentation of the USER +
    +
    22. + +
  22. 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).
    23. + +
  23. Shorewall will now load module files that are formed from the +module name by appending ".o.gz".
    24. + +
  24. 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.
    25. + +
  25. The rfc1918 file has been updated to reflect recent +allocations.
    26. + +
  26. The documentation of the USER SET column in the rules file has been corrected.
    27. -
  27. If there is no policy defined + +
  28. 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 +                                                                                                                                                                                   
    + +         [: 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>
    -
    -
    29. -
  29. 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...
    +                                                                                                                                                                                   
    + +         No policy defined from +zone <source> to zone <dest>
    +
    +
    30. + +
  30. 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
    +    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.
    31. -
  31. The order of processing the -various options has been changed such that blacklist entries now take -precedence over the 'dhcp' interface setting.
    32. -
  32. The log message generated from +
    + Shorewall now reports a fatal error if neither of these two files +exist and correctly removes the lock fille.
    33. + +
  33. The order of processing the +various options has been changed such that blacklist entries now +take precedence over the 'dhcp' interface setting.
    34. + +
  34. The log message generated from the 'logunclean' interface option has been changed to reflect a disposition of LOG rather than DROP.
    35. -
  35. The RFC1918 file has been + +
  36. The RFC1918 file has been updated to reflect recent IANA allocations.
    -
    37. +
+ 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 +
  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. -
  5. 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.
    -
    6. + +
  6. 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.
    +
+ New Features:
    -
  1. Thanks to Steve Herber, the 'help' command can now give +
  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.
    -
    + +
  4. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    5. -
  5. Given the wide range of VPN software, I can never hope to -add specific support for all of it. I have therefore decided to add +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    6. + +
  6. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add "generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +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
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.
    7. -
  7. An 'arp_filter' option has been added to the +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    8. + +
  8. 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.
    9. -
  9. 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. \
    10. -
  10. An /etc/shorewall/accounting file has been added to allow -for traffic accounting.  See the accounting -documentation for a description of this facility.
    11. -
  11. Bridge interfaces (br[0-9]) may now be used in +/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.
    12. + +
  12. 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. \
    13. + +
  13. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting documentation for a description of +this facility.
    14. + +
  14. Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.
    15. -
  15. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in + +
  16. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
     
    - Warning: When rate + 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.
    +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,
    -
    +To specify a rate limit,
    +
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
     
          < <rate>/<interval>[:<burst>] >
     
    -  -where
    +  where
     
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
          <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    +accepted within an <interval>. If not given, the default of 5 +is assumed.
     
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -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:
    -
    +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>]
     
    @@ -809,221 +955,260 @@ 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.
    -
    17. -
  17. Multiple chains may now be displayed in one "shorewall -show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
    18. -
  18. 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.
    19. +   
    +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.
    + + +
  19. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    20. + +
  20. 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.
+

9/18/2003 - Shorewall 1.4.7 RC 1

-

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

+ +

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 +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables command.
    5. -
  5. The "shorewall stop" command is now disabled when + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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
    8. -
  8. Interface-specific dynamic blacklisting chains are -now displayed by "shorewall monitor" on the "Dynamic Chains" page +shooting themselves in the foot prior to having configured +Shorewall.
    9. + +
  9. 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
    10. + +
  10. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page (previously named "Dynamic Chain").
    11. -
  11. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    12. -
  12. 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.
    13. -
  13. When ADD_SNAT_ALIASES=Yes in -shorewall.conf, the following entry in /etc/shorewall/masq resulted in -a startup error:
    + +
  14. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    15. + +
  15. 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.
    16. + +
  16. 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
    -
    -
    17. -
  17. 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).
    18. -
  18. Shorewall will now load module -files that are formed from the module name by appending ".o.gz".
    19. -
  19. When Shorewall adds a route to a proxy -ARP host and such a route already exists, two routes resulted +
    +
    20. + +
  20. 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).
    21. + +
  21. Shorewall will now load module files that are formed from the +module name by appending ".o.gz".
    22. + +
  22. 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.
    23. -
  23. The rfc1918 file has been + +
  24. The rfc1918 file has been updated to reflect recent allocations.
    -
    25. +
+ 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 +
  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. -
  5. 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.
    -
    6. + +
  6. 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.
    +
+ New Features:
    -
  1. Thanks to Steve Herber, the 'help' command can now give +
  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.
    -
    + +
  4. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    5. -
  5. Given the wide range of VPN software, I can never hope to -add specific support for all of it. I have therefore decided to add +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    6. + +
  6. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add "generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +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
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.
    7. -
  7. An 'arp_filter' option has been added to the +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    8. + +
  8. 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.
    9. -
  9. 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. \
    10. -
  10. An /etc/shorewall/accounting file has been added to allow -for traffic accounting.  See the accounting -documentation for a description of this facility.
    11. -
  11. Bridge interfaces (br[0-9]) may now be used in +/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.
    12. + +
  12. 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. \
    13. + +
  13. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting documentation for a description of +this facility.
    14. + +
  14. Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.
    15. -
  15. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in + +
  16. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
     
    - Warning: When rate + 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.
    +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,
    -
    +To specify a rate limit,
    +
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
     
          < <rate>/<interval>[:<burst>] >
     
    -  -where
    +  where
     
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
          <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    +accepted within an <interval>. If not given, the default of 5 +is assumed.
     
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -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:
    -
    +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>]
     
    @@ -1033,424 +1218,255 @@ 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.
    -
    17. -
  17. Multiple chains may now be displayed in one "shorewall -show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
    18. -
  18. 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.
    19. +   
    +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.
    + + +
  19. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    20. + +
  20. 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.
-

9/15/2003 - Shorewall 1.4.7 Beta 2
+ +

9/15/2003 - Shorewall 1.4.7 Beta 2

-

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

+ +

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 +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables command.
    5. -
  5. The "shorewall stop" command is now disabled when + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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
    8. -
  8. Interface-specific dynamic blacklisting chains are -now displayed by "shorewall monitor" on the "Dynamic Chains" page +shooting themselves in the foot prior to having configured +Shorewall.
    9. + +
  9. 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
    10. + +
  10. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page (previously named "Dynamic Chain").
    11. -
  11. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    12. -
  12. 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.
    13. -
  13. When ADD_SNAT_ALIASES=Yes in -shorewall.conf, the following entry in /etc/shorewall/masq resulted in -a startup error:
    + +
  14. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    15. + +
  15. 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.
    16. + +
  16. 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
    -
    -
    17. -
  17. 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).
    18. -
  18. Shorewall will now load module -files that are formed from the module name by appending ".o.gz".
    -
    19. +
    + + +
  19. 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).
    20. + +
  20. Shorewall will now load module +files that are formed from the module name by appending +".o.gz".
    +
+ 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 +
  11. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page for details.
    12. -
-

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 + +
  3. The Uset Set capability introduced in SnapShot 20030821 has changed -- see the User Set page for details.
    4. -
  4. 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.
    -
    5. + +
  5. 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.
    +
+ New Features:
    -
  1. Thanks to Steve Herber, the 'help' command can now give +
  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.
    -
    + +
  4. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    5. -
  5. Given the wide range of VPN software, I can never hope to -add specific support for all of it. I have therefore decided to add +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
    6. + +
  6. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add "generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +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
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.
    7. -
  7. An 'arp_filter' option has been added to the +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    8. + +
  8. 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.
    9. -
  9. 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. \
    10. -
  10. An /etc/shorewall/accounting file has been added to allow -for traffic accounting.  See the accounting -documentation for a description of this facility.
    11. -
  11. Bridge interfaces (br[0-9]) may now be used in +/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.
    12. + +
  12. 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. \
    13. + +
  13. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting documentation for a description of +this facility.
    14. + +
  14. Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.
    15. -
  15. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in + +
  16. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
     
    - Warning: When rate + 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.
    +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,
    -
    +To specify a rate limit,
    +
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
     
          < <rate>/<interval>[:<burst>] >
     
    -  -where
    +  where
     
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
          <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    +accepted within an <interval>. If not given, the default of 5 +is assumed.
     
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -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:
    -
    +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>]
     
    @@ -1460,207 +1476,496 @@ 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.
    -
    17. -
  17. Multiple chains may now be displayed in one "shorewall -show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
    18. -
  18. 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.
    -
    19. +   
    +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.
    + + +
  19. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    20. + +
  20. 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.
-

8/23/2003 - Snapshot 1.4.6_20030823

-
-

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

-
+ +

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 +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables command.
    5. -
  5. The "shorewall stop" command is now disabled when + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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
    8. -
  8. Interface-specific dynamic blacklisting chains are -now displayed by "shorewall monitor" on the "Dynamic Chains" page +shooting themselves in the foot prior to having configured +Shorewall.
    9. + +
  9. 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
    10. + +
  10. Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page (previously named "Dynamic Chain").
    11. -
  11. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    -
    -
    12. + +
  12. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    +
    +
+ 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, +
  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. + +
  5. 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.
    +
    6. +
+ +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 + +
  5. Shorewall IP Traffic Accounting has changed since snapshot +20030813 -- see the Accounting Page +for details.
    6. + +
  6. The Uset Set capability introduced in SnapShot 20030821 has changed -- see the User Set page for details.
+ 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 +
  3. 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.
    4. + +
  4. Thanks to Steve Herber, the 'help' command can now give command-specific help (e.g., shorewall help <command>).
    5. -
  5. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of "No" -for existing users which causes Shorewall's 'stopped' state  to -continue as it has been; namely, in the stopped state only traffic -to/from hosts listed in /etc/shorewall/routestopped is accepted.
    -
    + +
  6. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    7. -
  7. Given the wide range of VPN software, I can never hope to -add specific support for all of it. I have therefore decided to add +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!!!
    8. + +
  8. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add "generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +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
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.
    9. -
  9. An 'arp_filter' option has been added to the +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    10. + +
  10. An 'arp_filter' option has been added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.
    11. -
  11. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter will -use all listed addresses/ranges in round-robin fashion. \
    12. -
  12. An /etc/shorewall/accounting file has been added to allow -for traffic accounting.  See the accounting -documentation for a description of this facility.
    13. -
  13. Bridge interfaces (br[0-9]) may now be used in +/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.
    14. + +
  14. 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. \
    15. + +
  15. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting documentation for a description of +this facility.
    16. + +
  16. Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.
    17. -
  17. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in + +
  18. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
     
    - Warning: When rate + 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.
    +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,
    -
    +To specify a rate limit,
    +
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
     
          < <rate>/<interval>[:<burst>] >
     
    -  -where
    +  where
     
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
          <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    +accepted within an <interval>. If not given, the default of 5 +is assumed.
     
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -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:
    -
    +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>]
     
    @@ -1670,194 +1975,228 @@ 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.
    -
    19. -
  19. Multiple chains may now be displayed in one "shorewall -show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
    20. -
  20. 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.
    -
    21. +   
    +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.
    + + +
  21. Multiple chains may now be displayed in one "shorewall show" +command (e.g., shorewall show INPUT FORWARD OUTPUT).
    22. + +
  22. 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.
    +
-

8/13/2003 - Snapshot 1.4.6_20030813 

+ +

8/13/2003 - Snapshot 1.4.6_20030813  +

+
-

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

+

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 +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables command.
    5. -
  5. The "shorewall stop" command is now disabled when + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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
    8. -
  8.  Interface-specific -dynamic blacklisting chains are now displayed by "shorewall monitor" on -the "Dynamic Chains" page (previously named "Dynamic Chain").
    -
    -
    9. +shooting themselves in the foot prior to having configured +Shorewall. + +
  9. 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
    10. + +
  10.  Interface-specific dynamic blacklisting chains are now +displayed by "shorewall monitor" on the "Dynamic Chains" page +(previously named "Dynamic Chain").
    +
    +
+ 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, +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. + +
  4. To maintain strict compatibility with previous versions, current uses of "shorewall drop" and "shorewall reject" should be -replaced with "shorewall dropall" and "shorewall rejectall"
    5. +replaced with "shorewall dropall" and "shorewall rejectall"
+ 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 +
  3. 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.
    4. + +
  4. Thanks to Steve Herber, the 'help' command can now give command-specific help (e.g., shorewall help <command>).
    5. -
  5. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of "No" -for existing users which causes Shorewall's 'stopped' state  to -continue as it has been; namely, in the stopped state only traffic -to/from hosts listed in /etc/shorewall/routestopped is accepted.
    -
    + +
  6. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    7. -
  7. Given the wide range of VPN software, I can never hope to -add specific support for all of it. I have therefore decided to add +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!!!
    8. + +
  8. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add "generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +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
    +       <protocol> is the +protocol used by the tunnel
    +       <port>  if the +protocol is 'udp' or 'tcp' then this is the destination port number +used by the tunnel.
    +       <zone>  is the zone +of the remote tunnel gateway
           <ip address> is the IP address of the remote tunnel gateway.
    -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.
    9. -
  9. An 'arp_filter' option has been added to the +       <gateway +zone>   Optional. A comma-separated list of zone +names. If specified, the remote gateway is to be considered part of +these zones.
    10. + +
  10. An 'arp_filter' option has been added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.
    11. -
  11. The -ADDRESS column in /etc/shorewall/masq may now include a comma-separated -list of addresses and/or address ranges. Netfilter will use all listed -addresses/ranges in round-robin fashion. \
    12. -
  12. An /etc/shorewall/accounting file has been added to allow for -traffic accounting.  See the accounting -documentation for a description of this facility.
    13. -
  13. Bridge interfaces (br[0-9]) may now be used in +/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.
    14. + +
  14. 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. \
    15. + +
  15. An /etc/shorewall/accounting file has been added to allow for +traffic accounting.  See the accounting documentation for a description of +this facility.
    16. + +
  16. Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.
    17. -
  17. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in + +
  18. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
    +corresponding ACCEPT rule in the filter table is not rate limited. +If you want to limit the filter table rule, you will need o create +two rules; a DNAT- rule and an ACCEPT rule which can be +rate-limited separately.
     
    - Warning: When rate -limiting -is specified on a rule with "all" in the SOURCE or DEST fields, the -limit will apply to each pair of zones individually rather than as a -single limit for all pairs of covered by the rule.
    + Warning: When rate +limiting is specified on a rule with "all" in the SOURCE or DEST +fields, the limit will apply to each pair of zones individually +rather than as a single limit for all pairs of covered by the +rule.
     
    -To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    +To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG +with
     
          < <rate>/<interval>[:<burst>] >
     
       where
     
    -      <rate> is the sustained rate per -<interval>
    -      <interval> is "sec" or "min"
    +      <rate> is the sustained rate +per <interval>
    +      <interval> is "sec" or +"min"
          <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
    +accepted within an <interval>. If not given, the default of 5 +is assumed.
     
    -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    +There may be no white space between the ACTION and "<" nor there +may be any white space within the burst specification. If you want +to specify logging of a rate-limited rule, the ":" and log level +comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
     
    Let's take an example:
     
    @@ -1865,534 +2204,639 @@ 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.
    -
    19. +   
    +The first time this rule is reached, the packet will be accepted; +in fact, since the burst is 4, the first four packets will be +accepted. After this, it will be 500ms (1 second divided by the +rate
    +of 2) before a packet will be accepted from this rule, regardless +of how many packets reach it. Also, every 500ms which passes +without matching a packet, one of the bursts will be regained; if +no packets hit the rule for 2 second, the burst will be fully +recharged; back where we started.
    +
-

8/9/2003 - Snapshot 1.4.6_20030809 

+ +

8/9/2003 - Snapshot 1.4.6_20030809  +

+
-

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

+

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 +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables command.
    5. -
  5. The -"shorewall stop" command is now disabled when + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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
    -
    8. +shooting themselves in the foot prior to having configured +Shorewall. + +
  8. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +   
    +The firewall script has been modified to eliminate the error +messages
    +
+ 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, +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. + +
  4. To maintain strict compatibility with previous versions, current uses of "shorewall drop" and "shorewall reject" should be -replaced with "shorewall dropall" and "shorewall rejectall"
    5. +replaced with "shorewall dropall" and "shorewall rejectall"
+ 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 +
  3. 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.
    4. + +
  4. Thanks to Steve Herber, the 'help' command can now give command-specific help (e.g., shorewall help <command>).
    5. -
  5. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of "No" -for existing users which causes Shorewall's 'stopped' state  to -continue as it has been; namely, in the stopped state only traffic -to/from hosts listed in /etc/shorewall/routestopped is accepted.
    -
    + +
  6. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    7. -
  7. Given -the wide range of VPN software, I can never hope to add specific -support for all of it. I have therefore decided to add "generic" tunnel -support.
    +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!!!
    8. + +
  8. Given the wide range of VPN software, I can never hope to add +specific support for all of it. I have therefore decided to add +"generic" tunnel support.
     
    -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those systems.
    +Generic tunnels work pretty much like any of the other tunnel +types. You usually add a zone to represent the systems at the other +end of the tunnel and you add the appropriate rules/policies to
    +implement your security policy regarding traffic to/from those +systems.
     
    -In the /etc/shorewall/tunnels file, you can have entries of the form:
    -
    -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
    +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
    +       <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 +       <gateway +zone>   Optional. A comma-separated list of zone names. If specified, the remote gateway is to be considered part of these zones.
    9. -
  9. An 'arp_filter' option has been added to the + +
  10. An 'arp_filter' option has been added to the /etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.
    -
    11. +/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with +the result that this interface will only answer ARP 'who-has' +requests from hosts that are routed out through that interface. +Setting this option facilitates testing of your firewall where +multiple firewall interfaces are connected to the same HUB/Switch +(all interfaces connected to the single HUB/Switch should have this +option specified). Note that using such a configuration in a +production environment is strongly recommended against.
    +
-

8/5/2003 - Shorewall-1.4.6b 
+ +

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 +
  2. Previously, if TC_ENABLED is set to yes in shorewall.conf then +Shorewall would fail to start with the error "ERROR:  Traffic Control requires Mangle"; that problem has been corrected.
    3. -
  3. Corrected handling of MAC addresses in the SOURCE column of -the + +
  4. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid -iptables -command.
    5. -
  5. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled -exists. This prevents people from shooting themselves in the foot prior -to -having configured Shorewall.
    6. -
  6. A change introduced in version 1.4.6 caused error messages -during -"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were -being -added to a PPP interface; the addresses were successfully added in -spite -of the messages.
    -  
    -The firewall script has been modified to eliminate the error messages.
    7. +iptables command. + +
  7. The "shorewall stop" command is now disabled when +/etc/shorewall/startup_disabled exists. This prevents people from +shooting themselves in the foot prior to having configured +Shorewall.
    8. + +
  8. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +  
    +The firewall script has been modified to eliminate the error +messages.
-

8/5/2003 - Shorewall-1.4.6b
+ +

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 +
  4. 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.
    5. + +
  5. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid +iptables command.
    6. + +
  6. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
    7. -
  7. 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.
    -
    8. +shooting themselves in the foot prior to having configured +Shorewall. + +
  8. A change introduced in version 1.4.6 caused error messages +during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip +addresses were being added to a PPP interface; the addresses were +successfully added in spite of the messages.
    +  
    +The firewall script has been modified to eliminate the error +messages.
    +
-

7/31/2003 - Snapshot 1.4.6_20030731

+ +

7/31/2003 - Snapshot 1.4.6_20030731

+
-

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

+

http://shorewall.net/pub/shorewall/Snapshots/
+ + ftp://shorewall.net/pub/shorewall/Snapshots/

+

Problems Corrected since version 1.4.6:

+
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was -being tested before it was set.
    2. -
  2. Corrected handling of MAC addresses in the SOURCE column of the +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command.
    -
    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. +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. + +
  4. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
-

New Features:
+ +

New Features:

+
    -
  1. Shorewall now creates a dynamic blacklisting chain for each -interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject' -commands use the routing table to determine which of these chains is to -be used for blacklisting the specified IP address(es).
    -
    -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 +
  3. 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.
    4. + +
  4. Thanks to Steve Herber, the 'help' command can now give command-specific help (e.g., shorewall help <command>).
    5. -
  5. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of "No" -for existing users which causes -Shorewall's 'stopped' state  to continue as it has been; namely, -in the -stopped state only traffic to/from hosts listed in -/etc/shorewall/routestopped -is accepted.
    -
    + +
  6. A new option "ADMINISABSENTMINDED" has been added to +/etc/shorewall/shorewall.conf. This option has a default value of +"No" for existing users which causes Shorewall's 'stopped' state + to continue as it has been; namely, in the stopped state only +traffic to/from hosts listed in /etc/shorewall/routestopped is +accepted.
    +
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; and
    +
    +   a) All traffic originating from the firewall itself; +and
       b) All traffic that is part of or related to an already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
    -
    +
    + 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   
    -
    +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!!!
    7. +fw        tcp    +22
    +
    +From a remote system, I ssh to 206.124.146.178 which establishes an +SSH connection with local system 192.168.1.5. I then create a +second SSH connection from that computer to the firewall and +confidently type "shorewall stop". As part of its stop processing, +Shorewall removes eth0:0 which kills my SSH connection to +192.168.1.5!!!
-

7/27/2003 - Snapshot 1.4.6_20030727

+ +

7/27/2003 - Snapshot 1.4.6_20030727

+
-

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

+

http://shorewall.net/pub/shorewall/Snapshots/
+ + ftp://shorewall.net/pub/shorewall/Snapshots/

+ Problems Corrected since version 1.4.6
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was -being tested before it was set.
    2. -
  2. Corrected handling of MAC addresses in the SOURCE column of the +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command.
    -
    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. +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. + +
  4. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
+ New Features:
    -
  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 +
  3. 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.
    4. + +
  4. Thanks to Steve Herber, the 'help' command can now give command-specific help (e.g., shorewall help <command>).
    -
    5. +
+

7/26/2003 - Snapshot 1.4.6_20030726

+
-

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

+

http://shorewall.net/pub/shorewall/Snapshots/
+ + ftp://shorewall.net/pub/shorewall/Snapshots/

+

Problems Corrected since version 1.4.6:

+
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was -being tested before it was set.
    2. -
  2. Corrected handling of MAC addresses in the SOURCE column of the +
  3. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable +was being tested before it was set.
    4. + +
  4. Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid -iptables -command.
    -
    5. +iptables command.
    +
+

Migration Issues:

+
    -
  1. Once you have installed this version of Shorewall, you must -restart Shorewall before you may use the 'drop', 'reject', 'allow' or -'save' commands.
    2. -
  2. To maintain strict compatibility with previous versions, current -uses of "shorewall drop" and "shorewall reject" should be replaced with -"shorewall dropall" and "shorewall rejectall"
    3. +
  3. Once you have installed this version of Shorewall, you must +restart Shorewall before you may use the 'drop', 'reject', 'allow' +or 'save' commands.
    4. + +
  4. To maintain strict compatibility with previous versions, +current uses of "shorewall drop" and "shorewall reject" should be +replaced with "shorewall dropall" and "shorewall rejectall"
+

New Features:

-Shorewall now creates a dynamic blacklisting chain for each 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).
+ +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
+Two new commands ('dropall' and 'rejectall') have been introduced +that do what 'drop' and 'reject' used to do; namely, when an +address is blacklisted using these new commands, it will be +blacklisted on all of your firewall's interfaces. + +

7/22/2003 - Shorewall-1.4.6a

+ Problems Corrected:
    -
  1. Previously, if TC_ENABLED is set to yes in shorewall.conf then +
  2. Previously, if TC_ENABLED is set to yes in shorewall.conf then Shorewall would fail to start with the error "ERROR:  Traffic -Control requires -Mangle"; that problem has been corrected.
    3. +Control requires Mangle"; that problem has been corrected.
-

7/20/2003 - Shorewall-1.4.6
+ +

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. +
  5. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    +
    6. + +
  6. 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.
    +
    +
    7. + +
  7. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a +rule.
    +
    +
    8. + +
  8. A number of problems with rule parsing have been corrected. Corrections involve the handling of "z1!z2" in the SOURCE column as well as lists in the ORIGINAL DESTINATION column.
    -
    -
    9. -
  9. The message "Adding rules for DHCP" is now suppressed if there +
    +
    10. + +
  10. The message "Adding rules for DHCP" is now suppressed if there are no DHCP rules to add.
    -
    11. +
+

Migration Issues:

+
    -
  1. In earlier versions, an undocumented feature allowed entries in +
  2. In earlier versions, an undocumented feature allowed entries in the host file as follows:
    -
    +
        z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    -
    -This capability was never documented and has been removed -in 1.4.6 to allow entries of the following format:
    -
    +
    +This capability was never documented and has been removed in 1.4.6 +to allow entries of the following format:
    +
        z   eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    3. -
  3. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now -automatically detected by Shorewall (see below).
    -
    4. +
    + + +
  4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are +now automatically detected by Shorewall (see below).
    +
+

New Features:

+
    -
  1. A 'newnotsyn' interface option has been added. This option may be -specified in /etc/shorewall/interfaces and overrides the setting +
  2. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No for packets arriving on the associated interface.
    -
    -
    3. -
  3. The means for specifying a range of IP addresses in +
    +
    4. + +
  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    -
    -
    5. -
  5. Shorewall can now add IP addresses to subnets other than the +
    +
    6. + +
  6. Shorewall can now add IP addresses to subnets other than the first one on an interface.
    -
    -
    7. -
  7. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses -given as <first address>-<last address>.
    -
    +
    +
    8. + +
  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of +addresses given as <first address>-<last address>.
    +
    Example:
    -
    +
        DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    9. -
  9. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report -the outcome:
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +
    +
    10. + +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    Verifying Configuration...
    -
    -
    11. -
  11. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables releases -and allows for rules which match against elements in netfilter's -connection tracking table. Shorewall automatically detects the -availability of this extension and reports its availability in the -output of the start, restart and check commands.
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +
    +
    12. + +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in +netfilter's connection tracking table. Shorewall automatically +detects the availability of this extension and reports its +availability in the output of the start, restart and check +commands.
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
       Connection Tracking Match: Available
    Verifying Configuration...
    -
    -If this extension is available, the ruleset generated by -Shorewall is changed in the following ways:
    13. -
      -
    • To handle 'norfc1918' filtering, Shorewall will not create -chains in the mangle table but will rather do all 'norfc1918' filtering -in the filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter rules; +
      +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
      • + +
    • +
        +
      • 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.
        -
        -
        • -
      -
    • The shell used to interpret the firewall script +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.
      +
      +
      • +
    + + +
  13. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    -
    14. -
  14. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -      ipcalc [ <address> <netmask> -| <address>/<vlsm> ]
    -
    +
    +
    15. + +
  15. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +      ipcalc [ <address> +<netmask> | <address>/<vlsm> ]
    +
    Examples:
    -
    +
          [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#
    -
    +
          [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#
    -
    +
    Warning:
    -
    -If your shell only supports 32-bit signed arithmatic (ash -or dash), then the ipcalc command produces incorrect information for -IP addresses 128.0.0.0-1 and for /1 networks. Bash should produce +
    +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.
    -
    -
    16. -
  16. 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.
    -
    +
    +
    17. + +
  17. 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
    +
    +      [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
    @@ -2405,18 +2849,20 @@ Example:
          192.168.12.0/29
          192.168.12.8/31
          [root@gateway root]#
    -
    -
    18. -
  18. A list of host/net addresses is now allowed in an entry in +
    +
    19. + +
  19. 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
    -
    -
    20. -
  20. The "shorewall check" command now includes the chain name when +
    +
    21. + +
  21. The "shorewall check" command now includes the chain name when printing the applicable policy for each pair of zones.
     
        Example:
    @@ -2424,186 +2870,223 @@ printing the applicable policy for each pair of zones.
            Policy for dmz to net is REJECT using chain all2all
     
    -This means that the policy for connections from the dmz to the internet -is REJECT and the applicable entry in the /etc/shorewall/policy was the -all->all policy.
    -
    -
    22. -
  22. Support for the 2.6 Kernel series has been added.
    -
    23. +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.
    +
    + + +
  23. Support for the 2.6 Kernel series has been added.
    +
+

7/15/2003 - New Mirror in Brazil

+ Thanks to the folks at securityopensource.org.br, there is now a Shorewall -mirror in Brazil. -

7/15/2003 - Shorewall-1.4.6 RC 1
+href="http://shorewall.securityopensource.org.br" target= +"_top">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 +
  3. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    +
    4. + +
  4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat table (one for each element in the list). Shorewall now -correctly -creates a single DNAT rule with multiple "--to-destination" clauses.
    -
    -
    5. -
  5. Corrected a problem in Beta 1 where DNS names containing a -"-" were mis-handled when they appeared in the DEST column of a rule.
    -
    -
    6. -
  6. A number of problems with rule parsing have been corrected. +correctly creates a single DNAT rule with multiple +"--to-destination" clauses.
    +
    +
    7. + +
  7. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a +rule.
    +
    +
    8. + +
  8. A number of problems with rule parsing have been corrected. Corrections involve the handling of "z1!z2" in the SOURCE column as well as lists in the ORIGINAL DESTINATION column.
    -
    9. +
+

Migration Issues:

+
    -
  1. In earlier versions, an undocumented feature allowed entries in +
  2. In earlier versions, an undocumented feature allowed entries in the host file as follows:
    -
    +
        z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    -
    -This capability was never documented and has been removed in 1.4.6 to -allow entries of the following format:
    -
    +
    +This capability was never documented and has been removed in 1.4.6 +to allow entries of the following format:
    +
        z   eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    3. -
  3. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have -been removed from /etc/shorewall/shorewall.conf. These capabilities are +
    +
    4. + +
  4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically detected by Shorewall (see below).
    -
    5. +
+

New Features:

+
    -
  1. A 'newnotsyn' interface option has been added. This option -may be specified in /etc/shorewall/interfaces and overrides the setting +
  2. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No for packets arriving on the associated interface.
    -
    -
    3. -
  3. The means for specifying a range of IP addresses in +
    +
    4. + +
  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    -
    -
    5. -
  5. Shorewall can now add IP addresses to subnets other than the +
    +
    6. + +
  6. Shorewall can now add IP addresses to subnets other than the first one on an interface.
    -
    -
    7. -
  7. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses -given as <first address>-<last address>.
    -
    +
    +
    8. + +
  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of +addresses given as <first address>-<last address>.
    +
    Example:
    -
    +
        DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    9. -
  9. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report the -outcome:
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +
    +
    10. + +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    Verifying Configuration...
    -
    -
    11. -
  11. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables releases -and allows for rules which match against elements in netfilter's -connection tracking table. Shorewall automatically detects the -availability of -this extension and reports its availability in the output of the start, -restart and check commands.
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +
    +
    12. + +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in +netfilter's connection tracking table. Shorewall automatically +detects the availability of this extension and reports its +availability in the output of the start, restart and check +commands.
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
       Connection Tracking Match: Available
    Verifying Configuration...
    -
    -If this extension is available, the ruleset generated by Shorewall is -changed in the following ways:
    13. -
      -
    • To handle 'norfc1918' filtering, Shorewall will not create -chains in the mangle table but will rather do all 'norfc1918' filtering -in the filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter rules; +
      +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
      • + +
    • +
        +
      • 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.
        -
        -
        • -
      -
    • The shell used to interpret the firewall script +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.
      +
      +
      • +
    + + +
  13. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    -
    14. -
  14. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -      ipcalc [ <address> <netmask> -| <address>/<vlsm> ]
    -
    +
    +
    15. + +
  15. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +      ipcalc [ <address> +<netmask> | <address>/<vlsm> ]
    +
    Examples:
    -
    +
          [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#
    -
    +
          [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#
    -
    +
    Warning:
    -
    +
    If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP addresses -128.0.0.0-1 and for /1 networks. Bash should produce correct -information for all valid IP addresses.
    -
    -
    16. -
  16. 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.
    -
    +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.
    +
    +
    17. + +
  17. 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
    +
    +      [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
    @@ -2616,176 +3099,211 @@ Example:
          192.168.12.0/29
          192.168.12.8/31
          [root@gateway root]#
    -
    -
    18. -
  18. A list of host/net addresses is now allowed in an entry in +
    +
    19. + +
  19. 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
+

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. +
  4. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    +
    5. + +
  5. 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.
    +
    +
    6. + +
  6. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a +rule.
    +
+

Migration Issues:

+
    -
  1. In earlier versions, an undocumented feature allowed entries in +
  2. In earlier versions, an undocumented feature allowed entries in the host file as follows:
    -
    +
        z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    -
    -This capability was never documented and has been removed in 1.4.6 to -allow entries of the following format:
    -
    +
    +This capability was never documented and has been removed in 1.4.6 +to allow entries of the following format:
    +
        z   eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    3. -
  3. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now -automatically detected by Shorewall (see below).
    -
    4. +
    + + +
  4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are +now automatically detected by Shorewall (see below).
    +
+

New Features:

+
    -
  1. A 'newnotsyn' interface option has been added. This option may be -specified in /etc/shorewall/interfaces and overrides the setting +
  2. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No for packets arriving on the associated interface.
    -
    -
    3. -
  3. The means for specifying a range of IP addresses in +
    +
    4. + +
  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    -
    -
    5. -
  5. Shorewall can now add IP addresses to subnets other than the +
    +
    6. + +
  6. Shorewall can now add IP addresses to subnets other than the first one on an interface.
    -
    -
    7. -
  7. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses -given as <first address>-<last address>.
    -
    +
    +
    8. + +
  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of +addresses given as <first address>-<last address>.
    +
    Example:
    -
    +
        DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    9. -
  9. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report -the outcome:
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +
    +
    10. + +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    Verifying Configuration...
    -
    -
    11. -
  11. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables releases -and allows for rules which match against elements in netfilter's -connection tracking table. Shorewall automatically detects the -availability of this extension and reports its availability in the -output of the start, restart and check commands.
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +
    +
    12. + +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in +netfilter's connection tracking table. Shorewall automatically +detects the availability of this extension and reports its +availability in the output of the start, restart and check +commands.
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
       Connection Tracking Match: Available
    Verifying Configuration...
    -
    -If this extension is available, the ruleset generated by Shorewall is -changed in the following ways:
    13. -
      -
    • To handle 'norfc1918' filtering, Shorewall will not create -chains in the mangle table but will rather do all 'norfc1918' filtering -in the filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter -rules; one in the nat table and one in the filter table. If the -Connection Tracking Match Extension is available, the rule in the -filter table is extended to check that the original destination address -was the same as specified (or defaulted to) in the DNAT rule.
      -
      -
      • -
    -
  13. The shell used to interpret the firewall script +
    +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
    14. + +
  14. +
      +
    • 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.
      +
      +
      • +
    +
    15. + +
  15. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    -
    16. -
  16. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -      ipcalc [ <address> <netmask> -| <address>/<vlsm> ]
    -
    +
    +
    17. + +
  17. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +      ipcalc [ <address> +<netmask> | <address>/<vlsm> ]
    +
    Examples:
    -
    +
          [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#
    -
    +
          [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -         CIDR=192.168.1.0/24
    -         NETMASK=255.255.255.0
    -         NETWORK=192.168.1.0
    -         BROADCAST=192.168.1.255
    +         +CIDR=192.168.1.0/24
    +         +NETMASK=255.255.255.0
    +         +NETWORK=192.168.1.0
    +         +BROADCAST=192.168.1.255
          [root@wookie root]#
    -
    +
    Warning:
    -
    +
    If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP addresses -128.0.0.0-1 and for /1 networks. Bash should produce correct -information for all valid IP addresses.
    -
    -
    18. -
  18. An 'iprange' command has been added to /sbin/shorewall.
    -
    -      iprange <address>-<address>
    -
    +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.
    +
    +
    19. + +
  19. 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.
    -
    +network and host addresses. The command can be useful if you need +to construct an efficient set of rules that accept connections from +a range of network addresses.
    +
    +Note: If your shell only supports 32-bit signed arithmetic (ash or +dash) then the range may not span 128.0.0.0.
    +
    Example:
    -
    -      [root@gateway root]# shorewall iprange -192.168.1.4-192.168.12.9
    +
    +      [root@gateway root]# shorewall +iprange 192.168.1.4-192.168.12.9
          192.168.1.4/30
          192.168.1.8/29
          192.168.1.16/28
    @@ -2798,205 +3316,250 @@ Example:
          192.168.12.0/29
          192.168.12.8/31
          [root@gateway root]#
    -
    -
    20. -
  20. A list of host/net addresses is now allowed in an entry in +
    +
    21. + +
  21. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
    -
    +
    Example:
    -
    +
        foo    eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    22. +
    +
+

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. +
  3. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been +worked around.
    +
    +
    4. + +
  4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in +the nat table (one for each element in the list). Shorewall now +correctly creates a single DNAT rule with multiple +"--to-destination" clauses.
    +
+

New Features:

+
    -
  1. A 'newnotsyn' interface option has been added. This option may be -specified in /etc/shorewall/interfaces and overrides the setting +
  2. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No for packets arriving on the associated interface.
    -
    -
    3. -
  3. The means for specifying a range of IP addresses in +
    +
    4. + +
  4. The means for specifying a range of IP addresses in /etc/shorewall/masq to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    -
    -
    5. -
  5. Shorewall can now add IP addresses to subnets other than the +
    +
    6. + +
  6. Shorewall can now add IP addresses to subnets other than the first one on an interface.
    -
    -
    7. -
  7. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Up to 256 servers may be specified in a range -of addresses given as <first address>-<last address>.
    -
    +
    +
    8. + +
  8. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Up to 256 servers may be specified in a +range of addresses given as <first address>-<last +address>.
    +
    Example:
    -
    +
        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.
    -
    -
    9. -
  9. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The -output of the start, restart and check commands have been enhanced to -report -the outcome:
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +
    +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.
    +
    +
    10. + +
  10. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that +detects whether these capabilities are present in the current +kernel. The output of the start, restart and check commands have +been enhanced to report the outcome:
    +
    +Shorewall has detected the following iptables/netfilter +capabilities:
       NAT: Available
       Packet Mangling: Available
       Multi-port Match: Available
    Verifying Configuration...
    -
    -
    11. -
  11. Support for the Connection Tracking Match Extension has -been added. This extension is available in recent kernel/iptables +
    +
    12. + +
  12. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables releases and allows for rules which match against elements in -netfilter's connection tracking table. Shorewall automatically detects -the availability of this extension and reports its availability in the -output of the start, restart and check commands.
    -
    -Shorewall has detected the following iptables/netfilter capabilities:
    +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:
    13. -
      -
    -
      -
    • To handle 'norfc1918' filtering, Shorewall will not create -chains in the mangle table but will rather do all 'norfc1918' filtering -in the filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter rules; +
      +If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
      • + +
    • +
        +
      • 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.
        -
        -
        • -
      -
    • The shell used to interpret the firewall script +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.
      +
      +
      • +
    + + +
  13. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    14. +
+

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; +
  3. The command "shorewall debug try <directory>" now +correctly traces the attempt.
    4. + +
  4. The INCLUDE directive now works properly in the zones file; previously, INCLUDE in that file was ignored.
    5. -
  5. /etc/shorewall/routestopped records with an empty second column + +
  6. /etc/shorewall/routestopped records with an empty second column are no longer ignored.
    -
    7. +
+

New Features:

+
    -
  1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now -contain a list of addresses. If the list begins with "!' then the rule -will take effect only if the original destination address in the -connection request does not match any of the addresses listed.
    2. +
  2. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may +now contain a list of addresses. If the list begins with "!' then +the rule will take effect only if the original destination address +in the connection request does not match any of the addresses +listed.
-

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

-

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

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

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'.
+ +The Fireparse --log-prefix fiasco continues. Tuomo Soini has +pointed out that the code in 1.4.4 restricts the length of short +zone names to 4 characters. I've produced version 1.4.4a that +restores the previous 5-character limit by conditionally omitting +the log rule number when the LOGFORMAT doesn't contain '%d'.

5/23/2003 - Shorewall-1.4.4

-I apologize for the rapid-fire releases but since there is a potential -configuration change required to go from 1.4.3a to 1.4.4, I decided to -make it a full release rather than just a bug-fix release.
+ +I apologize for the rapid-fire releases but since there is a +potential configuration change required to go from 1.4.3a to 1.4.4, +I decided to make it a full release rather than just a bug-fix +release.

    Problems corrected:
None.
+     New Features:
- + +
    -
  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:
    +
  3. 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.
    +
    +
    4. + +
  4. The LOGMARKER variable has been renamed LOGFORMAT and has been +changed to a 'printf' formatting template which accepts three +arguments (the chain name, logging rule number and the +disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it +as:
     
           LOGFORMAT="fp=%s:%d a=%s "
     
    - CAUTION: /sbin/shorewall uses the leading part of the -LOGFORMAT string (up to but not including the first '%') -to find log messages in the 'show log', 'status' and 'hits' commands. -This part should not be omitted (the LOGFORMAT should not begin with + 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.
    -
    -
    5. -
  5. When logging is specified on a DNAT[-] or REDIRECT[-] rule, the +
    +
    6. + +
  6. When logging is specified on a DNAT[-] or REDIRECT[-] rule, the logging now takes place in the nat table rather than in the filter -table. This way, only those connections that actually -undergo DNAT or redirection will be logged.
    -
    7. +table. This way, only those connections that actually undergo DNAT +or redirection will be logged.
    +
-

5/20/2003 - Shorewall-1.4.3a
+ +

5/20/2003 - Shorewall-1.4.3a

-This version primarily corrects the documentation included in the .tgz -and in the .rpm. In addition:
+ +This version primarily corrects the documentation included in the +.tgz and in the .rpm. In addition:
    -
  1. (This change is in 1.4.3 but is not documented) If you are -running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return -reject replies as follows:
    +
  2. (This change is in 1.4.3 but is not documented) If you are +running iptables 1.2.7a and kernel 2.4.20, then Shorewall will +return reject replies as follows:
       a) tcp - RST
       b) udp - ICMP port unreachable
       c) icmp - ICMP host unreachable
    @@ -3005,72 +3568,95 @@ If you are running earlier software, Shorewall will follow it's traditional convention:
       a) tcp - RST
       b) Otherwise - ICMP port unreachable
    3. -
  3. UDP port 135 is now silently dropped in the common.def chain. + +
  4. UDP port 135 is now silently dropped in the common.def chain. Remember that this chain is traversed just before a DROP or REJECT policy is enforced.
    -
    5. +
-

5/18/2003 - Shorewall 1.4.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. +
  3. There were several cases where Shorewall would fail to remove a +temporary directory from /tmp. These cases have been +corrected.
    4. + +
  4. The rules for allowing all traffic via the loopback interface +have been moved to before the rule that drops status=INVALID +packets. This insures that all loopback traffic is allowed even if +Netfilter connection tracking is confused.
+     New Features:
- + +
    -
  1.  IPV6-IPV4 (6to4) tunnels are now supported in the +
  2.  IPV6-IPV4 (6to4) tunnels are now supported in the /etc/shorewall/tunnels file.
    3. -
  3. You may now change the leading portion of the + +
  4. You may now change the leading portion of the --log-prefix used by Shorewall using the LOGMARKER variable in shorewall.conf. By default, "Shorewall:" is used.
    -
    5. +
+

5/10/2003 - Shorewall Mirror in Asia

+

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!

+

5/8/2003 - Shorewall Mirror in Chile

-Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile. -

4/21/2003 - Samples updated for Shorewall version 1.4.2

+ +Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago +Chile. + +

4/21/2003 - Samples updated for Shorewall version +1.4.2

+

Thanks to Francesca Smith, the sample configurations are now -upgraded to -Shorewall version 1.4.2.

+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 +
  3. 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.
    4. + +
  4. 'traceroute -I' from behind the firewall previously timed out +on the first hop (e.g., to the firewall). This has been worked +around.
    5. +
+ + +

    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.
    +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:
    @@ -3084,28 +3670,25 @@ the command.
       # Shorewall 1.3 /etc/shorewall/params
       [..]
       #######################################
    - 
    -   INCLUDE params.mgmt   
    - 
    + 
    +   INCLUDE params.mgmt   
    + 
       # params unique to this host here
    -   #LAST LINE - ADD YOUR ENTRIES ABOVE THIS -ONE - DO NOT REMOVE
    +   #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT +REMOVE
       ----- end params -----
     
     
       shorewall/rules.mgmt:
       ACCEPT net:$MGMT_SERVERS          -$FW    -tcp    22
    +$FW    tcp    22
       ACCEPT $FW          -net:$TIME_SERVERS    -udp    123
    +net:$TIME_SERVERS    udp    123
       ACCEPT $FW          -net:$BACKUP_SERVERS  -tcp    22
    +net:$BACKUP_SERVERS  tcp    22
       ----- end rules.mgmt -----
     
       shorewall/rules:
    @@ -3113,1715 +3696,2447 @@ tcp    22
       [..]
       #######################################
     
    -   INCLUDE rules.mgmt    
    - 
    +   INCLUDE rules.mgmt    
    + 
       # rules unique to this host here
    -   #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT -REMOVE
    +   #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO +NOT REMOVE
       ----- end rules -----
     
    INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives are ignored with a warning message.
    -
    -
    3. -
  3. Routing traffic from an interface back out that interface +
    +
    4. + +
  4. Routing traffic from an interface back out that interface continues to be a problem. While I firmly believe that this should never happen, people continue to want to do it. To limit the damage -that such nonsense produces, I have added a new 'routeback' option in -/etc/shorewall/interfaces and /etc/shorewall/hosts. When used in -/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; in -other words, 'routeback' can't be used as an option for a multi-zone -interface. The 'routeback' option CAN be specified however on -individual group entries in /etc/shorewall/hosts.
    +that such nonsense produces, I have added a new 'routeback' option +in /etc/shorewall/interfaces and /etc/shorewall/hosts. When used in +/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; +in other words, 'routeback' can't be used as an option for a +multi-zone interface. The 'routeback' option CAN be specified +however on individual group entries in /etc/shorewall/hosts.
     
    -The 'routeback' option is similar to the old 'multi' option with two -exceptions:
    +The 'routeback' option is similar to the old 'multi' option with +two exceptions:
     
       a) The option pertains to a particular zone,interface,address tuple.
     
    -   b) The option only created infrastructure to pass traffic -from (zone,interface,address) tuples back to themselves (the 'multi' -option affected all (zone,interface,address) tuples associated with the -given 'interface').
    +   b) The option only created infrastructure to pass +traffic from (zone,interface,address) tuples back to themselves +(the 'multi' option affected all (zone,interface,address) tuples +associated with the given 'interface').
     
    See the 'Upgrade Issues' for -information about how this new option may affect your configuration.
    -
    5. +information about how this new option may affect your +configuration.
    +
-

3/24/2003 - Shorewall 1.4.1

- -

This release follows up on 1.4.0. It corrects a problem introduced -in -1.4.0 and removes additional warts.
+ +

3/24/2003 - Shorewall 1.4.1

+ + + +

This release follows up on 1.4.0. It corrects a problem +introduced in 1.4.0 and removes additional warts.

Problems Corrected:

+
    -
  1. When Shorewall 1.4.0 is run under the ash shell (such as on +
  2. When Shorewall 1.4.0 is run under the ash shell (such as on Bering/LEAF), it can attempt to add ECN disabling rules even if the -/etc/shorewall/ecn file is empty. That problem has been corrected so -that ECN disabling rules are only added if there are entries in +/etc/shorewall/ecn file is empty. That problem has been corrected +so that ECN disabling rules are only added if there are entries in /etc/shorewall/ecn.
+ New Features:
-
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
+
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.
+ +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 +
  4. Beginning with Shorewall 1.4.1, if a zone Z comprises more than +one group then if there is no explicit Z to Z policy and +there are no rules governing traffic from Z to Z then Shorewall +will permit all traffic between the groups in the zone.
    5. + +
  5. Beginning with Shorewall 1.4.1, Shorewall will never create +rules to handle traffic from a group to itself.
    6. + +
  6. A NONE policy is introduced in 1.4.1. When a policy of NONE is specified from Z1 to Z2:
+
    -
  • There may be no rules created that govern connections from Z1 to -Z2.
    • -
  • Shorewall will not create any infrastructure to handle traffic +
  • 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.
+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:
+Function from 1.3 that has been omitted from this version +include:
    -
  1. The MERGE_HOSTS variable in shorewall.conf is no longer +
  2. The MERGE_HOSTS variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
    -
    -
    3. -
  3. Interface names of the form <device>:<integer> in +
    +
    4. + +
  4. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces now generate an error.
    -
    -
    5. -
  5. Shorewall 1.4 implements behavior consistent with -OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error at -startup as will specification of the 'noping' or 'filterping' interface -options.
    -
    -
    6. -
  6. 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.
    -
    -
    7. -
  7. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer -accepted.
    -
    -
    8. -
  8. The ALLOWRELATED variable in shorewall.conf is no longer +
    +
    9. + +
  9. 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.
    +
    +
    10. + +
  10. 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.
    +
    +
    11. + +
  11. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no +longer accepted.
    +
    +
    12. + +
  12. The ALLOWRELATED variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
    -
    -
    13. -
  13. The icmp.def file has been removed.
    -
    14. +
    + + +
  14. The icmp.def file has been removed.
    +
+ Changes for 1.4 include:
    -
  1. The /etc/shorewall/shorewall.conf file has been completely +
  2. The /etc/shorewall/shorewall.conf file has been completely reorganized into logical sections.
    -
    -
    3. -
  3. LOG is now a valid action for -a rule (/etc/shorewall/rules).
    -
    -
    4. -
  4. The firewall script and version file are now installed in +
    +
    5. + +
  5. LOG is now a valid action for a rule +(/etc/shorewall/rules).
    +
    +
    6. + +
  6. The firewall script and version file are now installed in /usr/share/shorewall.
    -
    -
    7. -
  7. Late arriving DNS replies are -now silently dropped in the common chain by default.
    -
    -
    8. -
  8. 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.
    -
    -
    9. -
  9. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
    10. -
  10. 802.11b devices with names of the form wlan<n> now support -the 'maclist' option.
    -
    -
    11. -
  11. 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:
    -
    +
    +
    12. + +
  12. Late arriving DNS replies are now silently dropped in the +common chain by default.
    +
    +
    13. + +
  13. 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.
    +
    +
    14. + +
  14. CONTINUE is now a valid action for a rule +(/etc/shorewall/rules).
    +
    +
    15. + +
  15. 802.11b devices with names of the form wlan<n> now +support the 'maclist' option.
    +
    +
    16. + +
  16. Explicit Congestion Notification (ECN - RFC 3168) may now be +turned off on a host or network basis using the new +/etc/shorewall/ecn file. To use this facility:
    +
       a) You must be running kernel 2.4.20
       b) You must have applied the patch in
       http://www.shorewall/net/pub/shorewall/ecn/patch.
       c) You must have iptables 1.2.7a installed.
    -
    -
    17. -
  17. The /etc/shorewall/params file is now processed first so that -variables may be used in the /etc/shorewall/shorewall.conf file.
    -
    -
    18. -
  18. Shorewall now gives a more helpful diagnostic when the -'ipchains' compatibility kernel module is loaded and a 'shorewall -start' command is issued.
    -
    -
    19. -
  19. 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.
    -
    -
    20. -
  20. Shorewall now ignores 'default' routes when detecting masq'd +
    +
    21. + +
  21. The /etc/shorewall/params file is now processed first so that +variables may be used in the /etc/shorewall/shorewall.conf +file.
    +
    +
    22. + +
  22. Shorewall now gives a more helpful diagnostic when +the 'ipchains' compatibility kernel module is loaded and a +'shorewall start' command is issued.
    +
    +
    23. + +
  23. The SHARED_DIR variable has been removed from shorewall.conf. +This variable was for use by package maintainers and was not +documented for general use.
    +
    +
    24. + +
  24. Shorewall now ignores 'default' routes when detecting masq'd networks.
+

3/10/2003 - Shoreall 1.3.14a

+

A roleup of the following bug fixes and other updates:

+
    -
  • There is an updated rfc1918 file that -reflects the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • +
  • 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> +
  • 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
    • + +
  • 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 +
  3. 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.
    +
    +
    4. + +
  4. It is now possible to direct Shorewall to create a "label" such as  "eth0:0" for IP addresses that it creates under -ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying -the label instead of just the interface name:
    +ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by +specifying the label instead of just the interface name:
     
       a) In the INTERFACE column of /etc/shorewall/masq
       b) In the INTERFACE column of /etc/shorewall/nat
     
    5. -
  5. Support for OpenVPN Tunnels.
    -
    -
    6. -
  6. Support for VLAN devices with names of the form $DEV.$VID (e.g., -eth0.0)
    -
    -
    7. -
  7. In /etc/shorewall/tcrules, the MARK value may be optionally + +
  8. Support for OpenVPN Tunnels.
    +
    +
    9. + +
  9. Support for VLAN devices with names of the form $DEV.$VID +(e.g., eth0.0)
    +
    +
    10. + +
  10. In /etc/shorewall/tcrules, the MARK value may be optionally followed by ":" and either 'F' or 'P' to designate that the marking -will occur in the FORWARD or PREROUTING chains respectively. If this -additional specification is omitted, the chain used to mark packets -will be determined by the setting of the MARK_IN_FORWARD_CHAIN option -in shorewall.conf.
    -
    -
    11. -
  11. When an interface name is -entered in the SUBNET column of the /etc/shorewall/masq file, Shorewall -previously masqueraded traffic from only -the first subnet defined on that interface. It did not masquerade -traffic from:
    +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.
    +
    +
    12. + +
  12. When an interface name is entered in the SUBNET column of the +/etc/shorewall/masq file, Shorewall previously masqueraded traffic +from only the first subnet defined on that interface. It did not +masquerade traffic from:
     
       a) The subnets associated with other addresses on the interface.
       b) Subnets accessed through local routers.
     
    -Beginning with Shorewall 1.3.14, if you enter an interface name in the -SUBNET column, -shorewall will use the firewall's routing table to construct the -masquerading/SNAT rules.
    +Beginning with Shorewall 1.3.14, if you enter an interface name in +the SUBNET column, shorewall will use the firewall's routing table +to construct the masquerading/SNAT rules.
     
    Example 1 -- This is how it works in 1.3.14.
    -  
    - 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    - 
       [root@gateway test]# shorewall start
       ...
       Masqueraded Subnets and Hosts:
           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
       Processing /etc/shorewall/tos...
    +  
    + + +
    +   [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.
    +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]#
    +  
    + + +
    +   [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.
    +   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]#
    + + +
    +   [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
    -
    13. +   In this case, you would want to change the entry +in  /etc/shorewall/masq to:
    + + +
    +   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    192.168.1.0/24          206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    +
+


-2/5/2003 - Shorewall Support -included in Webmin 1.060

-

Webmin version 1.060 now has Shorewall support included as standard. -See http://www.webmin.com.
+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.

+ +

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)

+ +

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 +
  3. 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.
    +
    +
    4. + +
  4. It is now possible to direct Shorewall to create a "label" such as  "eth0:0" for IP addresses that it creates under -ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying -the label instead of just the interface name:
    +ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by +specifying the label instead of just the interface name:
     
       a) In the INTERFACE column of /etc/shorewall/masq
       b) In the INTERFACE column of /etc/shorewall/nat
     
    5. -
  5. When an interface name is entered in the SUBNET column of the -/etc/shorewall/masq file, Shorewall previously masqueraded traffic from -only the first subnet defined on that interface. It did not masquerade -traffic from:
    + +
  6. When an interface name is entered in the SUBNET column of the +/etc/shorewall/masq file, Shorewall previously masqueraded traffic +from only the first subnet defined on that interface. It did not +masquerade traffic from:
     
       a) The subnets associated with other addresses on the interface.
       b) Subnets accessed through local routers.
     
    -Beginning with Shorewall 1.3.14, if you enter an interface name in the -SUBNET column, -shorewall will use the firewall's routing table to construct the -masquerading/SNAT rules.
    +Beginning with Shorewall 1.3.14, if you enter an interface name in +the SUBNET column, shorewall will use the firewall's routing table +to construct the masquerading/SNAT rules.
     
    Example 1 -- This is how it works in 1.3.14.
    -  
    - 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    - 
       [root@gateway test]# shorewall start
       ...
       Masqueraded Subnets and Hosts:
           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
       Processing /etc/shorewall/tos...
    +  
    + + +
    +   [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.
    +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]#
    +  
    + + +
    +   [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.
    +   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]#
    + + +
    +   [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. +   In this case, you would want to change the entry +in  /etc/shorewall/masq to:
    + + +
    +   #INTERFACE              SUBNET                  ADDRESS
    
+   eth0                    192.168.1.0/24          206.124.146.176
    
+   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
    + +
-

1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format

-

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 -documenation. the PDF may be downloaded from

-    ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-    http://slovakia.shorewall.net/pub/shorewall/pdf/ + +

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

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 +
  2. A new 'DNAT-' action has been added for entries in the /etc/shorewall/rules file. DNAT- is intended for advanced users who -wish -to minimize the number of rules that connection requests must traverse.
    -
    -A Shorewall DNAT rule actually generates two iptables rules: a header -rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter' -table. A DNAT- rule only generates the first of these rules. This is -handy when you have several DNAT rules that would generate the same -ACCEPT rule.
    -
    +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
    +
    +        DNAT   +net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
    +        DNAT   +net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
            ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
    -
    -   These three rules ended up generating _three_ copies of
    -
    +
    +   These three rules ended up generating _three_ copies +of
    +
             ACCEPT net  dmz:206.124.146.177 tcp smtp
    -
    -   By writing the rules this way, I end up with only one copy -of the ACCEPT rule.
    -
    +
    +   By writing the rules this way, I end up with only one +copy of the ACCEPT rule.
    +
            DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
            DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
            ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
    -
    -
    3. -
  3. The 'shorewall check' command now prints out the applicable +
    +
    4. + +
  4. The 'shorewall check' command now prints out the applicable policy between each pair of zones.
    -
    -
    5. -
  5. A new CLEAR_TC option has been added to shorewall.conf. If this -option is set to 'No' then Shorewall won't clear the current traffic -control rules during [re]start. This setting is intended for use by -people that prefer to configure traffic shaping when the network -interfaces come up rather than when the firewall is started. If that is -what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not -supply an /etc/shorewall/tcstart file. That way, your traffic shaping -rules can still use the 'fwmark' classifier based on packet marking -defined in /etc/shorewall/tcrules.
    -
    -
    6. -
  6. 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.
    -
    7. +
    + + +
  7. 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.
    +
    +
    8. + +
  8. A new SHARED_DIR variable has been added that allows +distribution packagers to easily move the shared directory (default +/usr/lib/shorewall). Users should never have a need to change the +value of this shorewall.conf setting.
    +
-

1/6/2003 - BURNOUT

-

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

+ +

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

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

Features include:

+
    -
  1. "shorewall refresh" now reloads the traffic shaping rules +
  2. "shorewall refresh" now reloads the traffic shaping rules (tcrules and tcstart).
    3. -
  3. "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.
    4. -
  4. "shorewall [re]start" has been speeded up by more than 40% with + +
  5. "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.
    6. + +
  6. "shorewall [re]start" has been speeded up by more than 40% with my configuration. Your milage may vary.
    7. -
  7. 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"
    8. -
  8. 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.
    9. -
  9. 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.
    10. -
  10. 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.
    11. -
  11. 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.
    -
    12. -
-

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 + +
  6. 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"
    7. + +
  7. 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.
    8. -
  8. 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.
    9. -
  9. 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.
    10. +from http://www.gnumonks.org/projects/ulogd) +and log all Shorewall messages to +a separate log file. + +
  10. 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.
    11. + +
  11. 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.
    12. + +
  12. 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.
    +
+ +

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
+
http://www.shorewall.net/pub/shorewall/Beta
+ + ftp://ftp.shorewall.net/pub/shorewall/Beta
-

12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux

+ +

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

+ Shorewall is at the center of MandrakeSoft's recently-announced Multi -Network Firewall (MNF) product. Here is the press +href= +"http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&id_art=250&LANG_=en#GOTO_250"> +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.

+ +

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.

+ +

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.

+ +

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

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

+ +

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.
+href="http://shorewall.sf.net" target= +"_top">http://shorewall.sf.net.

+

11/09/2002 - Shorewall 1.3.10

+

In this version:

+ -

10/24/2002 - Shorewall is now in Gentoo Linux
+ +

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

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

+ +

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

+

10/9/2002 - Shorewall 1.3.9b

-This release rolls up fixes to the installer and to the firewall script.
+ +This release rolls up fixes to the installer and to the firewall +script.

10/6/2002 - Shorewall.net now running on RH8.0

-The firewall and server here at shorewall.net are now running RedHat -release 8.0.
+The firewall and server here at shorewall.net are now running +RedHat release 8.0.

9/30/2002 - Shorewall 1.3.9a

+ Roles up the fix for broken tunnels.

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 + +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.
    -
    • +
  • 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:
+height="86" align="left"> 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. -
+
    +
  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. + +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:
+ +A couple of recent configuration changes at www.shorewall.net had +the negative effect of breaking the Search facility:
    -
  1. Mailing List Archive Search was not available.
    2. -
  2. The Site Search index was incomplete
    3. -
  3. Only one page of matches was presented.
    4. +
  4. Mailing List Archive Search was not available.
    5. + +
  5. The Site Search index was incomplete
    6. + +
  6. Only one page of matches was presented.
+ Hopefully these problems are now corrected.

9/18/2002 -  Debian 1.3.8 Packages Available

-

Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

+ +

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

    + +

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    +

    9/2/2002 - Shorewall 1.3.7c

    -

    This is a role up of a fix for "DNAT" rules where the source zone is -$FW (fw).

    + +

    This is a role up of a fix for "DNAT" rules where the source +zone is $FW (fw).

    +

    8/31/2002 - I'm not available

    +

    I'm currently on vacation  -- please respect my need for a couple of weeks free of Shorewall problem reports.

    +

    -Tom

    +

    8/26/2002 - Shorewall 1.3.7b

    -

    This is a role up of the "shorewall refresh" bug fix and the change -which reverses the order of "dhcp" and "norfc1918" checking.

    + +

    This is a role up of the "shorewall refresh" bug fix and the +change which reverses the order of "dhcp" and "norfc1918" +checking.

    +

    8/26/2002 - French FTP Mirror is Operational

    -

    ftp://france.shorewall.net/pub/mirrors/shorewall + +

    ftp://france.shorewall.net/pub/mirrors/shorewall is now available.

    +

    8/25/2002 - Shorewall Mirror in France

    -

    Thanks to a Shorewall user in Paris, the Shorewall web site is now -mirrored at http://france.shorewall.net.

    -

    8/25/2002 - Shorewall 1.3.7a Debian Packages Available

    -

    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 released

    + +

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

    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

    -

    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.

    + +

    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

    +section added to the Errata Page

    +

    Now there is one place to go to look for issues involved with upgrading to recent versions of Shorewall.

    +

    8/7/2002 - Shorewall 1.3.6

    -

    This is primarily a bug-fix rollup with a couple of new features:

    + +

    This is primarily a bug-fix rollup with a couple of new +features:

    + +

    7/30/2002 - Shorewall 1.3.5b Released

    +

    This interim release:

    +
      -
    • Causes the firewall script to remove the lock file if it is +
    • 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.
      • + +
    • 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.

    + +

    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.

    + +

    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.

    + +

    This interim release restores correct handling of REDIRECT +rules.

    +

    7/26/2002 - Shorewall 1.3.5 Released

    -

    This will be the last Shorewall release for a while. I'm going to be -focusing on rewriting a lot of the documentation.

    -

     In this version:

    + +

    This will be the last Shorewall release for a while. I'm going +to be focusing on rewriting a lot of the documentation.

    + +

      In this version:

    +
      -
    • Empty and invalid source and destination qualifiers are now +
    • 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 +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 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.
      • + +
    • 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!!!

    + +

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

    +href= +"http://security.dsi.unimi.it/%7Elorenzo/debian.html">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 +
    • 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 + +
    • 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 + +
    • 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 + +
    • 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.
      • + +
    • 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.

    + +

    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.

    +href= +"http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.

    +

    6/19/2002 - Documentation Available in PDF Format

    +

    Thanks to Mike Martinez, the Shorewall Documentation is now -available -for download in Adobe PDF format.

    +available for download in Adobe PDF format.

    +

    6/16/2002 - Shorewall 1.3.2 Released

    +

    In this version:

    + +

    6/6/2002 - Why CVS Web access is Password Protected

    +

    Last weekend, I installed the CVS Web package to provide -brower-based -access to the Shorewall CVS repository. Since then, I have had several -instances where my server was almost unusable due to the high load -generated -by website copying tools like HTTrack and WebStripper. These mindless -tools:

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

    + +

    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.

    +href= +"http://security.dsi.unimi.it/%7Elorenzo/debian.html">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.

    + +

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

    + +

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

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

    + +

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

    + +

    Thanks to Stefan +Mohr, there is now a mirror of the Shorewall website at http://germany.shorewall.net.

    + +

    4/10/2002 - Shorewall QuickStart Guide Version 1.1 +Available

    +

    Version 1.1 of the -QuickStart Guide is now available. Thanks to those who have read -version 1.0 and offered their suggestions. Corrections have also been -made to the sample scripts.

    -

    4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available

    +QuickStart Guide is now available. Thanks to those who have +read version 1.0 and offered their suggestions. Corrections have +also been made to the sample scripts.

    + +

    4/9/2002 - Shorewall QuickStart Guide Version 1.0 +Available

    +

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

    -

    4/8/2002 - Parameterized Samples Withdrawn

    -

    Although the parameterized +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 +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.

    + +

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

    + +

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

    + +

    See http://security.dsi.unimi.it/~lorenzo/debian.html

    +

    2/25/2002 - New Two-interface Sample

    +

    I've enhanced the two interface sample to allow access from the -firewall to servers in the local zone - -http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

    +firewall to servers in the local zone - +http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

    +

    2/23/2002 - Shorewall 1.2.8 Released

    +

    Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects problems associated with the lock file used to prevent multiple state-changing operations from occuring simultaneously. My -apologies for any inconvenience my carelessness may have caused.

    +apologies for any inconvenience my carelessness may have +caused.

    +

    2/22/2002 - Shorewall 1.2.7 Released

    +

    In this version:

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

    + +

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

    + +

    see http://security.dsi.unimi.it/~lorenzo/debian.html

    +

    2/1/2002 - Shorewall 1.2.5 Released

    -

    Due to installation problems with Shorewall 1.2.4, I have released -Shorewall 1.2.5. Sorry for the rapid-fire development.

    + +

    Due to installation problems with Shorewall 1.2.4, I have +released Shorewall 1.2.5. Sorry for the rapid-fire development.

    +

    In version 1.2.5:

    +
      -
    • 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.
      • +
    • 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 +
    • The "fw" zone may now be given a different name.
      • -
    • You may now place end-of-line comments (preceded by '#') in any + +
    • 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 + +
    • 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.
      • +'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/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.

    + +

    Corrects a problem with BLACKLIST_LOGLEVEL. See the errata for details.

    +

    1/19/2002 - Shorewall 1.2.3 Released

    -

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

    + +

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

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

    + +

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

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

    + +

    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:

    + +

    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

    +

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

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

    + +

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

    + +

    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:

    + +

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

    + +

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

    + +

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

    + +

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

    + -

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

    + +

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

    +
      -
    • Several columns in the rules file may now contain comma-separated -lists.
      • -
    • Shorewall is now more rigorous in parsing the options in +
    • 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.
      • + +
    • Complementation using "!" is now supported in rules.
    -

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

    + +

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

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

    +this version

    +
      -
    • Shorewall now enables Ipv4 Packet Forwarding by default. Packet +
    • 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. 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 + +
    • The "shorewall hits" command no longer lists extraneous service names in its last report.
      • -
    • Erroneous instructions in the comments at the head of the + +
    • 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

    +this version

    + +

    6/18/2001 - The current version of Shorewall is 1.1.8. In -this -version

    +this version

    + -

    6/2/2001 - The current version of Shorewall is 1.1.7. 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 +
    • 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

    +this version

    +
      -
    • You may now rate-limit the +
    • You may now rate-limit the packet log.
      • -
    • Previous versions of Shorewall have an implementation of Static + +
    • 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. 
      • +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

    +this version

    + +

    5/10/2001 - The current version of Shorewall is 1.1.4. In -this -version

    +this version

    +
      -
    • Accepting RELATED connections +
    • 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). 
      • + +
    • 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

    +this version

    +
      -
    • Correct message issued when Proxy ARP address added (Thanks to +
    • 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 + +
    • /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 + +
    • 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

    +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 +
    • 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.
      • + +
    • A couple of LRP-specific problems were corrected.
    -

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

    + +

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

    + +

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

    + +

    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 +
    • 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 + +
    • DMZ-related chains are now correctly deleted if the DMZ is deleted.
      • -
    • The interface OPTIONS for "gw" interfaces are no longer ignored.
      • + +
    • 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.

    -

    Updated 11/07/2003 - Tom Eastep -

    -

    Copyright © 2001, 2002 Thomas M. Eastep.
    + +

    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.

    + +

    Updated 11/07/2003 - Tom +Eastep

    + +

    Copyright © +2001, 2002 Thomas M. Eastep.

    +
    +