mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-31 10:38:55 +01:00
Add Two ISP graphics
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2135 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
44231e92a0
commit
39a54f211e
@ -15,10 +15,10 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-03-15</pubdate>
|
||||
<pubdate>2005-05-15</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
<year>2003-2005</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
@ -29,17 +29,18 @@
|
||||
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>
|
||||
|
||||
<section>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>While most configurations can be handled with each of the
|
||||
firewall's network interfaces assigned to a single zone, there are
|
||||
cases where you will want to divide the hosts accessed through an
|
||||
interface between two or more zones.</para>
|
||||
<para>While most configurations can be handled with each of the firewall's
|
||||
network interfaces assigned to a single zone, there are cases where you
|
||||
will want to divide the hosts accessed through an interface between two or
|
||||
more zones.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -57,7 +58,8 @@
|
||||
|
||||
<listitem>
|
||||
<para>There are routers accessible through the interface and you want
|
||||
to treat the networks accessed through that router as a separate zone.</para>
|
||||
to treat the networks accessed through that router as a separate
|
||||
zone.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -83,8 +85,8 @@
|
||||
</itemizedlist>
|
||||
|
||||
<para><emphasis role="bold">These examples use the local zone but the same
|
||||
technique works for any zone.</emphasis> Remember that Shorewall
|
||||
doesn't have any conceptual knowledge of <quote>Internet</quote>,
|
||||
technique works for any zone.</emphasis> Remember that Shorewall doesn't
|
||||
have any conceptual knowledge of <quote>Internet</quote>,
|
||||
<quote>Local</quote>, or <quote>DMZ</quote> so all zones except the
|
||||
firewall itself ($FW) are the same as far as Shorewall is concerned. Also,
|
||||
the examples use private (RFC 1918) addresses but public IP addresses can
|
||||
@ -119,7 +121,8 @@
|
||||
|
||||
<listitem>
|
||||
<para>The hosts in 192.168.1.0/24 know that the route to
|
||||
192.168.2.0/24 is through the <emphasis role="bold">router</emphasis>.</para>
|
||||
192.168.2.0/24 is through the <emphasis
|
||||
role="bold">router</emphasis>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@ -132,11 +135,11 @@
|
||||
<title>Will One Zone be Enough?</title>
|
||||
|
||||
<para>If the firewalling requirements for the two local networks is the
|
||||
same but the hosts in 192.168.1.0/24 don't know how to route to
|
||||
same but the hosts in 192.168.1.0/24 don't know how to route to
|
||||
192.168.2.0/24 then you need to configure the firewall slightly
|
||||
differently. This type of configuration is rather stupid from an IP
|
||||
networking point of view but it is sometimes necessary because you
|
||||
simply don't want to have to reconfigure all of the hosts in
|
||||
simply don't want to have to reconfigure all of the hosts in
|
||||
192.168.1.0/24 to add a persistent route to 192.168.2.0/24. On the
|
||||
firewall:</para>
|
||||
|
||||
@ -156,13 +159,32 @@
|
||||
<para>Restart Shorewall.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If this still doesn't work at all or if it works for connections
|
||||
in one direction but not for connections in the other direction
|
||||
then:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>You must be running Shorewall version 2.0.16 or later;
|
||||
and</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>You need to set DROPINVALID=No in
|
||||
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>I Need Separate Zones</title>
|
||||
|
||||
<para>If you need to make 192.168.2.0/24 into it's own zone, you can
|
||||
do it one of two ways; Nested Zones or Parallel Zones.</para>
|
||||
<para>If you need to make 192.168.2.0/24 into it's own zone, you can do
|
||||
it one of two ways; Nested Zones or Parallel Zones. Again, it is likely
|
||||
that you will need to be running Shorewall 2.0.16 or later and that you
|
||||
will have to set DROPINVALID=No in
|
||||
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
||||
|
||||
<section>
|
||||
<title>Nested Zones</title>
|
||||
@ -173,13 +195,13 @@
|
||||
|
||||
<graphic fileref="images/MultiZone1A.png" />
|
||||
|
||||
<para>The advantage of this approach is that the zone <quote>loc1</quote>
|
||||
can use CONTINUE policies such that if a connection request
|
||||
doesn't match a <quote>loc1</quote> rule, it will be matched
|
||||
against the <quote>loc</quote> rules. For example, if your
|
||||
loc1->net policy is CONTINUE then if a connection request from
|
||||
loc1 to the internet doesn't match any rules for loc1->net
|
||||
then it will be checked against the loc->net rules.</para>
|
||||
<para>The advantage of this approach is that the zone
|
||||
<quote>loc1</quote> can use CONTINUE policies such that if a
|
||||
connection request doesn't match a <quote>loc1</quote> rule, it will
|
||||
be matched against the <quote>loc</quote> rules. For example, if your
|
||||
loc1->net policy is CONTINUE then if a connection request from loc1
|
||||
to the internet doesn't match any rules for loc1->net then it will
|
||||
be checked against the loc->net rules.</para>
|
||||
|
||||
<para><filename>/etc/shorewall/zones</filename></para>
|
||||
|
||||
@ -201,9 +223,9 @@ loc eth1 192.168.1.255</programlisting>
|
||||
<programlisting>#ZONE HOSTS
|
||||
loc1 eth1:192.168.2.0/24</programlisting>
|
||||
|
||||
<para>If you don't need Shorewall to set up infrastructure to
|
||||
route traffic between <quote>loc</quote> and <quote>loc1</quote>, add
|
||||
these two policies.</para>
|
||||
<para>If you don't need Shorewall to set up infrastructure to route
|
||||
traffic between <quote>loc</quote> and <quote>loc1</quote>, add these
|
||||
two policies.</para>
|
||||
|
||||
<para>/etc/shorewall/policy</para>
|
||||
|
||||
@ -227,7 +249,7 @@ loc1 Local1 Hosts accessed Directly from Firewall
|
||||
loc2 Local2 Hosts accessed via the internal Router</programlisting>
|
||||
|
||||
<note>
|
||||
<para>Here it doesn't matter which zone is defined first.</para>
|
||||
<para>Here it doesn't matter which zone is defined first.</para>
|
||||
</note>
|
||||
|
||||
<para><filename>/etc/shorewall/interfaces</filename></para>
|
||||
@ -241,7 +263,7 @@ loc2 Local2 Hosts accessed via the internal Router</
|
||||
loc1 eth1:192.168.1.0/24
|
||||
loc2 eth1:192.168.2.0/24</programlisting>
|
||||
|
||||
<para>You don't need Shorewall to set up infrastructure to route
|
||||
<para>You don't need Shorewall to set up infrastructure to route
|
||||
traffic between <quote>loc</quote> and <quote>loc1</quote>, so add
|
||||
these two policies:</para>
|
||||
|
||||
@ -256,7 +278,7 @@ loc2 loc1 NONE</programlisting>
|
||||
<title>Some Hosts have Special Firewalling Requirements</title>
|
||||
|
||||
<para>There are cases where a subset of the addresses associated with an
|
||||
interface need special handling. Here's an example.</para>
|
||||
interface need special handling. Here's an example.</para>
|
||||
|
||||
<graphic fileref="images/MultiZone2.png" />
|
||||
|
||||
@ -281,9 +303,9 @@ loc eth1 192.168.1.255</programlisting>
|
||||
<para><filename>/etc/shorewall/hosts</filename><programlisting>#ZONE HOSTS
|
||||
loc1 eth1:192.168.1.8/29</programlisting></para>
|
||||
|
||||
<para>You probably don't want Shorewall to set up infrastructure to
|
||||
route traffic between <quote>loc</quote> and <quote>loc1</quote> so you
|
||||
should add these two policies.</para>
|
||||
<para>You probably don't want Shorewall to set up infrastructure to route
|
||||
traffic between <quote>loc</quote> and <quote>loc1</quote> so you should
|
||||
add these two policies.</para>
|
||||
|
||||
<para><filename>/etc/shorewall/policy</filename></para>
|
||||
|
||||
@ -295,16 +317,16 @@ loc1 loc NONE</programlisting>
|
||||
<section id="OneArmed">
|
||||
<title>One-armed Router</title>
|
||||
|
||||
<para>Nested zones may also be used to configure a <quote>one-armed</quote>
|
||||
router (I don't call it a <quote>firewall</quote> because it is very
|
||||
insecure. For example, if you connect to the internet via cable modem,
|
||||
your next door neighbor has full access to your local systems as does
|
||||
everyone else connected to the same cable modem head-end controller). Here
|
||||
eth0 is configured with both a public IP address and an RFC 1918 address
|
||||
(More on that topic may be found <ulink
|
||||
<para>Nested zones may also be used to configure a
|
||||
<quote>one-armed</quote> router (I don't call it a <quote>firewall</quote>
|
||||
because it is very insecure. For example, if you connect to the internet
|
||||
via cable modem, your next door neighbor has full access to your local
|
||||
systems as does everyone else connected to the same cable modem head-end
|
||||
controller). Here eth0 is configured with both a public IP address and an
|
||||
RFC 1918 address (More on that topic may be found <ulink
|
||||
url="Shorewall_and_Aliased_Interfaces.html">here</ulink>). Hosts in the
|
||||
<quote>loc</quote> zone are configured with their default gateway set to
|
||||
the Shorewall router's RFC1918 address.</para>
|
||||
the Shorewall router's RFC1918 address.</para>
|
||||
|
||||
<para><graphic fileref="images/MultiZone3.png" /></para>
|
||||
|
||||
@ -333,10 +355,11 @@ loc eth0:192.168.1.0/24 maclist</programlisting>
|
||||
<programlisting>#INTERFACE SUBNET ADDRESS
|
||||
eth0:!192.168.1.0/24 192.168.1.0/24</programlisting>
|
||||
|
||||
<para>Note that the maclist option is specified in <filename>/etc/shorewall/interfaces</filename>.
|
||||
This is to help protect your router from unauthorized access by your
|
||||
friends and neighbors. Start without maclist then add it and configure
|
||||
your <ulink url="MAC_Validation.html"><filename>/etc/shorewall/maclist</filename></ulink>
|
||||
<para>Note that the maclist option is specified in
|
||||
<filename>/etc/shorewall/interfaces</filename>. This is to help protect
|
||||
your router from unauthorized access by your friends and neighbors. Start
|
||||
without maclist then add it and configure your <ulink
|
||||
url="MAC_Validation.html"><filename>/etc/shorewall/maclist</filename></ulink>
|
||||
file when everything else is working.</para>
|
||||
</section>
|
||||
</article>
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-03-01</pubdate>
|
||||
<pubdate>2005-05-16</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003-2005</year>
|
||||
@ -174,7 +174,9 @@ REDIRECT loc 3128 tcp www - !206.124.146.
|
||||
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
|
||||
kernel and/or iptables do not have ROUTE target support then:</para>
|
||||
kernel and/or iptables do not have <ulink
|
||||
url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink> then:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
@ -218,17 +220,19 @@ fi</command></programlisting>
|
||||
</orderedlist>
|
||||
|
||||
<para>If you are running Shorewall 2.3.3 or later and your kernel and
|
||||
iptables have ROUTE target support then add this entry to
|
||||
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 INTERFACE GATEWAY
|
||||
<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>
|
||||
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
|
||||
ROUTE target support, you need the following:</para>
|
||||
<ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink>, you need the following:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
@ -282,7 +286,9 @@ chkconfig --level 35 iptables on</command></programlisting>
|
||||
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
|
||||
kernel and/or iptables do not have ROUTE target support then:</para>
|
||||
kernel and/or iptables do not have <ulink
|
||||
url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink> then:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
@ -351,17 +357,19 @@ fi</command></programlisting>
|
||||
</orderedlist>
|
||||
|
||||
<para>If you are running Shorewall 2.3.3 or later and your kernel and
|
||||
iptables have ROUTE target support then add this entry to
|
||||
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 INTERFACE GATEWAY
|
||||
<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>
|
||||
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
|
||||
ROUTE target support, you need the following:</para>
|
||||
<ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink>, you need the following:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-05-15</pubdate>
|
||||
<pubdate>2005-05-18</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.3.</emphasis></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -206,7 +206,194 @@
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Routing with Shorewall 2.3.3 and Later</title>
|
||||
<title>Multiple Internet Connection Support in Shorewall 2.3.3 and
|
||||
Later</title>
|
||||
|
||||
<para>Beginning with Shorewall 2.3.3, 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
|
||||
diagram.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>eth0 connects to ISP1. The IP address of eth0 is
|
||||
206.124.146.176 and the ISP's gateway router has IP address
|
||||
206.124.146.254.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>eth1 connects to ISP 2. The IP address of eth1 is
|
||||
130.252.99.27 and the ISP's gateway router has IP address
|
||||
130.252.99.254.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Each of these <firstterm>providers</firstterm> is described in an
|
||||
entry in the file <filename>/etc/shorewall/providers</filename>.</para>
|
||||
|
||||
<para>Entries in <filename>/etc/shorewall/providers</filename> can
|
||||
specify that outgoing connections are to be load-balanced between the
|
||||
two ISPs. Entries in <filename>/etc/shorewall/tcrules</filename> can be
|
||||
used to direct particular outgoing connections to one ISP or the
|
||||
other.</para>
|
||||
|
||||
<para>Connections from the internet are automatically routed back out of
|
||||
the correct interface and through the correct ISP gateway. This works
|
||||
whether the connection is handled by the firewall itself or if it is
|
||||
routed or port-forwarded to a system behind the firewall.</para>
|
||||
|
||||
<para>Shorewall will set up the routing and will update the
|
||||
/etc/iproute2/rt_tables to include the table names and number of the
|
||||
tables that it adds.</para>
|
||||
|
||||
<caution>
|
||||
<para>This feature uses <ulink url="traffic_shaping.htm">packet
|
||||
marking</ulink> to control the routing. As a consequence, there are
|
||||
some restrictions concerning entries in /etc/shorewall/tcrules:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Packet marking for traffic control purposes must be done in
|
||||
the FORWARD table.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>You may not use the SAVE or RESTORE options.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>You man not use connection marking.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</caution>
|
||||
|
||||
<para>The <filename>/etc/shorewall/providers</filename> file can also be
|
||||
used in other routing senarios. See the Squid documentation for an
|
||||
example.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>/etc/shorewall/providers File</title>
|
||||
|
||||
<para>Entries in this file have the following columns. As in all
|
||||
Shorewall configuration files, enter "-" in a column if you don't want
|
||||
to enter any value.</para>
|
||||
|
||||
<glossary>
|
||||
<glossdiv>
|
||||
<title>/etc/shorewall/providers:</title>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>NAME</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>The provider name. Must begin with a letter and consist of
|
||||
letters and digits. The provider name becomes the name of the
|
||||
generated routing table for this provider.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>NUMBER</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>A number between 1 and 252. This becomes the routing table
|
||||
number for the generated table for this provider.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>MARK</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>A mark value used in your /etc/shorewall/tcrules file to
|
||||
direct packets to this provider. Shorewall will also mark
|
||||
connections that have seen input from this provider with this
|
||||
value and will restore the packet mark in the PREROUTING
|
||||
CHAIN.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>DUPLICATE</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>Gives the name and number of a routing table to duplicate.
|
||||
May be 'main' or the name of a previously declared provider. For
|
||||
most applications, you want to specify 'main' here.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>INTERFACE</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>The name of the interface to the provider.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>GATEWAY</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>The IP address of the provider's Gateway router.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>OPTIONS</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>A comma-separated list from the following:</para>
|
||||
|
||||
<glosslist>
|
||||
<glossentry>
|
||||
<glossterm>track</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>If specified, connections FROM this interface are to
|
||||
be tracked so that responses may be routed back out this
|
||||
same interface. </para>
|
||||
|
||||
<para>You want specify 'track' if internet hosts will be
|
||||
connecting to local servers through this provider.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>balance</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>The providers that have 'default' specified will get
|
||||
outbound traffic load-balanced among them.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glosslist>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossdiv>
|
||||
</glossary>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Example</title>
|
||||
|
||||
<para>The configuration in the figure at the top of this section would
|
||||
be specified 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>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="RouteTarget">
|
||||
<title>Experimental Routing with Shorewall 2.3.3 and Later</title>
|
||||
|
||||
<para>Beginning with Shorewall 2.2.3, Shorewall is integrated with the
|
||||
ROUTE target extension available from Netfilter Patch-O-Matic-NG (<ulink
|
||||
@ -215,7 +402,11 @@
|
||||
<warning>
|
||||
<para>As of this writing, I know of no distribution that is shipping a
|
||||
kernel or iptables with the ROUTE target patch included. This means that
|
||||
you must patch and build your own kernel and iptables. </para>
|
||||
you must patch and build your own kernel and iptables in order to be
|
||||
able to use the feature described in this section. <emphasis
|
||||
role="bold">This code remains experimental</emphasis> since there is no
|
||||
intent by the Netfilter team to ever submit the ROUTE target patch for
|
||||
inclusion in the official kernels from kernel.org.</para>
|
||||
</warning>
|
||||
|
||||
<para>See <ulink url="FAQ.htm#faq42">Shorewall FAQ 42</ulink> for
|
||||
@ -224,7 +415,13 @@
|
||||
determination.</para>
|
||||
|
||||
<para>Routing with Shorewall is specified through entries in
|
||||
/etc/shorewall/routes. Columns in this file are as follows:</para>
|
||||
/etc/shorewall/routes. Note that entries in the /etc/shorewall/routes file
|
||||
override the routing specified in your routing tables. These rules
|
||||
generate Netfilter rules in the mangle tables FORWARD chain or OUTPUT
|
||||
chain depending whether the packets are being routed through the firewall
|
||||
or originate on the firewall itself (see figure above).</para>
|
||||
|
||||
<para>Columns in this file are as follows:</para>
|
||||
|
||||
<glosslist>
|
||||
<glossentry>
|
||||
@ -330,7 +527,58 @@
|
||||
<glossdef>
|
||||
<para>Optional) Source port(s). If omitted, any source port is
|
||||
acceptable. Specified as a comma-separated list of port names, port
|
||||
numbers or port ranges. </para>
|
||||
numbers or port ranges.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>TEST</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>Defines a test on the existing packet or connection mark. The
|
||||
rule will match only if the test returns true. Tests have the
|
||||
format</para>
|
||||
|
||||
<blockquote>
|
||||
<para>[!]<value>[/<mask>][:C]</para>
|
||||
</blockquote>
|
||||
|
||||
<para>where:</para>
|
||||
|
||||
<glosslist>
|
||||
<glossentry>
|
||||
<glossterm>!</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>Inverts the test (not equal)</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm><value></glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>Value of the packet or connection mark.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm><mask></glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>A mask to be applied to the mark before testing</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>:C</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>Designates a connection mark. If omitted, the packet
|
||||
mark's value is tested</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glosslist>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
@ -355,8 +603,8 @@
|
||||
</glosslist>
|
||||
|
||||
<para>The idea here is that traffic that matches the SOURCE, DEST, PROTO,
|
||||
PORT(S) and SOURCE PORT(S) columns is routed out of the INTERFACE through
|
||||
the optional GATEWAY.</para>
|
||||
PORT(S), SOURCE PORT(S) and TEST columns is routed out of the INTERFACE
|
||||
through the optional GATEWAY.</para>
|
||||
|
||||
<blockquote>
|
||||
<para>Example:</para>
|
||||
@ -366,17 +614,12 @@
|
||||
your DMZ. You would use the following entry in
|
||||
/etc/shorewall/routes:</para>
|
||||
|
||||
<programlisting>#SOURCE DEST PROTO PORT(S) SOURCE INTERFACE GATEWAY
|
||||
<programlisting>#SOURCE DEST PROTO PORT(S) SOURCE TEST INTERFACE GATEWAY
|
||||
# PORT(S)
|
||||
eth1 0.0.0.0/0 tcp 80 - eth1 192.168.3.22</programlisting>
|
||||
eth1 0.0.0.0/0 tcp 80 - - eth1 192.168.3.22</programlisting>
|
||||
|
||||
<para>This entry specifies that "traffic coming in through eth1 to TCP
|
||||
port 80 is to be routed out of eth1 to gateway 192.168.3.22".</para>
|
||||
</blockquote>
|
||||
|
||||
<para>Note that entries in the /etc/shorewall/routes file override the
|
||||
routing specified in your routing tables. These rules generate Netfilter
|
||||
rules in the mangle tables FORWARD chain or OUTPUT chain (see figure
|
||||
above).</para>
|
||||
</section>
|
||||
</article>
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-05-07</pubdate>
|
||||
<pubdate>2005-05-16</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2005</year>
|
||||
@ -39,7 +39,7 @@
|
||||
|
||||
<para>In Shorewall 2.2.4, support was added for UPnP (Universal Plug and
|
||||
Play) using linux-igd (<ulink
|
||||
url="http://linux-idg.sourceforge.net">http://linux-idg.sourceforge.net</ulink>).
|
||||
url="http://linux-igd.sourceforge.net">http://linux-igd.sourceforge.net</ulink>).
|
||||
UPnP is required by a number of popular applications including MSN
|
||||
IM.</para>
|
||||
|
||||
@ -83,7 +83,7 @@
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>linux-idg Configuration</title>
|
||||
<title>linux-igd Configuration</title>
|
||||
|
||||
<para>In /etc/upnpd.conf, you will want:</para>
|
||||
|
||||
@ -128,7 +128,7 @@ allowinUPnP loc fw</programlisting>
|
||||
forwardUPnP net loc</programlisting>
|
||||
|
||||
<para>You must also ensure that you have a route to 224.0.0.0/4 on your
|
||||
internal (local) interface as described in the linux-idg
|
||||
internal (local) interface as described in the linux-igd
|
||||
documentation.</para>
|
||||
</section>
|
||||
</article>
|
||||
BIN
Shorewall-docs2/images/TwoISPs.png
Executable file
BIN
Shorewall-docs2/images/TwoISPs.png
Executable file
Binary file not shown.
442
Shorewall-docs2/images/TwoISPs.vdx
Executable file
442
Shorewall-docs2/images/TwoISPs.vdx
Executable file
File diff suppressed because one or more lines are too long
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-04-13</pubdate>
|
||||
<pubdate>2005-05-15</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
@ -48,7 +48,45 @@
|
||||
to interact with Shorewall. Normally the root user's PATH includes
|
||||
<filename>/sbin</filename> and the program can be run from a shell
|
||||
prompt by simply typing <command>shorewall</command> followed by a
|
||||
command. To see a list of supported commands, use the
|
||||
command.</para>
|
||||
|
||||
<warning>
|
||||
<para>In some releases of KDE, the default configuration of the
|
||||
<emphasis role="bold">konsole</emphasis> program is brain dead with
|
||||
respect to the "Root Console". It executes the command "su" where it
|
||||
should execute "su -"; the latter will cause a login shell to be
|
||||
created which will in turn set PATH properly. You can correct this
|
||||
problem as follows:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Click on "Settings" on the toolbar and select "Configure
|
||||
Konsole"</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Select the "Session" tab.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Click on "Root Console"</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Change the Execute command from "su" to "su -"</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Click on "Save Session"</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Click on "Ok"</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</warning>
|
||||
|
||||
<para>To see a list of supported commands, use the
|
||||
<command>help</command> command:</para>
|
||||
|
||||
<programlisting><command>shorewall help</command></programlisting>
|
||||
@ -61,10 +99,11 @@
|
||||
|
||||
<listitem>
|
||||
<para><filename>/etc/shorewall</filename> — The default directory
|
||||
where Shorewall looks for configuration files. See the section
|
||||
entitled <link linkend="AltConfig">Alternate Configuration
|
||||
Directories</link> for information about how you can direct Shorewall
|
||||
to look in other directories.</para>
|
||||
where Shorewall looks for configuration files. See the sections
|
||||
entitled <link linkend="AddDirectories">Additional Configuration
|
||||
Directories</link> and <link linkend="AltConfig">Alternate
|
||||
Configuration Directories</link> for information about how you can
|
||||
direct Shorewall to look in other directories.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -237,7 +276,7 @@
|
||||
is much faster than starting Shorewall using the normal mechanism of
|
||||
reading the configuration files and running
|
||||
<command>iptables</command> dozens or even hundreds of times.
|
||||
<filename>/etc/init.d/shorewall</filename>
|
||||
<filename>By default, /etc/init.d/shorewall</filename>
|
||||
(<filename>/etc/rc.d/firewall.rc</filename>) uses the -f option when
|
||||
it is processing a request to start Shorewall.</para>
|
||||
</listitem>
|
||||
@ -271,16 +310,52 @@
|
||||
shell prompt to remove these files).</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="AltConfig">Alternate Configuration Directories</title>
|
||||
<section id="AddDirectories">
|
||||
<title>Additional Configuration Directories</title>
|
||||
|
||||
<para>As explained above, Shorewall normally looks for configuration files
|
||||
in the directory <filename class="directory">/etc/shorewall</filename>.
|
||||
The <command>shorewall start</command>, <command>shorewall
|
||||
restart</command>, <command>shorewall check</command>, and
|
||||
<command>shorewall try </command>commands allow you to specify a different
|
||||
directory for Shorewall to check before looking in <filename
|
||||
class="directory">/etc/shorewall</filename>.</para>
|
||||
<para>The CONFIG_PATH setting in
|
||||
<filename>/etc/shorewall/shorewall.conf</filename> determines where
|
||||
Shorewall looks for configuration files. The default setting is
|
||||
CONFIG_PATH=<filename
|
||||
class="directory">/etc/shorewall</filename>:<filename
|
||||
class="directory">/usr/share/shorewall</filename> which means that
|
||||
<filename class="directory">/etc/shorewall</filename> is searched first
|
||||
and if the file is not found then <filename
|
||||
class="directory">/usr/share/shorewall</filename> is searched. You can
|
||||
change the value of CONFIG_PATH to cause additional directories to be
|
||||
searched but CONFIG_PATH should <emphasis>always</emphasis> include both
|
||||
<filename class="directory">/etc/shorewall</filename> and <filename
|
||||
class="directory">/usr/share/shorewall</filename>.</para>
|
||||
|
||||
<para>When an alternate configuration directory is specified as described
|
||||
in the <link linkend="AddDirectories">next section</link>, that directory
|
||||
is searched <emphasis>before</emphasis> those directories listed in
|
||||
CONFIG_PATH.</para>
|
||||
|
||||
<para>Example - Search <filename
|
||||
class="directory">/etc/shorewall</filename>, <filename
|
||||
class="directory">/etc/shorewall/actiondir</filename> and <filename
|
||||
class="directory">/usr/share/shorewall</filename> in that order:</para>
|
||||
|
||||
<programlisting>CONFIG_PATH=/etc/shorewall:/etc/shorewall/actiondir:/usr/share/shorewall</programlisting>
|
||||
|
||||
<para>The above is the setting that I use and it allows me to place all of
|
||||
my user-defined 'action.' files in <filename
|
||||
class="directory">/etc/shorewall/actiondir</filename>.</para>
|
||||
</section>
|
||||
|
||||
<section id="AltConfig">
|
||||
<title>Alternate Configuration Directories</title>
|
||||
|
||||
<para>As explained <link linkend="AddDirectories">above</link>, Shorewall
|
||||
normally looks for configuration files in the directories specified by the
|
||||
CONFIG_PATH option in <filename
|
||||
class="directory">/etc/shorewall/shorewall.conf</filename>. The
|
||||
<command>shorewall start</command>, <command>shorewall restart</command>,
|
||||
<command>shorewall check</command>, and <command>shorewall try
|
||||
</command>commands allow you to specify an additional directory for
|
||||
Shorewall to check before looking in the directories listed in
|
||||
CONFIG_PATH.</para>
|
||||
|
||||
<para>Shorewall versions before Shorewall 2.2.0:</para>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user