From a9641e69c7a29fe1bbb7c2b86c7023bc194cef38 Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 17 Mar 2009 19:55:34 +0000 Subject: [PATCH] Clean up Multi-ISP 4.4 doc Signed-off-by: Tom Eastep git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9698 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall/releasenotes.txt | 2 +- docs/MultiISP.xml | 115 +++++++++++++++++++++---------------- 2 files changed, 65 insertions(+), 52 deletions(-) diff --git a/Shorewall/releasenotes.txt b/Shorewall/releasenotes.txt index 9e2d0c5db..625f1fec2 100644 --- a/Shorewall/releasenotes.txt +++ b/Shorewall/releasenotes.txt @@ -155,7 +155,7 @@ None. When a successful start or restart is completed, the script that 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 is built on top of ipsets so you must have installed the diff --git a/docs/MultiISP.xml b/docs/MultiISP.xml index fb927014a..9c07f8714 100644 --- a/docs/MultiISP.xml +++ b/docs/MultiISP.xml @@ -134,12 +134,13 @@ Entries in /etc/shorewall/providers can specify that outgoing connections are to be load-balanced between the - two ISPs. Entries in /etc/shorewall/tcrules can be - used to direct particular outgoing connections to one ISP or the other. - Use of /etc/shorewall/tcrules is not required for - /etc/shorewall/providers to work, but you must - select a unique MARK value for each provider so Shorewall can set up the - correct marking rules for you. + two ISPs. Entries in /etc/shorewall/tcrules and + /etc/shorewall/route_rules can be used to direct + particular outgoing connections to one ISP or the other. Use of + /etc/shorewall/tcrules is not required for + /etc/shorewall/providers to work, but in most + cases, you must select a unique MARK value for each provider so + Shorewall can set up the correct marking rules for you. When you use the track option in /etc/shorewall/providers, connections from the @@ -166,11 +167,15 @@ - You may not use the SAVE or RESTORE options. + You may not use the SAVE or RESTORE options unless you also + set HIGH_ROUTE_MARKS=Yes in + /etc/shorewall/shorewall.conf. - You may not use connection marking. + You may not use connection marking unless you also set + HIGH_ROUTE_MARKS=Yes in + /etc/shorewall/shorewall.conf. @@ -235,6 +240,11 @@ low-order 8 bits being zero). + + This column may be omitted if you don´t use packet marking + to direct connections to a particular provider and you don´t + specify track in the OPTIONS + column. @@ -336,9 +346,10 @@ If you are using /etc/shorewall/providers because you have multiple Internet connections, we recommend that you - specify 'track' even if you don't need it. It helps - maintain long-term connections in which there are - significant periods with no traffic. + specify track even if you + don't need it. It helps maintain long-term connections in + which there are significant periods with no + traffic. @@ -347,27 +358,29 @@ balance - The providers that have 'balance' specified will get - outbound traffic load-balanced among them. Balancing will - not be perfect, as it is route based, and routes are cached. - This means that routes to often-used sites will always be - over the same provider. + The providers that have balance specified will get outbound + traffic load-balanced among them. Balancing will not be + perfect, as it is route based, and routes are cached. This + means that routes to often-used sites will always be over + the same provider. By default, each provider is given the same weight (1) . You can change the weight of a given provider by following - balance with "=" and the desired weight - (e.g., balance=2). The weights reflect the relative - bandwidth of the providers connections and should be small - numbers since the kernel actually creates additional default - routes for each weight increment. + balance with "=" and the + desired weight (e.g., balance=2). The weights reflect the + relative bandwidth of the providers connections and should + be small numbers since the kernel actually creates + additional default routes for each weight increment. If you are using /etc/shorewall/providers because you have multiple Internet connections, we recommend that you - specify 'balance' even if you don't need it. You can still - use entries in /etc/shorewall/tcrules - to force all traffic to one provider or another. + specify balance even if + you don't need it. You can still use entries in + /etc/shorewall/tcrules to force all + traffic to one provider or another. If you don't heed this advice then please read and follow the advice in FAQ 57 and - If you specify 'balance' and still find that all + If you specify balance and still find that all traffic is going out through only one provider, you may need to install a kernel built with CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. Several users have @@ -414,17 +428,18 @@ optional - Shorewall will determine of this interface is up and + Shorewall will determine if this interface is up and has a configured IPv4 address. If it is not, a warning is issued and this provider is not configured. - 'optional' is designed to detect interface states - that will cause shorewall start or - shorewall restart to fail; just because - an interface is in a state that Shorewall can [re]start - without error doesn't mean that traffic can actually be - sent through the interface. + optional is + designed to detect interface states that will cause + shorewall start or shorewall + restart to fail; just because an interface is in + a state that Shorewall can [re]start without error doesn't + mean that traffic can actually be sent through the + interface. You can supply an 'isusable' extension @@ -478,8 +493,8 @@ - For those of you who are terminally confused - between track and For those of you who are confused between track and balance: @@ -500,7 +515,7 @@ COPY - A comma-separated list if interface names. Wildcards + A comma-separated list of interface names. Wildcards specified using an asterisk ("*") are permitted (e.g., tun* ). @@ -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 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 had the destination IP address changed for DNAT or because the original 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: You are specifying both the loose and balance options on your provider(s). This - causes individual connections to ping-pong back and forth between - the interfaces which is guaranteed to cause problems. + role="bold">balance options on your provider(s). This can + cause individual connections to ping-pong back and forth between the + interfaces which is almost guaranteed to cause problems. - You are redirecting traffic from the local system out of one - interface or the other using packet marking in your + You are redirecting traffic from the firewall system out of + one interface or the other using packet marking in your /etc/shorewall/tcrules file. A better approach is to configure the application to use the appropriate local IP address (the IP address of the interface that you want the @@ -839,14 +854,6 @@ eth3 eth2 16.105.78.4 such traffic to a particular ISP. -
- IPSEC - - 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. -
-
/etc/shorewall/route_rules @@ -947,11 +954,17 @@ gateway:~ # For those VPN types that use routing to direct traffic to remote VPN clients (including but not limited to OpenVPN in routed mode and PPTP), the VPN software adds a host route to the main table for each VPN client. It follows that - you must add a routing rule in the 1000-1999 range to specify the + role="bold">main table for each VPN client. The best + approach is to use USE_DEFAULT_RT=Yes as described below. If that isn't possible, you + must add a routing rule in the 1000-1999 range to specify the main table for traffic addressed to those clients. See Example 2 below. + + 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.