Copyright © 2005 Thomas M. Eastep
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”.
2005-05-19
Table of Contents
One of the most misunderstood aspects of Shorewall is its releationship with routing. This article attempts to clear some of the fog that surrounds this issue.
As a general principle:
Routing determines where packets are to be sent.
Once routing determines where the packet is to go, the firewall (Shorewall) determines if the packet is allowed to go there.
There are ways that Shorewall can affect routing which are described in the following sections.
The following diagram shows the relationship between routing decisions and Netfilter.
The light blue boxes indicate where routing decisions are made. Upon exit from one of these boxes, if the packet is being sent to another system then the interface and the next hop have been uniquely determined.
The green boxes show where Netfilter processing takes place (as directed by Shorewall). You will notice that there are two different paths through this maze, depending on where the packet originates. We will look at each of these separately.
When a packet arrives from outside, it first undergoes Netfilter PREROUTING processing. In Shorewall terms:
Packets may be marked using entries in the /etc/shorewall/tcrules file. Entries in that file
containing ":P" in the mark column are applied here as are rules
that default to the MARK_IN_FORWARD_CHAIN=No setting in
/etc/shorewall/shorewall.conf
. These marks may
be used to specify that the packet should be routed using an
alternate routing table; see the Shorewall Squid
documentation for examples.
Marking packets then using the fwmark selector in your "ip rule add" commands should NOT be your first choice. In most cases, you can use the from or dev selector instead.
The destination IP address may be rewritten as a consequence of:
DNAT[-] rules.
REDIRECT[-] rules.
Entries in /etc/shorewall/nat
.
So the only influence that Shorewall has over where these packets go is via NAT or by marking them so that they may be routed using an alternate routing table.
Processing of packets that originate on the firewall itself are initially routed using the default routing table then passed through the OUTPUT chains. Shorewall can influence what happens here:
Packets may be marked using entries in the /etc/shorewall/tcrules file (rules with "$FW" in the SOURCE column). These marks may be used to specify that the packet should be re-routed using an alternate routing table.
The destination IP address may be rewritten as a consequence of:
DNAT[-] rules that specify $FW as the SOURCE.
Entries in /etc/shorewall/nat
that
have "Yes" in LOCAL column.
So again in this case, the only influence that Shorewall has over the packet destination is NAT or marking.
The Shorewall Squid
documentation shows how alternate routing tables can be created
and used. That documentation shows how you can use logic in
/etc/shorewall/init
to create and populate an
alternate table and to add a routing rule for its use. It is fine to use
that technique so long as you understand that you are basically just using
the Shorewall init script (/etc/init.d/shorewall
) to
configure your alternate routing table at boot time and that other than as described in the previous section, there is no
connection between Shorewall and routing when using Shorewall versions
prior to 2.3.2.
There is one instance where Shorewall creates routing table entries.
When an entry in /etc/shorewall/proxyarp
contains
"No" in the HAVEROUTE column then Shorewall will create a host route to
the IP address listed in the ADDRESS column through the interface named in
the INTERFACE column. This is the only case where
Shorewall directly manipulates the routing table.
Example:
/etc/shorewall/proxyarp
:
#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 206.124.146.177 eth1 eth0 No #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
The above entry will cause Shorewall to execute the following command:
ip route add 206.124.146.177 dev eth1
Beginning with Shorewall 2.3.2, support is included for multiple internet connections.
Let's assume that a firewall is connected via two separate ethernet interfaces to two different ISPs as in the following diagram.
eth0 connects to ISP1. The IP address of eth0 is 206.124.146.176 and the ISP'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 the ISP's gateway router has IP address 130.252.99.254.
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 be load-balanced between the
two ISPs. Entries in /etc/shorewall/tcrules
can be
used to direct particular outgoing connections to one ISP or the
other.
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.
Shorewall will set up the routing and will update the /etc/iproute2/rt_tables to include the table names and number of the tables that it adds.
This feature uses packet marking to control the routing. As a consequence, there are some restrictions concerning entries in /etc/shorewall/tcrules:
Packet marking for traffic control purposes must be done in the FORWARD table.
You may not use the SAVE or RESTORE options.
You man not use connection marking.
Use of this feature requires that your kernel and iptables support CONNMARK target and conntrack match as well as extended MARK support. It does NOT require the ROUTE target extension.
The current version of iptables (1.3.1) is broken with respect to CONNMARK and iptables-save/iptables-restore. This means that if you configure multiple ISPs, shorewall restore will fail. You must patch your iptables using the patch at http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff.
The /etc/shorewall/providers
file can also be
used in other routing senarios. See the Squid documentation for an
example.
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.
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.
A number between 1 and 252. This becomes the routing table number for the generated table for this provider.
A mark value used in your /etc/shorewall/tcrules file to direct packets to this provider. Shorewall will also mark connections that have seen input from this provider with this value and will restore the packet mark in the PREROUTING CHAIN.
Gives the name and number of a routing table to duplicate. May be 'main' or the name of a previously declared provider. For most applications, you want to specify 'main' here.
The name of the interface to the provider.
The IP address of the provider's Gateway router.
A comma-separated list from the following:
If specified, connections FROM this interface are to be tracked so that responses may be routed back out this same interface.
You want specify 'track' if internet hosts will be connecting to local servers through this provider.
The providers that have 'default' specified will get outbound traffic load-balanced among them.
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 ISP1 1 1 main eth0 206.124.146.254 track,balance ISP2 2 2 main eth1 130.252.99.254 track,balance
Other configuration files go something like this:
/etc/shorewall/interfaces
:
#ZONE INTERFACE BROADCAST OPTIONS net eth0 detect … net eth1 detect …
/etc/shorewall/policy
:
#SOURCE DESTINATION POLICY LIMIT:BURST net net DROP
If you have masqueraded hosts, be sure to update
/etc/shorewall/masq
to masquerade to both ISPs. For
example, if you masquerade all hosts connected to eth2
then:
#INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth1 eth2 130.252.99.27
Beginning with Shorewall 2.3.2, Shorewall is integrated with the ROUTE target extension available from Netfilter Patch-O-Matic-NG (http://www.netfilter.org).
As of this writing, I know of no distribution that is shipping a kernel or iptables with the ROUTE target patch included. This means that you must patch and build your own kernel and iptables in order to be able to use the feature described in this section. This code remains experimental since there is no intent by the Netfilter team to ever submit the ROUTE target patch for inclusion in the official kernels from kernel.org.
See Shorewall FAQ 42 for information about determining if your kernel and iptables have this support enabled. You must be running Shorewall 2.3.2 or later to make this determination.
Routing with Shorewall is specified through entries in /etc/shorewall/routes. Note that entries in the /etc/shorewall/routes file override the routing specified in your routing tables. These rules generate Netfilter rules in the mangle tables FORWARD chain or OUTPUT chain depending whether the packets are being routed through the firewall or originate on the firewall itself (see figure above).
Columns in this file are as follows:
Source of the packet. May be any of the following:
A host or network address
A network interface name.
The name of an ipset prefaced with "+"
$FW (for packets originating on the firewall)
A MAC address in Shorewall format
A range of IP addresses (assuming that your kernel and iptables support range match)
A network interface name followed by ":" and an address or address range.
Destination of the packet. May be any of the following:
A host or network address
A network interface name (determined from routing table(s))
The name of an ipset prefaced with "+"
A network interface name followed by ":" and an address or address range.
Protocol - Must be a protocol listed in /etc/protocols, a number or "ipp2p", a number, or "all". "ipp2p" require ipp2p match support in your kernel and iptables.
Destination Ports. A comma-separated list of Port names (from /etc/services), port numbers or port ranges; if the protocol is "icmp", this column is interpreted as the destination icmp-type(s).
If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example "bit" for bit-torrent). If no PORT is given, "ipp2p" is assumed.
This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is suggested that this field contain "-"
Optional) Source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges.
Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. Tests have the format
[!]<value>[/<mask>][:C]
where:
Inverts the test (not equal)
Value of the packet or connection mark.
A mask to be applied to the mark before testing
Designates a connection mark. If omitted, the packet mark's value is tested
The interface that the packet is to be routed out of. If you do not specify this field then you must place "-" in this column and enter an IP address in the GATEWAY column.
The gateway that the packet is to be forewarded through.
The idea here is that traffic that matches the SOURCE, DEST, PROTO, PORT(S), SOURCE PORT(S) and TEST columns is routed out of the INTERFACE through the optional GATEWAY.
Example:
Your local interface is eth1 and your DMZ interface is eth2. You want to run Squid as a transparent proxy for HTTP on 192.168.3.22 in your DMZ. You would use the following entry in /etc/shorewall/routes:
#SOURCE DEST PROTO PORT(S) SOURCE TEST INTERFACE GATEWAY # PORT(S) eth1 0.0.0.0/0 tcp 80 - - eth1 192.168.3.22This entry specifies that "traffic coming in through eth1 to TCP port 80 is to be routed out of eth1 to gateway 192.168.3.22".