 Redundant
Internet Connections Using Linux
Seann Herdejurgen
With the advent of high-speed Internet links from Internet Service
Providers (ISPs), it's easier for users to host services on
their home computers. But what happens when your ISP connection
goes down? An obvious solution is to have a redundant Internet connection
from another ISP. To help set up a Linux host with redundant Internet
connections, this article covers the following essentials:
1. Configuring the host to properly handle inbound network connections
from multiple ISPs
2. Load-balancing outbound network connections
3. Configuring various services to enable redundancy
4. Configuring firewall protection using ipchains or iptables
Figure 1 depicts the home computer network configuration that
is referred to throughout this article. The Linux host in Figure
1 acts as a firewall between two separate connections to the Internet
and an internal LAN. In this case, Ethernet interface eth1 uses
DSL and Ethernet interface eth2 uses a cable modem. The Linux host
load balances outbound network connections across the two ISPs.
The ability to load balance between two ISPs is not restricted to
high-speed network links. These same techniques can also be used
to load balance between two dial-up connections.
The host used for testing the configuration in Figure 1 was a
dual-processor Intel Celeron, 533-MHz computer running Red Hat 6.2
with Linux kernel 2.2.18. It has also been tested under Red Hat
7.1 with Linux kernel 2.4.13. The configuration in this article
does not require a dual-processor system, nor does it require a
533-MHz CPU. You can recycle your old Pentium 100 system with 32
MB of RAM to be your firewall. Some examples presented throughout
this article are specific to Red Hat, but they can be easily modified
to work with other Linux distributions.
The scope of this article precludes providing the step-by-step
details on configuring Ethernet cards, compiling Linux kernels,
or configuring DNS. Information on performing these tasks is readily
available on the Internet and in numerous books. http://www.linuxdoc.org/
is a good starting point for information.
Kernel Configuration
Linux kernels 2.2 and above support advanced routing techniques
that are required to provide load balancing and multiple default
routes on a Linux host. The following kernel networking options
must be compiled into the kernel to support multiple connections
to the Internet:
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
To access the advanced routing features of the new kernel, the iproute
toolset must be installed. (It is now distributed with Red Hat 7.1)
The iproute toolset is available from:
ftp://ftp.inr.ac.ru/ip-routing/
The iproute toolset provides two special commands for accessing advanced
routing features -- ip and tc. Documentation for
the ip command is available at:
http://snafu.freedom.org/linux2.2/docs/ip-cref/ip-cref.html
Source IP Routing
By default, TCP/IP packets are routed by examining the destination
IP address and checking for a route to the destination network in
the routing table. The routing table can be viewed with the netstat
-r command. If a route is found, the packet is sent to that
network interface, otherwise the packet is sent to the default gateway.
For most systems directly on the Internet, the default gateway is
an ISP. In our case, this means that all outbound Internet connections
go out of the DSL interface. This is not the desired behavior in
an environment with redundant Internet connections. When you add
a cable modem to the system, you don't want your cable modem
connections to respond using your DSL connection.
To solve this issue, we create multiple routing tables using the
ip command. A routing table is selected based on the source
IP address of the outbound packet. This is configured using the
following commands:
# Setup source IP routing rules for DSL
ip rule add from 63.89.102.157 lookup 1
ip route add 10.0.0.0/24 via 10.0.0.1 table 1
ip route add 0/0 via 63.89.102.1 table 1
# Setup source IP routing rules for cable modem
ip rule add from 65.3.17.133 lookup 2
ip route add 10.0.0.0/24 via 10.0.0.1 table 2
ip route add 0/0 via 65.3.17.1 table 2
If an outbound packet is from source address 63.89.102.157 (DSL),
then it looks at Routing Table 1, which has two entries:
> ip route list table 1
10.0.0.0/24 via 10.0.0.1 dev eth0
default via 63.89.102.1 dev eth1
The first line routes local traffic to the internal network, and the
second line catches all remaining packets and sends them to the ISP
over the DSL interface. Routing Table 2 for the cable modem interface
behaves in the same fashion.
Load Balancing
To load balance outbound network connections from the internal
network, the CONFIG_IP_ROUTE_MULTIPATH kernel option is used,
which allows you to have multiple default gateways. It is set up
by removing the default gateway from the /etc/sysconfig/network
file and setting up the default gateway using advanced routing features
with the following command:
# ip route add default equalize
nexthop via 63.89.102.1 dev eth1
nexthop via 65.3.17.1 dev eth2
To view the advanced routing table, use the following command:
> ip route list
255.255.255.255 dev eth0 scope link
255.255.255.255 dev eth2 scope link
255.255.255.255 dev eth1 scope link
10.0.0.1 dev eth0 scope link
63.89.102.157 dev eth1 scope link
65.3.17.133 dev eth2 scope link
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
63.89.102.0/24 dev eth1 proto kernel scope link src 63.89.102.157
65.3.17.0/24 dev eth2 proto kernel scope link src 65.3.17.133
127.0.0.0/8 dev lo scope link
default equalize
nexthop via 63.89.102.1 dev eth1 weight 1
nexthop via 65.3.17.1 dev eth2 weight 1
The CONFIG_IP_ROUTE_MULTIPATH kernel option causes Linux to
"consider all these paths (default routes) to be of equal 'cost'
and choose one of them in a non-deterministic fashion," according
to /usr/src/linux/Documentation/Configure.help. The equalize
option to the ip route command causes the Linux kernel to load
balance outbound connections based on IP address. For a particular
IP address, the kernel picks an interface on which it will transmit
outbound packets; the kernel then records this decision as an entry
in the routing cache for that IP address. Further connections to that
IP address will occur over the same interface until the entry expires
in the routing cache. You can view the routing cache with the command
ip route list cache.
Configuring Services
Various services (DNS, SMTP, HTTP, LDAP, SSH, etc.) can be made
redundant by implementing round-robin DNS. DNS is made redundant
by listing two authoritative NS records, one on each external interface.
The TTL (time to live) on each DNS record has been reduced so that
remote systems will only cache IP information for 30 minutes. This
causes inbound traffic to be distributed across the two IP addresses
in a round-robin fashion. For inbound SMTP connections, two MX records
of equal weight (10) were added to DNS so that if one interface
is down, inbound email will be delivered on the other interface.
You can use the dig command (nslookup on steroids)
to verify your DNS configuration as follows:
> dig alphapager.org any
; <<>> DiG 8.2 <<>> alphapager.org any
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5
;; QUERY SECTION:
;; alphapager.org, type = ANY, class = IN
;; ANSWER SECTION:
alphapager.org. 30M IN A 63.89.102.157
alphapager.org. 30M IN A 65.3.17.133
alphapager.org. 30M IN NS ns.alphapager.org.
alphapager.org. 30M IN NS ns.herdejurgen.com.
alphapager.org. 30M IN SOA proxy.alphapager.org.root.proxy.alphapager.org. (
2001031000 ; serial
3H ; refresh
1H ; retry
1W ; expiry
30M ) ; minimum
alphapager.org. 30M IN MX 10 ns.herdejurgen.com.
alphapager.org. 30M IN MX 10 ns.alphapager.org.
;; ADDITIONAL SECTION:
ns.alphapager.org. 30M IN A 63.89.102.157
ns.herdejurgen.com. 30M IN A 65.3.17.133
;; Total query time: 98 msec
;; FROM: pandora to SERVER: default -- 192.168.100.1
;; WHEN: Sat Mar 10 22:15:22 2001
;; MSG SIZE sent: 32 rcvd: 326
All DNS records (except ns.alphapager.org and ns.herdejurgen.com)
now resolve to two IP addresses. For example:
> nslookup seann.herdejurgen.com
Server: proxy-in.alphapager.org
Address: 10.0.0.1
Name: seann.herdejurgen.com
Addresses: 65.3.17.133, 63.89.102.157
For Apache, multiple named virtual hosts are supported using the following
lines in httpd.conf:
NameVirtualHost 63.89.102.157:80
NameVirtualHost 65.3.17.133:80
Inbound LDAP and SSH traffic are distributed using round-robin DNS
and require no special configuration.
Startup Scripts
A number of startup scripts had to be modified to support our
network configuration. These scripts are specific to Red Hat, but
can easily be modified for other Linux distributions. The ip
rule commands need to be executed only once after the system
boots. Add the following lines to the start section of the /etc/rc.d/init.d/network
script to accomplish this:
# Add non interface-specific static-rules
if [ -f /etc/sysconfig/static-rules ]; then
sh /etc/sysconfig/static-rules
fi
The /etc/sysconfig/static-rules file contains:
# Setup source IP routing rules
ip rule add from 63.89.102.157 lookup 1
ip rule add from 65.3.17.133 lookup 2
# Setup load balancing
ip route add default equalize
nexthop via 63.89.102.1 dev eth1
nexthop via 65.3.17.1 dev eth2
ip route commands must be executed each time you ifup
the appropriate interface. Add the following lines to /etc/sysconfig/network-scripts/ifup-routes:
# Add any advanced routes
grep "^advanced " /etc/sysconfig/static-routes |
while read ignore dev args; do
if [ "$dev" = "$1" ]; then
/sbin/ip route add $args
fi
done
The /etc/sysconfig/static-routes file contains:
advanced eth0 10.0.0.0/24 via 10.0.0.1 table 1
advanced eth0 10.0.0.0/24 via 10.0.0.1 table 2
advanced eth1 0/0 via 63.89.102.1 table 1
advanced eth2 0/0 via 65.3.17.1 table 2
Firewalls
If you have a host attached to the Internet, you should run a
firewall to block unwanted traffic from accessing your host. Decide
which services you will allow to be accessed over the Internet,
and deny connections to all other services. Keep in mind that running
a firewall does not mean that your system is secure. Any service
you allow through the firewall may have its own security holes that
hackers can exploit, so it is important that you keep your applications
up-to-date with security patches.
Most firewall scripts only support a single external network connection
connected to an internal network. To support multiple external network
interfaces, some homegrown firewall scripts were written. The first
script uses a packet-based firewall called ipchains that comes with
Linux 2.2 kernels. The second script uses a packet-based firewall
called iptables that comes with Linux 2.4 kernels. (It is possible
to run an ipchains firewall under a Linux 2.4 kernel, but you cannot
use both ipchains and iptables simultaneously.)
iptables is the successor to ipchains and is more powerful because
it supports connection tracking, which gives Linux stateful firewall
capabilities. iptables is also extensible, which means that new
features (e.g., string matching) can be added to it without modifying
the base source code for iptables. See the sidebar for new iptables
features. Both ipchains and iptables split traffic into several
different chains of rules that decide whether to accept or reject
a packet. iptables uses three tables of chains called filter, nat,
and mangle to filter packets. When a packet traverses a chain, each
rule is checked in sequence until a match is found.
The three standard chains in ipchains are called INPUT, FORWARD,
and OUTPUT. These chains are also present in iptables in the filter
table. The INPUT chain analyzes packets just after they arrive on
a network interface. The FORWARD chain analyzes masqueraded packets.
The OUTPUT chain analyzes packets just before they are sent out
of a network interface. Figure 2 depicts the path that packets follow
while traversing the different chains in an ipchains firewall.
In iptables, two additional chains are available in the nat table
-- PREROUTING and POSTROUTING. These chains are used to perform
masquerading, also known as network address translation. All packets
traverse these chains when they arrive on a network interface and
before they are sent out of a network interface. In iptables, the
INPUT and OUTPUT chains handle packets destined for the firewall,
and the FORWARD chain handles masqueraded packets only. Figure 3
depicts the path that packets follow while traversing the different
chains in an iptables firewall.
The mangle table in iptables uses the PREROUTING and OUTPUT chains
to allow you to modify IP flags on packets, such as TTL (time to
live) or TOS (type of service).
A more detailed description of how packets traverse the different
chains in ipchains and iptables is available at:
http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-4.html
http://www.linuxdoc.org/LDP/nag2/x-087-2-firewall.future.html
Firewall Kernel Configuration
To set up an ipchains firewall using a Linux 2.2 kernel, you must
enable the following features in your kernel configuration file:
CONFIG_IP_FIREWALL=y
CONFIG_IP_MASQUERADE=y
CONFIG_IP_MASQUERADE_ICMP=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_SYN_COOKIES=y
To set up an iptables firewall using a Linux 2.4 kernel, you must
enable the following features in your kernel configuration file:
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_PSD=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_IPLIMIT=m
CONFIG_IP_NF_MATCH_STRING=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_ROUTE_TOS=y
CONFIG_SYN_COOKIES=y
At the time of this writing, some of these kernel features are not
available in the mainstream Linux 2.4 kernel, however they can be
added as patches. To add these features to your kernel, you should
install Linux kernel 2.4.13 and iptables 1.2.4, which are available
from:
http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.13.tar.gz
http://netfilter.filewatcher.org/iptables-1.2.4.tar.bz2
Use these directions to add experimental iptables patches to the kernel:
1. Install Linux 2.4.13 kernel in /usr/src/linux and get
it running.
2. Extract iptables-1.2.4.tar.bz2 into its own directory.
3. iptables-1.2.4# make patch-o-matic
Answer yes to the following patches:
string
psd (port scan detection)
iplimit
Not every patch is compatible, so only select patches you intend to
use.
4. iptables-1.2.4# make install
5. /usr/src/linux# make oldconfig
Answer m to the CONFIG_IP_NF_MATCH options that
you patched into the kernel.
6. Recompile kernel and reboot.
Note that these instructions are specific to Linux kernel 2.4.13
and iptables 1.2.4. It is expected that these experimental features
will become part of the mainstream kernel release sometime in the
future.
Firewall Scripts
The basic flow of the firewall scripts is to set up the INPUT,
FORWARD, and OUTPUT chains in succession. The iptables firewall
script also configures the PREROUTING and POSTROUTING chains. Each
script contains comments that describe what traffic is being accepted
or rejected. Some packets are rejected while others are denied.
A REJECT ignores packets and sends ICMP responses back to the senders
notifying them that their packets were dropped. A DENY (ipchains)
or DROP (iptables) simply drops the packet and does not send a response.
This makes your system appear to be non-existent when probed on
a particular port. The firewall scripts in this article are designed
to drop packets on the INPUT and FORWARD chains so that no response
is sent back to remote systems. The scripts will reject packets
on the OUTPUT chain so that your local system will receive responses
back for invalid outbound packets.
To install the firewall script on your Red Hat 7.1 system, place
the script in /etc/init.d/firewall and execute the following
command:
# chkconfig firewall on
To configure the firewall script for your system, you must edit the
following two lines to define your internal and external interfaces:
INT_IFACE="eth0"
EXT_IFACES="eth1 eth2"
The INPUT chain explicitly opens up holes in the firewall for services
that are allowed and denies the rest. You must edit the list of services
for your particular system. Inbound connections are allowed using
the following lines in the ipchains firewall script:
# ACCEPT TCP connections for various
# services found in /etc/services
for service in ftp ssh smtp domain
http auth ldap https; do
ipchains -A INPUT -i $EXT_IFACE -p tcp
-d $IP $service -j ACCEPT
done
The firewall script loops through the various services that are allowed
on the host. In this case, FTP, SSH, Sendmail, DNS (zone transfers),
HTTP, ident, LDAP, and HTTPS. The names and port numbers for these
TCP-based protocols can be found in the /etc/services file.
The INPUT chain also accepts any responses (returns) to connections
originating locally with the following rules in the ipchains firewall
script:
# ACCEPT non-SYN TCP packets on
# unprivileged ports (returns)
ipchains -A INPUT -i $EXT_IFACE -p tcp
! -y -d $IP 1024: -j ACCEPT
# ACCEPT all UDP packets on unprivileged ports
ipchains -A INPUT -i $EXT_IFACE -p udp -d $IP 1024:
-j ACCEPT
ipchains is not a stateful firewall, so this is the only way to accept
return TCP traffic using it. iptables greatly improves security by
supporting stateful firewalling, also called "connection tracking",
which means that packets are accepted only if they match an active
connection that originated locally. This is handled in the iptables
firewall script with the following rules:
# ACCEPT return TCP/UDP traffic (stateful firewall)
iptables -t filter -A INPUT -m state
--state ESTABLISHED -i $EXT_IFACE
-p tcp -d $IP --dport 1024: -j ACCEPT
iptables -t filter -A INPUT -m state
--state ESTABLISHED -i $EXT_IFACE
-p udp -d $IP --dport 1024: -j ACCEPT
Even though UDP is a stateless protocol, iptables connection tracking
maintains a state table and only allows replies on UDP ports to traffic
that originated locally.
The iptables firewall script accepts inbound connections and places
new connections in the connection-tracking database with the following
rule:
# ACCEPT inbound TCP connections for various
# services found in /etc/services
for service in ftp ssh smtp domain
http auth ldap https; do
iptables -t filter INPUT -m state
--state NEW,ESTABLISHED -i $EXT_IFACE
-p tcp -d $IP --dport $service -j ACCEPT
done
You can view the connection tracking database by viewing the file
/proc/net/ip_conntrack.
The following iptables rule allows incoming active mode FTP connections
on the firewall from TCP port 20 only if there is a related FTP
in progress:
# ACCEPT active FTP data connections on firewall
iptables -t filter -A INPUT -m state --state RELATED
-i $EXT_IFACE -p tcp -d $IP --dport 1024:
--sport ftp-data -j ACCEPT
The following rule allows incoming DNS queries to BIND:
# ACCEPT inbound DNS requests
iptables -t filter -A INPUT -i $EXT_IFACE
-p udp -d $IP --dport domain -j ACCEPT
The following rules allow incoming NTP traffic from the United States
Naval Observatory:
# ACCEPT inbound NTP updates from time servers
# tick.usno.navy.mil & tock.usno.navy.mil
for timehost in 192.5.41.40 192.5.41.41; do
iptables -t filter -A INPUT -i $EXT_IFACE -p udp
-d $IP --dport ntp -s $timehost --sport ntp
-j ACCEPT
done
The FORWARD chain simply masquerades connections for systems on the
internal network using network addresss translation (NAT). Most protocols
work using NAT, while others need a little help by using a special
module that re-writes IP addresses. Active mode FTP connections need
a helper program to get through the firewall. You can masquerade active
FTP connections by loading the ip_masq_ftp (ipchains) or ip_nat_ftp
(iptables) module with the modprobe command (unless they are
already compiled into the kernel). The remote machine in an active
FTP connection tries to connect back to the local machine through
the firewall for data transfers. The ip_masq_ftp module re-writes
packets in your FTP connection so that the internal machine appears
to be directly on the Internet. Passive mode FTP avoids this problem
by transferring all data over TCP port 21. If you choose to support
FTP, remember that it transfers passwords over the network in clear
text and is not considered to be secure. A secure alternative to FTP
is sftp, which uses secure sockets as its method of communication.
sftp is distributed with the OpenSSH client tools.
Other masquerading modules for various applications can be found
in the /lib/modules/'uname -r'/ipv4 (ipchains) or /lib/modules/'uname
-r'/ kernel/net/ipv4/netfilter/ (iptables) directories.
The FORWARD chain uses the following iptables rules to masquerade
packets traversing the firewall:
# ACCEPT new outbound traffic (stateful firewall)
iptables -t filter -A FORWARD -m state --state NEW,ESTABLISHED
-i $INT_IFACE -s $INT_NET -j ACCEPT
# ACCEPT return traffic (stateful firewall)
iptables -t filter -A FORWARD -m state --state NEW,ESTABLISHED,RELATED \
-i $EXT_IFACE -s ! $INT_NET -j ACCEPT
# Pass Internet traffic to internal network unmodified
iptables -t nat -A POSTROUTING -o $INT_IFACE -j ACCEPT
# Masquerading outbound connections from internal network
iptables -t nat -A POSTROUTING -o $EXT_IFACE -j MASQUERADE
The OUTPUT chain only accepts network traffic that is going out on
the correct interface. The OUTPUT chain also prioritizes certain traffic
by setting TOS (Type of Service) flags. For example, TOS flags can
be used to prioritize interactive (SSH) traffic over FTP traffic.
The different TOS flags are Minimize-Delay, Maximize-Throughput, Maximize-Reliability,
and Minimize-Cost.
Many ISPs ignore TOS flags on packets; however, these flags are
useful because the CONFIG_IP_ROUTE_TOS kernel option prioritizes
outbound traffic based on these flags. This means that you can have
a high-bandwidth application (such as a large FTP) running with
"maximum throughput" while an interactive application
(such as SSH) runs with "minimum delay". Thus, the FTP
won't adversely impact your SSH connection performance.
TOS flags are set in the iptables firewall script in the PREROUTING
and OUTPUT chains of the mangle table. The PREROUTING chain prioritizes
inbound packets and the OUTPUT chain prioritizes outbound packets.
The following rules are used to minimize the delay of SSH packets:
iptables -t mangle -A PREROUTING -j TOS
--set-tos Minimize-Delay -p tcp --dport ssh
iptables -t mangle -A OUTPUT -j TOS
--set-tos Minimize-Delay -p tcp --sport ssh
The OUTPUT chain also restricts the types of ICMP messages to which
the system responds. ICMP messages for ping and traceroute
are allowed, but timestamp messages (used in OS fingerprinting) are
denied. ICMP responses are configured using the following lines of
the ipchains firewall script:
# ACCEPT various ICMP messages
for message in echo-reply destination-unreachable
source-quench redirect echo-request
time-exceeded parameter-problem; do
ipchains -A OUTPUT -p icmp -s 0/0 $message -j ACCEPT
done
The last few commands of the firewall scripts set up IP forwarding
(masquerading/NAT), enable TCP SYN cookies (which helps reduce effects
of TCP SYN-scan denial of service attacks), ignore various ICMP messages,
enable reverse path routing (antispoof), and log martian packets with
impossible addresses.
Firewall Maintenance
To check the effectiveness or your firewall rules, you must execute
the firewall script with the following command:
# ./firewall status
Inspect the data in the first two columns of the output. Zeroes in
these columns indicate that no packet matched that rule. This isn't
necessarily bad -- zeroes in a DENY or DROP rule
could mean that no one is trying to hack your host using that particular
rule. Zeroes in an ACCEPT rule means that no traffic is being
accepted by that rule, however, traffic might be matching an earlier
rule in the chain.
If you need to debug your firewall rules, be sure that every REJECT
and DENY rule logs to the /var/log/messages file by
including the -l option in your ipchains command. The iptables
firewall script creates a special chain called DROPLOG, which
logs dropped packets. Remember to check your logs frequently for
intruders. A useful tool for monitoring your firewall logs is called
fwlogwatch and is available from:
http://cert.uni-stuttgart.de/projects/fwlogwatch/
These firewall scripts only allow returns on non-privileged ports,
so you may need to update your SSH configuration to allow non-privileged
ports by editing your ssh_config file and adding the line:
UsePrivilegedPort no
Summary
I have been running in this configuration for about a year and
have been pleased with its performance. However, there are a few
issues with outbound connections when a network link goes down.
If a single network link goes down, you still have redundancy for
inbound connections at the application level. Outbound connections
originating locally will be sporadic until you ifdown the
interface of the failed ISP. You may want to update DNS if your
outage extends for a long period of time. The problem occurs when
you ifup the interface, because you then must re-add the
routing entries in the secondary table (e.g., ip route add 0/0
via 63.89.102.1 table 1). The ifup-routes script was
modified to add these advanced routes automatically. If the ifdown
command is run on both interfaces, the default route will need to
be added back in the main routing table (e.g., ip route add default
equalize nexthop via...). Scripts to handle the different failover
scenarios are left as an exercise for the reader.
References
I would like to thank Lars Kellogg-Stedman for his initial write-up
on symmetric routing under Linux that became the starting point
for my research. I would also like to thank Jeff Humes for his assistance
in researching and testing this configuration. Much of the other
information in this article was obtained from the Internet using
the search engine google.com to uncover the following URLs:
fwlogwatch information page --
http://cert.uni-stuttgart.de/projects/fwlogwatch/
ICMP Usage in Scanning, by Ofir Arkin --
http://www.sys-security.com/archive/papers/ICMP_Scanning_v2.0.pdf
ipchains howto page -- http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-4.html
ipcref information page -- http://snafu.freedom.org/linux2.2/docs/ip-cref/ip-cref.html
iprouting information page --
ftp://ftp.inr.ac.ru/ip-routing/
iptables Tutorial 1.1.3, by Oskar Andreasson --
http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html
Linux Guruz iptables information page --
http://www.linuxguruz.org/iptables/
Linux Network Administrators Guide chapter "Netfilter and
IP Tables (2.4 Kernels)" -- http://www.linuxdoc.org/LDP/nag2/x-087-2-firewall.future.html
Load-balancing information page -- ftp://sliepen.warande.net/pub/eql/load-balancing.txt
Transparent Proxy with Linux and Squid mini-HOWTO, by Daniel Kiracofe
-- http://www.linuxdoc.org/HOWTO/mini/TransparentProxy.html
Seann Herdejurgen has been working with UNIX since 1987 and
now architects UNIX solutions as a seniour consultant with Collective
Technologies in Dallas, Texas. He holds a Master's degree in
Computer Science from Texas A&M University. He may be reached
at: seann@herdejurgen.com.
| 
