extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2025-05-31 23:15:48 +02:00
Code Issues Packages Projects Releases Wiki Activity

Shorewall-1.4.1

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@519 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-03-23 18:47:54 +00:00
parent 8377f70bc7
commit c68ecd14e7
94 changed files with 21164 additions and 20883 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
STABLE/changelog.txt
View File

@ -1,66 +1,9 @@
Changes since 1.3.14
Changes since 1.4.0
1. All versions changed to 1.4.
1. Implement NONE policy.
2. Rework of error message generation to make the 'firewall' script
smaller.
2. Never create rules for <iface>:<subnet> to itself.
3. Deimplemented MERGE_HOSTS=No.
3. Always allow intrazone traffic.
4. Generate error for <dev>:<integer> name in interfaces file.
5. Deimplement old ping handling.
6. Deimplement 'routestopped' interface/hosts option.
7. Strip comments from potentially large files while the firewall is
still up and running during 'restart'.
8. Disallow the old port forwarding/redirection syntax.
9. Reorganize shorewall.conf.
10. Added support for LOG target.
11. Move firewall and version (one more time....)
12. Add late DNS reply rule to the common chain.
12. Corrected rule number calculation problem in 'shorewall add' command
processing.
13. Update Documentation for 1.4
14. Remove icmp.def file.
15. Added CONTINUE rule target.
16. Added Andrew Zhoglo's fix for logunclean.
17. Removed 'multi' option.
18. Support 802.11b devices with maclist.
19. Don't detect loopback simply by name.
20. Removed trailing white space from all files.
21. Improved parsing of comma-separated lists.
22. Add ECN Removal support
23. Add TCP ports 445 and 139 to the common silent list.
24. Remove 'check' command support.
25. Restore 'check' command support.
26. Remove unused function find_interface_broadcasts()
27. Remove stale comments in the params file.
28. Silently drop INVALID state packets
29. Ignore the 'default' route when detecting masq'd networks.
30. REALLY process the params file first now (honest).
4. Correct building of ECN interface list under ash.

1002
STABLE/documentation/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

656
STABLE/documentation/FAQ.htm
View File

File diff suppressed because it is too large Load Diff

109
STABLE/documentation/Install.htm
View File

@ -50,17 +50,30 @@
<ul>
<li>Install the RPM (rpm -ivh &lt;shorewall rpm&gt;).<br>
<br>
<b>Note: </b>Some SuSE users have encountered a problem whereby rpm
reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel is
installed. If this happens, simply use the --nodeps option to rpm (rpm
-ivh --nodeps &lt;shorewall rpm&gt;).</li>
<li>Edit the <a href="#Config_Files"> configuration files</a> to match
your configuration. <font color="#ff0000"><b>WARNING - YOU CAN <u>NOT</u>
<b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -ivh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent
on the iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the installation of Shorewall to fail with the
diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -ivh --nodeps
&lt;shorewall rpm&gt;).<br>
<br>
</li>
<li>Edit the <a href="#Config_Files"> configuration files</a> to
match your configuration. <font color="#ff0000"><b>WARNING - YOU CAN <u>NOT</u>
SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION
IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU ISSUE A "start" COMMAND
AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL NO LONGER ACCEPT ANY
NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall clear" COMMAND TO
RESTORE NETWORK CONNECTIVITY.</b></font></li>
NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall clear" COMMAND TO RESTORE
NETWORK CONNECTIVITY.</b></font></li>
<li>Start the firewall by typing "shorewall start"</li>
</ul>
@ -79,15 +92,15 @@ RESTORE NETWORK CONNECTIVITY.</b></font></li>
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using <a href="http://www.suse.com">SuSe</a> then type
"./install.sh /etc/init.d"</li>
<li>If you are using <a href="http://www.suse.com">SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your distribution
installs init scripts and type "./install.sh &lt;init script
directory&gt;</li>
<li>Edit the <a href="#Config_Files"> configuration files</a> to match
your configuration.</li>
<li>Edit the <a href="#Config_Files"> configuration files</a> to
match your configuration.</li>
<li>Start the firewall by typing "shorewall start"</li>
<li>If the install script was unable to configure Shorewall to be
started automatically at boot, see <a
@ -96,49 +109,58 @@ started automatically at boot, see <a
</ul>
<p><a name="LRP"></a>To install my version of Shorewall on a fresh Bering
disk, simply replace the "shorwall.lrp" file on the image with the file
that you downloaded. See the <a href="two-interface.htm">two-interface QuickStart
disk, simply replace the "shorwall.lrp" file on the image with the file that
you downloaded. See the <a href="two-interface.htm">two-interface QuickStart
Guide</a> for information about further steps required.</p>
<p><a name="Upgrade_RPM"></a>If you already have the Shorewall RPM installed
and are upgrading to a new version:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version or
and you have entries in the /etc/shorewall/hosts file then please check
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version
or and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file. Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues </a>for
details.</p>
1.2 rule forms that are no longer supported under 1.4 (you must use the new
1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues </a>for details.</p>
<ul>
<li>Upgrade the RPM (rpm -Uvh &lt;shorewall rpm file&gt;) <b>Note:
</b>If you are installing version 1.2.0 and have one of the 1.2.0
Beta RPMs installed, you must use the "--oldpackage" option to rpm (e.g.,
"rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
Beta RPMs installed, you must use the "--oldpackage" option to rpm (e.g.,
"rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
<p> <b>Note: </b>Some SuSE users have encountered a problem whereby
<p> <b>Note1: </b>Some SuSE users have encountered a problem whereby
rpm reports a conflict with kernel &lt;= 2.2 even though a 2.4 kernel
is installed. If this happens, simply use the --nodeps option to rpm
(rpm -Uvh --nodeps &lt;shorewall rpm&gt;).<br>
  </p>
is installed. If this happens, simply use the --nodeps option to rpm (rpm
-Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
<b>Note2: </b>Beginning with Shorewall 1.4.0, Shorewall is dependent on
the iproute package. Unfortunately, some distributions call this package iproute2
which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -Uvh
--nodeps &lt;shorewall rpm&gt;). </p>
</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct as necessary.</li>
and the new Shorewall version (type "shorewall check") and correct as
necessary.</li>
<li>Restart the firewall (shorewall restart).</li>
</ul>
<p><a name="Upgrade_Tarball"></a>If you already have Shorewall installed
and are upgrading to a new version using the tarball:</p>
<p><a name="Upgrade_Tarball"></a>If you already have Shorewall installed and
are upgrading to a new version using the tarball:</p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version
and you have entries in the /etc/shorewall/hosts file then please check
your /etc/shorewall/interfaces file to be sure that it contains an entry
for each interface mentioned in the hosts file.  Also, there are certain
1.2 rule forms that are no longer supported under 1.4 (you must use the
new 1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues</a>
for details. </p>
<p>If you are upgrading from a 1.2 version of Shorewall to a 1.4 version and
you have entries in the /etc/shorewall/hosts file then please check your
/etc/shorewall/interfaces file to be sure that it contains an entry for
each interface mentioned in the hosts file.  Also, there are certain 1.2
rule forms that are no longer supported under 1.4 (you must use the new
1.4 syntax). See <a href="errata.htm#Upgrade">the upgrade issues</a> for
details. </p>
<ul>
<li>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</li>
@ -151,35 +173,35 @@ for details. </p>
href="http://www.corel.com">Corel</a>, <a
href="http://www.slackware.com/">Slackware</a> or <a
href="http://www.debian.org">Debian</a> then type "./install.sh"</li>
<li>If you are using<a href="http://www.suse.com"> SuSe</a> then type
"./install.sh /etc/init.d"</li>
<li>If you are using<a href="http://www.suse.com"> SuSe</a> then
type "./install.sh /etc/init.d"</li>
<li>If your distribution has directory /etc/rc.d/init.d
or /etc/init.d then type "./install.sh"</li>
<li>For other distributions, determine where your distribution
installs init scripts and type "./install.sh &lt;init script
directory&gt;</li>
<li>See if there are any incompatibilities between your configuration
and the new Shorewall version (type "shorewall check") and correct as necessary.</li>
and the new Shorewall version (type "shorewall check") and correct as
necessary.</li>
<li>Restart the firewall by typing "shorewall restart"</li>
</ul>
<a name="LRP_Upgrade"></a>If you already have a running Bering
installation and wish to upgrade to a later version of Shorewall:<br>
installation and wish to upgrade to a later version of Shorewall:<br>
<br>
    <b>UNDER CONSTRUCTION...</b><br>
<h3><a name="Config_Files"></a>Configuring Shorewall</h3>
<p>You will need to edit some or all of the configuration files to match
your setup. In most cases, the <a
href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guides</a>
contain all of the information you need.</p>
your setup. In most cases, the <a href="shorewall_quickstart_guide.htm">Shorewall
QuickStart Guides</a> contain all of the information you need.</p>
<ul>
</ul>
<p><font size="2">Updated 2/27/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="2">Updated 3/18/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
@ -189,5 +211,6 @@ contain all of the information you need.</p>
<br>
<br>
<br>
<br>
</body>
</html>

1033
STABLE/documentation/News.htm
View File

File diff suppressed because it is too large Load Diff

81
STABLE/documentation/ProxyARP.htm
View File

@ -29,8 +29,8 @@
<p>Proxy ARP allows you to insert a firewall in front of a set of servers
without changing their IP addresses and without having to re-subnet.
Before you try to use this technique, I strongly recommend that you read the
<a href="shorewall_setup_guide.htm">Shorewall Setup Guide.</a></p>
Before you try to use this technique, I strongly recommend that you read
the <a href="shorewall_setup_guide.htm">Shorewall Setup Guide.</a></p>
<p>The following figure represents a Proxy ARP environment.</p>
@ -46,7 +46,7 @@ Before you try to use this technique, I strongly recommend that you read the
130.252.100.18 and 130.252.100.19 appear to be on the upper (130.252.100.*)
subnet.  Assuming that the upper firewall interface is eth0 and the
lower interface is eth1, this is accomplished using the following entries
in /etc/shorewall/proxyarp:</p>
in /etc/shorewall/proxyarp:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
@ -83,62 +83,71 @@ or /etc/shorewall/nat.</p>
<p>The lower systems (130.252.100.18 and 130.252.100.19) should have their
subnet mask and default gateway configured exactly the same way that
the Firewall system's eth0 is configured.</p>
the Firewall system's eth0 is configured. In other words, they should
be configured just like they would be if they were parallel to the firewall
rather than behind it.<br>
</p>
<p><font color="#ff0000"><b>NOTE: Do not add the Proxy ARP'ed address(es)
(130.252.100.18 and 130.252.100.19 in the above example)  to the external
interface (eth0 in this example) of the firewall.</b></font><br>
</p>
<div align="left"> </div>
<div align="left">
<p align="left">A word of warning is in order here. ISPs typically configure
their routers with a long ARP cache timeout. If you move a system from
parallel to your firewall to behind your firewall with Proxy ARP, it will
probably be HOURS before that system can communicate with the internet.
There are a couple of things that you can try:<br>
There are a couple of things that you can try:<br>
</p>
<ol>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP Illustrated,
Vol 1</i> reveals that a <br>
Vol 1</i> reveals that a <br>
<br>
"gratuitous" ARP packet should cause the ISP's router to refresh their ARP
cache (section 4.7). A gratuitous ARP is simply a host requesting the MAC
address for its own IP; in addition to ensuring that the IP address isn't
a duplicate...<br>
"gratuitous" ARP packet should cause the ISP's router to refresh their
ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the
MAC address for its own IP; in addition to ensuring that the IP address isn't
a duplicate...<br>
<br>
"if the host sending the gratuitous ARP has just changed its hardware address...,
this packet causes any other host...that has an entry in its cache for the
old hardware address to update its ARP cache entry accordingly."<br>
"if the host sending the gratuitous ARP has just changed its hardware
address..., this packet causes any other host...that has an entry in its
cache for the old hardware address to update its ARP cache entry accordingly."<br>
<br>
Which is, of course, exactly what you want to do when you switch a host
from being exposed to the Internet to behind Shorewall using proxy ARP (or
static NAT for that matter). Happily enough, recent versions of Redhat's
from being exposed to the Internet to behind Shorewall using proxy ARP (or
static NAT for that matter). Happily enough, recent versions of Redhat's
iputils package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I <i>&lt;net if&gt; &lt;newly proxied
IP&gt;</i></b></font><br>
    <font color="#009900"><b>arping -U -I <i>&lt;net if&gt; &lt;newly
proxied IP&gt;</i></b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly to gratuitous
ARPs, but googling for "arping -U" seems to support the idea that it works
most of the time.<br>
ARPs, but googling for "arping -U" seems to support the idea that it works
most of the time.<br>
<br>
To use arping with Proxy ARP in the above example, you would have to:<br>
To use arping with Proxy ARP in the above example, you would have to:<br>
<br>
<font color="#009900"><b>    shorewall clear<br>
</b></font>    <font color="#009900"><b>ip addr add 130.252.100.18 dev
eth0<br>
    ip addr add 130.252.100.19 dev eth0</b></font><br>
</b></font>    <font color="#009900"><b>ip addr add 130.252.100.18
dev eth0<br>
    ip addr add 130.252.100.19 dev eth0</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 130.252.100.18</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 130.252.100.19</b></font><br>
    <b><font color="#009900">ip addr del 130.252.100.18 dev eth0<br>
    ip addr del 130.252.100.19 dev eth0<br>
    shorewall start</font></b><br>
    <font color="#009900"><b>arping -U -I eth0 130.252.100.19</b></font><br>
    <b><font color="#009900">ip addr del 130.252.100.18 dev eth0<br>
    ip addr del 130.252.100.19 dev eth0<br>
    shorewall start</font></b><br>
<br>
</li>
<li>You can call your ISP and ask them to purge the stale ARP cache
entry but many either can't or won't purge individual entries.</li>
entry but many either can't or won't purge individual entries.</li>
</ol>
You can determine if your ISP's gateway ARP cache is stale using ping
and tcpdump. Suppose that we suspect that the gateway router has a stale
ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:</div>
and tcpdump. Suppose that we suspect that the gateway router has a stale
ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:</div>
<div align="left">
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
@ -146,7 +155,7 @@ ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:<
<div align="left">
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we
will assume is 130.252.100.254):</p>
will assume is 130.252.100.254):</p>
</div>
<div align="left">
@ -164,16 +173,18 @@ will assume is 130.252.100.254):</p>
<div align="left">
<p align="left">Notice that the source MAC address in the echo request is
different from the destination MAC address in the echo reply!! In this
case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
was the MAC address of the system on the lower left. In other words, the
gateway's ARP cache still associates 130.252.100.19 with the NIC in that
system rather than with the firewall's eth0.</p>
gateway's ARP cache still associates 130.252.100.19 with the NIC in that
system rather than with the firewall's eth0.</p>
</div>
<p><font size="2">Last updated 1/26/2003 - </font><font size="2"> <a
<p><font size="2">Last updated 3/21/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<br>
<br>
<br>
</body>
</html>

168
STABLE/documentation/Shorewall_and_Aliased_Interfaces.html
View File

@ -30,39 +30,41 @@
<h2>Background</h2>
The traditional net-tools contain a program called <i>ifconfig</i> which
is used to configure network devices. ifconfig introduced the concept of
<i>aliased </i>or <i>virtial </i>interfaces. These virtual interfaces have
names of the form <i>interface</i>:<i>integer </i>(e.g., eth0:0) and ifconfig
treats them more or less like real interfaces.<br>
<i>aliased </i>or <i>virtial </i>interfaces. These virtual interfaces have
names of the form <i>interface</i>:<i>integer </i>(e.g., eth0:0) and ifconfig
treats them more or less like real interfaces.<br>
<br>
Example:<br>
<pre>[root@gateway root]# ifconfig eth0:0<br>eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55<br> inet addr:206.124.146.178 Bcast:206.124.146.255 Mask:255.255.255.0<br> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br> Interrupt:11 Base address:0x2000<br>[root@gateway root]# <br></pre>
The ifconfig utility is being gradually phased out in favor of the <i>ip</i>
utility which is part of the <i>iproute </i>package. The ip utility does
not use the concept of aliases or virtual interfaces but rather treats additional
addresses on an interface as addresses. The ip utility does provide for interaction
with ifconfig in that it allows addresses to be <i>labeled.</i> <br>
not use the concept of aliases or virtual interfaces but rather treats additional
addresses on an interface as objects. The ip utility does provide for interaction
with ifconfig in that it allows addresses to be <i>labeled </i>and labels
may take the form of ipconfig virtual interfaces.<br>
<br>
Example:<br>
<br>
<pre>[root@gateway root]# ip addr show dev eth0<br>2: eth0: &lt;BROADCAST,MULTICAST,UP&gt; mtu 1500 qdisc htb qlen 100<br> link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff<br> inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0<br> inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0<br>[root@gateway root]# <br></pre>
Note that one <u>cannot</u> type "ip addr show dev eth0:0"<br>
Note that one <u>cannot</u> type "ip addr show dev eth0:0" because "eth0:0"
is a label for a particular address rather than a device name.<br>
<pre>[root@gateway root]# ip addr show dev eth0:0<br>Device "eth0:0" does not exist.<br>[root@gateway root]#<br></pre>
The iptables program doesn't support virtual interfaces in either it's
"-i" or "-o" command options; as a consequence, Shorewall does not allow
them to be used in the /etc/shorewall/interfaces file.<br>
"-i" or "-o" command options; as a consequence, Shorewall does not allow
them to be used in the /etc/shorewall/interfaces file.<br>
<br>
<h2>So how do I handle more than one address on an interface?</h2>
Depends on what you are trying to do with the interfaces. In the sub-sections
that follow, we'll take a look at common scenarios.<br>
The answer depends on what you are trying to do with the interfaces.
In the sub-sections that follow, we'll take a look at common scenarios.<br>
<h3>Separate Rules</h3>
If you need to make a rule for traffic to/from the firewall itself only
apply to a particular IP address, simply qualify the $FW zone with the IP
address.<br>
If you need to make a rule for traffic to/from the firewall itself that
only applies to a particular IP address, simply qualify the $FW zone with
the IP address.<br>
<br>
Example (allow SSH from net to eth0:0 above):<br>
<br>
@ -110,8 +112,9 @@ address.<br>
<h3>DNAT</h3>
Suppose that I had set up eth0:0 as above and I wanted to port forward
from that virtual interface to a web server running in my local zone at 192.168.1.3.
That is accomplised by a single rule in the /etc/shorewall/rules file:<br>
from that virtual interface to a web server running in my local zone at
192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules
file:<br>
<br>
<blockquote>
@ -157,7 +160,7 @@ from that virtual interface to a web server running in my local zone at 192.168
<h3>SNAT</h3>
If you wanted to use eth0:0 as the IP address for outbound connections
from your local zone (eth1), then in /etc/shorewall/masq:<br>
from your local zone (eth1), then in /etc/shorewall/masq:<br>
<br>
<blockquote>
@ -185,11 +188,11 @@ from your local zone (eth1), then in /etc/shorewall/masq:<br>
<br>
</blockquote>
Shorewall can create the alias (additional address) for you if you set
ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
@ -254,11 +257,11 @@ column as follows:<br>
<br>
</blockquote>
Shorewall can create the alias (additional address) for you if you set
ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_IP_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_IP_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
<br>
<blockquote>
@ -294,9 +297,10 @@ column as follows:<br>
<br>
</blockquote>
In either case, to create rules that pertain only to this NAT pair, you
simply qualify the local zone with the internal IP address.<br>
simply qualify the local zone with the internal IP address.<br>
<br>
Example: You want to allow SSH from the net to 206.124.146.178 a.k.a. 192.168.1.3.<br>
Example: You want to allow SSH from the net to 206.124.146.178 a.k.a.
192.168.1.3.<br>
<br>
<blockquote>
@ -343,18 +347,86 @@ simply qualify the local zone with the internal IP address.<br>
<h3>MULTIPLE SUBNETS</h3>
Sometimes multiple IP addresses are used because there are multiple subnetworks
configured on a LAN segment. This technique does not provide for any security
between the subnetworks if the users of the systems have administrative privileges
because in that case, the users can simply manipulate their system's routing
table to bypass your firewall/router. Nevertheless, there are cases where
you simply want to consider the LAN segment itself as a zone and allow your
firewall/router to route between the two subnetworks.<br>
between the subnetworks if the users of the systems have administrative
privileges because in that case, the users can simply manipulate their system's
routing table to bypass your firewall/router. Nevertheless, there are cases
where you simply want to consider the LAN segment itself as a zone and allow
your firewall/router to route between the two subnetworks.<br>
<br>
Example 1: &nbsp;Local interface eth1 interfaces to 192.168.1.0/24 and
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and eth1:0
is 192.168.20.254. You want to simply route all requests between the two
subnetworks.<br>
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and eth1:0
is 192.168.20.254. You want to simply route all requests between the two
subnetworks.<br>
<h4>If you are running Shorewall 1.4.1 or Later</h4>
In /etc/shorewall/interfaces:<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ZONE<br>
</b></td>
<td valign="top"><b>INTERFACE<br>
</b></td>
<td valign="top"><b>BROADCAST<br>
</b></td>
<td valign="top"><b>OPTIONS<br>
</b></td>
</tr>
<tr>
<td valign="top">-<br>
</td>
<td valign="top">eth1<br>
</td>
<td valign="top">192.168.1.255,192.168.20.255<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
In /etc/shorewall/interfaces:<br>
</blockquote>
In /etc/shorewall/hosts:<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ZONE<br>
</b></td>
<td valign="top"><b>HOSTS<br>
</b></td>
<td valign="top"><b>OPTIONS<br>
</b></td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">eth0:192.168.1.0/24<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">eth0:192.168.20.0/24<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall
1.4.1 and later releases default to allowing intra-zone traffic.<br>
<h4>If you are running Shorewall 1.4.0 or earlier<br>
</h4>
In /etc/shorewall/interfaces:<br>
<br>
<blockquote>
@ -385,8 +457,8 @@ subnetworks.<br>
</table>
<br>
</blockquote>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must specify
the <b>multi</b> option.<br>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must
specify the <b>multi</b> option.<br>
<br>
In /etc/shorewall/policy:<br>
<br>
@ -425,9 +497,8 @@ subnetworks.<br>
</blockquote>
Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and 192.168.20.0/24.
The primary IP address of eth1 is 192.168.1.254 and eth1:0 is 192.168.20.254.
You want to make these subnetworks into separate zones and control the
access between them (the users of the systems do not have administrative
privileges).<br>
You want to make these subnetworks into separate zones and control the access
between them (the users of the systems do not have administrative privileges).<br>
<br>
In /etc/shorewall/zones:<br>
<br>
@ -495,8 +566,8 @@ privileges).<br>
</table>
<br>
</blockquote>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must specify
the <b>multi</b> option.<br>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must
specify the <b>multi</b> option.<br>
<br>
In /etc/shorewall/hosts:<br>
@ -532,11 +603,11 @@ privileges).<br>
</table>
<br>
</blockquote>
In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic that
you want to permit.<br>
In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic
that you want to permit.<br>
<br>
<p align="left"><font size="2">Last Updated 3/5/2003 A - <a
<p align="left"><font size="2">Last Updated 3/22/2003 A - <a
href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
@ -545,5 +616,6 @@ privileges).<br>
</p>
<br>
<br>
<br>
</body>
</html>

57
STABLE/documentation/errata.htm
View File

@ -42,6 +42,7 @@
<ol>
<li>
<p align="left"> <b><u>I</u>f you use a Windows system to download
a corrected script, be sure to run the script through <u>
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
@ -50,16 +51,18 @@
</li>
<li>
<p align="left"> <b>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
<p align="left"> <b>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.</b></p>
</li>
<li>
<p align="left"> <b>When the instructions say to install a corrected
firewall script in /usr/share/shorewall/firewall, you may
rename the existing file before copying in the new file.</b></p>
rename the existing file before copying in the new file.</b></p>
</li>
<li>
@ -86,14 +89,14 @@ rename the existing file before copying in the new file.</b></p>
color="#660066"><a href="#iptables"> Problem with iptables version 1.2.3
on RH7.2</a></font></b></li>
<li> <b><a
href="#Debug">Problems with kernels &gt;= 2.4.18 and
RedHat iptables</a></b></li>
href="#Debug">Problems with kernels &gt;= 2.4.18 and RedHat
iptables</a></b></li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables
version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
and NAT</a></b><br>
and NAT</a></b><br>
</li>
</ul>
@ -103,7 +106,16 @@ and NAT</a></b><br>
<h3></h3>
None.
<h3>1.4.0</h3>
<ul>
<li>When running under certain shells Shorewall will attempt to create
ECN rules even when /etc/shorewall/ecn is empty. You may either just remove
/etc/shorewall/ecn or you can install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.4.0/firewall">this
correct script</a> in /usr/share/shorewall/firewall as described above.<br>
</li>
</ul>
<hr width="100%" size="2">
<h2 align="left"><a name="Upgrade"></a>Upgrade Issues</h2>
@ -117,8 +129,8 @@ and NAT</a></b><br>
<blockquote>
<p align="left">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. </p>
prevent it from working with Shorewall. Regrettably,
RedHat released this buggy iptables in RedHat 7.2. </p>
<p align="left"> I have built a <a
@ -126,7 +138,7 @@ and NAT</a></b><br>
corrected 1.2.3 rpm which you can download here</a>  and I have
also built an <a
href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">
iptables-1.2.4 rpm which you can download here</a>. If you are currently
iptables-1.2.4 rpm which you can download here</a>. If you are currently
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
@ -181,35 +193,41 @@ download from<font color="#ff6633"> <a
installing <a
href="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm">
this iptables RPM</a>. 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").</p>
of iptables, you will need to specify the --oldpackage option
to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").</p>
</blockquote>
<h3><a name="SuSE"></a>Problems installing/upgrading
RPM on SuSE</h3>
<p>If you find that rpm complains about a conflict
with kernel &lt;= 2.2 yet you have a 2.4 kernel
installed, simply use the "--nodeps" option to
rpm.</p>
<p>Installing: rpm -ivh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<p>Upgrading: rpm -Uvh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<h3><a name="Multiport"></a><b>Problems with
iptables version 1.2.7 and MULTIPORT=Yes</b></h3>
<p>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:</p>
<ul>
<li>set MULTIPORT=No
in /etc/shorewall/shorewall.conf; or </li>
in /etc/shorewall/shorewall.conf; or </li>
<li>if you are running
Shorewall 1.3.6 you may install
<a
@ -229,17 +247,18 @@ in /etc/shorewall/shorewall.conf; or </li>
Error message is:<br>
<pre>Setting up NAT...<br>iptables: Invalid argument<br>Terminated<br><br></pre>
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 <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
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 <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 2/8/2003 -
<p><font size="2"> Last updated 3/21/2003 -
<a href="support.htm">Tom Eastep</a></font> </p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
</body>
</html>

43
STABLE/documentation/myfiles.htm
View File

@ -34,13 +34,16 @@
<h1>My Current Network </h1>
<blockquote>
<p><big><font color="#ff0000"><b>Warning: </b></font><b><small>I</small></b></big><big><b><small>
<p><big><font color="#ff0000"><b>Warning 1: </b></font><b><small>I</small></b></big><big><b><small>
use a combination of Static NAT and Proxy ARP, neither of which are relevant
to a simple configuration with a single public IP address.</small></b></big><big><b><small>
If you have just a single public IP address, most of what you see here won't
apply to your setup so beware of copying parts of this configuration and
expecting them to work for you. What you copy may or may not work in your
configuration. </small></b></big><br>
If you have just a single public IP address, most of what you see here
won't apply to your setup so beware of copying parts of this configuration
and expecting them to work for you. What you copy may or may not work in
your configuration.<br>
</small></b></big></p>
<p><big><b><small><big><font color="#ff0000">Warning 2:</font></big> </small></b></big><b>My
configuration uses features introduced in Shorewall version 1.4.1.</b><br>
</p>
<p> I have DSL service and have 5 static IP addresses (206.124.146.176-180).
@ -52,13 +55,13 @@ configuration. </small></b></big><br>
</p>
<ul>
<li>Static NAT for Ursa (my XP System) - Internal address 192.168.1.5
and external address 206.124.146.178.</li>
<li>Static NAT for Ursa (my XP System) - Internal address
192.168.1.5 and external address 206.124.146.178.</li>
<li>Static NAT for Wookie (my Linux System). Internal address
192.168.1.3 and external address 206.124.146.179.</li>
192.168.1.3 and external address 206.124.146.179.</li>
<li>SNAT through the primary gateway address (206.124.146.176)
for  my Wife's system (Tarry) and the laptop when connected through
the Wireless Access Point (wap)</li>
for  my Wife's system (Tarry) and the laptop when connected through the
Wireless Access Point (wap)</li>
</ul>
@ -81,8 +84,8 @@ through a PPTP server running on Ursa. </p>
network.</p>
<p> All administration and publishing is done using ssh/scp. I have X installed
on both the firewall and the server but no X server or desktop is installed.
X applications tunnel through SSH to XWin.exe running on Ursa.</p>
on both the firewall and the server but no X server or desktop is installed.
X applications tunnel through SSH to XWin.exe running on Ursa.</p>
<p> I run an SNMP server on my firewall to serve <a
href="http://www.ee.ethz.ch/%7Eoetiker/webtools/mrtg/"> MRTG</a> running
@ -99,10 +102,10 @@ X applications tunnel through SSH to XWin.exe running on Ursa.</p>
255.255.255.0. The server's default gateway is
206.124.146.254 (Router at my ISP. This is the same
default gateway used by the firewall itself). On the firewall,
Shorewall automatically adds a host route to
206.124.146.177 through eth1 (192.168.2.1) because
of the entry in /etc/shorewall/proxyarp (see
below).</p>
Shorewall automatically adds a host route
to 206.124.146.177 through eth1 (192.168.2.1)
because of the entry in /etc/shorewall/proxyarp
(see below).</p>
<p>A similar setup is used on eth3 (192.168.3.1) which
interfaces to my laptop (206.124.146.180).<br>
@ -122,6 +125,7 @@ X applications tunnel through SSH to XWin.exe running on Ursa.</p>
</blockquote>
<h4> </h4>
<h3>Params File (Edited):</h3>
<blockquote>MIRRORS=<i>&lt;list of shorewall mirror ip addresses&gt;</i><br>
@ -141,8 +145,8 @@ X applications tunnel through SSH to XWin.exe running on Ursa.</p>
<blockquote>
<p> This is set up so that I can start the firewall before bringing up
my Ethernet interfaces. </p>
<p> This is set up so that I can start the firewall before bringing up my
Ethernet interfaces. </p>
</blockquote>
<blockquote>
@ -166,7 +170,7 @@ my Ethernet interfaces. </p>
<h3>Policy File:</h3>
<blockquote>
<pre>#SOURCE DESTINATION POLICY LOG LEVEL BURST:LIMIT<br>me all ACCEPT<br>tx me ACCEPT<br>all me CONTINUE - 2/sec:5<br>loc net ACCEPT<br>$FW loc ACCEPT<br>$FW tx ACCEPT<br>loc tx ACCEPT<br>loc fw REJECT $LOG<br>net net ACCEPT<br>net all DROP $LOG 10/sec:40<br>all all REJECT $LOG<br>#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE<br></pre>
<pre>#SOURCE DESTINATION POLICY LOG LEVEL BURST:LIMIT<br>me loc NONE<br>loc me NONE<br>me all ACCEPT<br>tx me ACCEPT<br>all me CONTINUE - 2/sec:5<br>loc net ACCEPT<br>$FW loc ACCEPT<br>$FW tx ACCEPT<br>loc tx ACCEPT<br>loc fw REJECT $LOG<br>net all DROP $LOG 10/sec:40<br>all all REJECT $LOG<br>#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE<br></pre>
</blockquote>
<h3>Masq File: </h3>
@ -223,5 +227,6 @@ my Ethernet interfaces. </p>
<br>
<br>
<br>
<br>
</body>
</html>

59
STABLE/documentation/quotes.htm
View File

@ -27,16 +27,20 @@
</tbody>
</table>
<p>"The configuration is intuitive and flexible, and much easier than any
of the other iptables-based firewall programs out there. After sifting through
many other scripts, it is obvious that yours is the most well thought-out
and complete one available." -- BC, USA</p>
<p>"I just installed Shorewall after weeks of messing with ipchains/iptables
and I had it up and running in under 20 minutes!" -- JL, Ohio<br>
and I had it up and running in under 20 minutes!" -- JL, Ohio<br>
</p>
"My case was almost like [the one above]. Well. instead of 'weeks' it was
'months' for me, and I think I needed two minutes more:<br>
'months' for me, and I think I needed two minutes more:<br>
<ul>
<li>One to see that I had no Internet access from the firewall itself.</li>
<li>Other to see that this was the default configuration, and it was enough
to uncomment a line in /etc/shorewall/policy.<br>
<li>Other to see that this was the default configuration, and it was
enough to uncomment a line in /etc/shorewall/policy.<br>
</li>
</ul>
@ -44,37 +48,37 @@ to uncomment a line in /etc/shorewall/policy.<br>
and well documented thing for something as huge as iptables." -- JV, Spain.
<p>"I downloaded Shorewall 1.2.0 and installed it on Mandrake 8.1 without
any problems. Your documentation is great and I really appreciate your
network configuration info. That really helped me out alot. THANKS!!!"
-- MM. </p>
any problems. Your documentation is great and I really appreciate
your network configuration info. That really helped me out alot. THANKS!!!"
-- MM. </p>
<p>"[Shorewall is a] great, great project. I've used/tested may firewall
scripts but this one is till now the best." -- B.R, Netherlands
scripts but this one is till now the best." -- B.R, Netherlands
</p>
<p>"Never in my +12 year career as a sys admin have I witnessed someone
so relentless in developing a secure, state of the art, safe and useful
product as the Shorewall firewall package for no cost or obligation
involved." -- Mario Kerecki, Toronto </p>
so relentless in developing a secure, state of the art, safe and useful
product as the Shorewall firewall package for no cost or obligation
involved." -- Mario Kerecki, Toronto </p>
<p>"one time more to report, that your great shorewall in the latest
release 1.2.9 is working fine for me with SuSE Linux 7.3! I now have
7 machines up and running with shorewall on several versions - starting
with 1.2.2 up to the new 1.2.9 and I never have encountered any problems!"
-- SM, Germany</p>
release 1.2.9 is working fine for me with SuSE Linux 7.3! I now
have 7 machines up and running with shorewall on several versions -
starting with 1.2.2 up to the new 1.2.9 and I never have encountered
any problems!" -- SM, Germany</p>
<p>"You have the best support of any other package I've ever used."
-- SE, US </p>
-- SE, US </p>
<p>"Because our company has information which has been classified by the
national government as secret, our security doesn't stop by putting a fence
national government as secret, our security doesn't stop by putting a fence
around our company. Information security is a hot issue. We also make use
of checkpoint firewalls, but not all of the internet servers are guarded
by checkpoint, some of them are running....Shorewall." -- Name withheld by
request, Europe</p>
of checkpoint firewalls, but not all of the internet servers are guarded
by checkpoint, some of them are running....Shorewall." -- Name withheld
by request, Europe</p>
<p>"thanx for all your efforts you put into shorewall - this product stands
out against a lot of commercial stuff i´ve been working with in terms of
out against a lot of commercial stuff i´ve been working with in terms of
flexibillity, quality &amp; support" -- RM, Austria</p>
<p>"I have never seen such a complete firewall package that is so easy to
@ -82,22 +86,23 @@ out against a lot of commercial stuff i
Shorewall won hands down." -- RG, Toronto</p>
<p>"My respects... I've just found and installed Shorewall 1.3.3-1 and it
is a wonderful piece of software. I've just sent out an email to about 30
people recommending it. :-)<br>
is a wonderful piece of software. I've just sent out an email to about
30 people recommending it. :-)<br>
While I had previously taken the time (maybe 40 hours) to really understand
ipchains, then spent at least an hour per server customizing and carefully
scrutinizing firewall rules, I've got shorewall running on my home firewall,
with rulesets and policies that I know make sense, in under 20 minutes."
-- RP, Guatamala<br>
-- RP, Guatamala<br>
<br>
 </p>
<p><font size="2" face="Century Gothic, Arial, Helvetica">Updated 10/9/2002
- <a href="support.htm">Tom Eastep</a> </font>
<p><font size="2" face="Century Gothic, Arial, Helvetica">Updated 3/18/2003
- <a href="support.htm">Tom Eastep</a> </font>
</p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
</body>

306
STABLE/documentation/seattlefirewall_index.htm
View File

@ -63,6 +63,7 @@
</div>
<p><a href="http://www.shorewall.net" target="_top">
</a> </p>
@ -78,9 +79,9 @@
<div align="center"><a href="http://1.3/index.htm" target="_top"><font
<div align="center"><a href="1.3" target="_top"><font
color="#ffffff">Shorewall 1.3 Site is here</font></a>                  
            <br>
            <br>
</div>
</td>
@ -165,7 +166,7 @@ Software Foundation.<br>
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
A PARTICULAR PURPOSE. See the GNU General Public License
for more details.<br>
<br>
@ -173,7 +174,7 @@ A PARTICULAR PURPOSE. See the GNU General Public License
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
to the Free Software Foundation, Inc., 675
Mass Ave, Cambridge, MA 02139, USA</p>
@ -219,6 +220,7 @@ to the Free Software Foundation, Inc., 675
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.1!!! </b><br>
</p>
@ -228,271 +230,48 @@ Bering 1.1!!! </b><br>
<h2>News</h2>
<p><b>3/17/2003 - Shorewall 1.4.0 </b><b> </b><b><img
<p><b>3/24/2003 - Shorewall 1.4.1 </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b><b> </b></p>
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. <br>
This release follows up on 1.4.0. It corrects a problem introduced in 1.4.0
and removes additional warts.<br>
<br>
<b>IMPORTANT: Shorewall 1.4.0 requires</b> <b>the iproute package
('ip' utility).</b><br>
<br>
Function from 1.3 that has been omitted from this version
include:<br>
<b>Problems Corrected:</b><br>
<ol>
<li>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.<br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
</li>
<li>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.</li>
</ol>
Changes for 1.4 include:<br>
<b>New Features:</b><br>
<blockquote>Note: In the list that follows, the term <i>group </i>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:<br>
<blockquote>eth0:0.0.0.0/0<br>
eth2:192.168.1.0/24<br>
eth3:192.0.2.123<br>
</blockquote>
You can use the "shorewall check" command to see the groups associated with
each of your zones.<br>
</blockquote>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
<br>
</li>
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script, common functions file and version file
are now installed in /usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the
common chain by default.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>CONTINUE is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i>
now support the 'maclist' option.<br>
<br>
</li>
<li value="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:<br>
<br>
a) You must be running kernel 2.4.20<br>
b) You must have applied the patch in<br>
http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
c) You must have iptables 1.2.7a installed.<br>
<br>
</li>
<li>The /etc/shorewall/params file is now processed first so that
variables may be used in the /etc/shorewall/shorewall.conf file.<br>
<br>
</li>
<li value="10">Shorewall now gives a more helpful diagnostic when
the 'ipchains' compatibility kernel module is loaded and a 'shorewall start'
command is issued.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>Shorewall now ignores 'default' routes when detecting masq'd
networks.<br>
</li>
<li>Beginning with Shorewall 1.4.1, if a zone Z comprises more than
one group<i> </i>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.</li>
<li>Beginning with Shorewall 1.4.1, Shorewall will never create rules
to handle traffic from a group to itself.</li>
<li>A NONE policy is introduced in 1.4.1. When a policy of NONE is
specified from Z1 to Z2:</li>
</ol>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
target="_top"></a>
<p><b>3/11/2003 - Shoreall 1.3.14a</b><b> </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>A roleup of the following bug fixes and other updates:</p>
<ul>
<li>There is an updated rfc1918 file that reflects the resent
allocation of 222.0.0.0/8 and 223.0.0.0/8.</li>
<li>The documentation for the routestopped file claimed that a
comma-separated list could appear in the second column while the code
only supported a single host or network address.</li>
<li>Log messages produced by 'logunclean' and 'dropunclean' were
not rate-limited. 802.11b devices with names of the form <i>wlan</i>&lt;n&gt;
don't support the 'maclist' interface option.</li>
<li>Log messages generated by RFC 1918 filtering are not rate
limited.</li>
<li>The firewall fails to start in the case
where you have "eth0 eth1" in /etc/shorewall/masq and the default route
is through eth1.</li>
<li>There may be no rules created that govern connections from Z1
to Z2.</li>
<li>Shorewall will not create any infrastructure to handle traffic
from Z1 to Z2.</li>
</ul>
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b></p>
<p>New features include</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>
<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>
<br>
a) In the INTERFACE column of /etc/shorewall/masq<br>
b) In the INTERFACE column of /etc/shorewall/nat<br>
</li>
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the
form $DEV.$VID (e.g., eth0.0)<br>
<br>
</li>
<li>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 <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<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>
<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>
<br>
Example 1 -- This is how it works in 1.3.14.<br>
<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS<br> eth0 eth2 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<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></pre>
<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>
<br>
Example 2 -- Suppose that your current config is as
follows:<br>
<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS<br> eth0 eth2 206.124.146.176<br> eth0 192.168.10.0/24 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<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]#</pre>
<br>
In this case, the second entry in /etc/shorewall/masq
is no longer required.<br>
<br>
Example 3 -- What if your current configuration is
like this?<br>
<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS<br> eth0 eth2 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<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]#</pre>
<br>
In this case, you would want to change the entry
in /etc/shorewall/masq to:<br>
<pre> #INTERFACE SUBNET ADDRESS<br> eth0 192.168.1.0/24 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
</li>
</ol>
<br>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0</b><b>
</b></p>
Webmin version 1.060 now has Shorewall support included
as standard. See <a href="http://www.webmin.com">http://www.webmin.com</a>.<b>
</b>
See the <a href="upgrade_issues.htm">upgrade issues</a> for a discussion
of how these changes may affect your configuration.<br>
<p><a href="News.htm">More News</a></p>
<h2><a name="Donations"></a>Donations</h2>
@ -511,6 +290,7 @@ like this?<br>
</tbody>
</table>
@ -581,9 +361,11 @@ Children's Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 3/17/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 3/21/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</p>
<br>
<br>
</body>
</html>

37
STABLE/documentation/shoreline.htm
View File

@ -47,8 +47,8 @@
<li>Burroughs Corporation (now <a
href="http://www.unisys.com">Unisys</a> ) 1969 - 1980</li>
<li><a href="http://www.tandem.com">Tandem Computers, Incorporated</a>
(now part of the <a href="http://www.hp.com">The New HP</a>) 1980 -
present</li>
(now part of the <a href="http://www.hp.com">The New HP</a>) 1980
- present</li>
<li>Married 1969 - no children.</li>
</ul>
@ -58,15 +58,15 @@
<p>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 <a href="http://seawall.sourceforge.net"> Seattle Firewall</a>.
Expanding on what I learned from Seattle Firewall, I then designed
and wrote Shorewall. </p>
ipchains and developed the scripts which are now collectively known as
<a href="http://seawall.sourceforge.net"> Seattle Firewall</a>. Expanding
on what I learned from Seattle Firewall, I then designed and
wrote Shorewall. </p>
<p>I telework from our <a
href="http://lists.shorewall.net/SeattleInTheSpring.html">home</a> in <a
href="http://www.cityofshoreline.com">Shoreline, Washington</a>
where I live with my wife Tarry.  </p>
href="http://www.cityofshoreline.com">Shoreline, Washington</a> where
I live with my wife Tarry.  </p>
<p>Our current home network consists of: </p>
@ -76,22 +76,22 @@ where I live with my wife Tarry.
Serves as a PPTP server for Road Warrior access. Dual boots <a
href="http://www.mandrakelinux.com">Mandrake</a> 9.0.</li>
<li>Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip)
NIC - My personal Linux System which runs Samba configured as
a WINS server. This system also has <a
href="http://www.vmware.com/">VMware</a> installed and can run
both <a href="http://www.debian.org">Debian Woody</a> and <a
NIC - My personal Linux System which runs Samba configured as a
WINS server. This system also has <a
href="http://www.vmware.com/">VMware</a> installed and can run both
<a href="http://www.debian.org">Debian Woody</a> and <a
href="http://www.suse.com">SuSE 8.1</a> in virtual machines.</li>
<li>K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC 
- Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd),
DNS server (Bind 9).</li>
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3
LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.14 
LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.4.0 
and a DHCP server.</li>
<li>Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC -
My wife's personal system.</li>
<li>Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC
- My wife's personal system.</li>
<li>PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard
EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main
work system.</li>
EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My
main work system.</li>
</ul>
@ -118,12 +118,13 @@ My wife's personal system.</li>
width="125" height="40" hspace="4">
</font></p>
<p><font size="2">Last updated 3/7/2003 - </font><font size="2"> <a
<p><font size="2">Last updated 3/17/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<font face="Trebuchet MS"><a href="copyright.htm"><font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas
M. Eastep.</font></a></font><br>
<br>
<br>
<br>
</body>
</html>

20
STABLE/documentation/shorewall_prerequisites.htm
View File

@ -30,16 +30,17 @@
Shorewall Requires:<br>
<ul>
<li>A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6.
<a href="kernel.htm"> Check here for kernel configuration information.</a>
If you are looking for a firewall for use with 2.2 kernels, <a
href="http://seawall.sf.net"> see the Seattle Firewall site</a>
.</li>
<li>A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20.
With current releases of Shorewall, Traffic Shaping/Control requires at least
2.4.18.  <a href="kernel.htm"> Check here for kernel configuration
information.</a> If you are looking for a firewall for use with
2.2 kernels, <a href="http://seawall.sf.net"> see the Seattle Firewall
site</a> .</li>
<li>iptables 1.2 or later but beware version 1.2.3 -- see the <a
href="errata.htm">Errata</a>. <font color="#ff0000"><b>WARNING: </b></font>The
buggy iptables version 1.2.3 is included in RedHat 7.2 and you should
upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4
is available <a
upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4
is available <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">from RedHat</a>
and in the <a href="errata.htm">Shorewall Errata</a>. </li>
<li>Iproute ("ip" utility). The iproute package is included with
@ -52,11 +53,11 @@ download site is <a href="ftp://ftp.inr.ac.ru/ip-routing"
}, ${<i>variable</i>%%<i>pattern</i>}, ${<i>variable</i>#<i>pattern</i>
} and ${<i>variable</i>##<i>pattern</i>}.</li>
<li>The firewall monitoring display is greatly improved if you have
awk (gawk) installed.</li>
awk (gawk) installed.</li>
</ul>
<p align="left"><font size="2">Last updated 2/21/2003 - <a
<p align="left"><font size="2">Last updated 3/19/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
@ -65,5 +66,6 @@ awk (gawk) installed.</li>
<br>
<br>
<br>
<br>
</body>
</html>

370
STABLE/documentation/shorewall_setup_guide.htm
View File

@ -61,13 +61,13 @@
general guidelines and will point you to other resources as necessary.</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you run LEAF Bering, your Shorewall configuration is NOT what
I release -- I suggest that you consider installing a stock Shorewall
lrp from the shorewall.net site before you proceed.</p>
    If you run LEAF Bering, your Shorewall configuration is NOT
what I release -- I suggest that you consider installing a stock Shorewall
lrp from the shorewall.net site before you proceed.</p>
<p>Shorewall requires that the iproute/iproute2 package be installed (on
RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell if
this package is installed by the presence of an <b>ip</b> program on your
this package is installed by the presence of an <b>ip</b> program on your
firewall system. As root, you can use the 'which' command to check for
this program:</p>
@ -76,22 +76,24 @@ this program:</p>
<p>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 <img border="0" src="images/BD21298_.gif" width="13" height="13">
with <img border="0" src="images/BD21298_.gif" width="13"
height="13">
.</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    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 with Shorewall.
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.</p>
must save them as Unix files if your editor supports that option or you
must run them through dos2unix before trying to use them with Shorewall.
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.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
Version of dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
<li><a href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux
Version of dos2unix</a></li>
</ul>
@ -107,8 +109,8 @@ of these as described in this guide. Skeleton files are created during the
and some contain default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the default installation, the following zone names
are used:</p>
set of <i>zones.</i> In the default installation, the following zone
names are used:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
@ -137,14 +139,14 @@ of these as described in this guide. Skeleton files are created during the
file.</p>
<p>Shorewall also recognizes the firewall system as its own zone - by default,
the firewall itself is known as <b>fw</b> but that may be changed in the
<a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
the firewall itself is known as <b>fw</b> but that may be changed in
the <a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
file. In this guide, the default name (<b>fw</b>) will be used.</p>
<p>With the exception of <b>fw</b>, Shorewall attaches absolutely no meaning
to zone names. Zones are entirely what YOU make of them. That means that
you should not expect Shorewall to do something special "because this
is the internet zone" or "because that is the DMZ".</p>
is the internet zone" or "because that is the DMZ".</p>
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
    Edit the /etc/shorewall/zones file and make any changes necessary.</p>
@ -153,11 +155,11 @@ is the internet zone" or "because that is the DMZ".</p>
in terms of zones.</p>
<ul>
<li>You express your default policy for connections from one zone
to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
<li>You express your default policy for connections from one
zone to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
</a>file.</li>
<li>You define exceptions to those default policies in the <a
href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
<li>You define exceptions to those default policies in the
<a href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
</ul>
@ -173,19 +175,19 @@ is the internet zone" or "because that is the DMZ".</p>
<li> Identify the source zone.</li>
<li> Identify the destination zone.</li>
<li> If the POLICY from the client's zone to the server's
zone is what you want for this client/server pair, you need do nothing
further.</li>
<li> If the POLICY is not what you want, then you must add
a rule. That rule is expressed in terms of the client's zone and
the server's zone.</li>
zone is what you want for this client/server pair, you need do
nothing further.</li>
<li> If the POLICY is not what you want, then you must
add a rule. That rule is expressed in terms of the client's zone
and the server's zone.</li>
</ol>
<p> Just because connections of a particular type are allowed from zone A
to the firewall and are also allowed from the firewall to zone B <font
color="#ff6633"><b><u> DOES NOT mean that these connections are allowed
from zone A to zone B</u></b></font>. It rather means that you can have
a proxy running on the firewall that accepts a connection from zone
from zone A to zone B</u></b></font>. It rather means that you can
have a proxy running on the firewall that accepts a connection from zone
A and then establishes its own separate connection from the firewall to
zone B.</p>
@ -193,7 +195,7 @@ zone B.</p>
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.def.</p>
the request is first checked against the rules in /etc/shorewall/common.def.</p>
<p>The default /etc/shorewall/policy file has the following policies:</p>
@ -237,35 +239,35 @@ the request is first checked against the rules in /etc/shorewall/common.def.</
<p>The above policy will:</p>
<ol>
<li>allow all connection requests from your local network to the
internet</li>
<li>allow all connection requests from your local network to
the internet</li>
<li>drop (ignore) all connection requests from the internet to
your firewall or local network and log a message at the <i>info</i>
level (<a href="shorewall_logging.html">here</a> is a description of log
levels).</li>
<li>reject all other connection requests and log a message at the
<i>info</i> level. When a request is rejected, the firewall will
return an RST (if the protocol is TCP) or an ICMP port-unreachable packet
for other protocols.</li>
your firewall or local network and log a message at the <i>info</i>
level (<a href="shorewall_logging.html">here</a> is a description of log
levels).</li>
<li>reject all other connection requests and log a message at
the <i>info</i> level. When a request is rejected, the firewall
will return an RST (if the protocol is TCP) or an ICMP port-unreachable
packet for other protocols.</li>
</ol>
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
    At this point, edit your /etc/shorewall/policy and make any changes
that you wish.</p>
    At this point, edit your /etc/shorewall/policy and make any
changes that you wish.</p>
<h2 align="left"><a name="Interfaces"></a>3.0 Network Interfaces</h2>
<p align="left">For the remainder of this guide, we'll refer to the following
diagram. While it may not look like your own network, it can be used to
illustrate the important aspects of Shorewall configuration.</p>
diagram. While it may not look like your own network, it can be used
to illustrate the important aspects of Shorewall configuration.</p>
<p align="left">In this diagram:</p>
<ul>
<li>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is
used to isolate your internet-accessible servers from your local systems
so that if one of those servers is compromised, you still have the firewall
used to isolate your internet-accessible servers from your local systems
so that if one of those servers is compromised, you still have the firewall
between the compromised system and your local systems. </li>
<li>The Local Zone consists of systems Local 1, Local 2 and Local
3. </li>
@ -280,18 +282,18 @@ so that if one of those servers is compromised, you still have the firewall
<p align="left">The simplest way to define zones is to simply associate the
zone name (previously defined in /etc/shorewall/zones) with a network
interface. This is done in the <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
file.</p>
interface. This is done in the <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a> file.</p>
<p align="left">The firewall illustrated above has three network interfaces.
Where Internet connectivity is through a cable or DSL "Modem", the <i>External
Interface</i> will be the Ethernet adapter that is connected to that "Modem"
(e.g., <b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
Interface</i> will be the Ethernet adapter that is connected to that
"Modem" (e.g., <b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect via
a regular modem, your External Interface will also be <b>ppp0</b>. If
you connect using ISDN, you external interface will be <b>ippp0.</b></p>
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect
via a regular modem, your External Interface will also be <b>ppp0</b>.
If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
@ -302,21 +304,21 @@ you connect using ISDN, you external interface will be <b>ippp0.</b></p>
<p align="left">Your <i>Local Interface</i> 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 <i>cross-over </i> cable).</p>
local system, you can connect the firewall directly to the computer using
a <i>cross-over </i> cable).</p>
<p align="left">Your <i>DMZ Interface</i> 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
a single DMZ system, you can connect the firewall directly to the computer
using a <i>cross-over </i> cable).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u>Do not connect more than one interface to the same hub or
switch (even for testing). It won't work the way that you expect it to
and you will end up confused and believing that Linux networking doesn't
work at all.</p>
</b></u>Do not connect more than one interface to the same hub
or switch (even for testing). It won't work the way that you expect
it to and you will end up confused and believing that Linux networking
doesn't work at all.</p>
<p align="left">For the remainder of this Guide, we will assume that:</p>
@ -374,7 +376,7 @@ work at all.</p>
height="13">
    Edit the /etc/shorewall/interfaces file and define the network
interfaces on your firewall and associate each interface with a zone.
If you have a zone that is interfaced through more than one interface,
If you have a zone that is interfaced through more than one interface,
simply include one entry for each interface and repeat the zone name as
many times as necessary.</p>
@ -453,9 +455,9 @@ many times as necessary.</p>
<p align="left">Normally, your ISP will assign you a set of <i> Public</i>
IP addresses. You will configure your firewall's external interface to
use one of those addresses permanently and you will then have to decide
how you are going to use the rest of your addresses. Before we tackle that
question though, some background is in order.</p>
use one of those addresses permanently and you will then have to decide
how you are going to use the rest of your addresses. Before we tackle that
question though, some background is in order.</p>
<p align="left">If you are thoroughly familiar with IP addressing and routing,
you may <a href="#Options">go to the next section</a>.</p>
@ -500,11 +502,11 @@ Addressing &amp; Routing",</i> Thomas A. Maufer, Prentice-Hall, 1999, ISBN
<p align="left">The class of a network was uniquely determined by the value
of the high order byte of its address so you could look at an IP address
and immediately determine the associated <i>netmask</i>. The netmask is
a number that when logically ANDed with an address isolates the <i>network
and immediately determine the associated <i>netmask</i>. The netmask
is a number that when logically ANDed with an address isolates the <i>network
number</i>; the remainder of the address is the <i>host number</i>. For
example, in the Class C address 192.0.2.14, the network number is hex C00002
and the host number is hex 0E.</p>
example, in the Class C address 192.0.2.14, the network number is hex
C00002 and the host number is hex 0E.</p>
<p align="left">As the internet grew, it became clear that such a gross
partitioning of the 32-bit address space was going to be very limiting (early
@ -538,15 +540,15 @@ that you are likely to work with will understand CIDR and Class-based networkin
</ol>
<p align="left">As you can see by this definition, in each subnet of size
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that can
be assigned to hosts). The first and last address in the subnet are
used for the subnet address and subnet broadcast address respectively.
Consequently, small subnetworks are more wasteful of IP addresses than
are large ones. </p>
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that
can be assigned to hosts). The first and last address in the subnet
are used for the subnet address and subnet broadcast address respectively.
Consequently, small subnetworks are more wasteful of IP addresses than
are large ones. </p>
<p align="left">Since <b>n</b> is a power of two, we can easily calculate
the <i>Natural Logarithm</i> (<b>log2</b>) of <b>n</b>. For the more
common subnet sizes, the size and its natural logarithm are given in the
common subnet sizes, the size and its natural logarithm are given in the
following table:</p>
<blockquote>
@ -745,12 +747,12 @@ common subnet sizes, the size and its natural logarithm are given in the
the subnet mask with an address in the subnet, the result is the subnet
address. Just as important, if you logically AND the subnet mask with
an address outside the subnet, the result is NOT the subnet address.
As we will see below, this property of subnet masks is very useful in
routing.</p>
As we will see below, this property of subnet masks is very useful in
routing.</p>
<p align="left">For a subnetwork whose address is <b>a.b.c.d</b> and whose
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork as
"<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork
as "<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
<p align="left">Example:</p>
@ -842,11 +844,12 @@ routing.</p>
the Dallas, Texas area.<br>
<br>
The first three routes are <i>host routes</i> since they indicate
how to get to a single host. In the 'netstat' output this can be seen
by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags
column. The remainder are 'net' routes since they tell the kernel how
to route packets to a subnetwork. The last route is the <i>default route</i>
and the gateway mentioned in that route is called the <i>default gateway</i>.</p>
how to get to a single host. In the 'netstat' output this can be seen
by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the
Flags column. The remainder are 'net' routes since they tell the kernel
how to route packets to a subnetwork. The last route is the <i>default
route</i> and the gateway mentioned in that route is called the <i>default
gateway</i>.</p>
<p align="left">When the kernel is trying to send a packet to IP address <b>A</b>,
it starts at the top of the routing table and:</p>
@ -893,7 +896,7 @@ at your ISP.</p>
<p align="left">Lets take an example. Suppose that we want to route a packet
to 192.168.1.5. That address clearly doesn't match any of the host routes
in the table but if we logically and that address with 255.255.255.0,
the result is 192.168.1.0 which matches this routing table entry:</p>
the result is 192.168.1.0 which matches this routing table entry:</p>
<div align="left">
<blockquote>
@ -904,9 +907,9 @@ the result is 192.168.1.0 which matches this routing table entry:</p>
</div>
<p align="left">One more thing needs to be emphasized -- all outgoing packet
are sent using the routing table and reply packets are not a special case.
There seems to be a common mis-conception whereby people think that request
packets are like salmon and contain a genetic code that is magically
are sent using the routing table and reply packets are not a special
case. There seems to be a common mis-conception whereby people think that
request packets are like salmon and contain a genetic code that is magically
transferred to reply packets so that the replies follow the reverse route
taken by the request. That isn't the case; the replies may take a totally
different route back to the client than was taken by the requests -- they
@ -918,7 +921,7 @@ are totally independent.</p>
Rather Ethernet addressing is based on <i>Media Access Control</i> (MAC)
addresses. Each Ethernet device has it's own unique  MAC address which
is burned into a PROM on the device during manufacture. You can obtain
the MAC of an Ethernet device using the 'ip' utility:</p>
the MAC of an Ethernet device using the 'ip' utility:</p>
<blockquote>
<div align="left">
@ -954,8 +957,8 @@ the card itself. </p>
<p align="left">In order to avoid having to exchange ARP information each
time that an IP packet is to be sent, systems maintain an <i>ARP cache</i>
of IP&lt;-&gt;MAC correspondences. You can see the ARP cache on your system
(including your Windows system) using the 'arp' command:</p>
of IP&lt;-&gt;MAC correspondences. You can see the ARP cache on your
system (including your Windows system) using the 'arp' command:</p>
<blockquote>
<div align="left">
@ -965,10 +968,10 @@ the card itself. </p>
<p align="left">The leading question marks are a result of my having specified
the 'n' option (Windows 'arp' doesn't allow that option) which causes
the 'arp' program to forego IP-&gt;DNS name translation. Had I not given
that option, the question marks would have been replaced with the FQDN
corresponding to each IP address. Notice that the last entry in the table
records the information we saw using tcpdump above.</p>
the 'arp' program to forego IP-&gt;DNS name translation. Had I not given
that option, the question marks would have been replaced with the FQDN
corresponding to each IP address. Notice that the last entry in the table
records the information we saw using tcpdump above.</p>
<h3 align="left"><a name="RFC1918"></a>4.5 RFC 1918</h3>
@ -976,10 +979,11 @@ records the information we saw using tcpdump above.</p>
href="http://www.iana.org">Internet Assigned Number Authority</a> </i>(IANA)
who delegates allocations on a geographic basis to <i>Regional Internet
Registries</i> (RIRs). For example, allocation for the Americas and for
sub-Sahara Africa is delegated to the <i><a href="http://www.arin.net">American
Registry for Internet Numbers</a> </i>(ARIN). These RIRs may in turn delegate
to national registries. Most of us don't deal with these registrars but
rather get our IP addresses from our ISP.</p>
sub-Sahara Africa is delegated to the <i><a
href="http://www.arin.net">American Registry for Internet Numbers</a>
</i>(ARIN). These RIRs may in turn delegate to national registries. Most
of us don't deal with these registrars but rather get our IP addresses
from our ISP.</p>
<p align="left">It's a fact of life that most of us can't afford as many Public
IP addresses as we have devices to assign them to so we end up making use
@ -993,9 +997,9 @@ for this purpose:</p>
<div align="left">
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. This is understandable
given that anyone can select any of these addresses for their private
use.</p>
forward packets which have an RFC-1918 destination address. This is
understandable given that anyone can select any of these addresses for
their private use.</p>
</div>
<div align="left">
@ -1042,8 +1046,8 @@ for this purpose:</p>
<p align="left"><b>Routed - </b>Traffic to any of your addresses will
be routed through a single <i>gateway address</i>. This will generally
only be done if your ISP has assigned you a complete subnet (/29 or
larger). In this case, you will assign the gateway address as the IP
address of your firewall/router's external interface. </p>
larger). In this case, you will assign the gateway address as the IP
address of your firewall/router's external interface. </p>
</li>
<li>
<p align="left"><b>Non-routed - </b>Your ISP will send traffic to each
@ -1086,7 +1090,7 @@ change them appropriately:<br>
is 192.0.2.65. Your ISP has also told you that you should use a netmask
of 255.255.255.0 (so your /28 is part of a larger /24). With this many
IP addresses, you are able to subnet your /28 into two /29's and set
up your network as shown in the following diagram.</p>
up your network as shown in the following diagram.</p>
</div>
<div align="left">
@ -1105,11 +1109,11 @@ be configured to 192.0.2.66 and the default gateway for hosts in the local
<div align="left">
<p align="left">Notice that this arrangement is rather wasteful of public
IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet
addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and
192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
Nevertheless, it shows how subnetting can work and if we were dealing
with a /24 rather than a /28 network, the use of 6 IP addresses out of
256 would be justified because of the simplicity of the setup.</p>
addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses
and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
Nevertheless, it shows how subnetting can work and if we were dealing
with a /24 rather than a /28 network, the use of 6 IP addresses out
of 256 would be justified because of the simplicity of the setup.</p>
</div>
<div align="left">
@ -1129,9 +1133,9 @@ with a /24 rather than a /28 network, the use of 6 IP addresses out of
<p align="left">This means that DMZ 1 will send an ARP "who-has 192.0.2.65"
request and no device on the DMZ Ethernet segment has that IP address.
Oddly enough, the firewall will respond to the request with the MAC
address of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet frames
addressed to that MAC address and the frames will be received (correctly)
by the firewall/router.</p>
address of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet frames
addressed to that MAC address and the frames will be received (correctly)
by the firewall/router.</p>
</div>
<div align="left">
@ -1141,7 +1145,7 @@ by the firewall/router.</p>
When an ARP request for one of the firewall/router's IP addresses is sent
by another system connected to the hub/switch, all of the firewall's
interfaces that connect to the hub/switch can respond! It is then a
race as to which "here-is" response reaches the sender first.</p>
race as to which "here-is" response reaches the sender first.</p>
</div>
<div align="left">
@ -1170,8 +1174,8 @@ if the setup is routed). </p>
<div align="left">
<p align="left">Clearly, that set of addresses doesn't comprise a subnetwork
and there aren't enough addresses for all of the network interfaces.
There are four different techniques that can be used to work around this
problem.</p>
There are four different techniques that can be used to work around
this problem.</p>
</div>
<div align="left">
@ -1207,8 +1211,8 @@ if the setup is routed). </p>
<div align="left">
<p align="left">With SNAT, an internal LAN segment is configured using RFC
1918 addresses. When a host <b>A </b>on this internal segment initiates
a connection to host <b>B</b> on the internet, the firewall/router rewrites
the IP header in the request to use one of your public IP addresses
a connection to host <b>B</b> on the internet, the firewall/router
rewrites the IP header in the request to use one of your public IP addresses
as the source address. When <b>B</b> responds and the response is received
by the firewall, the firewall changes the destination address back
to the RFC 1918 address of <b>A</b> and forwards the response back to
@ -1218,8 +1222,8 @@ to the RFC 1918 address of <b>A</b> and forwards the response back to
<div align="left">
<p align="left">Let's suppose that you decide to use SNAT on your local zone
and use public address 192.0.2.176 as both your firewall's external
IP address and the source IP address of internet requests sent from that
zone.</p>
IP address and the source IP address of internet requests sent from
that zone.</p>
</div>
<div align="left">
@ -1235,8 +1239,9 @@ IP address and the source IP address of internet requests sent from that
<div align="left"> <img border="0" src="images/BD21298_2.gif"
width="13" height="13">
    The systems in the local zone would be configured with a default
gateway of 192.168.201.1 (the IP address of the firewall's local interface).</div>
    The systems in the local zone would be configured with a
default gateway of 192.168.201.1 (the IP address of the firewall's
local interface).</div>
<div align="left">  </div>
@ -1269,8 +1274,8 @@ IP address and the source IP address of internet requests sent from that
<div align="left">
<p align="left">This example used the normal technique of assigning the same
public IP address for the firewall external interface and for SNAT.
If you wanted to use a different IP address, you would either have to
use your distributions network configuration tools to add that IP address
If you wanted to use a different IP address, you would either have to
use your distributions network configuration tools to add that IP address
to the external interface or you could set ADD_SNAT_ALIASES=Yes in
/etc/shorewall/shorewall.conf and Shorewall will add the address for you.</p>
</div>
@ -1282,16 +1287,16 @@ use your distributions network configuration tools to add that IP address
<div align="left">
<p align="left">When SNAT is used, it is impossible for hosts on the internet
to initiate a connection to one of the internal systems since those
systems do not have a public IP address. DNAT provides a way to allow
selected connections from the internet.</p>
systems do not have a public IP address. DNAT provides a way to allow
selected connections from the internet.</p>
</div>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
     Suppose that your daughter wants to run a web server on her
system "Local 3". You could allow connections to the internet to her
server by adding the following entry in <a
     Suppose that your daughter wants to run a web server on
her system "Local 3". You could allow connections to the internet
to her server by adding the following entry in <a
href="Documentation.htm#Rules">/etc/shorewall/rules</a>:</p>
</div>
@ -1427,9 +1432,17 @@ respond (with the MAC if the firewall interface to <b>H</b>). </p>
</p>
<p align="left">The ethernet interfaces on DMZ 1 and DMZ 2 should be configured
to have the IP addresses shown but should have the same default gateway as
the firewall itself -- namely 192.0.2.254.<br>
to have the IP addresses shown but should have the same default gateway
as the firewall itself -- namely 192.0.2.254. In other words, they should
be configured just like they would be if they were parallel to the firewall
rather than behind it.<br>
</p>
<p><font color="#ff0000"><b>NOTE: Do not add the Proxy ARP'ed address(es)
(192.0.2.177 and 192.0.2.178 in the above example)  to the external interface
(eth0 in this example) of the firewall.</b></font><br>
</p>
<div align="left"> </div>
</div>
<div align="left">
@ -1441,45 +1454,45 @@ respond (with the MAC if the firewall interface to <b>H</b>). </p>
<p align="left">A word of warning is in order here. ISPs typically configure
their routers with a long ARP cache timeout. If you move a system from
parallel to your firewall to behind your firewall with Proxy ARP, it
will probably be HOURS before that system can communicate with the internet.
will probably be HOURS before that system can communicate with the internet.
There are a couple of things that you can try:<br>
</p>
<ol>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP
Illustrated, Vol 1</i> reveals that a <br>
Illustrated, Vol 1</i> reveals that a <br>
<br>
"gratuitous" ARP packet should cause the ISP's router to refresh their
ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the
MAC address for its own IP; in addition to ensuring that the IP address
isn't a duplicate,...<br>
ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
the MAC address for its own IP; in addition to ensuring that the IP address
isn't a duplicate,...<br>
<br>
"if the host sending the gratuitous ARP has just changed its hardware
address..., this packet causes any other host...that has an entry in its
cache for the old hardware address to update its ARP cache entry accordingly."<br>
<br>
Which is, of course, exactly what you want to do when you switch a host
from being exposed to the Internet to behind Shorewall using proxy ARP
(or static NAT for that matter). Happily enough, recent versions of Redhat's
iputils package include "arping", whose "-U" flag does just that:<br>
Which is, of course, exactly what you want to do when you switch a
host from being exposed to the Internet to behind Shorewall using proxy
ARP (or static NAT for that matter). Happily enough, recent versions of
Redhat's iputils package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I &lt;net if&gt; &lt;newly proxied
IP&gt;</b></font><br>
    <font color="#009900"><b>arping -U -I &lt;net if&gt; &lt;newly
proxied IP&gt;</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly to
gratuitous ARPs, but googling for "arping -U" seems to support the idea
that it works most of the time.<br>
Stevens goes on to mention that not all systems respond correctly
to gratuitous ARPs, but googling for "arping -U" seems to support the
idea that it works most of the time.<br>
<br>
</li>
<li>You can call your ISP and ask them to purge the stale ARP cache
entry but many either can't or won't purge individual entries.</li>
<li>You can call your ISP and ask them to purge the stale ARP
cache entry but many either can't or won't purge individual entries.</li>
</ol>
You can determine if your ISP's gateway ARP cache is stale using
ping and tcpdump. Suppose that we suspect that the gateway router has
a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump
as follows:</div>
ping and tcpdump. Suppose that we suspect that the gateway router has
a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump
as follows:</div>
<div align="left">
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
@ -1508,8 +1521,8 @@ as follows:</div>
different from the destination MAC address in the echo reply!! In this
case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
was the MAC address of DMZ 1. In other words, the gateway's ARP cache
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the
firewall's eth0.</p>
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with
the firewall's eth0.</p>
</div>
<div align="left">
@ -1520,9 +1533,9 @@ as follows:</div>
<p align="left">With static NAT, you assign local systems RFC 1918 addresses
then establish a one-to-one mapping between those addresses and public
IP addresses. For outgoing connections SNAT (Source Network Address
Translation) occurs and on incoming connections DNAT (Destination Network
Address Translation) occurs. Let's go back to our earlier example involving
your daughter's web server running on system Local 3.</p>
Translation) occurs and on incoming connections DNAT (Destination
Network Address Translation) occurs. Let's go back to our earlier example
involving your daughter's web server running on system Local 3.</p>
</div>
<div align="left">
@ -1533,8 +1546,8 @@ as follows:</div>
<div align="left">
<p align="left">Recall that in this setup, the local network is using SNAT
and is sharing the firewall external IP (192.0.2.176) for outbound connections.
This is done with the following entry in /etc/shorewall/masq:</p>
and is sharing the firewall external IP (192.0.2.176) for outbound
connections. This is done with the following entry in /etc/shorewall/masq:</p>
</div>
<div align="left">
@ -1562,8 +1575,8 @@ as follows:</div>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Suppose now that you have decided to give your daughter her
own IP address (192.0.2.179) for both inbound and outbound connections.
You would do that by adding an entry in <a
own IP address (192.0.2.179) for both inbound and outbound connections.
You would do that by adding an entry in <a
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</p>
</div>
@ -1601,7 +1614,7 @@ You would do that by adding an entry in <a
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Once the relationship between 192.0.2.179 and 192.168.201.4
is established by the nat file entry above, it is no longer appropriate
is established by the nat file entry above, it is no longer appropriate
to use a DNAT rule for you daughter's web server -- you would rather
just use an ACCEPT rule:</p>
</div>
@ -1642,13 +1655,13 @@ is established by the nat file entry above, it is no longer appropriate
<div align="left">
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    With the default policies, your local systems (Local 1-3) can
access any servers on the internet and the DMZ can't access any other
host (including the firewall). With the exception of <a
    With the default policies, your local systems (Local 1-3)
can access any servers on the internet and the DMZ can't access any
other host (including the firewall). With the exception of <a
href="#DNAT">DNAT rules</a> which cause address translation and allow
the translated connection request to pass through the firewall, the way
to allow connection requests through your firewall is to use ACCEPT
rules.</p>
the translated connection request to pass through the firewall, the
way to allow connection requests through your firewall is to use ACCEPT
rules.</p>
</div>
<div align="left">
@ -1945,12 +1958,12 @@ subnet needs to have it's own public IP.
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    If you haven't already, it would be a good idea to browse through
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a> just
to see if there is anything there that might be of interest. You might
also want to look at the other configuration files that you haven't
touched yet just to get a feel for the other things that Shorewall can
do.</p>
    If you haven't already, it would be a good idea to browse
through <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>
just to see if there is anything there that might be of interest. You
might also want to look at the other configuration files that you
haven't touched yet just to get a feel for the other things that Shorewall
can do.</p>
</div>
<div align="left">
@ -2001,9 +2014,9 @@ do.</p>
<div align="left">
<p align="left">The setup described here requires that your network interfaces
be brought up before Shorewall can start. This opens a short window
during which you have no firewall protection. If you replace 'detect'
with the actual broadcast addresses in the entries above, you can bring
up Shorewall before you bring up your network interfaces.</p>
during which you have no firewall protection. If you replace 'detect'
with the actual broadcast addresses in the entries above, you can bring
up Shorewall before you bring up your network interfaces.</p>
</div>
<div align="left">
@ -2351,8 +2364,8 @@ servers. You can combine the two into a single BIND 9 server using <i>Views.
<p align="left">Suppose that your domain is foobar.net and you want the two
DMZ systems named www.foobar.net and mail.foobar.net and you want the
three local systems named "winken.foobar.net, blinken.foobar.net and
nod.foobar.net. You want your firewall to be known as firewall.foobar.net
externally and it's interface to the local network to be know as gateway.foobar.net
nod.foobar.net. You want your firewall to be known as firewall.foobar.net
externally and it's interface to the local network to be know as gateway.foobar.net
and its interface to the dmz as dmz.foobar.net. Let's have the DNS server
on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
</div>
@ -2492,7 +2505,8 @@ externally and it's interface to the local network to be know as gateway.foo
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Edit the /etc/shorewall/routestopped file and configure those
systems that you want to be able to access the firewall when it is stopped.</p>
systems that you want to be able to access the firewall when it is
stopped.</p>
</div>
<div align="left">
@ -2506,7 +2520,7 @@ externally and it's interface to the local network to be know as gateway.foo
try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 2/21/2003 - <a
<p align="left"><font size="2">Last updated 3/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
@ -2519,5 +2533,7 @@ externally and it's interface to the local network to be know as gateway.foo
<br>
<br>
<br>
<br>
<br>
</body>
</html>

326
STABLE/documentation/sourceforge_index.htm
View File

@ -122,8 +122,8 @@
<p>The Shoreline Firewall, more commonly known as  "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables)
based firewall that can be used on a dedicated firewall system,
a multi-function gateway/router/server or on a standalone
based firewall that can be used on a dedicated firewall
system, a multi-function gateway/router/server or on a standalone
GNU/Linux system.</p>
@ -140,9 +140,9 @@
<p>This program is free software; you can redistribute it and/or modify
it under the
terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</a> as published by the Free Software
Foundation.<br>
terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</a> as published by the Free
Software Foundation.<br>
<br>
@ -150,15 +150,15 @@ terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
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>
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
to the Free Software Foundation, Inc., 675
Mass Ave, Cambridge, MA 02139, USA</p>
@ -191,7 +191,7 @@ to the Free Software Foundation, Inc., 675
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques
Nilo and Eric Wolzak have a LEAF (router/firewall/gateway
Nilo and Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution
called <i>Bering</i> that features
Shorewall-1.3.14 and Kernel-2.4.20. You can find
@ -199,7 +199,7 @@ Nilo and Eric Wolzak have a LEAF (router/firewall/gatew
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.1!!! <br>
1.1!!! <br>
</b>
@ -222,255 +222,9 @@ Nilo and Eric Wolzak have a LEAF (router/firewall/gatew
<p><b>3/17/2003 - Shorewall 1.4.0  </b><b> </b><b><img
<p><b>3/24/2003 - Shorewall 1.4.1 </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
 </b><b> </b></p>
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. <br>
<br>
<b>IMPORTANT: Shorewall 1.4.0 requires</b> <b>the iproute package
('ip' utility).</b><br>
<br>
Function from 1.3 that has been omitted from this version
include:<br>
<ol>
<li>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.<br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
</li>
</ol>
Changes for 1.4 include:<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
<br>
</li>
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script, common functions file and version file
are now installed in /usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the
common chain by default.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>CONTINUE is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i>
now support the 'maclist' option.<br>
<br>
</li>
<li value="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:<br>
<br>
   a) You must be running kernel 2.4.20<br>
   b) You must have applied the patch in<br>
   http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
   c) You must have iptables 1.2.7a installed.<br>
<br>
</li>
<li>The /etc/shorewall/params file is now processed first so that
variables may be used in the /etc/shorewall/shorewall.conf file.<br>
<br>
</li>
<li value="10">Shorewall now gives a more helpful diagnostic when
the 'ipchains' compatibility kernel module is loaded and a 'shorewall start'
command is issued.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>Shorewall now ignores 'default' routes when detecting masq'd
networks.<br>
</li>
</ol>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top"></a>
<p><b>3/11/2003 - Shoreall 1.3.14a</b><b> </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
 </b></p>
<p>A roleup of the following bug fixes and other updates:</p>
<ul>
<li>There is an updated rfc1918 file that reflects the resent
allocation of 222.0.0.0/8 and 223.0.0.0/8. </li>
<li>The documentation for the routestopped file claimed that a comma-separated
list could appear in the second column while the code only supported a
single host or network address. </li>
<li>Log messages produced by 'logunclean' and 'dropunclean' were
not rate-limited. </li>
<li>802.11b devices with names of the form <i>wlan</i>&lt;n&gt;
don't support the 'maclist' interface option. </li>
<li>Log messages generated by RFC 1918 filtering are not rate limited. </li>
<li>The firewall fails to start in the case where you have "eth0
eth1" in /etc/shorewall/masq and the default route is through eth1
</li>
</ul>
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b></p>
<p>New features include</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>
<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>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form
$DEV.$VID (e.g., eth0.0)<br>
<br>
</li>
<li>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 <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<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>
 <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>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<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></pre>
<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>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<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]#</pre>
 <br>
   In this case, the second entry in /etc/shorewall/masq
is no longer required.<br>
 <br>
Example 3 -- What if your current configuration is like
this?<br>
 <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<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]#</pre>
 <br>
   In this case, you would want to change the entry in 
/etc/shorewall/masq to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
</li>
</ol>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0</b><b>
</b></p>
Webmin version 1.060 now has Shorewall support included
as standard. See <a href="http://www.webmin.com">http://www.webmin.com</a>
<b> </b>
@ -482,6 +236,7 @@ as standard. See <a href="http://www.webmin.com">http://www.webmin.
<ul>
@ -502,6 +257,50 @@ as standard. See <a href="http://www.webmin.com">http://www.webmin.
<p>This release follows up on 1.4.0. It corrects a problem introduced
in 1.4.0 and removes additional warts.<br>
<br>
<b>Problems Corrected:</b><br>
</p>
<ol>
<li>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.</li>
</ol>
<b>New Features:</b><br>
<blockquote>Note: In the list that follows, the term <i>group </i>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:<br>
<blockquote>eth0:0.0.0.0/0<br>
eth2:192.168.1.0/24<br>
eth3:192.0.2.123<br>
</blockquote>
You can use the "shorewall check" command to see the groups associated with
each of your zones.<br>
</blockquote>
<ol>
<li>Beginning with Shorewall 1.4.1, if a zone Z comprises more than
one group<i> </i>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.</li>
<li>Beginning with Shorewall 1.4.1, Shorewall will never create rules
to handle traffic from a group to itself.</li>
<li>A NONE policy is introduced in 1.4.1. When a policy of NONE is
specified from Z1 to Z2:</li>
</ol>
<ul>
<li>There may be no rules created that govern connections from Z1
to Z2.</li>
<li>Shorewall will not create any infrastructure to handle traffic
from Z1 to Z2.</li>
</ul>
See the <a href="upgrade_issues.htm">upgrade issues</a> for a discussion
of how these changes may affect your configuration.
<p><a href="News.htm">More News</a></p>
@ -559,6 +358,7 @@ as standard. See <a href="http://www.webmin.com">http://www.webmin.
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <br>
</td>
</tr>
@ -618,11 +418,11 @@ as standard. See <a href="http://www.webmin.com">http://www.webmin.
<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
<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
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></p>
href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
@ -633,6 +433,7 @@ Foundation.</font></a> Thanks!</font></p>
</tbody>
</table>
@ -640,10 +441,11 @@ Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 3/17/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 3/21/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
</body>
</html>

88
STABLE/documentation/support.htm
View File

@ -41,13 +41,13 @@
<h2>Before Reporting a Problem or Asking a Question<br>
</h2>
There are a number
of sources of Shorewall information. Please try these before you post.
of sources of Shorewall information. Please try these before you post.
<ul>
<li>More than half of the questions posted
on the support list have answers directly accessible from the <a
href="shorewall_quickstart_guide.htm#Documentation">Documentation Index</a><br>
on the support list have answers directly accessible from the
<a href="shorewall_quickstart_guide.htm#Documentation">Documentation Index</a><br>
</li>
<li> The <a
href="FAQ.htm">FAQ</a> has solutions to more than 20 common problems.
@ -113,8 +113,8 @@ of sources of Shorewall information. Please try these before you post.
<ul>
<li>Please remember we only know what is posted
in your message. Do not leave out any information that appears to
be correct, or was mentioned in a previous post. There have been
in your message. Do not leave out any information that appears
to be correct, or was mentioned in a previous post. There have been
countless posts by people who were sure that some part of their
configuration was correct when it actually contained a small error.
We tend to be skeptics where detail is lacking.<br>
@ -122,17 +122,17 @@ countless posts by people who were sure that some part of their
</li>
<li>Please keep in mind that you're asking for
<strong>free</strong> technical support. Any help we offer
is an act of generosity, not an obligation. Try to make it easy
is an act of generosity, not an obligation. Try to make it easy
for us to help you. Follow good, courteous practices in writing
and formatting your e-mail. Provide details that we need if you expect
good answers. <em>Exact quoting </em> of error messages, log entries,
command output, and other output is better than a paraphrase or summary.<br>
<br>
</li>
<li> Please don't
describe your environment and then ask us to send you
<li> Please
don't describe your environment and then ask us to send you
custom configuration files. We're here to answer your
questions but we can't do your job for you.<br>
questions but we can't do your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong>
@ -144,7 +144,8 @@ questions but we can't do your job for you.<br>
<ul>
<li>the exact version of Shorewall you are running.<br>
<li>the exact version of Shorewall you are
running.<br>
<br>
<b><font color="#009900">shorewall version</font><br>
</b> <br>
@ -189,7 +190,7 @@ questions but we can't do your job for you.<br>
<ul>
<li>If your kernel is modularized, the exact
output from<br>
output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
<br>
@ -202,9 +203,8 @@ output from<br>
Guides, please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using
the Mandrake installation of Shorewall, please say so.</b><br>
<br>
<li><b>If you are running Shorewall under Mandrake
using the Mandrake installation of Shorewall, please say so.</b><br>
</li>
@ -213,10 +213,10 @@ output from<br>
</ul>
<ul>
<li><b>NEVER </b>include the output of "<b><font
color="#009900">iptables -L</font></b>". Instead,<font
color="#ff0000"><u><i><big> <b>if you are having connection problems of
any kind then:</b></big></i></u></font><br>
<ul>
<li><font color="#ff0000"><u><i><big><b>If you are having connection
problems of any kind then:</b></big></i></u></font><br>
<br>
1. <b><font color="#009900">/sbin/shorewall/reset</font></b><br>
<br>
@ -227,18 +227,19 @@ output from<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
</ul>
<li>As a general
matter, please <strong>do not edit the diagnostic information</strong>
in an attempt to conceal your IP address, netmask, nameserver addresses,
domain name, etc. These aren't secrets, and concealing them often
misleads us (and 80% of the time, a hacker could derive them anyway
from information contained in the SMTP headers of your post).<br>
in an attempt to conceal your IP address, netmask, nameserver
addresses, domain name, etc. These aren't secrets, and concealing
them often misleads us (and 80% of the time, a hacker could derive them
anyway from information contained in the SMTP headers of your post).<br>
<br>
<strong></strong></li>
<li>Do you see any "Shorewall" messages ("<b><font
color="#009900">/sbin/shorewall show log</font></b>") when
you exercise the function that is giving you problems? If so, include
the message(s) in your post along with a copy of your /etc/shorewall/interfaces
you exercise the function that is giving you problems? If so,
include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
file.<br>
<br>
</li>
@ -281,13 +282,13 @@ plagiarized from the excellent LEAF document by <i>Ray</i> <em>Olszewski</e
<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 whose MTAs are bouncing
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 <i>(expletive 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.<br>
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.<br>
</blockquote>
@ -300,34 +301,37 @@ from outgoing posts.<br>
style="font-weight: 400;">please post your question or problem
to the <a href="mailto:leaf-user@lists.sourceforge.net">LEAF
Users mailing list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft Multi
Network Firewall (MNF) and you have not purchased an MNF license
from MandrakeSoft then you can post non MNF-specific Shorewall questions
to the </b><a href="mailto:shorewall-users@lists.shorewall.net">Shorewall
users mailing list</a>. <b>Do not expect to get free MNF support
on the list or forum.</b><br>
<b>If you run Shorewall under MandrakeSoft
Multi Network Firewall (MNF) and you have not purchased an MNF
license from MandrakeSoft then you can post non MNF-specific Shorewall
questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a> or to the <a
href="http://www.developercube.com/forum/index.php?c=8">Shorewall Support
Forum</a>. <b>Do not expect to get free MNF support on the list or forum.</b><br>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a>.</p>
list</a> or to the <a
href="http://www.developercube.com/forum/index.php?c=8">Shorewall Support
Forum</a>.<br>
To Subscribe to the mailing list go to <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.<br>
</p>
</blockquote>
<p>To Subscribe to the mailing list go to <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.<br>
</p>
<p>For information on other Shorewall mailing lists, go to <a
href="http://lists.shorewall.net/mailing_list.htm">http://lists.shorewall.net/mailing_list.htm</a><br>
</p>
<p align="left"><font size="2">Last Updated 3/14/2003 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 3/17/2003 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
@ -335,5 +339,7 @@ on the list or forum.</b><br>
</p>
<br>
<br>
<br>
<br>
</body>
</html>

94
STABLE/documentation/traffic_shaping.htm
View File

@ -32,7 +32,8 @@
<p align="left">Shorewall has limited support for traffic shaping/control.
In order to use traffic shaping under Shorewall, it is essential that
you get a copy of the <a href="http://ds9a.nl/lartc">Linux Advanced Routing
and Shaping HOWTO</a>, version 0.3.0 or later.</p>
and Shaping HOWTO</a>, version 0.3.0 or later. It is also necessary
to be running Linux Kernel 2.4.18 or later.</p>
<p align="left">Shorewall traffic shaping support consists of the following:</p>
@ -40,8 +41,8 @@
<li>A new <b>TC_ENABLED</b> parameter in /etc/shorewall.conf.
Traffic Shaping also requires that you enable packet mangling.</li>
<li>A new <b>CLEAR_TC </b>parameter in /etc/shorewall.conf (Added
in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes),
the setting of this variable determines whether Shorewall clears the traffic
in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes),
the setting of this variable determines whether Shorewall clears the traffic
shaping configuration during Shorewall [re]start and Shorewall stop. <br>
</li>
<li><b>/etc/shorewall/tcrules</b> - A file where you can
@ -54,13 +55,13 @@ the setting of this variable determines whether Shorewall clears the traffic
I have provided a <a
href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a> that does
table-driven CBQ shaping but if you read the traffic shaping sections
of the HOWTO mentioned above, you can probably code your own faster
than you can learn how to use my sample. I personally use <a
href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall
since HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
HTB is a standard part of the kernel but iproute2 must be patched in
order to use it.<br>
of the HOWTO mentioned above, you can probably code your own
faster than you can learn how to use my sample. I personally use
<a href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall
since HTB is a lot simpler and better-documented than CBQ. As of
2.4.20, HTB is a standard part of the kernel but iproute2 must be patched
in order to use it.<br>
<br>
In tcstart, when you want to run the 'tc' utility, use
the run_tc function supplied by shorewall if you want tc errors
@ -69,13 +70,13 @@ since HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
You can generally use off-the-shelf traffic shaping scripts by
simply copying them to /etc/shorewall/tcstart. I use <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (HTB version)
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart
and modified it according to the Wonder Shaper README). <b>WARNING: </b>If
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and
modified it according to the Wonder Shaper README). <b>WARNING: </b>If
you use use Masquerading or SNAT (i.e., you only have one external IP address)
then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb]
script won't work. Traffic shaping occurs after SNAT has already been
applied so when traffic shaping happens, all outbound traffic will have
as a source address the IP addresss of your firewall's external interface.<br>
script won't work. Traffic shaping occurs after SNAT has already been applied
so when traffic shaping happens, all outbound traffic will have as a source
address the IP addresss of your firewall's external interface.<br>
</li>
<li><b>/etc/shorewall/tcclear</b> - A user-supplied file
that is sourced by Shorewall when it is clearing traffic shaping.
@ -84,8 +85,8 @@ as a source address the IP addresss of your firewall's external interface.<b
</ul>
Shorewall allows you to start traffic shaping when Shorewall itself
starts or it allows you to bring up traffic shaping when you bring up your
interfaces.<br>
starts or it allows you to bring up traffic shaping when you bring up
your interfaces.<br>
<br>
To start traffic shaping when Shorewall starts:<br>
@ -100,9 +101,9 @@ mark packets using entries in /etc/shorewall/tcrules.</li>
</ol>
To start traffic shaping when you bring up your network interfaces,
you will have to arrange for your traffic shaping configuration script to
be run at that time. How you do that is distribution dependent and will not
be covered here. You then should:<br>
you will have to arrange for your traffic shaping configuration script
to be run at that time. How you do that is distribution dependent and will
not be covered here. You then should:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=No</li>
@ -130,28 +131,28 @@ be covered here. You then should:<br>
<p align="left">Normally, packet marking occurs in the PREROUTING chain before
any address rewriting takes place. This makes it impossible to mark inbound
packets based on their destination address when SNAT or Masquerading
are being used. Beginning with Shorewall 1.3.12, you can cause packet
marking to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN
option in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
packets based on their destination address when SNAT or Masquerading are
being used. Beginning with Shorewall 1.3.12, you can cause packet marking
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option
in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
</p>
<p align="left">Columns in the file are as follows:</p>
<ul>
<li>MARK - Specifies the mark value is to be assigned in
case of a match. This is an integer in the range 1-255. Beginning
with Shorewall version 1.3.14, this 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 <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<li>MARK - Specifies the mark value is to be assigned
in case of a match. This is an integer in the range 1-255. Beginning
with Shorewall version 1.3.14, this 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 <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<br>
Example - 5<br>
</li>
<li>SOURCE - The source of the packet. If the packet originates
on the firewall, place "fw" in this column. Otherwise, this is a
comma-separated list of interface names, IP addresses, MAC addresses
on the firewall, place "fw" in this column. Otherwise, this is
a comma-separated list of interface names, IP addresses, MAC addresses
in <a href="Documentation.htm#MAC">Shorewall Format</a> and/or Subnets.<br>
<br>
Examples<br>
@ -161,12 +162,12 @@ of the MARK_IN_FORWARD_CHAIN option in <a href="Documentation.htm#Conf">shorewa
<li>DEST -- Destination of the packet. Comma-separated
list of IP addresses and/or subnets.<br>
</li>
<li>PROTO - Protocol - Must be the name of a protocol from
/etc/protocol, a number or "all"<br>
<li>PROTO - Protocol - Must be the name of a protocol
from /etc/protocol, a number or "all"<br>
</li>
<li>PORT(S) - Destination Ports. A comma-separated list
of Port names (from /etc/services), port numbers or port ranges (e.g.,
21:22); if the protocol is "icmp", this column is interpreted
of Port names (from /etc/services), port numbers or port ranges
(e.g., 21:22); if the protocol is "icmp", this column is interpreted
as the destination icmp type(s).<br>
</li>
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client.
@ -177,8 +178,8 @@ as the destination icmp type(s).<br>
<p align="left">Example 1 - All packets arriving on eth1 should be marked
with 1. All packets arriving on eth2 and eth3 should be marked with
2. All packets originating on the firewall itself should be marked with
3.</p>
2. All packets originating on the firewall itself should be marked
with 3.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
@ -233,8 +234,8 @@ as the destination icmp type(s).<br>
</table>
<p align="left">Example 2 - All GRE (protocol 47) packets not originating
on the firewall and destined for 155.186.235.151 should be marked with
12.</p>
on the firewall and destined for 155.186.235.151 should be marked
with 12.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
@ -316,17 +317,17 @@ see why I wanted shaping of this type.<br>
<ol>
<li>I wanted to allow up to 140kbits/second for traffic outbound
from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic
can use all available bandwidth if there is no traffic from the local
systems or from my laptop or firewall).</li>
from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ
traffic can use all available bandwidth if there is no traffic from the
local systems or from my laptop or firewall).</li>
<li>My laptop and local systems could use up to 224kbits/second.</li>
<li>My firewall could use up to 20kbits/second.</li>
</ol>
You see <a href="myfiles.htm">the rest of my Shorewall configuration</a>
to see how this fit in. <br>
to see how this fit in. <br>
<p><font size="2">Last Updated 3/5/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last Updated 3/19/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
@ -335,5 +336,6 @@ to see how this fit in. <br>
<br>
<br>
<br>
<br>
</body>
</html>

309
STABLE/documentation/upgrade_issues.htm
View File

@ -11,6 +11,7 @@
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
@ -22,6 +23,7 @@
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
</td>
</tr>
@ -29,67 +31,154 @@
</tbody>
</table>
<p>For upgrade instructions see the <a
href="Install.htm">Install/Upgrade page</a>.</p>
href="Install.htm">Install/Upgrade page</a>.<br>
</p>
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you are
currently running. <br>
</p>
<h3> </h3>
<h3>Version &gt;= 1.4.1</h3>
In the description that follows, the term <i>group </i>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:<br>
<blockquote>eth0:0.0.0.0/0<br>
eth2:192.168.1.0/24<br>
eth3:192.0.2.123<br>
</blockquote>
You can use the "shorewall check" command to see the groups associated with
each of your zones.<br>
<br>
<ul>
<li>Beginning with Version 1.4.1, traffic between groups in the same
zone is accepted by default. Previously, traffic from a zone to itself was
treated just like any other traffic; any matching rules were applied followed
by enforcement of the appropriate policy. With 1.4.1 and later versions,
unless you have explicit rules for traffic from Z to Z or you have an explicit
Z to Z policy (where "Z" is some zone) then traffic between the groups in
zone Z will be accepted. If you do have one or more explicit rules for Z
to Z or if you have an explicit Z to Z policy then the behavior is as it
was in prior versions.</li>
</ul>
<blockquote>
<ol>
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic between
two interfaces to the same zone, that policy can be removed and traffic
between the interfaces will traverse fewer rules than previously.</li>
<li>If you have a Z Z DROP or Z Z REJECT policy or you have Z-&gt;Z
rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that has
"all" in either the SOURCE or DESTINATION column) to prevent traffic between
two interfaces to a zone Z and you have no rules for Z-&gt;Z then you should
add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
</ol>
</blockquote>
<ul>
<li>Beginning with Version 1.4.1, Shorewall will never create rules to
deal with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between two
subnetworks on the same interface then either:</li>
</ul>
<blockquote>
<ol>
<li>The subnetworks must be in different zones; or</li>
<li>You must use the /etc/shorewall/hosts file to define the subnetworks
as two groups in a single zone.</li>
</ol>
</blockquote>
Example 1 -- Two zones:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/policy<br><br>z1 z2 ACCEPT<br>z2 z1 ACCEPT<br><br>/etc/shorewall/interfaces<br><br>- eth1 192.168.1.255,192.168.2.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.0/24<br>z2 eth1:192.168.2.0/24<br></pre>
</blockquote>
Example 2 -- One zone:
<blockquote>
<pre><br>/etc/shorewall/zones<br><br>z Zone The Zone<br><br>/etc/shorewall/interfaces<br><br>- eth1 192.168.1.255,192.168.2.255<br><br>/etc/shorewall/hosts<br><br>z eth1:192.168.1.0/24<br>z eth1:192.168.2.0/24<br></pre>
</blockquote>
Note that in the second example, we don't need any policy since z-&gt;z
traffic is accepted by default. The second technique is preferable if you
want unlimited access between the two subnetworks.<br>
<br>
Sometimes, you want two separate zones on one interface but you don't want
Shorewall to set up any infrastructure to handle traffic between them. <br>
<br>
Example:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going to be involved
in any traffic between these two zones. Beginning with Shorewall 1.4.1, you
can prevent Shorewall from setting up any infrastructure to handle traffic
between z1 and z2 by using the new NONE policy:<br>
<blockquote>
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
</blockquote>
Note that NONE policies are generally used in pairs unless there is asymetric
routing where only the traffic on one direction flows through the firewall
and you are using a NONE polciy in the other direction. 
<h3>Version &gt;= 1.4.0</h3>
<b>IMPORTANT: Shorewall &gt;=1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<b>IMPORTANT: Shorewall &gt;=1.4.0 </b><b>requires</b> <b>the iproute
package ('ip' utility).</b><br>
<br>
<b>Note: </b>Unfortunately, some distributions call this package iproute2
which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm (rpm -Uvh
--nodeps &lt;shorewall rpm&gt;).<br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options are
no longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
ICMP echo-request (ping) packets are treated just like any other connection
request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt; in
/etc/shorewall/interfaces now generate a Shorewall error at startup (they
always have produced warnings in iptables).</li>
<li>The <b>noping </b>and <b>forwardping</b> interface options
are no longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
ICMP echo-request (ping) packets are treated just like any other connection
request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents
are determined by BOTH the interfaces and hosts files when there are entries
for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts file
has been eliminated; use entries in the routestopped file instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are not dropped by default;
there is no need for your own /etc/shorewall/common file simply to avoid
logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file have been
moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include it
from /etc/shorewall/icmpdef, you will need to modify that file.</li>
<li value="8">The 'multi' interface option is no longer supported.  Shorewall
will generate rules for sending packets back out the same interface that
they arrived on in two cases:</li>
</ul>
<ul>
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents
are determined by BOTH the interfaces and hosts files when there are entries
for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts
file has been eliminated; use entries in the routestopped file instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf is no
longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped by default;
there is no need for your own /etc/shorewall/common file simply to avoid
logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file have
been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include
it from /etc/shorewall/icmpdef, you will need to modify that file.</li>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or from
the destination zone. An explicit policy names both zones and does not use
the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.</li>
</ul>
<li>If you followed the advice in FAQ #2 and call find_interface_address
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</li>
</ul>
@ -98,6 +187,33 @@ in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</ul>
<h3>Version 1.4.0</h3>
<ul>
<li value="8">The 'multi' interface option is no longer supported.  Shorewall
will generate rules for sending packets back out the same interface that
they arrived on in two cases:</li>
</ul>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or from
the destination zone. An explicit policy names both zones and does not
use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.</li>
</ul>
</blockquote>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13" height="13">
     Beginning in version 1.3.14, Shorewall treats entries in <a
@ -106,22 +222,22 @@ in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
<b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST subnet on the
interface (as shown by "ip addr show <i>interface</i>") and would masquerade
traffic from that subnet. Any other subnets that routed through eth1 needed
their own entry in /etc/shorewall/masq to be masqueraded or to have SNAT
applied.</li>
<li>Prior to 1.3.14, Shorewall would detect the FIRST subnet
on the interface (as shown by "ip addr show <i>interface</i>") and would
masquerade traffic from that subnet. Any other subnets that routed through
eth1 needed their own entry in /etc/shorewall/masq to be masqueraded
or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the firewall's
routing table to determine ALL subnets routed through the named interface.
Traffic originating in ANY of those subnets is masqueraded or has SNAT
applied.</li>
applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq with an interface
name in the SUBNET (second) column; and</li>
<li>You have one or more entries in /etc/shorewall/masq with
an interface name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
@ -135,7 +251,8 @@ applied.</li>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is like this?<br>
<b>Example 2</b>-- What if your current configuration is like
this?<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [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]#</pre>
@ -145,17 +262,18 @@ applied.</li>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13" height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request (ping)
handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be used
(If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes
is assumed). I don't plan on supporting the old handling indefinitely so
I urge current users to migrate to using the new handling as soon as possible.
See the <a href="ping.html">'Ping' handling documentation</a> for details.<br>
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be
used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the
old handling indefinitely so I urge current users to migrate to using
the new handling as soon as possible. See the <a href="ping.html">'Ping'
handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading
to version 1.3.10, you will need to use the '--force' option:<br>
to version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
@ -164,24 +282,24 @@ to version 1.3.10, you will need to use the '--force' option:<br>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file, your application
will need to be changed to reflect this change of location.<br>
If you have an application that uses functions from that file, your
application will need to be changed to reflect this change of location.<br>
<h3>Version &gt;= 1.3.8</h3>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
versions &gt;= 1.3.8. Beginning with version
1.3.8, you must set NEWNOTSYN=Yes in
your /etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following rules
in their /etc/shorewall/icmpdef file (creating
this file if necessary):</p>
will need to include the following
rules in their /etc/shorewall/icmpdef
file (creating this file if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
@ -196,25 +314,25 @@ If you have an application that uses functions from that file, your applicat
<ol>
<li>Be sure you have a backup
-- you will need to transcribe any Shorewall
configuration changes that you have
made to the new configuration.</li>
-- you will need to transcribe any
Shorewall configuration changes that
you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering floppy
with the later one. If you did not obtain
the later version from Jacques's site,
see additional instructions below.</li>
package provided on the Bering floppy
with the later one. If you did not
obtain the later version from Jacques's
site, see additional instructions below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not forget
to backup root.lrp !</li>
to backup root.lrp !</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a href="two-interface.htm">instructions
for setting up a two-interface firewall</a> plus you also need to add
the following two Bering-specific rules to /etc/shorewall/rules:</p>
for setting up a two-interface firewall</a> plus you also need
to add the following two Bering-specific rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
@ -224,8 +342,8 @@ to backup root.lrp !</li>
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
your firewall setup slightly under Shorewall versions
1.3.6 and 1.3.7</p>
<ol>
<li>
@ -233,10 +351,11 @@ to backup root.lrp !</li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn -j RETURN
# So that the connection tracking table can be rebuilt<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can be
rebuilt<br>
                                    # from non-SYN
packets after takeover.<br>
packets after takeover.<br>
 </font> </p>
</li>
<li>
@ -244,9 +363,9 @@ packets after takeover.<br>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common -p tcp
--tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild
connection<br>
<font face="Courier">run_iptables -A common -p
tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks to
rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
@ -291,11 +410,11 @@ connection<br>
<p align="left">The functions and versions files together with the
'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those applications
should be modified accordingly.</p>
If you have applications that access these files, those
applications should be modified accordingly.</p>
<p><font size="2"> Last updated 3/6/2003 -
<a href="support.htm">Tom Eastep</a></font> </p>
<p><font size="2"> Last updated 3/18/2003 -
<a href="support.htm">Tom Eastep</a></font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
@ -303,9 +422,5 @@ connection<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

2
STABLE/fallback.sh
View File

@ -28,7 +28,7 @@
# shown below. Simply run this script to revert to your prior version of
# Shoreline Firewall.
VERSION=1.4.0
VERSION=1.4.1
usage() # $1 = exit status
{

45
STABLE/firewall
View File

@ -672,6 +672,7 @@ validate_policy()
print_policy() # $1 = source zone, $2 = destination zone
{
[ $command != check ] || \
[ $1 = $2 ] || \
[ $1 = all ] || \
[ $2 = all ] || \
echo " Policy for $1 to $2 is $policy"
@ -708,7 +709,7 @@ validate_policy()
esac
case $policy in
ACCEPT|REJECT|DROP|CONTINUE)
ACCEPT|REJECT|DROP|CONTINUE|NONE)
;;
*)
startup_error "Invalid policy $policy"
@ -728,7 +729,7 @@ validate_policy()
chain=${client}2${server}
all_policy_chains="$all_policy_chains $chain"
[ $policy = NONE ] || all_policy_chains="$all_policy_chains $chain"
eval ${chain}_is_policy=Yes
eval ${chain}_policy=$policy
@ -743,6 +744,7 @@ validate_policy()
if [ -z "$pc" ]; then
eval ${zone}2${zone1}_policychain=$chain
eval ${zone}2${zone1}_policy=$policy
print_policy $zone $zone1
fi
done
@ -753,6 +755,7 @@ validate_policy()
if [ -z "$pc" ]; then
eval ${zone}2${server}_policychain=$chain
eval ${zone}2${server}_policy=$policy
print_policy $zone $server
fi
done
@ -763,6 +766,7 @@ validate_policy()
if [ -z "$pc" ]; then
eval ${client}2${zone}_policychain=$chain
eval ${client}2${zone}_policy=$policy
print_policy $client $zone
fi
done
@ -1438,7 +1442,7 @@ delete_nat() {
#
setup_ecn() # $1 = file name
{
local interfaces
local interfaces=""
local hosts
local h
@ -2151,7 +2155,7 @@ process_rule() # $1 = target
else
serverport=
[ -z "$serverzone" -o -z "$servers" ] && \
startup_error "Empty destination zone or qualifier: rule \"$rule\""
fatal_error "Empty destination zone or qualifier: rule \"$rule\""
fi
fi
@ -2165,6 +2169,11 @@ process_rule() # $1 = target
chain=${source}2${dest}
eval policy=\$${chain}_policy
[ $policy = NONE ] && \
fatal_error "Rules may not override a NONE policy: rule \"$rule\""
[ $command = check ] || ensurechain $chain
if [ "x$chain" = x${FW}2${FW} ]; then
@ -2683,6 +2692,8 @@ rules_chain() # $1 = source zone, $2 = destination zone
havechain $chain && { echo $chain; return; }
[ "$1" = "$2" ] && { echo ACCEPT; return; }
eval chain=\$${chain}_policychain
[ -n "$chain" ] && { echo $chain; return; }
@ -3670,41 +3681,27 @@ activate_rules()
done
for zone1 in $zones; do
eval policy=\$${zone}2${zone1}_policy
[ "$policy" = NONE ] && continue
eval dest_hosts=\$${zone1}_hosts
chain="`rules_chain $zone $zone1`"
echo "$zone $zone1 $chain" >> ${STATEDIR}/chains
if havechain ${zone}2${zone1} || havechain ${zone1}2${zone}; then
have_canonical=Yes
else
have_canonical=
fi
for host in $source_hosts; do
interface=${host%:*}
subnet=${host#*:}
chain1=`forward_chain $interface`
if [ -n "$have_canonical" ]; then
bounce=yes
else
case $interface in
*+*)
bounce=yes
;;
*)
bounce=
;;
esac
fi
for host1 in $dest_hosts; do
interface1=${host1%:*}
subnet1=${host1#*:}
if [ $interface != $interface1 -o -n "$bounce" ]; then
if [ "$host" != "$host1" ]; then
run_iptables -A $chain1 -s $subnet -o $interface1 -d $subnet1 -j $chain
fi
done

15
STABLE/hosts
View File

@ -1,10 +1,17 @@
#
# Shorewall 1.4 - /etc/shorewall/hosts
#
# WARNING: 90% of Shorewall users don't need to add entries to this
# file and 80% of those who try to add such entries get it
# wrong. Unless you are ABSOLUTELY SURE that you need entries
# in this file, don't touch it!
# THERE ARE TWO CASES WHERE YOU NEED THIS FILE:
#
# 1) YOU HAVE MULTIPLE NETWORKS IN THE SAME ZONE CONNECTED TO
# A SINGLE INTERFACE AND YOU WANT THE SHOREWALL BOX TO ROUTE
# BETWEEN THESE NETWORKS.
#
# 2) YOU HAVE MORE THAN ONE ZONE CONNECTED THROUGH A SINGLE
# INTERFACE.
#
# IF YOU DON'T HAVE EITHER OF THESE SITUATIONS THEN DON'T TOUCH
# THIS FILE.
#
# This file is used to define zones in terms of subnets and/or
# individual IP addresses. Most simple setups don't need to

2
STABLE/install.sh
View File

@ -54,7 +54,7 @@
# /etc/rc.d/rc.local file is modified to start the firewall.
#
VERSION=1.4.0
VERSION=1.4.1
usage() # $1 = exit status
{

21
STABLE/policy
View File

@ -22,7 +22,26 @@
# Shorewall will not start!
#
# POLICY Policy if no match from the rules file is found. Must
# be "ACCEPT", "DROP", "REJECT" or "CONTINUE"
# be "ACCEPT", "DROP", "REJECT", "CONTINUE" or "NONE".
#
# ACCEPT - Accept the connection
# DROP - Ignore the connection request
# REJECT - For TCP, send RST. For all other, send
# "port unreachable" ICMP.
# CONTINUE - Pass the connection request past
# any other rules that it might also
# match (where the source or destination
# zone in those rules is a superset of
# the SOURCE or DEST in this policy).
# NONE - Assume that there will never be any
# packets from this SOURCE
# to this DEST. Shorewall will not set up
# any infrastructure to handle such
# packets and you may not have any rules
# with this SOURCE and DEST in the
# /etc/shorewall/rules file. If such a
# packet _is_ received, the result is
# undefined.
#
# LOG LEVEL If supplied, each connection handled under the default
# POLICY is logged at that level. If not supplied, no

99
STABLE/releasenotes.txt
View File

@ -1,94 +1,19 @@
This is a major release of Shorewall.
This is a minor release of Shorewall.
Function from 1.3 that has been omitted from this version includes:
This release introduces incompatibilities with prior releases. See
http://www.shorewall.net/upgrade_issues.htm.
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.
Changes are:
2) Interface names of the form <device>:<integer> in
/etc/shorewall/interfaces now generate an error.
a) There is now a new NONE policy specifiable in
/etc/shorewall/policy. This policy will cause Shorewall to assume that
there will never be any traffic between the source and destination
zones.
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) 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) The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
accepted.
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) The 'multi' interface option is no longer supported. Shorewall will
generate rules for sending packets back out the same interface
that they arrived on in two cases:
a) There is an _explicit_ policy for the source zone to the
destination zone. An explicit policy names both zones and does not
use the 'all' reserved word.
b) There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all'
reserved word. Exception: If the source and the destination are
the same zone then the rule must be explicit - it must name the zone
in both the SOURCE and DESTINATION columns.
Changes for 1.4 include:
1) shorewall.conf has been completely reorganized into logical
sections.
2) LOG is now a valid action for a rule (/etc/shorewall/rules).
3) The firewall script and version file are now installed in
/usr/share/shorewall.
4. Late arriving DNS replies are now silently dropped in the common
chain by default.
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) CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
7) 802.11b devices with names of the form wlan<n> now support the
'maclist' option.
8) IMPORTANT: Shorewall now REQUIRES the iproute package ('ip'
utility).
9) 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.
10) The /etc/shorewall/params file is now processed first so that
variables may be used in the /etc/shorewall/shorewall.conf file.
11) Packets with state INVALID are now silently dropped.
12) Shorewall now gives a more helpful diagnostic when the 'ipchains'
compatibility kernel module is loaded and a 'shorewall start'
command is issued.
13) 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.
14) Shorewall now ignores 'default' routes when detecting masq'd
networks.
b) Shorewall no longer creates rules to govern traffic from an
interface:subnet to itself.
c) Intra-zone traffic is always accepted now (exception is (b)
above).. Intrazone policies and rules are no longer allowed.

4
STABLE/rules
View File

@ -15,7 +15,8 @@
# Columns are:
#
#
# ACTION ACCEPT, DROP, REJECT, DNAT or REDIRECT
# ACTION ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE
# or LOG.
#
# ACCEPT -- allow the connection request
# DROP -- ignore the request
@ -39,6 +40,7 @@
# connection request will be passed
# to the rules defined for that
# (those) zone(s).
# LOG -- Simply log the packet and continue.
#
# May optionally be followed by ":" and a syslog log
# level (e.g, REJECT:info). This causes the packet to be

4
STABLE/shorewall.spec
View File

@ -1,5 +1,5 @@
%define name shorewall
%define version 1.4.0
%define version 1.4.1
%define release 1
%define prefix /usr
@ -105,6 +105,8 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
* Fri Mar 21 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.1-1
* Mon Mar 17 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.0-1
* Fri Mar 07 2003 Tom Eastep <tom@shorewall.net>

2
STABLE/uninstall.sh
View File

@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Seattle Firewall
VERSION=1.4.0
VERSION=1.4.1
usage() # $1 = exit status
{

656
Shorewall-docs/FAQ.htm
View File

File diff suppressed because it is too large Load Diff

168
Shorewall-docs/Shorewall_and_Aliased_Interfaces.html
View File

@ -30,39 +30,41 @@
<h2>Background</h2>
The traditional net-tools contain a program called <i>ifconfig</i> which
is used to configure network devices. ifconfig introduced the concept of
<i>aliased </i>or <i>virtial </i>interfaces. These virtual interfaces have
names of the form <i>interface</i>:<i>integer </i>(e.g., eth0:0) and ifconfig
treats them more or less like real interfaces.<br>
<i>aliased </i>or <i>virtial </i>interfaces. These virtual interfaces have
names of the form <i>interface</i>:<i>integer </i>(e.g., eth0:0) and ifconfig
treats them more or less like real interfaces.<br>
<br>
Example:<br>
<pre>[root@gateway root]# ifconfig eth0:0<br>eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55<br> inet addr:206.124.146.178 Bcast:206.124.146.255 Mask:255.255.255.0<br> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br> Interrupt:11 Base address:0x2000<br>[root@gateway root]# <br></pre>
The ifconfig utility is being gradually phased out in favor of the <i>ip</i>
utility which is part of the <i>iproute </i>package. The ip utility does
not use the concept of aliases or virtual interfaces but rather treats additional
addresses on an interface as addresses. The ip utility does provide for interaction
with ifconfig in that it allows addresses to be <i>labeled.</i> <br>
not use the concept of aliases or virtual interfaces but rather treats additional
addresses on an interface as objects. The ip utility does provide for interaction
with ifconfig in that it allows addresses to be <i>labeled </i>and labels
may take the form of ipconfig virtual interfaces.<br>
<br>
Example:<br>
<br>
<pre>[root@gateway root]# ip addr show dev eth0<br>2: eth0: &lt;BROADCAST,MULTICAST,UP&gt; mtu 1500 qdisc htb qlen 100<br> link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff<br> inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0<br> inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0<br>[root@gateway root]# <br></pre>
Note that one <u>cannot</u> type "ip addr show dev eth0:0"<br>
Note that one <u>cannot</u> type "ip addr show dev eth0:0" because "eth0:0"
is a label for a particular address rather than a device name.<br>
<pre>[root@gateway root]# ip addr show dev eth0:0<br>Device "eth0:0" does not exist.<br>[root@gateway root]#<br></pre>
The iptables program doesn't support virtual interfaces in either it's
"-i" or "-o" command options; as a consequence, Shorewall does not allow
them to be used in the /etc/shorewall/interfaces file.<br>
"-i" or "-o" command options; as a consequence, Shorewall does not allow
them to be used in the /etc/shorewall/interfaces file.<br>
<br>
<h2>So how do I handle more than one address on an interface?</h2>
Depends on what you are trying to do with the interfaces. In the sub-sections
that follow, we'll take a look at common scenarios.<br>
The answer depends on what you are trying to do with the interfaces.
In the sub-sections that follow, we'll take a look at common scenarios.<br>
<h3>Separate Rules</h3>
If you need to make a rule for traffic to/from the firewall itself only
apply to a particular IP address, simply qualify the $FW zone with the IP
address.<br>
If you need to make a rule for traffic to/from the firewall itself that
only applies to a particular IP address, simply qualify the $FW zone with
the IP address.<br>
<br>
Example (allow SSH from net to eth0:0 above):<br>
<br>
@ -110,8 +112,9 @@ address.<br>
<h3>DNAT</h3>
Suppose that I had set up eth0:0 as above and I wanted to port forward
from that virtual interface to a web server running in my local zone at 192.168.1.3.
That is accomplised by a single rule in the /etc/shorewall/rules file:<br>
from that virtual interface to a web server running in my local zone at
192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules
file:<br>
<br>
<blockquote>
@ -157,7 +160,7 @@ from that virtual interface to a web server running in my local zone at 192.168
<h3>SNAT</h3>
If you wanted to use eth0:0 as the IP address for outbound connections
from your local zone (eth1), then in /etc/shorewall/masq:<br>
from your local zone (eth1), then in /etc/shorewall/masq:<br>
<br>
<blockquote>
@ -185,11 +188,11 @@ from your local zone (eth1), then in /etc/shorewall/masq:<br>
<br>
</blockquote>
Shorewall can create the alias (additional address) for you if you set
ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
@ -254,11 +257,11 @@ column as follows:<br>
<br>
</blockquote>
Shorewall can create the alias (additional address) for you if you set
ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_IP_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with Shorewall
1.3.14, Shorewall can actually create the "label" (virtual interface) so
that you can see the created address using ifconfig. In addition to setting
ADD_IP_ALIASES=Yes, you specify the virtual interface name in the INTERFACE
column as follows:<br>
<br>
<blockquote>
@ -294,9 +297,10 @@ column as follows:<br>
<br>
</blockquote>
In either case, to create rules that pertain only to this NAT pair, you
simply qualify the local zone with the internal IP address.<br>
simply qualify the local zone with the internal IP address.<br>
<br>
Example: You want to allow SSH from the net to 206.124.146.178 a.k.a. 192.168.1.3.<br>
Example: You want to allow SSH from the net to 206.124.146.178 a.k.a.
192.168.1.3.<br>
<br>
<blockquote>
@ -343,18 +347,86 @@ simply qualify the local zone with the internal IP address.<br>
<h3>MULTIPLE SUBNETS</h3>
Sometimes multiple IP addresses are used because there are multiple subnetworks
configured on a LAN segment. This technique does not provide for any security
between the subnetworks if the users of the systems have administrative privileges
because in that case, the users can simply manipulate their system's routing
table to bypass your firewall/router. Nevertheless, there are cases where
you simply want to consider the LAN segment itself as a zone and allow your
firewall/router to route between the two subnetworks.<br>
between the subnetworks if the users of the systems have administrative
privileges because in that case, the users can simply manipulate their system's
routing table to bypass your firewall/router. Nevertheless, there are cases
where you simply want to consider the LAN segment itself as a zone and allow
your firewall/router to route between the two subnetworks.<br>
<br>
Example 1: &nbsp;Local interface eth1 interfaces to 192.168.1.0/24 and
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and eth1:0
is 192.168.20.254. You want to simply route all requests between the two
subnetworks.<br>
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and eth1:0
is 192.168.20.254. You want to simply route all requests between the two
subnetworks.<br>
<h4>If you are running Shorewall 1.4.1 or Later</h4>
In /etc/shorewall/interfaces:<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ZONE<br>
</b></td>
<td valign="top"><b>INTERFACE<br>
</b></td>
<td valign="top"><b>BROADCAST<br>
</b></td>
<td valign="top"><b>OPTIONS<br>
</b></td>
</tr>
<tr>
<td valign="top">-<br>
</td>
<td valign="top">eth1<br>
</td>
<td valign="top">192.168.1.255,192.168.20.255<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
In /etc/shorewall/interfaces:<br>
</blockquote>
In /etc/shorewall/hosts:<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ZONE<br>
</b></td>
<td valign="top"><b>HOSTS<br>
</b></td>
<td valign="top"><b>OPTIONS<br>
</b></td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">eth0:192.168.1.0/24<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">eth0:192.168.20.0/24<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall
1.4.1 and later releases default to allowing intra-zone traffic.<br>
<h4>If you are running Shorewall 1.4.0 or earlier<br>
</h4>
In /etc/shorewall/interfaces:<br>
<br>
<blockquote>
@ -385,8 +457,8 @@ subnetworks.<br>
</table>
<br>
</blockquote>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must specify
the <b>multi</b> option.<br>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must
specify the <b>multi</b> option.<br>
<br>
In /etc/shorewall/policy:<br>
<br>
@ -425,9 +497,8 @@ subnetworks.<br>
</blockquote>
Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and 192.168.20.0/24.
The primary IP address of eth1 is 192.168.1.254 and eth1:0 is 192.168.20.254.
You want to make these subnetworks into separate zones and control the
access between them (the users of the systems do not have administrative
privileges).<br>
You want to make these subnetworks into separate zones and control the access
between them (the users of the systems do not have administrative privileges).<br>
<br>
In /etc/shorewall/zones:<br>
<br>
@ -495,8 +566,8 @@ privileges).<br>
</table>
<br>
</blockquote>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must specify
the <b>multi</b> option.<br>
Note 1: If you are running Shorewall 1.3.10 or earlier then you must
specify the <b>multi</b> option.<br>
<br>
In /etc/shorewall/hosts:<br>
@ -532,11 +603,11 @@ privileges).<br>
</table>
<br>
</blockquote>
In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic that
you want to permit.<br>
In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic
that you want to permit.<br>
<br>
<p align="left"><font size="2">Last Updated 3/5/2003 A - <a
<p align="left"><font size="2">Last Updated 3/22/2003 A - <a
href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
@ -545,5 +616,6 @@ privileges).<br>
</p>
<br>
<br>
<br>
</body>
</html>

89
Shorewall-docs/seattlefirewall_index.htm
View File

@ -55,11 +55,11 @@
alt="(Shorewall Logo)" align="right" vspace="4">
</a></h1>
<small><small><small><small><a
href="http://www.shorewall.net" target="_top"> </a></small></small></small></small><big></big>
href="http://www.shorewall.net" target="_top"> </a></small></small></small></small>
<div align="center">
<h1><font color="#ffffff">Shorewall 1.4</font><i><font
color="#ffffff"> <small><small><small>"iptables made easy" </small></small></small></font></i></h1>
color="#ffffff"> <small><small><small>"iptables made easy" </small></small></small></font></i></h1>
</div>
@ -80,8 +80,8 @@
<div align="center"><a href="1.3" target="_top"><font
color="#ffffff">Shorewall 1.3 Site is here</font></a>                  
            <br>
color="#ffffff">Shorewall 1.3 Site is here</font></a>
<br>
</div>
</td>
@ -93,6 +93,7 @@
</tbody>
</table>
@ -123,6 +124,7 @@
<h2 align="left">What is it?</h2>
@ -156,7 +158,7 @@ firewall that can be used on a dedicated firewall system, a multi-functio
<p>This program is free software; you can redistribute it and/or modify
it under the
terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</a> as published by the Free
Software Foundation.<br>
@ -166,8 +168,8 @@ Software Foundation.<br>
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>
A PARTICULAR PURPOSE. See the GNU General Public
License for more details.<br>
<br>
@ -206,8 +208,8 @@ Software Foundation.<br>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo
and Eric Wolzak have a LEAF (router/firewall/gateway
</a>Jacques
Nilo and Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution
called <i>Bering</i> that features
Shorewall-1.3.14 and Kernel-2.4.20. You can find
@ -232,46 +234,55 @@ Bering 1.1!!! </b><br>
<p><b>3/24/2003 - Shorewall 1.4.1 </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b><b> </b></p>
This release follows up on 1.4.0. It corrects a problem introduced in 1.4.0
and removes additional warts.<br>
</b></p>
This release follows up on 1.4.0. It corrects a problem introduced in 1.4.0
and removes additional warts.<br>
<br>
<b>Problems Corrected:</b><br>
<ol>
<li>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.</li>
<li>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.</li>
</ol>
<b>New Features:</b><br>
<blockquote>Note: In the list that follows, the term <i>group </i>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:<br>
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:<br>
<blockquote>eth0:0.0.0.0/0<br>
eth2:192.168.1.0/24<br>
eth3:192.0.2.123<br>
eth2:192.168.1.0/24<br>
eth3:192.0.2.123<br>
</blockquote>
You can use the "shorewall check" command to see the groups associated with
each of your zones.<br>
You can use the "shorewall check" command to see the groups associated
with each of your zones.<br>
</blockquote>
<ol>
<li>Beginning with Shorewall 1.4.1, if a zone Z comprises more than
one group<i> </i>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.</li>
<li>Beginning with Shorewall 1.4.1, Shorewall will never create rules
to handle traffic from a group to itself.</li>
<li>A NONE policy is introduced in 1.4.1. When a policy of NONE is
specified from Z1 to Z2:</li>
<li>Beginning with Shorewall 1.4.1, if a zone Z comprises more
than one group<i> </i>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.</li>
<li>Beginning with Shorewall 1.4.1, Shorewall will never create
rules to handle traffic from a group to itself.</li>
<li>A NONE policy is introduced in 1.4.1. When a policy of NONE
is specified from Z1 to Z2:</li>
</ol>
<ul>
<li>There may be no rules created that govern connections from Z1
to Z2.</li>
<li>There may be no rules created that govern connections from
Z1 to Z2.</li>
<li>Shorewall will not create any infrastructure to handle traffic
from Z1 to Z2.</li>
from Z1 to Z2.</li>
</ul>
See the <a href="upgrade_issues.htm">upgrade issues</a> for a discussion
of how these changes may affect your configuration.<br>
See the <a href="upgrade_issues.htm">upgrade issues</a> for a discussion
of how these changes may affect your configuration.<br>
<p><a href="News.htm">More News</a></p>
<h2><a name="Donations"></a>Donations</h2>
@ -280,8 +291,8 @@ of how these changes may affect your configuration.<br>
</td>
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <a
href="http://sourceforge.net">M</a></td>
bgcolor="#4b017c" valign="top" align="center"> <br>
</td>
</tr>
@ -339,6 +350,7 @@ of how these changes may affect your configuration.<br>
<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
@ -354,6 +366,7 @@ Children's Foundation.</font></a> Thanks!</font></p>
</tbody>
</table>
@ -367,5 +380,7 @@ Children's Foundation.</font></a> Thanks!</font></p>
</p>
<br>
<br>
<br>
</body>
</html>

131
Shorewall-docs/sourceforge_index.htm
View File

@ -1,29 +1,13 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<base target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
@ -95,49 +79,13 @@
<td width="90%">
<h2 align="left">What is it?</h2>
<p>The Shoreline Firewall, more commonly known as  "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables)
based firewall that can be used on a dedicated firewall
system, a multi-function gateway/router/server or on a standalone
GNU/Linux system.</p>
<p>This program is free software; you can redistribute it and/or modify
it under the
terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
@ -160,33 +108,7 @@ License for more details.<br>
along with this program; if not, write
to the Free Software Foundation, Inc., 675
Mass Ave, Cambridge, MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
@ -200,62 +122,11 @@ License for more details.<br>
<b>Congratulations
to Jacques and Eric on the recent release of Bering
1.1!!! <br>
</b>
<h2>News</h2>
<p><b>3/24/2003 - Shorewall 1.4.1 </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
 </b><b> </b></p>
<b> </b>
<ul>
</ul>
<20></b></p>
<p>This release follows up on 1.4.0. It corrects a problem introduced
in 1.4.0 and removes additional warts.<br>

148
Shorewall-docs/upgrade_issues.htm
View File

@ -38,35 +38,47 @@
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you are
currently running. <br>
currently running. <br>
</p>
<h3> </h3>
<h3>Version &gt;= 1.4.1</h3>
In the description that follows, the term <i>group </i>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:<br>
<blockquote>eth0:0.0.0.0/0<br>
eth2:192.168.1.0/24<br>
eth3:192.0.2.123<br>
</blockquote>
You can use the "shorewall check" command to see the groups associated with
each of your zones.<br>
<br>
<ul>
<li>Beginning with Version 1.4.1, intra-zone traffic is accepted by default.
Previously, traffic from a zone to itself was treated just like any other
traffic; any matching rules were applied followed by enforcement of the appropriate
policy. With 1.4.1 and later versions, unless you have explicit rules for
traffic from Z to Z or you have an explicit Z to Z policy (where "Z" is some
zone) then traffic within zone Z will be accepted. If you do have one or more
explicit rules for Z to Z or if you have an explicit Z to Z policy then the
behavior is as it was in prior versions.</li>
<li>Beginning with Version 1.4.1, traffic between groups in the same
zone is accepted by default. Previously, traffic from a zone to itself was
treated just like any other traffic; any matching rules were applied followed
by enforcement of the appropriate policy. With 1.4.1 and later versions,
unless you have explicit rules for traffic from Z to Z or you have an explicit
Z to Z policy (where "Z" is some zone) then traffic between the groups in
zone Z will be accepted. If you do have one or more explicit rules for Z
to Z or if you have an explicit Z to Z policy then the behavior is as it
was in prior versions.</li>
</ul>
<blockquote>
<ol>
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic between
two interfaces to the same zone, that policy can be removed and traffic between
the interfaces will traverse fewer rules than previously.</li>
two interfaces to the same zone, that policy can be removed and traffic
between the interfaces will traverse fewer rules than previously.</li>
<li>If you have a Z Z DROP or Z Z REJECT policy or you have Z-&gt;Z
rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that has "all"
in either the SOURCE or DESTINATION column) to prevent traffic between two
interfaces to a zone Z and you have no rules for Z-&gt;Z then you should
<li>If you are currently relying on a implicit policy (one that has
"all" in either the SOURCE or DESTINATION column) to prevent traffic between
two interfaces to a zone Z and you have no rules for Z-&gt;Z then you should
add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
@ -75,9 +87,9 @@ add an explicit DROP or REJECT policy for Z to Z.<br>
<ul>
<li>Beginning with Version 1.4.1, Shorewall will never create rules to
deal with traffic from a given <i>interface:subnetwork </i>back to itself.
The <i>multi</i> interface option is no longer available so if you want to
route traffic between two subnetworks on the same interface then either:</li>
deal with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between two
subnetworks on the same interface then either:</li>
</ul>
@ -85,38 +97,40 @@ route traffic between two subnetworks on the same interface then either:</li>
<ol>
<li>The subnetworks must be in different zones; or</li>
<li>You must use the /etc/shorewall/hosts file to define the subnetworks
in a single zone.</li>
as two groups in a single zone.</li>
</ol>
</blockquote>
Example 1 -- Two zones:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/policy<br><br>z1 z2 ACCEPT<br>z2 z1 ACCEPT<br><br>/etc/shorewall/interfaces<br><br>- eth1 192.168.1.255,192.168.2.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.0/24<br>z2 eth1:192.168.2.0/24<br></pre>
</blockquote>
Example 2 -- One zone:
</blockquote>
Example 2 -- One zone:
<blockquote>
<pre><br>/etc/shorewall/zones<br><br>z Zone The Zone<br><br>/etc/shorewall/interfaces<br><br>- eth1 192.168.1.255,192.168.2.255<br><br>/etc/shorewall/hosts<br><br>z eth1:192.168.1.0/24<br>z eth1:192.168.2.0/24<br></pre>
</blockquote>
Note that in the second example, we don't need any policy since z-&gt;z traffic
is accepted by default. The second technique is preferable if you want unlimited
access between the two subnetworks.<br>
<br>
Sometimes, you want two separate zones on one interface but you don't want
</blockquote>
Note that in the second example, we don't need any policy since z-&gt;z
traffic is accepted by default. The second technique is preferable if you
want unlimited access between the two subnetworks.<br>
<br>
Sometimes, you want two separate zones on one interface but you don't want
Shorewall to set up any infrastructure to handle traffic between them. <br>
<br>
Example:<br>
<br>
Example:<br>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going to be involved
Here, zone z1 is nested in zone z2 and the firewall is not going to be involved
in any traffic between these two zones. Beginning with Shorewall 1.4.1, you
can prevent Shorewall from setting up any infrastructure to handle traffic
between z1 and z2 by using the new NONE policy:<br>
<blockquote>
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
</blockquote>
Note that NONE policies are generally used in pairs unless there is asymetric
</blockquote>
Note that NONE policies are generally used in pairs unless there is asymetric
routing where only the traffic on one direction flows through the firewall
and you are using a NONE polciy in the other direction. 
<h3>Version &gt;= 1.4.0</h3>
@ -143,22 +157,22 @@ are no longer supported nor is the <b>FORWARDPING </b>option in shorewall.con
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
contents are determined by BOTH the interfaces and hosts files when there
are entries for the zone in both files.</li>
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents
are determined by BOTH the interfaces and hosts files when there are entries
for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts
file has been eliminated; use entries in the routestopped file instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf is no
longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.</li>
longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped by default;
there is no need for your own /etc/shorewall/common file simply to avoid
logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file have
been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include
it from /etc/shorewall/icmpdef, you will need to modify that file.</li>
it from /etc/shorewall/icmpdef, you will need to modify that file.</li>
<ul>
@ -185,14 +199,14 @@ it from /etc/shorewall/icmpdef, you will need to modify that file.</li>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or from
the destination zone. An explicit policy names both zones and does not use
the 'all' reserved word.</li>
the destination zone. An explicit policy names both zones and does not
use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all' reserved
or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.</li>
@ -204,15 +218,15 @@ DESTINATION columns.</li>
<img src="images/BD21298_3.gif" alt="" width="13" height="13">
     Beginning in version 1.3.14, Shorewall treats entries in <a
href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently. The change
involves entries with an <b>interface name</b> in the <b>SUBNET</b>
(second) <b>column</b>:<br>
involves entries with an <b>interface name</b> in the <b>SUBNET</b> (second)
<b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST subnet
on the interface (as shown by "ip addr show <i>interface</i>") and would
masquerade traffic from that subnet. Any other subnets that routed through
eth1 needed their own entry in /etc/shorewall/masq to be masqueraded or
to have SNAT applied.</li>
masquerade traffic from that subnet. Any other subnets that routed through
eth1 needed their own entry in /etc/shorewall/masq to be masqueraded
or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the firewall's
routing table to determine ALL subnets routed through the named interface.
Traffic originating in ANY of those subnets is masqueraded or has SNAT
@ -237,7 +251,8 @@ an interface name in the SUBNET (second) column; and</li>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is like this?<br>
<b>Example 2</b>-- What if your current configuration is like
this?<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [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]#</pre>
@ -249,12 +264,12 @@ an interface name in the SUBNET (second) column; and</li>
<img src="images/BD21298_3.gif" alt="" width="13" height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be used
(If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes
is assumed). I don't plan on supporting the old handling indefinitely
so I urge current users to migrate to using the new handling as soon as
possible. See the <a href="ping.html">'Ping' handling documentation</a>
for details.<br>
is used to specify that the old (pre-1.3.14) ping handling is to be
used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the
old handling indefinitely so I urge current users to migrate to using
the new handling as soon as possible. See the <a href="ping.html">'Ping'
handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading
@ -275,16 +290,16 @@ application will need to be changed to reflect this change of location.<br>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
versions &gt;= 1.3.8. Beginning with version
1.3.8, you must set NEWNOTSYN=Yes in
your /etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following rules
in their /etc/shorewall/icmpdef file
(creating this file if necessary):</p>
will need to include the following
rules in their /etc/shorewall/icmpdef
file (creating this file if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
@ -300,8 +315,8 @@ application will need to be changed to reflect this change of location.<br>
<ol>
<li>Be sure you have a backup
-- you will need to transcribe any
Shorewall configuration changes that
you have made to the new configuration.</li>
Shorewall configuration changes that
you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering floppy
with the later one. If you did not
@ -316,8 +331,8 @@ obtain the later version from Jacques's
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a href="two-interface.htm">instructions
for setting up a two-interface firewall</a> plus you also need to
add the following two Bering-specific rules to /etc/shorewall/rules:</p>
for setting up a two-interface firewall</a> plus you also need
to add the following two Bering-specific rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
@ -327,8 +342,8 @@ obtain the later version from Jacques's
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
your firewall setup slightly under Shorewall versions
1.3.6 and 1.3.7</p>
<ol>
<li>
@ -349,8 +364,8 @@ rebuilt<br>
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common -p
tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks
to rebuild connection<br>
tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks to
rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
@ -396,7 +411,7 @@ to rebuild connection<br>
<p align="left">The functions and versions files together with the
'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those
applications should be modified accordingly.</p>
applications should be modified accordingly.</p>
<p><font size="2"> Last updated 3/18/2003 -
<a href="support.htm">Tom Eastep</a></font> </p>
@ -406,5 +421,6 @@ applications should be modified accordingly.</p>
</p>
<br>
<br>
<br>
</body>
</html>