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.0 Stable Release is 2.0.13 -- Here are the release notes.
The current Developement Release is 2.2.0 RC2 -- Here are the release notes.

Preparing for Shorewall 2.2 -- End of support life for Shorewall 1.4 is Near!

Copyright © 2001-2004 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”.

2004-12-26

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

Shorewall 2.2.0 RC2
Shorewall 2.2.0 RC1
Shorewall 2.2.0 Beta 8
Shorewall 2.2.0 Beta 7
Shorewall 2.0.13
Shorewall 2.0.12
Shorewall 2.2.0 Beta 6
Shorewall 2.2.0 Beta 5
Shorewall 2.0.11
Shorewall 2.2.0 Beta 4
Shorewall 2.2.0 Beta 3
Shorewall 2.2.0 Beta 2
Shorewall 2.0.10
Shorewall 2.2.0 Beta 1

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.

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 Quick Search in the frame above.

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've 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. By popular demand, the default port for Open VPN tunnels is now 1194 (the IANA-reserved port number for Open VPN).

1. The syntax of the add and delete command has been clarified in the help summary produced by /sbin/shorewall.

1. TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type. OpenVPN entries in /etc/shorewall/tunnels have this format:
   
       openvpn[:{tcp|udp}][:<port>]    <zone>        <gateway>
   
   Examples:
   

       openvpn:tcp         net    1.2.3.4    # TCP tunnel on port 5000
       openvpn:3344        net    1.2.3.4    # UDP on port 3344
       openvpn:tcp:4455    net    1.2.3.4    # TCP on port 4455

2. A new 'ipsecvpn' script is included in the tarball and in the RPM. The RPM installs the file in the Documentation directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).
   
   This script is intended for use on Roadwarrior laptops for establishing an IPSEC SA to/from remote networks. The script has some limitations:
   
       - Only one instance of the script may be used at a time.
       - Only the first SPD accessed will be instantiated at the remote gateway. So while the script creates SPDs to/from the remote gateway and each network listed in the NETWORKS setting at the front of the script, only one of these may be used at a time.
   

1. A typo in the /etc/shorewall/interfaces file has been corrected.
2. Previously, the "add" and "delete" commands were generating incorrect policy matches when policy match support was available.

1. Recent 2.6 kernels include code that evaluates TCP packets based on TCP Window analysis. This can cause packets that were previously classified as NEW or ESTABLISHED to be classified as INVALID.
   
   The new kernel code can be disabled by including this command in your /etc/shorewall/init file:
   
       echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
   
   Additional kernel logging about INVALID TCP packets may be obtained by adding this command to /etc/shorewall/init:
   
       echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
   
   Traditionally, Shorewall has dropped INVALID TCP packets early. The new DROPINVALID option allows INVALID packets to be passed through the normal rules chains by setting DROPINVALID=No.
   
   If not specified or if specified as empty (e.g., DROPINVALID="") then DROPINVALID=Yes is assumed.
   
   
2. The "shorewall add" and "shorewall delete" commands now accept a list of hosts to add or delete.
   
   Examples:
   
       shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12
       shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12
   
   The above commands may also be written:
   
       shorewall add eth1:1.2.3.4,2.3.4.5 z12
       shorewall delete eth1:1.2.3.4,2.3.4.5 z12
     
   

1. The "shorewall add" and "shorewall delete" commands now work in a bridged environment. The syntax is:
    
              shorewall add <interface>[:<port>]:<address> <zone>
              shorewall delete <interface>[:<port>]:<address> <zone>
    
      Examples:
    
              shorewall add br0:eth2:192.168.1.3 OK
              shorewall delete br0:eth2:192.168.1.3 OK
   
   
2. Previously, "shorewall save" created an out-of-sequence restore script. The commands saved in the user's /etc/shorewall/start script were executed prior to the Netfilter configuration being restored. This has been corrected so that "shorewall save" now places those commands at the end of the script.
   
   To accomplish this change, the "restore base" file (/var/lib/shorewall/restore-base) has been split into two files:
    
   /var/lib/shorewall/restore-base -- commands to be executed before Netfilter the configuration is restored.
    
   /var/lib/shorewall/restore-tail -- commands to be executed after the Netfilter configuration is restored.
   
   
3. Previously, traffic from the firewall to a dynamic zone member host did not need to match the interface specified when the host was added to the zone. For example, if eth0:1.2.3.4 is added to dynamic zone Z then traffic out of any firewall interface to 1.2.3.4 will obey the fw->Z policies and rules. This has been corrected.
4. Shorewall uses the temporary chain 'fooX1234' to probe iptables for detrmining which features are supported. Previously, if that chain happened to exist when Shorewall was run, capabilities were mis-detected.

1. You can now use the "shorewall show zones" command to display the current contents of the zones. This is particularly useful if you use dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
    
       Example:
    
           ursa:/etc/shorewall # shorewall show zones
           Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004
    
           loc
              eth0:192.168.1.0/24
              eth1:1.2.3.4
           net
              eth0:0.0.0.0/0
           WiFi
              eth1:0.0.0.0/0
           sec
              eth1:0.0.0.0/0
    
           ursa:/etc/shorewall #
   
   
2. Variable expansion may now be used with the INCLUDE directive.
    
       Example:
    
           /etc/shorewall/params
    
               FILE=/etc/foo/bar
    
           Any other config file:
    
               INCLUDE $FILE
   
   
3. The output of "shorewall status" now includes the results of "ip -stat link ls". This helps diagnose performance problems caused by link errors.
4. Previously, when rate-limiting was specified in /etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded the specified rate was silently dropped. Now, if a log
   level is given in the entry (LEVEL column) then drops are logged at that level at a rate of 5/min with a burst of 5.
   

1. A typo in /usr/share/shorewall/firewall caused the "shorewall add" to issue an error message:
   

   /usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found

1. A typo in shorewall.conf (NETNOTSYN) has been corrected.
2. The "shorewall add" and "shorewall delete" commands now work in a bridged environment. The syntax is:
    
         shorewall add <interface>[:<bridge port>][:<address>] <zone>
         shorewall delete <interface>[:<bridge port>][:<address>] <zone>
    
   Examples:
    
         shorewall add br0:eth2:192.168.1.3 OK
         shorewall delete br0:eth2:192.168.1.3 OK
   
   
3. Previously, "shorewall save" created an out-of-sequence restore script. The commands saved in the user's /etc/shorewall/start script were executed prior to the Netfilter configuration being restored. This has been corrected so that "shorewall save" now places those commands at the end of the script.
    
   To accomplish this change, the "restore base" file (/var/lib/shorewall/restore-base) has been split into two files:
    
      /var/lib/shorewall/restore-base -- commands to be executed before the Netfilter configuration is restored.
    
      /var/lib/shorewall/restore-tail -- commands to be executed after the Netfilter configuration is restored.
   
   
4. Previously, traffic from the firewall to a dynamic zone member host did not need to match the interface specified when the host was added to the zone. For example, if eth0:1.2.3.4 is added to dynamic zone Z then traffic out of any firewall interface to 1.2.3.4 will obey the fw->Z policies and rules. This has been corrected.

1. Variable expansion may now be used with the INCLUDE directive.
    
   Example:
    
           /etc/shorewall/params
    
               FILE=/etc/foo/bar
    
           Any other config file:
    
               INCLUDE $FILE
   

1. Fixed a number of problems associated with not having an IPTABLES value assigned in shorewall.conf
2. Corrected a 'duplicate chain' error on "shorewall add" when the 'mss' option is present in /etc/shorewall/ipsec.
   

1. A typo in shorewall.conf (NETNOTSYN) has been corrected.

1. For consistency, the CLIENT PORT(S) column in the tcrules file has been renamed SOURCE PORT(S).
2. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown in the output of "shorewall status".
3. A new IPTABLES option has been added to shorewall.conf. IPTABLES can be used to designate the iptables executable to be used by Shorewall. If not specified, the iptables executable determined by the PATH setting is used.
   

1. The INSTALL file now include special instructions for Slackware users.
2. The bogons file has been updated.
3. Service names are replaced by port numbers in /etc/shorewall/tos.
4. A typo in the install.sh file that caused an error during a new install has been corrected.

1. The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).
   

1. A cut and paste error resulted in some nonsense in the description of the IPSEC column in /etc/shorewall/masq.
2. A typo in /etc/shorewall/rules has been corrected.
3. The bogons file has been updated.
4. The "shorewall add" command previously reported success but did nothing -- now it works.

1. The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).
   

1. Missing '#' in the rfc1918 file has been corrected.
2. The INSTALL file now includes special instructions for Slackware users.

1. In CLASSIFY rules (/etc/shorewall/tcrules), an interface name may now appear in the DEST column as in:
   

           #MARK/      SOURCE       DEST      PROTO     PORT(S)
           #CLASSIFY
           1:30        -            eth0      tcp       25

1. The "shorewall check" command results in the (harmless) error message:
    
           /usr/share/shorewall/firewall: line 2753:
              check_dupliate_zones: command not found
   
   
2. The AllowNTP standard action now allows outgoing responses to broadcasts.
3. A clarification has been added to the hosts file's description of the 'ipsec' option pointing out that the option is redundent if the zone named in the ZONE column has been designated an IPSEC zone in the /etc/shorewall/ipsec file.

1. The SUBNET column in /etc/shorewall/rfc1918 has been renamed SUBNETS and it is now possible to specify a list of addresses in that column.
   

1. The GATEWAY column was previously ignored in 'pptpserver' entries in /etc/shorewall/tunnels.
2. When log rule numbers are included in the LOGFORMAT, duplicate rule numbers could previously be generated.
3. The /etc/shorewall/tcrules file now includes a note to the effect that rule evaluation continues after a match.
4. The error message produced if Shorewall couldn't obtain the routes through an interface named in the SUBNET column of /etc/shorewall/masq was less than helpful since it didn't include the interface name.
   

1. The "shorewall status" command has been enhanced to include the values of key /proc settings:
   
   Example from a two-interface firewall:
   
   /proc
   
      /proc/sys/net/ipv4/ip_forward = 1
      /proc/sys/net/ipv4/conf/all/proxy_arp = 0
      /proc/sys/net/ipv4/conf/all/arp_filter = 0
      /proc/sys/net/ipv4/conf/all/rp_filter = 0
      /proc/sys/net/ipv4/conf/default/proxy_arp = 0
      /proc/sys/net/ipv4/conf/default/arp_filter = 0
      /proc/sys/net/ipv4/conf/default/rp_filter = 0
      /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
      /proc/sys/net/ipv4/conf/eth0/arp_filter = 0
      /proc/sys/net/ipv4/conf/eth0/rp_filter = 0
      /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0
      /proc/sys/net/ipv4/conf/eth1/arp_filter = 0
      /proc/sys/net/ipv4/conf/eth1/rp_filter = 0
      /proc/sys/net/ipv4/conf/lo/proxy_arp = 0
      /proc/sys/net/ipv4/conf/lo/arp_filter = 0
      /proc/sys/net/ipv4/conf/lo/rp_filter = 0
   

The features available in this release and the migration considerations are covered in the release notes. Highlights include:

1. The behavior produced by specifying a log level in an action invocation is now much more rational. Previously, all packets sent to the action were logged; now each rule within the invoked action behaves as if logging had been specified on it.
2. Support for the 2.6 Kernel's native IPSEC implementation is now available.
3. Support for ipp2p is included.
4. Support for the iptables CONNMARK facility is now included in Shorewall.
5. A new LOGALLNEW option facilitates problem analysis.
6. Users with a large static blacklist can now defer loading the blacklist until after the rest of the ruleset has been enabled. Doing so can decrease substantially the amount of time that connections are disabled during shorewall [re]start.
7. Support for the iptables 'iprange match' feature has been enabled. Users whose kernel and iptables contain this feature can use ip address ranges in most places in their Shorewall configuration where a CIDR netowrk can be used.
8. Accepting of source routing and martian logging may now be enabled/disabled on each interface.
9. Shorewall now supports the CLASSIFY iptable target.

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.

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.

Thanks