shorewall_multiisp

Shorewall and Multiple Internet Connections

Tom Eastep

Copyright © 2005, 2006, 2007, 2008, 2009 Thomas M. Eastep

Permission is granted to copy, distribute and/or modify this document under theterms of the GNU Free Documentation License, Version 1.2 or any later versionpublished by the Free Software Foundation; with no Invariant Sections, with noFront-Cover, and with no Back-Cover Texts. A copy of the license is included inthe section entitled “GNU Free Documentation License”.

2010/11/17

Table of Contents

Multiple Internet Connection SupportOverview/etc/shorewall/providers FileWhat an entry in the Providers File Does/etc/shorewall/masq and Multi-ISPMartiansExampleRouting a Particular Application Through a Specific InterfacePort ForwardingMore than 2 ProvidersApplications running on the Firewall -making them use a particular provider/etc/shorewall/route_rules

Routing RulesColumns in the route_rules fileMulti-ISP and VPNExamples

/etc/shorewall/routes FileLooking at the routing tablesUSE_DEFAULT_RTGateway Monitoring and Failover

SWPINGLink Status Monitor (LSM)

Two Providers Sharing an InterfaceA Complete Working Example

Warning

This document describes the Multi-ISP facility in Shorewall 4.3.5 andlater. If you are running an earlier release, please see thedocumentation for that release.

Warning

Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html

1 di 33 03/12/2010 16:02

Reading just Shorewall documentation is probably not going to giveyou enough background to use this material. Shorewall may makeiptables easy but the Shorewall team doesn't have the resources to beable to spoon-feed Linux policy routing to you (please remember thatthe user's manual for a tractor doesn't teach you to grow corn either).You will likely need to refer to the following additional information:

The LARTC HOWTO: http://www.lartc.org

Output of man ip

Output of ip route help and ip rule help

Multiple Internet Connection Support

Shorewall includes limited support for multiple Internet connections. Limitationsof this support are as follows:

It utilizes static routing configuration. If there is a change in the routingtopopogy, Shorewall must be restarted.

The routing changes are made and the route cache is purged whenShorewall is started and when Shorewall is restarted (unless you specifythe "-n" option to shorewall restart). Ideally, restarting the packet filtershould have no effect on routing.

For most routing applications, Quagga is a better solution although itrequires that your ISPs offer routing protocol support.

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

eth0 connects to ISP1. The IP address of eth0 is 206.124.146.176 and theISP's gateway router has IP address 206.124.146.254.

eth1 connects to ISP 2. The IP address of eth1 is 130.252.99.27 and theISP's gateway router has IP address 130.252.99.254.

eth2 connects to the local LAN. Its IP configuration is not relevant to thisdiscussion.

Each of these providers is described in an entry in the file /etc/shorewall/providers.

Entries in /etc/shorewall/providers can specify that outgoing connections are to beload-balanced between the two ISPs. Entries in /etc/shorewall/tcrules and /etc/shorewall/route_rules can be used to direct particular outgoing connections to one ISP or theother. 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 soShorewall can set up the correct marking rules for you.

When you use the track option in /etc/shorewall/providers, connections from theInternet are automatically routed back out of the correct interface and throughthe correct ISP gateway. This works whether the connection is handled by thefirewall itself or if it is routed or port-forwarded to a system behind the firewall.


3 di 33 03/12/2010 16:02

Shorewall will set up the routing and will update the /etc/iproute2/rt_tables toinclude the table names and numbers of the tables that it adds.

Caution

This feature uses packet marking to control the routing. As aconsequence, there are some restrictions concerning entries in/etc/shorewall/tcrules:

Packet marking for traffic control purposes may not be done inthe PREROUTING table for connections involving providers with'track' specified (see below).

You may not use the SAVE or RESTORE options unless you alsoset HIGH_ROUTE_MARKS=Yes in /etc/shorewall/shorewall.conf.

You may not use connection marking unless you also setHIGH_ROUTE_MARKS=Yes in /etc/shorewall/shorewall.conf.

The /etc/shorewall/providers file can also be used in other routing scenarios. See theSquid documentation for an example.

/etc/shorewall/providers File

Entries in this file have the following columns. As in all Shorewall configurationfiles, 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 thisprovider.

NUMBER

A number between 1 and 252. This becomes the routing table number forthe generated table for this provider.

MARK

A mark value used in your /etc/shorewall/tcrules file to direct packets to thisprovider. Shorewall will also mark connections that have seen input from thisprovider with this value and will restore the packet mark in thePREROUTING CHAIN. Mark values must be in the range 1-255.

Alternatively, you may set HIGH_ROUTE_MARKS=Yes in /etc/shorewall/shorewall.conf. This allows you to:

Use connection marks for traffic shaping, provided that you assign thosemarks in the FORWARD chain.

Use mark values > 255 for provider marks in this column.


4 di 33 03/12/2010 16:02

These mark values must be a multiple of 256 in the range256-65280 (hex equivalent 0x100 - 0xFF00 with the low-order 8bits being zero); or

Set WIDE_TC_MARKS=Yes in shorewall.conf (5) and use markvalues in the range 0x10000 - 0xFF0000 with the low-order 16 bitsbeing zero.

This column may be omitted if you don´t use packet marking to directconnections to a particular provider and you don´t specify track in theOPTIONS column.

DUPLICATE

Gives the name or number of a routing table to duplicate. May be 'main' orthe name or number of a previously declared provider. For mostapplications, you want to specify 'main' here. This field should be bespecified as '-' when USE_DEFAULT_RT=Yes in shorewall.conf

INTERFACE

The name of the interface to the provider. Where multiple providers sharethe 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.

The interface must have been previously defined in shorewall-interfaces (5).In general, that interface should not have the proxyarp option specified unlessloose is given in the OPTIONS column of this entry.

GATEWAY

The IP address of the provider's Gateway router.

You can enter detect here and Shorewall will attempt to automaticallydetermine the gateway IP address.

Hint: "detect" is appropriate for use in cases where the interface named inthe 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 todetermine the gateway address.

The GATEWAY may be omitted (enter '-') for point-to-point links.

OPTIONS

A comma-separated list from the following:

track

Important


5 di 33 03/12/2010 16:02

Beginning with Shorwall 4.3.3, track defaults to the settingof the TRACK_PROVIDERS option in shorewall.conf (5). To disablethis option when you have specifiedTRACK_PROVIDERS=Yes, you must specify notrack (seebelow).

If specified, connections FROM this interface are to be tracked so thatresponses may be routed back out this same interface.

You want to specify 'track' if Internet hosts will be connecting to localservers through this provider. Any time that you specify 'track', you willnormally want to also specify 'balance' (see below). 'track' will alsoensure that outgoing connections remain stay anchored to a singleprovider and don't try to switch providers when route cache entriesexpire.

Use of this feature requires that your kernel and iptables includeCONNMARK target and connmark match support (Warning: Untilrecently, standard Debian™ and Ubuntu™ kernels lacked that support.Both Lenny and Jaunty do have the proper support).

Important

If you are running a version of Shorewall earlier than 4.4.3and are using /etc/shorewall/providers because you have multipleInternet connections, we recommend that you specify trackeven if you don't need it. It helps maintain long-termconnections in which there are significant periods with notraffic.

balance

The providers that have balance specified will get outbound trafficload-balanced among them. Balancing will not be perfect, as it is routebased, and routes are cached. This means that routes to often-used siteswill always be over the same provider.

By default, each provider is given the same weight (1) . You can changethe weight of a given provider by following balance with "=" and thedesired weight (e.g., balance=2). The weights reflect the relativebandwidth of the providers connections and should be small numberssince the kernel actually creates additional default routes for eachweight increment.

Important

If you are using /etc/shorewall/providers because you havemultiple Internet connections, we recommend that youspecify balance even if you don't need it. You can still useentries in /etc/shorewall/tcrules and /etc/shorewall/route_rules toforce all traffic to one provider or another.


6 di 33 03/12/2010 16:02

Note

If you don't heed this advice then please readand follow the advice in FAQ 57 and FAQ 58.

Important

If you specify balance and still find that all traffic is goingout through only one provider, you may need to install akernel built withCONFIG_IP_ROUTE_MULTIPATH_CACHED=n. Severalusers have reported that this change has corrected similarproblems.

The SuSE 10.0 kernel is subject to this problem, and akernel oops may result in this circumstance. SUSE 10.1 andSLES 10 haveCONFIG_IP_ROUTE_MULTIPATH_CACHED=n set bydefault. The source of the problem seems to be anincompatibility between the LARTC patches andCONFIG_IP_ROUTE_MULTIPATH_CACHED.

loose

Do not generate routing rules that force traffic whose source IP is anaddress of the INTERFACE to be routed to this provider. Useful fordefining providers that are to be used only when the appropriate packetmark is applied.

Shorewall makes no attempt to consolidate the routing rules addedwhen loose is not specified. So, if you have multiple IP addresses on aprovider interface, you may be able to replace the rules that Shorewallgenerates with one or two rules in /etc/shorewall/route_rules. In that case,you can specify loose to suppress Shorewall's rule generation. See theexample below.

notrack

Added in Shorewall 4.4.3. This option turns off the track option.

optional

Note

This option is deprecated in favor of the optional interfaceoption. That option performs the same function.

Shorewall will determine if this interface is up and has a configured IPaddress. If it is not, a warning is issued and this provider is notconfigured.


7 di 33 03/12/2010 16:02

Note

optional is designed to detect interface states that willcause shorewall start or shorewall restart to fail; justbecause an interface is in a state that Shorewall can[re]start without error doesn't mean that traffic can actuallybe sent through the interface.

You can supply an 'isusable' extension script to extendShorewall's interface state detection. See also the GatewayMonitoring and Failover section below.

src=source-address

Specifies the source address to use when routing to this provider andnone is known (the local client has bound to the 0 address). May not bespecified when an address is given in the INTERFACE column. If thisoption is not used, Shorewall substitutes the primary IP address on theinterface 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]

Indicates that a default route through the provider should be added tothe default routing table (table 253). If a weight is given, a balancedroute is added with the weight of this provider equal to the specifiedweight. If the option is given without a weight, a separate default route isadded through the provider's gateway; the route has a metric equal tothe provider's NUMBER. The option is ignored with a warning messageif USE_DEFAULT_RT=Yes in shorewall.conf.

For those of you who are confused between track and balance:

track governs incoming connections (but is also useful for bindinglong-running connections to the same interface).

balance governs outgoing connections.

COPY

A comma-separated list of interface names. Wildcards specified using anasterisk ("*") are permitted (e.g., tun* ).

When you specify an existing table in the DUPLICATE column, Shorewallcopies all routes through the interface specified in the INTERFACE columnplus the interfaces listed in this column. Normally, you will list all interfaceson your firewall in this column except those Internet interfaces specified inthe INTERFACE column of entries in this file.


8 di 33 03/12/2010 16:02

Note

Beginning with Shorewall 4.4.15, provider routing tables can beaugmeted with additional routes through use of the/etc/shorewall/routes file.

What an entry in the Providers File Does

Adding another entry in the providers file simply creates an alternate routingtable for you (see the LARTC Howto). The table will usually contain two routes:

A host route to the specified GATEWAY through the specified INTERFACE.1.

A default route through the GATEWAY.2.

Note that the first route is omitted if "-" is specified as the GATEWAY; in thatcase, 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 thatcolumn are copied into the new table. By default, all routes (except defaultroutes) are copied. The set of routes copied can be restricted using the COPYcolumn which lists the interfaces whose routes you want copied. You willgenerally want to include all local interfaces in this list. You should exclude theloopback 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 themain table using entries in /etc/shorewall/route_rules (see Example 2 below) or byusing USE_DEFAULT_RT=Yes.

In addition:

Unless loose is specified, an ip rule is generated for each IP address on theINTERFACE that routes traffic from that address through the associatedrouting table.

1.

If you specify track, then connections which have had at least one packetarrive on the interface listed in the INTERFACE column have theirconnection mark set to the value in the MARK column. In the PREROUTINGchain, packets with a connection mark have their packet mark set to thevalue of the associated connection mark; packets marked in this way bypassany prerouting rules that you create in /etc/shorewall/tcrules. This ensures thatpackets associated with connections from outside are always routed out ofthe correct interface.

2.

If you specify balance, then Shorewall will replace the 'default' route withweight 100 in the 'main' routing table with a load-balancing route amongthose gateways where balance was specified. So if you configure defaultroutes, be sure that their weight is less than 100 or the route added byShorewall will not be used.

3.

That's all that these entries do. You still have to follow the principle stated in theShorewall Routing documentation:


9 di 33 03/12/2010 16:02

Routing determines where packets are to be sent.1.

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 theSOURCE IP address (SNAT/MASQUERADE).

2.

The bottom line is that if you want traffic to go out through a particular providerthen 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 mustprovide the appropriate rules in /etc/shorewall/route_rules.

/etc/shorewall/masq and Multi-ISP

If you masquerade a local network, you will need to add masquerade rules forboth external interfaces. Referring to the diagram above, if each of the interfaceshas only a single IP address and you have no systems with public IP addressesbehind your firewall, then I suggest the following simple entries:

#INTERFACE SOURCE ADDRESSeth0 0.0.0.0/0 206.124.146.176eth1 0.0.0.0/0 130.252.99.27

If you have a public subnet (for example 206.124.146.176/30) behind yourfirewall, then use exclusion:

#INTERFACE SOURCE ADDRESSeth0 !206.124.146.176/29 206.124.146.176eth1 0.0.0.0/0 130.252.99.27

Note that exclusion is only used on the interface corresponding to internalsubnetwork.

If you have multiple IP addresses on one of your interfaces, you can use a similartechnique -- simplY exclude the smallest network that contains all of thoseaddresses from being masqueraded.

Warning

Entries in /etc/shorewall/masq have no effect on which ISP a particularconnection will be sent through. That is rather the purpose of entriesin /etc/shorewall/tcrules and /etc/shorewall/route_rules.

Martians

One problem that often arises with Multi-ISP configuration is 'Martians'. If yourInternet interfaces are configured with the routefilter option in /etc/shorewall/interfaces (remember that if you set that option, you should also selectlogmartians), then things may not work correctly and you will see messages likethis:

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

The above message is somewhat awkwardly phrased. The source IP in thisincoming packet was 64.86.88.116 and the destination IP address was206.124.146.176. Another gotcha is that the incoming packet has already hadthe destination IP address changed for DNAT or because the original outgoingconnection was altered by an entry in /etc/shorewall/masq (SNAT or Masquerade). Sothe destination IP address (206.124.146.176) may not have been the destinationIP address in the packet as it was initially received.

There a couple of common causes for these problems:

You have connected both of your external interfaces to the same hub/switch.Connecting multiple firewall interfaces to a common hub or switch is alwaysa bad idea that will result in hard-to-diagnose problems.

1.

You are specifying both the loose and balance options on your provider(s).This can cause individual connections to ping-pong back and forth betweenthe interfaces which is almost guaranteed to cause problems.

2.

You are redirecting traffic from the firewall system out of one interface or theother using packet marking in your /etc/shorewall/tcrules file. A better approachis to configure the application to use the appropriate local IP address (the IPaddress of the interface that you want the application to use). See below.

3.

If all else fails, remove the routefilter option from your external interfaces. If youdo this, you may wish to add rules to log and drop packets from the Internet thathave source addresses in your local networks. For example, if the local LAN in theabove diagram is 192.168.1.0/24, then you would add this rule:

#ACTION SOURCE DESTDROP:info net:192.168.1.0/24 all

Be sure the above rule is added before any other rules with net in the SOURCEcolumn.

Example

The configuration in the figure at the top of this section would be specified in/etc/shorewall/providers as follows.

#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPYISP1 1 1 main eth0 206.124.146.254 track,balance eth2ISP2 2 2 main eth1 130.252.99.254 track,balance eth2

Other configuration files go something like this:

/etc/shorewall/interfaces:

#ZONE INTERFACE BROADCAST OPTIONSnet eth0 detect … net eth1 detect …

/etc/shorewall/policy:


11 di 33 03/12/2010 16:02

#SOURCE DESTINATION POLICY LIMIT:BURSTnet net DROP

/etc/shorewall/masq:

#INTERFACE SOURCE ADDRESSeth0 0.0.0.0/0 206.124.146.176eth1 0.0.0.0/0 130.252.99.27

Routing a Particular Application Through a Specific Interface

This continues the example in the preceding section.

Now suppose that you want to route all outgoing SMTP traffic from your localnetwork through ISP 2. You would make this entry in /etc/shorewall/tcrules (andif you are running a version of Shorewall earlier than 3.0.0, you would setTC_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

Port Forwarding

Shorewall provides considerable flexibility for port forwarding in a multi-ISPenvironment.

Normal port forwarding rules such as the following will forward from bothproviders.

/etc/shorewall/rules:

#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL# PORTS(S) DESTDNAT net loc:192.168.1.3 tcp 25

Continuing the above example, to forward only connection requests from ISP 1,you can either:

Qualify the SOURCE by ISP 1's interface:

#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL# PORTS(S) DESTDNAT net:eth0 loc:192.168.1.3 tcp 25

or

1.

Specify the IP address of ISP 1 in the ORIGINAL DEST column:2.


12 di 33 03/12/2010 16:02

#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL# PORTS(S) DESTDNAT net loc:192.168.1.3 tcp 25 - 206.124.146.176

More than 2 Providers

When there are more than two providers, you need to extend the two-providercase in the expected way:

For each external address, you need an entry in /etc/shorewall/masq to handlethe case where a connection using that address as the SOURCE is sent out ofthe interfaces other than the one that the address is configured on.

1.

For each external interface, you need to add an entry to /etc/shorewall/masq.2.

If we extend the above example to add eth3 with IP address 16.105.78.4 withgateway 16.105.78.254, then:

/etc/shorewall/providers:

#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPYISP1 1 1 main eth0 206.124.146.254 track,balance eth2ISP2 2 2 main eth1 130.252.99.254 track,balance eth2ISP3 3 3 main eth3 16.105.78.254 track,balance eth2


#INTERFACE SUBNET ADDRESSeth0 0.0.0.0/0 206.124.146.176eth1 0.0.0.0/0 130.252.99.27eth3 0.0.0.0/0 16.105.78.4

Applications running on the Firewall -making them use aparticular provider

As noted above, separate entries in /etc/shorewall/tcrules are required for trafficoriginating from the firewall.

Experience has shown that in some cases, problems occur with applicationsrunning on the firewall itself. This is especially true when you have specifiedroutefilter on your external interfaces in /etc/shorewall/interfaces (see above).When this happens, it is suggested that you have the application use specificlocal IP addresses rather than 0.

Examples:

Squid: In squid.conf, set tcp_outgoing_address to the IP address of theinterface that you want Squid to use.

In OpenVPN, set local (--local on the command line) to the IP address thatyou 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

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 mostreliable way to direct such traffic to a particular ISP.

Example:

#SOURCE DEST PROVIDER PRIORITYlo - shorewall 1000

/etc/shorewall/route_rules

The route_rules file allows assigning certain traffic to a particular provider just asentries in the tcrules file. The difference between the two files is that entries inroute_rules are independent of Netfilter.

Routing Rules

Routing rules are maintained by the Linux kernel and can be displayed using theip rule ls command. When routing a packet, the rules are processed in turn untilthe packet is successfully routed.

gateway:~ # ip rule ls0: from all lookup local <=== Local (to the firewall) IP addresses10001: from all fwmark 0x1 lookup Blarg <=== This and the next rule are generated by the10002: 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 unless20256: 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 emptygateway:~ #

In the above example, there are two providers: Blarg and Comcast with MARK 1going to Blarg and mark 2 going to Comcast.

Columns in the route_rules file

Columns in the file are:

SOURCE (Optional)

An ip address (network or host) that matches the source IP address in apacket. May also be specified as an interface name optionally followed by ":"and an address. If the device 'lo' is specified, the packet must originate fromthe firewall itself.

DEST (Optional)

An ip address (network or host) that matches the destination IP address in apacket.

If you choose to omit either SOURCE or DEST, place "-" in that column. Notethat you may not omit both SOURCE and DEST.


14 di 33 03/12/2010 16:02

PROVIDER

The provider to route the traffic through. May be expressed either as theprovider name or the provider number.

PRIORITY

The rule's priority which determines the order in which the rules areprocessed.

1000-1999 Before Shorewall-generated 'MARK' rules

11000- 11999 After 'MARK' rules but before Shorewall-generated rules forISP interfaces.

26000-26999 After ISP interface rules but before 'default' rule.

Rules with equal priority are applied in the order in which they appear inthe file.

Multi-ISP and VPN

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 VPNsoftware adds a host route to the main table for each VPN client. The bestapproach is to use USE_DEFAULT_RT=Yes as described below. If that isn'tpossible, you must add a routing rule in the 1000-1999 range to specify the maintable for traffic addressed to those clients. See Example 2 below.

If you have an IPSEC gateway on your firewall, be sure to arrange for ESPpackets to be routed out of the same interface that you have configured yourkeying daemon to use.

Examples

Example 1: You want all traffic entering the firewall on eth1 to be routedthrough Comcast.

#SOURCE DEST PROVIDER PRIORITYeth1 - Comcast 1000

With this entry, the output of ip rule ls would be as follows.

gateway:~ # ip rule ls0: from all lookup local1000: from all iif eth1 lookup Comcast10001: from all fwmark 0x1 lookup Blarg10002: from all fwmark 0x2 lookup Comcast20000: from 206.124.146.176 lookup Blarg20256: from 24.12.22.33 lookup Comcast32766: from all lookup main32767: from all lookup defaultgateway:~ #


15 di 33 03/12/2010 16:02

Note that because we used a priority of 1000, the test for eth1 is inserted beforethe fwmark tests.

Example 2: You use OpenVPN (routed setup w/tunX) in combination withmultiple providers. In this case you have to set up a rule to ensure that theOpenVPN traffic is routed back through the tunX interface(s) rather thanthrough any of the providers. 10.8.0.0/24 is the subnet chosen in your OpenVPNconfiguration (server 10.8.0.0 255.255.255.0).

#SOURCE DEST PROVIDER PRIORITY- 10.8.0.0/24 main 1000

/etc/shorewall/routes File

Beginning with Shorewall 4.4.15, additional routes can be added to the providerrouting tables using the /etc/shorewall/routes file.

The columns in the file are as follows.

PROVIDER

The name or number of a provider defined in shorewall-providers (5).

DEST

Destination host address or network address.

GATEWAY (Optional)

If specified, gives the IP address of the gateway to the DEST.

DEVICE (Optional)

Specifies the device route. If neither DEVICE nor GATEWAY is given, thenthe INTERFACE specified for the PROVIDER in shorewall-providers (5).

Assume the following entry in /etc/shorewall/providers:

#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPYComcast 1 - xxx eth2 ....

The following table gives some example entries in the file and the ip routecommand which results.

#PROVIDER DEST GATEWAY DEVICE | Generated CommandComcast 172.20.1.0/24 - eth0 | ip -4 route add 172.20.1.0/24 dev eth0 table 1Comcast 192.168.4.0/24 172.20.1.1 | ip -4 route add 192.168.1.0/24 via 172.20.1.1 table 1Comcast 192.168.4.0/24 | ip -4 route add 192.168.4.0/24 dev eth2 table 1

Looking at the routing tables

To look at the various routing tables, you must use the ip utility. To see the entirerouting configuration (including rules), the command is shorewall showrouting. To look at an individual provider's table use ip route ls table provider


16 di 33 03/12/2010 16:02

where provider can be either the provider name or number.

Example:

lillycat:- #ip route ls144.77.167.142 dev ppp0 proto kernel scope link src 144.177.121.19971.190.227.208 dev ppp1 proto kernel scope link src 71.24.88.151192.168.7.254 dev eth1 scope link src 192.168.7.1192.168.7.253 dev eth1 scope link src 192.168.7.1192.168.7.0/24 dev eth1 proto kernel scope link src 192.168.7.1192.168.5.0/24 via 192.168.4.2 dev eth0192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.223192.168.1.0/24 via 192.168.4.222 dev eth0default nexthop dev ppp1 weight 2 nexthop dev ppp0 weight 1lillycat: #ip route ls provider 1144.77.167.142 dev ppp0 proto kernel scope link src 144.177.121.199 192.168.5.0/24 via 192.168.4.2 dev eth0 192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.223 192.168.1.0/24 via 192.168.4.222 dev eth0 default dev ppp0 scope link lillycat: #

USE_DEFAULT_RT

USE_DEFAULT_RT is an option in shorewall.conf (5).

One of the drawbacks of the Multi-ISP support as described in the precedingsections is that changes to the main table made by applications are not added tothe individual provider tables. This makes route rules such as described in one ofthe examples above necessary.

USE_DEFAULT_RT=Yes works around that problem by passing packets throughthe main table first rather than last. This has a number of implications:

Both the DUPLICATE and the COPY columns in the providers file mustremain empty or contain "-". The individual provider routing tablesgenerated when USE_DEFAULT_RT=Yes contain only a host route to thegateway and a default route via the gateway.

1.

The balance option is assumed for all interfaces that do not have the looseoption. When you want both balance and loose, both must be specified.

2.

The default route generated by Shorewall is added to the default routingtable (253) rather than to the main routing table (254).

3.

Packets are sent through the main routing table by a routing rule withpriority 999. The priority range 1-998 may be used for inserting rules thatbypass the main table.

4.

You should disable all default route management outside of Shorewall. If adefault route is inadvertently added to the main table while Shorewall isstarted, then all policy routing will stop working except for those routingrules in the priority range 1-998.

5.


17 di 33 03/12/2010 16:02

For ppp interfaces, the GATEWAY may remain unspecified ("-"). For thoseinterfaces managed by dhcpcd or dhclient, you may specify 'detect' in theGATEWAY column; Shorewall will use the dhcp client's database todetermine the gateway IP address. All other interfaces must have aGATEWAY specified explicitly.

6.

Although 'balance' is automatically assumed when USE_DEFAULT_RT=Yes, youcan easily cause all traffic to use one provider except when you explicitly direct itto use the other provider via shorewall-route_rules (5) or shorewall-tcrules (5).

Example (send all traffic through the 'shorewall' provider unless otherwisedirected).


#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONSlinksys 1 1 - wlan0 172.20.1.1 track,balance=1,optionalshorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional

/etc/shorewall/route_rules:

#SOURCE DEST PROVIDER PRIORITY- - shorewall 11999

Gateway Monitoring and Failover

There are a couple of options available for monitoring the status of provider linksand taking action when a failure occurs. Both of these options assume that eachprovider has a unique nexthop gateway; if two or more providers use the samegateway router then neither option is suitable.

You specify the optional option in /etc/shorewall/interfaces:

#ZONE INTERFACE BROADCAST OPTIONSnet eth0 detect optional net eth1 detect optional

SWPING

Shorewall includes a sample monitoring script swping. The swping file is available inthe main directory contained in the Shorewall-common tarball and is included inthe 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 makeany claim that they will work for anyone else. But if you have a needfor automated link monitoring, they offer you a place to start.

Important


18 di 33 03/12/2010 16:02

If you have installed Shorewall-init, you should disable its ifup/ifdown/NetworkManager integration (set IFUPDOWN=0 in theShorewall-init configuration file).

The script should be copied to a directory on root's PATH such as /usr/local/sbin/.

The script works by sending pings to target IP addresses through each externalinterface. These targets must not depend on any routes other than those that arepresent in the main routing table. That ensures that a route is available to thetarget even when the target's interface is not working and Shorewall has omittedit from the routing configuration. An interface is assumed to be up when aspecified number (UP_COUNT) of consecutive ping operations succeed. Similarly,an interface is assumed to be down when a specified number (DOWN_COUNT) ofconsecutive 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 morethan 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=eth0IF2=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

If you leave COMMAND empty, the script sets its value automatically dependingon whether Shorewall-lite is installed.

When the status of an interface changes:

For each interface, a file is placed in ${VARDIR} (normally /var/lib/shorewall) to record the status of the interface: either 0 (UP) or 1 (DOWN).The name of the file is interface.status where interface is the interface (e.g.,eth0.status).

A shorewall -f restart command is executed (shorewall-lite restart, ifShorewall-lite is installed).

The contents of the main routing table are displayed.

The .status files are intended to be used with the following /etc/shorewall/isusablescript.

local status=0

[ -f ${VARDIR}/${1}.status ] && status=$(cat ${VARDIR}/${1}.status)

return $status

The above script is installed in /etc/shorewall, beginning with Shorewall 4.3.11.

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 tobe run at boot. It works on OpenSuSE™ 11.0 -- YMMV. Modify the PROG andSTATEDIR variables as needed.

As an alternative to using the init script, you can add the following to /etc/shorewall/started:

if [ "$COMMAND" = start ]; then killall -9 swping 2> /dev/null #be sure that there are none left running /usr/local/sbin/swping &fi

and add this to /etc/shorewall/stopped.

if [ "$COMMAND" = stop -o "$COMMAND" = clear ]; then killall -9 swping 2> /dev/nullfi

This simple script has a number of limitations:

It only works on IPv4 or IPv6 but not both at once. So if you want to monitorboth IPv4 and IPv6, you need to clone the script are run two copies; one forIPv4 and one for IPv6.

1.

It can only detect the gateway for interfaces managed by dhcpcd.2.

It's method of determining whether an interface is up or down is crude. Youwill normally specify the default gateway for each provider as the sites to

3.


20 di 33 03/12/2010 16:02

ping and being able to ping the default gateway is not a surefire indicationthat the provider is usable. The method of determining whether a site is upor down is also crude.

Because of the crudeness of the algorithm, hysteresis may occur.4.

It is tricky to configure a system such that the system works correctly whenone of its providers is down unless you largely don't care which interface isused.

5.

Link Status Monitor (LSM)

Link Status Monitor was written by Mika Ilmaranta <ilmis at nullnet.fi> andperforms more sophisticated monitoring than the simple swping script describedin the preceding section.

Important

If you have installed Shorewall-init, you should disable its ifup/ifdown/NetworkManager integration (set IFUPDOWN=0 in theShorewall-init configuration file) before installing LSM.

Like many Open Source products, LSM is poorly documented. It's mainconfiguration file is normally kept in /etc/lsm/lsm.conf, but the file's name is passedas 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 forconfiguration. One feature that is not mentioned in the sample is that an"include" directive is supported. This allows additional files to be sourced in fromthe main configuration file.

LSM monitors the status of the links defined in its configuration file and runs auser-provided script when the status of a link changes. The script name isspecified in the eventscript option in the configuration file. Key arguments to thescript are as follows:

$1

The state of the link ('up' or 'down')

$2

The name of the connection as specified in the configuration file.

$4

The name of the network interface associated with the connection.

$5

The email address of the person specified to receive notifications. Specifiedin the warn_email option in the configuration file.


21 di 33 03/12/2010 16:02

It is the responsibility of the script to perform any action needed in reaction tothe connection state change. The default script supplied with LSM composes anemail and sends it to $5.

I personally use LSM here at shorewall.net (configuration is described below). Ihave set things up so that:

Shorewall [re]starts lsm during processing of the start and restorecommands. I don't have Shorewall restart lsm during Shorewall restartbecause I restart Shorewall much more often than the average user is likelyto do.

Shorewall starts lsm because I have a dynamic IP address from one of myproviders (Comcast); Shorewall detects the default gateway to that providerand creates a secondary configuration file (/etc/lsm/shorewall.conf) that containsthe link configurations. That file is included by /etc/lsm/lsm.conf.

The script run by LSM during state change (/etc/lsm/script) writes a${VARDIR}/xxx.status file when the status of an interface changes. Those files areread by the isusable extension script (see below).

Below are my relevant configuration files.

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

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}

eth0 has a dynamic IP address so I need to use the Shorewall-detected gatewayaddress ($SW_ETH1_GATEWAY). I supply a default value to be used in the eventthat detection fails.

Note

In Shorewall 4.4.7 and earlier, the variable name is ETH1_GATEWAY.

/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_lsmfi

/etc/shorewall/restored:

################################################################################### Start lsm if it isn't running##################################################################################if [ -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then start_lsmfi

/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

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 [email protected] check_arp=0 sourceip= ttl=0}

include /etc/lsm/shorewall.conf

/etc/lsm/script

#!/bin/sh## (C) 2009 Mika Ilmaranta <[email protected]># (C) 2009 Tom Eastep <[email protected]>## 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-liteelse VARDIR=/var/lib/shorewall STATEDIR=/etc/shorewallfi

[ -f ${STATEDIR}/vardir ] && . ${STATEDIR}/vardir

cat <<EOM | mail -s "${NAME} ${STATE}, DEV ${DEVICE}" ${WARN_EMAIL}

Hi,

Connection ${NAME} is now ${STATE}.

Following parameters were passed:newstate = ${STATE}name = ${NAME}checkip = ${CHECKIP}device = ${DEVICE}warn_email = ${WARN_EMAIL}


24 di 33 03/12/2010 16:02

Packet counters:replied = ${REPLIED} packets repliedwaiting = ${WAITING} packets waiting for replytimeout = ${TIMEOUT} packets that have timed out (= packet loss)reply_late = ${REPLY_LATE} packets that received a reply after timeoutcons_rcvd = ${CONS_RCVD} consecutively received replies in sequencecons_wait = ${CONS_WAIT} consecutive packets waiting for replycons_miss = ${CONS_MISS} consecutive packets that have timed outavg_rtt = ${AVG_RTT} average rtt, notice that waiting and timed out packets have rtt = 0 when calculating this

Your LSM Daemon

EOM

[ ${STATE} = up ] && state=0 || state=1

echo $state > ${VARDIR}/${DEVICE}.status

/sbin/shorewall restart -f >> /var/log/lsm 2>&1

/sbin/shorewall show routing >> /var/log/lsm

exit 0

#EOF

:

Two Providers Sharing an Interface

Shared interface support has the following characteristics:

Only Ethernet (or Ethernet-like) interfaces can be used. For inbound traffic,the MAC addresses of the gateway routers are used to determine whichprovider a packet was received through. Note that only routed traffic can becategorized using this technique.

a.

You must specify the address on the interface that corresponds to aparticular provider in the INTERFACE column by following the interfacename with a colon (":") and the address.

b.

Entries in /etc/shorewall/masq must be qualified by the provider name (ornumber).

c.

This feature requires Realm Match support in your kernel and iptables.d.

You must add route_rules entries for networks that are accessed through aparticular provider.

e.

If you have additional IP addresses through either provider, you must addroute_rules to direct traffic FROM each of those addresses through theappropriate provider.

f.

You must manually add MARK rules for traffic known to come from eachprovider.

g.

You must specify a gateway IP address in the GATEWAY column ofh.


25 di 33 03/12/2010 16:02

/etc/shorewall/providers; detect is not permitted.

Taken together, b. and h. effectively preclude using this technique with dynamicIP addresses.

Example:

This is our home network circa fall 2008. We have two Internet providers:

Comcast -- Cable modem with one dynamic IP address.1.

Avvanta -- ADSL with 5 static IP addresses.2.

Because the old Compaq™ Presario™ that I use for a firewall only has three PCIslots and no onboard Ethernet, it doesn't have enough Ethernet controllers tosupport both providers. So I use a Linksys WRT300n pre-N router as a gateway toComcast. Note that because the Comcast IP address is dynamic, I could not sharea single firewall interface between the two providers directly.

On my personal laptop (ursa), I have 9 virtual machines running various Linuxdistributions. It is the Shorewall configuration on ursa that I will describe here.

Below is a diagram of our network:


26 di 33 03/12/2010 16:02

The local wired network in my office is connected to both gateways and uses theprivate (RFC 1918) network 172.20.1.0/24. The Comcast gateway has local IPaddress 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).

This configuration uses USE_DEFAULT_RT=Yes in shorewall.conf (see above).

Here is the providers file:

#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPYcomcast 1 1 - eth0:172.20.1.130 172.20.1.1 track,loose,balance,optionalavvanta 2 2 - eth0:172.20.1.130 172.20.1.254 track,optional,loosewireless 3 3 - wlan0 172.20.1.1 track,optional

Several things to note:

172.20.1.130 is specified as the eth0 IP address for both providers.1.


27 di 33 03/12/2010 16:02

Both wired providers have the loose option. This prevents Shorewall fromautomatically generating routing rules based on the source IP address.

2.

Only comcast has the balance option. With USE_DEFAULT_RT=yes, thatmeans that comcast will be the default provider. While balance is thedefault, with USE_DEFAULT_RT=Yes, it must be specified explicitly whenloose is also specified.

3.

I always disable the wireless interface when the laptop is connected to thewired network.

4.

I use a different Shorewall configuration when I take the laptop on the road.5.

Here is the route_rules file:

#SOURCE DEST PROVIDER PRIORITY- 206.124.146.176/31 avvanta 1000- 206.124.146.178/31 avvanta 1000- 206.124.146.180/32 avvanta 1000

Those rules direct traffic to the five static Avvanta IP addresses (only two arecurrently used) through the avvanta provider.

Here is the tcrules file (MARK_IN_FORWARD_CHAIN=No in shorewall.conf):

#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH TOS CONNBYTES# PORT(S) 2 $FW 0.0.0.0/0 tcp 212 $FW 0.0.0.0/0 tcp - - - - - - - 2 $FW 0.0.0.0/0 tcp 119

These rules:

Use avvanta for FTP.

Use avvanta for NTTP

The remaining files are for a rather standard two-interface config with a bridge asthe local interface.

zones:

#ZONE IPSEC OPTIONS IN OUT# ONLY OPTIONS OPTIONSfw firewallnet ipv4kvm ipv4

policy:

net net NONEfw net ACCEPTfw kvm ACCEPTkvm all ACCEPTnet all DROP infoall all REJECT info


28 di 33 03/12/2010 16:02

interfaces:

#ZONE INTERFACE BROADCAST OPTIONS GATEWAY#net eth0 detect dhcp,tcpflags,routefilter,blacklist,logmartians,optional,arp_ignorenet wlan0 detect dhcp,tcpflags,routefilter,blacklist,logmartians,optionalkvm br0 detect routeback #Virtual Machines

Note

wlan0 is the wireless adapter in the notebook. Used when the laptop isin our home but not connected to the wired network.

masq:

#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSECeth0 192.168.0.0/24wlan0 192.168.0.0/24

Note

Because the firewall has only a single external IP address, I don'tneed to specify the providers in the masq rules.

A Complete Working Example

This section describes the network at shorewall.net early in 2009. Theconfiguration is as follows:

Two providers:

Avvanta -- A slow (1.5mb/384kb) DSL service with 5 static IP addresses.

Comcast -- A fast (20mb/10mb) Cable circuit with a single dynamicaddress.

A local network consisting of wired and wireless client systems. A LinksysWRT300N wireless router is used as an access point for the wireless hosts.

A DMZ hosting a single server (lists.shorewall.net aka www1.shorewall.net,ftp1.shorewall.net,etc.)

The network is pictured in the following diagram:


29 di 33 03/12/2010 16:02

Because of the speed of the cable provider, all traffic uses that provider unlessthere is a specific need for the traffic to use the DSL line.

Responses to connections from the Internet to one of the DSL IP addresses --the track option takes care of that.

Connections initiated by the server and connections requested by clients onthe firewall that have bound their local socket to one of the DSL IPaddresses. Two entries in /etc/shorewall/route_rules take care of that traffic.

As a consequence, I have disabled all route filtering on the firewall and only usethe balance option in /etc/shorewall/providers on the Comcast provider whose defaultroute in the main table is established by DHCP. By specifying the fallback optionon Avvanta, I ensure that there is still a default route if Comcast is down. lsm isused 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

ROUTE_FILTER=NoRESTORE_DEFAULT_ROUTE=No

RESTORE_DEFAULT_ROUTE=No causes the default route in the main table to bedeleted when the Comcast link is unavailable. That way, the default route in thedefault table will be used until Comcast is available again.


#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPYAvvanta 1 0x100 main eth0 206.124.146.254 track,loose,fallback eth2,eth4,tun*Comcast 2 0x200 main eth3 detect track,balance eth2,eth4,tun*#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

The loose option on Avvanta results in fewer routing rules. The first two routingrules below insure that all traffic from Avvanta-assigned IP addresses is sent viathe Avvanta provider. The 'tun*' included in the COPY column is there because Irun a routed OpenVPN server on the firewall.

/etc/shorewall/route_rules:

#SOURCE DEST PROVIDER PRIORITY- 172.20.0.0/24 main 1000 # Addresses assigned by routed OpenVPN server206.124.146.176/30 - Avvanta 26000206.124.146.180 - Avvanta 26000- 216.168.3.44 Avvanta 26000 # Avvanta NNTP Server -- verifies source IP address#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

The /etc/shorewall/route_rules entries provide all of the provider selection necessaryso my /etc/shorewall/tcrules file is used exclusively for traffic shaping of the Avvantaline. Note that I still need to provide values in the MARK colum of /etc/shorewall/providers because I specify track on both providers.

Here is the output of shorewall show routing:

Routing Rules

0: from all lookup local1000: from all to 172.20.0.0/24 lookup main 10000: from all fwmark 0x100 lookup Avvanta 10001: from all fwmark 0x200 lookup Comcast 20256: from 71.227.156.229 lookup Comcast 26000: from 206.124.146.176/30 lookup Avvanta 26000: from 206.124.146.180 lookup Avvanta 26000: from all to 216.168.3.44 lookup Avvanta 32766: from all lookup main 32767: from all lookup default

Table Avvanta:

206.124.146.254 dev eth0 scope link src 206.124.146.176 206.124.146.177 dev eth4 scope link 172.20.1.0/24 dev eth2 proto kernel scope link src 172.20.1.254 206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176 169.254.0.0/16 dev eth0 scope link default via 206.124.146.254 dev eth0 src 206.124.146.176


31 di 33 03/12/2010 16:02

Table Comcast:

206.124.146.177 dev eth4 scope link 71.227.156.1 dev eth3 scope link src 71.227.156.229 172.20.1.0/24 dev eth2 proto kernel scope link src 172.20.1.254 71.227.156.0/23 dev eth3 proto kernel scope link src 71.227.156.229 default via 71.227.156.1 dev eth3 src 71.227.156.229

Table default:

default via 206.124.146.254 dev eth0 metric 1

Table local:

broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 172.20.1.0 dev eth2 proto kernel scope link src 172.20.1.254 broadcast 206.124.146.255 dev eth0 proto kernel scope link src 206.124.146.176 local 206.124.146.179 dev eth0 proto kernel scope host src 206.124.146.176 local 206.124.146.178 dev eth0 proto kernel scope host src 206.124.146.176 local 206.124.146.176 dev eth0 proto kernel scope host src 206.124.146.176 local 206.124.146.176 dev eth4 proto kernel scope host src 206.124.146.176 broadcast 71.227.157.255 dev eth3 proto kernel scope link src 71.227.156.229 broadcast 71.227.156.0 dev eth3 proto kernel scope link src 71.227.156.229 local 172.20.1.254 dev eth2 proto kernel scope host src 172.20.1.254 local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1 broadcast 172.20.1.255 dev eth2 proto kernel scope link src 172.20.1.254 local 71.227.156.229 dev eth3 proto kernel scope host src 71.227.156.229 broadcast 206.124.146.0 dev eth0 proto kernel scope link src 206.124.146.176 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 206.124.146.180 dev eth0 proto kernel scope host src 206.124.146.176 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

Table main:

206.124.146.177 dev eth4 scope link 172.20.1.0/24 dev eth2 proto kernel scope link src 172.20.1.254 206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176 71.227.156.0/23 dev eth3 proto kernel scope link src 71.227.156.229 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 71.227.156.1 dev eth3

/etc/shorewall/interfaces:

#ZONE INTERFACE BROADCAST OPTIONSloc eth2 detect dhcp,routebackdmz eth4 detectnet eth0 detect dhcp,blacklist,tcpflags,optionalnet eth3 detect dhcp,blacklist,tcpflags,optional#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC

COMMENT Masquerade Local Networketh3 0.0.0.0/0eth0 !206.124.146.0/24 206.124.146.179

#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE


32 di 33 03/12/2010 16:02

All traffic leaving eth3 must use the dynamic IP address assigned to that interfaceas the SOURCE address. All traffic leaving eth0 that does not have a SOURCEaddress falling within the Avvanta subnet (206.124.146.0/24) must have itsSOURCE address changed to 206.124.146.179.

[1] While we describe a setup using different ISPs in this article, the facility alsoworks with two uplinks from the same ISP.


33 di 33 03/12/2010 16:02

shorewall_multiisp

Documents

Transcript of shorewall_multiisp