Update for Shorewall 2.2.0 Beta 4

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1756 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2004-11-19 17:58:59 +00:00
parent 60c9d48fda
commit 60c710d9f4
19 changed files with 345 additions and 173 deletions

View File

@ -111,18 +111,6 @@
# your kernel and iptables must include policy
# match support.
#
# Yes -- Only packets that will be encrypted using
# an ipsec policy will have their source
# address changed.
#
# No -- Only packets that will not be encrypted
# using an ipsec policy will have their
# source address changed.
#
# - or empty is the same as No providing that
# your kernel and iptables contain policy match
# support.
#
# Comma-separated list of options from the following.
# Only packets that will be encrypted via an SA that
# matches these options will have their source address

View File

@ -72,7 +72,7 @@
# DNAT:debug). This causes the packet to be
# logged at the specified level.
#
# If the ACTION names an action devined in
# If the ACTION names an action defined in
# /etc/shorewall/actions or in
# /usr/share/shorewall/actions.std then:
#

View File

@ -1,10 +1,11 @@
#
# Shorewall 2.2 /usr/share/shorewall/action.AllowNNTP
#
# This action accepts NNTP traffic (Usenet).
# This action accepts NNTP traffic (Usenet) and encrypted NNTP (NNTPS)
#
######################################################################################
#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
# PORT PORT(S) LIMIT GROUP
ACCEPT - - tcp 119
ACCEPT - - tcp 563
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

View File

@ -1,5 +1,5 @@
#
# Shorewall 2.0-- Bogons File
# Shorewall 2.2-- Bogons File
#
# /etc/shorewall/bogons
#
@ -48,7 +48,6 @@
42.0.0.0/8 logdrop # Reserved
49.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98
50.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98
58.0.0.0/7 logdrop # Reserved
73.0.0.0/8 logdrop # Reserved
74.0.0.0/7 logdrop # Reserved
76.0.0.0/6 logdrop # Reserved

View File

@ -1749,6 +1749,7 @@ setup_tunnels() # $1 = name of tunnels file
# Process the ipsec file
#
setup_ipsec() {
local zone
#
# Add a --set-mss rule to the passed chain
#
@ -6642,18 +6643,21 @@ add_to_zone() # $1 = <interface>[:<hosts>] $2 = zone
#
validate_interfaces_file
#
# Validate IPSec File
#
f=$(find_file ipsec)
if [ -f $f ]; then
progress_message "Processing $f..."
setup_ipsec $f
fi
#
# Validate Zone
#
zone=$2
validate_zone $zone || startup_error "Unknown zone: $zone"
f=$(find_file ipsec)
if [ -f $f ]; then
progress_message "Processing $f..."
setup_ipsec $f
fi
[ "$zone" = $FW ] && startup_error "Can't add $1 to firewall zone"
eval is_ipsec=\$${zone}_is_ipsec

View File

@ -1 +1 @@
2.2.0-Beta3
2.2.0-Beta4

View File

@ -5,7 +5,7 @@
<!--$Id$-->
<articleinfo>
<title>Shorewall 2.0 Reference</title>
<title>Shorewall 2.x Reference</title>
<authorgroup>
<author>
@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-10-25</pubdate>
<pubdate>2004-11-18</pubdate>
<copyright>
<year>2001-2004</year>
@ -181,6 +181,16 @@
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Ipsec">ipsec</link></term>
<listitem>
<para>a parameter file installed in <filename
class="directory">/etc/shorewall</filename> and used to describe
ipsec policies associated with zones.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Maclist">maclist</link></term>
@ -1625,7 +1635,11 @@ ACCEPT<emphasis role="bold">:info</emphasis> - - tc
<listitem>
<para>refers to a connection request from any host in the
specified subnet (example net:155.186.235.0/24).</para>
specified subnet (example net:155.186.235.0/24). Beginning
with Shorewall 2.1.0, IP address ranges of the form
&lt;<emphasis>first address</emphasis>&gt;-&lt;<emphasis>last
address</emphasis>&gt; may be specified. This requires that
your kernel and iptables have iprange match support.</para>
</listitem>
</varlistentry>
</variablelist>
@ -1674,7 +1688,7 @@ ACCEPT<emphasis role="bold">:info</emphasis> - - tc
</listitem>
</itemizedlist>
<para>Unlike in the SOURCE column, a range of IP addresses may be
<para>Like in the SOURCE column, a range of IP addresses may be
specified in the DEST column as &lt;<emphasis>first
address</emphasis>&gt;-&lt;<emphasis>last address</emphasis>&gt;.
When the ACTION is DNAT or DNAT-, connections will be assigned to
@ -2566,7 +2580,7 @@ eth0 eth1 206.124.146.176</programlisting>
</itemizedlist>
<para>Example: Using the default LOGFORMAT, the log prefix for
logging from the nat table's PREROUTING chain is: </para>
logging from the nat table's PREROUTING chain is:</para>
<programlisting>Shorewall:nat:PREROUTING</programlisting>
@ -2934,7 +2948,7 @@ eth0 eth1 206.124.146.176</programlisting>
enable martian logging for all interfaces, you may still enable it
for individual interfaces using the <emphasis
role="bold">logmartians</emphasis> interface option in <link
linkend="Interfaces">/etc/shorewall/interfaces</link>. </para>
linkend="Interfaces">/etc/shorewall/interfaces</link>.</para>
</listitem>
</varlistentry>

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-11-03</pubdate>
<pubdate>2004-11-18</pubdate>
<copyright>
<year>2001-2004</year>
@ -23,7 +23,7 @@
<holder>Thomas M. Eastep</holder>
</copyright>
<edition>2.2.0 Beta 2</edition>
<edition>2.2.0 Beta 4</edition>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
@ -275,6 +275,10 @@
<listitem>
<para><ulink url="Documentation.htm#Netmap">netmap</ulink></para>
</listitem>
<listitem>
<para><ulink url="Documentation.htm#Ipsec">ipsec</ulink></para>
</listitem>
</itemizedlist></para>
</listitem>

View File

@ -17,7 +17,7 @@
</author>
</authorgroup>
<pubdate>2004-11-05</pubdate>
<pubdate>2004-11-18</pubdate>
<copyright>
<year>2001-2004</year>
@ -1966,12 +1966,53 @@ REJECT fw net:216.239.39.99 all</programlisting>Given that
then be accurately parsed and decisions can be made based on the
result.</para>
</section>
<section id="faq42">
<title>(FAQ 42) How can I tell which features my kernel and iptables
support?</title>
<para>Answer: At a root prompt, enter the command <command>shorewall
check</command>. There is a section near the top of the resulting output
that gives you a synopsis of your kernel/iptables capabilities.</para>
<programlisting>gateway:/etc/shorewall # shorewall check
Loading /usr/share/shorewall/functions...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Notice: The 'check' command is unsupported and problem
reports complaining about errors that it didn't catch
will not be accepted
Shorewall has detected the following iptables/netfilter capabilities:
NAT: Available
Packet Mangling: Available
Multi-port Match: Available
Connection Tracking Match: Available
Packet Type Match: Not available
Policy Match: Available
Physdev Match: Available
IP range Match: Available
Verifying Configuration...
...</programlisting>
</section>
</section>
<appendix>
<title>Revision History</title>
<para><revhistory>
<revision>
<revnumber>1.38</revnumber>
<date>2004-11-18</date>
<authorinitials>TE</authorinitials>
<revremark>Added FAQ 42.</revremark>
</revision>
<revision>
<revnumber>1.37</revnumber>

View File

@ -13,7 +13,7 @@
<surname>Eastep</surname>
</author>
<pubdate>2004-07-10</pubdate>
<pubdate>2004-11-18</pubdate>
<copyright>
<year>2003-2004</year>
@ -27,14 +27,15 @@
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink type="" url="Copyright.htm">GNU Free Documentation License</ulink></quote>.</para>
<quote><ulink type="" url="Copyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Introduction</title>
<para>The information in this document applies only to 2.0.x releases of
<para>The information in this document applies only to 2.x releases of
Shorewall.</para>
<section>
@ -43,7 +44,8 @@
<itemizedlist>
<listitem>
<para><ulink url="http://www.netfilter.org">Netfilter</ulink> - the
packet filter facility built into the 2.4 and later Linux kernels.</para>
packet filter facility built into the 2.4 and later Linux
kernels.</para>
</listitem>
<listitem>
@ -65,19 +67,19 @@
<section>
<title>What is Shorewall?</title>
<para>The Shoreline Firewall, more commonly known as <quote>Shorewall</quote>,
is high-level tool for configuring Netfilter. You describe your
firewall/gateway requirements using entries in a set of configuration
files. Shorewall reads those configuration files and with the help of
the iptables utility, Shorewall configures Netfilter to match your
requirements. Shorewall can be used on a dedicated firewall system, a
multi-function gateway/router/server or on a standalone GNU/Linux
system. Shorewall does not use Netfilter&#39;s ipchains compatibility
mode and can thus take advantage of Netfilter&#39;s connection state
tracking capabilities.</para>
<para>The Shoreline Firewall, more commonly known as
<quote>Shorewall</quote>, is high-level tool for configuring Netfilter.
You describe your firewall/gateway requirements using entries in a set
of configuration files. Shorewall reads those configuration files and
with the help of the iptables utility, Shorewall configures Netfilter to
match your requirements. Shorewall can be used on a dedicated firewall
system, a multi-function gateway/router/server or on a standalone
GNU/Linux system. Shorewall does not use Netfilter's ipchains
compatibility mode and can thus take advantage of Netfilter's connection
state tracking capabilities.</para>
<para>Shorewall is not a daemon. Once Shorewall has configured
Netfilter, it&#39;s job is complete and there is no <quote>Shorewall
Netfilter, it's job is complete and there is no <quote>Shorewall
process</quote> left running in your system. The <ulink
url="starting_and_stopping_shorewall.htm">/sbin/shorewall program can be
used at any time to monitor the Netfilter firewall</ulink>.</para>
@ -92,54 +94,109 @@
setups, you will only need to deal with a few of them.</para>
<para>Shorewall views the network where it is running as being composed of
a set of zones. In the <ulink url="three-interface.htm">three-interface
sample configuration</ulink> for example, the following zone names are
used: <informaltable frame="all" pgwide="0"><tgroup align="left" cols="2"><thead
valign="middle"><row valign="middle"><entry align="left">Name</entry><entry
align="left">Description</entry></row></thead><tbody valign="middle"><row
valign="middle"><entry align="left"><varname>net</varname></entry><entry
align="left">The Internet</entry></row><row valign="middle"><entry
align="left"><varname>loc</varname></entry><entry align="left">Your Local
Network</entry></row><row valign="middle"><entry align="left"><varname>dmz</varname></entry><entry
align="left">Demilitarized Zone</entry></row></tbody></tgroup></informaltable>Zones
are defined in the <ulink url="Documentation.htm#Zones"><filename
a set of <firstterm>zones</firstterm>. In the <ulink
url="three-interface.htm">three-interface sample configuration</ulink> for
example, the following zone names are used: <informaltable frame="all"
pgwide="0">
<tgroup align="left" cols="2">
<thead valign="middle">
<row valign="middle">
<entry align="left">Name</entry>
<entry align="left">Description</entry>
</row>
</thead>
<tbody valign="middle">
<row valign="middle">
<entry align="left"><varname>net</varname></entry>
<entry align="left">The Internet</entry>
</row>
<row valign="middle">
<entry align="left"><varname>loc</varname></entry>
<entry align="left">Your Local Network</entry>
</row>
<row valign="middle">
<entry align="left"><varname>dmz</varname></entry>
<entry align="left">Demilitarized Zone</entry>
</row>
</tbody>
</tgroup>
</informaltable>Zones are defined in the <ulink
url="Documentation.htm#Zones"><filename
class="directory">/etc/shorewall/</filename><filename>zones</filename></ulink>
file.</para>
<para>Shorewall also recognizes the firewall system as its own zone - by
default, the firewall itself is known as <emphasis role="bold"><varname>fw</varname></emphasis>.</para>
default, the firewall itself is known as <emphasis
role="bold"><varname>fw</varname></emphasis>.</para>
<para>Rules about what traffic to allow and what traffic to deny are
expressed in terms of zones. <itemizedlist spacing="compact"><listitem><para>You
express your default policy for connections from one zone to another zone
in the <ulink url="Documentation.htm#Policy"><filename class="directory">/etc/shorewall/</filename><filename>policy</filename></ulink>
file. The choices for policy are:</para><itemizedlist><listitem><para>ACCEPT
- Accept the connection.</para></listitem><listitem><para>DROP - Ignore
the connection request.</para></listitem><listitem><para>REJECT - Return
an appropriate error to the connection request.</para></listitem></itemizedlist><para>Connection
request logging may be specified as part of a policy and it is
conventional to log DROP and REJECT policies.</para></listitem><listitem><para>You
define exceptions to those default policies in the <ulink
url="Documentation.htm#Rules"><filename class="directory">/etc/shorewall/</filename><filename>rules</filename></ulink>
file.</para></listitem><listitem><para>You only need concern yourself with
connection requests. You don&#39;t need to define rules for how traffic
that is part of an established connection is handled and in most cases you
don&#39;t have to worry about how related connections are handled (ICMP
error packets and <ulink url="FTP.html">related TCP connection requests
such as used by FTP</ulink>).</para></listitem></itemizedlist>For each
connection request entering the firewall, the request is first checked
against the <filename class="directory">/etc/shorewall/</filename><filename>rules</filename>
file. If no rule in that file matches the connection request then the
first policy in <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
that matches the request is applied. If there is a common action defined
for the policy in /etc/shorewall/actions (or <filename>/usr/share/shorewall/actions.std</filename>)
then that action is invoked before the policy is enforces. In the standard
Shorewall distribution, the DROP policy has a common action called
<emphasis role="bold">Drop</emphasis> and the REJECT policy has a common
action called <emphasis role="bold">Reject</emphasis>. Common actions are
used primarily to discard</para>
expressed in terms of zones. <itemizedlist spacing="compact">
<listitem>
<para>You express your default policy for connections from one zone
to another zone in the <ulink
url="Documentation.htm#Policy"><filename
class="directory">/etc/shorewall/</filename><filename>policy</filename></ulink>
file. The basic choices for policy are:</para>
<para>The <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
<itemizedlist>
<listitem>
<para>ACCEPT - Accept the connection.</para>
</listitem>
<listitem>
<para>DROP - Ignore the connection request.</para>
</listitem>
<listitem>
<para>REJECT - Return an appropriate error to the connection
request.</para>
</listitem>
</itemizedlist>
<para>Connection request logging may be specified as part of a
policy and it is conventional to log DROP and REJECT
policies.</para>
</listitem>
<listitem>
<para>You define exceptions to these default policies in the <ulink
url="Documentation.htm#Rules"><filename
class="directory">/etc/shorewall/</filename><filename>rules</filename></ulink>
file.</para>
</listitem>
<listitem>
<para>You only need concern yourself with connection requests. You
don't need to define rules for how traffic that is part of an
established connection is handled and in most cases you don't have
to worry about how related connections are handled (ICMP error
packets and <ulink url="FTP.html">related TCP connection requests
such as used by FTP</ulink>).</para>
</listitem>
</itemizedlist>For each connection request entering the firewall, the
request is first checked against the <filename
class="directory">/etc/shorewall/</filename><filename>rules</filename>
file. If no rule in that file matches the connection request then the
first policy in <filename
class="directory">/etc/shorewall/</filename><filename>policy</filename>
that matches the request is applied. If there is a common action defined
for the policy in /etc/shorewall/actions (or
<filename>/usr/share/shorewall/actions.std</filename>) then that action is
invoked before the policy is enforces. In the standard Shorewall
distribution, the DROP policy has a common action called <emphasis
role="bold">Drop</emphasis> and the REJECT policy has a common action
called <emphasis role="bold">Reject</emphasis>. Common actions are used
primarily to discard</para>
<para>The <filename
class="directory">/etc/shorewall/</filename><filename>policy</filename>
file included with the three-interface sample has the following policies:
<programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
@ -149,18 +206,34 @@ all all REJECT info</programlisting>In the three-interface
firewall system to have full access to servers on the internet, uncomment
that line. <programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
fw net ACCEPT</programlisting> The above policy will:
<itemizedlist><listitem><para>Allow all connection requests from your
local network to the internet</para></listitem><listitem><para>Drop
(ignore) all connection requests from the internet to your firewall or
local network; these ignored connection requests will be logged using the
<emphasis>info</emphasis> syslog priority (log level).</para></listitem><listitem><para>Optionally
accept all connection requests from the firewall to the internet (if you
uncomment the additional policy)</para></listitem><listitem><para>reject
all other connection requests; these rejected connection requests will be
logged using the <emphasis>info</emphasis> syslog priority (log level).</para></listitem></itemizedlist></para>
<itemizedlist>
<listitem>
<para>Allow all connection requests from your local network to the
internet</para>
</listitem>
<listitem>
<para>Drop (ignore) all connection requests from the internet to
your firewall or local network; these ignored connection requests
will be logged using the <emphasis>info</emphasis> syslog priority
(log level).</para>
</listitem>
<listitem>
<para>Optionally accept all connection requests from the firewall to
the internet (if you uncomment the additional policy)</para>
</listitem>
<listitem>
<para>reject all other connection requests; these rejected
connection requests will be logged using the
<emphasis>info</emphasis> syslog priority (log level).</para>
</listitem>
</itemizedlist></para>
<para>The simplest way to define a zone is to associate the zone with a
network interface using the <ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
network interface using the <ulink
url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
file. In the three-interface sample, the three zones are defined using
that file as follows:</para>
@ -194,16 +267,16 @@ ACCEPT net fw tcp 22</programlisting>
<listitem>
<para>The <ulink url="shorewall_quickstart_guide.htm">QuickStart
guildes</ulink> provide links to download pre-populated files for use
in common setups and the <ulink url="shorewall_setup_guide.htm">Shorewall
Setup Guide</ulink> shows you examples for use with other more complex
setups.</para>
in common setups and the <ulink
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink> shows
you examples for use with other more complex setups.</para>
</listitem>
<listitem>
<para>To keep your <ulink url="shorewall_logging.html">firewall log</ulink>
from filling up with useless noise, Shorewall provides <ulink
url="User_defined_Actions.html">common actions</ulink> that silently
discard or reject such noise before it can be logged. As with
<para>To keep your <ulink url="shorewall_logging.html">firewall
log</ulink> from filling up with useless noise, Shorewall provides
<ulink url="User_defined_Actions.html">common actions</ulink> that
silently discard or reject such noise before it can be logged. As with
everything in Shorewall, you can alter the behavior of these common
actions (or do away with them entirely) as you see fit.</para>
</listitem>
@ -214,9 +287,10 @@ ACCEPT net fw tcp 22</programlisting>
<title>License</title>
<para>This program is free software; you can redistribute it and/or modify
it under the terms of <ulink url="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</ulink> as published by the Free
Software Foundation.</para>
it under the terms of <ulink
url="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU General
Public License</ulink> as published by the Free Software
Foundation.</para>
<para>This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-08-10</pubdate>
<pubdate>2004-11-16</pubdate>
<copyright>
<year>2001-2004</year>
@ -29,7 +29,8 @@
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
@ -37,9 +38,9 @@
one network appear to be logically part of a different physical network
connected to the same router/firewall. Typically it allows us to hide a
machine with a public IP address on a private network behind a router, and
still have the machine appear to be on the public network &#34;in front
of&#34; the router. The router &#34;proxys&#34; ARP requests and all network
traffic to and from the hidden machine to make this fiction possible.</para>
still have the machine appear to be on the public network "in front of" the
router. The router "proxys" ARP requests and all network traffic to and from
the hidden machine to make this fiction possible.</para>
<para>Consider a router with two interface cards, one connected to a public
network PUBNET and one connected to a private network PRIVNET. We want to
@ -49,16 +50,16 @@
behind the router.</para>
<para>By enabling proxy ARP on the router, any machine on the PUBNET network
that issues an ARP &#34;who has&#34; request for the server&#39;s MAC
address will get a proxy ARP reply from the router containing the
router&#39;s MAC address. This tells machines on the PUBNET network that
they should be sending packets destined for the server via the router. The
router forwards the packets from the machines on the PUBNET network to the
server on the PRIVNET network.</para>
that issues an ARP "who has" request for the server's MAC address will get a
proxy ARP reply from the router containing the router's MAC address. This
tells machines on the PUBNET network that they should be sending packets
destined for the server via the router. The router forwards the packets from
the machines on the PUBNET network to the server on the PRIVNET
network.</para>
<para>Similarly, when the server on the PRIVNET network issues a &#34;who
has&#34; request for any machines on the PUBNET network, the router provides
its own MAC address via proxy ARP. This tells the server to send packets for
<para>Similarly, when the server on the PRIVNET network issues a "who has"
request for any machines on the PUBNET network, the router provides its own
MAC address via proxy ARP. This tells the server to send packets for
machines on the PUBNET network via the router. The router forwards the
packets from the server on the PRIVNET network to the machines on the PUBNET
network.</para>
@ -71,7 +72,8 @@
hidden behind the router.</para>
<para>Before you try to use this technique, I strongly recommend that you
read the <ulink url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink>.</para>
read the <ulink url="shorewall_setup_guide.htm">Shorewall Setup
Guide</ulink>.</para>
<section>
<title>Example</title>
@ -92,22 +94,22 @@
<para>Be sure that the internal systems (130.242.100.18 and 130.252.100.19
in the above example) are not included in any specification in
<filename>/etc/shorewall/masq</filename> or <filename>/etc/shorewall/nat</filename>.
</para>
<filename>/etc/shorewall/masq</filename> or
<filename>/etc/shorewall/nat</filename>.</para>
<note>
<para>I&#39;ve used an RFC1918 IP address for eth1 - that IP address is
<para>I've used an RFC1918 IP address for eth1 - that IP address is
largely irrelevant (see below).</para>
</note>
<para>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&#39;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. </para>
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.</para>
<warning>
<para>Do not add the Proxy ARP&#39;ed address(es) (130.252.100.18 and
<para>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.</para>
</warning>
@ -132,22 +134,45 @@
url="myfiles.htm">that I take with my DMZ</ulink>.</para>
<warning>
<para>Your distribution&#39;s network configuration GUI may not be
capable of configuring a device in this way. It may complain about the
duplicate address or it may configure the address incorrectly. Here is
what the above configuration should look like when viewed using
<command>ip</command> (the part of the output that is in <emphasis
role="bold">bold text</emphasis> is relevant):</para>
<para>Your distribution's network configuration GUI may not be capable
of configuring a device in this way. It may complain about the duplicate
address or it may configure the address incorrectly. Here is what the
above configuration should look like when viewed using
<command>ip</command> (the line "inet 130.252.100.17/32 scope global
eth1" is the most important):</para>
<programlisting>gateway:~# <command>ip addr ls eth1</command>
3: eth1: &#60;BROADCAST,MULTICAST,UP&#62; mtu 1500 qdisc pfifo_fast qlen 1000
3: eth1: &lt;BROADCAST,MULTICAST,UP&gt; mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:a0:cc:d1:db:12 brd ff:ff:ff:ff:ff:ff
<emphasis role="bold">inet 130.252.100.17/32 scope global eth1</emphasis>
gateway:~#</programlisting>
<para>Note in particular that there is no broadcast address. <ulink
url="myfiles.htm#Interfaces">Here is how I configure a device in this
way under Debian</ulink>.</para>
<para>Note in particular that there is no broadcast address. Here is an
<filename>ifcfg-eth-id-00:a0:cc:d1:db:12</filename> file from SuSE that
produces this result (Note: SuSE ties the configuration file to the card
by embedding the card's MAC address in the file name):</para>
<programlisting>BOOTPROTO='static'
BROADCAST='130.252.100.17'
IPADDR='130.252.100.17'
MTU=''
NETMASK='255.255.255.255'
NETWORK='130.252.100.17'
REMOTE_IPADDR=''
STARTMODE='onboot'
UNIQUE='8otl.IPwRm6bNMRD'
_nm_name='bus-pci-0000:00:04.0'</programlisting>
<para>Here is an excerpt from a Debian /etc/shorewall/interfaces file
that does the same thing:</para>
<programlisting>...
auto eth1
iface eth1 inet static
address 130.252.100.17
netmask 255.255.255.255
broadcast 0.0.0.0
...</programlisting>
</warning>
</section>
@ -163,11 +188,13 @@ gateway:~#</programlisting>
<orderedlist>
<listitem>
<para>A reading of <citetitle>TCP/IP Illustrated, Vol 1</citetitle> by
Stevens reveals<footnote><para>Courtesy of Bradey Honsinger</para></footnote>
that a <quote>gratuitous</quote> ARP packet should cause the ISP&#39;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&#39;t a duplicate...</para>
Stevens reveals<footnote>
<para>Courtesy of Bradey Honsinger</para>
</footnote> that a <quote>gratuitous</quote> 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...</para>
<blockquote>
<para>if the host sending the gratuitous ARP has just changed its
@ -179,15 +206,16 @@ gateway:~#</programlisting>
<para>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 one-to-one NAT for that matter). Happily enough, recent
versions of Redhat&#39;s iputils package include <quote>arping</quote>,
versions of Redhat's iputils package include <quote>arping</quote>,
whose <quote>-U</quote> flag does just that:</para>
<programlisting>arping -U -I &#60;<emphasis>net if</emphasis>&#62; &#60;<emphasis>newly proxied IP</emphasis>&#62;
<programlisting>arping -U -I &lt;<emphasis>net if</emphasis>&gt; &lt;<emphasis>newly proxied IP</emphasis>&gt;
arping -U -I eth0 66.58.99.83 # for example</programlisting>
<para>Stevens goes on to mention that not all systems respond
correctly to gratuitous ARPs, but googling for <quote>arping -U</quote>
seems to support the idea that it works most of the time.</para>
correctly to gratuitous ARPs, but googling for <quote>arping
-U</quote> seems to support the idea that it works most of the
time.</para>
<para>To use arping with Proxy ARP in the above example, you would
have to:</para>
@ -204,32 +232,32 @@ shorewall start</programlisting>
<listitem>
<para>You can call your ISP and ask them to purge the stale ARP cache
entry but many either can&#39;t or won&#39;t purge individual entries.</para>
entry but many either can't or won't purge individual entries.</para>
</listitem>
</orderedlist>
<para>You can determine if your ISP&#39;s gateway ARP cache is stale using
<para>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:</para>
<programlisting>tcpdump -nei eth0 icmp</programlisting>
<para>Now from 130.252.100.19, ping the ISP&#39;s gateway (which we will
<para>Now from 130.252.100.19, ping the ISP's gateway (which we will
assume is 130.252.100.254):</para>
<programlisting>ping 130.252.100.254</programlisting>
<para>We can now observe the tcpdump output:</para>
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 &#62; 130.252.100.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 &#62; 130.252.100.177 : icmp: echo reply</programlisting>
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 &gt; 130.252.100.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 &gt; 130.252.100.177 : icmp: echo reply</programlisting>
<para>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&#39;s eth0 NIC while
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&#39;s ARP cache still associates 130.252.100.19
with the NIC in that system rather than with the firewall&#39;s eth0.</para>
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.</para>
</section>
</article>

View File

@ -13,7 +13,7 @@
<surname>Eastep</surname>
</author>
<pubdate>2004-10-26</pubdate>
<pubdate>2004-11-14</pubdate>
<copyright>
<year>2003</year>
@ -91,8 +91,7 @@
<itemizedlist>
<listitem>
<para>Shorewall generally does not contain any support for Netfilter
<ulink
url="http://www.netfilter.org/documentation/pomlist/pom-summary.html">Patch-O-Matic-ng</ulink>
<ulink url="http://www.netfilter.org">Patch-O-Matic-ng</ulink>
features or any other features that require kernel patching --
Shorewall only supports features from released kernels except in
unusual cases.</para>

View File

@ -13,7 +13,7 @@
</author>
</authorgroup>
<pubdate>2004-10-25</pubdate>
<pubdate>2004-11-12</pubdate>
<copyright>
<year>2001-2004</year>
@ -69,11 +69,12 @@
<para><ulink
url="http://shorewall.net/pub/shorewall/errata/1.4.10/rfc1918">Here</ulink>
is the most up to date version of the <ulink
url="Documentation.htm#rfc1918">rfc1918 file</ulink>. This file only
applies to Shorewall version 2.0.0 and its bugfix updates. In Shorewall
2.0.1 and later releases, the <filename>bogons</filename> file lists IP
ranges that are reserved by the IANA and the <filename>rfc1918</filename>
file only lists those three ranges that are reserved by <ulink
url="Documentation.htm#rfc1918">rfc1918 file</ulink>. <emphasis
role="bold">This file only applies to Shorewall versions 1.4.* and 2.0.0
and its bugfix updates</emphasis>. In Shorewall 2.0.1 and later releases,
the <filename>bogons</filename> file lists IP ranges that are reserved by
the IANA and the <filename>rfc1918</filename> file only lists those three
ranges that are reserved by <ulink
url="shorewall_setup_guide.htm#RFC1918">RFC 1918</ulink>.</para>
</section>
@ -81,7 +82,7 @@
<title>Bogons File</title>
<para><ulink
url="http://shorewall.net/pub/shorewall/errata/2.0.8/bogons">Here</ulink>
url="http://shorewall.net/pub/shorewall/errata/2.0.10/bogons">Here</ulink>
is the most up to date version of the <ulink
url="Documentation.htm#Bogons">bogons file</ulink>.</para>
</section>

View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-10-24</pubdate>
<pubdate>2004-11-19</pubdate>
<copyright>
<year>2001-2004</year>
@ -162,6 +162,17 @@
<para>Zones are defined in the file <filename><ulink
url="Documentation.htm#Zones"><filename>/etc/shorewall/zones</filename></ulink></filename>.</para>
<important>
<para>Beginning with Shorewall 2.2.0, the
<filename>/etc/shorewall/zones</filename> file included in the release
is empty. You can create the above set of zones by copying and pasting
the following into the file:</para>
<programlisting>net Net Internet
loc Local Local networks
dmz DMZ Demilitarized zone</programlisting>
</important>
<para>Shorewall also recognizes the firewall system as its own zone - by
default, the firewall itself is known as <emphasis
role="bold">fw</emphasis> but that may be changed in the <ulink
@ -280,6 +291,12 @@ all all REJECT info</programlisting>
<para>At this point, edit your <filename>/etc/shorewall/policy
</filename>and make any changes that you wish.</para>
<important>
<para>Beginning with Shorewall 2.2.0, the released policy file is empty.
You can copy and paste the above entries to create a starting point from
which to customize your policies.</para>
</important>
</section>
<section id="Interfaces">

View File

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

View File

@ -22,7 +22,7 @@
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA
#
VERSION=2.2.0-Beta3
VERSION=2.2.0-Beta4
usage() # $1 = exit status
{

View File

@ -1,4 +1,4 @@
Shorewall 2.2.0-Beta3
Shorewall 2.2.0-Beta4
----------------------------------------------------------------------
Problems Corrected since 2.0.3

View File

@ -1,6 +1,6 @@
%define name shorewall
%define version 2.2.0
%define release 0Beta3
%define release 0Beta4
%define prefix /usr
Summary: Shoreline Firewall is an iptables-based firewall for Linux systems.
@ -137,6 +137,8 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
* Fri Nov 19 2004 Tom Eastep tom@shorewall.net
- Updated to 2.2.0-0Beta3
* Tue Nov 09 2004 Tom Eastep tom@shorewall.net
- Updated to 2.2.0-0Beta3
* Tue Nov 02 2004 Tom Eastep tom@shorewall.net

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=2.2.0-Beta3
VERSION=2.2.0-Beta4
usage() # $1 = exit status
{