extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2025-06-13 13:16:45 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updates for 1.3.14 RC1

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@431 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-04 17:25:01 +00:00
parent 5b9a57d49e
commit 50b692b6be
3 changed files with 1040 additions and 1000 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
Shorewall-docs/mailing_list.htm
View File

@ -2,13 +2,17 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Shorewall Mailing Lists</title>
@ -50,8 +54,8 @@
</a><br>
<div align="left"><a href="http://www.spamassassin.org"><img
src="file:///J:/Shorewall-docs/images/ninjalogo.png" alt="" width="110"
height="42" align="right" border="0">
src="images/ninjalogo.png" alt="" width="110" height="42" align="right"
border="0">
</a> </div>
<br>
@ -62,6 +66,7 @@
</td>
</tr>
</tbody>
</table>
@ -93,15 +98,15 @@
<li>to verify that the sender's domain has an A or MX record
in DNS.</li>
<li>to ensure that the host name in the HELO/EHLO command
is a valid fully-qualified DNS name that resolves.</li>
is a valid fully-qualified DNS name that resolves.</li>
</ol>
<h2>Please post in plain text</h2>
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!!<br>
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!!<br>
<br>
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
@ -110,17 +115,17 @@ is a valid fully-qualified DNS name that resolves.</li>
deleted)</i> 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.<br>
from outgoing posts. This means that HTML-only posts will be bounced by the
list server.<br>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
</p>
<h2>Other Mail Delivery Problems</h2>
If you find that you are missing an occasional list post, your e-mail
admin may be blocking mail whose <i>Received:</i> 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 <i>Received:</i>
admin may be blocking mail whose <i>Received:</i> 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 <i>Received:</i>
headers to circumvent those policies.<br>
<h2 align="left">Mailing Lists Archive Search</h2>
@ -158,26 +163,26 @@ help but I'm not prepared to go so far as to start stripping <i>Received:</i>
value=""> <input type="submit" value="Search"> </p>
</form>
<h2 align="left"><font color="#ff0000">Please do not try to download the entire
Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't
stand the traffic. If I catch you, you will be blacklisted.<br>
<h2 align="left"><font color="#ff0000">Please do not try to download the
entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply
won't stand the traffic. If I catch you, you will be blacklisted.<br>
</font></h2>
<h2 align="left">Shorewall CA Certificate</h2>
If you want to trust X.509 certificates issued by Shoreline
Firewall (such as the one used on my web site), you may <a
href="Shorewall_CA_html.html">download and install my CA certificate</a>
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.<br>
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.<br>
<h2 align="left">Shorewall Users Mailing List</h2>
<p align="left">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.</p>
to get answers to questions and to report problems. Information of
general interest to the Shorewall user community is also posted to
this list.</p>
<p align="left"><b>Before posting a problem report to this list, please see
the <a href="http://www.shorewall.net/support.htm">problem reporting
@ -201,9 +206,9 @@ guidelines</a>.</b></p>
<p align="left">The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-users/index.html">http://lists.shorewall.net/pipermail/shorewall-users</a>.</p>
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted
at <a href="http://sourceforge.net">Sourceforge</a>. The archives from that
list may be found at <a
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted at
<a href="http://sourceforge.net">Sourceforge</a>. The archives from that list
may be found at <a
href="http://www.geocrawler.com/lists/3/Sourceforge/9327/0/">www.geocrawler.com/lists/3/Sourceforge/9327/0/</a>.</p>
<h2 align="left">Shorewall Announce Mailing List</h2>
@ -290,17 +295,8 @@ list may be found at <a
<p align="left"><font size="2">Last updated 2/3/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
</body>
</html>

206
Shorewall-docs/seattlefirewall_index.htm
View File

@ -37,14 +37,15 @@
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables made
easy"</i></font></font></h1>
1.3 - <font size="4">"<i>iptables
made easy"</i></font></font></h1>
@ -129,18 +130,18 @@ Public License</a> as published by the Free Software Foundation.<br>
<br>
This program is distributed in the hope
that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY
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.<br>
<br>
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,
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</p>
@ -163,6 +164,7 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
@ -224,11 +226,12 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
<p>Includes the Beta 2 content plus support for OpenVPN tunnels.</p>
<p> The beta may be downloaded from:<br>
<p> The release candidate may be downloaded from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2 </b><b><img border="0"
@ -258,30 +261,30 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
When set to Yes, Shorewall ping handling is as it has always been (see http://www.shorewall.net/ping.html).<br>
<br>
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.<br>
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.<br>
<br>
</li>
<li>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:<br>
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:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>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:<br>
the /etc/shorewall/masq file, Shorewall previously masqueraded traffic
from only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
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.<br>
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.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <br>
@ -305,7 +308,7 @@ to occur on subnetworks that you don't wish to masquerade.<br>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#<br></pre>
   In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
required.<br>
 <br>
Example 3 -- What if your current configuration is like this?<br>
@ -353,13 +356,13 @@ big thanks to Alex for making this happen.<br>
<ol>
<li>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.<br>
/etc/shorewall/rules file. DNAT- is intended for advanced users who wish
to minimize the number of rules that connection requests must traverse.<br>
<br>
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.<br>
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.<br>
<br>
   Here are three rules from my previous rules file:<br>
<br>
@ -372,7 +375,7 @@ to minimize the number of rules that connection requests must traverse.<br>
         ACCEPT net  dmz:206.124.146.177 tcp smtp<br>
<br>
   By writing the rules this way, I end up with only one copy of
the ACCEPT rule.<br>
the ACCEPT rule.<br>
<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179<br>
@ -384,17 +387,18 @@ the ACCEPT rule.<br>
<br>
</li>
<li>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.<br>
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.<br>
<br>
</li>
<li>A new SHARED_DIR variable has been added that allows distribution
packagers to easily move the shared directory (default /usr/lib/shorewall).
<li>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.<br>
</li>
@ -417,10 +421,12 @@ the ACCEPT rule.<br>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
@ -429,6 +435,7 @@ the ACCEPT rule.<br>
</p>
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b><b>
</b></p>
@ -438,39 +445,39 @@ the ACCEPT rule.<br>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping
rules (tcrules and tcstart).</li>
<li>"shorewall refresh" now reloads the traffic
shaping rules (tcrules and tcstart).</li>
<li>"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.</li>
<li>"shorewall [re]start" has been speeded up by more
than 40% with my configuration. Your milage may vary.</li>
the end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by
more than 40% with my configuration. Your milage may vary.</li>
<li>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"</li>
<li>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 <a
output from this command is also added as a separate page in "shorewall
monitor"</li>
<li>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 <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>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 <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for marking
input packets based on their destination even when you are using
Masquerading or SNAT.</li>
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 <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
marking input packets based on their destination even when you are
using Masquerading or SNAT.</li>
<li>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.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable
to <a href="Documentation.htm#Conf">shorewall.conf</a>. 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.<br>
to <a href="Documentation.htm#Conf">shorewall.conf</a>. 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.<br>
</li>
@ -479,9 +486,9 @@ of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b><br>
</p>
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.<br>
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.<br>
<p> You may download the Beta from:<br>
@ -498,7 +505,7 @@ of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b>
</b></p>
The first public Beta version of Shorewall 1.3.12 is
now available (Beta 1 was made available to a limited audience).
now available (Beta 1 was made available to a limited audience).
<br>
<br>
Features include:<br>
@ -510,30 +517,30 @@ now available (Beta 1 was made available to a limited audience).
<li>"shorewall refresh" now reloads the traffic
shaping rules (tcrules and tcstart).</li>
<li>"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.</li>
<li>"shorewall [re]start" has been speeded up
by more than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has
been added which shows the current packet classification filters.
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.</li>
<li>"shorewall [re]start" has been speeded
up by more than 40% with my configuration. Your milage may vary.</li>
<li>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"</li>
<li>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 <a
"shorewall monitor"</li>
<li>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 <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>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
<li>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.</li>
<li>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.</li>
their destination even when you are using Masquerading or SNAT.</li>
<li>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.</li>
@ -569,7 +576,7 @@ their destination even when you are using Masquerading or SNAT.</li>
<p>Two months and 3 days after I pre-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.</p>
now in a position to support Shorewall users who run Mandrake 9.0.</p>
@ -590,12 +597,14 @@ now in a position to support Shorewall users who run Mandrake 9.0.</p>
<p>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.</p>
<p><b>11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format</b><b>
</b></p>
@ -629,25 +638,26 @@ now in a position to support Shorewall users who run Mandrake 9.0.</p>
<ul>
<li>A 'tcpflags' option has been added
to entries in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
<li>A 'tcpflags' option has been
added to entries in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
This option causes Shorewall to make a set of sanity check on TCP
packet header flags.</li>
packet header flags.</li>
<li>It is now allowed to use 'all'
in the SOURCE or DEST column in a <a
in the SOURCE or DEST column in a <a
href="Documentation.htm#Rules">rule</a>. When used, 'all' must appear
by itself (in may not be qualified) and it does not enable intra-zone
traffic. For example, the rule <br>
<br>
    ACCEPT loc all tcp 80<br>
<br>
does not enable http traffic from 'loc' to
'loc'.</li>
<li>Shorewall's use of the 'echo' command
is now compatible with bash clones such as ash and dash.</li>
does not enable http traffic from 'loc'
to 'loc'.</li>
<li>Shorewall's use of the 'echo'
command is now compatible with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate
a startup error. fw-&gt;fw rules generate a warning and are
ignored</li>
a startup error. fw-&gt;fw rules generate a warning and are
ignored</li>
@ -670,6 +680,7 @@ ignored</li>
<h2><a name="Donations"></a>Donations</h2>
</td>
@ -711,11 +722,12 @@ ignored</li>
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
 
</a></p>
  </a></p>
@ -752,5 +764,7 @@ Foundation.</font></a> Thanks!</font></p>
</p>
<br>
<br>
<br>
<br>
</body>
</html>

222
Shorewall-docs/sourceforge_index.htm
View File

@ -47,7 +47,8 @@
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables
made easy"</i></font></font><a href="http://www.sf.net"> </a></h1>
made easy"</i></font></font><a href="http://www.sf.net">
</a></h1>
@ -94,6 +95,7 @@
<h2 align="left">What is it?</h2>
@ -130,7 +132,7 @@ the GNU General Public License</a> as published by the Free Software
<br>
This program is distributed in
the hope that it will be useful, but WITHOUT
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
@ -141,8 +143,8 @@ the hope that it will be useful, but WITHOUT
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</p>
Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA</p>
@ -175,8 +177,8 @@ the hope that it will be useful, but WITHOUT
that features Shorewall-1.3.10 and Kernel-2.4.18.
You can find their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and Eric
on the recent release of Bering 1.0 Final!!! <br>
<b>Congratulations to Jacques and
Eric on the recent release of Bering 1.0 Final!!! <br>
</b>
@ -195,12 +197,26 @@ the hope that it will be useful, but WITHOUT
<p><b>2/4/2003 - Shorewall 1.3.14-RC1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>Includes the Beta 2 content plus support for OpenVPN tunnels.<br>
</p>
<p> The release candidate may be downloaded from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><a
href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top"><br>
ftp://ftp.shorewall.net/pub/shorewall/Beta</a></blockquote>
<p></p>
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2 </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>Includes the Beta 1 content plus restores VLAN device names of the
form $dev.$vid (e.g., eth0.1)</p>
form $dev.$vid (e.g., eth0.1)</p>
<p> The beta may be downloaded from:<br>
</p>
@ -219,33 +235,34 @@ form $dev.$vid (e.g., eth0.1)</p>
<ol>
<li>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).<br>
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
<br>
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.<br>
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.<br>
<br>
</li>
<li>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:<br>
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:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>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:<br>
<li>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:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
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.<br>
SUBNET column, shorewall will use the firewall's routing table to construct
the masquerading/SNAT rules.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <br>
@ -257,12 +274,12 @@ the masquerading/SNAT rules.<br>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
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.<br>
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.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
@ -271,7 +288,7 @@ connected to an interface that is specified in the SUBNET column of an /etc/sho
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#<br></pre>
   In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
required.<br>
 <br>
Example 3 -- What if your current configuration is like this?<br>
 <br>
@ -295,6 +312,7 @@ required.<br>
<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format</b><b> </b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
documenation. the PDF may be downloaded from</p>
    <a
@ -321,13 +339,14 @@ for making this happen.<br>
<ol>
<li>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.<br>
/etc/shorewall/rules file. DNAT- is intended for advanced users who wish
to minimize the number of rules that connection requests must traverse.<br>
<br>
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.<br>
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.<br>
<br>
   Here are three rules from my previous rules file:<br>
<br>
@ -339,8 +358,8 @@ to minimize the number of rules that connection requests must traverse.<br>
<br>
         ACCEPT net  dmz:206.124.146.177 tcp smtp<br>
<br>
   By writing the rules this way, I end up with only one copy of the
ACCEPT rule.<br>
   By writing the rules this way, I end up with only one copy of
the ACCEPT rule.<br>
<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179<br>
@ -352,17 +371,17 @@ to minimize the number of rules that connection requests must traverse.<br>
<br>
</li>
<li>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
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
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.<br>
<br>
</li>
<li>A new SHARED_DIR variable has been added that allows distribution
packagers to easily move the shared directory (default /usr/lib/shorewall).
<li>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.</li>
@ -408,34 +427,35 @@ classifier based on packet marking defined in /etc/shorewall/tcrules.<br>
<li>"shorewall refresh" now reloads the traffic shaping
rules (tcrules and tcstart).</li>
<li>"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.</li>
<li>"shorewall [re]start" has been speeded up by more
than 40% with my configuration. Your milage may vary.</li>
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.</li>
<li>"shorewall [re]start" has been speeded up by
more than 40% with my configuration. Your milage may vary.</li>
<li>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"</li>
<li>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 <a
added which shows the current packet classification filters. The
output from this command is also added as a separate page in "shorewall
monitor"</li>
<li>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 <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to
a separate log file</a>.</li>
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>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 <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
marking input packets based on their destination even when you are
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 <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
marking input packets based on their destination even when you are
using Masquerading or SNAT.</li>
<li>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.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable to
<a href="Documentation.htm#Conf">shorewall.conf</a>. This variable
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.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable
to <a href="Documentation.htm#Conf">shorewall.conf</a>. 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
of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
were always logged at the 'info' level.</li>
@ -444,9 +464,9 @@ of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b><br>
</p>
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.<br>
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.<br>
<p> You may download the Beta from:<br>
@ -462,8 +482,8 @@ of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b>
</b></p>
The first public Beta version of Shorewall 1.3.12 is now
available (Beta 1 was made available only to a limited audience).
The first public Beta version of Shorewall 1.3.12 is
now available (Beta 1 was made available only to a limited audience).
<br>
<br>
Features include:<br>
@ -475,26 +495,26 @@ of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
<li>"shorewall refresh" now reloads the traffic
shaping rules (tcrules and tcstart).</li>
<li>"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.</li>
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.</li>
<li>"shorewall [re]start" has been speeded up
by more than 40% with my configuration. Your milage may vary.</li>
by more than 40% with my configuration. Your milage may vary.</li>
<li>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"</li>
<li>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 <a
been added which shows the current packet classification filters.
The output from this command is also added as a separate page in
"shorewall monitor"</li>
<li>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 <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a href="shorewall_logging.html">to
a separate log file</a>.</li>
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>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.</li>
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.</li>
<li>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
@ -534,7 +554,7 @@ in shorewall.conf. This allows for marking input packets based on their
<p>Two months and 3 days after I pre-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.</p>
now in a position to support Shorewall users who run Mandrake 9.0.</p>
@ -549,17 +569,20 @@ now in a position to support Shorewall users who run Mandrake 9.0.</p>
<p><b>12/3/2002 - Shorewall 1.3.11a</b><b>
</b></p>
<p>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.</p>
<p><b>11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format</b><b>
</b></p>
@ -593,25 +616,26 @@ now in a position to support Shorewall users who run Mandrake 9.0.</p>
<ul>
<li>A 'tcpflags' option has been added
to entries in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
<li>A 'tcpflags' option has been
added to entries in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
This option causes Shorewall to make a set of sanity check on TCP
packet header flags.</li>
packet header flags.</li>
<li>It is now allowed to use 'all'
in the SOURCE or DEST column in a <a
in the SOURCE or DEST column in a <a
href="Documentation.htm#Rules">rule</a>. When used, 'all' must appear
by itself (in may not be qualified) and it does not enable intra-zone
traffic. For example, the rule <br>
<br>
    ACCEPT loc all tcp 80<br>
<br>
does not enable http traffic from 'loc' to
'loc'.</li>
<li>Shorewall's use of the 'echo' command
is now compatible with bash clones such as ash and dash.</li>
does not enable http traffic from 'loc'
to 'loc'.</li>
<li>Shorewall's use of the 'echo'
command is now compatible with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate
a startup error. fw-&gt;fw rules generate a warning and are
ignored</li>
a startup error. fw-&gt;fw rules generate a warning and are
ignored</li>
@ -704,6 +728,7 @@ ignored</li>
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c"
@ -727,6 +752,7 @@ ignored</li>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
@ -760,6 +786,7 @@ ignored</li>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
to <a
@ -774,16 +801,19 @@ Children's Foundation.</font></a> Thanks!</font></p>
</tbody>
</table>
<p><font size="2">Updated 1/28/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>