Shorewall 2.x

Tom Eastep

The information on this site applies only to 2.x releases of Shorewall. For older versions:

• The 1.4 site is here.

• The 1.3 site is here.

• The 1.2 site is here.

The current 2.2 Stable Release is 2.2.3 -- Here are the release notes and here are the known problems and updates.

End of support life for Shorewall 1.4 -- Upgrading to Shorewall 2.2

Copyright © 2001-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-01

Table of Contents

Introduction to Shorewall

Glossary
What is Shorewall?
Getting Started with Shorewall
Looking for Information?
Running Shorewall on Mandrake® with a two-interface setup?
License

News

Tom spoke at LinuxFest NW 2005
Shorewall 2.2.3
Shorewall 2.0.17
Shorewall 2.2.2

Donations

Introduction to Shorewall

Glossary

• Netfilter - the packet filter facility built into the 2.4 and later Linux kernels.

• ipchains - the packet filter facility built into the 2.2 Linux kernels. Also the name of the utility program used to configure and control that facility. Netfilter can be used in ipchains compatibility mode.

• iptables - the utility program used to configure and control Netfilter. The term 'iptables' is often used to refer to the combination of iptables+Netfilter (with Netfilter not in ipchains compatibility mode).

What is Shorewall?

The Shoreline Firewall, more commonly known as "Shorewall", is a high-level tool for configuring Netfilter. You describe your firewall/gateway requirements using entries in a set of configuration files. Shorewall reads those configuration files and with the help of the iptables utility, Shorewall configures Netfilter to match your requirements. Shorewall can be used on a dedicated firewall system, a multi-function gateway/router/server or on a standalone GNU/Linux system. Shorewall does not use Netfilter's ipchains compatibility mode and can thus take advantage of Netfilter's connection state tracking capabilities.

Shorewall is not a daemon. Once Shorewall has configured Netfilter, it's job is complete. After that, there is no Shorewall code running although the /sbin/shorewall program can be used at any time to monitor the Netfilter firewall.

Shorewall is not the easiest to use of the available iptables configuration tools but I believe that it is the most flexible and powerful. So if you are looking for a simple point-and-click set-and-forget Linux firewall solution that requires a minimum of networking knowledge, I would encourage you to check out the following alternatives:

• http://www.m0n0.ch/wall
• http://www.fs-security.com/
  

On the other hand, if you are looking for a Linux firewall solution that can handle complex and fast changing network environments then Shorewall is a logical choice.

Getting Started with Shorewall

New to Shorewall? Start by selecting the QuickStart Guide that most closely matches your environment and follow the step by step instructions.

Looking for Information?

The Documentation Index is a good place to start as is the Site Search in the frame above. network

Running Shorewall on Mandrake® with a two-interface setup?

If so, the documentation on this site will not apply directly to your setup. If you want to use the documentation that you find here, you will want to consider uninstalling what you have and installing a setup that matches the documentation on this site. See the Two-interface QuickStart Guide for details.

Update: I have been informed by Mandrake Development that this problem has been corrected in Mandrake 10.0 Final (the problem still exists in the 10.0 Community release).

License

This program is free software; you can redistribute it and/or modify it under the terms of Version 2 of the GNU General Public License as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more detail.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA

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".

News

1. If a zone is defined in /etc/shorewall/hosts using <interface>:!<network> in the HOSTS column then startup errors occur on "shorewall [re]start".
2. Previously, if "shorewall status" was run on a system whose kernel lacked advanced routing support (CONFIG_IP_ADVANCED_ROUTER),  then no routing information was displayed.

1. A new extension script "continue" has been added. This script is invoked after Shorewall has set the built-in filter chains policy to DROP, deleted any existing Netfilter rules and user chains and has enabled existing connections. It is useful for enabling certain communication while Shorewall is being [re]started. Be sure to delete any rules that you add here in your /etc/shorewall/start file.
2. There has been ongoing confusion about how the /etc/shorewall/routestopped file works. People understand how it works with the 'shorewall stop' command but when they read that 'shorewall restart' is logically equivalent to 'shorewall stop' followed by 'shorewall start' then they erroneously conclude that /etc/shorewall/routestopped can be used to enable new connections during 'shorewall restart'. Up to now, it cannot -- that file is not processed during either 'shorewall start' or 'shorewall restart'.
   
   Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped will be processed TWICE during 'shorewall start' and during 'shorewall restart'. It will be processed early in the command execution to add rules allowing new connections while the command is running and it will be processed again when the command is complete to remove the rules added earlier.
   
   The result of this change will be that during most of [re]start, new connections will be allowed in accordance with the contents of /etc/shorewall/routestopped.
3. The performance of configurations with a large numbers of entries in /etc/shorewall/maclist can be improved by setting the new MACLIST_TTL variable in /etc/shorewall/shorewall.conf.
   
   If your iptables and kernel support the "Recent Match" (see the output of "shorewall check" near the top), you can cache the results of a 'maclist' file lookup and thus reduce the overhead associated with MAC Verification.
   
   When a new connection arrives from a 'maclist' interface, the packet passes through then list of entries for that interface in /etc/shorewall/maclist. If there is a match then the source IP address is added to the 'Recent' set for that interface. Subsequent connection attempts from that IP address occuring within $MACLIST_TTL seconds will be accepted without having to scan all of the entries. After $MACLIST_TTL from the first accepted connection request from an IP address, the next connection request from that IP address will be checked against the entire list.
   
   If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not be cached.
4. You can now specify QUEUE as a policy and you can designate a common action for QUEUE policies in /etc/shorewall/actions. This is useful for sending packets to something like Snort Inline.
   

1. Invoking the 'rejNotSyn' action results in an error at startup.
2. The UDP and TCP port numbers in /usr/share/shorewall/action.AllowPCA were reversed.
3. If a zone is defined in /etc/shorewall/hosts using <interface>:!<network> in the HOSTS column then startup errors occur on "shorewall [re]start".
   

1. The SOURCE column in the /etc/shorewall/tcrules file now correctly allows IP ranges (assuming that your iptables and kernel support ranges).
   
2. If A is a user-defined action and you have file /etc/shorewall/A then when that file is invoked by Shorewall during [re]start, the $TAG value may be incorrect.
3. Previously, if an iptables command generating a logging rule failed, the Shorewall [re]start was still successful. This error is now considered fatal and Shorewall will be either restored from the last save (if any) or it will be stopped.
4. The port numbers for UDP and TCP were previously reversed in the /usr/share/shorewall/action.AllowPCA file.
5. Previously, the 'install.sh' script did not update the /usr/share/shorewall/action.* files.
6. Previously, when an interface name appeared in the DEST column of /etc/shorewall/tcrules, the name was not validated against the set of defined interfaces and bridge ports.
   

1. The SOURCE column in the /etc/shorewall/tcrules file now allows $FW to be optionally followed by ":" and a host/network address or address range.
2. Shorewall now clears the output device only if it is a terminal. This avoids ugly control sequences being placed in files when /sbin/shorewall output is redirected.
3. The output from 'arp -na' has been added to the 'shorewall status' display.
4. The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges to appear in port lists handled by "multiport match". If Shorewall detects this capability, it will use "multiport match" for port lists containing port ranges. Be cautioned that each port range counts for TWO ports and a port list handled with "multiport match" can still specify a maximum of 15 ports.
   
   As always, if a port list in /etc/shorewall/rules is incompatible with "multiport match", a separate iptables rule will be generated for each element in the list.
5. Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918' processing to cease for a packet if the packet's source IP address matches the rule. Thus, if you have:
   
      SUBNETS          TARGET
      192.168.1.0/24   RETURN
   
   then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you also have:
   
      SUBNETS          TARGET
      10.0.0.0/8       logdrop
   
   Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to be logged and dropped since while the packet's source matches the RETURN rule, the packet's destination matches the 'logdrop' rule.
   
   If not specified or specified as empty (e.g., RFC1918_STRICT="") then RFC1918_STRICT=No is assumed.
   
   WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support 'Connection Tracking' match.
   

More News

Leaf

LEAF is an open source project which provides a Firewall/router on a floppy, CD or CF. Several LEAF distributions including Bering and Bering-uClibc use Shorewall as their Netfilter configuration tool.

OpenWRT

Donations

Shorewall is free but if you try it and find it useful, please consider making a donation to the Alzheimer's Association or to the Starlight Children's Foundation.

Thank You