Seattle Firewall

Differences between 2.x and 3.x


The documentation is now included in the Seattle Firewall tarball in seawall/documentation/*. The documentation is in HTML format and is very similar to this web site.


The 3.0 install.sh script create a symbolic link from /etc/seawall/firewall to the firewall scripts. The firewall variable in seawall.conf is no longer used to locate the firewall script.


The 3.0 Seattle Firewall contains limited DMZ support.


The 2.x Seattle Firewall ended most chains with a -l -j DENY rule (such rules log and drop any packets matching the rule). For example, a rejected incoming TCP SYN packet would be reported out of the last rule in the tcpsyn chain. To reduce the number of rules required and to try to keep the "seawall monitor" display on a single page, the 3.0 series has only three -l -j DENY rules -- one at the end of each of the three standard chains. On 3.0 all incoming packets that are denied and logged will be logged at the end of the input chain.


If a gateway has multiple internal interfaces listed in the local variable, the 2.x series requires the user to include rules in /etc/seawall/forward that permit routing between these interfaces. 3.0 Seattle Firewall creates these rules automatically.


The 3.0 version of Seattle Firewall includes an installation script (install.sh). The script can be used to install Seattle Firewall initially and to upgrade to a new version of Seattle Firewall.


The 2.x Seattle Firewall series made certain assumptions about what applications could run on a masquerading gateway system running Seattle Firewall. It assumed that the whois client could run there and it assumed that an auth server (identd) and a secure shell server (sshd) also ran there. These assumptions were imbedded in logic in the firewall script. To extend the set of client or server applications running on the gateway or to override these basic assumptions, the user had to make entries in /etc/seawall/udp-in, /etc/seawall/tcpdata and/or /etc/seawall/tcpsyn.

Beginning with 3.0, the firewall script makes no assumptions about what can run on the gateway system. It rather consults two new files to make this determination:

The version of these files that are included in the 3.0 Seattle Firewall maintain compatibility with 2.x but may be extended by the user as required. The Seattle Firewall installation script does not overwrite these files during upgrade installation.


A new chains, tcp, has been added. All TCP packets received from the internet interface are routed through this chain. Using this chain, only a single ACCEPT rule is required for each TCP port used by servers running on the gateway or on a masqueraded system. In 2.x, two rules were required -- one in tcpsyn and one in tcpdata.


3.0 allows configuring Seattle Firewall for running PoPToP on the gateway/firewall system.


The tunnel script included with Seattle Seawall now permits "start", "stop" and "restert" arguments.


3.1 and later versions have the file /etc/seawall/tunnels that is used to define ipip and IPSec tunnels.


Less visible changes include:


Last updated 5/7/2000 - Tom Eastep