diff --git a/docs/MultiISP.xml b/docs/MultiISP.xml index 16b59c35a..ae17297c3 100644 --- a/docs/MultiISP.xml +++ b/docs/MultiISP.xml @@ -286,7 +286,12 @@ Hint: "detect" is appropriate for use in cases where the interface named in the INTERFACE column is dynamically - configured via DHCP etc. + configured via DHCP etc. Be sure, however, that you don't have + stale dhcp client state files in /var/lib/dhcpcd or + /var/lib/dhclient-*.lease because Shorewall + may try to use those stale files to determine the gateway + address. The GATEWAY may be omitted (enter '-') for point-to-point links. @@ -320,28 +325,9 @@ iptables include CONNMARK target and connmark match support (Warning: Standard Debian and - Ubuntu kernels are lacking that + Ubuntu kernels may lack that support!). - - A bug in Shorewall - versions 3.2.0-3.2.10, 3.4.0-3.4.6 and 4.0.0-4.0.2 - prevents proper handling of PREROUTING marks when - HIGH_ROUTE_MARKS=No and the track option is specified. Patches - are available to correct this problem: - - Shorewall version 3.2.0-3.4.3: http://www1.shorewall.net/pub/shorewall/3.2/shorewall-3.2.10/errata/patches/Shorewall/patch-3.2.10-2.diff - - - Shorewall version 3.4.4-3.4.6: http://www1.shorewall.net/pub/shorewall/3.4/shorewall-3.4.6/errata/patches/Shorewall/patch-3.4.6-1.diff - - Shorewall-shell version 4.0.0-4.0.2: http://www1.shorewall.net/pub/shorewall/4.0/shorewall-4.0.2/errata/patches/Shorewall-shell/patch-shell-4.0.2-2.diff - - If you are using /etc/shorewall/providers because you @@ -379,8 +365,9 @@ 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. + /etc/shorewall/tcrules and + /etc/shorewall/route_rules 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 Do not include routing rules that force traffic whose source IP is an address of the INTERFACE to be routed to this provider. Useful for defining providers that are to be - used only when the appropriate packet mark is applied. - Should not be specified together with balance. + used only when the appropriate packet mark is + applied. @@ -429,7 +415,7 @@ Shorewall will determine if this interface is up and - has a configured IPv4 address. If it is not, a warning is + has a configured IP address. If it is not, a warning is issued and this provider is not configured. @@ -444,7 +430,9 @@ You can supply an 'isusable' extension script to extend Shorewall's interface state - detection. + detection. See also the Gateway Monitoring and + Failover section below. @@ -479,11 +467,12 @@ Indicates that a default route through the provider - should be added to the default routing table (table 253). If - a weight is given, a balanced - route is added with the weight of this provider equal to the + should be added to the default + routing table (table 253). If a + weight is given, a balanced route + is added with the weight of this provider equal to the specified weight. If the option - is given without a weight, an + is given without a weight, a separate default route is added through the provider's gateway; the route has a metric equal to the provider's NUMBER. The option is ignored with a warning message if @@ -500,7 +489,8 @@ track governs incoming - connections. + connections (but is also useful for binding long-running + connections to the same interface). @@ -534,8 +524,9 @@ What an entry in the Providers File Does Adding another entry in the providers file simply creates an - alternate routing table for you. The table will usually contain two - routes: + alternate routing table for you (see the LARTC Howto). The table will usually + contain two routes: @@ -558,12 +549,13 @@ be restricted using the COPY column which lists the interfaces whose routes you want copied. You will generally want to include all local interfaces in this list. You should exclude the loopback interface (lo) - and any interfaces that do not have an IPv4 configuration. You should - also omit interfaces like tun - interfaces that are created dynamically. Traffic to networks handled by - those interfaces should be routed through the main table using entries - in /etc/shorewall/route_rules (see Example 2 below). + and any interfaces that do not have an IP configuration. You should also + omit interfaces like tun interfaces + that are created dynamically. Traffic to networks handled by those + interfaces should be routed through the main table using entries in + /etc/shorewall/route_rules (see Example 2 below) or by using USE_DEFAULT_RT=Yes. In addition: @@ -624,6 +616,42 @@ /etc/shorewall/route_rules. +
+ /etc/shorewall/masq and Multi-ISP + + If you masquerade a local network, you will need to add masquerade + rules for both external interfaces. Referring to the diagram above, if + each of the interfaces has only a single IP address and you have no + systems with public IP addresses behind your firewall, then I suggest + the following simple entries: + + #INTERFACE SOURCE ADDRESS +eth0 0.0.0.0/0 206.124.146.176 +eth1 0.0.0.0/0 130.252.99.27 + + If you have a public subnet (for example 206.124.146.176/30) + behind your firewall, then use exclusion: + + #INTERFACE SOURCE ADDRESS +eth0 !206.124.146.176/29 206.124.146.176 +eth1 0.0.0.0/0 130.252.99.27 + + Note that exclusion is only used on the interface corresponding to + internal subnetwork. + + If you have multiple IP addresses on one of your interfaces, you + can use a similar technique -- simple exclude the smallest network that + contains all of those addresses from being masqueraded. + + + Entries in /etc/shorewall/masq have no + effect on which ISP a particular connection will be sent through. That + is rather the purpose of entries in + /etc/shorewall/tcrules and + /etc/shorewall/route_rules. + +
+
Martians @@ -714,66 +742,36 @@ net eth1 detect … #SOURCE DESTINATION POLICY LIMIT:BURST net net DROP - Regardless of whether you have masqueraded hosts or not, the - following entries are required in - /etc/shorewall/masq if you plan to redirect - connections from the firewall using entries in - /etc/shorewall/tcrules or if you specify balance on your providers. + /etc/shorewall/masq: - #INTERFACE SUBNET ADDRESS -eth0 130.252.99.27 206.124.146.176 -eth1 206.124.146.176 130.252.99.27 + #INTERFACE SOURCE ADDRESS +eth0 0.0.0.0/0 206.124.146.176 +eth1 0.0.0.0/0 130.252.99.27 +
- Those entries ensure that traffic originating on the firewall and - redirected via packet marks always has the source IP address - corresponding to the interface that it is routed out of. +
+ Routing a Particular Application Through a Specific + Interface - - If you have a Dynamic IP address on either of the interfaces, - you can use shell variables to construct the above rules. For example, - if eth0 had a dynamic IP - address, then: - - /etc/shorewall/params: - - ETH0_IP=$(find_first_interface_address eth0) - - For optional interfaces, use - find_first_interface_address_if_any in place of - find_first_interface_address. - - /etc/shorewall/masq: - - #INTERFACE SUBNET ADDRESS -eth0 130.252.99.27 $ETH0_IP -eth1 $ETH0_IP 130.252.99.27 - - - If you have masqueraded hosts, be sure to update - /etc/shorewall/masq to masquerade to both ISPs. For - example, if you masquerade all hosts connected to eth2 then: - - #INTERFACE SUBNET ADDRESS -eth0 eth2 206.124.146.176 -eth1 eth2 130.252.99.27 - - - Entries in /etc/shorewall/masq have no - effect on which ISP a particular connection will be sent through. That - is rather the purpose of entries in - /etc/shorewall/tcrules or - /etc/shorewall/route_rules. - + This continues the example in the preceding section. Now suppose that you want to route all outgoing SMTP traffic from your local network through ISP 2. You would make this entry in /etc/shorewall/tcrules + url="traffic_shaping.htm">/etc/shorewall/tcrules (and if you are + running a version of Shorewall earlier than 3.0.0, you would set + TC_ENABLED=Yes in /etc/shorewall/shorewall.conf). #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) 2:P <local network> 0.0.0.0/0 tcp 25 + + Note that traffic from the firewall itself must be handled in a + different rule: + + #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST +# PORT(S) +2 $FW 0.0.0.0/0 tcp 25
@@ -793,9 +791,7 @@ eth1 eth2 130.252.99.27 For each external interface, you need to add an entry to - /etc/shorewall/masq for each internal network - that needs to be masqueraded (or use SNAT) through that - interface. + /etc/shorewall/masq. @@ -808,20 +804,18 @@ ISP2 2 2 main eth1 130.252.99.254 track,ba ISP3 3 3 main eth3 16.105.78.254 track,balance eth2 /etc/shorewall/masq:#INTERFACE SUBNET ADDRESS -eth0 130.252.99.27 206.124.146.176 -eth3 130.252.99.27 16.105.78.4 -eth1 206.124.146.176 130.252.99.27 -eth3 206.124.146.176 16.105.78.4 -eth0 16.106.78.4 206.124.146.176 -eth1 16.106.78.4 130.252.99.27 -eth0 eth2 206.124.146.176 -eth1 eth2 130.252.99.27 -eth3 eth2 16.105.78.4 +eth0 0.0.0.0/0 206.124.146.176 +eth1 0.0.0.0/0 130.252.99.27 +eth3 0.0.0.0/0 16.105.78.4
Applications running on the Firewall + As noted above, separate + entries in /etc/shorewall/tcrules are required for + traffic originating from the firewall. + Experience has shown that in some cases, problems occur with applications running on the firewall itself. This is especially true when you have specified routefilter on