diff --git a/Shorewall-docs/Banner.html b/Shorewall-docs/Banner.html deleted file mode 100755 index a4fcd9ad8..000000000 --- a/Shorewall-docs/Banner.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - Banner - - - - - - - - - - - -
-
(Shorewall Logo)
- 		-
Note: Search -is unavailable Daily 0200-0330 GMT.
- -

Quick Search
-         Extended Search including Mailing -List Archives
-

-
-
- - diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm deleted file mode 100644 index c47758cab..000000000 --- a/Shorewall-docs/News.htm +++ /dev/null @@ -1,6142 +0,0 @@ - - - - - -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 -using some versions of 'ash'. The symptom is that "shorewall start" -fails with:
    - 
    -   local: --limit: bad variable name
    -   iptables v1.2.8: Couldn't load match -`-j':/lib/iptables/libipt_-j.so:
    -   cannot open shared object file: No such file or -directory
    -   Try `iptables -h' or 'iptables --help' for more -information.
    2. - -
  2. Andres Zhoglo has supplied a correction that avoids trying to -use the multiport match iptables facility on ICMP rules.
    - 
    -   Example of rule that previously caused "shorewall -start" to fail:
    - 
    -           -ACCEPT      loc  $FW  -icmp    0,8,11,12
    -
    -
    3. - -
  3. Previously, if the following error message was issued, -Shorewall was left in an inconsistent state.
    - 
    -   Error: Unable to determine the routes through -interface xxx
    -
    -
    4. - -
  4. Handling of the LOGUNCLEAN option in shorewall.conf has been -corrected.
    5. - -
  5. In Shorewall 1.4.2, an optimization was added. This -optimization involved creating a chain named "<zone>_frwd" -for most zones defined using the /etc/shorewall/hosts file. It has -since been discovered that in many cases these new chains contain -redundant rules and that the "optimization" turns out to be less -than optimal. The implementation has now been corrected.
    6. - -
  6. When the MARK value in a tcrules entry is followed by ":F" or -":P", the ":F" or ":P" was previously only applied to the first -Netfilter rule generated by the entry. It is now applied to all -entries.
    7. - -
  7. An incorrect comment concerning Debian's use of the SUBSYSLOCK -option has been removed from shorewall.conf.
    8. - -
  8. Previously, neither the 'routefilter' interface option nor the -ROUTE_FILTER parameter were working properly. This has been -corrected (thanks to Eric Bowles for his analysis and patch). The -definition of the ROUTE_FILTER option has changed however. -Previously, ROUTE_FILTER=Yes was documented as enabling route -filtering on all interfaces (which didn't work). Beginning with -this release, setting ROUTE_FILTER=Yes will enable route filtering -of all interfaces brought up while Shorewall is started. As a -consequence, ROUTE_FILTER=Yes can coexist with the use of the -'routefilter' option in the interfaces file.
    9. - -
  9. If MAC verification was enabled on an interface with a /32 -address and a broadcast address then an error would occur during -startup.
    10. - -
  10. The NONE policy's intended use is to suppress the generating of -rules that can't possibly be traversed. This means that a policy of -NONE is inappropriate where the source or destination zone is $FW -or "all". Shorewall now generates an error message if such a policy -is given in /etc/shorewall/policy. Previously such a policy caused -"shorewall start" to fail.
    11. - -
  11. The 'routeback' option was broken for wildcard interfaces -(e.g., "tun+"). This has been corrected so that 'routeback' now -works as expected in this case.
    -
    12. -
- -Migration Issues:
-
    -
  1. The definition of the ROUTE_FILTER option in shorewall.conf has -changed as described in item 8) above.
    -
    2. -
- -New Features:
-
    -
  1. A new QUEUE action has been introduced for rules. QUEUE allows -you to pass connection requests to a user-space filter such as -ftwall (http://p2pwall.sourceforge.net). The ftwall program allows -for effective filtering of p2p applications such as Kazaa. For -example, to use ftwall to filter P2P clients in the 'loc' zone, you -would add the following rules:
    -
    -   QUEUE   loc    -     net    tcp
    -   QUEUE   loc    -     net    udp
    -   QUEUE   loc    -     fw     udp
    -
    -You would normally want to place those three rules BEFORE any -ACCEPT rules for loc->net udp or tcp.
    -
    -Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), -Shorewall will only pass connection requests (SYN packets) to user -space. This is for compatibility with ftwall.
    2. - -
  2. A BLACKLISTNEWNONLY option has been added to shorewall.conf. -When this option is set to "Yes", the blacklists (dynamic and -static) are only consulted for new connection requests. When set to -"No" (the default if the variable is not set), the blacklists are -consulted on every packet.
    -
    -Setting this option to "No" allows blacklisting to stop existing -connections from a newly blacklisted host but is more expensive in -terms of packet processing time. This is especially true if the -blacklists contain a large number of entries.
    3. - -
  3. Chain names used in the /etc/shorewall/accounting file may now -begin with a digit ([0-9]) and may contain embedded dashes -("-").
    4. -
- -

10/30/2003 - Shorewall 1.4.8 RC1
-

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

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

- -
    -
  1. Tuomo Soini has supplied a correction to a problem that occurs -using some versions of 'ash'. The symptom is that "shorewall start" -fails with:
    - 
    -   local: --limit: bad variable name
    -   iptables v1.2.8: Couldn't load match -`-j':/lib/iptables/libipt_-j.so:
    -   cannot open shared object file: No such file or -directory
    -   Try `iptables -h' or 'iptables --help' for more -information.
    2. - -
  2. Andres Zhoglo has supplied a correction that avoids trying to -use the multiport match iptables facility on ICMP rules.
    - 
    -   Example of rule that previously caused "shorewall -start" to fail:
    - 
    -           -ACCEPT      loc  $FW  -icmp    0,8,11,12
    -
    -
    3. - -
  3. Previously, if the following error message was issued, -Shorewall was left in an inconsistent state.
    - 
    -   Error: Unable to determine the routes through -interface xxx
    -
    -
    4. - -
  4. Handling of the LOGUNCLEAN option in shorewall.conf has been -corrected.
    5. - -
  5. In Shorewall 1.4.2, an optimization was added. This -optimization involved creating a chain named "<zone>_frwd" -for most zones defined using the /etc/shorewall/hosts file. It has -since been discovered that in many cases these new chains contain -redundant rules and that the "optimization" turns out to be less -than optimal. The implementation has now been corrected.
    6. - -
  6. When the MARK value in a tcrules entry is followed by ":F" or -":P", the ":F" or ":P" was previously only applied to the first -Netfilter rule generated by the entry. It is now applied to all -entries.
    7. - -
  7. An incorrect comment concerning Debian's use of the SYBSYSLOCK -option has been removed from shorewall.conf.
    8. - -
  8. Previously, neither the 'routefilter' interface option nor the -ROUTE_FILTER parameter were working properly. This has been -corrected (thanks to Eric Bowles for his analysis and patch). The -definition of the ROUTE_FILTER option has changed however. -Previously, ROUTE_FILTER=Yes was documented as enabling route -filtering on all interfaces (which didn't work). Beginning with -this release, setting ROUTE_FILTER=Yes will enable route filtering -of all interfaces brought up while Shorewall is started. As a -consequence, ROUTE_FILTER=Yes can coexist with the use of the -'routefilter' option in the interfaces file.
    9. -
- -Migration Issues:
-
    -
  1. The definition of the ROUTE_FILTER option in shorewall.conf has -changed as described in item 8) above.
    -
    2. -
- -New Features:
-
    -
  1. A new QUEUE action has been introduced for rules. QUEUE allows -you to pass connection requests to a user-space filter such as -ftwall (http://p2pwall.sourceforge.net). The ftwall program allows -for effective filtering of p2p applications such as Kazaa. For -example, to use ftwall to filter P2P clients in the 'loc' zone, you -would add the following rules:
    -
    -   QUEUE   loc    -     net    tcp
    -   QUEUE   loc    -     net    udp
    -   QUEUE   loc    -     fw     udp
    -
    -You would normally want to place those three rules BEFORE any -ACCEPT rules for loc->net udp or tcp.
    -
    -Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), -Shorewall will only pass connection requests (SYN packets) to user -space. This is for compatibility with ftwall.
    2. - -
  2. A BLACKLISTNEWNONLY option has been added to shorewall.conf. -When this option is set to "Yes", the blacklists (dynamic and -static) are only consulted for new connection requests. When set to -"No" (the default if the variable is not set), the blacklists are -consulted on every packet.
    -
    -Setting this option to "No" allows blacklisting to stop existing -connections from a newly blacklisted host but is more expensive in -terms of packet processing time. This is especially true if the -blacklists contain a large number of entries.
    3. - -
  3. Chain names used in the /etc/shorewall/accounting file may now -begin with a digit ([0-9]) and may contain embedded dashes -("-").
    -
    4. -
- - - -

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

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

10/24/2003 - Shorewall 1.4.7b

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

10/21/2003 - Shorewall 1.4.7a
-

- -

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

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

10/06/2003 - Shorewall 1.4.7
-

- -Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 RC2).
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    3. - -
  3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured -Shorewall.
    4. - -
  4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip -addresses were being added to a PPP interface; the addresses were -successfully added in spite of the messages.
    -   
    -The firewall script has been modified to eliminate the error -messages
    5. - -
  5. Interface-specific dynamic blacklisting chains are now -displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").
    6. - -
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    7. - -
  7. The 'shorewall reject' and 'shorewall drop' commands -now delete any existing rules for the subject IP address before -adding a new DROP or REJECT rule. Previously, there could be many -rules for the same IP address in the dynamic chain so that multiple -'allow' commands were required to re-enable traffic to/from the -address.
    8. - -
  8. When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following -entry in /etc/shorewall/masq resulted in a startup error:
    - 
    -   eth0 eth1     -206.124.146.20-206.124.146.24
    -
    -
    9. - -
  9. Shorewall previously choked over IPV6 addresses configured on -interfaces in contexts where Shorewall needed to detect something -about the interface (such as when "detect" appears in the BROADCAST -column of the /etc/shorewall/interfaces file).
    10. - -
  10. Shorewall will now load module files that are formed from the -module name by appending ".o.gz".
    11. - -
  11. When Shorewall adds a route to a proxy ARP host and such a -route already exists, two routes resulted previously. This has been -corrected so that the existing route is replaced if it already -exists.
    12. - -
  12. The rfc1918 file has been updated to reflect recent -allocations.
    13. - -
  13. The documentation of the USER SET column in the rules file has -been corrected.
    14. - -
  14. If there is no policy defined for the zones specified in a -rule, the firewall script previously encountered a shell syntax -error:
    -                                                                                                                                                                                   
    - -        [: NONE: unexpected -operator
    -                                                                                                                                                                                   
    - -Now, the absence of a policy generates an error message and the -firewall is stopped:
    -                                                                                                                                                                                   
    - -        No policy defined from -zone <source> to zone <dest>
    -
    -
    15. - -
  15. Previously, if neither /etc/shorewall/common nor -/etc/shorewall/common.def existed, Shorewall would fail to start -and would not remove the lock file. Failure to remove the lock file -resulted in the following during subsequent attempts to start:
    -                                                                                                                                                                                   
    - -    Loading /usr/share/shorewall/functions...
    -    Processing /etc/shorewall/params ...
    -    Processing /etc/shorewall/shorewall.conf...
    -    Giving up on lock file -/var/lib/shorewall/lock
    -    Shorewall Not Started
    -
    -Shorewall now reports a fatal error if neither of these two files -exist and correctly removes the lock fille.
    16. - -
  16. The order of processing the various options has been changed -such that blacklist entries now take precedence over the 'dhcp' -interface setting.
    17. - -
  17. The log message generated from the 'logunclean' interface -option has been changed to reflect a disposition of LOG rather than -DROP.
    18. - -
  18. When a user name and/or a -group name was specified in the USER SET column and the destination -zone was qualified with a IP address, the user and/or group name -was not being used to qualify the rule.
    - 
    -     Example:
    - 
    -     ACCEPT fw  net:192.0.2.12 tcp 23 - - - -vladimir:
    -
    -
    19. - -
  19. The /etc/shorewall/masq file -has had the spurious "/" character at the front removed.
    -
    -
    20. -
- -Migration Issues:
-
    -
  1. Shorewall IP Traffic Accounting has changed since snapshot -20030813 -- see the Accounting Page -for details.
    2. - -
  2. The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page for -details.
    3. - -
  3. The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had -too many idiosyncrasies for dial-up users to be a viable part of -Shorewall.
    -
    4. -
- -New Features:
-
    -
  1. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    2. - -
  2. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of -"No" for existing users which causes Shorewall's 'stopped' state - to continue as it has been; namely, in the stopped state only -traffic to/from hosts listed in /etc/shorewall/routestopped is -accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; -and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall -stop" entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is -still possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    -22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an -SSH connection with local system 192.168.1.5. I then create a -second SSH connection from that computer to the firewall and -confidently type "shorewall stop". As part of its stop processing, -Shorewall removes eth0:0 which kills my SSH connection to -192.168.1.5!!!
    3. - -
  3. Given the wide range of VPN software, I can never hope to add -specific support for all of it. I have therefore decided to add -"generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel -types. You usually add a zone to represent the systems at the other -end of the tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those -systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the -form:
    -
    -generic:<protocol>[:<port>]  <zone>  -<ip address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the -protocol used by the tunnel
    -       <port>  if the -protocol is 'udp' or 'tcp' then this is the destination port number -used by the tunnel.
    -       <zone>  is the zone -of the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway -zone>   Optional. A comma-separated list of zone -names. If specified, the remote gateway is to be considered part of -these zones.
    4. - -
  4. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with -the result that this interface will only answer ARP 'who-has' -requests from hosts that are routed out through that interface. -Setting this option facilitates testing of your firewall where -multiple firewall interfaces are connected to the same HUB/Switch -(all interfaces connected to the single HUB/Switch should have this -option specified). Note that using such a configuration in a -production environment is strongly recommended against.
    5. - -
  5. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter -will use all listed addresses/ranges in round-robin fashion. \
    6. - -
  6. An /etc/shorewall/accounting file has been added to allow for -traffic accounting.  See the accounting documentation for a description of -this facility.
    7. - -
  7. Bridge interfaces (br[0-9]) may now be used in -/etc/shorewall/maclist.
    8. - -
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in -/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT -rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create -two rules; a DNAT- rule and an ACCEPT rule which can be -rate-limited separately.
    - 
    - Warning: When rate -limiting is specified on a rule with "all" in the SOURCE or DEST -fields, the limit will apply to each pair of zones individually -rather than as a single limit for all pairs of covered by the -rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate -per <interval>
    -      <interval> is "sec" or -"min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 -is assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there -may be any white space within the burst specification. If you want -to specify logging of a rate-limited rule, the ":" and log level -comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the -/etc/shorewall/rules file. You may specify the rate limit there in -the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; -in fact, since the burst is 4, the first four packets will be -accepted. After this, it will be 500ms (1 second divided by the -rate
    -of 2) before a packet will be accepted from this rule, regardless -of how many packets reach it. Also, every 500ms which passes -without matching a packet, one of the bursts will be regained; if -no packets hit the rule for 2 second, the burst will be fully -recharged; back where we started.
    -
    9. - -
  9. Multiple chains may now be displayed in one "shorewall show" -command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. - -
  10. Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html for -details.
    11. -
- -

10/02/2003 - Shorewall 1.4.7 RC2
-

- -

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

- -Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 RC 1).
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    3. - -
  3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured -Shorewall.
    4. - -
  4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip -addresses were being added to a PPP interface; the addresses were -successfully added in spite of the messages.
    -   
    -The firewall script has been modified to eliminate the error -messages
    5. - -
  5. Interface-specific dynamic blacklisting chains are now -displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").
    6. - -
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    7. - -
  7. The 'shorewall reject' and 'shorewall drop' commands -now delete any existing rules for the subject IP address before -adding a new DROP or REJECT rule. Previously, there could be many -rules for the same IP address in the dynamic chain so that multiple -'allow' commands were required to re-enable traffic to/from the -address.
    8. - -
  8. When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following -entry in /etc/shorewall/masq resulted in a startup error:
    - 
    -   eth0 eth1     -206.124.146.20-206.124.146.24
    -
    -
    9. - -
  9. Shorewall previously choked over IPV6 addresses configured on -interfaces in contexts where Shorewall needed to detect something -about the interface (such as when "detect" appears in the BROADCAST -column of the /etc/shorewall/interfaces file).
    10. - -
  10. Shorewall will now load module files that are formed from the -module name by appending ".o.gz".
    11. - -
  11. When Shorewall adds a route to a proxy ARP host and such a -route already exists, two routes resulted previously. This has been -corrected so that the existing route is replaced if it already -exists.
    12. - -
  12. The rfc1918 file has been updated to reflect recent -allocations.
    13. - -
  13. The documentation of the USER -SET column in the rules file has been corrected.
    14. - -
  14. If there is no policy defined -for the zones specified in a rule, the firewall script previously -encountered a shell syntax error:
    -                                                                                                                                                                                   
    - -         [: NONE: unexpected -operator
    -                                                                                                                                                                                   
    - - Now, the absence of a policy generates an error message and the -firewall is stopped:
    -                                                                                                                                                                                   
    - -         No policy defined from -zone <source> to zone <dest>
    -
    -
    15. - -
  15. Previously, if neither -/etc/shorewall/common nor /etc/shorewall/common.def existed, -Shorewall would fail to start and would not remove the lock file. -Failure to remove the lock file resulted in the following during -subsequent attempts to start:
    -                                                                                                                                                                                   
    - -     Loading /usr/share/shorewall/functions...
    -    Processing /etc/shorewall/params ...
    -    Processing /etc/shorewall/shorewall.conf...
    -    Giving up on lock file -/var/lib/shorewall/lock
    -    Shorewall Not Started
    -
    - Shorewall now reports a fatal error if neither of these two files -exist and correctly removes the lock fille.
    16. - -
  16. The order of processing the -various options has been changed such that blacklist entries now -take precedence over the 'dhcp' interface setting.
    17. - -
  17. The log message generated from -the 'logunclean' interface option has been changed to reflect a -disposition of LOG rather than DROP.
    18. - -
  18. The RFC1918 file has been -updated to reflect recent IANA allocations.
    -
    19. -
- -Migration Issues:
-
    -
  1. Shorewall IP Traffic Accounting has changed since snapshot -20030813 -- see the Accounting Page -for details.
    2. - -
  2. The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page for -details.
    3. - -
  3. The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had -too many idiosyncrasies for dial-up users to be a viable part of -Shorewall.
    -
    4. -
- -New Features:
-
    -
  1. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    2. - -
  2. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of -"No" for existing users which causes Shorewall's 'stopped' state - to continue as it has been; namely, in the stopped state only -traffic to/from hosts listed in /etc/shorewall/routestopped is -accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; -and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall -stop" entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is -still possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    -22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an -SSH connection with local system 192.168.1.5. I then create a -second SSH connection from that computer to the firewall and -confidently type "shorewall stop". As part of its stop processing, -Shorewall removes eth0:0 which kills my SSH connection to -192.168.1.5!!!
    3. - -
  3. Given the wide range of VPN software, I can never hope to add -specific support for all of it. I have therefore decided to add -"generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel -types. You usually add a zone to represent the systems at the other -end of the tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those -systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the -form:
    -
    -generic:<protocol>[:<port>]  <zone>  -<ip address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the -protocol used by the tunnel
    -       <port>  if the -protocol is 'udp' or 'tcp' then this is the destination port number -used by the tunnel.
    -       <zone>  is the zone -of the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway -zone>   Optional. A comma-separated list of zone -names. If specified, the remote gateway is to be considered part of -these zones.
    4. - -
  4. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with -the result that this interface will only answer ARP 'who-has' -requests from hosts that are routed out through that interface. -Setting this option facilitates testing of your firewall where -multiple firewall interfaces are connected to the same HUB/Switch -(all interfaces connected to the single HUB/Switch should have this -option specified). Note that using such a configuration in a -production environment is strongly recommended against.
    5. - -
  5. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter -will use all listed addresses/ranges in round-robin fashion. \
    6. - -
  6. An /etc/shorewall/accounting file has been added to allow for -traffic accounting.  See the accounting documentation for a description of -this facility.
    7. - -
  7. Bridge interfaces (br[0-9]) may now be used in -/etc/shorewall/maclist.
    8. - -
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in -/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT -rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create -two rules; a DNAT- rule and an ACCEPT rule which can be -rate-limited separately.
    - 
    - Warning: When rate -limiting is specified on a rule with "all" in the SOURCE or DEST -fields, the limit will apply to each pair of zones individually -rather than as a single limit for all pairs of covered by the -rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate -per <interval>
    -      <interval> is "sec" or -"min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 -is assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there -may be any white space within the burst specification. If you want -to specify logging of a rate-limited rule, the ":" and log level -comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the -/etc/shorewall/rules file. You may specify the rate limit there in -the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; -in fact, since the burst is 4, the first four packets will be -accepted. After this, it will be 500ms (1 second divided by the -rate
    -of 2) before a packet will be accepted from this rule, regardless -of how many packets reach it. Also, every 500ms which passes -without matching a packet, one of the bursts will be regained; if -no packets hit the rule for 2 second, the burst will be fully -recharged; back where we started.
    -
    9. - -
  9. Multiple chains may now be displayed in one "shorewall show" -command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. - -
  10. Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html for -details.
    11. -
- -

9/18/2003 - Shorewall 1.4.7 RC 1
-

- -

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

- -Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 Beta 1).
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    3. - -
  3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured -Shorewall.
    4. - -
  4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip -addresses were being added to a PPP interface; the addresses were -successfully added in spite of the messages.
    -   
    -The firewall script has been modified to eliminate the error -messages
    5. - -
  5. Interface-specific dynamic blacklisting chains are now -displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").
    6. - -
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    7. - -
  7. The 'shorewall reject' and 'shorewall drop' commands -now delete any existing rules for the subject IP address before -adding a new DROP or REJECT rule. Previously, there could be many -rules for the same IP address in the dynamic chain so that multiple -'allow' commands were required to re-enable traffic to/from the -address.
    8. - -
  8. When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following -entry in /etc/shorewall/masq resulted in a startup error:
    - 
    -   eth0 eth1     -206.124.146.20-206.124.146.24
    -
    -
    9. - -
  9. Shorewall previously choked over IPV6 addresses configured on -interfaces in contexts where Shorewall needed to detect something -about the interface (such as when "detect" appears in the BROADCAST -column of the /etc/shorewall/interfaces file).
    10. - -
  10. Shorewall will now load module files that are formed from the -module name by appending ".o.gz".
    11. - -
  11. When Shorewall adds a route to a -proxy ARP host and such a route already exists, two routes resulted -previously. This has been corrected so that the existing route is -replaced if it already exists.
    12. - -
  12. The rfc1918 file has been -updated to reflect recent allocations.
    -
    13. -
- -Migration Issues:
-
    -
  1. Shorewall IP Traffic Accounting has changed since snapshot -20030813 -- see the Accounting Page -for details.
    2. - -
  2. The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page for -details.
    3. - -
  3. The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had -too many idiosyncrasies for dial-up users to be a viable part of -Shorewall.
    -
    4. -
- -New Features:
-
    -
  1. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    2. - -
  2. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of -"No" for existing users which causes Shorewall's 'stopped' state - to continue as it has been; namely, in the stopped state only -traffic to/from hosts listed in /etc/shorewall/routestopped is -accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; -and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall -stop" entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is -still possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    -22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an -SSH connection with local system 192.168.1.5. I then create a -second SSH connection from that computer to the firewall and -confidently type "shorewall stop". As part of its stop processing, -Shorewall removes eth0:0 which kills my SSH connection to -192.168.1.5!!!
    3. - -
  3. Given the wide range of VPN software, I can never hope to add -specific support for all of it. I have therefore decided to add -"generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel -types. You usually add a zone to represent the systems at the other -end of the tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those -systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the -form:
    -
    -generic:<protocol>[:<port>]  <zone>  -<ip address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the -protocol used by the tunnel
    -       <port>  if the -protocol is 'udp' or 'tcp' then this is the destination port number -used by the tunnel.
    -       <zone>  is the zone -of the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway -zone>   Optional. A comma-separated list of zone -names. If specified, the remote gateway is to be considered part of -these zones.
    4. - -
  4. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with -the result that this interface will only answer ARP 'who-has' -requests from hosts that are routed out through that interface. -Setting this option facilitates testing of your firewall where -multiple firewall interfaces are connected to the same HUB/Switch -(all interfaces connected to the single HUB/Switch should have this -option specified). Note that using such a configuration in a -production environment is strongly recommended against.
    5. - -
  5. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter -will use all listed addresses/ranges in round-robin fashion. \
    6. - -
  6. An /etc/shorewall/accounting file has been added to allow for -traffic accounting.  See the accounting documentation for a description of -this facility.
    7. - -
  7. Bridge interfaces (br[0-9]) may now be used in -/etc/shorewall/maclist.
    8. - -
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in -/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT -rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create -two rules; a DNAT- rule and an ACCEPT rule which can be -rate-limited separately.
    - 
    - Warning: When rate -limiting is specified on a rule with "all" in the SOURCE or DEST -fields, the limit will apply to each pair of zones individually -rather than as a single limit for all pairs of covered by the -rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate -per <interval>
    -      <interval> is "sec" or -"min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 -is assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there -may be any white space within the burst specification. If you want -to specify logging of a rate-limited rule, the ":" and log level -comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the -/etc/shorewall/rules file. You may specify the rate limit there in -the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; -in fact, since the burst is 4, the first four packets will be -accepted. After this, it will be 500ms (1 second divided by the -rate
    -of 2) before a packet will be accepted from this rule, regardless -of how many packets reach it. Also, every 500ms which passes -without matching a packet, one of the bursts will be regained; if -no packets hit the rule for 2 second, the burst will be fully -recharged; back where we started.
    -
    9. - -
  9. Multiple chains may now be displayed in one "shorewall show" -command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. - -
  10. Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html for -details.
    11. -
- -

9/15/2003 - Shorewall 1.4.7 Beta 2
-

- -

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

- -Problems Corrected since version 1.4.6 (Those in bold font were -corrected since 1.4.7 Beta 1).
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    3. - -
  3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured -Shorewall.
    4. - -
  4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip -addresses were being added to a PPP interface; the addresses were -successfully added in spite of the messages.
    -   
    -The firewall script has been modified to eliminate the error -messages
    5. - -
  5. Interface-specific dynamic blacklisting chains are now -displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").
    6. - -
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    7. - -
  7. The 'shorewall reject' and -'shorewall drop' commands now delete any existing rules for the -subject IP address before adding a new DROP or REJECT rule. -Previously, there could be many rules for the same IP address in -the dynamic chain so that multiple 'allow' commands were required -to re-enable traffic to/from the address.
    8. - -
  8. When ADD_SNAT_ALIASES=Yes in -shorewall.conf, the following entry in /etc/shorewall/masq resulted -in a startup error:
    - 
    -   eth0 eth1     -206.124.146.20-206.124.146.24
    -
    -
    9. - -
  9. Shorewall previously choked over -IPV6 addresses configured on interfaces in contexts where Shorewall -needed to detect something about the interface (such as when -"detect" appears in the BROADCAST column of the -/etc/shorewall/interfaces file).
    10. - -
  10. Shorewall will now load module -files that are formed from the module name by appending -".o.gz".
    -
    11. -
- -Migration Issues:
-
    -
  1. Shorewall IP Traffic Accounting has changed since snapshot -20030813 -- see the Accounting Page -for details.
    2. - -
  2. The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page for -details.
    3. - -
  3. The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had -too many idiosyncrasies for dial-up users to be a viable part of -Shorewall.
    -
    4. -
- -New Features:
-
    -
  1. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    2. - -
  2. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of -"No" for existing users which causes Shorewall's 'stopped' state - to continue as it has been; namely, in the stopped state only -traffic to/from hosts listed in /etc/shorewall/routestopped is -accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; -and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall -stop" entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is -still possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    -22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an -SSH connection with local system 192.168.1.5. I then create a -second SSH connection from that computer to the firewall and -confidently type "shorewall stop". As part of its stop processing, -Shorewall removes eth0:0 which kills my SSH connection to -192.168.1.5!!!
    3. - -
  3. Given the wide range of VPN software, I can never hope to add -specific support for all of it. I have therefore decided to add -"generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel -types. You usually add a zone to represent the systems at the other -end of the tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those -systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the -form:
    -
    -generic:<protocol>[:<port>]  <zone>  -<ip address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the -protocol used by the tunnel
    -       <port>  if the -protocol is 'udp' or 'tcp' then this is the destination port number -used by the tunnel.
    -       <zone>  is the zone -of the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway -zone>   Optional. A comma-separated list of zone -names. If specified, the remote gateway is to be considered part of -these zones.
    4. - -
  4. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with -the result that this interface will only answer ARP 'who-has' -requests from hosts that are routed out through that interface. -Setting this option facilitates testing of your firewall where -multiple firewall interfaces are connected to the same HUB/Switch -(all interfaces connected to the single HUB/Switch should have this -option specified). Note that using such a configuration in a -production environment is strongly recommended against.
    5. - -
  5. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter -will use all listed addresses/ranges in round-robin fashion. \
    6. - -
  6. An /etc/shorewall/accounting file has been added to allow for -traffic accounting.  See the accounting documentation for a description of -this facility.
    7. - -
  7. Bridge interfaces (br[0-9]) may now be used in -/etc/shorewall/maclist.
    8. - -
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in -/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT -rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create -two rules; a DNAT- rule and an ACCEPT rule which can be -rate-limited separately.
    - 
    - Warning: When rate -limiting is specified on a rule with "all" in the SOURCE or DEST -fields, the limit will apply to each pair of zones individually -rather than as a single limit for all pairs of covered by the -rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate -per <interval>
    -      <interval> is "sec" or -"min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 -is assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there -may be any white space within the burst specification. If you want -to specify logging of a rate-limited rule, the ":" and log level -comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the -/etc/shorewall/rules file. You may specify the rate limit there in -the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; -in fact, since the burst is 4, the first four packets will be -accepted. After this, it will be 500ms (1 second divided by the -rate
    -of 2) before a packet will be accepted from this rule, regardless -of how many packets reach it. Also, every 500ms which passes -without matching a packet, one of the bursts will be regained; if -no packets hit the rule for 2 second, the burst will be fully -recharged; back where we started.
    -
    9. - -
  9. Multiple chains may now be displayed in one "shorewall show" -command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. - -
  10. Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html for -details.
    11. -
- -

8/27/2003 - Shorewall Mirror in Australia

- -

Thanks to Dave Kempe and Solutions First (http://www.solutionsfirst.com.au), there is now a -Shorewall Mirror in Australia:

- -
http://www.shorewall.com.au
-ftp://ftp.shorewall.com.au
- -

8/26/2003 - French Version of the Shorewall Setup -Guide 

- -Thanks to Fabien Demassieux, there is now a French translation of the Shorewall -Setup Guide. Merci Beacoup, Fabien! - -

8/25/2003 - Shorewall 1.4.7 Beta 1
-

- -

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

- -Problems Corrected since version 1.4.6
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    3. - -
  3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured -Shorewall.
    4. - -
  4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip -addresses were being added to a PPP interface; the addresses were -successfully added in spite of the messages.
    -   
    -The firewall script has been modified to eliminate the error -messages
    5. - -
  5. Interface-specific dynamic blacklisting chains are now -displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").
    6. - -
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    -
    -
    7. -
- -Migration Issues:
-
    -
  1. Shorewall IP Traffic Accounting has changed since snapshot -20030813 -- see the Accounting Page -for details.
    2. - -
  2. The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page for -details.
    3. - -
  3. The per-interface Dynamic Blacklisting facility introduced in -the first post-1.4.6 Snapshot has been removed. The facility had -too many idiosyncrasies for dial-up users to be a viable part of -Shorewall.
    -
    4. -
- -New Features:
-
    -
  1. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    2. - -
  2. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of -"No" for existing users which causes Shorewall's 'stopped' state - to continue as it has been; namely, in the stopped state only -traffic to/from hosts listed in /etc/shorewall/routestopped is -accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; -and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall -stop" entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is -still possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    -22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an -SSH connection with local system 192.168.1.5. I then create a -second SSH connection from that computer to the firewall and -confidently type "shorewall stop". As part of its stop processing, -Shorewall removes eth0:0 which kills my SSH connection to -192.168.1.5!!!
    3. - -
  3. Given the wide range of VPN software, I can never hope to add -specific support for all of it. I have therefore decided to add -"generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel -types. You usually add a zone to represent the systems at the other -end of the tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those -systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the -form:
    -
    -generic:<protocol>[:<port>]  <zone>  -<ip address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the -protocol used by the tunnel
    -       <port>  if the -protocol is 'udp' or 'tcp' then this is the destination port number -used by the tunnel.
    -       <zone>  is the zone -of the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway -zone>   Optional. A comma-separated list of zone -names. If specified, the remote gateway is to be considered part of -these zones.
    4. - -
  4. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with -the result that this interface will only answer ARP 'who-has' -requests from hosts that are routed out through that interface. -Setting this option facilitates testing of your firewall where -multiple firewall interfaces are connected to the same HUB/Switch -(all interfaces connected to the single HUB/Switch should have this -option specified). Note that using such a configuration in a -production environment is strongly recommended against.
    5. - -
  5. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter -will use all listed addresses/ranges in round-robin fashion. \
    6. - -
  6. An /etc/shorewall/accounting file has been added to allow for -traffic accounting.  See the accounting documentation for a description of -this facility.
    7. - -
  7. Bridge interfaces (br[0-9]) may now be used in -/etc/shorewall/maclist.
    8. - -
  8. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in -/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT -rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create -two rules; a DNAT- rule and an ACCEPT rule which can be -rate-limited separately.
    - 
    - Warning: When rate -limiting is specified on a rule with "all" in the SOURCE or DEST -fields, the limit will apply to each pair of zones individually -rather than as a single limit for all pairs of covered by the -rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate -per <interval>
    -      <interval> is "sec" or -"min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 -is assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there -may be any white space within the burst specification. If you want -to specify logging of a rate-limited rule, the ":" and log level -comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the -/etc/shorewall/rules file. You may specify the rate limit there in -the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; -in fact, since the burst is 4, the first four packets will be -accepted. After this, it will be 500ms (1 second divided by the -rate
    -of 2) before a packet will be accepted from this rule, regardless -of how many packets reach it. Also, every 500ms which passes -without matching a packet, one of the bursts will be regained; if -no packets hit the rule for 2 second, the burst will be fully -recharged; back where we started.
    -
    9. - -
  9. Multiple chains may now be displayed in one "shorewall show" -command (e.g., shorewall show INPUT FORWARD OUTPUT).
    10. - -
  10. Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html for -details.
    -
    11. -
- -

8/23/2003 - Snapshot 1.4.6_20030823

- -
-

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

-
- -Problems Corrected since version 1.4.6
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    3. - -
  3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured -Shorewall.
    4. - -
  4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip -addresses were being added to a PPP interface; the addresses were -successfully added in spite of the messages.
    -   
    -The firewall script has been modified to eliminate the error -messages
    5. - -
  5. Interface-specific dynamic blacklisting chains are now -displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").
    6. - -
  6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
    -
    -
    7. -
- -Migration Issues:
-
    -
  1. Once you have installed this version of Shorewall, you must -restart Shorewall before you may use the 'drop', 'reject', 'allow' -or 'save' commands.
    2. - -
  2. To maintain strict compatibility with previous versions, -current uses of "shorewall drop" and "shorewall reject" should be -replaced with "shorewall dropall" and "shorewall rejectall"
    3. - -
  3. Shorewall IP Traffic Accounting has changed since snapshot -20030813 -- see the Accounting Page -for details.
    4. - -
  4. The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page for -details.
    5. -
- -New Features:
-
    -
  1. Shorewall now creates a dynamic blacklisting chain for each -interface defined in /etc/shorewall/interfaces. The 'drop' and -'reject' commands use the routing table to determine which of these -chains is to be used for blacklisting the specified IP -address(es).
    -
    -Two new commands ('dropall' and 'rejectall') have been introduced -that do what 'drop' and 'reject' used to do; namely, when an -address is blacklisted using these new commands, it will be -blacklisted on all of your firewall's interfaces.
    2. - -
  2. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    3. - -
  3. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of -"No" for existing users which causes Shorewall's 'stopped' state - to continue as it has been; namely, in the stopped state only -traffic to/from hosts listed in /etc/shorewall/routestopped is -accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; -and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall -stop" entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is -still possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    -22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an -SSH connection with local system 192.168.1.5. I then create a -second SSH connection from that computer to the firewall and -confidently type "shorewall stop". As part of its stop processing, -Shorewall removes eth0:0 which kills my SSH connection to -192.168.1.5!!!
    4. - -
  4. Given the wide range of VPN software, I can never hope to add -specific support for all of it. I have therefore decided to add -"generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel -types. You usually add a zone to represent the systems at the other -end of the tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those -systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the -form:
    -
    -generic:<protocol>[:<port>]  <zone>  -<ip address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the -protocol used by the tunnel
    -       <port>  if the -protocol is 'udp' or 'tcp' then this is the destination port number -used by the tunnel.
    -       <zone>  is the zone -of the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway -zone>   Optional. A comma-separated list of zone -names. If specified, the remote gateway is to be considered part of -these zones.
    5. - -
  5. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with -the result that this interface will only answer ARP 'who-has' -requests from hosts that are routed out through that interface. -Setting this option facilitates testing of your firewall where -multiple firewall interfaces are connected to the same HUB/Switch -(all interfaces connected to the single HUB/Switch should have this -option specified). Note that using such a configuration in a -production environment is strongly recommended against.
    6. - -
  6. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter -will use all listed addresses/ranges in round-robin fashion. \
    7. - -
  7. An /etc/shorewall/accounting file has been added to allow for -traffic accounting.  See the accounting documentation for a description of -this facility.
    8. - -
  8. Bridge interfaces (br[0-9]) may now be used in -/etc/shorewall/maclist.
    9. - -
  9. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in -/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT -rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. -If you want to limit the filter table rule, you will need o create -two rules; a DNAT- rule and an ACCEPT rule which can be -rate-limited separately.
    - 
    - Warning: When rate -limiting is specified on a rule with "all" in the SOURCE or DEST -fields, the limit will apply to each pair of zones individually -rather than as a single limit for all pairs of covered by the -rule.
    - 
    -To specify a rate limit,
    -
    -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    - 
    -      < -<rate>/<interval>[:<burst>] >
    - 
    -  where
    - 
    -      <rate> is the sustained rate -per <interval>
    -      <interval> is "sec" or -"min"
    -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 -is assumed.
    - 
    -There may be no white space between the ACTION and "<" nor there -may be any white space within the burst specification. If you want -to specify logging of a rate-limited rule, the ":" and log level -comes after the ">" (e.g., ACCEPT<2/sec:4>:info ).
    -
    -b) A new RATE LIMIT column has been added to the -/etc/shorewall/rules file. You may specify the rate limit there in -the format:
    -
    -      -<rate>/<interval>[:<burst>]
    - 
    -Let's take an example:
    - 
    -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
    -   
    -The first time this rule is reached, the packet will be accepted; -in fact, since the burst is 4, the first four packets will be -accepted. After this, it will be 500ms (1 second divided by the -rate
    -of 2) before a packet will be accepted from this rule, regardless -of how many packets reach it. Also, every 500ms which passes -without matching a packet, one of the bursts will be regained; if -no packets hit the rule for 2 second, the burst will be fully -recharged; back where we started.
    -
    10. - -
  10. Multiple chains may now be displayed in one "shorewall show" -command (e.g., shorewall show INPUT FORWARD OUTPUT).
    11. - -
  11. Output rules (those with $FW as the SOURCE) may now be limited -to a set of local users and/or groups. See http://shorewall.net/UserSets.html for -details.
    -
    12. -
- -

8/13/2003 - Snapshot 1.4.6_20030813  -

- -
-

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

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

8/9/2003 - Snapshot 1.4.6_20030809  -

- -
-

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

-
- -Problems Corrected since version 1.4.6
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    3. - -
  3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured -Shorewall.
    4. - -
  4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip -addresses were being added to a PPP interface; the addresses were -successfully added in spite of the messages.
    -   
    -The firewall script has been modified to eliminate the error -messages
    -
    5. -
- -Migration Issues:
-
    -
  1. Once you have installed this version of Shorewall, you must -restart Shorewall before you may use the 'drop', 'reject', 'allow' -or 'save' commands.
    2. - -
  2. To maintain strict compatibility with previous versions, -current uses of "shorewall drop" and "shorewall reject" should be -replaced with "shorewall dropall" and "shorewall rejectall"
    3. -
- -New Features:
-
    -
  1. Shorewall now creates a dynamic blacklisting chain for each -interface defined in /etc/shorewall/interfaces. The 'drop' and -'reject' commands use the routing table to determine which of these -chains is to be used for blacklisting the specified IP -address(es).
    -
    -Two new commands ('dropall' and 'rejectall') have been introduced -that do what 'drop' and 'reject' used to do; namely, when an -address is blacklisted using these new commands, it will be -blacklisted on all of your firewall's interfaces.
    2. - -
  2. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    3. - -
  3. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of -"No" for existing users which causes Shorewall's 'stopped' state - to continue as it has been; namely, in the stopped state only -traffic to/from hosts listed in /etc/shorewall/routestopped is -accepted.
    -
    -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
    -
    -   a) All traffic originating from the firewall itself; -and
    -   b) All traffic that is part of or related to an -already-existing connection.
    -
    - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall -stop" entered through an ssh session will not kill the session.
    -
    - Note though that even with ADMINISABSENTMINDED=Yes, it is -still possible for people to shoot themselves in the foot.
    -
    - Example:
    -
    - /etc/shorewall/nat:
    -
    -     206.124.146.178    -eth0:0    192.168.1.5   
    -
    - /etc/shorewall/rules:
    -
    -   ACCEPT    net    -loc:192.168.1.5    tcp    22
    -   ACCEPT    loc    -fw        tcp    -22
    -
    -From a remote system, I ssh to 206.124.146.178 which establishes an -SSH connection with local system 192.168.1.5. I then create a -second SSH connection from that computer to the firewall and -confidently type "shorewall stop". As part of its stop processing, -Shorewall removes eth0:0 which kills my SSH connection to -192.168.1.5!!!
    4. - -
  4. Given the wide range of VPN software, I can never hope to add -specific support for all of it. I have therefore decided to add -"generic" tunnel support.
    - 
    -Generic tunnels work pretty much like any of the other tunnel -types. You usually add a zone to represent the systems at the other -end of the tunnel and you add the appropriate rules/policies to
    -implement your security policy regarding traffic to/from those -systems.
    - 
    -In the /etc/shorewall/tunnels file, you can have entries of the -form:
    -
    -generic:<protocol>[:<port>]  <zone>  -<ip address>    <gateway zones>
    - 
    -where:
    - 
    -       <protocol> is the -protocol used by the tunnel
    -       <port>  if the -protocol is 'udp' or 'tcp' then this is the destination port number -used by the tunnel.
    -       <zone>  is the zone -of the remote tunnel gateway
    -       <ip address> is the IP -address of the remote tunnel gateway.
    -       <gateway -zone>   Optional. A comma-separated list of zone -names. If specified, the remote gateway is to be considered part of -these zones.
    5. - -
  5. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with -the result that this interface will only answer ARP 'who-has' -requests from hosts that are routed out through that interface. -Setting this option facilitates testing of your firewall where -multiple firewall interfaces are connected to the same HUB/Switch -(all interfaces connected to the single HUB/Switch should have this -option specified). Note that using such a configuration in a -production environment is strongly recommended against.
    -
    6. -
- -

8/5/2003 - Shorewall-1.4.6b 
-

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

8/5/2003 - Shorewall-1.4.6b
-

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

7/31/2003 - Snapshot 1.4.6_20030731

- -
-

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

-
- -

Problems Corrected since version 1.4.6:
-

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

Migration Issues:
-

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

New Features:
-

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

7/27/2003 - Snapshot 1.4.6_20030727

- -
-

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

-
- -Problems Corrected since version 1.4.6
-
    -
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable -was being tested before it was set.
    2. - -
  2. Corrected handling of MAC addresses in the SOURCE column of the -tcrules file. Previously, these addresses resulted in an invalid -iptables command.
    -
    3. -
- -Migration Issues:
-
    -
  1. Once you have installed this version of Shorewall, you must -restart Shorewall before you may use the 'drop', 'reject', 'allow' -or 'save' commands.
    2. - -
  2. To maintain strict compatibility with previous versions, -current uses of "shorewall drop" and "shorewall reject" should be -replaced with "shorewall dropall" and "shorewall rejectall"
    3. -
- -New Features:
-
    -
  1. Shorewall now creates a dynamic blacklisting chain for each -interface defined in /etc/shorewall/interfaces. The 'drop' and -'reject' commands use the routing table to determine which of these -chains is to be used for blacklisting the specified IP -address(es).
    -
    -Two new commands ('dropall' and 'rejectall') have been introduced -that do what 'drop' and 'reject' used to do; namely, when an -address is blacklisted using these new commands, it will be -blacklisted on all of your firewall's interfaces.
    2. - -
  2. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
    -
    3. -
- -

7/26/2003 - Snapshot 1.4.6_20030726

- -
-

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

-
- -

Problems Corrected since version 1.4.6:
-

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

Migration Issues:
-

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

New Features:
-

- -Shorewall now creates a dynamic blacklisting chain for each -interface defined in /etc/shorewall/interfaces. The 'drop' and -'reject' commands use the routing table to determine which of these -chains is to be used for blacklisting the specified IP -address(es).
-
-Two new commands ('dropall' and 'rejectall') have been introduced -that do what 'drop' and 'reject' used to do; namely, when an -address is blacklisted using these new commands, it will be -blacklisted on all of your firewall's interfaces. - -

7/22/2003 - Shorewall-1.4.6a
-

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

7/20/2003 - Shorewall-1.4.6
-

- -

Problems Corrected:
-

- -
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been -worked around.
    -
    -
    2. - -
  2. Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in -the nat table (one for each element in the list). Shorewall now -correctly creates a single DNAT rule with multiple -"--to-destination" clauses.
    -
    -
    3. - -
  3. Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a -rule.
    -
    -
    4. - -
  4. A number of problems with rule parsing have been corrected. -Corrections involve the handling of "z1!z2" in the SOURCE column as -well as lists in the ORIGINAL DESTINATION column.
    -
    -
    5. - -
  5. The message "Adding rules for DHCP" is now suppressed if there -are no DHCP rules to add.
    -
    6. -
- -

Migration Issues:
-

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

New Features:
-

- -
    -
  1. A 'newnotsyn' interface option has been added. This option may -be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.
    -
    -
    2. - -
  2. The means for specifying a range of IP addresses in -/etc/shorewall/masq to use for SNAT is now documented. -ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    -
    -
    3. - -
  3. Shorewall can now add IP addresses to subnets other than the -first one on an interface.
    -
    -
    4. - -
  4. DNAT[-] rules may now be used to load balance (round-robin) -over a set of servers. Servers may be specified in a range of -addresses given as <first address>-<last address>.
    -
    -Example:
    -
    -    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    5. - -
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that -detects whether these capabilities are present in the current -kernel. The output of the start, restart and check commands have -been enhanced to report the outcome:
    -
    -Shorewall has detected the following iptables/netfilter -capabilities:
    -   NAT: Available
    -   Packet Mangling: Available
    -   Multi-port Match: Available
    -Verifying Configuration...
    -
    -
    6. - -
  6. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables -releases and allows for rules which match against elements in -netfilter's connection tracking table. Shorewall automatically -detects the availability of this extension and reports its -availability in the output of the start, restart and check -commands.
    -
    -Shorewall has detected the following iptables/netfilter -capabilities:
    -   NAT: Available
    -   Packet Mangling: Available
    -   Multi-port Match: Available
    -   Connection Tracking Match: Available
    -Verifying Configuration...
    -
    -If this extension is available, the ruleset generated by Shorewall -is changed in the following ways:
    7. - -
  7. - -
    8. - -
  8. The shell used to interpret the firewall script -(/usr/share/shorewall/firewall) may now be specified using the -SHOREWALL_SHELL parameter in shorewall.conf.
    -
    -
    9. - -
  9. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -      ipcalc [ <address> -<netmask> | <address>/<vlsm> ]
    -
    -Examples:
    -
    -      [root@wookie root]# shorewall ipcalc -192.168.1.0/24
    -         -CIDR=192.168.1.0/24
    -         -NETMASK=255.255.255.0
    -         -NETWORK=192.168.1.0
    -         -BROADCAST=192.168.1.255
    -      [root@wookie root]#
    -
    -      [root@wookie root]# shorewall ipcalc -192.168.1.0 255.255.255.0
    -         -CIDR=192.168.1.0/24
    -         -NETMASK=255.255.255.0
    -         -NETWORK=192.168.1.0
    -         -BROADCAST=192.168.1.255
    -      [root@wookie root]#
    -
    -Warning:
    -
    -If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP -addresses 128.0.0.0-1 and for /1 networks. Bash should produce -correct information for all valid IP addresses.
    -
    -
    10. - -
  10. An 'iprange' command has been added to /sbin/shorewall.
    -
    -      iprange -<address>-<address>
    -
    -This command decomposes a range of IP addressses into a list of -network and host addresses. The command can be useful if you need -to construct an efficient set of rules that accept connections from -a range of network addresses.
    -
    -Note: If your shell only supports 32-bit signed arithmetic (ash or -dash) then the range may not span 128.0.0.0.
    -
    -Example:
    -
    -      [root@gateway root]# shorewall -iprange 192.168.1.4-192.168.12.9
    -      192.168.1.4/30
    -      192.168.1.8/29
    -      192.168.1.16/28
    -      192.168.1.32/27
    -      192.168.1.64/26
    -      192.168.1.128/25
    -      192.168.2.0/23
    -      192.168.4.0/22
    -      192.168.8.0/22
    -      192.168.12.0/29
    -      192.168.12.8/31
    -      [root@gateway root]#
    -
    -
    11. - -
  11. A list of host/net addresses is now allowed in an entry in -/etc/shorewall/hosts.
    -
    -Example:
    -
    -    foo    -eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    12. - -
  12. The "shorewall check" command now includes the chain name when -printing the applicable policy for each pair of zones.
    - 
    -    Example:
    - 
    -        Policy for dmz to net is -REJECT using chain all2all
    - 
    -This means that the policy for connections from the dmz to the -internet is REJECT and the applicable entry in the -/etc/shorewall/policy was the all->all policy.
    -
    -
    13. - -
  13. Support for the 2.6 Kernel series has been added.
    -
    14. -
- -

7/15/2003 - New Mirror in Brazil
-

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

7/15/2003 - Shorewall-1.4.6 RC 1
-

- -

Problems Corrected:
-

- -
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been -worked around.
    -
    -
    2. - -
  2. Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in -the nat table (one for each element in the list). Shorewall now -correctly creates a single DNAT rule with multiple -"--to-destination" clauses.
    -
    -
    3. - -
  3. Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a -rule.
    -
    -
    4. - -
  4. A number of problems with rule parsing have been corrected. -Corrections involve the handling of "z1!z2" in the SOURCE column as -well as lists in the ORIGINAL DESTINATION column.
    -
    5. -
- -

Migration Issues:
-

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

New Features:
-

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

7/7/2003 - Shorewall-1.4.6 Beta 2

- -

Problems Corrected:
-

- -
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been -worked around.
    -
    -
    2. - -
  2. Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in -the nat table (one for each element in the list). Shorewall now -correctly creates a single DNAT rule with multiple -"--to-destination" clauses.
    -
    -
    3. - -
  3. Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a -rule.
    -
    4. -
- -

Migration Issues:
-

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

New Features:
-

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

7/4/2003 - Shorewall-1.4.6 Beta 1

- -

Problems Corrected:
-

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

New Features:
-

- -
    -
  1. A 'newnotsyn' interface option has been added. This option may -be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.
    -
    -
    2. - -
  2. The means for specifying a range of IP addresses in -/etc/shorewall/masq to use for SNAT is now documented. -ADD_SNAT_ALIASES=Yes is enabled for address ranges.
    -
    -
    3. - -
  3. Shorewall can now add IP addresses to subnets other than the -first one on an interface.
    -
    -
    4. - -
  4. DNAT[-] rules may now be used to load balance (round-robin) -over a set of servers. Up to 256 servers may be specified in a -range of addresses given as <first address>-<last -address>.
    -
    -Example:
    -
    -    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -Note that this capability has previously been available using a -combination of a DNAT- rule and one or more ACCEPT rules. That -technique is still preferable for load-balancing over a large -number of servers (> 16) since specifying a range in the DNAT -rule causes one filter table ACCEPT rule to be generated for each -IP address in the range.
    -
    -
    5. - -
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that -detects whether these capabilities are present in the current -kernel. The output of the start, restart and check commands have -been enhanced to report the outcome:
    -
    -Shorewall has detected the following iptables/netfilter -capabilities:
    -   NAT: Available
    -   Packet Mangling: Available
    -   Multi-port Match: Available
    -Verifying Configuration...
    -
    -
    6. - -
  6. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables -releases and allows for rules which match against elements in -netfilter's connection tracking table. Shorewall automatically -detects the availability of this extension and reports its -availability in the output of the start, restart and check -commands.
    -
    -Shorewall has detected the following iptables/netfilter -capabilities:
    -   NAT: Available
    -   Packet Mangling: Available
    -   Multi-port Match: Available
    -   Connection Tracking Match: Available
    -Verifying Configuration...
    -
    -If this extension is available, the ruleset generated by Shorewall -is changed in the following ways:
    7. - -
  7. - -
    8. - -
  8. The shell used to interpret the firewall script -(/usr/share/shorewall/firewall) may now be specified using the -SHOREWALL_SHELL parameter in shorewall.conf.
    -
    9. -
- -

6/17/2003 - Shorewall-1.4.5

- -

Problems Corrected:
-

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

New Features:
-

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

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

- -

The firewall at shorewall.net has been upgraded to the 2.4.21 -kernel and iptables 1.2.8 (using the "official" RPM from -netfilter.org). No problems have been encountered with this set of -software. The Shorewall version is 1.4.4b plus the accumulated -changes for 1.4.5.
-

- -

6/8/2003 - Updated Samples

- -

Thanks to Francesca Smith, the samples have been updated to -Shorewall version 1.4.4.

- -

5/29/2003 - Shorewall-1.4.4b

- -

Groan -- This version corrects a problem whereby the --log-level -was not being set when logging via syslog. The most commonly -reported symptom was that Shorewall messages were being written to -the console even though console logging was correctly configured -per FAQ 16.
-

- -

5/27/2003 - Shorewall-1.4.4a

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

5/23/2003 - Shorewall-1.4.4

- -I apologize for the rapid-fire releases but since there is a -potential configuration change required to go from 1.4.3a to 1.4.4, -I decided to make it a full release rather than just a bug-fix -release.
-
-    Problems corrected:
-
None.
-
- -    New Features:
- - -
    -
  1. A REDIRECT- rule target has been added. This target behaves for -REDIRECT in the same way as DNAT- does for DNAT in that the -Netfilter nat table REDIRECT rule is added but not the companion -filter table ACCEPT rule.
    -
    -
    2. - -
  2. The LOGMARKER variable has been renamed LOGFORMAT and has been -changed to a 'printf' formatting template which accepts three -arguments (the chain name, logging rule number and the -disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it -as:
    - 
    -       LOGFORMAT="fp=%s:%d a=%s "
    - 
    - CAUTION: /sbin/shorewall uses the leading part of the -LOGFORMAT string (up to but not including the first '%') to find -log messages in the 'show log', 'status' and 'hits' commands. This -part should not be omitted (the LOGFORMAT should not begin with -"%") and the leading part should be sufficiently unique for -/sbin/shorewall to identify Shorewall messages.
    -
    -
    3. - -
  3. When logging is specified on a DNAT[-] or REDIRECT[-] rule, the -logging now takes place in the nat table rather than in the filter -table. This way, only those connections that actually undergo DNAT -or redirection will be logged.
    -
    4. -
- -

5/20/2003 - Shorewall-1.4.3a
-

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

5/18/2003 - Shorewall 1.4.3
-

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

5/10/2003 - Shorewall Mirror in Asia
-

- -

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

- -

5/8/2003 - Shorewall Mirror in Chile

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

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

- -

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

- -

4/9/2003 - Shorewall 1.4.2
-

- -

    Problems Corrected:

- -
-
    -
  1. TCP connection requests rejected out of the common chain -are now properly rejected with TCP RST; previously, some of these -requests were rejected with an ICMP port-unreachable response.
    2. - -
  2. 'traceroute -I' from behind the firewall previously timed out -on the first hop (e.g., to the firewall). This has been worked -around.
    3. -
-
- -

    New Features:

- -
    -
  1. Where an entry in the/etc/shorewall/hosts file specifies a -particular host or network, Shorewall now creates an intermediate -chain for handling input from the related zone. This can -substantially reduce the number of rules traversed by connections -requests from such zones.
    -
    -
    2. - -
  2. Any file may include an INCLUDE directive. An INCLUDE directive -consists of the word INCLUDE followed by a file name and causes the -contents of the named file to be logically included into the file -containing the INCLUDE. File names given in an INCLUDE directive -are assumed to reside in /etc/shorewall or in an alternate -configuration directory if one has been specified for the -command.
    - 
    -   Examples:
    -   shorewall/params.mgmt:
    -   MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    -   TIME_SERVERS=4.4.4.4
    -   BACKUP_SERVERS=5.5.5.5
    -   ----- end params.mgmt -----
    - 
    - 
    -   shorewall/params:
    -   # Shorewall 1.3 /etc/shorewall/params
    -   [..]
    -   #######################################
    - 
    -   INCLUDE params.mgmt   
    - 
    -   # params unique to this host here
    -   #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT -REMOVE
    -   ----- end params -----
    - 
    - 
    -   shorewall/rules.mgmt:
    -   ACCEPT -net:$MGMT_SERVERS          -$FW    tcp    22
    -   ACCEPT -$FW          -net:$TIME_SERVERS    udp    123
    -   ACCEPT -$FW          -net:$BACKUP_SERVERS  tcp    22
    -   ----- end rules.mgmt -----
    - 
    -   shorewall/rules:
    -   # Shorewall version 1.3 - Rules File
    -   [..]
    -   #######################################
    - 
    -   INCLUDE rules.mgmt    
    - 
    -   # rules unique to this host here
    -   #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO -NOT REMOVE
    -   ----- end rules -----
    - 
    -INCLUDE's may be nested to a level of 3 -- further nested INCLUDE -directives are ignored with a warning message.
    -
    -
    3. - -
  3. Routing traffic from an interface back out that interface -continues to be a problem. While I firmly believe that this should -never happen, people continue to want to do it. To limit the damage -that such nonsense produces, I have added a new 'routeback' option -in /etc/shorewall/interfaces and /etc/shorewall/hosts. When used in -/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; -in other words, 'routeback' can't be used as an option for a -multi-zone interface. The 'routeback' option CAN be specified -however on individual group entries in /etc/shorewall/hosts.
    - 
    -The 'routeback' option is similar to the old 'multi' option with -two exceptions:
    - 
    -   a) The option pertains to a particular -zone,interface,address tuple.
    - 
    -   b) The option only created infrastructure to pass -traffic from (zone,interface,address) tuples back to themselves -(the 'multi' option affected all (zone,interface,address) tuples -associated with the given 'interface').
    - 
    -See the 'Upgrade Issues' for -information about how this new option may affect your -configuration.
    -
    4. -
- -

3/24/2003 - Shorewall 1.4.1

- - - -

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

- -
    -
  1. When Shorewall 1.4.0 is run under the ash shell (such as on -Bering/LEAF), it can attempt to add ECN disabling rules even if the -/etc/shorewall/ecn file is empty. That problem has been corrected -so that ECN disabling rules are only added if there are entries in -/etc/shorewall/ecn.
    2. -
- -New Features:
-
Note: In the list that follows, the term group -refers to a particular network or subnetwork (which may be -0.0.0.0/0 or it may be a host address) accessed through a -particular interface. Examples:
- - -
eth0:0.0.0.0/0
-eth2:192.168.1.0/24
-eth3:192.0.2.123
-
- -You can use the "shorewall check" command to see the groups -associated with each of your zones.
-
- -
    -
  1. Beginning with Shorewall 1.4.1, if a zone Z comprises more than -one group then if there is no explicit Z to Z policy and -there are no rules governing traffic from Z to Z then Shorewall -will permit all traffic between the groups in the zone.
    2. - -
  2. Beginning with Shorewall 1.4.1, Shorewall will never create -rules to handle traffic from a group to itself.
    3. - -
  3. A NONE policy is introduced in 1.4.1. When a policy of NONE is -specified from Z1 to Z2:
    4. -
- - - -See the upgrade issues for a -discussion of how these changes may affect your configuration. - -

3/17/2003 - Shorewall 1.4.0

- -Shorewall 1.4 represents the next step in the evolution of -Shorewall. The main thrust of the initial release is simply to -remove the cruft that has accumulated in Shorewall over time.
-
-IMPORTANT: Shorewall 1.4.0 requires the iproute package -('ip' utility).
-
-Function from 1.3 that has been omitted from this version -include:
-
    -
  1. The MERGE_HOSTS variable in shorewall.conf is no longer -supported. Shorewall 1.4 behavior is the same as 1.3 with -MERGE_HOSTS=Yes.
    -
    -
    2. - -
  2. Interface names of the form <device>:<integer> in -/etc/shorewall/interfaces now generate an error.
    -
    -
    3. - -
  3. Shorewall 1.4 implements behavior consistent with -OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error -at startup as will specification of the 'noping' or 'filterping' -interface options.
    -
    -
    4. - -
  4. The 'routestopped' option in the /etc/shorewall/interfaces and -/etc/shorewall/hosts files is no longer supported and will generate -an error at startup if specified.
    -
    -
    5. - -
  5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no -longer accepted.
    -
    -
    6. - -
  6. The ALLOWRELATED variable in shorewall.conf is no longer -supported. Shorewall 1.4 behavior is the same as 1.3 with -ALLOWRELATED=Yes.
    -
    -
    7. - -
  7. The icmp.def file has been removed.
    -
    8. -
- -Changes for 1.4 include:
-
    -
  1. The /etc/shorewall/shorewall.conf file has been completely -reorganized into logical sections.
    -
    -
    2. - -
  2. LOG is now a valid action for a rule -(/etc/shorewall/rules).
    -
    -
    3. - -
  3. The firewall script and version file are now installed in -/usr/share/shorewall.
    -
    -
    4. - -
  4. Late arriving DNS replies are now silently dropped in the -common chain by default.
    -
    -
    5. - -
  5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall -1.4 no longer unconditionally accepts outbound ICMP packets. So if -you want to 'ping' from the firewall, you will need the appropriate -rule or policy.
    -
    -
    6. - -
  6. CONTINUE is now a valid action for a rule -(/etc/shorewall/rules).
    -
    -
    7. - -
  7. 802.11b devices with names of the form wlan<n> now -support the 'maclist' option.
    -
    -
    8. - -
  8. Explicit Congestion Notification (ECN - RFC 3168) may now be -turned off on a host or network basis using the new -/etc/shorewall/ecn file. To use this facility:
    -
    -   a) You must be running kernel 2.4.20
    -   b) You must have applied the patch in
    -   http://www.shorewall/net/pub/shorewall/ecn/patch.
    -   c) You must have iptables 1.2.7a installed.
    -
    -
    9. - -
  9. The /etc/shorewall/params file is now processed first so that -variables may be used in the /etc/shorewall/shorewall.conf -file.
    -
    -
    10. - -
  10. Shorewall now gives a more helpful diagnostic when -the 'ipchains' compatibility kernel module is loaded and a -'shorewall start' command is issued.
    -
    -
    11. - -
  11. The SHARED_DIR variable has been removed from shorewall.conf. -This variable was for use by package maintainers and was not -documented for general use.
    -
    -
    12. - -
  12. Shorewall now ignores 'default' routes when detecting masq'd -networks.
    13. -
- -

3/10/2003 - Shoreall 1.3.14a

- -

A roleup of the following bug fixes and other updates:

- - - - - -

2/8/2003 - Shoreawall 1.3.14

- -

New features include

- -
    -
  1. An OLD_PING_HANDLING option has been added to shorewall.conf. -When set to Yes, Shorewall ping handling is as it has always been -(see http://www.shorewall.net/ping.html).
    -
    -When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules -and policies just like any other connection request. The -FORWARDPING=Yes option in shorewall.conf and the 'noping' and -'filterping' options in /etc/shorewall/interfaces will all generate -an error.
    -
    -
    2. - -
  2. It is now possible to direct Shorewall to create a "label" such -as  "eth0:0" for IP addresses that it creates under -ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by -specifying the label instead of just the interface name:
    - 
    -   a) In the INTERFACE column of /etc/shorewall/masq
    -   b) In the INTERFACE column of /etc/shorewall/nat
    - 
    3. - -
  3. Support for OpenVPN Tunnels.
    -
    -
    4. - -
  4. Support for VLAN devices with names of the form $DEV.$VID -(e.g., eth0.0)
    -
    -
    5. - -
  5. In /etc/shorewall/tcrules, the MARK value may be optionally -followed by ":" and either 'F' or 'P' to designate that the marking -will occur in the FORWARD or PREROUTING chains respectively. If -this additional specification is omitted, the chain used to mark -packets will be determined by the setting of the -MARK_IN_FORWARD_CHAIN option in shorewall.conf.
    -
    -
    6. - -
  6. When an interface name is entered in the SUBNET column of the -/etc/shorewall/masq file, Shorewall previously masqueraded traffic -from only the first subnet defined on that interface. It did not -masquerade traffic from:
    - 
    -   a) The subnets associated with other addresses on the -interface.
    -   b) Subnets accessed through local routers.
    - 
    -Beginning with Shorewall 1.3.14, if you enter an interface name in -the SUBNET column, shorewall will use the firewall's routing table -to construct the masquerading/SNAT rules.
    - 
    -Example 1 -- This is how it works in 1.3.14.
    -  
    - - -
    -   [root@gateway test]# cat /etc/shorewall/masq
    
-   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    eth2                    206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    - -
    -   [root@gateway test]# ip route show dev eth2
    
-   192.168.1.0/24  scope link
    
-   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
-
    - -
    -   [root@gateway test]# shorewall start
    
-   ...
    
-   Masqueraded Subnets and Hosts:
    
-       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
    
-       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
    
-   Processing /etc/shorewall/tos...
-
    - - 
    -When upgrading to Shorewall 1.3.14, if you have multiple local -subnets connected to an interface that is specified in the SUBNET -column of an /etc/shorewall/masq entry, your /etc/shorewall/masq -file will need changing. In most cases, you will simply be able to -remove redundant entries. In some cases though, you might want to -change from using the interface name to listing specific -subnetworks if the change described above will cause masquerading -to occur on subnetworks that you don't wish to masquerade.
    - 
    -Example 2 -- Suppose that your current config is as follows:
    -  
    - - -
    -   [root@gateway test]# cat /etc/shorewall/masq
    
-   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    eth2                    206.124.146.176
    
-   eth0                    192.168.10.0/24         206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    - -
    -   [root@gateway test]# ip route show dev eth2
    
-   192.168.1.0/24  scope link
    
-   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
-   [root@gateway test]#
-
    - - 
    -   In this case, the second entry in /etc/shorewall/masq -is no longer required.
    - 
    -Example 3 -- What if your current configuration is like this?
    - 
    - - -
    -   [root@gateway test]# cat /etc/shorewall/masq
    
-   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    eth2                    206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    - -
    -   [root@gateway test]# ip route show dev eth2
    
-   192.168.1.0/24  scope link
    
-   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
-   [root@gateway test]#
-
    - - 
    -   In this case, you would want to change the entry -in  /etc/shorewall/masq to:
    - - -
    -   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    192.168.1.0/24          206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    -
    7. -
- -


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

- -

Webmin version 1.060 now has Shorewall support included as -standard. See http://www.webmin.com.
-
-2/4/2003 - Shorewall 1.3.14-RC1

- -

Includes the Beta 2 content plus support for OpenVPN -tunnels.

- -

1/28/2003 - Shorewall 1.3.14-Beta2

- -

Includes the Beta 1 content plus restores VLAN device names of -the form $dev.$vid (e.g., eth0.1)

- -

1/25/2003 - Shorewall 1.3.14-Beta1
-

- -

The Beta includes the following changes:
-

- -
    -
  1. An OLD_PING_HANDLING option has been added to shorewall.conf. -When set to Yes, Shorewall ping handling is as it has always been -(see http://www.shorewall.net/ping.html).
    -
    -When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules -and policies just like any other connection request. The -FORWARDPING=Yes option in shorewall.conf and the 'noping' and -'filterping' options in /etc/shorewall/interfaces will all generate -an error.
    -
    -
    2. - -
  2. It is now possible to direct Shorewall to create a "label" such -as  "eth0:0" for IP addresses that it creates under -ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by -specifying the label instead of just the interface name:
    - 
    -   a) In the INTERFACE column of /etc/shorewall/masq
    -   b) In the INTERFACE column of /etc/shorewall/nat
    - 
    3. - -
  3. When an interface name is entered in the SUBNET column of the -/etc/shorewall/masq file, Shorewall previously masqueraded traffic -from only the first subnet defined on that interface. It did not -masquerade traffic from:
    - 
    -   a) The subnets associated with other addresses on the -interface.
    -   b) Subnets accessed through local routers.
    - 
    -Beginning with Shorewall 1.3.14, if you enter an interface name in -the SUBNET column, shorewall will use the firewall's routing table -to construct the masquerading/SNAT rules.
    - 
    -Example 1 -- This is how it works in 1.3.14.
    -  
    - - -
    -   [root@gateway test]# cat /etc/shorewall/masq
    
-   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    eth2                    206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    - -
    -   [root@gateway test]# ip route show dev eth2
    
-   192.168.1.0/24  scope link
    
-   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
-
    - -
    -   [root@gateway test]# shorewall start
    
-   ...
    
-   Masqueraded Subnets and Hosts:
    
-       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
    
-       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
    
-   Processing /etc/shorewall/tos...
-
    - - 
    -When upgrading to Shorewall 1.3.14, if you have multiple local -subnets connected to an interface that is specified in the SUBNET -column of an /etc/shorewall/masq entry, your /etc/shorewall/masq -file will need changing. In most cases, you will simply be able to -remove redundant entries. In some cases though, you might want to -change from using the interface name to listing specific -subnetworks if the change described above will cause masquerading -to occur on subnetworks that you don't wish to masquerade.
    - 
    -Example 2 -- Suppose that your current config is as follows:
    -  
    - - -
    -   [root@gateway test]# cat /etc/shorewall/masq
    
-   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    eth2                    206.124.146.176
    
-   eth0                    192.168.10.0/24         206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    - -
    -   [root@gateway test]# ip route show dev eth2
    
-   192.168.1.0/24  scope link
    
-   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
-   [root@gateway test]#
-
    - - 
    -   In this case, the second entry in /etc/shorewall/masq -is no longer required.
    - 
    -Example 3 -- What if your current configuration is like this?
    - 
    - - -
    -   [root@gateway test]# cat /etc/shorewall/masq
    
-   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    eth2                    206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    - -
    -   [root@gateway test]# ip route show dev eth2
    
-   192.168.1.0/24  scope link
    
-   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    
-   [root@gateway test]#
-
    - - 
    -   In this case, you would want to change the entry -in  /etc/shorewall/masq to:
    - - -
    -   #INTERFACE              SUBNET                  ADDRESS
    
-   eth0                    192.168.1.0/24          206.124.146.176
    
-   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
    - -
    4. -
- -

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

- -

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

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

1/17/2003 - shorewall.net has MOVED 

- -

Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and -ftp.shorewall.net are now hosted on a system in Bellevue, -Washington. A big thanks to Alex for making this happen.
-

- -

1/13/2003 - Shorewall 1.3.13
-

- -

Just includes a few things that I had on the burner:
-

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

1/6/2003 - BURNOUT -

- -

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

- -

-Tom Eastep
-

- -

12/30/2002 - Shorewall Documentation in PDF Format

- -

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

- -

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

- -

12/27/2002 - Shorewall 1.3.12 Released

- -

Features include:
-

- -
    -
  1. "shorewall refresh" now reloads the traffic shaping rules -(tcrules and tcstart).
    2. - -
  2. "shorewall debug [re]start" now turns off debugging after an -error occurs. This places the point of the failure near the end of -the trace rather than up in the middle of it.
    3. - -
  3. "shorewall [re]start" has been speeded up by more than 40% with -my configuration. Your milage may vary.
    4. - -
  4. A "shorewall show classifiers" command has been added which -shows the current packet classification filters. The output from -this command is also added as a separate page in "shorewall -monitor"
    5. - -
  5. ULOG (must be all caps) is now accepted as a valid syslog level -and causes the subject packets to be logged using the ULOG target -rather than the LOG target. This allows you to run ulogd (available -from http://www.gnumonks.org/projects/ulogd) -and log all Shorewall messages to -a separate log file.
    6. - -
  6. If you are running a kernel that has a FORWARD chain in the -mangle table ("shorewall show mangle" will show you the chains in -the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for -marking input packets based on their destination even when you are -using Masquerading or SNAT.
    7. - -
  7. I have cluttered up the /etc/shorewall directory with empty -'init', 'start', 'stop' and 'stopped' files. If you already have a -file with one of these names, don't worry -- the upgrade process -won't overwrite your file.
    8. - -
  8. I have added a new RFC1918_LOG_LEVEL variable to shorewall.conf. This variable -specifies the syslog level at which packets are logged as a result -of entries in the /etc/shorewall/rfc1918 file. Previously, these -packets were always logged at the 'info' level.
    -
    9. -
- -

12/20/2002 - Shorewall 1.3.12 Beta 3
-

- -This version corrects a problem with Blacklist logging. In Beta 2, -if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall -would fail to start and "shorewall refresh" would also fail.
-

12/20/2002 - Shorewall 1.3.12 Beta 2

- -

The first public Beta version of Shorewall 1.3.12 is now -available (Beta 1 was made available only to a limited -audience).
-

- -Features include:
-
    -
  1. "shorewall refresh" now reloads the traffic shaping rules -(tcrules and tcstart).
    2. - -
  2. "shorewall debug [re]start" now turns off debugging after an -error occurs. This places the point of the failure near the end of -the trace rather than up in the middle of it.
    3. - -
  3. "shorewall [re]start" has been speeded up by more than 40% with -my configuration. Your milage may vary.
    4. - -
  4. A "shorewall show classifiers" command has been added which -shows the current packet classification filters. The output from -this command is also added as a separate page in "shorewall -monitor"
    5. - -
  5. ULOG (must be all caps) is now accepted as a valid syslog level -and causes the subject packets to be logged using the ULOG target -rather than the LOG target. This allows you to run ulogd (available -from http://www.gnumonks.org/projects/ulogd) -and log all Shorewall messages to -a separate log file.
    6. - -
  6. If you are running a kernel that has a FORWARD chain in the -mangle table ("shorewall show mangle" will show you the chains in -the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in -shorewall.conf. This allows for marking input packets based on -their destination even when you are using Masquerading or -SNAT.
    7. - -
  7. I have cluttered up the /etc/shorewall directory with empty -'init', 'start', 'stop' and 'stopped' files. If you already have a -file with one of these names, don't worry -- the upgrade process -won't overwrite your file.
    8. -
- -You may download the Beta from:
-
http://www.shorewall.net/pub/shorewall/Beta
- - ftp://ftp.shorewall.net/pub/shorewall/Beta
-
- -

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

- -Shorewall is at the center of MandrakeSoft's recently-announced -Multi Network Firewall (MNF) product. Here is the press -release.
-

12/7/2002 - Shorewall Support for Mandrake 9.0

- -

Two months and 3 days after I ordered Mandrake 9.0, it was -finally delivered. I have installed 9.0 on one of my systems and I -am now in a position to support Shorewall users who run Mandrake -9.0.

- -

12/6/2002 - Debian 1.3.11a Packages Available
-

- -

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

- -

12/3/2002 - Shorewall 1.3.11a

- -

This is a bug-fix roll up which includes Roger Aich's fix for -DNAT with excluded subnets (e.g., "DNAT foo!bar ..."). Current -1.3.11 users who don't need rules of this type need not upgrade to -1.3.11.

- -

11/24/2002 - Shorewall 1.3.11

- -

In this version:

- - - -

11/14/2002 - Shorewall Documentation in PDF Format

- -

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

- -

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

- -

11/09/2002 - Shorewall is Back at SourceForge

- -

The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
-

- -

11/09/2002 - Shorewall 1.3.10

- -

In this version:

- - - -

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

- -Alexandru Hartmann reports that his Shorewall package is now a part -of the Gentoo Linux -distribution. Thanks Alex!
-

10/23/2002 - Shorewall 1.3.10 Beta 1

- -In this version:
- - -You may download the Beta from:
- - -

10/10/2002 -  Debian 1.3.9b Packages Available
-

- -

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

- -

10/9/2002 - Shorewall 1.3.9b

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

10/6/2002 - Shorewall.net now running on RH8.0
-
-The firewall and server here at shorewall.net are now running -RedHat release 8.0.
-
-9/30/2002 - Shorewall 1.3.9a

- -Roles up the fix for broken tunnels.
-

9/30/2002 - TUNNELS Broken in 1.3.9!!!

- -There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall --- copy that file to /usr/lib/shorewall/firewall.
-

9/28/2002 - Shorewall 1.3.9

- -

In this version:
-

- - - -

9/23/2002 - Full Shorewall Site/Mailing List Archive Search -Capability Restored
-

- -Brown Paper Bag A couple of recent configuration changes -at www.shorewall.net broke the Search facility:
-
-
    -
  1. Mailing List Archive Search was not available.
    2. - -
  2. The Site Search index was incomplete
    3. - -
  3. Only one page of matches was presented.
    4. -
-
- -Hopefully these problems are now corrected. - -

9/23/2002 - Full Shorewall Site/Mailing List Archive Search -Capability Restored
-

- -A couple of recent configuration changes at www.shorewall.net had -the negative effect of breaking the Search facility:
-
    -
  1. Mailing List Archive Search was not available.
    2. - -
  2. The Site Search index was incomplete
    3. - -
  3. Only one page of matches was presented.
    4. -
- -Hopefully these problems are now corrected.
-

9/18/2002 -  Debian 1.3.8 Packages Available
-

- -

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

- -

9/16/2002 - Shorewall 1.3.8

- -

In this version:
-

- - - - - -

9/11/2002 - Debian 1.3.7c Packages Available

- -

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

- -

9/2/2002 - Shorewall 1.3.7c

- -

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

- -

8/31/2002 - I'm not available

- -

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

- -

-Tom

- -

8/26/2002 - Shorewall 1.3.7b

- -

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

- -

8/26/2002 - French FTP Mirror is Operational

- -

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

- -

8/25/2002 - Shorewall Mirror in France

- -

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

- -

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

- -

Lorenzo Martignoni reports that the packages for version 1.3.7a -are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for -its Author -- Shorewall 1.3.7a releasedBrown Paper Bag Graphic

- -

1.3.7a corrects problems occurring in rules file processing when -starting Shorewall 1.3.7.

- -

8/22/2002 - Shorewall 1.3.7 Released 8/13/2002

- -

Features in this release include:

- - - -

I would like to thank John Distler for his valuable input -regarding TCP SYN and ICMP treatment in Shorewall. That input has -led to marked improvement in Shorewall in the last two -releases.

- -

8/13/2002 - Documentation in the CVS -Repository

- -

The Shorewall-docs project now contains just the HTML and image -files - the Frontpage files have been removed.

- -

8/7/2002 - STABLE branch added to CVS -Repository

- -

This branch will only be updated after I release a new version -of Shorewall so you can always update from this branch to get the -latest stable tree.

- -

8/7/2002 - Upgrade Issues -section added to the Errata Page

- -

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

- -

8/7/2002 - Shorewall 1.3.6

- -

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

- - - -

7/30/2002 - Shorewall 1.3.5b Released

- -

This interim release:

- - - -

7/29/2002 - New Shorewall Setup Guide Available

- -

The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm. -The guide is intended for use by people who are setting up -Shorewall to manage multiple public IP addresses and by people who -want to learn more about Shorewall than is described in the -single-address guides. Feedback on the new guide is welcome.

- -

7/28/2002 - Shorewall 1.3.5 Debian Package Available

- -

Lorenzo Martignoni reports that the packages are version 1.3.5a -and are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

7/27/2002 - Shorewall 1.3.5a Released

- -

This interim release restores correct handling of REDIRECT -rules.

- -

7/26/2002 - Shorewall 1.3.5 Released

- -

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

- -

  In this version:

- - - -

7/16/2002 - New Mirror in Argentina

- -

Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall -mirror in Argentina. Thanks Buanzo!!!

- -

7/16/2002 - Shorewall 1.3.4 Released

- -

In this version:

- - - -

7/8/2002 - Shorewall 1.3.3 Debian Package Available

- -

Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

7/6/2002 - Shorewall 1.3.3 Released

- -

In this version:

- - - -

6/25/2002 - Samples Updated for 1.3.2

- -

The comments in the sample configuration files have been updated -to reflect new features introduced in Shorewall 1.3.2.

- -

6/25/2002 - Shorewall 1.3.1 Debian Package Available

- -

Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

6/19/2002 - Documentation Available in PDF Format

- -

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

- -

6/16/2002 - Shorewall 1.3.2 Released

- -

In this version:

- - - -

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

- -

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

- - - -

These tools/weapons are particularly damaging when combined with -CVS Web because they doggedly follow every link in the -cgi-generated HTML resulting in 1000s of executions of the -cvsweb.cgi script. Yesterday, I spend several hours implementing -measures to block these tools but unfortunately, these measures -resulted in my server OOM-ing under even moderate load.

- -

Until I have the time to understand the cause of the OOM (or -until I buy more RAM if that is what is required), CVS Web access -will remain Password Protected.

- -

6/5/2002 - Shorewall 1.3.1 Debian Package Available

- -

Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

- -

6/2/2002 - Samples Corrected

- -

The 1.3.0 samples configurations had several serious problems -that prevented DNS and SSH from working properly. These problems -have been corrected in the 1.3.1 samples.

- -

6/1/2002 - Shorewall 1.3.1 Released

- -

Hot on the heels of 1.3.0, this release:

- - - -

5/29/2002 - Shorewall 1.3.0 Released

- -

In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall -1.3.0 includes:

- - - -

5/23/2002 - Shorewall 1.3 RC1 Available

- -

In addition to the changes in Beta 1 and Beta 2, RC1 (Version -1.2.92) incorporates the following:

- - - -

5/19/2002 - Shorewall 1.3 Beta 2 Available

- -

In addition to the changes in Beta 1, this release which carries -the designation 1.2.91 adds:

- - - -

5/17/2002 - Shorewall 1.3 Beta 1 Available

- -

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

- - - -

5/4/2002 - Shorewall 1.2.13 is Available

- -

In this version:

- - - -

4/30/2002 - Shorewall Debian News

- -

Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both -the Debian -Testing Branch and the Debian -Unstable Branch.

- -

4/20/2002 - Shorewall 1.2.12 is Available

- - - -

4/17/2002 - Shorewall Debian News

- -

Lorenzo Marignoni reports that:

- - - -

Thanks, Lorenzo!

- -

4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE

- -

Thanks to Stefan -Mohr, there is now a Shorewall 1.2.11 -SuSE RPM available.

- -

4/13/2002 - Shorewall 1.2.11 Available

- -

In this version:

- - - -

4/13/2002 - Hamburg Mirror now has FTP

- -

Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  -Thanks Stefan!

- -

4/12/2002 - New Mirror in Hamburg

- -

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

- -

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

- -

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

- -

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

- -

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

- -

4/8/2002 - Parameterized Samples Withdrawn

- -

Although the parameterized -samples have allowed people to get a firewall up and running -quickly, they have unfortunately set the wrong level of expectation -among those who have used them. I am therefore withdrawing support -for the samples and I am recommending that they not be used in new -Shorewall installations.

- -

4/2/2002 - Updated Log Parser

- -

John Lodge has provided -an updated version of his CGI-based log parser with corrected -date handling.

- -

3/30/2002 - Shorewall Website Search Improvements

- -

The quick search on the home page now excludes the mailing list -archives. The Extended Search -allows excluding the archives or restricting the search to just the -archives. An archive search form is also available on the mailing list -information page.

- -

3/28/2002 - Debian Shorewall News (From Lorenzo -Martignoni)

- - - -

3/25/2002 - Log Parser Available

- -

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

- -

3/20/2002 - Shorewall 1.2.10 Released

- -

In this version:

- - - -

3/11/2002 - Shorewall 1.2.9 Released

- -

In this version:

- - - -

3/1/2002 - 1.2.8 Debian Package is Available

- -

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

- -

2/25/2002 - New Two-interface Sample

- -

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

- -

2/23/2002 - Shorewall 1.2.8 Released

- -

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

- -

2/22/2002 - Shorewall 1.2.7 Released

- -

In this version:

- - - -

2/18/2002 - 1.2.6 Debian Package is Available

- -

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

- -

2/8/2002 - Shorewall 1.2.6 Released

- -

In this version:

- - - -

2/4/2002 - Shorewall 1.2.5 Debian Package Available

- -

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

- -

2/1/2002 - Shorewall 1.2.5 Released

- -

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

- -

In version 1.2.5:

- - - -

1/28/2002 - Shorewall 1.2.4 Released

- - - -

1/27/2002 - Shorewall 1.2.3 Debian Package Available -- -see http://security.dsi.unimi.it/~lorenzo/debian.html

- -

1/20/2002 - Corrected firewall script available 

- -

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

- -

1/19/2002 - Shorewall 1.2.3 Released

- -

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

- - - -

The following problems were corrected:

- - - -

1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release

- -

Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF -distribution that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo -for details.

- -

1/11/2002 - Debian Package (.deb) Now Available - Thanks -to Lorenzo -Martignoni, a 1.2.2 Shorewall Debian package is now available. -There is a link to Lorenzo's site from the Shorewall download page.

- -

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

- -

1/8/2002 - Shorewall 1.2.2 Released

- -

In version 1.2.2

- - - -

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:

- - - -

See the README file for upgrade instructions.

- -

1/1/2002 - Shorewall Mailing List -Moving

- -

The Shorewall mailing list hosted at Sourceforge is moving to -Shorewall.net. If you are a current subscriber to the list at -Sourceforge, please see these instructions. -If you would like to subscribe to the new list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.

- -

12/31/2001 - Shorewall 1.2.1 Released

- -

In version 1.2.1:

- - - -

12/21/2001 - Shorewall 1.2.0 Released! - I couldn't -resist releasing 1.2 on 12/21/2001

- -

Version 1.2 contains the following new features:

- - - -

For the next month or so, I will continue to provide corrections -to version 1.1.18 as necessary so that current version 1.1.x users -will not be forced into a quick upgrade to 1.2.0 just to have -access to bug fixes.

- -

For those of you who have installed one of the Beta RPMS, you -will need to use the "--oldpackage" option when upgrading to -1.2.0:

- -
-

rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

-
- -

12/19/2001 - Thanks to Steve Cowles, there is now a -Shorewall mirror in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall and the ftp site is -at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. - 

- -

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

- - - -

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

- -

In this version:

- - - -

11/19/2001 - Thanks to Juraj Ontkanin, there is now a -Shorewall mirror in the Slovak Republic. The website is now -mirrored at http://www.nrg.sk/mirror/shorewall and the FTP site is -mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

- -

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

- - - -

Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 -. 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/15/2001 - The current version of Shorewall is 1.1.15. -In this version:

- - - -

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

- - - -

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

- - - -

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

- - - -

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

- - - -

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

- - - -

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

- - - -

6/2/2001 - The current version of Shorewall is 1.1.7. In -this version

- - - -

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

- - - -

5/20/2001 - The current version of Shorewall is 1.1.5. In -this version

- - - -

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

- - - -

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

- - - -

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

- - - -

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

- -

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

- - - -

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

- - - -

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

- - - -

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

- - - -

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

- -
- - - diff --git a/Shorewall-docs/SeattleInTheSpring.html b/Shorewall-docs/SeattleInTheSpring.html deleted file mode 100755 index 31c8c8231..000000000 --- a/Shorewall-docs/SeattleInTheSpring.html +++ /dev/null @@ -1,34 +0,0 @@ - - - - - Springtime in Seattle!!! - - - - --+ -

-

Visit Seattle in the Springtime!!!
-

-
-
-March 6, 2003 - Nice day for a walk....
-
-
-
-
- -

The view from my office window -- think I'll go out and enjoy the -deck (Yes -- that is snow on the deck...).
-

-

Updated 3/7/2003 - Tom Eastep -

-

Copyright © 2001, 2002 Thomas M. Eastep.

-
-
-
- - diff --git a/Shorewall-docs/Shorewall_CA_html.html b/Shorewall-docs/Shorewall_CA_html.html deleted file mode 100644 index c26ac9c80..000000000 --- a/Shorewall-docs/Shorewall_CA_html.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - Shorewall Certificate Authority - - - - -

Shorewall Certificate Authority (CA) -Certificate
-

-Given that I develop and support Shorewall without asking for any -renumeration, I can hardly justify paying $200US+ a year to a -Certificate Authority such as Thawte (A Division of VeriSign) for an -X.509 certificate to prove that I am who I am. I have therefore -established my own Certificate Authority (CA) and sign my own X.509 -certificates. I use these certificates on my list server (https://lists.shorewall.net) -which hosts parts of this web site.
-
-X.509 certificates are the basis for the Secure Socket Layer (SSL). As -part of establishing an SSL session (URL https://...), your browser -verifies the X.509 certificate supplied by the HTTPS server against the -set of Certificate Authority Certificates that were shipped with your -browser. It is expected that the server's certificate was issued by one -of the authorities whose identities are known to your browser.
-
-This mechanism, while supposedly guaranteeing that when you connect to -https://www.foo.bar you are REALLY connecting to www.foo.bar, means -that the CAs literally have a license to print money -- they are -selling a string of bits (an X.509 certificate) for $200US+ per -year!!!I
-
-I wish that I had decided to become a CA rather that designing and -writing Shorewall.
-
-What does this mean to you? It means that the X.509 certificate that my -server will present to your browser will not have been signed by one of -the authorities known to your browser. If you try to connect to my -server using SSL, your browser will frown and give you a dialog box -asking if you want to accept the sleezy X.509 certificate being -presented by my server.
-
-There are two things that you can do:
-
    -
  1. You can accept the mail.shorewall.net certificate when your -browser asks -- your acceptence of the certificate can be temporary -(for that access only) or perminent.
    2. -
  2. You can download and install my (self-signed) -CA certificate. This will make my Certificate Authority known to -your browser so that it will accept any certificate signed by me.
    -
    3. -
-What are the risks?
-
    -
  1. If you install my CA certificate then you assume that I am -trustworthy and that Shorewall running on your firewall won't redirect -HTTPS requests intented to go to your bank's server to one of my -systems that will present your browser with a bogus certificate -claiming that my server is that of -your bank.
    2. -
  2. If you only accept my server's certificate when prompted then the -most that you have to loose is that when you connect to -https://mail.shorewall.net, the server you are connecting to might not -be mine.
    3. -
-I have my CA certificate loaded into all of my browsers but I certainly -won't be offended if you decline to load it into yours... :-)
-

Last Updated 1/17/2003 - Tom Eastep

-

Copyright © 2001, 2002, 2003 -Thomas M. -Eastep.

-
-
-
-
- - diff --git a/Shorewall-docs/Shorewall_CVS_Access.html b/Shorewall-docs/Shorewall_CVS_Access.html deleted file mode 100644 index e57b52b90..000000000 --- a/Shorewall-docs/Shorewall_CVS_Access.html +++ /dev/null @@ -1,39 +0,0 @@ - - - - Shorewall CVS Access - - - - -
-

Shorewall CVS Access
-

-Lots of people try to download the entire Shorewall website for -off-line browsing, including the CVS portion. In addition to being an -enormous volume of data (HTML versions of all versions of all Shorewall -files), all of the pages in Shorewall CVS access are cgi-generated -which places a tremendous load on my little server. I have therefore -resorted to making CVS access password controlled. When you are asked -to log in, enter "Shorewall" (NOTE THE CAPITALIZATION!!!!!) for both -the user name and the password.
-
-
-

CVS Login  
-

-
-

Updated -1/14/2002 - Tom Eastep

-

Copyright -© 2001, 2002, 2003 Thomas M. Eastep.

-
-
-
-
-
-
-
- - diff --git a/Shorewall-docs/Shorewall_index_frame.htm b/Shorewall-docs/Shorewall_index_frame.htm deleted file mode 100644 index cda8c5640..000000000 --- a/Shorewall-docs/Shorewall_index_frame.htm +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - Shorewall Index - - - - - - - - - -
- -
-

Valid XHTML 1.0!

-

Copyright © 2001-2003 Thomas -M. Eastep.

- - diff --git a/Shorewall-docs/Shorewall_sfindex_frame.htm b/Shorewall-docs/Shorewall_sfindex_frame.htm deleted file mode 100644 index 4136620b8..000000000 --- a/Shorewall-docs/Shorewall_sfindex_frame.htm +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - - - Shorewall Index - - - - - - - - - - -
- -
-

Copyright © 2001-2003 Thomas M. Eastep.
-

-
-
- - diff --git a/Shorewall-docs/SourceforgeBanner.html b/Shorewall-docs/SourceforgeBanner.html deleted file mode 100755 index 5366fafa0..000000000 --- a/Shorewall-docs/SourceforgeBanner.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - - Banner - - - - - - - - - - - -
-
(Shorewall Logo)
- 		-
Note: Search -is unavailable Daily 0200-0330 GMT.
- -

Quick Search
-         Extended Search

-
-
- - diff --git a/Shorewall-docs/copyright.htm b/Shorewall-docs/copyright.htm deleted file mode 100644 index 05fccb49b..000000000 --- a/Shorewall-docs/copyright.htm +++ /dev/null @@ -1,30 +0,0 @@ - - - - - - - - Copyright - - -

Copyright
-

-

Copyright ©  -2000, 2001, 2003 Thomas M Eastep
- 

-
-

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

-
-
-
- - diff --git a/Shorewall-docs/download.htm b/Shorewall-docs/download.htm deleted file mode 100644 index 0058e0ea9..000000000 --- a/Shorewall-docs/download.htm +++ /dev/null @@ -1,191 +0,0 @@ - - - - - - - - Download - - -

Shorewall Download
-

-

I strongly urge you to read and print a copy of the Shorewall QuickStart Guide -for the configuration that most closely matches your own.
-

-

The entire set of Shorewall documentation is available in PDF format -at:

-

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

-

The documentation in HTML format is included in the .rpm and in the -.tgz -packages below.

-

Once you've printed the appropriate QuickStart Guide, download -one of the modules:

- -

The documentation in HTML format is included in the .tgz and .rpm -files and there is an documentation .deb that also contains the -documentation.  The .rpm will install the documentation in -your default document directory which can be obtained using the -following command:
-

-
-

rpm --eval '%{_defaultdocdir}'

-
-

Please check the -errata to see if there are updates that apply to the version -that you have downloaded.

-

WARNING - YOU CAN NOT SIMPLY -INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME -CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have -completed configuration of your firewall, you can enable startup by -removing the file /etc/shorewall/startup_disabled.

-

-

Download Sites:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SERVER LOCATIONDOMAINHTTPFTP
Slovak RepublicShorewall.netBrowse Browse
Washington State, USAShorewall.netBrowseBrowse
Texas, USAInfohiiway.comBrowseBrowse
-
Hamburg, GermanyShorewall.netBrowseBrowse
FranceShorewall.netBrowse Browse
Taiwan
- 		Greshko.com
- 		Browse
- 		Browse
-
Argentina
- 		Shorewall.net
- 		Browse
- 		Browse
-
Brazil
- 		securityopensource.org.br
- 		Browse
- 		N/A
-
Sourceforge - California, USA (Incomplete)
- 		Sourceforge.net
- 		Browse
- 		N/A
-
-
-

CVS:

-
-

The CVS -repository at cvs.shorewall.net contains the latest snapshots of -the each Shorewall component. There's no guarantee that what you find -there will work at all.
-

-
-

Shapshots:
-

-
-

Periodic snapshots from CVS may be found at http://shorewall.net/pub/shorewall/Snapshots -(FTP). -These snapshots have undergone initial testing and will have been -installed and run at shorewall.net.
-

-
-

Last Updated 12/29/2003 - Tom Eastep

-

Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-

- - diff --git a/Shorewall-docs/errata_1.htm b/Shorewall-docs/errata_1.htm deleted file mode 100644 index 351893bed..000000000 --- a/Shorewall-docs/errata_1.htm +++ /dev/null @@ -1,196 +0,0 @@ - - - - - - - - - - - - Shorewall Errata for Version 1 - - - - - - - - - - -
-

Shorewall Errata for Version -1.1

-
- -

To those of you who downloaded -the 1.1.13 updated firewall script prior to Sept 20, 2001:

- -
-

Prior to 20:00 20 Sept 2001 GMT, the link under 1.1.13 -pointed to a broken version of the firewall script. This has now been corrected. -I apologize for any confusion this may have caused.

-
- -

Version 1.1.18

- -
-

In the original .lrp, /etc/init.d/shorewall was not - secured for execute access. I have replaced the incorrect .lrp - (shorwall-1.1.18.lrp) with a corrected one (shorwall-1.1.18a.lrp).

-
- -

Version 1.1.17

- -
-

In shorewall.conf, ADD_IP_ALIASES was incorrectly -spelled IP_ADD_ALIASAES. There is a corrected version of the -file here.

- -

This problem is also corrected in version 1.1.18.

-
- -

Version 1.1.16

- -
-

The ADD_IP_ALIASES variable added in 1.1.16 was incorrectly - spelled IP_ADD_ALIASES in the firewall script. To correct this problem, - install the corrected - firewall script in the location pointed to by the symbolic link - /etc/shorewall/firewall.

- -

This problem is also corrected in version 1.1.17.

-
- -

Version 1.1.14-1.1.15

- -
-

There are no corrections for these versions.

-
- -

Version 1.1.13

- -
-

The firewall fails to start if a rule with the following - format is given:

- -

<disposition>    z1:www.xxx.yyy.zzz    z2    - proto    p1,p2,p3

- -

To correct this problem, install this - corrected firewall script in the location pointed to by the symbolic -link /etc/shorewall/firewall. 

-
- -

Version 1.1.12

- -
-

The LRP version of Shorewall 1.1.12 has the incorrect - /etc/shorewall/functions file. This incorrect file results in many error - messages of the form:

- -
-

separate_list: not found

-
- -

The - correct file may be obtained here . This problem is also corrected -in version 1.1.13.

-
- -

Version 1.1.11

- -
-

There are no known problems with this version.

-
- -

Version 1.1.10

- -
-

If the following conditions were met:
-

- -
    -
  1. -

    A LAN segment attached to the firewall was served -by a DHCP server running on the firewall.

    -
    2. -
  2. -

    There were entries in /etc/shorewall/hosts that referred - to the interface to that LAN segment.

    -
    3. - -
- -

then up until now it has been necessary to include entries - for 0.0.0.0 and 255.255.255.255 for that interface in /etc/shorewall/hosts. - - This version of the firewall script makes those additions unnecessary - provided that you simply include "dhcp" in the options for the interface -in /etc/shorewall/interfaces. Install the script into the location pointed -to by the symbolic link /etc/shorewall/firewall.

- -

This problem has also been corrected in version 1.1.11.

-
- -

Version 1.1.9

- - - -

Version 1.1.8

- - - -

Version 1.1.7

- - - -
-

This problem is also corrected in version 1.1.8

-
- -

Last updated 12/21/2001 - Tom Eastep

- -

Copyright -© 2001, 2002 Thomas M. Eastep.

-
- - diff --git a/Shorewall-docs/errata_2.htm b/Shorewall-docs/errata_2.htm deleted file mode 100644 index a6f430238..000000000 --- a/Shorewall-docs/errata_2.htm +++ /dev/null @@ -1,425 +0,0 @@ - - - - - - Shorewall 1.2 Errata - - - - - - - - - - - - - - -
-

Shorewall 1.2 Errata

-
- -

- IMPORTANT

- -

If you use a Windows system to download a -corrected script, be sure to run the script through dos2unix - after you have moved it to your Linux system.

- -

When the instructions say to install a corrected -firewall script in /etc/shorewall/firewall, use the 'cp' (or 'scp') -utility to overwrite the existing file. DO NOT REMOVE OR RENAME THE -OLD /etc/shorewall/firewall before you do that. /etc/shorewall/firewall -is a symbolic link that points to the 'shorewall' file used by your -system initialization scripts to start Shorewall during boot and it -is that file that must be overwritten with the corrected script.

- - - -
-

Problems in Version 1.2

- -

Version 1.2.13

- - - -

Version 1.2.11

- - - -

Both problems are corrected by - this new version of /sbin/shorewall.

- -

Sample Configurations:

- - - -

All Versions through 1.2.10

- - - -
-
- - - - - - - - - - - - - - - - - - - -
ZONEHOST(S)OPTIONS
loceth2:192.168.1.0/24routestopped
locppp+:192.168.1.0/24 
-
-
- -

All Versions through 1.2.8

- - - -

Version 1.2.7

- -

Version 1.2.7 is quite broken -- please install 1.2.8

- -

If you have installed and started version 1.2.7 then before trying - to restart under 1.2.8:

- -
    -
  1. Look at your /etc/shorewall/shorewall.conf file and note the directory - named in the STATEDIR variable. If that variable is empty, assume /var/state/shorewall.
    2. -
  2. Remove the file 'lock' in the directory determined in step 1.
    3. - -
- -

You may now restart using 1.2.8.

- -

Version 1.2.6

- - - -

To correct the above problems, install this - corrected firewall script in  /etc/shorewall/firewall..

-

Version 1.2.5

- - - -

To correct the above problems, install this - corrected firewall script in /etc/shorewall/firewall.

-

 

- - -

Version 1.2.4

- - - -

Version 1.2.3

- - - -
-

Alternatively, edit /etc/shorewall/firewall and change line 1564 from:

-
- -
          run_iptables -A blacklst -d $addr -j LOG $LOGPARAMS --log-prefix \
- -
-

to

-
- -
          run_iptables -A blacklst -s $addr -j LOG $LOGPARAMS --log-prefix \
- -

Version 1.2.2

- - - -
-
       status)
           clear
-
- -
-

to this:

-
- -
-
       status)
           get_config
           clear
-
- - - - - -

Version 1.2.1

- - - -

Version 1.2.0

- -
-

Note: If you are upgrading from one of the Beta - RPMs to 1.2.0, you must use the "--oldpackage" option to rpm - (e.g., rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm).

- -

The tunnel script released in version 1.2.0 contained - errors -- a corrected - script is available.

-
- -
-

Problem with -iptables version 1.2.3

- -
-

There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, RedHat released -this buggy iptables in RedHat 7.2. 

- -

I have built a - corrected 1.2.3 rpm which you can download here  and I have also built - an -iptables-1.2.4 rpm which you can download here. If you are currently -running RedHat 7.1, you can install either of these RPMs before - you upgrade to RedHat 7.2.

- -

Update 11/9/2001: RedHat has released -an iptables-1.2.4 RPM of their own which you can download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works fine.

- -

If you would like to patch iptables 1.2.3 yourself, -the patches are available for download. This patch - which corrects a problem with parsing of the --log-level specification -while this patch - corrects a problem in handling the  TOS target.

- -

To install one of the above patches:

- - -
- -

Problems with kernel 2.4.18 - and RedHat iptables

- -
-

Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18 -may experience the following:

- -
- 
# shorewall start
Processing /etc/shorewall/shorewall.conf ...
Processing /etc/shorewall/params ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)
-
- -

The RedHat iptables RPM is compiled with debugging enabled but the - user-space debugging code was not updated to reflect recent changes in -the Netfilter 'mangle' table. You can correct the problem by installing - - this iptables RPM. If you are already running a 1.2.5 version of - iptables, you will need to specify the --oldpackage option to rpm (e.g., - "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

-
- -

Last updated -5/24/2002 - Tom Eastep

- -

Copyright - © 2001, 2002 Thomas M. Eastep.

-
- - diff --git a/Shorewall-docs/errata_3.html b/Shorewall-docs/errata_3.html deleted file mode 100755 index fe34058ff..000000000 --- a/Shorewall-docs/errata_3.html +++ /dev/null @@ -1,656 +0,0 @@ - - - - - - Shorewall 1.3 Errata - - - - - - - - - - - - - - - - -
-

Shorewall Errata/Upgrade Issues

-
- -

IMPORTANT

- -
    -
  1. -

    If you use a Windows system to download - a corrected script, be sure to run the script through - dos2unix after you have moved - it to your Linux system.

    -
    2. -
  2. -

    If you are installing Shorewall for the first -time and plan to use the .tgz and install.sh script, you can untar -the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

    -
    3. -
  3. -

    If you are running a Shorewall version earlier - than 1.3.11, when the instructions say to install a corrected firewall - script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall - or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to -overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD -/etc/shorewall/firewall or /var/lib/shorewall/firewall before -you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall - are symbolic links that point to the 'shorewall' file used by your - system initialization scripts to start Shorewall during boot. -It is that file that must be overwritten with the corrected -script. Beginning with Shorewall 1.3.11, you may rename the existing file -before copying in the new file.

    -
    4. -
  4. -

    DO NOT INSTALL CORRECTED COMPONENTS - ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. - For example, do NOT install the 1.3.9a firewall script if you are running - 1.3.7c.
    -

    -
    5. - -
- - - -
-

Problems in Version 1.3

- -

Version 1.3.14

- - - - - These problems have been corrected in this - firewall script which may be installed in /usr/lib/shorewall as described - above.
- -

Version 1.3.13

- - - All three problems are corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
- - - -

Version 1.3.12

- - - -

Version 1.3.12 LRP

- - - -

Version 1.3.11a

- - - -

Version 1.3.11

- - - -

Version 1.3.10

- - - -

Version 1.3.9a

- - - -
          recalculate_interfacess: command not found
- -
The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - corrects this problem.Copy the script to /usr/lib/shorewall/firewall - as described above.
-
- -
Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' - to 'recalculate_interface'.
-
- - - -

Version 1.3.9

- TUNNELS Broken in 1.3.9!!! There is an updated -firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall as described above.
-
- Version 1.3.8 - - Installing - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects these - problems. -

Version 1.3.7b

- -

DNAT rules where the source zone is 'fw' ($FW) result in an error -message. Installing - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this - problem.

- -

Version 1.3.7a

- -

"shorewall refresh" is not creating the proper rule for FORWARDPING=Yes. -Consequently, after "shorewall refresh", the firewall will not -forward icmp echo-request (ping) packets. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this - problem.

- -

Version <= 1.3.7a

- -

If "norfc1918" and "dhcp" are both specified as options on a -given interface then RFC 1918 checking is occurring before DHCP -checking. This means that if a DHCP client broadcasts using -an RFC 1918 source address, then the firewall will - reject the broadcast (usually logging it). This - has two problems:

- -
    -
  1. If the firewall - is running a DHCP server, the client - won't be able to obtain an IP address lease from -that server.
    2. -
  2. With this order - of checking, the "dhcp" option -cannot be used as a noise-reduction measure where there are both -dynamic and static clients on a LAN segment.
    3. - -
- -

- This version of the 1.3.7a firewall script - corrects the problem. It must be installed - in /var/lib/shorewall as described - above.

- -

Version 1.3.7

- -

Version 1.3.7 dead on arrival -- please use version 1.3.7a and check -your version against these md5sums -- if there's a difference, please - download again.

- -
	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
- -

In other words, type "md5sum <whatever package you downloaded> - and compare the result with what you see above.

- -

I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the - .7 version in each sequence from now on.

- -

Version 1.3.6

- - - -

These problems are fixed in - this correct firewall script which must be installed in /var/lib/shorewall/ -as described above. These problems are also corrected in version 1.3.7.

- -

Two-interface Samples 1.3.6 (file two-interfaces.tgz)

- -

A line was inadvertently deleted from the "interfaces - file" -- this line should be added back in if the version that you - downloaded is missing it:

- -

net    eth0    detect    routefilter,dhcp,norfc1918

- -

If you downloaded two-interfaces-a.tgz then the above - line should already be in the file.

- -

Version 1.3.5-1.3.5b

- -

The new 'proxyarp' interface option doesn't work :-( - This is fixed in - this corrected firewall script which must be installed in -/var/lib/shorewall/ as described above.

- -

Versions 1.3.4-1.3.5a

- -

Prior to version 1.3.4, host file entries such as the - following were allowed:

- -
-
	adm	eth0:1.2.4.5,eth0:5.6.7.8
-
- -
-

That capability was lost in version 1.3.4 so that it is only - possible to  include a single host specification on each line. - This problem is corrected by this - modified 1.3.5a firewall script. Install the script in -/var/lib/pub/shorewall/firewall as instructed above.

-
- -
-

This problem is corrected in version 1.3.5b.

-
- -

Version 1.3.5

- -

REDIRECT rules are broken in this version. Install - this corrected firewall script in /var/lib/pub/shorewall/firewall - as instructed above. This problem is corrected in version - 1.3.5a.

- -

Version 1.3.n, n < 4

- -

The "shorewall start" and "shorewall restart" commands - to not verify that the zones named in the /etc/shorewall/policy file - have been previously defined in the /etc/shorewall/zones file. -The "shorewall check" command does perform this verification so -it's a good idea to run that command after you have made configuration - changes.

- -

Version 1.3.n, n < 3

- -

If you have upgraded from Shorewall 1.2 and after "Activating -rules..." you see the message: "iptables: No chains/target/match - by that name" then you probably have an entry in /etc/shorewall/hosts - that specifies an interface that you didn't include -in /etc/shorewall/interfaces. To correct this problem, you - must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 -and later versions produce a clearer error message in this - case.

- -

Version 1.3.2

- -

Until approximately 2130 GMT on 17 June 2002, the download -sites contained an incorrect version of the .lrp file. That file -can be identified by its size (56284 bytes). The correct version - has a size of 38126 bytes.

- - - -

Both problems are corrected in - this script which should be installed in /var/lib/shorewall - as described above.

- - - -

Version 1.3.1

- - - -

These problems are corrected in - this firewall script which should be installed in /etc/shorewall/firewall - as described above.

- -

Version 1.3.0

- - - -
-

Upgrade Issues

- -

The upgrade issues have moved to a separate page.

- -
-

Problem with - iptables version 1.2.3

- -
-

There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, -RedHat released this buggy iptables in RedHat 7.2. 

- -

I have built a - corrected 1.2.3 rpm which you can download here  and I have - also built an iptables-1.2.4 - rpm which you can download here. If you are currently running -RedHat 7.1, you can install either of these RPMs before - you upgrade to RedHat 7.2.

- -

Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can - download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works - fine.

- -

If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level specification - while this patch - corrects a problem in handling the  TOS target.

- -

To install one of the above patches:

- - -
- -

Problems with kernels >= 2.4.18 - and RedHat iptables

- -
-

Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

- -
- 
# shorewall start
Processing /etc/shorewall/shorewall.conf ...
Processing /etc/shorewall/params ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)
-
- -

The RedHat iptables RPM is compiled with debugging enabled but the - user-space debugging code was not updated to reflect recent changes in - the Netfilter 'mangle' table. You can correct the problem by - installing - this iptables RPM. If you are already running a 1.2.5 version - of iptables, you will need to specify the --oldpackage option -to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

-
- -

Problems installing/upgrading - RPM on SuSE

- -

If you find that rpm complains about a conflict with kernel <= -2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps" -option to rpm.

- -

Installing: rpm -ivh --nodeps <shorewall rpm>

- -

Upgrading: rpm -Uvh --nodeps <shorewall rpm>

- -

Problems with iptables version 1.2.7 and -MULTIPORT=Yes

- -

The iptables 1.2.7 release of iptables has made an incompatible -change to the syntax used to specify multiport match rules; as -a consequence, if you install iptables 1.2.7 you must -be running Shorewall 1.3.7a or later or:

- - - -

Problems with RH Kernel 2.4.18-10 and NAT
-

- /etc/shorewall/nat entries of the following form will -result in Shorewall being unable to start:
-
- -
#EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
192.0.2.22      eth0            192.168.9.22    yes                     yes
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
- Error message is:
- -
Setting up NAT...
iptables: Invalid argument
Terminated

- The solution is to put "no" in the LOCAL column. Kernel -support for LOCAL=yes has never worked properly and 2.4.18-10 has -disabled it. The 2.4.19 kernel contains corrected support under a new -kernel configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
- -

Last updated 3/8/2003 - Tom Eastep -

- -

Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - diff --git a/Shorewall-docs/gnu_mailman.htm b/Shorewall-docs/gnu_mailman.htm deleted file mode 100644 index dd2d374ae..000000000 --- a/Shorewall-docs/gnu_mailman.htm +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - - - GNU Mailman - - -

GNU Mailman/Postfix the Easy Way 

-

The following was posted on the Postfix mailing list on 5/4/2002 by -Michael Tokarev as a suggested addition to the Postfix FAQ.

-

Q: Mailman does not work with Postfix, complaining about GID mismatch
-
-A: Mailman uses a setgid wrapper that is designed to be used in -system-wide aliases file so that rest of mailman's mail handling -processes will run with proper uid/gid. Postfix has an ability to run a -command specified in an alias as owner of that alias, thus mailman's -wrapper is not needed here. The best method to invoke mailman's mail -handling via aliases is to use separate alias file especially for -mailman, and made it owned by mailman and group mailman. Like:
-
-alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases
-
-Make sure that /var/mailman/aliases.db is owned by mailman user (this -may be done by executing postalias as mailman userid).
-
-Next, instead of using mailman-suggested aliases entries with wrapper, -use the following:
-
-instead of
-mailinglist: /var/mailman/mail/wrapper post mailinglist
-mailinglist-admin: /var/mailman/mail/wrapper mailowner mailinglist
-mailinglist-request: /var/mailman/mail/wrapper mailcmd mailinglist
-...
-
-use
-mailinglist: /var/mailman/scripts/post mailinglist
-mailinglist-admin: /var/mailman/scripts/mailowner mailinglist
-mailinglist-request: /var/mailman/scripts/mailcmd mailinglist
-...

-

The above tip works with Mailman 2.0; Mailman 2.1 has adopted -something very similar so that no workaround is necessary. See the -README.POSTFIX file included with Mailman-2.1. 

-

Last updated 12/29/2002 - Tom Eastep

-

Copyright © 2001, 2002 Thomas M. -Eastep.

-
-
-
-
- - diff --git a/Shorewall-docs/index.htm b/Shorewall-docs/index.htm deleted file mode 100644 index 802a2d853..000000000 --- a/Shorewall-docs/index.htm +++ /dev/null @@ -1,19 +0,0 @@ - - - -Shoreline Firewall - - - - - - -<body><p>This page uses frames, but your browser doesn't -support them.</p></body> - diff --git a/Shorewall-docs/mailing_list.htm b/Shorewall-docs/mailing_list.htm deleted file mode 100644 index a86de7fb9..000000000 --- a/Shorewall-docs/mailing_list.htm +++ /dev/null @@ -1,264 +0,0 @@ - - - - - - - - Shorewall Mailing Lists - - - - - - - - - - - -
-

Vexira Logo

- -

  (Razor Logo) -

- 		-

Shorewall Mailing Lists

- 		(Postfix Logo) -
-
-
-

-
-
-
-
-If you are reporting a problem or asking a -question, you are at the wrong place -- please see the Shorewall Support Guide.
-
-If you experience problems with any of these lists, -please let me -know -

Not able to Post Mail to shorewall.net?

-

You can report such problems by sending mail to -tmeastep at -hotmail dot com.

-

A Word about the SPAM Filters at Shorewall.net 

-

Please note that the mail server at shorewall.net checks -incoming mail:
-

-
    -
  1. against Spamassassin -(including Vipul's Razor).
    -
    2. -
  2. to ensure that the sender address is -fully qualified.
    3. -
  3. to verify that the sender's domain has an A or MX record in DNS.
    4. -
  4. to ensure that the host name in the HELO/EHLO command is a valid -fully-qualified DNS name.
    5. -
-

Please post in plain text

-A growing number of MTAs serving list subscribers are rejecting all -HTML traffic. At least one MTA has gone so far as to blacklist -shorewall.net "for continuous abuse" because it has been my policy to -allow HTML in list posts!!
-
-I think that blocking all HTML is a Draconian way to control spam and -that the ultimate losers here are not the spammers but the list -subscribers whose MTAs are bouncing all shorewall.net mail. As one list -subscriber wrote to me privately "These e-mail admin's need to get a (explitive -deleted) life instead of trying to -rid the planet of HTML based e-mail". Nevertheless, to allow -subscribers to receive list posts as must as possible, I have now -configured the list server at shorewall.net to strip all HTML from -outgoing posts. -This means that HTML-only posts will be bounced by the list server.
-

Note: The list server limits posts to 120kb.
-

-

Other Mail Delivery Problems

-If you find that you are missing an occasional list post, your e-mail -admin may be blocking mail whose Received: headers contain the -names of certain ISPs. Again, I believe that such policies hurt more -than they help but I'm not prepared to go so far as to start stripping Received: -headers to circumvent those policies.
-

Mailing Lists Archive Search

-
-

Match: - -Format: - -Sort by: - -
-Search:

-
-

Please do not try to download -the entire -Archive -- it is 164MB (and growing daily) and my slow DSL line simply -won't -stand the traffic. If I catch you, you will be blacklisted.
-

-

Shorewall CA Certificate

-If you want to trust X.509 certificates issued by Shoreline Firewall -(such as the one used on my web site), you may download and install my CA certificate -in your browser. If you don't wish to trust my certificates then you -can either use unencrypted access when subscribing to Shorewall mailing -lists or you can use secure access (SSL) and -accept the server's certificate when prompted by your browser.
-

Shorewall Newbies Mailing List

-This list provides a place where people who are new to Shorewall can -get questions answered and can receive help with problems.
-

Before posting -to this list, please see the problem -reporting guidelines.
-

-

To subscribe: https//lists.shorewall.net/mailman/listinfo/shorewall-newbies

-

To post to the list, post to shorewall-newbies@lists.shorewall.net.
-

-

The list archives are at http://lists.shorewall.net/pipermail/shorewall-newbies.

-

Shorewall Users Mailing List

-

The Shorewall Users Mailing list provides a way for -users to get answers to questions and to report problems. Information -of general interest to the Shorewall user community is also posted to -this list.
-

-

The Shorewall author does not monitor this list.
-

-

Before posting -to this list, please see the problem -reporting guidelines.
-

-

To subscribe: https//lists.shorewall.net/mailman/listinfo/shorewall-users

- -

To post to the list, post to shorewall-users@lists.shorewall.net. -IMPORTANT: If you are not -subscribed to the list, please say so -- otherwise, you will not be -included in any replies.
-

-

The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.

-

Note that prior to 1/1/2002, the mailing list was -hosted -at Sourceforge. The archives from -that -list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

-

Shorewall Announce Mailing List

-

This list is for announcements of general interest to -the Shorewall community. DO NOT USE THIS LIST FOR REPORTING PROBLEMS -OR ASKING FOR HELP.
-

-

To subscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-announce. -
-

- - -The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce. -

Shorewall Development Mailing List

-

The Shorewall Development Mailing list provides a forum -for the exchange of ideas about the future of Shorewall and -for coordinating ongoing Shorewall Development. DO NOT -USE THIS LIST FOR REPORTING PROBLEMS OR ASKING FOR HELP.

-

To subscribe to the mailing list: https//lists.shorewall.net/mailman/listinfo/shorewall-devel.

- -

To post to the list, post to shorewall-devel@lists.shorewall.net. 

-

The list archives are at http://lists.shorewall.net/pipermail/shorewall-devel.

-

How to Unsubscribe from one -of the Mailing Lists

-

There seems to be near-universal confusion about -unsubscribing from Mailman-managed lists although Mailman 2.1 has -attempted to make this less confusing. To unsubscribe:

- -
-

Frustrated by having to Rebuild Mailman to use it with -Postfix?

-

Check out these instructions

-

Last updated 12/03/2003 - Tom Eastep

-

Copyright -© -2001, 2002, 2003 Thomas M. Eastep.
-

-
- - diff --git a/Shorewall-docs/myfiles.xml b/Shorewall-docs/myfiles.xml index e4fbd67e7..6be94db6e 100644 --- a/Shorewall-docs/myfiles.xml +++ b/Shorewall-docs/myfiles.xml @@ -157,7 +157,7 @@ ROUTE_FILTER=No NAT_BEFORE_RULES=No DETECT_DNAT_IPADDRS=Yes MUTEX_TIMEOUT=60 -NEWNOTSYN=No +NEWNOTSYN=Yes BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=REJECT TCP_FLAGS_DISPOSITION=DROP @@ -199,9 +199,9 @@ tx Texas Peer Network in Dallas #ZONE INERFACE BROADCAST OPTIONS net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags -loc eth2 192.168.1.255 dhcp,newnotsyn -dmz eth1 192.168.2.255 newnotsyn -WiFi eth3 192.168.3.255 dhcp,maclist,newnotsyn +loc eth2 192.168.1.255 dhcp +dmz eth1 192.168.2.255 +WiFi eth3 192.168.3.255 dhcp,maclist - texas 192.168.9.255 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE @@ -592,27 +592,6 @@ gre net $TEXAS My tcstart file is just the HTB version of WonderShaper. -
- Newnotsyn file (/etc/shorewall/newnotsyn): - -
- I prefer to allow FIN and RST packets unconditionally rather - than just on newnotsyn interfaces as is the case with - the standard Shorewall ruleset. This file deletes the - Shorewall-generated rules for these packets and creates my own. - - #!/bin/sh - -for interface in `find_interfaces_by_option newnotsyn`; do - run_iptables -D newnotsyn -i $interface -p tcp --tcp-flags RST RST -j ACCEPT - run_iptables -D newnotsyn -i $interface -p tcp --tcp-flags FIN FIN -j ACCEPT -done - -run_iptables -A newnotsyn -p tcp --tcp-flags RST RST -j ACCEPT -run_iptables -A newnotsyn -p tcp --tcp-flags FIN FIN -j ACCEPT -
-
-
/sbin/ifup-local diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm deleted file mode 100644 index 699360e84..000000000 --- a/Shorewall-docs/seattlefirewall_index.htm +++ /dev/null @@ -1,396 +0,0 @@ - - - - - - Shoreline Firewall (Shorewall) 1.4 - - - -
- - - - - - -
-

Introduction to Shorewall

-

This is the Shorewall 1.4 Web Site

-The information on this site applies only to 1.4.x releases of -Shorewall. For older versions:
-
    -
  • The 1.3 site is here.
    • -
  • The 1.2 site is here.
    • -
-

Glossary

-
    -
  • Netfilter - the -packet filter facility built into the 2.4 and later Linux kernels.
    • -
  • ipchains - the packet filter facility built into the 2.2 -Linux kernels. Also the name of the utility program used to configure -and control that facility. Netfilter can be used in ipchains -compatibility mode.
    • -
  • iptables - the utility program used to configure and -control Netfilter. The term 'iptables' is often used to refer to the -combination of iptables+Netfilter (with Netfilter not in ipchains -compatibility mode).
    • -
-

What is Shorewall?

-The Shoreline Firewall, more commonly known as "Shorewall", is -high-level tool for configuring Netfilter. You describe your -firewall/gateway requirements using entries in a set of configuration -files. Shorewall reads those configuration files and with the help of -the iptables utility, Shorewall configures Netfilter to match your -requirements. Shorewall can be used on a dedicated firewall system, a -multi-function gateway/router/server or on a standalone GNU/Linux -system. Shorewall does not use Netfilter's ipchains compatibility mode -and can thus take advantage of Netfilter's connection state tracking -capabilities.
-
-Shorewall is not a -daemon. Once Shorewall has configured Netfilter, it's job is complete -although the /sbin/shorewall -program can be used at any time to monitor the Netfilter firewall.
-

Getting Started with Shorewall

-New to Shorewall? Start by selecting the QuickStart Guide that most -closely match your environment and follow the step by step instructions.
-

Looking for Information?

-The Documentation -Index is a good place to start as is the Quick Search in the frame -above. -

License

-This program is free software; you can redistribute it and/or modify it -under the terms of Version -2 of the GNU General Public License as published by the Free -Software Foundation.
-

This program is distributed in the hope that it will be -useful, but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more detail.

-

You should have received a copy of the GNU General Public -License along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA

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

Copyright © 2001-2003 Thomas M. Eastep

-

Running Shorewall on Mandrake with a two-interface setup?

-If so, the documentation on this site will not apply directly -to your setup. If you want to use the documentation that you find here, -you will want to consider uninstalling what you have and installing a -setup that matches the documentation on this site. See the Two-interface QuickStart Guide for -details.
-

News

-

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

-

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

-

12/07/2003 - Shorewall 1.4.9 Beta 1

- -

Problems Corrected since version 1.4.8:

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

Migration Issues:
-    None.
-
-New Features:

-
    -
  1. To cut down on the number of "Why are these ports closed -rather than stealthed?" questions, the SMB-related rules in -/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.
    2. -
  2. For easier identification, packets logged under the -'norfc1918' interface option are now logged out of chains named -'rfc1918'. Previously, such packets were logged under chains named -'logdrop'.
    3. -
  3. Distributors and developers seem to be regularly inventing -new naming conventions for kernel modules. To avoid the need to change -Shorewall code for each new convention, the MODULE_SUFFIX option has -been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix -for module names in your particular distribution. If MODULE_SUFFIX is -not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".
    -
    -To see what suffix is used by your distribution:
    -
    -ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
    -
    -All of the files listed should have the same suffix (extension). Set -MODULE_SUFFIX to that suffix.
    -
    -Examples:
    -
    -     If all files end in ".kzo" then set -MODULE_SUFFIX="kzo"
    -     If all files end in ".kz.o" then set -MODULE_SUFFIX="kz.o"
    4. -
  4. Support for user defined rule ACTIONS has been implemented -through two new files:
    -
    -/etc/shorewall/actions - used to list the user-defined ACTIONS.
    -/etc/shorewall/action.template - For each user defined <action>, -copy this file to /etc/shorewall/action.<action> and add the -appropriate rules for that <action>. Once an <action> has -been defined, it may be used like any of the builtin ACTIONS (ACCEPT, -DROP, etc.) in /etc/shorewall/rules.
    -
    -Example: You want an action that logs a packet at the 'info' level and -accepts the connection.
    -
    -In /etc/shorewall/actions, you would add:
    -
    -     LogAndAccept
    -
    -You would then copy /etc/shorewall/action.template to -/etc/shorewall/LogAndAccept and in that file, you would add the two -rules:
    -        LOG:info
    -        ACCEPT
    -
    -
    5. -
-

12/03/2003 - Support Torch Passed (New)

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

11/07/2003 - Shorewall 1.4.8
-
- Problems Corrected since version 1.4.7:
-

-
    -
  1. Tuomo Soini has supplied a correction to a problem that -occurs using some versions of 'ash'. The symptom is that "shorewall -start" fails with:
    - 
    -   local: --limit: bad variable name
    -   iptables v1.2.8: Couldn't load match -`-j':/lib/iptables/libipt_-j.so:
    -   cannot open shared object file: No such file or directory
    -   Try `iptables -h' or 'iptables --help' for more -information.
    2. -
  2. Andres Zhoglo has supplied a correction that avoids trying -to use the multiport match iptables facility on ICMP rules.
    - 
    -   Example of rule that previously caused "shorewall start" -to fail:
    - 
    -           -ACCEPT      loc  $FW  -icmp    0,8,11,12
    -
    -
    3. -
  3. Previously, if the following error message was issued, -Shorewall was left in an inconsistent state.
    - 
    -   Error: Unable to determine the routes through interface xxx
    -
    -
    4. -
  4. Handling of the LOGUNCLEAN option in shorewall.conf has -been corrected.
    5. -
  5. In Shorewall 1.4.2, an optimization was added. This -optimization involved creating a chain named "<zone>_frwd" for -most zones defined using the /etc/shorewall/hosts file. It has since -been discovered that in many cases these new chains contain redundant -rules and that the "optimization" turns out to be less than optimal. -The implementation has now been corrected.
    6. -
  6. When the MARK value in a tcrules entry is followed by ":F" -or ":P", the ":F" or ":P" was previously only applied to the first -Netfilter rule generated by the entry. It is now applied to all entries.
    7. -
  7. An incorrect comment concerning Debian's use of the -SUBSYSLOCK option has been removed from shorewall.conf.
    8. -
  8. Previously, neither the 'routefilter' interface option nor -the ROUTE_FILTER parameter were working properly. This has been -corrected (thanks to Eric Bowles for his analysis and patch). The -definition of the ROUTE_FILTER option has changed however. Previously, -ROUTE_FILTER=Yes was documented as enabling route filtering on all -interfaces (which didn't work). Beginning with this release, setting -ROUTE_FILTER=Yes will enable route filtering of all interfaces brought -up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can -coexist with the use of the 'routefilter' option in the interfaces file.
    9. -
  9. If MAC verification was enabled on an interface with a /32 -address and a broadcast address then an error would occur during -startup.
    10. -
  10. he NONE policy's intended use is to suppress the generating -of rules that can't possibly be traversed. This means that a policy of -NONE is inappropriate where the source or destination zone is $FW or -"all". Shorewall now generates an error message if such a policy is -given in /etc/shorewall/policy. Previously such a policy caused -"shorewall start" to fail.
    11. -
  11. The 'routeback' option was broken for wildcard interfaces -(e.g., "tun+"). This has been corrected so that 'routeback' now works -as expected in this case.
    -
    12. -
-Migration Issues:
-
    -
  1. The definition of the ROUTE_FILTER option in shorewall.conf -has changed as described in item 8) above.
    -
    2. -
-New Features:
-
    -
  1. A new QUEUE action has been introduced for rules. QUEUE -allows you to pass connection requests to a user-space filter such as -ftwall (http://p2pwall.sourceforge.net). The ftwall program allows for -effective filtering of p2p applications such as Kazaa. For example, to -use ftwall to filter P2P clients in the 'loc' zone, you would add the -following rules:
    -
    -   QUEUE   loc    -     net    tcp
    -   QUEUE   loc    -     net    udp
    -   QUEUE   loc    -     fw     udp
    -
    -You would normally want to place those three rules BEFORE any ACCEPT -rules for loc->net udp or tcp.
    -
    -Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), -Shorewall will only pass connection requests (SYN packets) to user -space. This is for compatibility with ftwall.
    2. -
  2. A BLACKLISTNEWNONLY option has been added to -shorewall.conf. When this option is set to "Yes", the blacklists -(dynamic and static) are only consulted for new connection requests. -When set to "No" (the default if the variable is not set), the -blacklists are consulted on every packet.
    -
    -Setting this option to "No" allows blacklisting to stop existing -connections from a newly blacklisted host but is more expensive in -terms of packet processing time. This is especially true if the -blacklists contain a large number of entries.
    3. -
  3. Chain names used in the /etc/shorewall/accounting file may -now begin with a digit ([0-9]) and may contain embedded dashes ("-").
    4. -
-

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

More News

-

(Leaf Logo) Jacques Nilo and Eric Wolzak have a LEAF -(router/firewall/gateway on a floppy, CD or compact flash) distribution -called Bering that features Shorewall-1.4.2 and Kernel-2.4.20. -You can find their work at: http://leaf.sourceforge.net/devel/jnilo
-

- Congratulations to Jacques and Eric on the recent release of -Bering 1.2!!!
-
- -
(Protected by Shorewall)
- -
-
-
-

Donations

-

(Starlight Logo)
- Shorewall is free but if you try it and find it useful, -please consider making a donation to Starlight -Children's Foundation. Thanks!
-

-
-
-

Updated 12/28/2003 - Tom Eastep
-

- - diff --git a/Shorewall-docs/sfindex.htm b/Shorewall-docs/sfindex.htm deleted file mode 100644 index 1cb9ee41a..000000000 --- a/Shorewall-docs/sfindex.htm +++ /dev/null @@ -1,22 +0,0 @@ - - - - -Shoreline Firewall - - - - - - - - - <body> - - <p>This page uses frames, but your browser doesn't support them.</p> - - </body> - - - - diff --git a/Shorewall-docs/shoreline.htm b/Shorewall-docs/shoreline.htm deleted file mode 100644 index 3e7f9bdb1..000000000 --- a/Shorewall-docs/shoreline.htm +++ /dev/null @@ -1,59 +0,0 @@ - - - - - About the Shorewall Author - - - - - -

-

Tom Eastep
-

-

Aging Geek - June 2003

-

"The Aging Geek" -- June 2003
-
-

- -

I am currently a member of the design team for the next-generation -operating system from the NonStop Enterprise Division of HP.

-

I became interested in Internet Security when I established a home -office in 1999 and had DSL service installed in our home. I -investigated ipchains and developed the scripts which are now -collectively known as -Seattle Firewall. Expanding on what I learned from Seattle -Firewall, I then designed and wrote Shorewall.

-

I telework from our home -in Shoreline, Washington -where -I live with my wife Tarry. 

-

- -

For information about our home network see my -Shorewall Configuration files.

-

All of our other systems are made by Compaq -(part of the new HP).

-

Last updated 7/20/2003 - Tom Eastep

-Copyright -© 2001, 2002, 2003 Thomas M. Eastep.
- - diff --git a/Shorewall-docs/shorewall_index.htm b/Shorewall-docs/shorewall_index.htm deleted file mode 100644 index bede1c576..000000000 --- a/Shorewall-docs/shorewall_index.htm +++ /dev/null @@ -1,24 +0,0 @@ - - - - -Shoreline Firewall - - - - - - - - - - - - - <body> - - <p>This page uses frames, but your browser doesn't support them.</body> - - - - diff --git a/Shorewall-docs/shorewall_mirrors.htm b/Shorewall-docs/shorewall_mirrors.htm deleted file mode 100644 index f7fef1d06..000000000 --- a/Shorewall-docs/shorewall_mirrors.htm +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - - Shorewall Mirrors - - -

Shorewall Mirrors
-

-

Remember that updates to the mirrors are often -delayed for 6-12 hours after an update to the primary rsync site. For -HTML content, the main web site (http://shorewall.sf.net) -is updated at the same time as the rsync site.

-

The main Shorewall Web Site is http://shorewall.sf.net -and is located in California, USA. It is mirrored at:

- -

The rsync site is mirrored via FTP at:

- -Search results and the mailing list archives are always fetched from -the site in Washington State.
-

Last Updated 11/14/2003 - Tom Eastep

-

Copyright © 2001, 2002, 2003 Thomas M. -Eastep
-

-
- - diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm deleted file mode 100644 index f9a594bb1..000000000 --- a/Shorewall-docs/sourceforge_index.htm +++ /dev/null @@ -1,452 +0,0 @@ - - - - - - Shoreline Firewall (Shorewall) 1.4 - - - -
-
- - - - - - -
-

Introduction
-

-
    -
  • Netfilter - the -packet -filter facility built into the 2.4 and later Linux kernels.
    • -
  • ipchains - the packet filter facility built into the 2.2 -Linux -kernels. Also the name of the utility program used to configure and -control that facility. Netfilter can be used in ipchains -compatibility mode.
    -
    • -
  • iptables - the utility program used to configure and -control -Netfilter. The term 'iptables' is often used to refer to the -combination of iptables+Netfilter (with Netfilter not in ipchains -compatibility mode).
    -
    • -
-The Shoreline Firewall, more commonly known as "Shorewall", is -high-level tool for configuring Netfilter. You describe your -firewall/gateway requirements using entries in a set of -configuration files. Shorewall reads those configuration files and -with the help of the iptables utility, Shorewall configures -Netfilter to match your requirements. Shorewall can be used on a -dedicated firewall system, a multi-function gateway/router/server -or on a standalone GNU/Linux system. Shorewall does not use -Netfilter's ipchains compatibility mode and can thus take advantage -of Netfilter's connection state tracking capabilities. -

This program is free software; you can redistribute it and/or -modify it under the terms of Version 2 of the GNU -General -Public License as published by the Free Software -Foundation.
-
-This program is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details.
-
-You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA

-

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

-

Copyright © 2001-2003 Thomas M. Eastep

-

This is the Shorewall 1.4 Web Site

-The information on this site applies only to 1.4.x releases of -Shorewall. For older versions:
-
    -
  • The 1.3 site is here.
    • -
  • The 1.2 site is here.
    -
    • -
-

Getting Started with Shorewall

-New to Shorewall? Start by selecting the QuickStart Guide that most -closely match your environment and follow the step by step -instructions.
-

Looking for Information?

-The Documentation -Index is a good place to start as is the Quick Search in the -frame above. -

Running Shorewall on Mandrake with a two-interface setup?

-If so, the documentation on this site will not apply -directly to your setup. If you want to use the documentation that -you find here, you will want to consider uninstalling what you have -and installing a setup that matches the documentation on this site. -See the Two-interface QuickStart -Guide for details. -

News

-

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

-

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

-

12/07/2003 - Shorewall 1.4.9 Beta 1 (New)
-

- -

Problems Corrected since version 1.4.8:
-

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

Migration Issues:
-
-    None.
-
-New Features:
-

-
    -
  1. To cut down on the number of "Why are these ports closed -rather -than stealthed?" questions, the SMB-related rules in -/etc/shorewall/common.def have been changed from 'reject' to -'DROP'.
    2. -
  2. For easier identification, packets logged under the -'norfc1918' -interface option are now logged out of chains named 'rfc1918'. -Previously, such packets were logged under chains named -'logdrop'.
    3. -
  3. Distributors and developers seem to be regularly inventing -new -naming conventions for kernel modules. To avoid the need to change -Shorewall code for each new convention, the MODULE_SUFFIX option -has been added to shorewall.conf. MODULE_SUFFIX may be set to the -suffix for module names in your particular distribution. If -MODULE_SUFFIX is not set in shorewall.conf, Shorewall will use the -list "o gz ko o.gz".
    -
    -To see what suffix is used by your distribution:
    -
    -ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
    -
    -All of the files listed should have the same suffix (extension). -Set MODULE_SUFFIX to that suffix.
    -
    -Examples:
    -
    -     If all files end in ".kzo" then set -MODULE_SUFFIX="kzo"
    -     If all files end in ".kz.o" then set -MODULE_SUFFIX="kz.o"
    4. -
  4. Support for user defined rule ACTIONS has been implemented -through two new files:
    -
    -/etc/shorewall/actions - used to list the user-defined ACTIONS.
    -/etc/shorewall/action.template - For each user defined -<action>, copy this file to -/etc/shorewall/action.<action> and add the appropriate rules -for that <action>. Once an <action> has been defined, -it may be used like any of the builtin ACTIONS (ACCEPT, DROP, etc.) -in /etc/shorewall/rules.
    -
    -Example: You want an action that logs a packet at the 'info' level -and accepts the connection.
    -
    -In /etc/shorewall/actions, you would add:
    -
    -     LogAndAccept
    -
    -You would then copy /etc/shorewall/action.template to -/etc/shorewall/LogAndAccept and in that file, you would add the two -rules:
    -        LOG:info
    -        ACCEPT
    5. -
-

12/03/2003 - Support Torch Passed (New)

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

11/01/2003 - Shorewall 1.4.8 RC2 (New)

-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 -SUBSYSLOCK -option has been removed from shorewall.conf.
    8. -
  8. Previously, neither the 'routefilter' interface option nor -the -ROUTE_FILTER parameter were working properly. This has been -corrected (thanks to Eric Bowles for his analysis and patch). The -definition of the ROUTE_FILTER option has changed however. -Previously, ROUTE_FILTER=Yes was documented as enabling route -filtering on all interfaces (which didn't work). Beginning with -this release, setting ROUTE_FILTER=Yes will enable route filtering -of all interfaces brought up while Shorewall is started. As a -consequence, ROUTE_FILTER=Yes can coexist with the use of the -'routefilter' option in the interfaces file.
    9. -
  9. If MAC verification was enabled on an interface with a /32 -address and a broadcast address then an error would occur during -startup.
    10. -
-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 (New)

-

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

More News

- -

- -

(Leaf Logo) Jacques Nilo and Eric Wolzak have a LEAF -(router/firewall/gateway on a floppy, CD or compact flash) -distribution called Bering that features Shorewall-1.4.2 and -Kernel-2.4.20. You can find their work at: http://leaf.sourceforge.net/devel/jnilo

- Congratulations to Jacques and Eric on the recent release of -Bering 1.2!!!
-

SourceForge Logo

- -

- -

This site is hosted by the generous folks at SourceForge.net

-
-
-

Donations

-
-
-
- - - - - - -
-

Starlight Foundation Logo

-


- Shorewall is free but if you try it and find it -useful, please consider making a donation to Starlight -Children's Foundation. Thanks!

-
-

Updated 12/28/2003 - Tom -Eastep
-

- - diff --git a/Shorewall-docs/starting_and_stopping_shorewall.xml b/Shorewall-docs/starting_and_stopping_shorewall.xml index 3b5fae8ea..2c3b00293 100755 --- a/Shorewall-docs/starting_and_stopping_shorewall.xml +++ b/Shorewall-docs/starting_and_stopping_shorewall.xml @@ -15,7 +15,7 @@ - 2003-12-28 + 2003-12-29 2001-2003 @@ -39,11 +39,13 @@ If you have a permanent internet connection such as DSL or Cable, I recommend that you start the firewall automatically at boot. Once you have installed firewall in your init.d directory, simply type - chkconfig --add firewall. This will - start the firewall in run levels 2-5 and stop it in run levels 1 and 6. If - you want to configure your firewall differently from this default, you can - use the --level option in chkconfig (see man - chkconfig) or using your favorite graphical run-level editor. + chkconfig --add shorewall (insserv + -d shorewall if your distribution uses insserv to + install startup scripts). This will start the firewall in run levels 2-5 + and stop it in run levels 1 and 6. If you want to configure your firewall + differently from this default, you can use the --level + option in chkconfig (see man chkconfig) or using your + favorite graphical run-level editor. @@ -120,11 +122,11 @@ - shorewall show chain1 [ chain2 ... ] - - produce a verbose report about the listed chains (iptables -L chain -n - -v) Note: You may only list one chain in the show command when running - Shorewall version 1.4.6 and earlier. Version 1.4.7 and later allow you - to list multiple chains in one command. + shorewall show <chain1> [ <chain2> ... + ] - produce a verbose report about the listed chains + (iptables -L chain -n -v) Note: You may only list one chain in the + show command when running Shorewall version 1.4.6 and earlier. Version + 1.4.7 and later allow you to list multiple chains in one command. @@ -153,9 +155,11 @@ - shorewall monitor [ delay ] - Continuously - display the firewall status, last 20 log entries and nat. When the log - entry display changes, an audible alarm is sounded. + shorewall monitor [ <delay> ] - + Continuously display the firewall status, last 20 log entries and nat. + When the log entry display changes, an audible alarm is sounded. The + <delay> indicates the number of seconds + between updates with the default being 10 seconds. @@ -183,10 +187,11 @@ shorewall try <configuration-directory> - [ timeout ] - Restart shorewall using the specified - configuration and if an error occurs or if the timeout option is given - and the new configuration has been up for that many seconds then - shorewall is restarted using the standard configuration. + [ <timeout> ] - Restart shorewall using the + specified configuration and if an error occurs or if the + <timeout> option is given and the new + configuration has been up for that many seconds then shorewall is + restarted using the standard configuration. @@ -210,7 +215,7 @@ shorewall iprange <address1>-<address2> - Decomposes the specified range of IP addresses into the equivalent - list of network/host addresses. + list of network/host addresses @@ -267,21 +272,25 @@ shorewall delete ipsec0:192.0.2.24 vpn1 -- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1 +
- The shorewall start, shorewall restart, shorewall check, and - shorewall try commands allow you to specify which Shorewall configuration - to use: +
+ Alternate Configurations + + The shorewall start, shorewall restart, + shorewall check, and shorewall try commands + allow you to specify which Shorewall configuration to use: shorewall [ -c <configuration-directory> ] {start|restart|check} shorewall try <configuration-directory> - If a configuration-directory is specified, each - time that Shorewall is going to use a file in /etc/shorewall it will first - look in the configuration-directory . If the file is - present in the configuration-directory, that file - will be used; otherwise, the file in /etc/shorewall will be used. When - changing the configuration of a production firewall, I recommend the - following: + If a <configuration-directory> is + specified, each time that Shorewall is going to use a file in + /etc/shorewall it will first look in the + <configuration-directory> . If the file is present in + the <configuration-directory>, that file will + be used; otherwise, the file in /etc/shorewall will be used. When changing + the configuration of a production firewall, I recommend the following: @@ -298,7 +307,7 @@ - shorewall -c . check + shorewall -c ./ check @@ -330,6 +339,10 @@ rm -rf /etc/test +
+ +
+ Shorewall State Diagram The Shorewall State Diargram is depicted below. diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm deleted file mode 100644 index 50b01becf..000000000 --- a/Shorewall-docs/three-interface.htm +++ /dev/null @@ -1,1080 +0,0 @@ - - - - - - - - Three-Interface Firewall - - -

Three-Interface Firewall
-

-

Setting up a Linux system as a firewall for a small -network with DMZ is a fairly straight-forward task if you understand -the basics and follow the documentation.

-

This guide doesn't attempt to acquaint you with all of the features -of Shorewall. It rather focuses on what is required to configure -Shorewall in one of its more popular configurations:

- -

Here is a schematic of a typical installation.

-

-

Shorewall requires that you have the iproute/iproute2 package -installed (on RedHat, the package is called iproute). You -can tell if this package is installed by the presence of an ip -program on your firewall system. As root, you can use the 'which' -command to check for this program:

-
     [root@gateway root]# which ip
     /sbin/ip
     [root@gateway root]#
-

I recommend that you first read through the guide to familiarize -yourself with what's involved then go back through it again making your -configuration changes. Points at which configuration changes are -recommended are flagged with . Configuration notes that are unique to -LEAF/Bering are marked with (LEAF Logo)

-

-    If you edit your configuration files on a Windows -system, you must save them as Unix files if your editor supports that -option or you must run them through dos2unix before trying -to use them. Similarly, if you copy a configuration file from your -Windows hard drive to a floppy disk, you must run dos2unix against the -copy before using it with Shorewall.

- -

PPTP/ADSL

-    If you -have an ADSL Modem and you use PPTP to communicate with a server in -that modem, you must make the changes -recommended here in addition to those detailed below.  ADSL -with PPTP is most commonly found in Europe, notably in Austria.
-

Shorewall Concepts

-

    The configuration files for Shorewall are -contained in the directory /etc/shorewall -- for simple setups, you -will only need -to deal with a few of these as described in this guide. After you have -installed Shorewall, download the three-interface -sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the -files to /etc/shorewall (the files will replace files with the same -names that were placed in /etc/shorewall when Shorewall was -installed).

-

As each file is introduced, I suggest that you look through the -actual file on your system -- each file contains detailed configuration -instructions and default entries.

-

Shorewall views the network where it is running as being composed of -a set of zones. In the three-interface sample configuration, -the following zone names are used:

- - - - - - - - - - - - - - - - - - - -
NameDescription
netThe Internet
locYour Local Network
dmzDemilitarized Zone
-

Zone names are defined in -/etc/shorewall/zones.

-

Shorewall also recognizes the firewall system as its own zone - by -default, the firewall itself is known as fw.

-

Rules about what traffic to allow and what traffic to deny are -expressed in terms of zones.

- -

For each connection request entering the firewall, the request is -first checked against the /etc/shorewall/rules file. If no rule in that -file matches the connection request then the first policy in -/etc/shorewall/policy that matches the request is applied. If that -policy is REJECT -or DROP  the request is first checked against the rules in -/etc/shorewall/common if that file exists; otherwise the file -/etc/shorewall/common.def is checked
-

-

The /etc/shorewall/policy file included with the three-interface -sample has the following policies:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Source ZoneDestination ZonePolicyLog LevelLimit:Burst
locnetACCEPT  
netallDROPinfo 
allallREJECTinfo 
-
-
-

In the three-interface sample, the line below is included but -commented out. If you want your firewall system to have full access to -servers on the internet, uncomment that line.

- - - - - - - - - - - - - - - - - -
Source ZoneDestination ZonePolicyLog LevelLimit:Burst
fwnetACCEPT  
-
-

The above policy will:

-
    -
  1. allow all connection requests from your local -network to the internet
    2. -
  2. drop (ignore) all connection requests from the internet to your -firewall or local network
    3. -
  3. optionally accept all connection requests from the firewall to -the internet (if you uncomment the additional policy)
    4. -
  4. reject all other connection requests.
    5. -
-

-    At this point, edit your /etc/shorewall/policy file -and make any changes that you wish.

-

Network Interfaces

-

-

The firewall has three network interfaces. Where -Internet connectivity is through a cable or DSL "Modem", the External -Interface will be the ethernet adapter that is connected to -that "Modem" (e.g., eth0)  unless you connect via Point-to-Point -Protocol over Ethernet (PPPoE) or Point-to-Point -Tunneling Protocol (PPTP) in which case the -External Interface will be a ppp interface (e.g., ppp0). If you -connect via a regular modem, your External Interface will also be ppp0. -If you connect using ISDN, you external interface will be ippp0.

-

    If your external interface is ppp0 -or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

-

Your Local Interface will be an ethernet -adapter (eth0, eth1 or eth2) and will be connected to a hub or switch. -Your local computers will be connected to the same switch (note: If you -have only a single local system, you can connect the firewall directly -to the computer using a cross-over cable).

-

Your DMZ Interface will also be an ethernet -adapter (eth0, eth1 or eth2) and will be connected to a hub or switch. -Your DMZ computers will be connected to the same switch (note: If -you have only a single DMZ system, you can connect the firewall -directly to the computer using a cross-over cable).

-

Do not connect the internal and -external interface to the same hub or switch except for testing AND you -are running Shorewall version 1.4.7 or later.  When using these -recent -versions, you can test using this kind of configuration if you specify -the arp_filter -option in /etc/shorewall/interfaces for all interfaces connected to the -common hub/switch. Using such a setup with a production firewall is -strongly recommended against.

-

    The Shorewall three-interface sample -configuration assumes that the external interface is eth0, the -local interface is eth1 and the DMZ interface is eth2. -If your configuration is different, you will have to modify the sample -/etc/shorewall/interfaces file accordingly. While you are there, you -may wish to review the list of options that are specified for the -interfaces. Some hints:

- -

IP Addresses

-

Before going further, we should say a few words about -Internet Protocol (IP) addresses. Normally, your ISP will -assign -you a single Public IP address. This address may be assigned -via the Dynamic Host Configuration Protocol (DHCP) or as part -of establishing your connection when you dial in (standard modem) or -establish your PPP connection. In rare cases, your ISP may assign you -a static IP address; that means that you configure your -firewall's -external interface to use that address permanently. Regardless -of how the address is assigned, it will be shared by all of your -systems -when you access the Internet. You will have to assign your own -addresses for your internal network (the local and DMZ Interfaces on -your firewall -plus your other computers). RFC 1918 reserves several Private IP -address ranges for this purpose:

-
-
     10.0.0.0    - 10.255.255.255
     172.16.0.0  - 172.31.255.255
     192.168.0.0 - 192.168.255.255
-
-
-

    Before starting Shorewall, you should -look at -the IP address of your external interface and if it is one of -the above ranges, you should remove the 'norfc1918' option from -the external interface's entry in /etc/shorewall/interfaces.

-
-
-

You will want to assign your local addresses from one -sub-network or subnet and your DMZ addresses from -another subnet. For our purposes, we can consider a subnet to -consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet -will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 -is reserved as the Subnet Address and x.y.z.255 is reserved -as the Subnet Broadcast Address. In Shorewall, a subnet -is described using Classless -InterDomain Routing (CIDR) notation with consists of the -subnet address followed by "/24". The "24" refers to the number of -consecutive "1" bits from the left of the subnet mask.

-
-
-

Example sub-network:

-
-
-
- - - - - - - - - - - - - - - - - - - -
Range:10.10.10.0 - 10.10.10.255
Subnet Address:10.10.10.0
Broadcast Address:10.10.10.255
CIDR Notation:10.10.10.0/24
-
-
-
-

It is conventional to assign the internal interface -either the first usable address in the subnet (10.10.10.1 in the above -example) or the last usable address (10.10.10.254).

-
-
-

One of the purposes of subnetting is to allow all -computers in the subnet to understand which other computers can be -communicated with directly. To communicate with systems outside of the -subnetwork, systems send packets through a  gateway  -(router).

-
-
-

    Your local computers (Local Computers -1 & 2) should be configured with their default gateway set -to -the IP address of the firewall's internal interface and your DMZ -computers ( DMZ Computers 1 & 2) should be configured with their -default gateway set to the IP address of the firewall's DMZ -interface.   -

-
-

The foregoing short discussion barely scratches the -surface regarding subnetting and routing. If you are interested in -learning more about IP addressing and routing, I highly recommend "IP -Fundamentals: What Everyone Needs to Know about Addressing & -Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

-

The remainder of this quide will assume that you have -configured your network as shown here:

-

-

The default gateway for the DMZ computers would be -10.10.11.254 and the default gateway for the Local computers would be -10.10.10.254.
-

-

    WARNING: -Your ISP  might assign your external interface an -RFC 1918 address. If that address is in the 10.10.10.0/24 subnet then -you will need to select a DIFFERENT RFC 1918 subnet for your local -network and if it is in the 10.10.11.0/24 subnet then you will need to -select a different RFC 1918 subnet for your DMZ.
-

-

IP Masquerading (SNAT)

-

The addresses reserved by RFC 1918 are sometimes -referred to as non-routable because the Internet backbone -routers -don't forward packets which have an RFC-1918 destination address. -When one of your local systems (let's assume local computer 1) sends -a connection request to an internet host, the firewall must perform -Network Address Translation (NAT). The firewall rewrites the -source address in the packet to be the address of the firewall's -external -interface; in other words, the firewall makes it look as if the -firewall itself is initiating the connection.  This is necessary -so that the destination host will be able to route return packets back -to the firewall (remember that packets whose destination address is -reserved by RFC -1918 can't be routed accross the internet). When the firewall receives -a return packet, it rewrites the destination address back to 10.10.10.1 -and forwards the packet on to local computer 1.

-

On Linux systems, the above process is often referred -to -as IP Masquerading and you will also see the term Source -Network -Address Translation (SNAT) used. Shorewall follows the convention -used -with Netfilter:

- -

In Shorewall, both Masquerading and SNAT are configured -with entries in the /etc/shorewall/masq file.

-

    If your external firewall interface is -eth0, your local interface eth1 and your DMZ interface -is eth2 then you do not need to modify the file provided with -the sample. -Otherwise, edit /etc/shorewall/masq and change it to match your -configuration.

-

    If your external IP is static, you can -enter it -in the third column in the /etc/shorewall/masq entry if you like -although your firewall will work fine if you leave that column empty. -Entering your static IP in column 3 makes
-processing outgoing packets a little more efficient.
-

-

    If you are using the Debian -package, please check your shorewall.conf file to ensure that the -following are set correctly; if they are not, change them appropriately:
-

- -

Port Forwarding (DNAT)

-

One of your goals will be to run one or more servers on -your DMZ computers. Because these computers have RFC-1918 addresses, -it is not possible for clients on the internet to connect directly -to them. It is rather necessary for those clients to address their -connection requests to your firewall who rewrites the destination -address to the address of your server and forwards the packet to that -server. When your server responds, the firewall automatically performs -SNAT to rewrite the source address in the response.

-

The above process is called Port Forwarding or -Destination Network Address Translation (DNAT). You configure port -forwarding using DNAT rules in the /etc/shorewall/rules file.

-

The general form of a simple port forwarding rule in -/etc/shorewall/rules is:

-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetdmz:<server local ip address> [:<server -port>]<protocol><port>  
-
-

If you don't specify the <server port>, it is assumed -to -be the same as <port>.

-

Example - you run a Web Server on DMZ 2 and you want to forward -incoming TCP port 80 to that system:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
-
-

A couple of important points to keep in mind:

- -
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetdmz:10.10.11.2:80tcp5000  
-
-

If you want to be able to access your server from the local network -using your external address, then if you have a static external IP you -can replace the loc->dmz rule above with:

-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetdmz:10.10.11.2:80tcp80-<external IP>
-
-

If you have a dynamic ip then you must ensure that your external -interface is up before starting Shorewall and you must take steps as -follows (assume that your external interface is eth0):

-
    -
  1. Include the following in /etc/shorewall/params:
    -
    -ETH0_IP=`find_interface_address eth0`
    - 
    2. -
  2. Make your loc->dmz rule:
    3. -
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATloc
- 		dmz:10.10.11.2:80tcp80-$ETH0_IP
-
-

If you want to access your server from the DMZ using your external -IP address, see FAQ 2a.

-

-    At this point, add the DNAT and ACCEPT rules for -your servers.

-

Domain Name Server (DNS)

-

Normally, when you connect to your ISP, as part of -getting an IP address your firewall's Domain Name Service (DNS) -resolver will be automatically configured (e.g., the /etc/resolv.conf -file will be written). Alternatively, your ISP may have given you -the IP address of a pair of DNS name servers for you to -manually -configure as your primary and secondary name servers. It is your -responsibility to configure the resolver in your internal systems. -You can take one of two approaches:

- -
-

If you run the name server on the firewall: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp53  
ACCEPTlocfwudp53  
ACCEPTdmzfwtcp53  
ACCEPTdmzfwudp53  
-

-
-
-
-

Run name server on DMZ computer 1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocdmz:10.10.11.1tcp53  
ACCEPTlocdmz:10.10.11.1udp53  
ACCEPTfwdmz:10.10.10.1tcp53  
ACCEPTfwdmz:10.10.10.1udp53  
-
-
-
-

Other Connections

-
-
-

The three-interface sample includes the following rules:

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTfwnetudp53  
ACCEPTfwnettcp53  
-
-
-
-

Those rules allow DNS access from your firewall and may -be removed if you commented out the line in /etc/shorewall/policy -allowing all connections from the firewall to the internet.

-
-
-

The sample also includes:

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp22  
ACCEPTlocdmztcp22  
-
-
-
-

That rule allows you to run an SSH server on your -firewall and in each of your DMZ systems and to connect to those -servers from your local systems.

-
-
-

If you wish to enable other connections between your -systems, the general format is:

-
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPT<source zone><destination zone><protocol><port>  
-
-
-
-

Example - You want to run a publicly-available DNS -server on your firewall system:

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
ACCEPTnetfwudp
- 		53#Allow DNS accessfrom the internet
-
-
-
-

Those two rules would of course be in addition to the -rules listed above under "If you run the name server on your firewall".

-
-
-

If you don't know what port and protocol a particular -application uses, look here.

-
-
-

Important: I don't recommend enabling telnet -to/from the internet because it uses clear text (even for login!). If -you want shell access to your firewall from the internet, use -SSH:

-
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
-
-
-
-

-

(LEAF Logo)     Bering users will want to -add the following two rules to be compatible with Jacques's Shorewall -configuration.
-

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTloc
- 		fwudp
- 		53
- 		#Allow DNS Cache towork
-
ACCEPTlocfwtcp80#Allow weblet to work
-
-
-
-

    Now modify /etc/shorewall/rules to add -or remove other connections as required.

-
-
-

Starting and Stopping Your Firewall

-
-
-

Arrow     The installation -procedure configures your system to start Shorewall at system -boot  but beginning with Shorewall version 1.3.9 startup is -disabled so that your system won't try to start Shorewall before -configuration is complete. Once you have completed configuration of -your firewall, you can enable Shorewall startup by removing the file -/etc/shorewall/startup_disabled.
-

-

IMPORTANT: Users of the .deb package must edit -/etc/default/shorewall and set 'startup=1'.
-

-
-
-

The firewall is started using the "shorewall start" -command and stopped using "shorewall stop". When the firewall is -stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. -A running firewall may be restarted using the "shorewall restart" -command. If you want to totally remove any trace of Shorewall -from your Netfilter configuration, use "shorewall clear".

-
-
-

    The three-interface sample assumes -that you want -to enable routing to/from eth1 (your local network) and eth2 -(DMZ) when Shorewall is stopped. If these two interfaces don't -connect to your local network and DMZ or if you want to enable a -different set of hosts, modify /etc/shorewall/routestopped accordingly.

-
-
-

WARNING: If you are connected to your firewall -from the internet, do not issue a "shorewall stop" command unless -you have added an entry for the IP address that you are connected -from to /etc/shorewall/routestopped. -Also, I don't recommend using "shorewall restart"; it is better to -create an alternate -configuration and test it using the "shorewall try" command.
-

-

Additional Recommended Reading

-I highly recommend that you review the Common Configuration File -Features page -- it contains helpful tips about Shorewall features -than make administering your firewall easier. -
-

Last updated 11/15/2003 - Tom Eastep

-

Copyright 2002, -2003 Thomas M. Eastep
-

-
-
- - diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm deleted file mode 100644 index e43e72d7b..000000000 --- a/Shorewall-docs/two-interface.htm +++ /dev/null @@ -1,956 +0,0 @@ - - - - - - - - Two-Interface Firewall - - - -

Basic Two-Interface Firewall
-

-

Setting up a Linux system as a firewall for a small -network is a fairly straight-forward task if you understand the basics -and follow the documentation.

-

This guide doesn't attempt to acquaint you with all of the features -of Shorewall. It rather focuses on what is required to configure -Shorewall in its most common configuration:

- -

Here is a schematic of a typical installation.

-

-

If you are running Shorewall under Mandrake 9.0 or later, you can -easily configure the above setup using the Mandrake "Internet -Connection -Sharing" applet. From the Mandrake Control Center, select "Network -& Internet" then "Connection Sharing".
-

-

Note however, that the Shorewall configuration produced by -Mandrake Internet Connection Sharing is strange and is apt to confuse -you if you use the rest of this documentation (it has two local zones; -"loc" and "masq" where "loc" is empty; this conflicts with this -documentation which assumes a single local zone "loc"). We therefore -recommend that once you have set up this sharing that you uninstall the -Mandrake Shorewall RPM and install the one from the download page then follow the instructions in -this Guide.
-

-

Shorewall requires that you have the iproute/iproute2 package -installed (on RedHat, the package is called iproute). You -can tell if this package is installed by the presence of an ip -program on your firewall system. As root, you can use the 'which' -command to check for this program:

-
     [root@gateway root]# which ip
     /sbin/ip
     [root@gateway root]#
-

I recommend that you first read through the guide to familiarize -yourself with what's involved then go back through it again making your -configuration changes. Points at which configuration changes are -recommended are flagged with . Configuration notes that are unique to -LEAF/Bering are marked with (LEAF Logo)

-

-    If you edit your configuration files on a Windows -system, you must save them as Unix files if your editor supports that -option or you must run them through dos2unix before trying -to use them. Similarly, if you copy a configuration file from your -Windows hard drive to a floppy disk, you must run dos2unix against the -copy before using it with Shorewall.

- -

PPTP/ADSL

-    If you -have an ADSL Modem and you use PPTP to communicate with a server in -that modem, you must make the changes -recommended here in addition to those detailed below. ADSL with -PPTP is most commonly found in Europe, notably in Austria.
-

Shorewall Concepts

-

    The configuration files for Shorewall are -contained in the directory /etc/shorewall -- for simple setups, you -will only need to deal with a few of these as described in this guide. -After you have installed Shorewall, download -the two-interface -sample, un-tar it (tar -zxvf two-interfaces.tgz) and and copy the -files -to /etc/shorewall (these files will replace files with the same -name).

-

As each file is introduced, I suggest that you look through the -actual file on your system -- each file contains detailed configuration -instructions and default entries.

-

Shorewall views the network where it is running as being composed of -a set of zones. In the two-interface sample configuration, the -following zone names are used:

- - - - - - - - - - - - - - - -
NameDescription
netThe Internet
locYour Local Network
-

Zones are defined in the -/etc/shorewall/zones file.

-

Shorewall also recognizes the firewall system as its own zone - by -default, the firewall itself is known as fw.

-

Rules about what traffic to allow and what traffic to deny are -expressed in terms of zones.

- -

For each connection request entering the firewall, the request is -first checked against the /etc/shorewall/rules file. If no rule in -that file matches the connection request then the first policy -in /etc/shorewall/policy that matches the request is applied. -If that policy is REJECT or DROP  the request is first checked -against -the rules in /etc/shorewall/common if that file exists; otherwise the -rules in /etc/shorewall/common.def are checked.

-

The /etc/shorewall/policy file included with the two-interface -sample -has the following policies:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Source ZoneDestination ZonePolicyLog LevelLimit:Burst
locnetACCEPT  
netallDROPinfo 
allallREJECTinfo 
-
-
-

In the two-interface sample, the line below is included but -commented out. If you want your firewall system to have full access to -servers on the internet, uncomment that line.

- - - - - - - - - - - - - - - - - -
Source ZoneDestination ZonePolicyLog LevelLimit:Burst
fwnetACCEPT  
-
-

The above policy will:

-
    -
  1. allow all connection requests from your local network to the -internet
    2. -
  2. drop (ignore) all connection requests from the internet to your -firewall or local network
    3. -
  3. optionally accept all connection requests from the firewall to -the internet (if you uncomment the additional policy)
    4. -
  4. reject all other connection requests.
    5. -
-

-    At this point, edit your /etc/shorewall/policy -and make any changes that you wish.

-

Network Interfaces

-

-

The firewall has two network interfaces. Where Internet -connectivity -is through a cable or DSL "Modem", the External Interface will -be -the ethernet adapter that is connected to that "Modem" (e.g., eth0)  -unless you connect via Point-to-Point -Protocol over Ethernet (PPPoE) or Point-to-Point -Tunneling Protocol (PPTP) in which case the -External Interface will be a ppp interface (e.g., ppp0). If you -connect via a regular modem, your External Interface will also be ppp0. -If you connect via ISDN, your external interface will be ippp0.

-

    If your external interface is ppp0 -or ippp0  then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

-

Your Internal Interface will be an ethernet -adapter (eth1 or eth0) and will be connected to a hub or switch. Your -other computers will be connected to the same hub/switch (note: -If you have only a single internal system, you can connect the firewall -directly to the computer using a cross-over cable).

-

Do not connect the internal and -external interface to the same hub or switch except for testing AND you -are running Shorewall version 1.4.7 or later.  When using these -recent versions, you can test using this kind of configuration if you -specify the arp_filter option -in /etc/shorewall/interfaces for all interfaces connected to the common -hub/switch. Using such a setup with a production firewall is strongly -recommended against.
-

-

    The Shorewall two-interface -sample configuration assumes that the external interface is eth0 -and the internal interface is eth1. If your configuration is -different, you will have to modify the sample /etc/shorewall/interfaces file -accordingly. While you are there, you may wish to review the list of -options that are specified for the interfaces. Some hints:

- -

IP Addresses

-

Before going further, we should say a few words about -Internet Protocol (IP) addresses. Normally, your ISP will -assign you a single Public IP address. This address may be -assigned via the Dynamic Host Configuration Protocol (DHCP) or -as part of establishing your connection when you dial in (standard -modem) or establish your PPP connection. In rare cases, your ISP may -assign you a static IP address; that means that you configure -your firewall's external interface to use that address permanently. However -your external address is assigned, it will be shared by all of your -systems when you access the Internet. You will have to assign your own -addresses in your internal network (the Internal Interface on your -firewall plus your other computers). RFC 1918 reserves several Private -IP address ranges for this purpose:

-
-
     10.0.0.0    - 10.255.255.255
     172.16.0.0  - 172.31.255.255
     192.168.0.0 - 192.168.255.255
-
-
-

    Before starting Shorewall, you should -look at the IP address of your external interface and if it is one of -the above ranges, you should remove the 'norfc1918' option from the -external interface's entry in /etc/shorewall/interfaces.

-
-
-

You will want to assign your addresses from the same -sub-network (subnet).  For our purposes, we can -consider a subnet to consists of a range of addresses x.y.z.0 - -x.y.z.255. Such a subnet will have a Subnet Mask of -255.255.255.0. The -address x.y.z.0 is reserved as the Subnet Address and x.y.z.255 -is reserved as the Subnet Broadcast Address. In -Shorewall, a subnet is described using Classless InterDomain -Routing (CIDR) notation with consists of the subnet address -followed by "/24". The "24" refers to the number of consecutive leading -"1" bits from the left of the subnet mask.

-
-
-

Example sub-network:

-
-
-
- - - - - - - - - - - - - - - - - - - -
Range:10.10.10.0 - 10.10.10.255
Subnet Address:10.10.10.0
Broadcast Address:10.10.10.255
CIDR Notation:10.10.10.0/24
-
-
-
-

It is conventional to assign the internal interface -either the first usable address in the subnet (10.10.10.1 in the above -example) or the last usable address (10.10.10.254).

-
-
-

One of the purposes of subnetting is to allow all -computers in the subnet to understand which other computers can be -communicated with directly. To communicate with systems outside of the -subnetwork, systems send packets through a  gateway  -(router).

-
-
-

    Your local computers (computer 1 and -computer 2 in the above diagram) should be configured with their -default gateway to be the IP address of the firewall's internal -interface.     

-
-

The foregoing short discussion barely scratches the -surface regarding subnetting and routing. If you are interested in -learning more about IP addressing and routing, I highly recommend "IP -Fundamentals: What Everyone Needs to Know about Addressing & -Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

-

The remainder of this quide will assume that you have -configured your network as shown here:

-

-

The default gateway for computer's 1 & 2 would be -10.10.10.254.
-

-

    WARNING: -Your ISP might assign your external interface an RFC 1918 -address. If that address -is in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT -RFC 1918 subnet for your local network.
-

-

IP Masquerading (SNAT)

-

The addresses reserved by RFC 1918 are sometimes -referred to as non-routable because the Internet backbone -routers don't forward packets which have an RFC-1918 destination -address. When one of your local systems (let's assume computer 1) sends -a -connection request to an internet host, the firewall must perform -Network Address Translation (NAT). The firewall rewrites -the source address in the packet to be the address of the firewall's -external interface; in other words, the firewall makes it look as -if the firewall itself is initiating the connection.  This is -necessary -so that the destination host will be able to route return packets back -to the firewall (remember that packets whose destination address -is reserved by RFC 1918 can't be routed across the internet so the -remote host can't address its response to computer 1). When the -firewall -receives a return packet, it rewrites the destination address back to -10.10.10.1 and forwards the packet on to computer 1.

-

On Linux systems, the above process is often referred -to -as IP Masquerading but you will also see the term Source -Network -Address Translation (SNAT) used. Shorewall follows the convention -used -with Netfilter:

- -

In Shorewall, both Masquerading and SNAT are configured -with entries in the /etc/shorewall/masq file. You will normally use -Masquerading if your external IP is dynamic and SNAT if the IP -is static.

-

    If your external firewall interface is -eth0, you do not need to modify the file provided with the -sample. Otherwise, edit /etc/shorewall/masq and change the first column -to the name of your external interface and the second column to the -name of your internal interface.

-

    If your external IP is static, you can -enter it in the third column in the /etc/shorewall/masq entry if you -like although your firewall will work fine if you leave that column -empty. Entering your static IP in column 3 makes processing outgoing -packets a little more efficient.
-
- -    If you are using the Debian package, please check -your -shorewall.conf file to ensure that the following are set correctly; -if they are not, change them appropriately:
-

- -

Port Forwarding (DNAT)

-

One of your goals may be to run one or more servers on -your local computers. Because these computers have RFC-1918 addresses, -it is not possible for clients on the internet to connect directly to -them. It is rather necessary for those clients to address their -connection requests to the firewall who rewrites the destination -address to the address of your server and forwards the packet to -that server. When your server responds, the firewall automatically -performs SNAT to rewrite the source address in the response.

-

The above process is called Port Forwarding or -Destination Network Address Translation (DNAT). You configure port -forwarding using DNAT rules in the /etc/shorewall/rules file.

-

The general form of a simple port forwarding rule in -/etc/shorewall/rules is:

-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:<server local ip address> [:<server -port>]<protocol><port>  
-
-

Example 1 - you run a Web Server on computer 2 and you want to -forward -incoming TCP port 80 to that system:

-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:10.10.10.2tcp80  
-
-

Example 2 - you run an FTP Server on computer 1 so you want to -forward -incoming TCP port 21 to that system:

-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:10.10.10.1tcp21
- 		  
-
-

For FTP, you will also need to have FTP connection tracking and NAT -support -in your kernel. For vendor-supplied kernels, this means that the -ip_conntrack_ftp -and ip_nat_ftp modules must be loaded. Shorewall will automatically -load -these modules if they are available and located in the standard place -under -/lib/modules/<kernel version>/kernel/net/ipv4/netfilter.
-

-

A couple of important points to keep in mind:

- -
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:10.10.10.2:80tcp5000  
-
-

-    At this point, modify /etc/shorewall/rules to -add any DNAT rules that you require.

-

Domain Name Server (DNS)

-

Normally, when you connect to your ISP, as part of -getting an IP address your firewall's Domain Name Service (DNS) -resolver will be automatically configured (e.g., the /etc/resolv.conf -file will be written). Alternatively, your ISP may have given you -the IP address of a pair of DNS name servers for you to -manually configure as your primary and secondary name servers. -Regardless -of how DNS gets configured on your firewall, it is your -responsibility to configure the resolver in your internal systems. You -can take -one of two approaches:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp53  
ACCEPTlocfwudp53  
-
-
-

Other Connections

-
-
-

The two-interface sample includes the following rules:

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTfwnettcp53  
ACCEPTfwnetudp53  
-
-
-
-

Those rules allow DNS access from your firewall and may -be removed if you uncommented the line in /etc/shorewall/policy -allowing all connections from the firewall to the internet.

-
-
-

The sample also includes:

-
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp22  
-
-
-
-

That rule allows you to run an SSH server on your -firewall and connect to that server from your local systems.

-
-
-

If you wish to enable other connections between your -firewall and other systems, the general format is:

-
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPT<source zone><destination zone><protocol><port>  
-
-
-
-

Example - You want to run a Web Server on your firewall -system:

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp80#Allow web accessfrom the internet
ACCEPTlocfwtcp80#Allow web accessfrom the local network
-
-
-
-

Those two rules would of course be in addition to the -rules listed above under "You can configure a Caching Name Server -on your firewall"

-
-
-

If you don't know what port and protocol a particular -application uses, look here.

-
-
-

Important: I don't recommend enabling telnet -to/from the internet because it uses clear text (even for login!). -If you want shell access to your firewall from the internet, -use SSH:

-
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
-
-
-
-

(LEAF Logo)     Bering users will want to -add the following two rules to be -compatible with Jacques's Shorewall configuration.

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTloc
- 		fwudp
- 		53
- 		#Allow DNS Cache towork
-
ACCEPTlocfwtcp80#Allow weblet to work
-
-
-
-


- -    Now edit your /etc/shorewall/rules file to add or -delete other connections as required.

-
-
-

Starting and Stopping Your Firewall

-
-
-

Arrow     The installation -procedure configures your system to start Shorewall at system -boot  but -beginning with Shorewall version 1.3.9 startup is disabled so that -your system won't try to start Shorewall before configuration is -complete. -Once you have completed configuration of your firewall, you can enable -Shorewall startup by removing the file /etc/shorewall/startup_disabled.
-

-

IMPORTANT: Users of the .deb package must edit -/etc/default/shorewall and set 'startup=1'.
-

-
-
-

The firewall is started using the "shorewall start" -command and stopped using "shorewall stop". When the firewall is -stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. -A running firewall may be restarted using the "shorewall restart" -command. If you want to totally remove any trace of Shorewall from your -Netfilter configuration, use "shorewall clear".

-
-
-

    The two-interface sample assumes that -you want -to enable routing to/from eth1 (the local network) when -Shorewall is stopped. If your local network isn't connected to eth1 -or if you wish to enable access to/from other hosts, change -/etc/shorewall/routestopped accordingly.

-
-
-

WARNING: If you are connected to your firewall -from the internet, do not issue a "shorewall stop" command unless you -have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. -Also, I don't recommend using "shorewall restart"; it is better -to create an alternate -configuration and test it using the "shorewall try" command.
-

-

Additional Recommended Reading

-I highly recommend that you review the Common Configuration File -Features page -- it contains helpful tips about Shorewall features -than make administering your firewall easier. -
-

Last updated 11/15/2003 - Tom Eastep

-

Copyright 2002, -2003 Thomas M. Eastep
-

- -