mirror of
https://gitlab.com/shorewall/code.git
synced 2025-06-24 19:51:40 +02:00
Describe a way to improve provider selection from the firewall
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
parent
c5549ff21e
commit
0005bb697b
@ -710,7 +710,7 @@
|
|||||||
up.</para>
|
up.</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section id="masq">
|
||||||
<title>./etc/shorewall/masq and Multi-ISP</title>
|
<title>./etc/shorewall/masq and Multi-ISP</title>
|
||||||
|
|
||||||
<para>If you masquerade a local network, you will need to add masquerade
|
<para>If you masquerade a local network, you will need to add masquerade
|
||||||
@ -976,51 +976,6 @@ eth1 0.0.0.0/0 130.252.99.27
|
|||||||
eth3 0.0.0.0/0 16.105.78.4</programlisting></para>
|
eth3 0.0.0.0/0 16.105.78.4</programlisting></para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id="Local">
|
|
||||||
<title>Applications running on the Firewall -making them use a
|
|
||||||
particular provider</title>
|
|
||||||
|
|
||||||
<para>As <link linkend="Applications">noted above</link>, separate
|
|
||||||
entries in <filename>/etc/shorewall/mangle</filename> are required for
|
|
||||||
traffic originating from the firewall.</para>
|
|
||||||
|
|
||||||
<para>Experience has shown that in some cases, problems occur with
|
|
||||||
applications running on the firewall itself. This is especially true
|
|
||||||
when you have specified <emphasis role="bold">routefilter</emphasis> on
|
|
||||||
your external interfaces in /etc/shorewall/interfaces (see <link
|
|
||||||
linkend="Martians">above</link>). When this happens, it is suggested
|
|
||||||
that you have the application use specific local IP addresses rather
|
|
||||||
than 0.</para>
|
|
||||||
|
|
||||||
<para>Examples:</para>
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>Squid: In <filename>squid.conf</filename>, set <emphasis
|
|
||||||
role="bold">tcp_outgoing_address</emphasis> to the IP address of the
|
|
||||||
interface that you want Squid to use.</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>In OpenVPN, set <emphasis role="bold">local
|
|
||||||
</emphasis>(<emphasis role="bold">--local</emphasis> on the command
|
|
||||||
line) to the IP address that you want the server to receive
|
|
||||||
connections on.</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
|
|
||||||
<para>Note that some traffic originating on the firewall doesn't have a
|
|
||||||
SOURCE IP address before routing. At least one Shorewall user reports
|
|
||||||
that an entry in <filename>/etc/shorewall/rtrules</filename> with 'lo'
|
|
||||||
in the SOURCE column seems to be the most reliable way to direct such
|
|
||||||
traffic to a particular ISP.</para>
|
|
||||||
|
|
||||||
<para>Example:</para>
|
|
||||||
|
|
||||||
<programlisting>#SOURCE DEST PROVIDER PRIORITY
|
|
||||||
lo - shorewall 1000</programlisting>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="rtrules">
|
<section id="rtrules">
|
||||||
<title>/etc/shorewall/rtrules (formerly
|
<title>/etc/shorewall/rtrules (formerly
|
||||||
/etc/shorewall/route_rules)</title>
|
/etc/shorewall/route_rules)</title>
|
||||||
@ -1186,6 +1141,108 @@ gateway:~ #</programlisting>Note that because we used a priority of 1000, the
|
|||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
<section id="Local">
|
||||||
|
<title>Applications running on the Firewall - making them use a
|
||||||
|
particular provider</title>
|
||||||
|
|
||||||
|
<para>As <link linkend="Applications">noted above</link>, separate
|
||||||
|
entries in <filename>/etc/shorewall/mangle</filename> are required for
|
||||||
|
traffic originating from the firewall.</para>
|
||||||
|
|
||||||
|
<para>Experience has shown that in some cases, problems occur with
|
||||||
|
applications running on the firewall itself. This is especially true
|
||||||
|
when you have specified <emphasis role="bold">routefilter</emphasis> on
|
||||||
|
your external interfaces in /etc/shorewall/interfaces (see <link
|
||||||
|
linkend="Martians">above</link>). When this happens, it is suggested
|
||||||
|
that you have the application use specific local IP addresses rather
|
||||||
|
than 0.</para>
|
||||||
|
|
||||||
|
<para>Examples:</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>Squid: In <filename>squid.conf</filename>, set <emphasis
|
||||||
|
role="bold">tcp_outgoing_address</emphasis> to the IP address of the
|
||||||
|
interface that you want Squid to use.</para>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para>In OpenVPN, set <emphasis role="bold">local
|
||||||
|
</emphasis>(<emphasis role="bold">--local</emphasis> on the command
|
||||||
|
line) to the IP address that you want the server to receive
|
||||||
|
connections on.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>Note that some traffic originating on the firewall doesn't have a
|
||||||
|
SOURCE IP address before routing. At least one Shorewall user reports
|
||||||
|
that an entry in <filename>/etc/shorewall/rtrules</filename> with 'lo'
|
||||||
|
in the SOURCE column seems to be the most reliable way to direct such
|
||||||
|
traffic to a particular ISP.</para>
|
||||||
|
|
||||||
|
<para>Example:</para>
|
||||||
|
|
||||||
|
<programlisting>#SOURCE DEST PROVIDER PRIORITY
|
||||||
|
lo - shorewall 1000</programlisting>
|
||||||
|
|
||||||
|
<para>Another option is to re-arrange the routing rules. Here is an
|
||||||
|
example of the routing rules produced with USE_DEFAULT_RT=Yes and
|
||||||
|
without the <option>loose</option> option being specified on the
|
||||||
|
providers:</para>
|
||||||
|
|
||||||
|
<programlisting>0: from all lookup local
|
||||||
|
1: from all fwmark 0x80000/0x80000 lookup TProxy
|
||||||
|
999: from all lookup main
|
||||||
|
1000: from 70.90.191.121 lookup ComcastB
|
||||||
|
1000: from 70.90.191.123 lookup ComcastB
|
||||||
|
1000: from 10.0.0.4 lookup ComcastC
|
||||||
|
10000: from all fwmark 0x10000/0x30000 lookup ComcastB
|
||||||
|
10001: from all fwmark 0x20000/0x30000 lookup ComcastC
|
||||||
|
32765: from all lookup balance
|
||||||
|
32767: from all lookup default
|
||||||
|
</programlisting>
|
||||||
|
|
||||||
|
<para>Note the rules with priority 1000 -- these rules are configured by
|
||||||
|
Shorewall when the providers do not have the <option>loose</option>
|
||||||
|
option. If that option is specified, the rules become:</para>
|
||||||
|
|
||||||
|
<programlisting>0: from all lookup local
|
||||||
|
1: from all fwmark 0x80000/0x80000 lookup TProxy
|
||||||
|
999: from all lookup main
|
||||||
|
10000: from all fwmark 0x10000/0x30000 lookup ComcastB
|
||||||
|
10001: from all fwmark 0x20000/0x30000 lookup ComcastC
|
||||||
|
32765: from all lookup balance
|
||||||
|
32767: from all lookup default
|
||||||
|
</programlisting>
|
||||||
|
|
||||||
|
<para>Now, if we configure the following rtrules:</para>
|
||||||
|
|
||||||
|
<programlisting>#SOURCE DEST PROVIDER PRIORITY
|
||||||
|
70.90.191.121 - ComcastB 20000
|
||||||
|
70.90.191.123 - ComcastB 20000
|
||||||
|
10.0.0.4 - ComcastC 20000</programlisting>
|
||||||
|
|
||||||
|
<para>Then the routing rules become:</para>
|
||||||
|
|
||||||
|
<programlisting>0: from all lookup local
|
||||||
|
1: from all fwmark 0x80000/0x80000 lookup TProxy
|
||||||
|
999: from all lookup main
|
||||||
|
10000: from all fwmark 0x10000/0x30000 lookup ComcastB
|
||||||
|
10001: from all fwmark 0x20000/0x30000 lookup ComcastC
|
||||||
|
20000: from 70.90.191.121 lookup ComcastB
|
||||||
|
20000: from 70.90.191.123 lookup ComcastB
|
||||||
|
20000: from 10.0.0.4 lookup ComcastC
|
||||||
|
32765: from all lookup balance
|
||||||
|
32767: from all lookup default
|
||||||
|
</programlisting>
|
||||||
|
|
||||||
|
<para>These change give marks priority over the source IP address, so
|
||||||
|
marking a packet will send it to the proscribed provider, regardless of
|
||||||
|
its source IP address. If you take this approach, be sure to include
|
||||||
|
the<link linkend="masq"> proper rules in /etc/shorewall/masq</link> to
|
||||||
|
insure that the correct source IP address is used.</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section id="routes">
|
<section id="routes">
|
||||||
<title>/etc/shorewall/routes File</title>
|
<title>/etc/shorewall/routes File</title>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user