html
Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 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 “GNU Free Documentation License”.
2010/11/17
Table of Contents
Warning
Warning
1 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Output of man ip
The routing changes are made and the route cache is purged when
Shorewall is started and when Shorewall is restarted (unless you specify
the "-n" option to shorewall restart). Ideally, restarting the packet filter
should have no effect on routing.
Overview
Let's assume that a firewall is connected via two separate Ethernet interfaces to
two different ISPs.[1] as in the following diagram.
2 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
eth2 connects to the local LAN. Its IP configuration is not relevant to this
discussion.
When you use the track option in /etc/shorewall/providers, 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.
3 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Shorewall will set up the routing and will update the /etc/iproute2/rt_tables to
include the table names and numbers of the tables that it adds.
Caution
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 unless you also set
HIGH_ROUTE_MARKS=Yes in /etc/shorewall/shorewall.conf.
The /etc/shorewall/providers file can also be used in other routing scenarios. See the
Squid documentation for an example.
/etc/shorewall/providers File
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.
NAME
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.
NUMBER
A number between 1 and 252. This becomes the routing table number for
the generated table for this provider.
MARK
Use connection marks for traffic shaping, provided that you assign those
marks in the FORWARD chain.
Use mark values > 255 for provider marks in this column.
4 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
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.
DUPLICATE
INTERFACE
The name of the interface to the provider. Where multiple providers share
the same interface, you must follow the name of the interface by a colon (":")
and the IP address assigned by this provider (e.g., eth0:206.124.146.176).
See below for additional considerations.
GATEWAY
You can enter detect here and Shorewall will attempt to automatically
determine the gateway IP address.
Hint: "detect" is appropriate for use in cases where the interface named in
the INTERFACE column is dynamically 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.
OPTIONS
track
Important
5 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Use of this feature requires that your kernel and iptables include
CONNMARK target and connmark match support (Warning: Until
recently, standard Debian™ and Ubuntu™ kernels lacked that support.
Both Lenny and Jaunty do have the proper support).
Important
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.
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.
Important
6 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Note
Important
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 reported that this change has corrected similar
problems.
loose
notrack
Added in Shorewall 4.4.3. This option turns off the track option.
optional
Note
7 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Note
src=source-address
Specifies the source address to use when routing to this provider and
none is known (the local client has bound to the 0 address). May not be
specified when an address is given in the INTERFACE column. If this
option is not used, Shorewall substitutes the primary IP address on the
interface named in the INTERFACE column.
mtu=number
Specifies the MTU when forwarding through this provider. If not given,
the MTU of the interface named in the INTERFACE column is assumed.
fallback[=weight]
For those of you who are confused between track and balance:
COPY
8 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Note
Adding another entry in the providers file simply creates an alternate routing
table for you (see the LARTC Howto). The table will usually contain two routes:
Note that the first route is omitted if "-" is specified as the GATEWAY; in that
case, the default route does not specify a gateway (point-to-point link).
If the DUPLICATE column is non-empty, then routes from the table named in that
column are copied into the new table. By default, all routes (except default
routes) are copied. The set of routes copied can 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 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:
2. If you specify track, then connections which have had at least one packet
arrive on the interface listed in the INTERFACE column have their
connection mark set to the value in the MARK column. In the PREROUTING
chain, packets with a connection mark have their packet mark set to the
value of the associated connection mark; packets marked in this way bypass
any prerouting rules that you create in /etc/shorewall/tcrules. This ensures that
packets associated with connections from outside are always routed out of
the correct interface.
3. If you specify balance, then Shorewall will replace the 'default' route with
weight 100 in the 'main' routing table with a load-balancing route among
those gateways where balance was specified. So if you configure default
routes, be sure that their weight is less than 100 or the route added by
Shorewall will not be used.
That's all that these entries do. You still have to follow the principle stated in the
Shorewall Routing documentation:
9 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
2. Once routing determines where the packet is to go, the firewall (Shorewall)
determines if the packet is allowed to go there and controls rewriting of the
SOURCE IP address (SNAT/MASQUERADE).
The bottom line is that if you want traffic to go out through a particular provider
then you must mark that traffic with the provider's MARK value in /etc/shorewall
/tcrules and you must do that marking in the PREROUTING chain; or, you must
provide the appropriate rules in /etc/shorewall/route_rules.
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:
If you have multiple IP addresses on one of your interfaces, you can use a similar
technique -- simplY exclude the smallest network that contains all of those
addresses from being masqueraded.
Warning
Martians
One problem that often arises with Multi-ISP configuration is 'Martians'. If your
Internet interfaces are configured with the routefilter option in /etc/shorewall
/interfaces (remember that if you set that option, you should also select
logmartians), then things may not work correctly and you will see messages like
this:
Feb 9 17:23:45 gw.ilinx kernel: martian source 206.124.146.176 from 64.86.88.116, on dev eth1
Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00
10 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
1. You have connected both of your external interfaces to the same hub/switch.
Connecting multiple firewall interfaces to a common hub or switch is always
a bad idea that will result in hard-to-diagnose problems.
2. You are specifying both the loose and 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.
3. 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 application to use). See below.
If all else fails, remove the routefilter option from your external interfaces. If you
do this, you may wish to add rules to log and drop packets from the Internet that
have source addresses in your local networks. For example, if the local LAN in the
above diagram is 192.168.1.0/24, then you would add this rule:
Be sure the above rule is added before any other rules with net in the SOURCE
column.
Example
The configuration in the figure at the top of this section would be specified in
/etc/shorewall/providers as follows.
/etc/shorewall/interfaces:
/etc/shorewall/policy:
11 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
/etc/shorewall/masq:
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 (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).
Note that traffic from the firewall itself must be handled in a different rule:
Port Forwarding
Normal port forwarding rules such as the following will forward from both
providers.
/etc/shorewall/rules:
Continuing the above example, to forward only connection requests from ISP 1,
you can either:
or
12 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
When there are more than two providers, you need to extend the two-provider
case in the expected way:
If we extend the above example to add eth3 with IP address 16.105.78.4 with
gateway 16.105.78.254, then:
/etc/shorewall/providers:
/etc/shorewall/masq:
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 your external interfaces in /etc/shorewall/interfaces (see above).
When this happens, it is suggested that you have the application use specific
local IP addresses rather than 0.
Examples:
In OpenVPN, set local (--local on the command line) to the IP address that
you want the server to receive connections on.
Note that some traffic originating on the firewall doesn't have a SOURCE IP
13 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
address before routing. At least one Shorewall user reports that an entry in
/etc/shorewall/route_rules with 'lo' in the SOURCE column seems to be the most
reliable way to direct such traffic to a particular ISP.
Example:
/etc/shorewall/route_rules
The route_rules file allows assigning certain traffic to a particular provider just as
entries in the tcrules file. The difference between the two files is that entries in
route_rules are independent of Netfilter.
Routing Rules
Routing rules are maintained by the Linux kernel and can be displayed using the
ip rule ls command. When routing a packet, the rules are processed in turn until
the packet is successfully routed.
gateway:~ # ip rule ls
0: from all lookup local <=== Local (to the firewall) IP addresses
10001: from all fwmark 0x1 lookup Blarg <=== This and the next rule are generated by the
10002: from all fwmark 0x2 lookup Comcast 'MARK' values in /etc/shorewall/providers.
20000: from 206.124.146.176 lookup Blarg <=== This and the next rule are generated unless
20256: from 24.12.22.33 lookup Comcast 'loose' is specified; based in the output of 'ip addr ls'
32766: from all lookup main <=== This is the routing table shown by 'iproute -n'
32767: from all lookup default <=== This table is usually empty
gateway:~ #
In the above example, there are two providers: Blarg and Comcast with MARK 1
going to Blarg and mark 2 going to Comcast.
SOURCE (Optional)
DEST (Optional)
If you choose to omit either SOURCE or DEST, place "-" in that column. Note
that you may not omit both SOURCE and DEST.
14 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
PROVIDER
The provider to route the traffic through. May be expressed either as the
provider name or the provider number.
PRIORITY
The rule's priority which determines the order in which the rules are
processed.
11000- 11999 After 'MARK' rules but before Shorewall-generated rules for
ISP interfaces.
Rules with equal priority are applied in the order in which they appear in
the file.
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. 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.
Examples
Example 1: You want all traffic entering the firewall on eth1 to be routed
through Comcast.
gateway:~ # ip rule ls
0: from all lookup local
1000: from all iif eth1 lookup Comcast
10001: from all fwmark 0x1 lookup Blarg
10002: from all fwmark 0x2 lookup Comcast
20000: from 206.124.146.176 lookup Blarg
20256: from 24.12.22.33 lookup Comcast
32766: from all lookup main
32767: from all lookup default
gateway:~ #
15 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Note that because we used a priority of 1000, the test for eth1 is inserted before
the fwmark tests.
/etc/shorewall/routes File
Beginning with Shorewall 4.4.15, additional routes can be added to the provider
routing tables using the /etc/shorewall/routes file.
PROVIDER
DEST
GATEWAY (Optional)
DEVICE (Optional)
Specifies the device route. If neither DEVICE nor GATEWAY is given, then
the INTERFACE specified for the PROVIDER in shorewall-providers (5).
The following table gives some example entries in the file and the ip route
command which results.
To look at the various routing tables, you must use the ip utility. To see the entire
routing configuration (including rules), the command is shorewall show
routing. To look at an individual provider's table use ip route ls table provider
16 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Example:
USE_DEFAULT_RT
1. Both the DUPLICATE and the COPY columns in the providers file must
remain empty or contain "-". The individual provider routing tables
generated when USE_DEFAULT_RT=Yes contain only a host route to the
gateway and a default route via the gateway.
2. The balance option is assumed for all interfaces that do not have the loose
option. When you want both balance and loose, both must be specified.
4. Packets are sent through the main routing table by a routing rule with
priority 999. The priority range 1-998 may be used for inserting rules that
bypass the main table.
17 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
6. For ppp interfaces, the GATEWAY may remain unspecified ("-"). For those
interfaces managed by dhcpcd or dhclient, you may specify 'detect' in the
GATEWAY column; Shorewall will use the dhcp client's database to
determine the gateway IP address. All other interfaces must have a
GATEWAY specified explicitly.
Example (send all traffic through the 'shorewall' provider unless otherwise
directed).
/etc/shorewall/providers:
/etc/shorewall/route_rules:
There are a couple of options available for monitoring the status of provider links
and taking action when a failure occurs. Both of these options assume that each
provider has a unique nexthop gateway; if two or more providers use the same
gateway router then neither option is suitable.
SWPING
Shorewall includes a sample monitoring script swping. The swping file is available in
the main directory contained in the Shorewall-common tarball and is included in
the Shorewall-common documentation directory in the Shorewall-common RPM.
The script is inspired by Angsuman Chakraborty's gwping script.
Important
These samples are offered as is — they work for me but I don't make
any claim that they will work for anyone else. But if you have a need
for automated link monitoring, they offer you a place to start.
Important
18 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
The script works by sending pings to target IP addresses through each external
interface. These targets must not depend on any routes other than those that are
present in the main routing table. That ensures that a route is available to the
target even when the target's interface is not working and Shorewall has omitted
it from the routing configuration. An interface is assumed to be up when a
specified number (UP_COUNT) of consecutive ping operations succeed. Similarly,
an interface is assumed to be down when a specified number (DOWN_COUNT) of
consecutive ping operations fail. You can specify the interval between pings
(PING_INTERVAL).
The script monitors two interfaces but it is a trivial exercise to extend it to more
than two. At the top are a number of variables to set:
#
# IP family -- 4 or 6
#
FAMILY=4
#
# The commands to run when the status of a line changes. Multiple commands may be specified
# when separated by semicolons (";")
#
COMMAND=
...
#
# Interfaces to monitor -- you may use shell variables from your params file
#
IF1=eth0
IF2=eth1
#
# Sites to Ping. Must depend only on routes in the 'main' routing table. If not specified,
# the interface is assumed to be managed by dhcpcd and the script uses the gateway address
# from /var/lib/dhcpcd/dhcpcd-${IFx}.info
#
TARGET1=
TARGET2=
#
# How often to ping
#
PING_INTERVAL=5
#
# Value for ping's -W option
#
PING_TIMEOUT=2
#
# This many successive pings must succeed for the interface to be marked up when it is down
#
UP_COUNT=5
#
# This many successive pings must fail for the interface to be marked down when it is up
#
DOWN_COUNT=2
19 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
If you leave COMMAND empty, the script sets its value automatically depending
on whether Shorewall-lite is installed.
The .status files are intended to be used with the following /etc/shorewall/isusable
script.
local status=0
return $status
Also included is a sample init script ( swping.init) to start the monitoring daemon.
Copy it to /etc/init.d/swping and use your distribution's SysV init tools to cause it to
be run at boot. It works on OpenSuSE™ 11.0 -- YMMV. Modify the PROG and
STATEDIR variables as needed.
As an alternative to using the init script, you can add the following to /etc/shorewall
/started:
1. It only works on IPv4 or IPv6 but not both at once. So if you want to monitor
both IPv4 and IPv6, you need to clone the script are run two copies; one for
IPv4 and one for IPv6.
20 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
ping and being able to ping the default gateway is not a surefire indication
that the provider is usable. The method of determining whether a site is up
or down is also crude.
5. It is tricky to configure a system such that the system works correctly when
one of its providers is down unless you largely don't care which interface is
used.
Link Status Monitor was written by Mika Ilmaranta <ilmis at nullnet.fi> and
performs more sophisticated monitoring than the simple swping script described
in the preceding section.
Important
Like many Open Source products, LSM is poorly documented. It's main
configuration file is normally kept in /etc/lsm/lsm.conf, but the file's name is passed
as an argument to the lsm program so you can name it anything you want.
The sample lsm.conf included with the product shows some of the possibilities for
configuration. One feature that is not mentioned in the sample is that an
"include" directive is supported. This allows additional files to be sourced in from
the main configuration file.
LSM monitors the status of the links defined in its configuration file and runs a
user-provided script when the status of a link changes. The script name is
specified in the eventscript option in the configuration file. Key arguments to the
script are as follows:
$1
$2
$4
$5
21 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Warning
These files only work with Shorewall-perl 4.4 Beta 2 and later.
/etc/shorewall/isusable:
local status=0
#
# Read the status file (if any) created by /etc/lsm/script
#
[ -f ${VARDIR}/${1}.status ] && status=$(cat ${VARDIR}/${1}.status)
return $status
/etc/shorewall/lib.private:
###############################################################################
# Create /etc/lsm/shorewall.conf
# Remove the current interface status files
# Start lsm
###############################################################################
start_lsm() {
#
# Kill any existing lsm process(es)
#
killall lsm 2> /dev/null
#
# Create the Shorewall-specific part of the LSM configuration. This file is
# included by /etc/lsm/lsm.conf
#
# Avvanta has a static gateway while Comcast's is dynamic
#
cat <<EOF > /etc/lsm/shorewall.conf
22 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
connection {
name=Avvanta
checkip=206.124.146.254
device=$EXT_IF
ttl=2
}
connection {
name=Comcast
checkip=${SW_ETH0_GATEWAY:-71.231.152.1}
device=$COM_IF
ttl=1
}
EOF
#
# Since LSM assumes that interfaces start in the 'up' state, remove any
# existing status files that might have an interface in the down state
#
rm -f /var/lib/shorewall/*.status
#
# Run LSM -- by default, it forks into the background
#
/usr/sbin/lsm /etc/lsm/lsm.conf >> /var/log/lsm
}
Note
/etc/shorewall/started:
##################################################################################
# [re]start lsm if this is a 'start' command or if lsm isn't running
##################################################################################
if [ "$COMMAND" = start -o -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then
start_lsm
fi
/etc/shorewall/restored:
##################################################################################
# Start lsm if it isn't running
##################################################################################
if [ -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then
start_lsm
fi
/etc/lsm/lsm.conf:
#
# Defaults for the connection entries
#
defaults {
name=defaults
checkip=127.0.0.1
23 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
eventscript=/etc/lsm/script
max_packet_loss=20
max_successive_pkts_lost=7
min_packet_loss=5
min_successive_pkts_rcvd=10
interval_ms=2000
timeout_ms=2000
warn_email=teastep@shorewall.net
check_arp=0
sourceip=
ttl=0
}
include /etc/lsm/shorewall.conf
/etc/lsm/script
#!/bin/sh
#
# (C) 2009 Mika Ilmaranta <ilmis@nullnet.fi>
# (C) 2009 Tom Eastep <teastep@shorewall.net>
#
# License: GPLv2
#
STATE=${1}
NAME=${2}
CHECKIP=${3}
DEVICE=${4}
WARN_EMAIL=${5}
REPLIED=${6}
WAITING=${7}
TIMEOUT=${8}
REPLY_LATE=${9}
CONS_RCVD=${10}
CONS_WAIT=${11}
CONS_MISS=${12}
AVG_RTT=${13}
if [ -f /usr/share/shorewall-lite/lib.base ]; then
VARDIR=/var/lib/shorewall-lite
STATEDIR=/etc/shorewall-lite
else
VARDIR=/var/lib/shorewall
STATEDIR=/etc/shorewall
fi
Hi,
24 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Packet counters:
replied = ${REPLIED} packets replied
waiting = ${WAITING} packets waiting for reply
timeout = ${TIMEOUT} packets that have timed out (= packet loss)
reply_late = ${REPLY_LATE} packets that received a reply after timeout
cons_rcvd = ${CONS_RCVD} consecutively received replies in sequence
cons_wait = ${CONS_WAIT} consecutive packets waiting for reply
cons_miss = ${CONS_MISS} consecutive packets that have timed out
avg_rtt = ${AVG_RTT} average rtt, notice that waiting and timed out packets have rtt = 0 when calculating this
EOM
exit 0
#EOF
a. Only Ethernet (or Ethernet-like) interfaces can be used. For inbound traffic,
the MAC addresses of the gateway routers are used to determine which
provider a packet was received through. Note that only routed traffic can be
categorized using this technique.
d. This feature requires Realm Match support in your kernel and iptables.
e. You must add route_rules entries for networks that are accessed through a
particular provider.
f. If you have additional IP addresses through either provider, you must add
route_rules to direct traffic FROM each of those addresses through the
appropriate provider.
g. You must manually add MARK rules for traffic known to come from each
provider.
25 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Taken together, b. and h. effectively preclude using this technique with dynamic
IP addresses.
Example:
This is our home network circa fall 2008. We have two Internet providers:
Because the old Compaq™ Presario™ that I use for a firewall only has three PCI
slots and no onboard Ethernet, it doesn't have enough Ethernet controllers to
support both providers. So I use a Linksys WRT300n pre-N router as a gateway to
Comcast. Note that because the Comcast IP address is dynamic, I could not share
a single firewall interface between the two providers directly.
26 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
The local wired network in my office is connected to both gateways and uses the
private (RFC 1918) network 172.20.1.0/24. The Comcast gateway has local IP
address 172.20.1.1 while the Avvanta gateway has local IP address 172.20.1.254.
Ursa's eth0 interface has a single IP address (172.20.1.130).
27 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
2. Both wired providers have the loose option. This prevents Shorewall from
automatically generating routing rules based on the source IP address.
4. I always disable the wireless interface when the laptop is connected to the
wired network.
5. I use a different Shorewall configuration when I take the laptop on the road.
Those rules direct traffic to the five static Avvanta IP addresses (only two are
currently used) through the avvanta provider.
#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH TOS CON
# PORT(S)
2 $FW 0.0.0.0/0 tcp 21
2 $FW 0.0.0.0/0 tcp - - - - - - -
2 $FW 0.0.0.0/0 tcp 119
These rules:
The remaining files are for a rather standard two-interface config with a bridge as
the local interface.
zones:
policy:
28 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
interfaces:
Note
wlan0is the wireless adapter in the notebook. Used when the laptop is
in our home but not connected to the wired network.
masq:
Note
Two providers:
29 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Because of the speed of the cable provider, all traffic uses that provider unless
there is a specific need for the traffic to use the DSL line.
As a consequence, I have disabled all route filtering on the firewall and only use
the balance option in /etc/shorewall/providers on the Comcast provider whose default
route in the main table is established by DHCP. By specifying the fallback option
on Avvanta, I ensure that there is still a default route if Comcast is down. lsm is
used to monitor the links.
/etc/sysctl.conf:
net.ipv4.conf.all.rp_filter = 0
/etc/shorewall/shorewall.conf:
30 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
ROUTE_FILTER=No
RESTORE_DEFAULT_ROUTE=No
/etc/shorewall/providers:
The loose option on Avvanta results in fewer routing rules. The first two routing
rules below insure that all traffic from Avvanta-assigned IP addresses is sent via
the Avvanta provider. The 'tun*' included in the COPY column is there because I
run a routed OpenVPN server on the firewall.
/etc/shorewall/route_rules:
Routing Rules
Table Avvanta:
31 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
Table Comcast:
Table default:
Table local:
Table main:
/etc/shorewall/interfaces:
/etc/shorewall/masq:
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
32 di 33 03/12/2010 16:02
Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html
All traffic leaving eth3 must use the dynamic IP address assigned to that interface
as the SOURCE address. All traffic leaving eth0 that does not have a SOURCE
address falling within the Avvanta subnet (206.124.146.0/24) must have its
SOURCE address changed to 206.124.146.179.
[1]
While we describe a setup using different ISPs in this article, the facility also
works with two uplinks from the same ISP.
33 di 33 03/12/2010 16:02