holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Clean up Multi-ISP 4.4 doc

Browse Source 
Signed-off-by: Tom Eastep <teastep@shorewall.net>

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9698 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2009-03-17 19:55:34 +00:00
parent 5ea4f651eb
commit a9641e69c7
2 changed files with 65 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Shorewall/releasenotes.txt
View File

@ -155,7 +155,7 @@ None.
When a successful start or restart is completed, the script that When a successful start or restart is completed, the script that
executed the command copies itself to to executed the command copies itself to to
/var/lib/shorewall[6/firewall. /var/lib/shorewall[6]/firewall.
5) Dynamic zone support is once again available for IPv4. This support 5) Dynamic zone support is once again available for IPv4. This support
is built on top of ipsets so you must have installed the is built on top of ipsets so you must have installed the

115
docs/MultiISP.xml
View File

@ -134,12 +134,13 @@
<para>Entries in <filename>/etc/shorewall/providers</filename> can <para>Entries in <filename>/etc/shorewall/providers</filename> can
specify that outgoing connections are to be load-balanced between the specify that outgoing connections are to be load-balanced between the
two ISPs. Entries in <filename>/etc/shorewall/tcrules</filename> can be two ISPs. Entries in <filename>/etc/shorewall/tcrules</filename> and
used to direct particular outgoing connections to one ISP or the other. <filename>/etc/shorewall/route_rules</filename> can be used to direct
Use of <filename>/etc/shorewall/tcrules</filename> is not required for particular outgoing connections to one ISP or the other. Use of
<filename>/etc/shorewall/providers</filename> to work, but you must <filename>/etc/shorewall/tcrules</filename> is not required for
select a unique MARK value for each provider so Shorewall can set up the <filename>/etc/shorewall/providers</filename> to work, but in most
correct marking rules for you.</para> cases, you must select a unique MARK value for each provider so
Shorewall can set up the correct marking rules for you.</para>
<para>When you use the <emphasis role="bold">track</emphasis> option in <para>When you use the <emphasis role="bold">track</emphasis> option in
<filename>/etc/shorewall/providers</filename>, connections from the <filename>/etc/shorewall/providers</filename>, connections from the
@ -166,11 +167,15 @@
</listitem> </listitem>
<listitem> <listitem>
<para>You may not use the SAVE or RESTORE options.</para> <para>You may not use the SAVE or RESTORE options unless you also
set HIGH_ROUTE_MARKS=Yes in
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>You may not use connection marking.</para> <para>You may not use connection marking unless you also set
HIGH_ROUTE_MARKS=Yes in
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</caution> </caution>
@ -235,6 +240,11 @@
low-order 8 bits being zero).</para> low-order 8 bits being zero).</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<para>This column may be omitted if you don´t use packet marking
to direct connections to a particular provider and you don´t
specify <emphasis role="bold">track</emphasis> in the OPTIONS
column.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -336,9 +346,10 @@
<para>If you are using <para>If you are using
<filename>/etc/shorewall/providers</filename> because you <filename>/etc/shorewall/providers</filename> because you
have multiple Internet connections, we recommend that you have multiple Internet connections, we recommend that you
specify 'track' even if you don't need it. It helps specify <emphasis role="bold">track</emphasis> even if you
maintain long-term connections in which there are don't need it. It helps maintain long-term connections in
significant periods with no traffic.</para> which there are significant periods with no
traffic.</para>
</important> </important>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -347,27 +358,29 @@
<term>balance</term> <term>balance</term>
<listitem> <listitem>
<para>The providers that have 'balance' specified will get <para>The providers that have <emphasis
outbound traffic load-balanced among them. Balancing will role="bold">balance</emphasis> specified will get outbound
not be perfect, as it is route based, and routes are cached. traffic load-balanced among them. Balancing will not be
This means that routes to often-used sites will always be perfect, as it is route based, and routes are cached. This
over the same provider.</para> means that routes to often-used sites will always be over
the same provider.</para>
<para>By default, each provider is given the same weight (1) <para>By default, each provider is given the same weight (1)
. You can change the weight of a given provider by following . You can change the weight of a given provider by following
<emphasis>balance</emphasis> with "=" and the desired weight <emphasis role="bold">balance</emphasis> with "=" and the
(e.g., balance=2). The weights reflect the relative desired weight (e.g., balance=2). The weights reflect the
bandwidth of the providers connections and should be small relative bandwidth of the providers connections and should
numbers since the kernel actually creates additional default be small numbers since the kernel actually creates
routes for each weight increment.</para> additional default routes for each weight increment.</para>
<important> <important>
<para>If you are using <para>If you are using
<filename>/etc/shorewall/providers</filename> because you <filename>/etc/shorewall/providers</filename> because you
have multiple Internet connections, we recommend that you have multiple Internet connections, we recommend that you
specify 'balance' even if you don't need it. You can still specify <emphasis role="bold">balance</emphasis> even if
use entries in <filename>/etc/shorewall/tcrules</filename> you don't need it. You can still use entries in
to force all traffic to one provider or another.<note> <filename>/etc/shorewall/tcrules</filename> to force all
traffic to one provider or another.<note>
<para>If you don't heed this advice then please read <para>If you don't heed this advice then please read
and follow the advice in <ulink and follow the advice in <ulink
url="FAQ.htm#faq57">FAQ 57</ulink> and <ulink url="FAQ.htm#faq57">FAQ 57</ulink> and <ulink
@ -376,7 +389,8 @@
</important> </important>
<important> <important>
<para>If you specify 'balance' and still find that all <para>If you specify <emphasis
role="bold">balance</emphasis> and still find that all
traffic is going out through only one provider, you may traffic is going out through only one provider, you may
need to install a kernel built with need to install a kernel built with
CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. Several users have CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. Several users have
@ -414,17 +428,18 @@
<term>optional</term> <term>optional</term>
<listitem> <listitem>
<para>Shorewall will determine of this interface is up and <para>Shorewall will determine if this interface is up and
has a configured IPv4 address. If it is not, a warning is has a configured IPv4 address. If it is not, a warning is
issued and this provider is not configured.</para> issued and this provider is not configured.</para>
<note> <note>
<para>'optional' is designed to detect interface states <para><emphasis role="bold">optional</emphasis> is
that will cause <command>shorewall start</command> or designed to detect interface states that will cause
<command>shorewall restart</command> to fail; just because <command>shorewall start</command> or <command>shorewall
an interface is in a state that Shorewall can [re]start restart</command> to fail; just because an interface is in
without error doesn't mean that traffic can actually be a state that Shorewall can [re]start without error doesn't
sent through the interface.</para> mean that traffic can actually be sent through the
interface.</para>
<para>You can supply an 'isusable' <ulink <para>You can supply an 'isusable' <ulink
url="shorewall_extension_scripts.htm">extension url="shorewall_extension_scripts.htm">extension
@ -478,8 +493,8 @@
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<para>For those of you who are terminally confused <para>For those of you who are confused between<emphasis
between<emphasis role="bold"> track</emphasis> and <emphasis role="bold"> track</emphasis> and <emphasis
role="bold">balance</emphasis>:</para> role="bold">balance</emphasis>:</para>
<itemizedlist> <itemizedlist>
@ -500,7 +515,7 @@
<term>COPY</term> <term>COPY</term>
<listitem> <listitem>
<para>A comma-separated list if interface names. Wildcards <para>A comma-separated list of interface names. Wildcards
specified using an asterisk ("*") are permitted (e.g., tun* specified using an asterisk ("*") are permitted (e.g., tun*
).</para> ).</para>
@ -624,7 +639,7 @@
Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00</programlisting> Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00</programlisting>
<para>The above message is somewhat awkwardly phrased. The source IP in <para>The above message is somewhat awkwardly phrased. The source IP in
this incoming packet was 64.86.88.116 and the destination IP address is this incoming packet was 64.86.88.116 and the destination IP address was
206.124.146.176. Another gotcha is that the incoming packet has already 206.124.146.176. Another gotcha is that the incoming packet has already
had the destination IP address changed for DNAT or because the original had the destination IP address changed for DNAT or because the original
outgoing connection was altered by an entry in outgoing connection was altered by an entry in
@ -646,14 +661,14 @@ Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:
<listitem> <listitem>
<para>You are specifying both the <emphasis <para>You are specifying both the <emphasis
role="bold">loose</emphasis> and <emphasis role="bold">loose</emphasis> and <emphasis
role="bold">balance</emphasis> options on your provider(s). This role="bold">balance</emphasis> options on your provider(s). This can
causes individual connections to ping-pong back and forth between cause individual connections to ping-pong back and forth between the
the interfaces which is guaranteed to cause problems.</para> interfaces which is almost guaranteed to cause problems.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>You are redirecting traffic from the local system out of one <para>You are redirecting traffic from the firewall system out of
interface or the other using packet marking in your one interface or the other using packet marking in your
<filename>/etc/shorewall/tcrules</filename> file. A better approach <filename>/etc/shorewall/tcrules</filename> file. A better approach
is to configure the application to use the appropriate local IP is to configure the application to use the appropriate local IP
address (the IP address of the interface that you want the address (the IP address of the interface that you want the
@ -839,14 +854,6 @@ eth3 eth2 16.105.78.4</programlisting></para>
such traffic to a particular ISP.</para> such traffic to a particular ISP.</para>
</section> </section>
<section id="IPSEC">
<title>IPSEC</title>
<para>If you have an IPSEC gateway on your firewall, be sure to arrange
for ESP packets to be routed out of the same interface that you have
configured your keying daemon to use.</para>
</section>
<section id="route_rules"> <section id="route_rules">
<title>/etc/shorewall/route_rules</title> <title>/etc/shorewall/route_rules</title>
@ -947,11 +954,17 @@ gateway:~ #</programlisting>
<para>For those VPN types that use routing to direct traffic to remote <para>For those VPN types that use routing to direct traffic to remote
VPN clients (including but not limited to OpenVPN in routed mode and VPN clients (including but not limited to OpenVPN in routed mode and
PPTP), the VPN software adds a host route to the <emphasis PPTP), the VPN software adds a host route to the <emphasis
role="bold">main</emphasis> table for each VPN client. It follows that role="bold">main</emphasis> table for each VPN client. The best
you must add a routing rule in the 1000-1999 range to specify the approach is to use USE_DEFAULT_RT=Yes as described <link
linkend="USE_DEFAULT_RT">below</link>. If that isn't possible, you
must add a routing rule in the 1000-1999 range to specify the
<emphasis role="bold">main</emphasis> table for traffic addressed to <emphasis role="bold">main</emphasis> table for traffic addressed to
those clients. See<link linkend="Openvpn"> Example 2</link> those clients. See<link linkend="Openvpn"> Example 2</link>
below.</para> below.</para>
<para>If you have an IPSEC gateway on your firewall, be sure to
arrange for ESP packets to be routed out of the same interface that
you have configured your keying daemon to use.</para>
</section> </section>
<section id="Examples"> <section id="Examples">