extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-22 22:30:58 +01:00
Code Issues Packages Projects Releases Wiki Activity

More doc updates

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2142 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-05-20 14:04:11 +00:00
parent 2cdb52aa50
commit bb6f10818e
6 changed files with 255 additions and 94 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Shorewall-docs2/FAQ.xml
View File

@ -17,7 +17,7 @@
</author>
</authorgroup>
<pubdate>2005-05-10</pubdate>
<pubdate>2005-05-18</pubdate>
<copyright>
<year>2001-2005</year>
@ -1263,7 +1263,8 @@ LOGBURST=""</programlisting>
<para>Anyone with two Internet connections MUST read and understand
<ulink url="Shorewall_and_Routing.html">this article on Shorewall and
Routing</ulink>. If you don't, you will be completely lost trying to
make this work.</para>
make this work. And that article should be all that you need if you
are running Shorewall 2.3.2 or later.</para>
</important>
<para>Setting this up in Shorewall is easy; setting up the routing is a
@ -2249,4 +2250,4 @@ Verifying Configuration...
...</programlisting>
</section>
</section>
</article>
</article>

2
Shorewall-docs2/ProxyARP.xml
View File

@ -80,7 +80,7 @@
<para>The following figure represents a Proxy ARP environment.</para>
<graphic fileref="images/proxyarp.png" />
<graphic align="center" fileref="images/proxyarp.png" />
<para>Proxy ARP can be used to make the systems with addresses
130.252.100.18 and 130.252.100.19 appear to be on the upper

76
Shorewall-docs2/Shorewall_Squid_Usage.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-05-16</pubdate>
<pubdate>2005-05-19</pubdate>
<copyright>
<year>2003-2005</year>
@ -173,7 +173,7 @@ REDIRECT loc 3128 tcp www - !206.124.146.
a web server running on 192.168.1.3. It is assumed that web access is
already enabled from the local zone to the internet.</para>
<para>If you are running a Shorewall version earlier than 2.3.3 OR your
<para>If you are running a Shorewall version earlier than 2.3.2 OR your
kernel and/or iptables do not have <ulink
url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
support</ulink> then:</para>
@ -211,30 +211,29 @@ fi</command></programlisting>
<programlisting><command>run_and_save_command "/etc/shorewall/addroutes"</command></programlisting>
</listitem>
</orderedlist>
<para>If you are running Shorewall 2.3.2 or later:</para>
<orderedlist>
<listitem>
<para>Add this entry to your /etc/shorewall/providers file.</para>
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
Squid 1 202 - eth1 192.168.1.3 -</programlisting>
</listitem>
</orderedlist>
<para>Regardless of your Shorewall version, you need the
following:</para>
<orderedlist>
<listitem>
<para>In <filename>/etc/shorewall/start</filename> add:</para>
<programlisting><command>iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</command></programlisting>
</listitem>
</orderedlist>
<para>If you are running Shorewall 2.3.3 or later and your kernel and
iptables have <ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE
target support</ulink> then add this entry to
/etc/shorewall/routes:</para>
<blockquote>
<programlisting>#SOURCE DEST PROTO PORT(S) SOURCE TEST INTERFACE GATEWAY
# PORT(S)
eth1 0.0.0.0/0 tcp 80 - - eth1 192.168.1.3</programlisting>
</blockquote>
<para>Regardless of your Shorewall version or your kernel and iptables
<ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
support</ulink>, you need the following:</para>
<orderedlist>
<listitem>
<para>In
<filename><filename>/etc/shorewall/interfaces</filename></filename>:</para>
@ -285,7 +284,7 @@ chkconfig --level 35 iptables on</command></programlisting>
192.0.2.177. You want to run both a web server and Squid on that system.
Your DMZ interface is eth1 and your local interface is eth2.</para>
<para>If you are running a Shorewall version earlier than 2.3.3 OR your
<para>If you are running a Shorewall version earlier than 2.3.2 OR your
kernel and/or iptables do not have <ulink
url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
support</ulink> then:</para>
@ -323,7 +322,27 @@ fi</command></programlisting>
<programlisting><command>run_and_save_command "/etc/shorewall/addroutes"</command></programlisting>
</listitem>
</orderedlist>
<para>If you are running Shorewall 2.3.2 or later:</para>
<orderedlist>
<listitem>
<para>Add this entry in
<filename>/etc/shorewall/providers</filename>:</para>
</listitem>
</orderedlist>
<blockquote>
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
Squid 1 202 - eth1 192.0.2.177 -
</programlisting>
</blockquote>
<para>Regardless of your Shorewall version, you need the
following:</para>
<orderedlist>
<listitem>
<para>Do <emphasis role="bold">one</emphasis> of the
following:</para>
@ -354,24 +373,7 @@ fi</command></programlisting>
</listitem>
</orderedlist>
</listitem>
</orderedlist>
<para>If you are running Shorewall 2.3.3 or later and your kernel and
iptables have <ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE
target support</ulink> then add this entry to
/etc/shorewall/routes:</para>
<blockquote>
<programlisting>#SOURCE DEST PROTO PORT(S) SOURCE TEST INTERFACE GATEWAY
# PORT(S)
eth2 0.0.0.0/0 tcp 80 - - eth1 192.0.2.177</programlisting>
</blockquote>
<para>Regardless of your Shorewall version or your kernel and iptables
<ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
support</ulink>, you need the following:</para>
<orderedlist>
<listitem>
<para>In <filename>/etc/shorewall/rules</filename>, you will
need:</para>

60
Shorewall-docs2/Shorewall_and_Routing.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-05-18</pubdate>
<pubdate>2005-05-19</pubdate>
<copyright>
<year>2005</year>
@ -178,7 +178,7 @@
configure your alternate routing table at boot time and that <emphasis
role="bold">other than as described in the previous section, there is no
connection between Shorewall and routing when using Shorewall versions
prior to 2.3.3.</emphasis></para>
prior to 2.3.2.</emphasis></para>
</section>
<section>
@ -206,19 +206,21 @@
</section>
<section>
<title>Multiple Internet Connection Support in Shorewall 2.3.3 and
<title>Multiple Internet Connection Support in Shorewall 2.3.2 and
Later</title>
<para>Beginning with Shorewall 2.3.3, support is included for multiple
<para>Beginning with Shorewall 2.3.2, support is included for multiple
internet connections.</para>
<section>
<title>Overview</title>
<para>Let's assume that a firewall is connected via two separate
ethernet interfaces to two different ISP as in the following
ethernet interfaces to two different ISPs as in the following
diagram.</para>
<graphic fileref="images/TwoISPs.png" />
<itemizedlist>
<listitem>
<para>eth0 connects to ISP1. The IP address of eth0 is
@ -272,8 +274,21 @@
</itemizedlist>
</caution>
<para>Use of this feature requires that your kernel and iptables support
CONNMARK target and conntrack match as well as extended MARK support. It
does NOT require the ROUTE target extension.</para>
<warning>
<para>The current version of iptables (1.3.1) is broken with respect
to CONNMARK and iptables-save/iptables-restore. This means that if you
configure multiple ISPs, <command>shorewall restore</command> will
fail. You must patch your iptables using the patch at <ulink
url="http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff">http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff</ulink>.</para>
</warning>
<para>The <filename>/etc/shorewall/providers</filename> file can also be
used in other routing senarios. See the Squid documentation for an
used in other routing senarios. See the <ulink
url="Shorewall_Squid_Usage.html">Squid documentation</ulink> for an
example.</para>
</section>
@ -358,7 +373,7 @@
<glossdef>
<para>If specified, connections FROM this interface are to
be tracked so that responses may be routed back out this
same interface. </para>
same interface.</para>
<para>You want specify 'track' if internet hosts will be
connecting to local servers through this provider.</para>
@ -384,18 +399,41 @@
<title>Example</title>
<para>The configuration in the figure at the top of this section would
be specified as follows:</para>
be specified in <filename>/etc/shorewall/providers</filename> as
follows:</para>
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
ISP1 1 1 main eth0 206.124.146.254 track,balance
ISP2 2 2 main eth1 130.252.99.254 track,balance</programlisting>
<para>Other configuration files go something like this:</para>
<para><filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect …
net eth1 detect …</programlisting>
<para><filename>/etc/shorewall/policy</filename>:</para>
<programlisting>#SOURCE DESTINATION POLICY LIMIT:BURST
net net DROP</programlisting>
<para>If you have masqueraded hosts, be sure to update
<filename>/etc/shorewall/masq</filename> to masquerade to both ISPs. For
example, if you masquerade all hosts connected to <filename
class="devicefile">eth2</filename> then:</para>
<programlisting>#INTERFACE SUBNET ADDRESS
eth0 eth2 206.124.146.176
eth1 eth2 130.252.99.27</programlisting>
</section>
</section>
<section id="RouteTarget">
<title>Experimental Routing with Shorewall 2.3.3 and Later</title>
<title>Experimental Routing with Shorewall 2.3.2 and Later</title>
<para>Beginning with Shorewall 2.2.3, Shorewall is integrated with the
<para>Beginning with Shorewall 2.3.2, Shorewall is integrated with the
ROUTE target extension available from Netfilter Patch-O-Matic-NG (<ulink
url="http://www.netfilter.org">http://www.netfilter.org</ulink>).</para>
@ -411,7 +449,7 @@ ISP2 2 2 main eth1 130.252.99.254 track,ba
<para>See <ulink url="FAQ.htm#faq42">Shorewall FAQ 42</ulink> for
information about determining if your kernel and iptables have this
support enabled. You must be running Shorewall 2.3.3 or later to make this
support enabled. You must be running Shorewall 2.3.2 or later to make this
determination.</para>
<para>Routing with Shorewall is specified through entries in

195
Shorewall-docs2/netmap.xml
View File

@ -15,10 +15,10 @@
</author>
</authorgroup>
<pubdate>2004-05-28</pubdate>
<pubdate>2005-05-19</pubdate>
<copyright>
<year>2004</year>
<year>2004-2005</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -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>
@ -40,7 +41,8 @@
Suppose that two organizations, A and B, need to be linked and that both
organizations have allocated the 192.168.1.0/24 subnetwork. There is a
need to connect the two networks so that all systems in A can access the
192.168.1.0/24 network in B and vice versa without any re-addressing.</para>
192.168.1.0/24 network in B and vice versa without any
re-addressing.</para>
</section>
<section>
@ -69,7 +71,8 @@
<listitem>
<para>Your kernel must have NETMAP support. 2.6 Kernels have NETMAP
support without patching while 2.4 kernels must be patched using
Patch-O-Matic from <ulink url="http://www.netfilter.org">netfilter.org</ulink>.</para>
Patch-O-Matic from <ulink
url="http://www.netfilter.org">netfilter.org</ulink>.</para>
</listitem>
<listitem>
@ -83,8 +86,9 @@
</listitem>
</itemizedlist>
<para>Network mapping is defined using the <filename>/etc/shorewall/netmap</filename>
file. Columns in this file are:</para>
<para>Network mapping is defined using the
<filename>/etc/shorewall/netmap</filename> file. Columns in this file
are:</para>
<variablelist>
<varlistentry>
@ -94,12 +98,12 @@
<para>Must be DNAT or SNAT.</para>
<para>If DNAT, traffic entering INTERFACE and addressed to NET1 has
it&#39;s destination address rewritten to the corresponding address
in NET2.</para>
it's destination address rewritten to the corresponding address in
NET2.</para>
<para>If SNAT, traffic leaving INTERFACE with a source address in
NET1 has it&#39;s source address rewritten to the corresponding
address in NET2.</para>
NET1 has it's source address rewritten to the corresponding address
in NET2.</para>
</listitem>
</varlistentry>
@ -107,7 +111,8 @@
<term>NET1</term>
<listitem>
<para>Must be expressed in CIDR format (e.g., 192.168.1.0/24).</para>
<para>Must be expressed in CIDR format (e.g.,
192.168.1.0/24).</para>
</listitem>
</varlistentry>
@ -116,7 +121,8 @@
<listitem>
<para>A firewall interface. This interface must have been defined in
<ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
<ulink
url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
</listitem>
</varlistentry>
@ -132,15 +138,34 @@
<para>Referring to the figure above, lets suppose that systems in the top
cloud are going to access the 192.168.1.0/24 network in the bottom cloud
using addresses in 10.10.10.0/24 and that systems in the bottom could will
access 192.168.1.0/24 in the top could using addresses in 10.10.11.0.<important><para>You
must arrange for routing as follows:</para><itemizedlist><listitem><para>Traffic
from the top cloud to 10.10.10.0/24 must be routed to eth0 on firewall 1.</para></listitem><listitem><para>Firewall
1 must route traffic to 10.10.10.0/24 through firewall 2.</para></listitem><listitem><para>Traffic
from the bottom cloud to 10.10.11.0/24 must be routed to eth0 on firewall
2.</para></listitem><listitem><para>Firewall 2 must route traffic to
10.10.11.0/24 through firewall 1.</para></listitem></itemizedlist></important>
The entries in <filename><filename>/etc/shorewall/netmap</filename></filename>
in firewall1 would be as follows:</para>
access 192.168.1.0/24 in the top could using addresses in
10.10.11.0.<important>
<para>You must arrange for routing as follows:</para>
<itemizedlist>
<listitem>
<para>Traffic from the top cloud to 10.10.10.0/24 must be routed
to eth0 on firewall 1.</para>
</listitem>
<listitem>
<para>Firewall 1 must route traffic to 10.10.10.0/24 through
firewall 2.</para>
</listitem>
<listitem>
<para>Traffic from the bottom cloud to 10.10.11.0/24 must be
routed to eth0 on firewall 2.</para>
</listitem>
<listitem>
<para>Firewall 2 must route traffic to 10.10.11.0/24 through
firewall 1.</para>
</listitem>
</itemizedlist>
</important> The entries in
<filename><filename>/etc/shorewall/netmap</filename></filename> in
firewall1 would be as follows:</para>
<programlisting>#TYPE NET1 INTERFACE NET2
SNAT 192.168.1.0/24 vpn 10.10.11.0/24 #RULE 1A
@ -160,44 +185,132 @@ SNAT 192.168.1.0/24 vpn 10.10.10.0/24 #RULE 2B</programlist
<para>In order to make this connection, the client attempts a connection
to 10.10.10.27. The following table shows how the source and destination
IP addresses are modified as requests are sent and replies are returned.
The RULE column refers to the above <filename>/etc/shorewall/netmap</filename>
entries and gives the rule which transforms the source and destination
IP addresses to those shown on the next line.
<informaltable><tgroup cols="5"><thead><row><entry>FROM</entry><entry>TO</entry><entry>SOURCE
IP ADDRESS</entry><entry>DESTINATION IP ADDRESS</entry><entry>RULE</entry></row></thead><tbody><row><entry>192.168.1.4
in upper cloud</entry><entry>Firewall 1</entry><entry>192.168.1.4</entry><entry>10.10.10.27</entry><entry>1A</entry></row><row><entry>Firewall
1</entry><entry>Firewall 2</entry><entry>10.10.11.4</entry><entry>10.10.10.27</entry><entry>2A</entry></row><row><entry>Filrewall
2</entry><entry>192.168.1.27 in lower cloud</entry><entry>10.10.11.4</entry><entry>192.168.1.27</entry><entry></entry></row><row><entry>192.168.1.27
in the lower cloud</entry><entry>Firewall 2</entry><entry>192.168.1.27</entry><entry>10.10.11.4</entry><entry>2B</entry></row><row><entry>Firewall
2</entry><entry>Firewall 1</entry><entry>10.10.10.27</entry><entry>10.10.11.4</entry><entry>1B</entry></row><row><entry>Firewall
1</entry><entry>192.168.1.4 in upper cloud</entry><entry>10.10.10.27</entry><entry>192.168.1.4</entry><entry></entry></row></tbody></tgroup></informaltable></para>
The RULE column refers to the above
<filename>/etc/shorewall/netmap</filename> entries and gives the rule
which transforms the source and destination IP addresses to those shown
on the next line. <informaltable>
<tgroup cols="5">
<thead>
<row>
<entry>FROM</entry>
<entry>TO</entry>
<entry>SOURCE IP ADDRESS</entry>
<entry>DESTINATION IP ADDRESS</entry>
<entry>RULE</entry>
</row>
</thead>
<tbody>
<row>
<entry>192.168.1.4 in upper cloud</entry>
<entry>Firewall 1</entry>
<entry>192.168.1.4</entry>
<entry>10.10.10.27</entry>
<entry>1A</entry>
</row>
<row>
<entry>Firewall 1</entry>
<entry>Firewall 2</entry>
<entry>10.10.11.4</entry>
<entry>10.10.10.27</entry>
<entry>2A</entry>
</row>
<row>
<entry>Filrewall 2</entry>
<entry>192.168.1.27 in lower cloud</entry>
<entry>10.10.11.4</entry>
<entry>192.168.1.27</entry>
<entry></entry>
</row>
<row>
<entry>192.168.1.27 in the lower cloud</entry>
<entry>Firewall 2</entry>
<entry>192.168.1.27</entry>
<entry>10.10.11.4</entry>
<entry>2B</entry>
</row>
<row>
<entry>Firewall 2</entry>
<entry>Firewall 1</entry>
<entry>10.10.10.27</entry>
<entry>10.10.11.4</entry>
<entry>1B</entry>
</row>
<row>
<entry>Firewall 1</entry>
<entry>192.168.1.4 in upper cloud</entry>
<entry>10.10.10.27</entry>
<entry>192.168.1.4</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable></para>
</example>
</section>
<section>
<title>Author&#39;s Notes</title>
<title>Author's Notes</title>
<para>This could all be made a bit simpler by eliminating the TYPE field
and have Shorewall generate both the SNAT and DNAT rules from a single
entry. I have chosen to include the TYPE in order to make the
implementation a bit more flexible. If you find cases where you can use an
SNAT or DNAT entry by itself, please let <ulink
url="mailto:webmaster@shorewall.net">me</ulink> know and I&#39;ll add the
url="mailto:webmaster@shorewall.net">me</ulink> know and I'll add the
example to this page.</para>
<para>In the previous section, the table in the example contains a bit of
a lie. Because of Netfilter&#39;s connection tracking, rules 2B and 1A
aren&#39;t needed to handle the replies. They ARE needed though for hosts
in the bottom cloud to be able to establish connections with the
192.168.1.0/24 network in the top cloud.</para>
a lie. Because of Netfilter's connection tracking, rules 2B and 1B aren't
needed to handle the replies. They ARE needed though for hosts in the
bottom cloud to be able to establish connections with the 192.168.1.0/24
network in the top cloud.</para>
</section>
<section>
<title>Can&#39;t I do this with one router? Why do I need two?</title>
<title>Can't I do this with one router? Why do I need two?</title>
<para>The single router would have to be able to route to two different
192.168.1.0/24 networks. In Netfilter parlance, that would mean that the
destination IP address would have to be rewritten after the packet had
been routed; Netfilter doesn&#39;t have that capability.</para>
been routed; Netfilter doesn't have that capability.</para>
<para>Note that if you do it with two routers, then adding a third is
easy. There's no reason why you can't have yet another network that is
192.168.1.0/24 on the inside, but you can allocated it 10.10.12.0/24 for
everybody else.</para>
</section>
</article>

9
Shorewall-docs2/support.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-05-14</pubdate>
<pubdate>2005-05-19</pubdate>
<copyright>
<year>2001-2005</year>
@ -40,6 +40,13 @@
</legalnotice>
</articleinfo>
<section>
<title>Notice</title>
<para>Effective May 18, 2005 the original Shorewall designer and author is
no longer providing Shorewall support.</para>
</section>
<section>
<title>Before Reporting a Problem or Asking a Question</title>