Shorewall Documentation

1. Philosophy

Shorewall is designed to allow flexible firewall configuration.

Shorewall:

bullethas no built-in policies 
bulletcreates a simple but powerful model for expressing firewall rules
bulletincludes documentation for using this simple model to solve specific problems.

2. Components

Shorewall consists of the following components:

bullet shorewall.conf -- a parameter file installed in /etc/shorewall that is used to set several firewall parameters.
bullet zones - a parameter file installed in /etc/shorewall that defines a network partitioning into "zones"
bullet policy -- a parameter file installed in /etc/shorewall/ that establishes overall firewall policy.
bullet rules -- a parameter file installed in /etc/shorewall and used to express firewall rules that are exceptions to the high-level policies established in /etc/shorewall/policy.
bulletblacklist -- a parameter file installed in /etc/shorewall and used to list blacklisted IP/subnet addresses.
bullet functions -- a set of shell functions used by both the firewall and shorewall shell programs. Installed in /etc/shorewall.
bullet modules -- a parameter file installed in /etc/shorewall and that specifies kernel modules and their parameters. Shorewall will automatically load the modules specified in this file.
bullet tos -- a parameter file installed in /etc/shorewall that is used to specify how the Type of Service (TOS) field in packets is to be set.
bullet icmp.def -- a parameter file installed in /etc/shorewall and that specifies the default handling of ICMP packets. This file should not be modified but may be copied to /etc/shorewall/icmpdef which can then be modified as desired.
bulletcommon.def -- a parameter file installed in in /etc/shorewall that defines firewall-wide rules. This file should not be modified but may be copied to /etc/shorewall/common which can then be modified as desired.
bullet interfaces -- a parameter file installed in /etc/shorewall/ and used to describe the interfaces on the firewall system.
bullet hosts -- a parameter file installed in /etc/shorewall/ and used to describe individual hosts or subnetworks in zones.
bullet masq - This file also describes IP masquerading under Shorewall and is installed in /etc/shorewall.
bulletfirewall -- a shell program that reads the configuration files in /etc/shorewall and configures your firewall. This file is installed in your init.d directory (/etc/rc.d/init.d on RedHat and Caldera , /etc/init.d on Debian , ...) where it is renamed shorewall.  /etc/shorewall/firewall is a symbolic link to this program.
bullet nat -- a parameter file in /etc/shorewall used to define static NAT .
bullet proxyarp -- a parameter file in /etc/shorewall used to define Proxy Arp .
bullettcrules -- a parameter file in /etc/shorewall used to define rules for classifying packets for Traffic Shaping/Control.
bullet tunnels -- a parameter file in /etc/shorewall used to define IPSec tunnels.
bullet shorewall -- a shell program (requiring a Bourne shell or derivative) used to control and monitor the firewall. This should be placed in /sbin or in /usr/sbin (the install.sh script installs this file in /sbin).
bullet version -- a file created in /etc/shorewall/ that describes the version of  Shorewall installed on your system.

3. Shorewall Configurations

Beginning with Shorewall version 1.1.14, Shorewall supports configuration directories other than /etc/shorewall. The shorewall start and restart commands allow you to specify an alternate configuration directory and Shorewall will use the files in the alternate directory rather than the corresponding files in /etc/shorewall. The alternate directory need not contain a complete configuration; those files not in the alternate directory will be read from /etc/shorewall.

This facility permits you to easily create a test or temporary configuration by:

  1. copying the files that need modification from /etc/shorewall to a separate directory;
  2. modify those files in the separate directory; and
  3. specifying the separate directory in a shorewall start or shorewall restart command (e.g., shorewall -c /etc/testconfig restart ).

4. Firewall Structure

Shorewall views the network in which it is running as a set of disjoint zones. Shorewall itself defines exactly one zone called "fw" which refers to the firewall system itself . The /etc/shorewall/zones file is used to define additional zones and the example file provided with Shorewall defines the zones:

  1. net -- the (untrusted) internet.
  2. dmz - systems that must be accessible from the internet and from the local network.  These systems cannot be trusted completely since their servers may have been compromised through a security exploit.
  3. loc - systems in your local network(s). These systems must be protected from the internet and from the DMZ and in some cases, from each other.

Note: Beginning with version 1.2.4, you can specify the name of the firewall zone. For ease of description in the remainder of this section, I am going to assume that the firewall zone is named "fw".

I can't stress enough that with the exception of the firewall zone, Shorewall itself attaches no meaning to zone names. Zone names are simply labels used to refer to a collection of network hosts.

Beginning with Shorewall 1.1.13, the firewall reserves the zone name "multi". This zone name is used to describe those network interface that are associated with multiple zones although it is not treated as a real zone.

Traffic directed from a zone to the firewall itself is sent through a chain named <zone name>2fw. For example, traffic inbound from the internet and addressed to the firewall is sent through a chain named net2fw. Similarly, traffic originating in the firewall and being sent to a host in a given zone is sent through a chain named fw2<zone name>. For example, traffic originating in the firewall and destined for a host in the local network is sent through a chain named fw2loc.  

Traffic being forwarded between two zones (or from one interface to a zone to another interface to that zone) is sent through a chain named <source zone>2 <destination zone>. So for example, traffic originating in a local system and destined for a remote web server is sent through chain loc2net. This chain is referred to as the canonical chain from <source zone> to <destination zone>. Any destination NAT will have occurred before the packet traverses one of these chains so rules in /etc/shorewall/rules should be expressed in terms of the destination system's real IP address as opposed to its apparent external address. Similarly, source NAT will occur after the packet has traversed the appropriate forwarding chain so the rules again will be expressed using the source system's real IP address.

Beginning with Shorewall 1.1, the firewall structure is slightly modified. For each record in the /etc/shorewall/policy file, a chain is created. Policies in that file are expressed in terms of a source zone and destination zone where these zones may be a zone defined in /etc/shorewall/zones, "fw" or "all". Policies specifying the pseudo-zone "all" matches all defined zones and "fw". These chains are referred to as Policy Chains. Notice that for an ordered pair of zones (za,zb), the canonical chain (za2zb) may also be the policy chain for the pair or the policy chain may be a different chain (za2all, for example). Packets from one zone to another will traverse chains as follows:

  1. If the canonical chain exists, packets first traverse that chain.
  2. If the canonical chain and policy chain are different and the packet does not match a rule in the canonical chain, it then is sent to the policy chain.
  3. If the canonical chain does not exist, packets are sent immediately to the policy chain.

The canonical chain from zone za to zone zb will be created only if there are exception rules defined in /etc/shorewall/rules for packets going from za to zb.

Shorewall is built on top of the Netfilter kernel facility. Netfilter implements connection tracking function that allow what is often referred to as "statefull inspection" of packets. This statefull property allows firewall rules to be defined in terms of "connections" rather than in terms of "packets". With Shorewall, you:

  1. Identify the client's zone.
  2. Identify the server's zone.
  3. If the POLICY from the client's zone to the server's zone is what you want for this client/server pair, you need do nothing further.
  4. If the POLICY is not what you want, then you must add a rule. That rule is expressed in terms of the client's zone and the server's zone.

Just because connections of a particular type are allowed between zone A and the firewall and are also allowed between the firewall and zone B DOES NOT mean that these connections are allowed between zone A and zone B. It rather means that you can have a proxy running on the firewall that accepts a connection from zone A and then establishes its own separate connection from the firewall to zone B.

If you adopt the default policy of ACCEPT from the local zone to the internet zone and you are having problems connecting from a local client to an internet server, adding a rule won't help (see point 3 above).

5. Installation

See the installation instructions . Also, Scott Merrill has written a set of step-by-step instructions for Installing a "Belt and Suspenders" Firewall Configuration under RedHat 7.2.

6. Getting Started

The steps involved in configuring Shorewall are as follows:

  1. Define your Zones (/etc/shorewall/zones ). Zones allow you to define sets of systems that are to be treated similarly by the firewall. A zone may be all of the hosts accessible through a particular network interface (see /etc/shorewall/interfaces ) or may be a more specific set of hosts (see /etc/shorewall/hosts ).
  2. Define your Policies (/etc/shorewall/policy ). Policies are like default rules for connections between zones.
  3. Define your Rules (/etc/shorewall/rules ). Rules are exceptions to the policies defined in the previous step. 
  4. Define NAT and/or Proxy ARP (/etc/shorewall/masq , /etc/shorewall/nat and /etc/shorewall/proxyarp ).
  5. Review the other files in /etc/shorewall to see if you wish to make any changes.

A couple of things to note:

bulletWhere specifying an IP address, a subnet or an interface, you can precede the item with "!" to specify the complement of the item. For example, !192.168.1.4 means "any host but 192.168.1.4".
bulletIn the rules file, rules are evaluated in the order that they appear and the first rule that a connection request matches is the one that governs the connection's disposition.
bulletDo not use blanket rules such as

    ACCEPT    local    net

That rule is a policy and belongs in the policy file as

    local    net    ACCEPT

7. Using MAC Addresses

Beginning with Shorewall version 1.2.9, MAC (Media Access Control) addresses can be used to specify packet source in several of the configuration files. To use this feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) included.

MAC addresses are 48 bits wide and each Ethernet Controller has a unique MAC address.

In Linux, MAC addresses are usually written as a series of 6 hex numbers separated by colons. Example:

     [root@gateway root]# ifconfig eth0
     eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
     inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0
     UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
     RX packets:2398102 errors:0 dropped:0 overruns:0 frame:0
     TX packets:3044698 errors:0 dropped:0 overruns:0 carrier:0
     collisions:30394 txqueuelen:100
     RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 (1582.8 Mb)
     Interrupt:11 Base address:0x1800

Because Shorewall uses colons as a separator for address fields, Shorewall requires MAC addresses to be written in another way. In Shorewall, MAC addresses begin with a tilde ("~") and consist of 6 hex numbers separated by hyphens. In Shorewall, the MAC address in the example above would be written "~02-00-08-E3-FA-55".

8. Configuration Files

You may place comments in configuration files by making the first character a pound sign ("#"). Beginning with Shorewall version 1.2.4, you may also place comments at the end of any line, again by delimiting the comment from the rest of the line with a pound sign.

Warning: If you edit your configuration files on a system running Microsoft Windows, you must run them through dos2unix before you use them with Shorewall.

9. /etc/shorewall/params

Beginning with Shorewall 1.1.13, you may use the file /etc/shorewall/params file to set shell variables that you can then use in some of the other configuration files.

It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally within the Shorewall programs

Example:

NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=noping,norfc1918


Example (/etc/shorewall/interfaces record):

net $NET_IF $NET_BCAST $NET_OPTIONS

The result will be the same as if the record had been written

net eth0 130.252.100.255 noping,norfc1918

Beginning in version 1.2.6, variables may be used anywhere in the other configuration files.

10. /etc/shorewall/zones

This file was introduced in version 1.0.4 and is used to define the network zones. Prior to version 1.0.4, the firewall script itself defined the network zones. There is one entry in /etc/shorewall/zones for each zone; Columns in an entry are:

bullet ZONE - short name for the zone. The name should be 5 characters or less in length and consist of lower-case letters or numbers. Short names must begin with a letter and the name assigned to the firewall and "multi" are reserved for use by Shorewall itself. Note that the output produced by iptables is much easier to read if you select short names that are three characters or less in length.
bullet DISPLAY - The name of the zone as displayed during Shorewall startup.
bullet COMMENTS - Any comments that you want to make about the zone. Shorewall ignores these comments.

The /etc/shorewall/zones file released with Shorewall is as follows:

ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local networks
dmz DMZ Demilitarized zone

You may add, delete and modify entries in the /etc/shorewall/zones file as desired so long as you have at least one zone defined.

Warning 1: If you rename or delete a zone, you should perform "shorewall stop; shorewall start" to install the change rather than "shorewall restart".

Warning 2: The order of entries in the /etc/shorewall/zones file is significant in some cases.

11. /etc/shorewall/interfaces

This file is used to tell the firewall which of your firewall's network interfaces are connected to which zone. There will be one entry in /etc/shorewall/interfaces for each of your interfaces. Columns in an entry are:

bullet ZONE - A zone defined in the /etc/shorewall/zones file or  "-". If you specify "-", you must use the /etc/shorewall/hosts file to define the zones accessed via this interface.
bullet INTERFACE - the name of the interface (examples: eth0, ppp0, ipsec+)
bullet BROADCAST - the broadcast address for the sub-network attached to the interface. This should be left empty for P-T-P interfaces (ppp*, ippp*); if you need to specify options for such an interface, enter "-" in this column. If you supply the special value "detect" in this column, the firewall will automatically determine the broadcast address. Note that to use this feature, you must have iproute installed and the interface must be up before you start your firewall. 
bullet OPTIONS - a comma-separated list of options. Possible options include:

blacklist - (Added in 1.2.2). This option causes incoming packets on this interface to be checked against the blacklist.

dhcp
- The interface is assigned an IP address via DHCP or is used by a DHCP server running on the firewall. The firewall will be configured to allow DHCP traffic to and from the interface even when the firewall is stopped.

noping - ICMP echo-request (ping) packets will be ignored by this interface.

routestopped - When the firewall is stopped, traffic to and from this interface will be accepted and routing will occur between this interface and other routestopped interfaces.

norfc1918 - Packets arriving on this interface and that have a source address that is reserved in RFC 1918 will be logged and dropped. Beginning with Shorewall 1.1.14, if packet mangling is enabled in /etc/shorewall/shorewall.conf , then packets arriving on this interface that have a destination address that is reserved in RFC 1918 will also be logged and dropped.

routefilter - Invoke the Kernel's route filtering facility on this interface. The kernel will reject any packets incoming on this interface that have a source address that would be routed outbound through another interface on the firewall. Warning: If you specify this option for an interface then the interface must be up prior to starting the firewall.

multi - The interface has multiple addresses and you want to be able to route between them. Example: you have two addresses on your single local interface eth1, one each in subnets 192.168.1.0/24 and 192.168.2.0/24 and you want to route between these subnets. Because you only have one interface in the local zone, Shorewall won't normally create a rule to forward packets from eth1 to eth1. Adding "multi" to the entry for eth1 will cause Shorewall to create the loc2loc chain and the appropriate forwarding rule.

dropunclean - (Added in 1.2.0_Beta2) Packets from this interface that are selected by the 'unclean' match target in iptables will be optionally logged and then dropped. Warning: This feature requires that UNCLEAN match support be configured in your kernel, either in the kernel itself or as a module. UNCLEAN support is broken in some versions of the kernel but appears to work ok in 2.4.17-rc1.

Update 12/17/2001:
The unclean match patch from 2.4.17-rc1 is available for download. I am currently running this patch applied to kernel 2.4.16.

Update 12/20/2001: I've seen a number of tcp connection requests with OPT (020405B40000080A...) being dropped in the badpkt chain. This appears to be a bug in the remote TCP stack whereby it is 8-byte aligning a timestamp (TCP option 8) but rather than padding with 0x01 it is padding with 0x00. It's a tough call whether to deny people access to your servers because of this rather minor bug in their networking software. If you wish to disable the check that causes these connections to be dropped, here's a kernel patch against 2.4.17-rc2.

logunclean - (Added in 1.2.1) This option works like dropunclean with the exception that packets selected by the 'unclean' match target in iptables are logged but not dropped. The level at which the packets are logged is determined by the setting of LOGUNCLEAN and if LOGUNCLEAN has not been set, "info" is assumed.

Example 1: You have a conventional firewall setup in which eth0 connects to a Cable or DSL modem and eth1 connects to your local network and eth0 gets its IP address via DHCP. You want to ignore ping requests from the internet and you want to check all packets entering from the internet against the black list. Your /etc/shorewall/interfaces file would be as follows:

ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,noping,norfc1918,blacklist
loc eth1 detect routestopped

Example 2: You have a standalone dialup Linux System. Your /etc/shorewall/interfaces file would be:

ZONE INTERFACE BROADCAST OPTIONS
net ppp0    

12. /etc/shorewall/hosts Configuration (version 1.1 and later)

For most applications, specifying zones entirely in terms of network interfaces is sufficient. There may be times though where you need to define a zone to be a more general collection of hosts. This is the purpose of the /etc/shorewall/hosts file.

WARNING: 90% of Shorewall users don't need to put entries in this file and 80% of those who try to add such entries do it wrong. Unless you are ABSOLUTELY SURE that you need entries in this file, don't touch it.

Columns in this file are:

bullet ZONE - A zone defined in the /etc/shorewall/zones file.
bullet HOST(S) - The name of a network interface followed by a colon (":") followed by either:
  1. An IP address (example - eth1:192.168.1.3)
  2. A subnet in the form <subnet address>/<width> (example - eth2:192.168.2.0/2)

If you want to specify an address or subnet without a network interface, use "+" as the interface (example - +:155.186.235.151). Note: Use of "+" weakens the firewall slightly and increases packet latency slightly.

bullet OPTIONS - A comma-separated list of options. Currently only a single option is defined:

routestopped - When the firewall is stopped, traffic to and from this host (these hosts) will be accepted and routing will occur between this host and other routestopped interfaces and hosts.

If you don't define any hosts for a zone, the hosts in the zone default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces to the zone.

Note 1: You probably DON'T want to specify any hosts for your internet zone since the hosts that you specify will be the only ones that you will be able to access without adding additional rules.

Note 2: If you have any entry for a zone in /etc/shorewall/hosts then the zone must be entirely defined in /etc/shorewall/hosts. For example, if a zone has two interfaces but only one interface has an entry in /etc/shorewall/hosts then hosts attached to the other interface will not be considered part of the zone.

Example:

Your local interface is eth1 and you have two groups of local hosts that you want to make into separate zones:

bullet192.168.1.0/25 
bullet192.168.1.128/25

Your /etc/shorewall/interfaces file might look like:

ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,noping,norfc1918
- eth1 detect multi

The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces to multiple zones.

The multi option allows the firewall to route between the two zones (although normally, the subnet mask for all local systems would be 255.255.255.0 which would make such an entry unnecessary).

Your /etc/shorewall/hosts file might look like:

ZONE HOST(S) OPTIONS
loc1 eth1:192.168.1.0/25  
loc2 eth1:192.168.1.128/25 routestopped

Hosts in 'loc2' can communicate with the firewall while Shorewall is stopped -- those in 'loc1' cannot.

Nested and Overlapping Zones

The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow you to define nested or overlapping zones. Such overlapping/nested zones are allowed and Shorewall processes zones in the order that they appear in the /etc/shorewall/zones file. So if you have nested zones, you want the sub-zone to appear before the super-zone and in the case of overlapping zones, the rules that will apply to hosts that belong to both zones is determined by which zone appears first in /etc/shorewall/zones.

Beginning with Shorewall version 1.1.15, hosts that belong to more than one zone may be managed by the rules of all of the zones. This is done through use of the special CONTINUE policy described below.

13. /etc/shorewall/policy Configuration.

This file is used to describe the firewall policy regarding establishment of connections. Connection establishment is described in terms of clients who initiate connections and servers who receive those connection requests. Policies defined in /etc/shorewall/policy describe which zones are allowed to establish connections with other zones.

Policies established in /etc/shorewall/policy can be viewed as default policies. If no rule in /etc/shorewall/rules applies to a particular connection request then the policy from /etc/shorewall/policy is applied.

Four policies are defined:

bullet ACCEPT - The connection is allowed.
bullet DROP - The connection request is ignored.
bullet REJECT - The connection request is rejected with an RST (TCP) or an ICMP destination-unreachable packet being returned to the client.
bullet CONTINUE - The connection is neither ACCEPTed, DROPped nor REJECTed. CONTINUE may be used when one or both of the zones named in the entry are sub-zones of or intersect with another zone. For more information, see below. 

For each policy specified in /etc/shorewall/policy, you can indicate that you want a message sent to your system log each time that the policy is applied.

Entries in /etc/shorewall/policy have four columns as follows:

  1. CLIENT - The name of a client zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all").
  2. SERVER - The name of a destination zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all").
  3. POLICY - The default policy for connection requests from the CLIENT zone to the DESTINATION zone.
  4. LOG LEVEL - Optional. If left empty, no log message is generated when the policy is applied. Otherwise, this column should contain an integer or name indicating a syslog level. See the syslog.conf man page for a description of each log level.

In the CLIENT and SERVER columns, you can enter "all" to indicate all zones. 

The policy file installed by default is as follows:

CLIENT SERVER POLICY LOG LEVEL
loc net ACCEPT  
net all DROP info
all all REJECT info

This table may be interpreted as follows:

bulletAll connection requests from the local network to hosts on the internet are accepted.
bulletAll connection requests originating from the internet are ignored and logged at level KERNEL.INFO.
bulletAll other connection requests are rejected and logged.

WARNING:

The firewall script processes  the /etc/shorewall/policy file from top to bottom and uses the first applicable policy that it finds. For example, in the following policy file, the policy for (loc, loc) connections would be ACCEPT as specified in the first entry even though the third entry in the file specifies REJECT.

CLIENT SERVER POLICY LOG LEVEL
loc all ACCEPT  
net all DROP info
loc loc REJECT info

The CONTINUE policy

Where zones are nested or overlapping , the CONTINUE policy allows hosts that are within multiple zones to be managed under the rules of all of these zones. Let's look at an example:

/etc/shorewall/zones:

ZONE DISPLAY COMMENTS
sam Sam Sam's system at home
net Internet The Internet
loc Loc Local Network

/etc/shorewall/interfaces:

ZONE INTERFACE BROADCAST OPTIONS
- eth0 detect dhcp,noping,norfc1918
loc eth1 detect routestopped

/etc/shorewall/hosts:

ZONE HOST(S) OPTIONS
net eth0:0.0.0.0/0  
sam eth0:206.191.149.197 routestopped

Note that Sam's home system is a member of both the sam zone and the net zone and as described above , that means that sam must be listed before net  in /etc/shorewall/zones.

/etc/shorewall/policy:

CLIENT SERVER POLICY LOG LEVEL
loc net ACCEPT  
sam all CONTINUE  
net all DROP info
all all REJECT info

The second entry above says that when Sam is the client, connection requests should first be process under rules where the source zone is sam and if there is no match then the connection request should be treated under rules where the source zone is net. It is important that this policy be listed BEFORE the next policy (net to all).

Partial /etc/shorewall/rules:

RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) ADDRESS
...            
ACCEPT sam loc:192.168.1.3 tcp ssh - all
ACCEPT net loc:192.168.1.5 tcp www - all
...            

Given these two rules, Sam can connect to the firewall's internet interface with ssh and the connection request will be forwarded to 192.168.1.3. Like all hosts in the net zone, Sam can connect to the firewall's internet interface on TCP port 80 and the connection request will be forwarded to 192.168.1.5. The order of the rules is not significant.

14. /etc/shorewall/rules

The /etc/shorewall/rules file defines exceptions to the policies established in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules for each of these rules. 

Entries in the file have the following columns:

bullet RESULT - ACCEPT, DROP or REJECT. These have the same meaning here as in the policy file above. Beginning with Shorewall version 1.0.4, this may optionally be followed by ":" and a syslogd log level (example: REJECT:info). This causes the packet to be logged at the specified level prior to being ACCEPTed, DROPped or REJECTed.
bullet CLIENT - Describes the client. The contents of this field must begin with the name of a zone but may be qualified further by following the zone name with a colon (":") and the qualifier. Qualifiers are may include:
bulletAn interface name - refers to any connection requests arriving on the specified interface (example loc:eth4).
bulletAn IP address - refers to a connection request from the host with the specified address (example net:155.186.235.151)
bulletA MAC Address in Shorewall format.
bulletA subnet - refers to a connection request from any host in the specified subnet (example net:155.186.235.0/24).

Beginning with version 1.1.12, you may include a list of qualifiers separated by commas. (example net:155.186.235.151,130.252.100.69)
bullet SERVER - Describes the server. May take any of the forms described above for CLIENT plus the following two additional forms:
bulletAn IP address followed by a colon and the port number that the server is listening on (service names from /etc/services are not allowed - example loc:192.168.1.3:80). 
bulletTwo colons followed by a port number (again, service names not allowed - example fw::8080) - this form is only allowed in the firewall zone and refers to a server running on the firewall itself and listening on the specified port.

These forms are used in conjunction with the ADDRESS column described below in order to perform port forwarding and port redirection respectively. In order to make use of this feature, you must have NAT enabled .
bullet PROTO - Protocol. Must be a protocol name from /etc/protocols, a number, "all" or "related" (Version 1.1.4 and later). Specifies the protocol of the connection request. "related" should be specified only if you have given ALLOWRELATED="no" in /etc/shorewall/shorewall.conf and you wish to override that setting for related connections originating with the client(s) and server(s) specified in this rule. When "related" is given for the protocol, the remainder of the columns should be left blank.
bullet PORT(S) - Port or port range being connected to. May only be specified if the protocol is tcp, udp or icmp. For icmp, this column's contents are interpreted as an icmp type. If you don't want to specify PORT(S) but need to include information in one of the columns to the right, enter "-" in this column. Beginning with version 1.1.12, you may give a list of ports and/or port ranges separated by commas. A port range has the form first-port-number:last-port-number.
bullet CLIENT PORTS(S) - May be used to restrict the rule to a particular client port or port range. If you don't want to restrict client ports but want to specify an ADDRESS in the next column, enter "-" in this column. Beginning with version 1.1.12, you may give a list of ports and/or port ranges separated by commas.
bullet ADDRESS - If included and different from any IP address given in the SERVER column then this is an address for some interface on the firewall and connections to that address that match this rule will be forwarded to the server specified in the SERVER column. In order to make use of this feature, you must have NAT enabled . If you use the special value "all" then requests matching this rule will be forwarded to the IP address given in SERVER. The IP address (or "all") may be optionally followed by ":" and a second IP address. This latter address, if present, is used as the source address for packets forwarded to the server (This is called "Source NAT" or SNAT). The special value "all" is intended to be used in port forwarding with a dynamic external IP address and in port redirection (see the first rule in example 2. below) -- IT SHOULD NOT BE USED IN ANY OTHER SITUATION.

Note:  If you use SNAT and qualify the client zone with the name of an interface (e.g., net:eth0), SNAT will occur regardless of which interface the packet arrived on.

If SNAT is not used (no ":" and second IP address), the original source address is used.

Example 1. You wish to forward all ssh connection requests from the internet to local system 192.168.1.3. 

RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) ADDRESS
ACCEPT net loc:192.168.1.3 tcp ssh - all

Example 2. You want to redirect all www requests from the local network to a Squid server running on the firewall and listening on port 8080 and the firewall zone is named "fw". Squid will require access to remote web servers.

RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) ADDRESS
ACCEPT loc fw::8080 tcp www - all
ACCEPT fw net tcp www    

Example 3. You want to run a web server at 155.186.235.222 in your DMZ and have it accessible remotely and locally. the DMZ is managed by Proxy ARP or by classical sub-netting.

RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) ADDRESS
ACCEPT net dmz:155.186.235.222 tcp www -  
ACCEPT loc dmz:155.186.235.222 tcp www    

Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded DMZ. Your internet interface address is 155.186.235.151 and you want the FTP server to be accessible from the local 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note that size the server is in the 192.168.2.0/24 subnetwork, we can assume that access to the server from that subnet will not involve the firewall.

RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) ADDRESS
ACCEPT net dmz:192.168.2.2 tcp ftp - all
ACCEPT  loc:192.168.1.0/24 dmz:192.168.2.2 tcp ftp   155.186.235.151

If you are running wu-ftpd, you should restrict the range of passive in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions so I use port range 65500-65535. In /etc/ftpaccess, this entry is appropriate:

passive ports  0.0.0.0/0 65500 65534

If you are running pure-ftpd, you would include "-p 65500:65534" on the pure-ftpd runline.

The important point here is to ensure that the port range used for FTP passive connections is unique and will not overlap with any usage on the firewall system.

Example 5. You wish to allow unlimited DMZ access to the host with MAC address 02:00:08:E3:FA:55.

RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) ADDRESS
ACCEPT loc:~02-00-08-E3-FA-55 dmz all      

Look here for information on other services.

15. /etc/shorewall/common

Shorewall allows definition of rules that apply between all zones. By default, these rules are defined in the file /etc/shorewall/common.def but may be modified to suit individual requirements. Rather than modify /etc/shorewall/common.def, you should copy that file to /etc/shorewall/common and modify that file.

The /etc/shorewall/common file is expected to contain iptables commands; rather than running iptables directly, you should run it indirectly using the Shorewall function 'run_iptables'. That way, if iptables encounters an error, the firewall will be safely stopped.

16. /etc/shorewall/masq

The /etc/shorewall/masq file is used to define classical IP Masquerading. Beginning with Shorewall version 1.2.5, it can also be used to define Source NAT (SNAT). There is one entry in the file for each subnet that you want to masquerade. In order to make use of this feature, you must have NAT enabled .

Columns are:

bullet INTERFACE - The interface that will masquerade the subnet; this is normally your internet interface. This interface name can be optionally qualified by adding ":" and a subnet or host IP. When this qualification is added, only packets addressed to that host or subnet will be masqueraded.
bullet SUBNET - The subnet that you want to have masqueraded through the INTERFACE. This may be expressed as a single IP address, a subnet or an interface name. In the latter instance, the interface must be configured and started before Shorewall is started as Shorewall will determine the subnet based on information obtained from the 'ip' utility.

Beginning with Version 1.2.11, the subnet may be optionally followed by "!' and a comma-separated list of addresses and/or subnets that are to be excluded from masquerading.
bulletADDRESS - (Added in Version 1.2.5) - The source address to be used for outgoing packets. This column is optional and if left blank, the current primary IP address of the interface in the first column is used.

Example 1: You have eth0 connected to a cable modem and eth1 connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq file would look like:    

INTERFACE SUBNET ADDRESS
eth0 192.168.9.0/24  

Example 2: You have a number of IPSEC tunnels through ipsec0 and you want to masquerade traffic from your 192.168.9.0/24 subnet to the remote subnet 10.1.0.0/16 only.

INTERFACE SUBNET ADDRESS
ipsec0:10.1.0.0/16 192.168.9.0/24  

Example 3: You have a DSL line connected on eth0 and a local network (192.168.10.0/24) connected to eth1. You want all local->net connections to use source address 206.124.146.176.

INTERFACE SUBNET ADDRESS
eth0 192.168.10.0/24 206.124.146.176

Example 4: Same as example 3 except that you wish to exclude 192.168.10.44 and 192.168.10.45 from the SNAT rule (Version 1.2.11 and later).

INTERFACE SUBNET ADDRESS
eth0 192.168.10.0/24!192.168.10.44,192.168.10.45 206.124.146.176

17. /etc/shorewall/proxyarp

The /etc/shorewall/proxyarp file is used to define Proxy ARP. You need one entry in this file for each system to be proxy arp'd. Columns are:

bullet ADDRESS - address of the system.
bullet INTERFACE - the interface that connects to the system. If the interface is obvious from the subnetting, you may enter "-" in this column.
bullet EXTERNAL - the external interface that you want to honor ARP requests for the ADDRESS specified in the first column.
bulletHAVEROUTE - If you already have a route through INTERFACE to ADDRESS, this column should contain "Yes" or "yes". If you want Shorewall to add the route, the column should contain "No" or "no".

Example: You have public IP addresses 155.182.235.0/28. You configure your firewall as follows:

bulleteth0 - 155.186.235.1 (internet connection)
bulleteth1 - 192.168.9.0/24 (masqueraded local systems)
bulleteth2 - 192.168.10.1 (interface to your DMZ)

In your DMZ, you want to install a Web/FTP server with public address 155.186.235.4. On the Web server, you subnet just like the firewall's eth0 and you configure 155.186.235.1 as the default gateway. In your /etc/shorewall/proxyarp file, you will have:

ADDRESS INTERFACE EXTERNAL HAVEROUTE
155.186.235.4 eth2 eth0 No

Note: You may want to configure the servers in your DMZ with a subnet that is smaller than the subnet of your internet interface. See the Proxy ARP Subnet Mini Howto for details. In this case you will want to place "Yes" in the HAVEROUTE column.

To learn how I use Proxy ARP in my DMZ, see my configuration files.

Warning: Do not use Proxy ARP and FreeS/Wan on the same system unless you are prepared to suffer the consequences. If you start or restart Shorewall with an IPSEC tunnel active, the proxied IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to the interface that you specify in the INTERFACE column of /etc/shorewall/proxyarp. I haven't had the time to debug this problem so I can't say if it is a bug in the Kernel or in FreeS/Wan. 

You might be able to work around this problem using the following (I haven't tried it):

In /etc/shorewall/init, include:

     qt service ipsec stop

In /etc/shorewall/start, include:

    qt service ipsec start

18. /etc/shorewall/nat

The /etc/shorewall/nat file is used to define static NAT. There is one entry in the file for each static NAT relationship that you wish to define. In order to make use of this feature, you must have NAT enabled .

IMPORTANT: If all you want to do is forward ports to servers behind your firewall, you do NOT want to use static NAT. Port forwarding can be accomplished with simple entries in the rules file. Also, in most cases Proxy ARP provides a superior solution to static NAT because the internal systems are accessed using the same IP address internally and externally.

Columns in an entry are:

bullet EXTERNAL - External IP address - This should NOT be the primary IP address of the interface named in the next column.
bullet INTERFACE - Interface that you want the EXTERNAL IP address to appear on.
bullet INTERNAL - Internal IP address.
bulletALL INTERFACES - If Yes or yes (or left empty), NAT will be effective from all hosts. If No or no then NAT will be effective only through the interface named in the INTERFACE column.
bulletLOCAL - If Yes or yes and the ALL INTERFACES column contains Yes or yes, NAT will be effective from the firewall system.

Look here for additional information and an example.

19. /etc/shorewall/tunnels

The /etc/shorewall/tunnels file allows you to define IPSec, GRE and IPIP tunnels with end-points on your firewall. To use ipsec, you must install version 1.9, 1.91 or the current FreeS/WAN development snapshot. 

Note: For kernels 2.4.4 and above, you will need to use version 1.91 or a development snapshot as patching with version 1.9 results in kernel compilation errors.

Instructions for setting up IPSEC tunnels may be found here and instructions for IPIP tunnels are here . Look here for information about setting up PPTP tunnels under Shorewall.

20. /etc/shorewall/shorewall.conf

This file is used to set the following firewall parameters:

bulletFW
This parameter specifies the name of the firewall zone. If not set or if set to an empty string, the value "fw" is assumed.
bulletSUBSYSLOCK
This parameter should be set to the name of a file that the firewall should create if it starts successfully and remove when it stops. Creating and removing this file allows Shorewall to work with your distribution's initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall. For Debian, the value is /var/state/shorewall and in LEAF it is /var/run/shorwall. Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
bullet STATEDIR
This parameter specifies the name of a directory where Shorewall stores state information. If the directory doesn't exist when Shorewall starts, it will create the directory. Example: STATEDIR=/tmp/shorewall.
bullet ALLOWRELATED (Version 1.1.4 or later)
This parameter must be assigned the value "Yes" ("yes") or "No" ("no") and specifies whether Shorewall allows connection requests that are related to an already allowed connection. If you say "No" ("no"), you can still override this setting by including "related" rules in /etc/shorewall/rules ("related" given as the protocol).
bullet MODULESDIR (Version 1.1.5 or later)
This parameter specifies the directory where your kernel netfilter modules may be found. If you leave the variable empty, Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
bullet LOGRATE and LOGBURST (Version 1.1.6 or later).
These parameters set the match rate and initial burst size for logged packets. Please see the iptables man page for a description of the behavior of these parameters (the iptables option --limit is set by LOGRATE and --limit-burst is set by LOGBURST). If both parameters are set empty, no rate-limiting will occur.
bulletLOGFILE (Added in version 1.2.2)
This parameter tells the /sbin/shorewall program where to look for Shorewall messages when processing the "show log", "monitor", "status" and "hits" commands. If not assigned or if assigned an empty value, /var/log/messages is assumed.
bulletNAT_ENABLED (Version 1.1.9 or later)
This parameter determines whether Shorewall supports NAT operations. NAT operations include:

    Static NAT
    Port Forwarding
    Port Redirection
    Masquerading

If the parameter has no value or has a value of "Yes" or "yes" then NAT is enabled. If the parameter has a value of "no" or "No" then NAT is disabled.
bullet MANGLE_ENABLED (Version 1.1.9 or later)
This parameter determines if packet mangling is enabled. If the parameter has no value or has a value of "Yes" or "yes" than packet mangling is enabled. If the parameter has a value of "no" or "No" then packet mangling is disabled. If packet mangling is disabled, the /etc/shorewall/tos file is ignored.
bullet IP_FORWARDING (Added in version 1.1.10)
This parameter determines whether Shorewall enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values are:

    On or on - packet forwarding will be enabled.
    Off or off - packet forwarding will be disabled.
    Keep or keep - Shorewall will neither enable nor disable packet forwarding.

If this variable is not set or is given an empty value (IP_FORWARD="") then IP_FORWARD=On is assumed.
bulletADD_IP_ALIASES (Added in version 1.1.16)
This parameter determines whether Shorewall automatically adds the external address(es) in /etc/shorewall/nat . If the variable is set to "Yes" or "yes" then Shorewall automatically adds these aliases. If it is set to "No" or "no", you must add these aliases yourself using your distribution's network configuration tools.

If this variable is not set or is given an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.
bulletADD_SNAT_ALIASES (Added in version 1.2.10)
This parameter determines whether Shorewall automatically adds the SNAT ADDRESS in /etc/shorewall/masq. If the variable is set to "Yes" or "yes" then Shorewall automatically adds these addresses. If it is set to "No" or "no", you must add these addresses yourself using your distribution's network configuration tools.

If this variable is not set or is given an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.
bulletLOGUNCLEAN (Added in Version 1.2.0_RC1)
This parameter determines the logging level of mangled/invalid packets controlled by the 'dropunclean and logunclean' interface options. If LOGUNCLEAN is empty (LOGUNCLEAN=) then packets selected by 'dropclean' are dropped silently ('logunclean' packets are logged under the 'info' log level). Otherwise, these packets are logged at the specified level (Example: LOGUNCLEAN=debug).
bulletBLACKLIST_DISPOSITION (Added in Version 1.2.2)
This parameter determines the disposition of packets from blacklisted hosts. It may have the value DROP if the packets are to be dropped or REJECT if the packets are to be replied with an ICMP port unreachable reply or a TCP RST (tcp only). If you do not assign a value or if you assign an empty value then DROP is assumed.
bulletBLACKLIST_LOGLEVEL (Added in Version 1.2.2)
This paremter determines if packets from blacklisted hosts are logged and it determines the syslog level that they are to be logged at. Its value is a syslog log level (Example: BLACKLIST_LOGLEVEL=debug). If you do not assign a value or if you assign an empty value then packets from blacklisted hosts are not logged.
bulletCLAMPMSS (Added in Version 1.2.3)
This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and is usually required when your internet connection is through PPPoE or PPTP. If set to "Yes" or "yes", the feature is enabled. If left blank or set to "No" or "no", the feature is not enabled. Note: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.
bulletROUTE_FILTER (Added in Version 1.2.11)
If this parameter is given the value "Yes" or "yes" then route filtering is enabled on all network interfaces. The default value is "no".

21. /etc/shorewall/modules Configuration

The file /etc/shorewall/modules contains commands for loading the kernel modules required by Shorewall-defined firewall rules. Shorewall will source this file during start/restart provided that it exists and that the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).

The file that is released with Shorewall calls the Shorewall function "loadmodule" for the set of modules that I load.

The loadmodule function is called as follows:

loadmodule <modulename> [ <module parameters> ]

where

<modulename>                

is the name of the modules without the trailing ".o" (example ip_conntrack).

<module parameters>

Optional parameters to the insmod utility.

The function determines if the module named by <modulename> is already loaded and if not then the function determines if the ".o" file corresponding to the module exists in the moduledirectory; if so, then the following command is executed:

insmod moduledirectory/<modulename>.o <module parameters>

If the file doesn't exist, the function determines of the ".o.gz" file corresponding to the module exists in the moduledirectory. If it does, the function assumes that the running configuration supports compressed modules and execute the following command:

insmod moduledirectory/<modulename>.o.gz <module parameters>

22. /etc/shorewall/tos Configuration

The /etc/shorewall/tos file allows you to set the Type of Service field in packet headers based on packet source, packet destination, protocol, source port and destination port. In order for this file to be processed by Shorewall, you must have mangle support enabled .

Entries in the file have the following columns:

bullet SOURCE -- The source zone. May be qualified by following the zone name with a colon (":") and either an IP address, an IP subnet, a MAC address in Shorewall Format or the name of an interface. This column may also contain the name of the firewall zone to indicate packets originating on the firewall itself or "all" to indicate any source.
bullet DEST -- The destination zone. May be qualified by following the zone name with a colon (":") and either an IP address or an IP subnet. Because packets are marked prior to routing, you may not specify the name of an interface. This column may also contain  "all" to indicate any destination.
bullet PROTOCOL -- The name of a protocol in /etc/protocols or the protocol's number.
bullet SOURCE PORT(S) -- The source port or a port range. For all ports, place a hyphen ("-") in this column.
bullet DEST PORT(S)  -- The destination port or a port range. To indicate all ports, place a hyphen ("-") in this column.
bullet TOS -- The type of service. Must be one of the following:

Minimize-Delay (16)
Maximize-Throughput (8)
Maximize-Reliability (4)
Minimize-Cost (2)
Normal-Service (0)

The /etc/shorewall/tos file that is included with Shorewall contains the following entries.

SOURCE DEST PROTOCOL SOURCE PORT(S) DEST PORT(S) TOS
all all tcp - ssh 16
all all tcp ssh - 16
all all tcp - ftp 16
all all tcp ftp - 16
all all tcp - ftp-data 8
all all tcp ftp-data - 8

23. /etc/shorewall/blacklist

Each line in /etc/shorewall/blacklist contains an IP address, a MAC address in Shorewall Format or subnet address. Example:

      130.252.100.69
      206.124.146.0/24

Packets from hosts listed in the blacklist file will be disposed of according to the value assigned to the BLACKLIST_DISPOSITION and BLACKLIST_LOGLEVEL variables in /etc/shorewall/shorewall.conf. Only packets arriving on interfaces that have the 'blacklist' option in /etc/shorewall/interfaces are checked against the blacklist.

24. Starting/Stopping and Monitoring the Firewall

If you have a permanent internet connection such as DSL or Cable, I recommend that you start the firewall automatically at boot. Once you have installed "firewall" in your init.d directory, simply type "chkconfig --add firewall". This will start the firewall in run levels 2-5 and stop it in run levels 1 and 6. If you want to configure your firewall differently from this default, you can use the "--level" option in chkconfig (see "man chkconfig") or using your favorite graphical run-level editor.

Important Note:

If you use dialup, you may want to start the firewall in your /etc/ppp/ip-up.local script. I recommend just placing "shorewall restart" in that script.

You can manually start and stop Shoreline Firewall using the "shorewall" shell program:

bulletshorewall start - starts the firewall
bulletshorewall stop - stops the firewall
bulletshorewall restart - stops the firewall (if it's running) and then starts it again
bulletshorewall reset - reset the packet and byte counters in the firewall
bulletshorewall clear - remove all rules and chains installed by Shoreline Firewall
bulletshorewall refresh - refresh the rules involving the broadcast addresses of firewall interfaces and the blacklist.

The "shorewall" program may also be used to monitor the firewall.

bulletshorewall status - produce a verbose report about the firewall (iptables -L -n -v)
bulletshorewall show chain - produce a verbose report about chain (iptables -L chain -n -v)
bulletshorewall show nat - produce a verbose report about the nat table (iptables -t nat -L -n -v)
bulletshorewall show tos - produce a verbose report about the mangle table (iptables -t mangle -L -n -v)
bulletshorewall show log - display the last 20 packet log entries.
bulletshorewall show connections - displays the IP connections currently being tracked by the firewall (added in version 1.1.16).
bulletshorewall show tc - displays information about the traffic control/shaping configuration (Added in version 1.2.0)
bulletshorewall monitor [ delay ] - Continuously display the firewall status, last 20 log entries and nat. When the log entry display changes, an audible alarm is sounded.
bulletshorewall hits - Produces several reports about the Shorewall packet log messages in the current /var/log/messages file.
bulletshorewall version - (added in version 1.2.5) Displays the installed version number.
bulletshorewall check - (added in version 1.2.7) Performs a cursory validation of the zones, interfaces, hosts, rules and policy files.
bulletshorewall try configuration-directory [ timeout ] - (added in version 1.2.10 and enhanced in 1.2.11) Restart shorewall using the specified configuration and if an error occurs or if the timeout option is given and the new configuration has been up for that many seconds then shorewall is restarted using the standard configuration.

Beginning with Shorewall version 1.1.14, the shorewall start and shorewall restart commands allow you to specify which Shorewall configuration to use:

shorewall [ -c configuration-directory ] {start|restart}

If a configuration-directory is specified, each time that Shorewall is going to use a file in /etc/shorewall it will first look in the configuration-directory . If the file is present in the configuration-directory, that file will be used; otherwise, the file in /etc/shorewall will be used.

25. Extension Scripts

Beginning with version 1.1, Shorewall includes provisions for extending Shorewall through Extension Scripts. Extension scripts are user-provided scripts that are invoked at various points during firewall start, restart, stop and clear. The scripts are placed in /etc/shorewall and are processed using the Bourne shell "source" mechanism. The following scripts can be supplied:

bulletinit -- invoked early in "shorewall start" and "shorewall restart"
bulletstart -- invoked after the firewall has been started or restarted.
bulletstop -- invoked after the firewall has been stopped.
bulletclear -- invoked after the firewall has been cleared.

You can also supply a script with the same name as any of the filter chains in the firewall and the script will be invoked after the /etc/shorewall/rules file has been processed but before the /etc/shorewall/policy file has been processed.

Beginning with version 1.1.2, the following two files receive special treatment:

bullet/etc/shorewall/common -- If this file is present, the rules that it defines will totally replace the default rules in the common chain. These default rules are contained in the file /etc/shorewall/common.def which may be used as a starting point for making your own customized file.
bullet/etc/shorewall/icmpdef -- If this file is present, the rules that it defines will totally replace the default rules in the icmpdef chain. These default rules are contained in the file /etc/shorewall/icmp.def which may be used as a starting point for making your own customized file.

Rather than running iptables directly, you should run it using the function run_iptables. Similarly, rather than running "ip" directly, you should use run_ip. These functions accept the same arguments as the underlying command but cause the firewall to be stopped if an error occurs during processing of the command.

26. LEAF

Jacques Nilo and Eric Wolzak have a LEAF offering that features Shorewall-1.2.9 and Kernel-2.4.18. You can find their work at:

http://leaf.sourceforge.net/devel/jnilo

Updated 4/19/2002 - Tom Eastep

Copyright © 2001, 2002 Thomas M. Eastep.