<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Old News </title>
</head>

<body>
<span style="font-weight: bold;">2007-02-10 Shorewall 3.2.9<br>
</span> 
<pre>Problems Corrected in 3.2.9<br><br>1)  While most distributions store the Shorewall Lite compiled program<br>    in /var/lib/shorewall-lite/, Shorewall includes features that allow<br>    that location to be changed on a per-distribution basis. The<br>    default for a particular distribution may be determined by the<br>    command "shorewall[-lite] show config".<br><br>        teastep@lists:~/shorewall/trunk$ shorewall show config<br>        Default CONFIG_PATH is /etc/shorewall:/usr/share/shorewall<br>        LITEDIR is /var/lib/shorewall-lite<br>        teastep@lists:~/shorewall/trunk$<br><br>    The LITEDIR setting is the location where the compiled script<br>    should be placed. Unfortunately, the "shorewall [re]load" command<br>    previously used the setting on the administrative system rather<br>    than the one from the firewall system so it was possible for that<br>    command to upload the compiled script to the wrong directory.<br><br>    To work around this problem, Shorewall now determines the LITEDIR<br>    setting on the firewall system and uses that setting for uploading<br>    the compiled script and its companion .conf file.<br><br>2)  Previously, IP ranges and ipset names were handled incorrectly in<br>    the last column of the maclist file with the result that run-time<br>    errors occured.<br><br>3)  The new SIP and H323 Netfilter helper modules were not being<br>    automatically loaded by Shorewall. They have now been added to the<br>    /usr/share/shorewall[-lite]/modules files.<br><br>Other Changes in 3.2.9<br><br>1)  Previously, 'ipsecnat' tunnels allowed AH traffic by default<br>    (unless 'isecnat:noah' was given). Given that AH is incompatible<br>    with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.<br><br>2)  A macro that handles SixXS has been contributed by Christian<br>    Roessner.<br><br>3)  It is rather difficult to code a 'params' file that assigns other<br>    than constant values such that it works correctly with Shorewall<br>    Lite. To work around this problem, a new EXPORTPARAMS option<br>    has been added to shorewall.conf. When EXPORTPARAMS=No, the<br>    'params' file is no longer copied to the compiler output.<br><br>    With EXPORTPARAMS=No, if you need to set environmental variables on<br>    the firewall system for use by your extension scripts, then do so<br>    in the init extension script.<br><br>    The default is EXPORTPARAMS=Yes to retain the current behavior. So<br>    if you are happy with the current behavior, you need make no change<br>    to your shorewall.conf file.<br></pre>
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;"></span><span>style="font-weight:
bold;"&gt;2007-01-16 Shorewall 3.2.8<br>
</span><span style="font-weight: bold;"></span> 
<pre>Problems Corrected in 3.2.8<br><br>1)  The 'ash' shell produced an error when processing an entry with a<br>    log tag from /etc/shorewall/rules.<br><br>2)  If the file /etc/shorewall/init did not exist, then the compiler<br>    would incorrectly copy /usr/share/shorewall/init into the<br>    compiled script. /usr/share/shorewall/init is a symbolic link<br>    to the Shorewall init script (usually /etc/init.d/shorewall).<br><br>3)  Previously, "ipp2p:udp" was incorrectly rejected in the PROTO<br>    column of an action definition.<br><br>Other Changes in 3.2.8.<br><br>1)  New macros for network printing protocols have been added,<br>    courtesy of Tuomo Soini. Tuomo also provided a macro for TFTP.<br><br>    The print-oriented macros are:<br><br>        macro.IPP<br>        macro.Jetdirect<br>        macro.Printer<br></pre>
<span style="font-weight: bold;"></span><span
style="font-weight: bold;"></span> 
<pre><span style="font-weight: bold;"></span></pre>
<hr style="width: 100%; height: 2px;">
<pre><span style="font-weight: bold;">2006-12-14 Shorewall 3.2.7</span><br></pre>
<pre>Problems Corrected in 3.2.7<br><br>1)  Handling of saved ipsets in /etc/shorewall/ipsets is broken when<br>    used on a system running Shorewall Lite. If there is a file named<br>    'ipsets' on the CONFIG_PATH when the firewall script is compiled,<br>    then the compiled script attempts to restore the ipsets from that<br>    file (which may not exist on the firewall system).<br><br>2)  The 'try' command failed on systems whose /bin/sh is Busybox ash:<br><br>        /sbin/shorewall: export: 2158: Illegal option -n<br><br>3)  Previously, Shorewall has assumed that the root user is named<br>    'root'. Beginning with this release, the root user may have a<br>    different name. This required the addition of an '-r' option for<br>    the 'shorewall load' and 'shorewall reload' commands.<br><br>        [re]load [ -e ] [ -c ] [ -r &lt;root user&gt; ] [ &lt;dir&gt; ] system<br><br>    Example: shorewall reload -r foobar firewall<br><br>4)  On systems with a light-weight shell such as ash or dash for /bin/sh,<br>    the output of "shorewall show macros" was garbled.<br><br>Other Changes in 3.2.7<br><br>1)  Prior to this release, on firewall systems with Shorewall Lite<br>    installed, the local modules file is used to determine which kernel<br>    modules to load. Beginning with this release, if there is a<br>    'modules' file in the export directory when the firewall script is<br>    compiled, then that file will be copied into the compiled script<br>    and used on the firewall system.<br><br>2)  When syslogd is run with the -C option (which in some<br>    implementations causes syslogd to log to an in-memory circular<br>    buffer), /sbin/shorewall will now use the 'logread' command to read<br>    the log from that buffer. This is for combatibility with OpenWRT.<br><br>3)  Failures of the start, restart and restore commands are now logged<br>    using 'logger'. These failures are logged with the 'kern' facility <br>    and 'err' priority. As part of this change, normal state changes<br>    are now logged with the 'kern' facility and 'info' priority.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-11-18 Shorewall 3.2.6<br>
</span><span style="font-weight: bold;"></span> 
<pre>Problems Corrected in 3.2.6.<br><br>1)  When using a light-weight shell (e.g., ash) with multiple<br>providers, the /etc/iproute2/rt_tables database may become corrupted.<br><br>2)  A startup error occurred when the LENGTH or TOS column was<br>    non-empty in /etc/shorewall/tcrules.<br><br>3)  A startup error resulted when whitespace as included in LOGFORMAT.<br><br>4)  Previously, when conntrack match support was not available, the<br>    'norfc1918' option on an interface or host group was incorrectly<br>    filtering IPSEC traffic whose source IP address was reserved by RFC<br>    1918.<br><br>5)  If a DNAT or REDIRECT rule was used where the effective policy<br>    between the source and final destination zones is ACCEPT, the ACCEPT<br>    part of the rule was not generated. This was intended as an<br>    optimizaiton but it could lead to confusing results if there was a<br>    DROP or REJECT rule following.<br><br>    This optimization has been removed. You may always use DNAT- and<br>    REDIRECT- to suppress generation of the ACCEPT rule.<br><br>6)  Shorewall[-lite] previously would return an error exit status to a<br>    "start" command where Shorewall was already running. It not returns<br>    a "success" status.<br><br>7)  The install.sh scripst have been corrected to work properly when <br>    used to create packages on Slackware and Arch Linux.<br><br>5)  A change in version 3.2.5 broke Mac Filtration in some<br>    cases. Result was:<br><br>      Setting up MAC Filtration -- Phase 1...<br>      iptables v1.3.6: policy match: invalid policy `--dir'<br>      Try `iptables -h' or 'iptables --help' for more information.<br>      ERROR: Command "/sbin/iptables -A eth1_fwd -s 0.0.0.0/0 -m state <br>             --state NEW -m policy --pol --dir in -j eth1_mac" Failed<br><br>6)  At VERBOSITY 1 and higher, the 'shorewall add' and 'shorewall<br>    delete' commands generated a fractured message. The message<br>    contents depended in the setting of IPSECFILE as follows:<br><br>    IPSECFILE=ipsec<br><br>        ipsec...<br><br>    IPSECFILE=zones<br><br>        IPSEC...<br><br>    The messages have been corrected and are only produced at VERBOSITY<br>    2 and higher as follows:<br><br>    IPSECFILE=ipsec<br><br>        Processing /etc/shorewall/ipsec...<br><br>    IPSECFILE=zones<br><br>        Processing IPSEC...<br><br>7)  Previously, when &lt;action&gt;:none appeared in a rule, the name of the<br>    action chain created was preceded by "%" and might have a one- or<br>    two-digit number appended. If both &lt;action&gt; and &lt;action&gt;:none<br>    appeared, then two chains were created. This has been corrected<br>    such that &lt;action&gt; and &lt;action&gt;:none are treated identically.<br><br>8)  If SAVE_IPSETS=Yes in shorewall.conf, the "shorewall[-lite] save"<br>    command produced error messages as follows:<br><br>       Dynamic Rules Saved<br>       Currently-running Configuration Saved to /var/lib/shorewall/restore<br>       grep: /var/lib/shorewall/restore-base: No such file or directory<br>       grep: /var/lib/shorewall/restore-base: No such file or directory<br>       Current Ipset Contents Saved to<br>       /var/lib/shorewall/restore-ipsets<br><br>9)  If BRIDGING=No in shorewall.conf, then an attempt to define a zone<br>    using ipsets fails as follows:<br><br>    ERROR: BRIDGING=Yes is needed for this zone definition: z eth0:+iset<br><br>Other Changes in 3.2.6.<br><br>1)  The "shorewall [re]load" command now supports a "-c" option.<br><br>    Example:<br><br>        shorewall reload -c gateway<br><br>    When -c is given, Shorewall will capture the capabilities of the<br>    remote system to a file named "capabilities" in the export<br>    directory before compiling the configuration.<br><br>    If the file "capabilities" does not currently exist in the <br>    export directory then "-c" is automatically assumed.<br><br>2)  If 0 (zero) is specified for the IN-BANDWIDTH in<br>    /etc/shorewall/tcdevices then no ingress qdisc will be created for<br>    the device.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-10-28 Shorewall 3.2.5<br>
</span><span style="font-weight: bold;"></span> 
<pre>Problems Corrected in 3.2.5<br><br>1)  Entries such as the following in /etc/shorewall/masq generate a<br>    run-time error:<br><br>           eth0    eth1!192.168.1.12            206.124.146.176<br><br>    Omitting the exclusion (!192.168.1.12) avoids the error.<br><br>2)  Previously, the 'provider' portion of the packet mark was not being<br>    cleared after routing for traffic that originates on the firewall<br>    itself.<br><br>3)  In prior releases, it was not possible to mark an outgoing packet<br>    with a high mark (HIGH_ROUTE_MARKS=Yes) when the packet originated<br>    on the firewall itself.<br><br>4)  The detected capabilities were not displayed by 'shorewall dump'<br>    when the effective VERBOSITY was less than 2.<br><br>Other changes in 3.2.5<br><br>1)  For users whose kernel and iptables have Extended MARK Target<br>    support, it is now possible to logically AND or OR a value into the<br>    current packet mark by preceding the mark value (and optional mask)<br>    with an ampersand ("&amp;") or vertical bar ("|") respectively.<br><br>    Example: To logically OR the value 4 into the mark value for<br>    packets from 192.168.1.1:<br><br>    #MARK   SOURCE<br>    |4      192.168.1.1<br><br>2)  A new macro (macro.RDP) has been added for Microsoft Remote<br>    Desktop. This macro was contributed by Tuomo Soini.<br><br>3)  A new 'maclog' extension file has been added. This file is<br>    processed just before logging based on the setting of<br>    MACLIST_LOG_LEVEL is done. When the script is copyied at compile<br>    time, the CHAIN variable will contain the name of the chain where<br>    rules should be inserted. Remember that if you have specified<br>    MACLIST_TABLE=mangle, then your run_iptables commands should<br>    include "-t mangle".<br><br>4)  Beginning with this release, Shorewall and Shorewall lite will<br>    share the same change log and release notes.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-10-6 Shorewall 3.0.9<br>
</span><span style="font-weight: bold;"></span> 
<pre>Problems corrected in 3.0.9<br><br>1)  When using a light-weight shell like ash or dash, "shorewall<br>    [re]start" fails when using the built-in traffic shaper. The error<br>    messages resemble these:<br><br>    local: 3: eth0:: bad variable name<br>    ERROR: Command "tc class add dev eth0 parent 1: classid 1:1 htb rate 800kbit mtu" Failed<br><br>2)  The output formating of the 'hits' command under BusyBox 1.2.0 has<br>    been corrected.<br><br>3)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not<br>    affect traffic to/from the firewall zone. That has been corrected.<br><br>4)  Previously, using IP address ranges in the accounting file could<br>    cause non-fatal iptables errors during shorewall [re]start.<br><br>Other changes in 3.0.9<br><br>1)  It is now possible to use the special value 'detect' in the ADDRESS<br>    column of /etc/shorewall/masq. This allows you to specify SNAT (as<br>    opposed to MASQUERADE) without having to know the ip address of the<br>    external interface. Shorewall must be restarted each time that the<br>    external address (the address of the interface named in the<br>    INTERFACE column) changes.<br><br>2)  Experimental optimization for PPP devices has been added to the<br>    providers file. If you omit the GATEWAY column for a ppp device (or<br>    enter "-" in the column) then Shorewall will generate routes<br>    for the named INTERFACE that do not specify a gateway IP address<br>    (the peer address will be assumed).<br><br>3)  Normally, Shorewall tries to protect users from themselves by<br>    preventing PREROUTING and OUTPUT tcrules from being applied to<br>    packets that have been marked by the 'track' option in<br>    /etc/shorewall/providers.<br><br>    If you really know what you are doing and understand packet marking<br>    thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and<br>    Shorewall will not include these cautionary checks.<br><br>4)  Previously, CLASSIFY tcrules were always processed out of the<br>    POSTROUTING chain. Beginning with this release, they are processed<br>    out of the POSTROUTING chain *except* when the SOURCE is<br>    $FW[:&lt;address&gt;] in which case the rule is processed out of the<br>    OUTPUT chain.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-09-27 Shorewall 3.2.4<br>
</span><span style="font-weight: bold;"></span> 
<pre>Shorewall Problems corrected in 3.2.4<br><br>1)  Previously, the directory name in the command "shorewall start<br>    &lt;directory name&gt;" was being dropped by "/sbin/shorewall".<br><br>2)  Previous, when /usr/share/shorewall/xmodules had been copied to<br>    /etc/shorewall/modules, Shorewall was not looking in the correct<br>    directory for the "xt_..." modules. There are two parts to the fix:<br><br>    - The /usr/share/shorewall/xmodules file has been removed. The<br>      /usr/share/shorewall/modules file will now load all required<br>      modules regardless of which kernel version you are running.<br>    - The MODULESDIR option can now contain a colon-separated list of<br>      directories to search for modules with the default being:<br><br>      /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname -r)/kernel/net/netfilter<br><br>3)  Rules in /etc/shorewall/tos which specify zones defined<br>    using entries in /etc/shorewall/hosts applied to all traffic<br>    to/from the zone interfaces (the bridge port, ipset or IP<br>    address(es) in the zone definition were ignored).<br><br>4)  Previously, 'shorewall-lite dump' did not report traffic shaping<br>    information even if TC_ENABLED was set to Yes or Internal in the<br>    shorewall.conf file used to compile the exported firewall script.<br><br>    To correct this problem, the firewall script must be recompiled and<br>    re-exported.<br><br>5)  Previously, errors during the compile phase were not reflected in<br>    the exit status of /sbin/shorewall. Thanks to Tuomo Soini for<br>    finding and correcting this problem.<br><br>Other Shorewall changes in 3.2.4<br><br>1)  Previously, scripts compiled for export (-e option) depended on<br>    /usr/share/shorewall-lite/functions in order to run correctly. This<br>    made it possible for a compiled script to be incompatible with the<br>    version of Shorewall Lite installed on a firewall system.<br><br>    Beginning with Shorewall 3.2.4, this dependency is removed such<br>    that version incompatibility between Shorewall and Shorewall Lite<br>    should not be a concern going forward.<br><br>2)  Two new macros have been added, courtesy of Tuomo Soini<br><br>        macro.Finger<br>        macro.Telnets<br><br>3)  The output of "shorewall show macros" has been enhanced to show<br>    macros in each directory in the CONFIG_PATH.<br><br>Shorewall Lite problems corrected in 3.2.4<br><br>1)  Previous, when /usr/share/shorewall-lite/xmodules had been copied to<br>    /etc/shorewall-lite/modules, Shorewall was not looking in the correct<br>    directory for the "xt_..." modules. There are two parts to the fix:<br><br>    - The /usr/share/shorewall-lite/xmodules file has been removed. The<br>      /usr/share/shorewall-lite/modules file will now load all required<br>      modules regardless of which kernel version you are running.<br>    - The MODULESDIR option can now contain a colon-separated list of<br>      directories to search for modules with the default being:<br><br>      /lib/modules/$(uname<br>      -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname<br>      -r)/kernel/net/netfilter<br><br>     /usr/share/shorewall-lite/modules contains a *lot* of modules. If<br>     you use module autoloading (which non-embedded Linux distributions<br>     do), then you can improve your "shorewall [re]start" time by<br>     trimming all but the helper modules from the file. To do that,<br>     create the file /etc/shorewall-lite/modules with the following<br>     entries:<br><br>        loadmodule ip_conntrack_amanda<br>        loadmodule ip_conntrack_ftp<br>        loadmodule ip_conntrack_irc<br>        loadmodule ip_conntrack_netbios_ns<br>        loadmodule ip_conntrack_pptp<br>        loadmodule ip_conntrack_tftp<br>        loadmodule ip_nat_amanda<br>        loadmodule ip_nat_ftp<br>        loadmodule ip_nat_irc<br>        loadmodule ip_nat_pptp<br>        loadmodule ip_nat_snmp_basic<br>        loadmodule ip_nat_tftp<br><br>Other Shorewall Lite changes in 3.2.4<br><br>None.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-08-26 Shorewall 3.2.3<br>
</span><span style="font-weight: bold;"></span> 
<pre>Shorewall Problems Corrected in 3.2.3<br><br> 1)  A problem in 'install.sh' resulted in sandbox violations on<br>     Gentoo and, when Shorewall is installed using an RPM, the problem<br>     caused an incorrect copy of shorewall.conf to be installed in<br>     /usr/share/shorewall/configfiles/.<br><br> 2)  A typo in the functions file caused startup errors when the user's<br>     distribution did not support a true mktemp program (such as<br>     Bering Uclibc). Patch courtesy of C&Atilde;&copy;dric Schieli.<br><br> 3)  Several erroneous references to ip_addr_del() were made in<br>     /var/lib/shorewall/compiler and in the code that it generates.<br><br>     a) These should have been references to del_ip_addr()<br>     b) One of the calls also had an incorrect parameter list.<br><br> 4)  Previously, "shorewall check -e" would erroneously attempt to<br>     detect interfaces configured for traffic shaping.<br><br> 5)  SUBSYSLOCK functionality has been restored.<br><br> 6)  In prior versions, setting 'mss=' in /etc/shorewall/zones did not<br>     affect traffic to/from the firewall zone. That has been corrected.<br><br> 7)  When /sbin/shorewall was run under BusyBox ash, shell errors would<br>     occur if certain command options were given.<br><br> 8)  Previously, the 'optional' provider option did not detect the case<br>     where the interface was DOWN but still had a configured IP<br>     address. Shorewall was detecting such interfaces as UP and later<br>     'ip replace route' commands would fail.<br><br>     It should also be clarified that the 'optional' option is intended<br>     to detect cases where a provider interface is in a state that would<br>     cause 'shorewall [re]start' to fail; it is not intended to<br>     determine whether communication is possible using the interface.<br><br> 9)  Previously, the "shorewall add" command would fail with error<br>     messages indicating that the commands "chain_exists" and<br>     "verify_hosts_file" could not be found.<br><br> 10) Using earlier Shorewall versions, the following sequence of<br>     commands produced inconsistant results:<br><br>     a) shorewall [re] start<br>     b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses<br>     c) shorewall refresh<br>     d) shorewall save<br>     e) shorewall restore (or reboot and shorewall start -f during boot<br>        up)<br><br>     After that series of commands, the state of traffic shaping was as<br>     it was after step a) rather than as it was after step c). The fix<br>     involved re-implementing 'shorewall refresh' as a compile/execute<br>     procedure similar to [re]start. While the entire configuration is<br>     recompiled, only ecn, blacklisting, tcrules and traffic control<br>     will be updated in the running configuration.<br><br> 11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been<br>     incorrect with the result that the rules didn't work at all.<br><br> Other Shorewall changes in 3.2.3<br><br> 1)  A 'shorewall export' command has been added.<br><br>     shorewall export [ &lt;directory1&gt; ] [user@]&lt;system&gt;:[&lt;directory2&gt;]<br><br>     If &lt;directory1&gt; is omitted, then the current working directory is<br>     assumed.<br><br>     Causes the shorewall configuration in &lt;directory1&gt; to be compiled<br>     into a program called '&lt;directory1&gt;/firewall'. If compilation is<br>     successful, the '&lt;directory1&gt;/firewall' script is copied via scp<br>     to the specified &lt;system&gt;.<br><br>     Example:<br><br>         shorewall export admin@gateway:<br><br>     This command would compile the configuration in the current working<br>     directory then copy the 'firewall' (and 'firewall.conf') files to<br>     admin's home directory on system 'gateway'.<br><br> 2)  Normally, Shorewall tries to protect users from themselves by<br>     preventing PREROUTING and OUTPUT tcrules from being applied to<br>     packets that have been marked by the 'track' option in<br>     /etc/shorewall/providers.<br><br>     If you really know what you are doing and understand packet marking<br>     thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and<br>     Shorewall will not include these cautionary checks.<br><br> 3)  Previously, CLASSIFY tcrules were always processed out of the<br>     POSTROUTING chain. Beginning with this release, they are processed<br>     out of the POSTROUTING chain *except* when the SOURCE is<br>     $FW[:&lt;address&gt;] in which case the rule is processed out of the<br>     OUTPUT chain.<br><br>     See the Migration Considerations section for further information.<br><br> 4)  Previously, if you specified 'detectnets' on an interface with a<br>     default route, Shorewall would ignore the default route with a<br>     warning message. This could lead to systems that were inaccessible<br>     from the net, even from systems listed in the 'routestopped' file.<br><br>     Specifying 'detectnets' on an interface with a default route now<br>     generates a fatal error.<br><br>Shorewall Lite problems corrected in 3.2.3<br><br>1)  A typo in /usr/share/shorewall-lite/functions caused startup errors<br>    on distributions like Bering Uclibc that don't have a true mktemp<br>    utility.<br><br>Other Shorewall Lite changes in 3.2.3<br><br>None.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-08-10 Shorewall 3.2.2</span><br>
<span style="font-weight: bold;"></span> 
<pre>Problems corrected in 3.0.8<br><br>1)  If the 'upnp' interface option was specified on one or more<br>    interfaces but no forwardUPnP rule was included, the following<br>    diagnostic messages were issued:<br><br>        WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on<br>                eth0)<br>        ERROR: Fatal error in find_logactionchain<br><br>    Given that the fatal error message is obscure if the first WARNING<br>    isn't noticed, the ERROR message has been eliminated with the<br>    result that Shorewall now starts but won't handle UPnP properly.<br><br>2)  If BRIDGING=No in shorewall.conf, then an entry in<br>    /etc/shorewall/hosts such as the following would result in an<br>    obscure failure of an iptables command:<br><br>    loc   br0:eth0<br><br>    Shorewall now detects this case and issues a more helpful error<br>    message:<br><br>    ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0<br><br>3)  Users of the Multi-ISP feature may experience this error during startup:<br><br>    /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +<br>        $rulenum : syntax error: operand expected (error token is<br>        "$rulenum ")<br><br>4)  A more useful diagnostic is now given when a command fails during<br>    setup of traffic shaping.<br><br>5)  Shorewall now checks to see if devices in /etc/shorewall/tcdevices<br>    exist. If a device does not exist, a warning message is issued and<br>    that device's entries in /etc/shorewall/tcclasses are ignored. This<br>    applies to "shorewall start", "shorewall restart" and "shorewall<br>    refresh".<br><br>6)  It is now possible to exclude a single source MAC address using<br>    !&lt;MAC address&gt;. Previously, a startup error occurred.<br><br>7)  Shorewall would use the incorrect shell for compilation in the<br>    following case:<br><br>8)  Reporting of the "Mangle FORWARD Chain" capability was broken. While<br>    Shorewall correctly detected and used the capability, the output of<br>    "shorewall show capabilities" and "shorewall dump" showed the<br>    capability as "Not Available".<br><br>9)  Extension scripts for policy chains (chains with the word 'all' in<br>    their name) were not being run previously.<br><br>-Tom</pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-07-24 End of support for Shorewall
2.4<br>
</span><span style="font-weight: bold;"></span> 
<pre>Support for Shorewall 2.4 has ended. As always, we will try to help you<br>with your problems but I personally will not spend any time reading old<br>code trying to solve your problem and I will not provide patches for any<br>bugs found in versions earlier than 3.0.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-07-21 Shorewall 3.2.1<br>
</span><span style="font-weight: bold;"></span> 
<pre>Problems Corrected in Shorewall 3.2.1:<br><br>1)  The output formatting of the 'hits' command under BusyBox 1.2.0 has<br>    been corrected.<br><br>2)  Shorewall no longer requires extended MARK support to use the 'track'<br>    provider option when HIGH_ROUTE_MARKS=No.<br><br>3)  The output of the 'hits' command was previously scrambled if<br>    /etc/services contained spaces as column delimiters rather than<br>    tabs.<br><br>4)  The /usr/share/shorewall/xmodules file was previously just a copy<br>    of /usr/share/shorewall/modules.<br><br>5)  The version number in the comments at the top of shorewall.conf has<br>    been corrected.<br><br>6)  The script generated when the -e option is given to the 'compile'<br>    command is  setting CONFIG_PATH to the value given in the remote<br>    firewall's shorewall.conf processed at compile time. This is<br>    generally incorrect and results in the inability to load any kernel<br>    modules on the firewall during 'shorewall-lite [re]start'.<br><br>Problems Corrected in Shorewall Lite 3.2.1:<br><br>1)  The output formatting of the 'hits' command under BusyBox 1.2.0 has<br>    been corrected.<br><br>2)  The output of the 'hits' command was previously scrambled if<br>    /etc/services contained spaces as column delimiters rather than<br>    tabs.<br><br>3)  The /usr/share/shorewall-lite/xmodules file was previously just a<br>    copy of /usr/share/shorewall-lite/modules.<br><br>4)  The version number in the comments at the top of shorewall.conf has<br>    been corrected.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-07-19 Shorewall bridge/firewall support
change upcoming<br>
</span><span style="font-weight: bold;"></span> 
<pre><tt>I regret to announce that Shorewall bridge/firewall support in its</tt><br><tt>current form (BRIDGING=Yes in shorewall.conf) is going away. I will</tt><br><tt>retain the code in Shorewall for the foreseeable future but users</tt><br><tt>migrating to new kernels coming out next year will find that their</tt><br><tt>current bridge configurations no longer work. Shorewall bridge/firewall</tt><br><tt>users upgrading to more immediate new kernel releases (possibly as early</tt><br><tt>as 2.6.18) will find Netfilter warning messages appearing in their</tt><br><tt>kernel log when Shorewall [re]starts.</tt><br><br><tt>The reason that this support is going away is that the underlying</tt><br><tt>Netfilter feature that BRIDGING=Yes depends on (physdev match) is being</tt><br><tt>reduced in scope to the point that it will no longer be possible to use</tt><br><tt>that feature for Shorewall zone definition. There is a significant list</tt><br><tt>of pending Netfilter bug reports than cannot be resolved so long as</tt><br><tt>'physdev match' works the way that it does today.</tt><br><br><tt>While 'physdev match' was a great idea in terms of the function that it</tt><br><tt>provides, it appears impossible to implement that function without</tt><br><tt>breaking other parts of the greater Linux IP stack; in short, 'physdev</tt><br><tt>match' in its current form should never have been released in the first</tt><br><tt>place.</tt><br><br><tt>So -- what can current Shorewall bridge/firewall users do? </tt><br><tt>-----------------------------------------------------------------------</tt><br><tt>a) Configure Shorewall as if you have a simple bridge</tt><br><tt>(<a href="http://www.shorewall.net/SimpleBridge.html">http://www.shorewall.net/SimpleBridge.html</a>) and use ebtables to filter</tt><br><tt>traffic in and out of the individual bridge ports.</tt><br><br><tt>b) Configure Shorewall so that you specifically enumerate the IP</tt><br><tt>addresses of the hosts connected to all but one of the bridge ports.</tt><br><br><tt>Example where br0 connects to 192.168.1.0/24:</tt><br><br><tt>/etc/shorewall/shorewall.conf</tt><br><br><tt>BRIDGING=&lt;doesn't matter&gt;</tt><br><br><tt>/etc/shorewall/zones</tt><br><br><tt>z1 ipv4</tt><br><tt>z2 ipv4</tt><br><br><tt>/etc/shorewall/interfaces</tt><br><br><tt>- br0 detect&nbsp;routeback</tt><br><br><tt>/etc/shorewall/hosts:</tt><br><br><tt>z1 br0:192.168.1.1-192.168.1.15,192.168.1.18,...</tt><br><tt>z2&nbsp;br0:192.168.1.0/24</tt><br><br><tt>In other words, explicitly specify the hosts in the first zone listed</tt><br><tt>in /etc/shorewall/zones (z1 in the above example) then simply specify</tt><br><tt>the entire network for the second zone. If the second zone contains your</tt><br><tt>default gateway, then you would enter 0.0.0.0/0 rather than</tt><br><tt>192.168.1.0/24.</tt><br><br><tt>I will expand these instructions into an article on the web site just as</tt><br><tt>soon as I find the time.</tt><br><br><tt>c) If you have ipset support, you can take the same approach as in b)</tt><br><tt>above but define 'z1' using one or more ipsets rather than with an</tt><br><tt>explicit lists of network/host IP addresses. That will generally result</tt><br><tt>in a smaller ruleset.</tt><br><tt>-----------------------------------------------------------------------</tt><br><tt>I realize that the options available to you are more cumbersome to</tt><br><tt>configure and maintain than what you have today but at the moment, I see</tt><br><tt>no alternatives. I will however continue to ponder the problem, and if I</tt><br><tt>come up with something better I will let you know.</tt><br><br><tt>-Tom</tt></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-07-11 Shorewall 3.2.0<br>
</span><span style="font-weight: bold;"></span> 
<pre>New Features:<br><br>1)  Shorewall has always been very noisy (lots of messages). No longer.<br><br>    You set the default level of verbosity using the VERBOSITY option in<br>    shorewall.conf. If you don't set it (as would be the case if you use your<br>    old shorewall.conf file) then VERBOSITY defaults to a value of 2 which<br>    results in behavior compatible with previous Shorewall versions.<br>    A value of 1 suppresses some of the output (like the old -q option did)<br>    while a value of 0 makes Shorewall almost silent. A value of -1<br>    suppresses all output except warning and error messages.<br><br>    The value specified in the 3.2 shorewall.conf is 1. So you can make<br>    Shorewall as verbose as previously using a single -v and you can make it<br>    almost silent by using a single -q.<br><br>    If VERBOSITY is set at 2, you can still make a command nearly<br>    silent by using two "q"s (e.g., shorewall -qq restart).<br><br>    In summary, each "q" subtracts one from VERBOSITY while each "v" adds one<br>    to VERBOSITY.<br><br>    The "shorewall show log", "shorewall logwatch" and "shorewall dump"<br>    commands require VERBOSITY to be greater than or equal to 3 to<br>    display MAC addresses.This is consistent with the previous<br>    implementation which required a single -v to enable MAC display but<br>    means that if you set VERBOSITY=0 in shorewall.conf, then you will<br>    need to include -vvv in commands that display log records in order<br>    to have MACs displayed.<br><br>    To make the display of MAC addresses less cumbersome, a '-m' option has<br>    been added to the "show" and logwatch commands:<br><br>        shorewall show -m log<br>        shorewall logwatch -m<br><br>2)  A new 'shorewall compile' command has been added.<br><br>     shorewall compile [ -e ] [ &lt;config directory&gt; ] &lt;script file&gt;<br><br>    where:<br><br>        -e                    Allows the generated script to run<br>                              on a system with Shorewall Lite installed.<br>                              Generates an error if the configuration uses<br>                              an option that would prevent the generated<br>                              script from running on a system other than<br>                              where the 'compile' command is running (see<br>                              additional consideration a) below).<br><br>        &lt;config directory&gt;    Is an optional directory to be searched for<br>                              configuration files prior to those listed<br>                              in CONFIG_DIR in<br>                              /etc/shorewall/shorewall.conf.<br><br>        &lt;script file&gt;         Is the name of the output file.<br><br>    The 'compile' command processes the configuration and generates a<br>    script file which may then be executed to configure the firewall.<br><br>    The generated script supports the following commands:<br><br>        start -   starts the firewall<br>        stop  -   stops the firewall<br>        clear -   clears the firewall (removes all iptables rules)<br>        restart - restarts the firewall<br>        status  - displays the firewall status<br>        version - displays the version of shorewall used to create the<br>                  script<br><br>    The generated script contains error checking and will terminate if an<br>    important command fails. Before terminating:<br><br>    a) The script will check for the existence of the restore script<br>       specified by the RESTOREFILE variable in shorewall.conf. If that<br>       restore script exists, it is executed.<br><br>    b) If the restore script doesn't exist but Shorewall appears to be<br>       installed on the system, the equivalent of an<br>       "/sbin/shorewall stop" command is executed.<br><br>    Some additional considerations:<br><br>    a) When you run 'compile' on one system and then run the generated script<br>       on another system under Shorewall Lite, there are certain limitations.<br><br>       1) A compatible version of Shorewall Lite must be running on the remote<br>          system. Going forward, the goal is that any minor version of<br>          the current major version will be compatible. So if the<br>          program is compiled using Shorewall 3.2.x, any 3.2.y version<br>          or 3.p.q version (where p &gt; 2) of Shorewall Lite will be compatible.<br>       2) The 'detectnets' interface option is not allowed.<br>       3) DYNAMIC_ZONES=Yes is not allowed.<br>       4) You must supply the file /etc/shorewall/capabilities to provide<br>          the compiler with knowledge of the capabilities of the system<br>          where the script is to be run. See below.<br>       5) If your /etc/shorewall/params file contains code other than simple<br>          assignment statements with contant values, then you should move<br>          that code to /etc/shorewall/init. That way, the code will be<br>          executed on the target system when the compiled script is run and<br>          not on the local system at compile time.<br><br>    b) If you run the "shorewall compile" or "shorewall check" commands under<br>       a user other than 'root', then you must supply<br>       /etc/shorewall/capabilities.<br><br>    c) To aid in building /etc/shorewall/capabilities, a 'shorecap' program<br>       is provided in the Shorewall Lite package and is installed in<br>       /usr/share/shorewall-lite/shorecap when you install Shorewall Lite.<br><br>       For instructions about running shorecap, see the comments at the<br>       top of the program file (it's a simple shell script).<br><br>    The "shorewall start" and "shorewall restart" commands have been<br>    rewritten to use compilation. They both compile a temporary program<br>    then run it. This results in a slightly longer elapsed time than the<br>    similar commands required under earlier versions of Shorewall but new<br>    connections are blocked for a much smaller percentage of that time.<br><br>    If an error is found during the compilation phase, /sbin/shorewall<br>    terminates and the Shorewall state is unchanged.<br><br>    Under Shorewall 3.1.5, "shorewall restart" takes roughly 16.5 seconds<br>    on my firewall:<br><br>        real    0m16.599s<br>        user    0m6.292s<br>        sys     0m9.885s<br><br>    Of the elapsed 16.5 seconds, new connections are disabled less than<br>    3.5 seconds. Here are some numbers for comparison:<br><br>    A) shorewall restart (Shorewall 3.0.4)<br><br>        real &nbsp; &nbsp;0m17.540s<br>        user &nbsp; &nbsp;0m5.956s<br>        sys &nbsp; &nbsp; 0m10.737s<br><br>    B) ./foo restart # foo created using "shorewall compile"<br><br>        real    0m3.297s<br>        user    0m1.444s<br>        sys     0m1.728s<br><br>    C) shorewall restore (Shorewall 3.0.4) # Restores from file generated by<br>                                           # "shorewall save"<br><br>        real &nbsp; &nbsp;0m1.164s<br>        user &nbsp; &nbsp;0m0.556s<br>        sys &nbsp; &nbsp; 0m0.608s<br><br>    D) shorewall restore (shorewall 3.1.5)<br><br>        real    0m1.637s<br>        user    0m0.728s<br>        sys     0m0.584s<br><br>    The time difference between B and C reflects the difference between<br>    "iptables-restore" and multiple executions of "iptables". The time<br>    difference between C and D results from the fact that the "restore"<br>    command in Shorewall 3.1 runs the compiled program in a way that<br>    turns all iptables commands into no-ops then invokes<br>    iptables-restore. The system is a 1.4Ghz Celeron with 512MB RAM.<br><br>    As a final part of this change, the "check" command now compiles the<br>    current configuration and writes the compiled output to /dev/null. So<br>    "check" performs all of the same validation that compile does. Note that<br>    there is still no guarantee that the generated script won't encounter<br>    run-time errors.<br><br>2)  The /etc/shorewall/maclist file has a new column layout. The first column<br>    is now DISPOSITION. This column determines what to do with matching<br>    packets and can have the value ACCEPT or DROP (if MACLIST_TABLE=filter, it<br>    can also contain REJECT). This change is upward compatible so your existing<br>    maclist file can still be used.<br><br>    ACCEPT, DROP and REJECT may be optionally followed by a log level to<br>    cause the packet to be logged.<br><br>4)  In macro files, you can now use the reserved words SOURCE and DEST<br>    in the columns of the same names. When Shorewall expands the<br>    macro, it will substitute the SOURCE from the macro invocation for<br>    SOURCE and the DEST from the invocation for DEST. This allows you<br>    to write macros that act in both directions (from source to destination<br>    and from destination to source).<br><br>    Example:<br><br>        macro.FOO:<br><br>            PARAM      SOURCE        DEST      udp     500<br>            PARAM      DEST          SOURCE    udp     500<br><br>        /etc/shorewall/rules:<br><br>            FOO/ACCEPT    fw         net<br><br>        Resulting rules:<br><br>            ACCEPT        fw         net        udp     500<br>            ACCEPT        net        fw         udp     500<br><br>    This new feature has been used to implement the SMBBI macro.<br>    SMBBI is the same as the SMB macro with the exception that<br>    it passes SMB traffic in both directions whereas SMB only<br>    passes that traffic in one direction.<br><br>5)  In the /etc/shorewall/rules file and in actions, you may now specify<br>    'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also<br>    requires that the SYN flag is set and the RST, FIN and ACK flags be<br>    off ("--syn" is added to the iptables rule).<br><br>    As part of this change, Shorewall no longer adds the "--syn" option<br>    to TCP rules that specify QUEUE as their target.<br><br>6)  /sbin/shorewall now supports a "-t" option that causes all progress<br>    messages to be timestamped.<br><br>    Example (VERBOSITY=0 in shorewall.conf):<br><br>    gateway:/etc/shorewall # shorewall -t restart<br>    07:08:51 Compiling...<br>    07:09:05 Shorewall configuration compiled to /var/lib/shorewall/.restart<br>    07:09:05 Restarting Shorewall....<br>    07:09:08 done.<br>    gateway:/etc/shorewall #<br><br>7)  A 'refreshed' extension script has been added -- it is executed after<br>    "shorewall refresh" has finished.<br><br>8)  Two new dynamic blacklisting commands have been added:<br><br>        logdrop -- like 'drop' but causes the dropped packets to be logged.<br><br>        logreject -- like 'reject' but causes the rejected packets to be<br>                     logged.<br><br>    Packets are logged at the BLACKLIST_LOGLEVEL if one was specified at the<br>    last "shorewall [re]start"; otherwise, they are logged at the 'info'<br>    log level.<br><br>9)  A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When<br>    this option is set to "Yes", it causes subzones to be treated differently<br>    with respect to policies.<br><br>    Subzones are defined by following their name with ":" and a list of parent<br>    zones (in /etc/shorewall/zones). Normally, you want to have a set of<br>    special rules for the subzone and if a connection doesn't match any of<br>    those subzone-specific rules then you want the parent zone rules and<br>    policies to be applied. With IMPLICIT_CONTINUE=Yes, that happens<br>    automatically.<br><br>    If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then<br>    subzones are not subject to this special treatment.<br><br>    With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden<br>    by including an explicit policy (one that does not specify "all" in either<br>    the SOURCE or the DEST columns).<br><br>    Example:<br><br>    /etc/shorewall/zones:<br><br>        prnt       ipv4<br>        chld:prnt  ipv4<br><br>    Traffic to/from the 'chld' zone will first pass through the applicable<br>    'chld' rules and if none of those rules match then it will be passed through<br>    the appropriate 'prnt' rules. If the connection request does not match<br>    any of the 'prnt' rules then the relevant 'prnt' policy is applied.<br><br>    If you want the fw-&gt;chld policy to be ACCEPT, simply add this entry to<br>    /etc/shorewall/policy:<br><br>        $FW      chld        ACCEPT<br><br>    Traffic from all other zones to 'chld' will be subject to the implicit<br>    CONTINUE policy.<br><br>10) Shorewall now includes support for explicit routing rules when the<br>    /etc/shorewall/providers file is used. A new file,<br>    /etc/shorewall/route_rules can be used to add routing rules based on<br>    packet source and/or destination.<br><br>    The file has the following columns:<br><br>                SOURCE(optonal) An ip address (network or host) that<br>                                matches the source IP address in a packet.<br>                                May also be specified as an interface<br>                                name optionally followed by ":" and an<br>                                address. If the define 'lo' is specified,<br>                                the packet must originate from the firewall<br>                                itself.<br><br>                DEST(optional)  An ip address (network or host) that<br>                                matches the destination IP address in a packet.<br><br>                                If you choose to omit either SOURCE or DEST,<br>                                place "-" in the column. Note that you<br>                                may not omit both SOURCE and DEST.<br><br>                PROVIDER        The provider to route the traffic through.<br>                                May be expressed either as the provider name<br>                                or the provider number. You may also specify<br>                                the 'main' routing table here, either by<br>                                name or by number (254).<br><br>                PRIORITY<br>                                The rule's priority which determines the order<br>                                in which the rules are processed.<br><br>                                1000-1999   Before Shorewall-generated<br>                                            'MARK' rules<br><br>                                11000- 11999 After 'MARK' rules but before<br>                                            Shorewall-generated rules for<br>                                            provider interfaces.<br><br>                                26000-26999 After provider interface rules but<br>                                            before 'default' rule.<br><br>                                Rules with equal priority are applied in<br>                                the order in which they appear in the file.<br><br>    Example 1: You want all traffic coming in on eth1 to be routed to the ISP1<br>             provider:<br><br>            #PROVIDER   PRIORITY        SOURCE                  DEST<br>            ISP1        1000            eth1<br><br>    Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple<br>               providers. In this case you have to set up a rule to ensure that<br>               the OpenVPN traffic is routed back through the tunX interface(s)<br>               rather than through any of the providers. 10.8.0.0/24 is the<br>               subnet choosen in your OpenVPN configuration (server 10.8.0.0<br>               255.255.255.0)<br><br>        #SOURCE                 DEST            PROVIDER        PRIORITY<br>        -                       10.8.0.0/24     main            1000<br><br>11) Prior to now, it has not been possible to use connection marking in<br>    /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the<br>    'track' option.<br><br>    Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in<br>    shorewall.conf to effectively divide the packet mark and connection mark<br>    into two 8-byte mark fields.<br><br>    When you do this:<br><br>        a) The MARK field in the providers file must have a value that is<br>           less than 65536 and that is a multiple of 256 (using hex<br>           representation, the values are 0x0100-0xFF00 with the low-order<br>           8 bits being zero).<br><br>        b) You may only set those mark values in the PREROUTING chain.<br><br>        c) Marks used for traffic shaping must still be in the range of 1-255<br>           and may still not be set in the PREROUTING chain.<br><br>        d) When you SAVE or RESTORE in tcrules, only the TC mark value is<br>           saved or restored. Shorewall handles saving and restoring the<br>           routing (provider) marks.<br><br>12) A TOS column has been added to /etc/shorewall/tcrules. This allows marking<br>    based on the contents of the TOS field in the packet header.<br><br>13) Beginning with this release, the way in which packet marking in the<br>    PREROUTING chain interracts with the 'track' option in /etc/shorewall/providers<br>    has changed in two ways:<br><br>    a)  Packets *arriving* on a tracked interface are now passed to the PREROUTING<br>        marking chain so that they may be marked with a mark other than the<br>        'track' mark (the connection still retains the 'track' mark).<br><br>    b)  When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets<br>        in the PREROUTING chain (i.e., you can specify a mark value of zero).<br><br>14) Shorewall will now attempt to detect the MTU of devices listed in<br>    /etc/shorewall/tcdevices and will use the detected MTU in setting<br>    up traffic shaping.<br><br>15) In /etc/shorewall/rules, the values "all-" and "all+-" may now be<br>    used for zone names. "all-" means "All zones except the firewall";<br>    "all+-" means "All zones except the firewall" and intra-zone<br>    traffic is included.<br><br>16) Kernel version 2.6.16 introduces 'xtables', a new common packet<br>    filtering and connection tracking facility that supports both IPv4<br>    and IPv6. Because a different set of kernel modules must be loaded<br>    for xtables, Shorewall now includes two 'modules' files:<br><br>    a) /usr/share/shorewall/modules -- the former<br>    /etc/shorewall/modules<br><br>    b) /usr/share/shorewall/xmodules -- a new file that support<br>    xtables.<br><br>    If you wish to use the new file, then simply execute this command:<br><br>    cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules<br><br>17) Shorewall now checks to see if devices in /etc/shorewall/tcdevices<br>    exist. If a device does not exist, a warning message is issued and<br>    that device's entries in /etc/shorewall/tcclasses are ignored. This<br>    applies to "shorewall start", "shorewall restart" and "shorewall<br>    refresh".<br><br>18) "load" and "reload" commands have been added. These commands allow<br>    a non-root user with ssh access to a remote system running<br>    Shorewall Lite to compile a firewall script on the local system and<br>    to install that script on the remote system.<br><br>    Syntax is:<br><br>           shorewall [re]load [ &lt;directory&gt; ] &lt;system&gt;<br><br>    If &lt;directory&gt; is omitted, the current working directory is<br>    assumed.<br><br>    The command is equivalent to:<br><br>    /sbin/shorewall compile -e &lt;directory&gt; firewall &amp;&amp;\<br>    scp firewall root@&lt;system&gt;:/var/lib/shorewall-lite/ &amp;&amp;\<br>    ssh root@&lt;system&gt; '/sbin/shorewall-lite [re]start' # Note 1<br><br>    In other words, the configuration in the specified (or defaulted)<br>    directory is compiled to a file called firewall in that<br>    directory. If compilation succeeds, then 'firewall' is copied to the<br>    (usually remote) &lt;system&gt; using scp. If the copy succeeds,<br>    Shorewall Lite on &lt;system&gt; is started or restarted via ssh (<br>    load causes Shorewall Lite to be started and 'reload' causes<br>    Shorewall Lite to be re-started)<br><br>    Note 1: In Shorewall Lite 3.2.0 RC4, the 'firewall' script has moved<br>    from /usr/share/shorewall-lite/ to /var/lib/shorewall-lite in<br>    packages from shorewall.net. The package maintainers for the<br>    various distributions are free to choose the directory where the<br>    script will be stored under their distribution by altering the<br>    value of LITEDIR in /usr/share/shorewall/configpath. You can run the<br>    "shorewall show config" command to see how your distribution<br>    defines LITEDIR.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-06-21 Shorewall 3.0.8<br>
</span><span style="font-weight: bold;"></span> 
<pre>Problems corrected in 3.0.8<br><br>1)  If the 'upnp' interface option was specified on one or more<br>    interfaces but no forwardUPnP rule was included, the following<br>    diagnostic messages were issued:<br><br>        WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on<br>                eth0)<br>        ERROR: Fatal error in find_logactionchain<br><br>    Given that the fatal error message is obscure if the first WARNING<br>    isn't noticed, the ERROR message has been eliminated with the<br>    result that Shorewall now starts but won't handle UPnP properly.<br><br>2)  If BRIDGING=No in shorewall.conf, then an entry in<br>    /etc/shorewall/hosts such as the following would result in an<br>    obscure failure of an iptables command:<br><br>    loc   br0:eth0<br><br>    Shorewall now detects this case and issues a more helpful error<br>    message:<br><br>    ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0<br><br>3)  Users of the Multi-ISP feature may experience this error during startup:<br><br>    /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +<br>        $rulenum : syntax error: operand expected (error token is<br>        "$rulenum ")<br><br>4)  A more useful diagnostic is now given when a command fails during<br>    setup of traffic shaping.<br><br>5)  Shorewall now checks to see if devices in /etc/shorewall/tcdevices<br>    exist. If a device does not exist, a warning message is issued and<br>    that device's entries in /etc/shorewall/tcclasses are ignored. This<br>    applies to "shorewall start", "shorewall restart" and "shorewall<br>    refresh".<br><br>6)  It is now possible to exclude a single source MAC address using<br>    !&lt;MAC address&gt;. Previously, a startup error occurred.<br><br>7)  Shorewall would use the incorrect shell for compilation in the<br>    following case:<br><br>8)  Reporting of the "Mangle FORWARD Chain" capability was broken. While<br>    Shorewall correctly detected and used the capability, the output of<br>    "shorewall show capabilities" and "shorewall dump" showed the<br>    capability as "Not Available".<br><br>9)  Extension scripts for policy chains (chains with the word 'all' in<br>    their name) were not being run previously.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-05-27 Shorewall 2.4.9<br>
</span><span style="font-weight: bold;"></span> 
<pre>Problems corrected in 2.4.9<br><br>1)  Updated the bogons file to reflect recent IANA allocations.<br><br>2)  If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq and<br>    if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall start" will<br>    fail with the error 'Error: an inet prefix is expected rather than "SAME".'.<br><br>3)  It is now possible to exclude a single source MAC address using<br>    !&lt;MAC address&gt;. Previously, a startup error occurred.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-05-06 Shorewall 3.0.7<br>
</span> 
<pre>Problems corrected in 3.0.7<br><br>1)  Previously, if your kernel did not supply the mangle table FORWARD chain<br>    then "shorewall [re]start" would fail. Now, if your mangle table does<br>    not supply this chain Shorewall will avoid using either that chain or<br>    the mangle table POSTROUTING chain. This change is strictly to stop Shorewall<br>    from blowing up during [re]start on very old kernels (such as 2.4.17<br>    running on a PS2); if your kernel does not support these chains and you<br>    try to mark packets in either of them using entries in<br>    /etc/shorewall/tcrules, [re]start will fail.<br><br>2)  Previously, if there were more than 10 IP addresses on a multi-ISP interface,<br>    some of the routing rules generated by Shorewall were placed after the<br>    default rule which resulted in them not being recognized.<br><br>3)  When install.sh is used to install on a Debian or Ubuntu system, the<br>    SUBSYSLOCK option in shorewall.conf was not being cleared.<br>    It will now be cleared, provided that Perl is installed on the system.<br><br>4)  When exclusion lists appeared in the /etc/shorewall/tcrules file, the<br>    resulting 'exclusion chains' (whose names begin with 'excl_') were not<br>    deleted as part of 'shorewall [re]start'. This meant that 'refresh'<br>    would fail, either the first or second time that it was done since<br>    the last 'shorewall [re]start'.<br><br>Other changes in 3.0.7<br><br>None.<br></pre>
<!-- Shorewall Release 3.0.5 ENDS-->
<!-- Shorewall moving to Subversion -->
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-03-28 Shorewall moved to Subversion <br>
</span> 
<pre> Effectively today, Shorewall source code repository was migrated to Subversion SCM.<br><br>Please read <a href="https://sourceforge.net/svn/?group_id=22587">https://sourceforge.net/svn/?group_id=22587 </a>
and <a href="http://www.shorewall.net/download.htm#SVN"> http://www.shorewall.net/download.htm#SVN </a>
for more information.</pre>
<!-- Moving to Subversion ENDS -->
<!-- Shorewall Release 3.0.5 -->
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-03-28 Shorewall 3.0.6<br>
</span> 
<pre>Problems corrected in 3.0.6<br><br>1)  A typo in the output of "help drop" has been corrected.<br><br>2)  Previously, 'shorewall start' would fail in the presence of a network<br>    interface named 'inet'.<br><br>3)  A shell syntax error was reported when duplicate policies appeared in<br>    /etc/shorewall/policy.<br><br>4)  The iptable_nat and iptable_mangle modules were previously omitted<br>    from /etc/shorewall/modules.<br><br>5)  If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq <br>    and if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall <br>    start" will fail with the error 'Error: an inet prefix is expected rather <br>    than "SAME".'.<br><br>6)  Previously, the 'routeback' option was ignored in an entry in the<br>    /etc/shorewall/hosts file that referred to a (set of) bridge port(s).<br><br>    Example:<br><br>            dmz        xenbr0:vif+           routeback<br><br>Other changes in 3.0.6<br><br>1)  A 'refreshed' extension script has been added -- it is executed after<br>    "shorewall refresh" has finished.<br></pre>
<!-- Shorewall Release 3.0.5 ENDS-->
<!-- Shorewall Release 3.0.5 -->
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-02-10 Shorewall 3.0.5<br>
</span> 
<pre>Problems corrected in Shorewall 3.0.5<br><br>1)  Previously, if /etc/shorewall/ipsets existed, it was run when Shorewall starts<br>    but not when Shorewall was restored.<br><br>2)  When using the NETKEY IPSEC implementation in kernel 2.6 but without the<br>    policy match patch and the Netfilter/IPSEC patches, previously an<br>    entry in /etc/shorewall/tunnels was not sufficient in cases where:<br><br>    a) gw&lt;-&gt;gw traffic was encrypted<br>    b) The gw&lt;-&gt;gw policy through the tunnel was not ACCEPT<br><br>    Thanks to Tuomo Soini, this has been corrected. By simply including the<br>    remote VPN zone in the GATEWAY ZONE column for the tunnel's entry, no<br>    additional rules are required.<br><br>3)  Extra blank output lines are no longer produced by install.sh (patch<br>    courtesy of Tuomo Soini).<br><br>4)  TCP packets sent to QUEUE by rules in the ESTABLISHED section of the<br>    rules file previously didn't work (they had the "--syn" parameter<br>    added to them which resulted in a rule that no traffic would match).<br><br>    WARNING: If you use the QUEUE target from an action, Shorewall will<br>    still insert --syn if the protocol is tcp. So you don't want to<br>    invoke such an action from the ESTABLISHED section of the rules<br>    file.<br><br>5)  The description of the SOURCE column in /etc/shorewall/rules has been<br>    improved (patch courtesy of Ed Suominen).<br><br>6)  The 'allow', 'drop' and 'reject' commands no longer produce iptables<br>    errors when executed while Shorewall is not started.<br><br>7)  The spelling of "maximize-throughput" has been corrected in the code<br>    that implements tcclasses parsing. Patch courtesy of Paul Traina.<br><br>8)  Shorewall now generates the correct match for devices in<br>    /etc/shorewall/tcdevices that are actually bridge ports.<br><br>New Features in Shorewall 3.0.5<br><br>1)  The facilities available for dealing with the TOS field in<br>    /etc/shorewall/tcclasses has been expended. The OPTIONS field is now may<br>    contain a comma-separates list of the following:<br><br>        tos=0x&lt;value&gt;[/0x&lt;mask&gt;]        (mask defaults to 0xff)<br>                                        - this lets you define a classifier<br>                                        for the given &lt;value&gt;/&lt;mask&gt; combination<br>                                        of the IP packet's TOS/Precedence/DiffSrv<br>                                        octet (aka the TOS byte).  Please note,<br>                                        classifiers override all mark settings,<br>                                        so if you define a classifer for a class,<br>                                        all traffic having that mark will go in it<br>                                        regardless of any mark set on the packet<br>                                        by a firewall/mangle filter.<br><br>                                        NOTE: multiple tos= statements may be<br>                                        applied per class and per interface, but<br>                                        a given value/mask pair is valid for only<br>                                        ONE class per interface.<br><br>        tos-&lt;tosname&gt;                        - aliases for the following TOS octet<br>                                        value and mask encodings.  TOS encodings<br>                                        of the "TOS byte" have been deprecated in<br>                                        favor of diffserve classes, but programs<br>                                        like ssh, rlogin, and ftp still use them.<br><br>                                           tos-minimize-delay          0x10/0x10<br>                                        tos-maximize-throughput         0x08/0x08<br>                                        tos-maximize-reliability 0x04/0x04<br>                                        tos-minimize-cost         0x02/0x02<br>                                        tos-normal-service         0x00/0x1e<br><br>        tcp-ack                         -    defined causes an tc filter to<br>                                        be created that puts all tcp ack<br>                                        packets on that interface that have<br>                                        an size of &lt;=64 Bytes to go in this<br>                                        class. This is useful for speeding up<br>                                        downloads. Please note that the size<br>                                        of the ack packets is limited to 64<br>                                        bytes as some applications (p2p for<br>                                        example) use to make every packet an<br>                                        ack packet which would cause them<br>                                        all into here. We want only packets<br>                                        WITHOUT payload to match, so the size<br>                                        limit.<br><br>                                        NOTE: This option is only valid for<br>                                        ONE class per interface.<br><br>    Note that the semantics of 'tos-&lt;tosname&gt;' have changed slightly. Previously,<br>    these were tested using a mask of 0xff (example: tos-minimize-delay was<br>    equivalent to 0x10/0xff). Now each bit is tested individually.<br><br>    This enhancement is courtesy of Paul Traina.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2006-01-05 Shorewall 3.0.4<br>
</span> 
<pre>Problems Corrected in 3.0.4<br><br>1) &nbsp;The shorewall.conf file is once again "console friendly". Patch is<br>&nbsp; &nbsp; courtesy of Tuomo Soini.<br><br>2) &nbsp;A potential security hole has been closed. Previously, Shorewall ACCEPTed<br>&nbsp; &nbsp; all traffic from a bridge port that was sent back out on the same port. If<br>&nbsp; &nbsp; the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,<br>&nbsp; &nbsp; xenbr0:vif+), this could lead to traffic being passed in variance with the<br>&nbsp; &nbsp; supplied policies and rules.<br><br>3) &nbsp;Previously, an intra-zone policy of NONE would cause a startup error. That<br>&nbsp; &nbsp; problem has been corrected.<br><br>4) &nbsp;When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not<br>&nbsp; &nbsp; add the retained aliases. This means that the following sequence of<br>&nbsp; &nbsp; events resulted in missing aliases:<br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall start<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall restart<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall save<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; reboot<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; shorewall -f start (which is the default during boot up)<br><br>5) &nbsp;When a 2.x standard action is invoked with a log level (example<br>&nbsp; &nbsp; "AllowPing:info"), logging does not occur.<br><br>New Features in 3.0.4<br><br>1) &nbsp;By popular demand, the 'Limit' action described at<br>&nbsp; &nbsp; http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard<br>&nbsp; &nbsp; action. Limit requires 'recent match' support in your kernel and iptables.<br><br>2) &nbsp;DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This<br>&nbsp; &nbsp; change is reported to improve Java startup time on some distributions.<br><br>3) &nbsp;Shorewall now contains support for wildcard ports. In<br>&nbsp; &nbsp; /etc/shorewall/hosts, you may specify the port name with trailing "+" then <br>&nbsp; &nbsp; use specific port names in rules.<br><br>&nbsp; &nbsp; Example:<br><br>&nbsp; &nbsp; /etc/shorewall/hosts<br><br>&nbsp; &nbsp; &nbsp; &nbsp; vpn &nbsp; &nbsp; &nbsp;br0:tap+<br><br>&nbsp; &nbsp; /etc/shorewall/rules<br><br>&nbsp; &nbsp; &nbsp; &nbsp; DROP &nbsp; &nbsp; &nbsp;vpn:tap0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vpn:tap1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;udp &nbsp; &nbsp;9999<br><br>4) &nbsp;For the benefit of those who run Shorewall on distributions that don't <br>&nbsp; &nbsp; autoload kernel modules, /etc/shorewall/modules now contains load commands <br>&nbsp; &nbsp; for a wide range of Netfilter modules.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2005-12-13 Shorewall 3.0.3<br>
</span> 
<pre>Problems Corrected in 3.0.3<br><br>1) The comments in the /etc/shorewall/shorewall.conf and<br>   /etc/shorewall/hosts files have been changed to clarify when<br>   BRIDGING=Yes is required when dealing with bridges.<br><br>2) Thanks to Tuomo Soini, formatting of the comments in the tcdevices<br>   and tcclasses files has been cleaned up.<br><br>3) Specifying 'trace' on the 'safe-start' and 'safe-restart' command no<br>   longer fails.<br><br>4) The output of "shorewall help restore" has been corrected. It previously<br>   printed incorrect syntax for that command.<br><br>5) The README.txt file in the tarball was stale and contained incorrect<br>   information. It has been corrected.<br><br>6) The shorewall.conf default setting of CLEAR_TC was previously "No". Given<br>   that the default setting of TC_ENABLED is "Internal", the setting of<br>   CLEAR_TC has been changed to the more appropriate value of "Yes".<br><br>7) Specifying an interface name in the SOURCE column of /etc/shorewall/tcrules<br>   resulted in a startup error.<br><br>8) When the 'install.sh' script is used on Debian, it now creates<br>   /var/log/shorewall-init.log. And if perl is installed on the system then<br>   STARTUP_ENABLED=Yes is specified in shorewall.conf (the user must still<br>   set startup=1 in /etc/default/shorewall).<br><br>New Features in 3.0.3 <br>

1) A "shorewall show macros" command has been added. This command displays
   a list of the standard macros along with a brief description of each.

2) The '-q' option is now supported with 'safe-start' and 'safe-restart'.

3) The value "-" is now allowed in the ADDRESS/SUBNET column of
   /etc/shorewall/blacklist. That value is equivalent to specifying
   0.0.0.0/0 in that column.

4) The output of "shorewall show tc" and "shorewall show classifiers" is
   now included in the output from "shorewall dump". This will aid us in
   analyzing traffic shaping problems.

5) You can now specify 'none' in the COPY column of /etc/shorewall/providers
   to signal that you want Shorewall to only copy routes through the interface
   listed in the INTERFACE column.

   Note: This works on older versions of Shorewall as well. It is
         now documented.

6) An 'ipdecimal' command has been added to /sbin/shorewall. This command
   converts between dot-quad and decimal.

   Example:

    gateway:/etc/openvpn# shorewall ipdecimal 192.168.1.4
        3232235780
    gateway:/etc/openvpn# shorewall ipdecimal 3232235780
        192.168.1.4
    gateway:/etc/openvpn#

7) /etc/init.d/shorewall now supports a 'reload' command which is
   synonymous with the 'restart' command.</pre>
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2005-12-12 Shorewall 2.4.7</span><br>
<br>
Problems Corrected in 2.4.7<br>
<br>
1)&nbsp;&nbsp;When MACLIST_TABLE=mangle and an interface is enabled for DHCP
(the<br>
&nbsp;&nbsp;&nbsp; 'dhcp' option is specified in /etc/shorewall/interfaces)
then broadcasts<br>
&nbsp;&nbsp;&nbsp; on UDP port 67 to address 255.255.255.255 from address
0.0.0.0 were being<br>
&nbsp;&nbsp;&nbsp; dropped and logged. While this did not prevent the client
from acquiring<br>
&nbsp;&nbsp;&nbsp; an IP address, it could result in lots of log messages.<br>
<br>
2)&nbsp;&nbsp;Entries for openvpn tunnels (including openvpnclient and<br>
&nbsp;&nbsp;&nbsp; openvpnserver) that specify a port but no protocol cause
startup<br>
&nbsp;&nbsp;&nbsp; errors as follows:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;iptables
v1.3.3: unknown protocol `1194' specified<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Try
`iptables -h' or 'iptables --help' for more information.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ERROR:
Command "/usr/sbin/iptables -A net2fw -p 1194 -s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0.0.0.0/0
--sport 1194 -j ACCEPT" Failed<br>
<br>
&nbsp;&nbsp;&nbsp; The problem may be worked around by specifying the
protocol as well<br>
&nbsp;&nbsp;&nbsp; (e.g., "openvpn:udp:3455).<br>
<br>
3)&nbsp;&nbsp;If the previous firewall configuration included a policy other
than<br>
&nbsp;&nbsp;&nbsp; ACCEPT in the nat, mangle or raw tables then Shorewall
would not set<br>
&nbsp;&nbsp;&nbsp; the policy to ACCEPT. This could result in a ruleset that
rejected or<br>
&nbsp;&nbsp;&nbsp; dropped all traffic.<br>
<br>
4)&nbsp;&nbsp;Specifying an interface name in the SOURCE column <br>
&nbsp;&nbsp;&nbsp; of /etc/shorewall/tcrules resulted in a startup error.<br>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;"></span><span
style="font-weight: bold;">2005-12-01 End of Support for Shorewall versions
2.0 and 2.2<br>
<br>
</span>Effective today, versions 2.0 and 2.2 are no longer supported. This
means that if you find a bug in one of these releases, we won't fix it and if
you ask for help with one of these releases, we will not spend much time
trying to solve your issue.<br>

<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2005-11-25 Shorewall 3.0.2<br>
</span> 
<pre>Problems Corrected in 3.0.2<br><br>1) A couple of typos in the one-interface sample configuration have<br>   been corrected.<br><br>2) The 3.0.1 version of Shorewall was incompatible with old versions of<br>   the Linux kernel (2.4.7 for example). The new code ignores errors<br>   produced when Shorewall 3.x is run on these ancient kernels.<br><br>3) Arch Linux installation routines has been improved.<br><br>New Features in 3.0.2<br><br>1) A new Webmin macro has been added. This macro assumes that Webmin is<br>   running on its default port (10000).<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">2005-11-18 Shorewall 3.0.1</span><br>

<pre>Problems Corrected in 3.0.1 <br>

1) If the previous firewall configuration included a policy other than
   ACCEPT in the nat, mangle or raw tables then Shorewall would not set
   the policy to ACCEPT. This could result in a ruleset that rejected or
   dropped all traffic.

2) The Makefile was broken such that 'make' didn't always work correctly.

3) If the SOURCE or DEST column in a macro body was non-empty and a dash
   ("-") appeared in the corresponding column of an invocation of that
   macro, then an invalid rule was generated.

4) The comments in the /etc/shorewall/blacklist file have been updated to
   clarify that the PORTS column refers to destination port number/service
   names.

5) When CLAMPMSS is set to a value other than "No" and FASTACCEPT=Yes, the
   order of the rules generated was incorrect causing RELATED TCP connections
   to not have CLAMPMSS applied.

New Features in 3.0.1

1)  To make the macro facility more flexible, Shorewall now examines the
    contents of the SOURCE and DEST columns in both the macro body and in
    the invocation and tries to create the intended rule. If the value in
    the invocation appears to be an address (IP or MAC) or the name of an
    ipset, then it is placed after the value in the macro body. Otherwise,
    it is placed before the value in the macro body.

    Example 1:

    /etc/shorewall/macro.foo:

    PARAM        -            192.168.1.5      tcp    http

    /etc/shorewallrules:

    foo/ACCEPT   net          loc

    Effective rule:

    ACCEPT       net          loc:192.168.1.5   tcp   http

    Example 2:

    /etc/shorewall/macro.bar:

    PARAM        net           loc              tcp    http

    /etc/shorewall/rules:

    bar/ACCEPT   -             192.168.1.5

    Effective rule:

    ACCEPT       net           loc:192.168.1.5  tcp    http</pre>

<p></p>
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">11/11/2005 Shorewall 3.0.0</span><br>

<pre>New Features in Shorewall 3.0.0<br><br>1) Error and warning messages are made easier to spot by using<br>   capitalization (e.g., ERROR: and WARNING:).<br><br>2) A new option 'critical' has been added to<br>   /etc/shorewall/routestopped. This option can be used to enable<br>   communication with a host or set of hosts during the entire<br>   "shorewall [re]start/stop" process. Listing a host with this option<br>   differs from listing it without the option in several ways:<br><br>   a) The option only affect traffic between the listed host(s) and the<br>   firewall itself.<br><br>   b) If there are any entries with 'critical', the firewall<br>   will be completely opened briefly during start, restart and stop but<br>   there will be no chance of any packets to/from the listed host(s)<br>   being dropped or rejected.<br><br>   Possible uses for this option are:<br><br>   a) Root file system is NFS mounted. You will want to list the NFS server<br>   in the 'critical' option.<br><br>   b) You are running Shorewall in a Crossbeam environment<br>   (www.crossbeam.com). You will want to list the Crossbeam interface<br>   in this option<br><br>3) A new 'macro' feature has been added.<br><br>   Macros are very similar to actions and can be used in similar<br>   ways. The differences between actions and macros are as follows:<br><br>   a) An action creates a separate chain with the same name as the<br>      action (when logging is specified on the invocation of an action,<br>      a chain beginning with "%" followed by the name of the action and<br>      possibly followed by a number is created). When a macro is<br>      invoked, it is expanded in-line and no new chain is created.<br><br>   b) An action may be specified as the default action for a policy;<br>      macros cannot be specified this way.<br><br>   c) Actions must be listed in either /usr/share/shorewall/actions.std<br>      or in /etc/shorewall/actions. Macros are defined simply by<br>      placing their definition file in the CONFIG_PATH.<br><br>   d) Actions are defined in a file with a name beginning with<br>      "action." and followed by the name of the action. Macro files are<br>      defined in a file with a name beginning with "macro.".<br><br>   e) Actions may invoke other actions. Macros may not directly invoke<br>      other macros although they may invoke other macros indirectly<br>      through an action.<br><br>   f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They<br>      are allowed in a macro with the restriction that the a macro<br>      containing one of these rules may not be invoked from an action.<br><br>   g) The values specified in the various columns when you invoke a<br>      macro are substituted in the corresponding column in each rule in<br>      the macro. The first three columns get special treatment:<br><br>      ACTION         If you code PARAM as the action in a macro then<br>                 when you invoke the macro, you can include the<br>                 name of the macro followed by a slash ("/") and<br>                 an ACTION (either built-in or user-defined. All<br>                 instances of PARAM in the body of the macro will be<br>                 replaced with the ACTION.<br><br>                 Any logging applied when the macro is invoked is<br>                 applied following the same rules as for actions.<br><br>      SOURCE and<br>      DEST         If the rule in the macro file specifies a value and<br>                 the invocation of the rule also specifies a value then<br>                 the value in the invocation is appended to the value<br>                 in the rule using ":" as a separator.<br><br>                 Example:<br><br>                 /etc/shorewall/macro.SMTP<br><br>                 PARAM                -        loc        tcp        25<br><br>                 /etc/shorewall/rules:<br><br>                 SMTP/DNAT:info                net        192.168.1.5<br><br>                 Would be equivalent to the following in the rules file:<br><br>                 DNAT:info           net        loc:192.168.1.5        tcp        25<br><br>      Rest         Any value in the invocation replaces the value in the<br>                 rule in the macro.<br><br>    One additional restriction applies to the mixing of macros and<br>    actions. Macros that are invoked from actions cannot themselves<br>    invoke other actions.<br><br>4)  If you have 'make' installed on your firewall, then when you use<br>    the '-f' option to 'shorewall start' (as happens when you reboot),<br>    if your /etc/shorewall/ directory contains files that were modified<br>    after Shorewall was last restarted then Shorewall is started using<br>    the config files rather than using the saved configuration.<br><br>5)  The 'arp_ignore' option has been added to /etc/shorewall/interfaces<br>    entries. This option sets<br>    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_ignore. By default, the<br>    option sets the value to 1. You can also write arp_ignore=&lt;value&gt;<br>    where value is one of the following:<br><br>        1 - reply only if the target IP address is local address<br>        configured on the incoming interface<br><br>        2 - reply only if the target IP address        is local address<br>        configured on the incoming interface and both with the sender's<br>        IP address are part from same subnet on this interface<br><br>        3 - do not reply for local addresses configured with scope<br>        host, only resolutions for global and link addresses are<br>        replied<br><br>        4-7 - reserved<br><br>         8 - do not reply for all local addresses<br><br>    WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN<br>    PROXY ARP.<br><br>6)  In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works<br>    like "all" but also includes intrazone traffic. So the rule:<br><br>         ACCEPT     loc                 all+         tcp           22<br><br>    would allow SSH traffic from loc-&gt;loc whereas<br><br>         ACCEPT     loc                 all         tcp           22<br><br>    does not.<br><br>7)  A new FASTACCEPT option has been added to shorewall.conf.<br><br>    Normally, Shorewall defers accepting ESTABLISHED/RELATED packets<br>    until these packets reach the chain in which the original connection<br>    was accepted. So for packets going from the 'loc' zone to the 'net'<br>    zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'<br>    chain.<br><br>    If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are<br>    accepted early in the INPUT, FORWARD and OUTPUT chains. If you set<br>    FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or<br>    RELATED sections of /etc/shorewall/rules.<br><br>8)  Shorewall now generates an error if the 'norfc1918' option is<br>    specified for an interface with an RFC 1918 address.<br><br>9)  You may now specify "!" followed by a list of addresses in the<br>    SOURCE and DEST columns of entries in /etc/shorewall/rules,<br>    /etc/shorewall/tcrules and in action files and Shorewall will<br>    generate the rule that you expect.<br><br>    Example 1 (/etc/shorewall/rules):<br><br>    #ACTION    SOURCE                                DEST        PROTO     DEST PORT(S)<br>    ACCEPT     loc:!192.168.1.0/24,10.0.0.0/8        net        tcp          80<br><br>    That rule would allow loc-&gt;net HTTP access except for the local<br>    networks 192.168.1.0/24 and 10.0.0.0/8.<br><br>    Example 2 (/etc/shorewall/rules):<br><br>    #ACTION    SOURCE                                DEST        PROTO     DEST PORT(S)<br>    ACCEPT     loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \<br>                                                net        tcp          80<br><br>    That rule would allow loc-&gt;net HTTP access from the local<br>    network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.<br><br>10) Tunnel types "openvpnserver" and "openvpnclient" have been added<br>    to reflect the introduction of client and server OpenVPN<br>    configurations in OpenVPN 2.0.<br><br>11) The COMMAND variable is now set to 'restore' in restore<br>    scripts. The value of this variable is sometimes of interest to<br>    programmers providing custom /etc/shorewall/tcstart scripts.<br><br>12) Previously, if you defined any intra-zone rule(s) then any traffic<br>    not matching the rule(s) was subject to normal policies (which<br>    usually turned out to involve the all-&gt;all REJECT policy). Now, the<br>    intra-zone ACCEPT policy will still be in effect in the presence of<br>    intra-zone rules. That policy can still be overridden by an<br>    explicit policy in your /etc/shorewall/policy file.<br><br>    Example:<br><br>    /etc/shorewall/rules:<br><br>    DNAT        loc:!192.168.1.4  loc:192.168.1.4:3128        tcp        80<br><br>    Any other loc-&gt;loc traffic will still be accepted. If you want to<br>    also log that other loc-&gt;loc traffic at the info log level then<br>    insert this into /etc/shorewall/policy:<br><br>    #SOURCE        DEST        POLICY        LOG LEVEL<br>    loc                loc        ACCEPT        info<br><br>13) Prior to Shorewall 2.5.3, the rules file only controlled packets in<br>    the Netfilter states NEW and INVALID. Beginning with this release,<br>    the rules file can also deal with packets in the ESTABLISHED and<br>    RELATED states.<br><br>    The /etc/shorewall/rules file may now be divided into<br>    "sections". Each section is introduced by a line that begins with<br>    the keyword SECTION followed by the section name. Sections<br>    are as listed below and must appear in the order shown.<br><br>    ESTABLISHED<br><br>        Rules in this section apply to packets in the ESTABLISHED<br>        state.<br><br>    RELATED<br><br>        Rules in this section apply to packets in the RELATED state.<br><br>    NEW<br><br>        Rules in this section apply to packets in the NEW and INVALID<br>        states.<br><br>    Rules in the ESTABLISHED and RELATED sections are limited to the<br>    following ACTIONs:<br><br>        ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.<br><br>    Macros may be used in these sections provided that they expand to<br>    only these ACTIONs.<br><br>    At the end of the ESTABLISHED and RELATED sections, there is an<br>    implicit "ALLOW   all          all all" rule.<br><br>    RESTRICTION: If you specify FASTACCEPT=Yes in<br>    /etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED<br>    sections must be empty.<br><br>14) The value 'ipp2p' is once again allowed in the PROTO column of<br>    the rules file. It is recommended that rules specifying 'ipp2p'<br>    only be included in the ESTABLISHED section of the file.<br><br><br>15) Shorewall actions lack a generalized way to pass parameters to an<br>    extension script associated with an action. To work around this<br>    lack, some users have used the log tag as a parameter. This works<br>    but requires that a log level other than 'none' be specified when<br>    the action is invoked. Beginning with this release, you can invoke<br>    an action with 'none'.<br><br>    Example:<br><br>        #ACTION                                SOURCE          DEST<br>        A:none:these,are,parameters     $FW                net<br><br>    When /etc/shorewall/A is invoked, the LEVEL variable will be empty<br>    but the TAG variable will contain "these,are,parameters" which<br>    can be easily parsed to isolate "these", "are" and "parameters":<br><br>        ifs=$IFS<br>        IFS=,<br>        set -- $TAG<br>        IFS=$ifs<span style="font-weight: bold;">2</span><br><br>    Now, $1 = these, $2 = are and $3 = parameters<br><br>16) The "shorewall check" command now checks the /etc/shorewall/masq,<br>    /etc/shorewall/blacklist, /etc/shorewall/proxyarp,<br>    /etc/shorewall/nat and /etc/shorewall/providers files.<br><br>17) Arne Bernin's "tc4shorewall" package has been integrated into<br>    Shorewall.<br><br>    See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.<br><br>    Thanks, Arne!<br><br>18) When /usr/share/shorewall/functions is loaded it now sets<br><span style="font-weight: bold;">2</span><br>         SHOREWALL_LIBRARY=Loaded<br><br>    Application code such as /etc/shorewall/tcstart may test that<br>    variable to determine if the library has been loaded into the<br>    current shell process.<br><br>19) The install.sh script now does a much cleaner job of backing up the<br>    current installation. It copies the directories /etc/shorewall,<br>    /usr/share/shorewall and /var/lib/shorewall to a directory of the<br>    same name with "-$VERSION.bkout" appended. The init script and<br>    /sbin/shorewall are backed up to the /usr/share/shorewall and<br>    /var/lib/shorewall directories respectively. This makes it very<br>    simple to remove the backups:<br><br>           rm -rf /etc/shorewall-*.bkout<br>           rm -rf /usr/share/shorewall-*.bkout<br>           rm -rf /var/lib/shorewall-*.bkout<br><br>20) A new '-n' option has been added to the "start", "restart",<br>    "restore",  "stop" and "try" commands. This option instructs<br>    Shorewall to not alter the routing in any way.<br><br>    This option is useful when you have a multi-ISP environment because<br>    it prevents the route cache from being flushed which preserves the<br>    mapping of end-point address pairs to routes.<br><br>21) The output of "shorewall dump" now includes a capabilities report<br>    such as the one produced by "shorewall show capabilities".<br><br>22) The "plain" zone type has been replaced by "ipv4". The types<br>    "IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",<br>    "ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".<br><br>23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been<br>    removed as have the 'newnotsyn' options in /etc/shorewall/interfaces<br>    and /etc/shorewall/hosts. See the Migration Considerations for<br>    instructions if you wish to block "new-not-syn" TCP packets.<br><br>24) The "shorewall show zones" command now displays the zone type. You<br>    must have restarted Shorewall using this release before this feature<br>    will work correctly.<br><br>25) The multi-ISP code now requires that that you set MARK_IN_FORWARD_CHAIN=Yes<br>    in shorewall.conf. This is done to ensure that "shorewall refresh" will<br>    work correctly.<br><br>26) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"<br>    keyword in the PROTOCOL column of the relevant files, the following<br>    values may be specified:<br><br>        ipp2p:tcp           Equivalent to ipp2p and matches TCP traffic<br>                            only.<br>        ipp2p:udp           Matches UDP traffic.<br>        ipp2p:all           Matches both UDP and TCP traffic. You may<br>                            not specify a SOURCE PORT with this PROTOCOL.<br><br>27) Normally MAC verification triggered by the 'maclist' interface and host<br>    options is done out of the INPUT and FORWARD chains of the filter table.<br>    Users have reported that under some circumstances, MAC verification is<br>    failing for forwarded packets when the packets are being forwarded out<br>    of a bridge.<br><br>    To work around this problem, a MACLIST_TABLE option has been added to<br>    shorewall.conf. The default value is MACLIST_TABLE=filter which results<br>    in the current behavior. If MACLIST_TABLE=mangle then filtering will<br>    take place out of the PREROUTING chain of the mangle table. Because<br>    the REJECT target may not be used in the PREROUTING chain, the settings<br>    MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.<br><br>28) The sample configurations are now packaged with the product. They are<br>    in the Samples directory on the tarball and are in the RPM they are<br>    in the Samples sub-directory of the Shorewall documentation<br>    directory.<br></pre>
<span style="font-weight: bold;"></span> 
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">10/31/2005 Shorewall 2.4.6<br>
<br>
</span>Problems Corrected in 2.4.6<br>

<ol>
  <li>"shorewall refresh" would fail if there were entries in
    /etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.</li>
  <li>An unprintable character in a comment caused /sbin/shorewall to fail
    when used with a light-weight shell like 'dash'.</li>
  <li>When using some flavors of 'ash', certain /sbin/shorewall commands
    produced 'ipset: not found' messages.</li>
  <li>Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0 but the
    implementation was incomplete. It has now been completed and is
    documented in the /etc/shorewall/tunnels file.</li>
  <li>The test that Shorewall uses to detect the availability of the owner
    match capability has been changed to avoid the generation of ipt_owner
    messages under kernel 2.6.14.</li>
</ol>
New Features in 2.4.6<br>

<ol>
  <li>Normally MAC verification triggered by the 'maclist' interface and host
    options is done out of the INPUT and FORWARD chains of the filter table.
    Users have reported that under some circulstances, MAC verification is
    failing for forwarded packets when the packets are being forwarded out of
    a bridge.<br>
    <br>
    To work around this problem, a MACLIST_TABLE option has been added to
    shorewall.conf. The default value is MACLIST_TABLE=filter which results
    in the current behavior. If MACLIST_TABLE=mangle then filtering will take
    place out of the PREROUTING chain of the mangle table. Because the REJECT
    target may not be used in the PREROUTING chain, the settings
    MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.</li>
  <li>A "dump" command has been added to /sbin/shorewall for compatibility
    with Shorewall 3.0. In 2.4.6, the "dump" command provides the same output
    as the "status".<br>
  </li>
</ol>
<hr style="width: 100%; height: 2px;">
Shorewall 2.4.5<br>
<br>
Problems Corrected in 2.4.5<br>

<ol>
  <li>In previous versions, when the command is 'start', 'restart' or 'stop'
    then OUTPUT traffic to hosts listed in /etc/shorewall/routestopped is not
    enabled if ADMINISABSENTMINDED=Yes. That traffic is now enabled
    independent of the setting of ADMINISABSENTMINDED.</li>
  <li>Although it was documented that icmp types could be used in the tcrules
    file, the code did not support it. Thanks to Jorge Molina, that problem
    is now corrected.</li>
  <li>In a multi-ISP configuration, fwmark routing rules now have a higher
    priority than source IP rules. This allows entries in tcrules to be more
    effective in controlling routing.</li>
  <li>Previously, not all of the mangle chains were flushed during "shorewall
    restart".</li>
</ol>
<span style="font-weight: bold;">09/12/2005 Shorewall 2.4.4<br>
</span><br>
Problems Corrected<br>

<ol>
  <li>An incorrect comment in the /etc/shorewall/proxyarp file has been
    removed.</li>
  <li>The message generated when a duplicate policy has been entered is now
    more informative. Previously, only the POLICY column contents appeared in
    the message. Now the SOURCE, DEST and POLICY column contents are
  shown.</li>
  <li>Shorewall now clears the Netfilter "raw" table during "shorewall
    [re]start", "shorewall stop" and "shorewall clear" processing.</li>
</ol>
New Features<br>

<ol>
  <li>Tunnel types "openvpnserver" and "openvpnclient" have been added to
    reflect the introduction of client and server OpenVPN configurations in
    OpenVPN 2.0.</li>
  <li>The COMMAND variable is now set to 'restore' in restore scripts. The
    value of this variable is sometimes of interest to programmers providing
    custom /etc/shorewall/tcstart scripts.<br>
  </li>
</ol>
<span style="font-weight: bold;">08/16/2005 Shorewall 2.4.3<br>
</span><br>
Problems Corrected:<br>

<ol>
  <li>Shorewall is no longer dependent on the 'which' utility.</li>
  <li>The 'shorewall add' command failed if there existed a zone in the
    configuration that specified the 'ipsec' option in
  /etc/shorewall/hosts.</li>
  <li>Shorewall is no longer dependent on /bin/echo.</li>
  <li>A CLASSIFY rule&nbsp; with $FW in the SOURCE column (tcrules) no longer
    results in a "shorewall start" error.</li>
  <li>You may now use port lists in the DEST PORT and SOURCE PORT columns of
    the /etc/shorewall/accounting file.</li>
  <li>The "shorewall show capabilities" command now accurately reports the
    availability of "Packet type match" independent of the setting of PKTTYPE
    in shorewall.conf.</li>
  <li>Thanks to Tuomo Soini, all of the files have been siginificantly
    cleaned up in terms of formatting and extra white-space.<br>
  </li>
</ol>
New Features:<br>

<ol>
  <li>New Allow.Submission and Allow.NTPbrd actions have been added. Users of
    the Allow.NTP action that use NTP broadcasting should switch to use of
    Allow.NTPbrd instead.</li>
  <li>The kernel version string is now included in the output of "shorewall
    status".<br>
  </li>
</ol>
<span style="font-weight: bold;">07/30/2005 Shorewall 2.2.6<br>
<br>
</span>Problems Corrected:<br>

<ol>
  <li><a href="#20050717">MACLIST_TTL Vulnerability</a> fix.</li>
  <li>TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of iptables.</li>
  <li>The bogons file has been updated to reflect recent IANA
  allocations.</li>
</ol>
<span style="font-weight: bold;">07/21/2005 Shorewall 2.4.2<br>
<br>
</span>Problems Corrected:<br>

<ol>
  <li>The /etc/shorewall/hosts file now includes information about defining a
    zone using one or more ipsets.</li>
  <li>A <a href="#20050717">vulnerability involving MACLIST_TTL &gt; 0 or
    MACLIST_DISPOSITION=ACCEPT</a> has been corrected.</li>
  <li>It is now possible to specify !&lt;address&gt; in the SUBNET column of
    /etc/shorewall/masq. Previously, it was necessary to write
    0.0.0.0/0!&lt;address&gt;.</li>
  <li>When &lt;network1&gt;!&lt;network2&gt; was specified in the SUBNET
    column of /etc/shorewall/masq, IPSEC policies were not correctly applied
    to the resulting rules. This usually resulted in IPSEC not working
    through the interface specified in the INTERFACES column.<br>
  </li>
</ol>
New Features:<br>

<ol>
  <li>A 'loose' provider option has been added. If you wish to be able to use
    marking to specify the gateway used by connections originating on the
    firewall itself, the specify 'loose' for each provider. It has bee
    reported that 'loose' may break the effect of 'track' so beware if you
    need 'track' functionality (you shouldn't be originating many connections
    from your firewall to the net anyway).<br>
    <br>
    To use 'loose', you also need to add two entries in
    /etc/shorewall/masq:<br>

    <pre><span style="font-family: monospace;">#INTERFACE           SUBNET          ADDRESS<br>
   $IF_ISP1             $IP_ISP2        $IP_ISP1<br>
   $IF_ISP2             $IP_ISP1        $IP_ISP2</span>
 </pre>
    where:<br>

    <pre>        $IF_ISP1        is the interface to ISP 1.<br>
        $IF_ISP2        is the interface to ISP 2.<br>
        $IP_ISP1        is the IP address of $IF_ISP1<br>
        $IP_ISP2        is the IP address of $IF_ISP2
 </pre>
  </li>
  <li>/sbin/shorewall now issues a warning each time that it finds that
    startup is disabled.</li>
  <li>A new COPY column has been added to the /etc/shorewall/providers file.
    Normally, when a table name/number is given in the DUPLICATE column, the
    entire table (less default routes) is copied. The COPY column allows you
    to limit the routes copied to those that go through an interface listed
    in COPY. For example, if you enter eth0 in INTERFACE, "eth1,eth2" in COPY
    and 'main' in DUPLICATE then the new table created will contain those
    routes through the interfaces eth0, eth1 and eth2.<br>
  </li>
</ol>
<hr style="width: 100%; height: 2px;">

<h2><a name="20050717"></a><font color="#ff0000">07/17/2005 Security
vulnerability in MACLIST processing</font></h2>

<h3>Description</h3>

<p>A security vulnerability has been discovered which affects all supported
stable versions of Shorewall.&nbsp; This vulnerability enables a client
accepted by MAC address filtering to bypass any other rule.&nbsp; If
MACLIST_TTL is set to a value greater than 0 or MACLIST_DISPOSITION is set to
"ACCEPT" in /etc/shorewall/shorewall.conf (default is MACLIST_TTL=0 and
MACLIST_DISPOSITION=REJECT), and a client is positively identified through
its MAC address, it bypasses all other policies/rules in place, thus gaining
access to all open services on the firewall.</p>

<h3>Fix</h3>

<h4>Workaround</h4>

<p>For Shorewall 2.2.x or 2.4.x, set MACLIST_TTL=0 or
MACLIST_DISPOSITION=REJECT in /etc/shorewall/shorewall.conf.&nbsp; For
Shorewall 2.0.x, set MACLIST_DISPOSITION=REJECT in
/etc/shorewall/shorewall.conf.&nbsp; MACLIST filtering is of limited value on
Internet-connected hosts, and the Shorewall team recommends this approach to
be used if possible.</p>

<h4>Upgrade</h4>

<p>For Shorewall 2.4.x, a fixed version of the 'firewall' script is available
at: <a
href="http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
and its mirrors, <a
href="http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
and <a
href="http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>.</p>

<p>For Shorewall 2.2.x, a fixed version of the 'firewall' script is available
at: <a
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
and its mirrors, <a
href="http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
and <a
href="http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>.</p>

<p>For Shorewall 2.0.x, a fixed version of the 'firewall' script is available
at: <a
href="http://shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
and its mirrors, <a
href="http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
and <a
href="http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>.</p>

<p>Users of any version before 2.0.17 are urged to upgrade to a supported
version of Shorewall (preferably 2.4.1) before using the fixed files.&nbsp;
Only the most recent version of the 2.0.x and 2.2.x streams will be supported
by the development team, and the 1.x branches are no longer maintained at
all.&nbsp; Future releases of Shorewall will include this fix.</p>

<p>This information was based on <a
href="http://seclists.org/lists/fulldisclosure/2005/Jul/0409.html">Patrick
Blitz's post to the Full Disclosure mailing list</a>.&nbsp; Thanks to
Supernaut (supernaut at ns dot sympatico dot ca) for reporting this bug.<br>
</p>

<p><span style="font-weight: bold;">Version Upgrade<br>
</span></p>

<p>The vulnerability is corrected in Shorewall 2.4.2 and in Shorewall
2.2.6.<br>
</p>
<hr style="width: 100%; height: 2px;">
<span style="font-weight: bold;">07/13/2005 Shorewall 2.4.1<br>
</span><br>
Problems Corrected:<br>

<ol>
  <li>Shell variables may now be used in the zones file.</li>
  <li>The /usr/share/shorewall/bogons file has been updated to reflect recent
    IANA allocations.</li>
  <li>Shorewall now detects an error where multiple providers specify the
    'track' option on the same interface.</li>
  <li>The remnants of the GATEWAY column in /etc/shorewall/interfaces have
    been removed. This column appeared briefly in one of the Beta versions
    and was immediately removed but some vestiges remained.</li>
  <li>Shorewall now correctly restores a load-balancing default route during
    processing of the 'shorewall restore' and 'shorewall -f start' commands.
    The latter command is normally executed by the Shorewall init script
    during reboot.</li>
  <li>A log level of "None!" is now allowed on builtin actions such as ACCEPT
    and DROP.</li>
  <li>Previously, LIMIT:BURST parameters in /etc/shorewall/policy were not
    correctly applied when the policy was QUEUE.</li>
  <li>The 'chkconfig' command on FC4 and Mandriva previously created symbolic
    links with incorrect names ("S-1shorewall"). The init script has been
    changed to prevent this incorrect behavior.</li>
  <li>DHCP traffic forwarded through a bridge could, under some
    configurations, be filtered by the 'maclist' option even though the
    'dhcp' option was specified. This has been corrected.<br>
  </li>
</ol>
<span style="font-weight: bold;">06/05/2005 Shorewall 2.4.0<br>
<br>
Note:</span> Because of the short time that has elapsed since the release of
Shorewall 2.2.0, Shorewall 2.0 will be supported until 1 December 2005 or
until the release of Shorewall 2.6.0, whichever occurs first.<br>
<br>
New Features:<br>

<ol>
  <li>Shorewall 2.4.0 includes support for multiple internet interfaces to
    different ISPs.<br>
    <br>
    The file /etc/shorewall/providers may be used to define the different
    providers. It can actually be used to define alternate routing tables so
    uses like transparent proxy can use the file as well.<br>
    <br>
    Columns are:<br>
    <br>
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    The provider name.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    NUMBER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The provider
    number -- a number between 1 and 15</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    MARK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A
    FWMARK value used in your /etc/shorewall/tcrules file to direct packets
    for this provider.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    DUPLICATE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The name of an existing
    table to duplicate. May</span> <span style="font-family: monospace;">be
    'main' or the name of a previous provider.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The name of the network
    interface to the</span> <span style="font-family: monospace;">provider.
    Must be listed in</span><span
    style="font-family: monospace;">/etc/shorewall/interfaces.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    GATEWAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The IP address of
    the provider's gateway router.</span> <span
    style="font-family: monospace;">If you enter "detect" here then
    Shorewall<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    will</span> <span style="font-family: monospace;">attempt to determine
    the gateway IP address</span> <span
    style="font-family: monospace;">automatically.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    OPTIONS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A comma-separated
    list selected from the</span> <span
    style="font-family: monospace;">following:</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    track&nbsp;&nbsp; If specified, connections FROM this interface
    are</span> <span style="font-family: monospace;">to be tracked so that
    responses may be<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    routed</span> <span style="font-family: monospace;">back out this same
    interface.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    You want specify 'track' if internet hosts will be</span> <span
    style="font-family: monospace;">connecting to local servers through<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    this</span> <span style="font-family: monospace;">provider.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Because of limitations in the 'ip' utility and</span> <span
    style="font-family: monospace;">policy routing, you may not use the SAVE
    or</span><span style="font-family: monospace;"><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    RESTORE tcrules options or use connection</span><span
    style="font-family: monospace;">marking on any traffic to or from
    this</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    interface. For traffic control purposes, you</span> <span
    style="font-family: monospace;">must mark packets in the FORWARD chain
    (or</span><span style="font-family: monospace;"><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    better yet, use the CLASSIFY target).</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    balance The providers that have 'balance' specified will</span> <span
    style="font-family: monospace;">get outbound traffic load-balanced
    among<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    them. By</span> <span style="font-family: monospace;">default, all
    interfaces with 'balance' specified</span> <span
    style="font-family: monospace;">will have the same weight (1).<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    You can change the</span><span style="font-family: monospace;">weight of
    the route out of the interface by</span> <span
    style="font-family: monospace;">specifiying balance=&lt;weight&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    where &lt;weight&gt; is</span><span style="font-family: monospace;">the
    desired route weight.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example:&nbsp; You run squid in your
    DMZ on IP address 192.168.2.99. Your DMZ interface is eth2<br>
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    #NAME&nbsp;&nbsp; NUMBER&nbsp; MARK DUPLICATE&nbsp; INTERFACE
    GATEWAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Squid&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    1&nbsp;&nbsp;&nbsp;
    -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.99&nbsp; -</span><br>
    <br>
    Use of this feature requires that your kernel and iptabls support
    CONNMARK target and conntrack match support. It does NOT require the
    ROUTE target extension.<br>
    <br>
    WARNING: 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" may fail. You must patch
    your iptables using the patch at <a
    href="http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff">http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff</a>.<br>
    <br>
  </li>
  <li>Shorewall 2.3.0 supports the 'cmd-owner' option of the owner match
    facility in Netfilter. Like all owner match options, 'cmd-owner' may only
    be applied to traffic that originates on the firewall.<br>
    <br>
    The syntax of the USER/GROUP column in the following files has been
    extended:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/accounting<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/rules<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/tcrules<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    /usr/share/shorewall/action.template<br>
    <br>
    To specify a command, prefix the command name with "+".<br>
    <br>
    &nbsp;&nbsp; Examples:<br>
    <br>
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    +mozilla-bin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    #The program is named "mozilla-bin"</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    joe+mozilla-bin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #The
    program is named "mozilla-bin" and</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    #is being run by user "joe"</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    joe:users+mozilla-bin&nbsp;&nbsp; #The program is named "mozilla-bin"
    and</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    #is being run by user "joe" with</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    #effective group "users".</span><br style="font-family: monospace;">
    <br>
    &nbsp;&nbsp; Note that this is not a particularly robust feature and I
    would never advertise it as a "Personal Firewall" equivalent. Using
    symbolic links, it's easy to alias command names to be anything you
    want.<br>
    <br>
  </li>
  <li>Support has been added for ipsets (see <a
    href="http://people.netfilter.org/kadlec/ipset/">http://people.netfilter.org/kadlec/ipset/</a>).<br>
    <br>
    In most places where a host or network address may be used, you may also
    use the name of an ipset prefaced by "+".<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example: "+Mirrors"<br>
    <br>
    The name of the set may be optionally followed by:<br>
    <br>
    a) a number from 1 to 6 enclosed in square brackets ([]) -- this number
    indicates the maximum number of ipset binding levels that are to be
    matched. Depending on the context where the ipset name is used, either
    all "src" or all "dst" matches will be used.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example: "+Mirrors[4]"<br>
    <br>
    b) a series of "src" and "dst" options separated by commas and inclosed
    in square brackets ([]). These will be passed directly to iptables in the
    generated --set clause. See the ipset documentation for details.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example:
    "+Mirrors[src,dst,src]"<br>
    <br>
    Note that "+Mirrors[4]" used in the SOURCE column of the rules file is
    equivalent to "+Mirrors[src,src,src,src]".<br>
    <br>
    To generate a negative match, prefix the "+" with "!" as in
    "!+Mirrors".<br>
    <br>
    Example 1: Blacklist all hosts in an ipset named "blacklist"<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    /etc/shorewall/blacklist<br>
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    #ADDRESS/SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    PROTOCOL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PORT</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    +blacklist</span><br style="font-family: monospace;">
    <br>
    Example 2: Allow SSH from all hosts in an ipset named "sshok:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    /etc/shorewall/rules<br>
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    #ACTION&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DEST&nbsp;&nbsp;&nbsp;&nbsp;
    PROTO&nbsp;&nbsp;&nbsp; DEST PORT(S)</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    +sshok&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    22</span><br style="font-family: monospace;">
    <br>
    Shorewall can automatically capture the contents of your ipsets for you.
    If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf then
    "shorewall save" will save the contents of your ipsets. The file where
    the sets are saved is formed by taking the name where the Shorewall
    configuration is stored and appending "-ipsets". So if you enter the
    command "shorewall save standard" then your Shorewall configuration will
    be saved in var/lib/shorewall/standard and your ipset contents will be
    saved in /var/lib/shorewall/standard-ipsets. Assuming the default
    RESTOREFILE setting, if you just enter "shorewall save" then your
    Shorewall configuration will be saved in /var/lib/shorewall/restore and
    your ipset contents will be saved in
    /var/lib/shorewall/restore-ipsets.<br>
    <br>
    Regardless of the setting of SAVE_IPSETS, the "shorewall -f start" and
    "shorewall restore" commands will restore the ipset contents
    corresponding to the Shorewall configuration restored provided that the
    saved Shorewall configuration specified exists.<br>
    <br>
    For example, "shorewall restore standard" would restore the ipset
    contents from /var/lib/shorewall/standard-ipsets provided that
    /var/lib/shorewall/standard exists and is executable and that
    /var/lib/shorewall/standard-ipsets exists and is executable.<br>
    <br>
    Also regardless of the setting of SAVE_IPSETS, the "shorewall forget"
    command will purge the saved ipset information (if any) associated with
    the saved shorewall configuration being removed.<br>
    <br>
    You can also associate ipset contents with Shorewall configuration
    directories using the following command:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -S &gt; &lt;config
    directory&gt;/ipsets<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -S &gt;
    /etc/shorewall/ipsets<br>
    <br>
    When you start or restart Shorewall (including using the 'try' command)
    from the configuration directory, your ipsets will be configured from the
    saved ipsets file. Once again, this behavior is independent of the
    setting of SAVE_IPSETS.<br>
    <br>
    Ipsets are well suited for large blacklists. You can maintain your
    blacklist using the 'ipset' utility without ever having to restart or
    refresh Shorewall. If you use the SAVE_IPSETS=Yes feature just be sure to
    "shorewall save" after altering the blacklist ipset(s).<br>
    <br>
    Example /etc/shorewall/blacklist:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;
    #ADDRESS/SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    PROTOCOL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PORT</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;
    +Blacklist[src,dst]</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;
    +Blacklistnets[src,dst]</span><br style="font-family: monospace;">
    <br>
    Create the blacklist ipsets using:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -N Blacklist
    iphash<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -N
    Blacklistnets nethash<br>
    <br>
    Add entries<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A Blacklist
    206.124.146.177<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A Blacklistnets
    206.124.146.0/24<br>
    <br>
    To allow entries for individual ports<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -N SMTP portmap --from 1 --to
    31<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A SMTP 25<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A Blacklist
    206.124.146.177<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -B Blacklist 206.124.146.177
    -b SMTP<br>
    <br>
    Now only port 25 will be blocked from 206.124.146.177.<br>
    <br>
  </li>
  <li>Shorewall 2.4.0 can now configure routing if your kernel and iptables
    support the ROUTE target extension. This extension is available in
    Patch-O-Matic-ng. This feature is *EXPERIMENTAL* since the Netfilter team
    have no intention of ever releasing the ROUTE target extension to
    kernel.org.<br>
    <br>
    Routing is configured using the /etc/shorewall/routes file. Columns in
    the file are as follows:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Source of the packet. May be any of the</span> <span
    style="font-family: monospace;">following:</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A host or network address</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A network interface name.</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - The name of an ipset prefaced with "+"</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - $FW (for packets originating on the firewall)</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A MAC address in Shorewall format</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A range of IP addresses (assuming that your</span> <span
    style="font-family: monospace;">kernel and iptables support range
    match)</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A network interface name followed by ":"</span> <span
    style="font-family: monospace;">and an address or address
    range.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    DEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Destination of the packet. May be any of the</span> <span
    style="font-family: monospace;">following:</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A host or network address</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A network interface name (determined from</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    routing table(s))</span><br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - The name of an ipset prefaced with "+"</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    - A network interface name followed by ":"</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    and an address or address range.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    PROTO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Protocol - Must be "tcp", "udp", "icmp",</span> <span
    style="font-family: monospace;">"ipp2p", a number, or "all". "ipp2p"
    requires</span><span style="font-family: monospace;"><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ipp2p match support in your kernel and</span><span
    style="font-family: monospace;">iptables.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    PORT(S)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Destination
    Ports. A comma-separated list of</span> <span
    style="font-family: monospace;">Port names (from /etc/services), port<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    numbers</span> <span style="font-family: monospace;">or port ranges; if
    the protocol is "icmp", this</span><span
    style="font-family: monospace;">column is interpreted as the<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    destination</span> <span
    style="font-family: monospace;">icmp-type(s).</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    If the protocol is ipp2p, this column is</span> <span
    style="font-family: monospace;">interpreted as an ipp2p option without
    the</span><span style="font-family: monospace;"><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    leading "--" (example "bit" for bit-torrent).</span> <span
    style="font-family: monospace;">If no PORT is given, "ipp2p" is
    assumed.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    This column is ignored if PROTOCOL = all but</span> <span
    style="font-family: monospace;">must be entered if any of the
    following<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    field</span> <span style="font-family: monospace;">is supplied. In that
    case, it is suggested that</span> <span
    style="font-family: monospace;">this field contain "-"</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    SOURCE PORT(S)&nbsp; (Optional) Source port(s). If omitted,</span> <span
    style="font-family: monospace;">any source port is acceptable. Specified
    as a</span><span style="font-family: monospace;"><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    comma-separated list of port names, port</span> <span
    style="font-family: monospace;">numbers or port ranges.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    TEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Defines a test on the existing packet or</span> <span
    style="font-family: monospace;">connection mark.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    The rule will match only if the test returns</span> <span
    style="font-family: monospace;">true. Tests have the format</span><span
    style="font-family: monospace;"><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    [!]&lt;value&gt;[/&lt;mask&gt;][:C]</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Where:</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Inverts the test (not equal)</span>
    <span style="font-family: monospace;">&lt;value&gt; Value of the packet
    or</span><span style="font-family: monospace;"><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    connection mark.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    &lt;mask&gt;&nbsp; A mask to be applied to the</span> <span
    style="font-family: monospace;">mark before testing</span><br
    style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    :C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Designates a connection</span> <span
    style="font-family: monospace;">mark. If omitted, the packet</span> <span
    style="font-family: monospace;">mark's value<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    is tested.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The interface that the
    packet is to be routed</span> <span style="font-family: monospace;">out
    of. If you do not specify this<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    field then</span> <span style="font-family: monospace;">you must place
    "-" in this column and enter an</span> <span
    style="font-family: monospace;">IP address in the GATEWAY<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    column.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span
    style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    GATEWAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The gateway that
    the packet is to be forewarded</span> <span
    style="font-family: monospace;">through.</span><br
    style="font-family: monospace;">
    <br style="font-family: monospace;">
  </li>
  <li>Normally when Shorewall is stopped, starting or restarting then
    connections are allowed from hosts listed in /etc/shorewall/routestopped
    to the firewall and to other hosts listed in
    /etc/shorewall/routestopped.<br>
    <br>
    A new 'source' option is added for entries in that file which will cause
    Shorewall to allow traffic from the host listed in the entry to ANY other
    host. When 'source' is specified in an entry, it is unnecessary to also
    specify 'routeback'.<br>
    <br>
    Similarly, a new 'dest' option is added which will cause Shorewall to
    allow traffic to the host listed in the entry from ANY other host. When
    'source' is specified in an entry, it is unnecessary to also specify
    'routeback'.<br>
    <br>
  </li>
  <li>This change was implemented by Lorenzo Martignoni. It provides two new
    commands: "safe-start" and "safe-restart".<br>
    <br>
    <span style="font-weight: bold;">safe-start</span> starts Shorewall then
    prompts you to ask you if everything looks ok. If you answer "no" or if
    you don't answer within 60 seconds, a "shorewall clear" is executed.<br>
    <br>
    <span style="font-weight: bold;">safe-restart</span> saves your current
    configuration to /var/lib/shorewall/safe-restart then issues a "shorewall
    restart"; It then prompts you to ask if you if you want to accept the new
    configuration. If you answer "no" or if you don't answer within 60
    seconds, the configuration is restored to its prior state.<br>
    <br>
    These new commands require either that your /bin/sh supports the "-t"
    option to the 'read' command or that you have /bin/bash installed.<br>
  </li>
</ol>
<span style="font-weight: bold;">05/20/2005&nbsp; Shorewall CVS Repository
has Moved to Sourceforge<br>
<br>
</span> The CVS repository may now be accessed at <a target="_top"
href="http://sourceforge.net/cvs/?group_id=22587">http://sourceforge.net/cvs/?group_id=22587</a>.<br>
<span style="font-weight: bold;"><br>
05/20/2005 Shorewall 2.2.5<br>
<br>
</span> This will be my last 2.2 release. It contains a couple of small bug
fixes that I hadn't yet released.<br>
<br>
-Tom<br>
<br>
Problems Corrected:<br>

<ol>
  <li>Previously, if PKTTYPE=No in shorewall.conf then pkttype match would
    still be used if the kernel supported it.</li>
  <li>A typo in the 'tunnel' script has been corrected (Thanks to Patrik
    Varmeck&Atilde;&frac12;).</li>
  <li>A warning is now generated if an invalid short zone name is used in
    /etc/shorewall/zones.<br>
  </li>
</ol>
<span style="font-weight: bold;">05/18/2005 Tom stepping away from Shorewall
development and support<br>
</span> <br>
It is with regret that I announce that my involvement in Shorewall
development and support is officially ending.<br>
<br>
Unlike the originators of other successful open source projects, I have not
been able to attract a core of people who believe in Shorewall and who are
willing to make sacrifices to ensure it's success. That is my weakness and I
accept it. But is means that I have been left with trying to develop,
document, and support Shorewall almost single-handedly. I cannot do it any
more.<br>
<br>
I will clean up what I have for a 2.3 release and place it on the server as
my last Shorewall release -- Shorewall 2.4.0.<br>
<br>
Discussions aimed at continuing Shorewall development under new leadership
are continuing.<br>
<br>
Shorewall will always be a part of my life that I look back on with
fondness.<br>
<br>
Regards,<br>
<br>
-Tom<br>


<p><span style="font-weight: bold;">05/02/2005 Shorewall 2.2.4<br>
</span></p>

<p>Problems Corrected:<br>
</p>
<ol>
  <li>The error message:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: No appropriate chain for zone
    &lt;z1&gt; to zone &lt;z2&gt;<br>
    <br>
    has been changed to one that is more self-explanatory:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: No policy defined for zone
    &lt;z1&gt; to zone &lt;z2&gt;</li>
  <li>When only an interface name appeared in the HOST(S) column of an
    /etc/shorewall/hosts file entry, a misleading iptables error message
    resulted. Now the following message is generated:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: Invalid HOST(S) column
    contents: &lt;column contents&gt;</li>
</ol>
New Features:<br>

<ol>
  <li>Support has been added for UPnP using linux-igd&nbsp; (<a
    href="http://linux-idg.sourceforge.net/">http://linux-idg.sourceforge.net</a>).
    UPnP is required by a number of popular applications including MSN
  IM.</li>
</ol>

<div style="margin-left: 40px;">
<span style="font-weight: bold;">WARNING</span>:<br>


<div style="margin-left: 40px;">
From a security architecture viewpoint, UPnP is a disaster. It assumes
that:<br>

<ol style="list-style-type: lower-alpha;">
  <li>All local systems and their users are completely trustworthy.</li>
  <li>No local system is infected with any worm or trojan.</li>
</ol>
</div>

<div style="margin-left: 40px;">
If either of these assumptions are not true then UPnP can be used to totally
defeat your firewall and to allow incoming connections to arbitrary local
systems on any port whatsoever.<br>
In short: <span style="font-weight: bold;">USE UPnP AT YOUR OWN
RISK</span>.<br>
</div>

<div style="margin-left: 40px;">
<br>
</div>
</div>

<div style="margin-left: 40px;">
<span style="font-weight: bold;">WARNING</span>:<br>


<div style="margin-left: 40px;">
The linux-igd project appears to be inactive and the web site does not
display correctly on any open source browser that I've tried.<br>
<br>
Building and installing linux-igd is not for the faint of heart. You must
download the source from CVS and be prepared to do quite a bit of fiddling
with the include files from libupnp (which is required to build and/or run
linux-igd).<br>
<br>
</div>
</div>

<div style="margin-left: 40px;">
Configuring linux-igd:<br>


<div style="margin-left: 40px;">
In /etc/upnpd.conf, you will want:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
insert_forward_rules = yes<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
prerouting_chain_name = UPnP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
forward_chain_name = forwardUPnP<br>
<br>
</div>
</div>

<div style="margin-left: 40px;">
Shorewall Configuration:<br>


<div style="margin-left: 40px;">
In /etc/shorewall/interfaces, you need the 'upnp' option on your external
interface.<br>
<br>
If your fw-&gt;loc policy is not ACCEPT then you need this rule:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
allowoutUPnP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc<br>
<br>
Note: To use 'allowoutUPnP', your iptables and kernel must support the 'owner
match' feature (see the output of "shorewall check").<br>
<br>
If your loc-&gt;fw policy is not ACCEPT then you need this rule:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
allowinUPnP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
loc&nbsp;&nbsp;&nbsp;&nbsp; fw<br>
<br>
You MUST have this rule:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
forwardUPnP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp;&nbsp; loc<br>
<br>
</div>
</div>

<div style="margin-left: 40px;">
&nbsp;&nbsp; You must also ensure that you have a route to 224.0.0.0/4 on you
internal (local) interface.<br>
</div>
<ol start="2" style="list-style-type: decimal;">
  <li>A new 'started' extension script has been added.&nbsp; The difference
    between this extension script and /etc/shorewall/start is that this one
    is invoked after delayed loading of the blacklist
    (DELAYBLACKLISTLOAD=Yes) and after the 'shorewall' chain has been created
    (thus signaling that the firewall is completely up.<br>
    <br>
    /etc/shorewall/started should not change the firewall configuration
    directly but may do so indirectly by running /sbin/shorewall with the
    'nolock' option.<br>
    <br>
  </li>
  <li>By default, shorewall is started with the "-f" (fast) option when your
    system boots. You can override that setting by setting the OPTIONS
    variable in /etc/sysconfig/shorewall (SUSE/Redhat) or
    /etc/default/shorewall (Debian/Bering). If neither file exists, feel free
    to create one or the other.<br>
    <br>
    Example: If you want Shorewall to always use the config files even if
    there is a saved configuration, then specify:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS=""<br>
    <br>
  </li>
  <li>Shorewall now has support for the SAME target. This change affects the
    /etc/shorewall/masq and /etc/shorewall/rules file.<br>
    <br>
    SAME is useful when you specify multiple target IP addresses (in the
    ADDRESSES column of /etc/shorewall/masq or in the DEST column of
    /etc/shorewall/rules).<br>
    <br>
    If you use normal SNAT then multiple connections from a given local host
    to hosts on the internet can be assigned different source IP addresses.
    This confuses some applications that use multiple connections. To correct
    this problem, prefix the list of address ranges in the ADDRESS column
    with "SAME:"<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Example:&nbsp;&nbsp; SAME:206.124.146.176-206.124.146.180<br>
    <br>
    If you want each internal system to use the same IP address from the list
    regardless of which internet host it is talking to then prefix the ranges
    with "SAME:nodst:".<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Example:&nbsp;&nbsp; SAME:nodst:206.124.146.176-206.124.146.180<br>
    <br>
    Note that it is not possible to map port numbers when using SAME.<br>
    <br>
    In the rules file, when multiple connections from an internet host match
    a SAME rule then all of the connections will be sent to the same internal
    server. SAME rules are very similar to DNAT rules with the keyword SAME
    replacing DNAT. As in the masq file, changing the port number is not
    supported.<br>
    <br>
  </li>
  <li>A "shorewall show capabilities" command has been added to report the
    capabilities of your kernel and iptables.<br>
    <br>
    &nbsp;&nbsp; Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; gateway:~# shorewall show capabilities<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Loading
    /usr/share/shorewall/functions...<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Processing /etc/shorewall/params ...<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Processing
    /etc/shorewall/shorewall.conf...<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Loading Modules...<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Shorewall has detected the following
    iptables/netfilter capabilities:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    NAT: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Packet Mangling: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Multi-port Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Extended Multi-port Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Connection Tracking Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Packet Type Match: Not available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Policy Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Physdev Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    IP range Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Recent Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Owner Match: Available<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; gateway:~#<br>
    <br>
  </li>
  <li>A "-v" option has been added to /sbin/shorewall. Currently, this option
    only affects the "show log" command (e.g., "shorewall -v show log") and
    the "monitor" command. In these commands, it causes the MAC address in
    the log message (if any) to be displayed. As previously, when "-v" is
    omitted, the MAC address is suppressed.<br>
    <br>
  </li>
  <li>In /etc/shorewall/rules, a value of 'none' in either the SOURCE or DEST
    columns now causes the rule to be ignored. This is most useful when used
    with shell variables:<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    AllowFTP&nbsp;&nbsp;&nbsp;
    $FTP_CLIENTS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fw<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When FTP_CLIENTS is set to
    'none', the above rule is ignored.&nbsp; Otherwise, the rule is evaluated
    and generates Netfilter rules.<br>
    <br>
  </li>
  <li>The installer now detects that it is running on a Slackware system and
    adjusts the DEST and INIT variables accordingly.<br>
  </li>
</ol>

<p><span style="font-weight: bold;">05/01/2005 Tom spoke at LinuxFest NW 2005
-- Bellingham Technical College, Bellingham Washington<br>
</span><br>
Tom's presentation was entitled "Shorewall and Native IPSEC" and is available
for download <a href="http://shorewall.net/LinuxFest.pdf">here (PDF
Format)</a>.<br>
<br>
<span style="font-weight: bold;">04/07/2005 Shorewall 2.2.3<br>
</span><br>
Problems Corrected:<br>
</p>
<ol>
  <li>If a zone is defined in /etc/shorewall/hosts using
    &lt;interface&gt;:!&lt;network&gt; in the HOSTS column then startup
    errors occur on "shorewall [re]start".</li>
  <li>Previously, if "shorewall status" was run on a system whose kernel
    lacked advanced routing support (CONFIG_IP_ADVANCED_ROUTER),&nbsp; then
    no routing information was displayed.</li>
</ol>
New Features:<br>

<ol>
  <li>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.</li>
  <li>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'.<br>
    <br>
    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.<br>
    <br>
    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.</li>
  <li>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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.</li>
  <li>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.<br>
  </li>
</ol>
<span style="font-weight: bold;">03/31/2005 Shorewall 2.0.17<br>
<br>
</span> Problems Corrected:<br>

<ol>
  <li>Invoking the 'rejNotSyn' action results in an error at startup.</li>
  <li>The UDP and TCP port numbers in /usr/share/shorewall/action.AllowPCA
    were reversed.</li>
  <li>If a zone is defined in /etc/shorewall/hosts using &lt;<span
    style="font-style: italic;">interface</span>&gt;:!&lt;<span
    style="font-style: italic;">network</span>&gt; in the HOSTS column then
    startup errors occur on "shorewall [re]start".<br>
  </li>
</ol>
<span style="font-weight: bold;">03/12/2005 Shorewall 2.2.2<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>The SOURCE column in the /etc/shorewall/tcrules file now correctly
    allows IP ranges (assuming that your iptables and kernel support
    ranges).<br>
  </li>
  <li>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.</li>
  <li>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.</li>
  <li>The port numbers for UDP and TCP were previously reversed in the
    /usr/share/shorewall/action.AllowPCA file.</li>
  <li>Previously, the 'install.sh' script did not update the
    /usr/share/shorewall/action.* files.</li>
  <li>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.<br>
  </li>
</ol>
New Features:<br>

<ol>
  <li>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.</li>
  <li>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.</li>
  <li>The output from 'arp -na' has been added to the 'shorewall status'
    display.</li>
  <li>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.<br>
    <br>
    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.</li>
  <li>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:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;
    SUBNETS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    TARGET</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;
    192.168.1.0/24&nbsp;&nbsp; RETURN</span><br>
    <br>
    then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though
    you also have:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;
    SUBNETS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    TARGET</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;
    10.0.0.0/8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; logdrop</span><br>
    <br>
    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.<br>
    <br>
    If not specified or specified as empty (e.g., RFC1918_STRICT="") then
    RFC1918_STRICT=No is assumed.<br>
    <br>
    WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
    support 'Connection Tracking' match.<br>
  </li>
</ol>

<p><span style="font-weight: bold;">02/15/2005 Shorewall 2.2.1<br>
<br>
</span> This release rolls up the fixes for bugs found in the first 2-3 weeks
of deployment of Shorewall 2.2.<br>
</p>
<ol>
  <li>The /etc/shorewall/policy file contained a misleading comment and both
    that file and the /etc/shorewall/zones file lacked examples.</li>
  <li>Shorewall previously used root's default umask which could cause files
    in /var/lib/shorewall to be world-readable. Shorewall now uses umask
  0177.</li>
  <li>In log messages produced by logging a built-in action, the packet
    disposition was displayed incorrectly.<br>
    <br>
    &nbsp;&nbsp; Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    rejNotSyn:ULOG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all&nbsp;&nbsp;&nbsp;&nbsp;
    all&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    tcp<br>
    <br>
    &nbsp;&nbsp; produces the log message:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feb 12
    23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
    <br>
    &nbsp;&nbsp; rather than<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feb 12
    23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
    <br>
  </li>
  <li>The comments regarding built-in actions in
    /usr/share/shorewall/actions.std have been corrected.</li>
  <li>The /etc/shorewall/policy file in the LRP package was missing the
    'all-&gt;all' policy.<br>
  </li>
</ol>
<span style="font-weight: bold;">02/05/2005 End of Support for Shorewall
1.4<br>
<br>
</span> Effective today, support for Shorewall 1.4 has been discontinued. See
the link at the top of this article for&nbsp; upgrade information.<br>
<br>
<span style="font-weight: bold;">02/01/2005 Shorewall 2.0.16<br>
</span> <br>
This release back-ports the DROPINVALID shorewall.conf option from 2.2.0.<br>

<ol>
  <li>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.<br>
    <br>
    The new kernel code can be disabled by including this command in your
    /etc/shorewall/init file:<br>
    <br>
    echo 1 &gt; /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
    <br>
    Additional kernel logging about INVALID TCP packets may be obtained by
    adding this command to /etc/shorewall/init:<br>
    <br>
    echo 1 &gt; /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
    <br>
    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.<br>
    <br>
    If not specified or if specified as empty (e.g., DROPINVALID="") then
    DROPINVALID=Yes is assumed.</li>
</ol>

<p><span style="font-weight: bold;">02/01/2005 Shorewall 2.2.0<br>
<br>
</span> New Features:<br>
</p>
<ol>
  <li>ICMP packets that are in the INVALID state are now dropped by the
    Reject and Drop default actions. They do so using the new 'dropInvalid'
    builtin action. An 'allowInvalid' builtin action is also provided which
    accepts packets in that state.</li>
  <li>The /etc/shorewall/masq file INTERFACE column now allows additional
    options.<br>
    <br>
    Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
    defined in the /etc/shorewall/nat file. If you preceed the interface name
    with a plus sign ("+") then the rule will be evaluated before one-to-one
    NAT.<br>
    <br>
    Examples:<br>
    <br>
    +eth0<br>
    +eth1:192.0.2.32/27<br>
    <br>
    Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
    following the interface name by ":" but no digit.<br>
    <br>
    Examples:<br>
    <br>
    eth0:<br>
    eth1::192.0.2.32/27<br>
    +eth3:<br>
    <br>
  </li>
  <li>Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
    you to override the setting of ADD_IP_ALIASES=Yes by following the
    interface name with ":" but no digit.</li>
  <li>All configuration files in the Shorewall distribution with the
    exception of shorewall.conf are now empty. In particular, the
    /etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos files
    now have no active entries. Hopefully this will stop the questions on the
    support and development lists regarding why the default entries are the
    way they are.</li>
  <li>Previously, including a log level (and optionally a log tag) on a rule
    that specified a user-defined (or Shorewall-defined) action would log all
    traffic passed to the action. Beginning with this release, specifying a
    log level in a rule that specifies a user- or Shorewall-defined action
    will cause each rule in the action to be logged with the specified level
    (and tag).<br>
    <br>
    The extent to which logging of action rules occurs is goverend by the
    following:</li>
  <li style="list-style: none"><ul>
      <li>When you invoke an action and specify a log level, only those rules
        in the action that have no log level will be changed to log at the
        level specified at the action invocation.<br>
        <br>
        Example:<br>
        <br>
        /etc/shorewall/action.foo:<br>
        <br>
        ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
        tcp&nbsp;&nbsp;&nbsp; 22<br>
        bar:info<br>
        <br>
        /etc/shorewall/rules:<br>
        <br>
        foo:debug&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp; net<br>
        <br>
        Logging in the invoked 'foo' action will be:<br>
        <br>
        ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
        -&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
        bar:info<br>
        <br>
      </li>
      <li>If you follow the log level with "!" then logging will be at that
        level for all rules recursively invoked by the action<br>
        <br>
        Example: /etc/shorewall/action.foo:<br>
        <br>
        <b>Update:</b> 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).<br>
        ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
        tcp&nbsp;&nbsp;&nbsp; 22<br>
        bar:info<br>
        <br>
        /etc/shorewall/rules:<br>
        <br>
        foo:debug!&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp; net<br>
        <br>
        Logging in the invoke 'foo' action will be:<br>
        <br>
        ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
        -&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
        bar:debug!<br>
        <br>
      </li>
    </ul>
  </li>
</ol>

<div style="margin-left: 40px;">
This change has an effect on extension scripts used with user-defined
actions. If you define an action 'acton' and you have an /etc/shorewall/acton
script then when that script is invoked, the following three variables will
be set for use by the script:<br>
<br>


<div style="margin-left: 40px;">
$CHAIN = the name of the chain where your rules are to be placed. When
logging is used on an action invocation, Shorewall creates a chain with a
slightly different name from the action itself.<br>
$LEVEL = Log level. If empty, no logging was specified.<br>
$TAG&nbsp;&nbsp; = Log Tag.<br>
<br>
</div>
Example:<br>
<br>
/etc/shorewall/rules:<br>
&nbsp;&nbsp;&nbsp;<br>
acton:info:test<br>
<br>
Your /etc/shorewall/acton file will be run with:<br>
<br>


<div style="margin-left: 40px;">
$CHAIN="%acton1<br>
$LEVEL="info"<br>
$TAG="test"<br>
</div>
</div>
<br>

<ol start="6">
  <li>The /etc/shorewall/startup_disabled file is no longer created when
    Shorewall is first installed. Rather, the variable STARTUP_ENABLED is set
    to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall to
    start, that variable's value must be set to 'Yes'. This change
    accomplishes two things:</li>
  <li style="list-style: none"><ul>
      <li>It prevents Shorewall from being started prematurely by the user's
        initialization scripts.</li>
      <li>It causes /etc/shorewall/shorewall.conf to be modified so that it
        won't be replaced by upgrades using RPM.<br>
        <br>
      </li>
    </ul>
  </li>
  <li>Support has been added for the 2.6 Kernel IPSEC implementation. To use
    this support, you must have installed the IPSEC policy match patch and
    the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The policy match
    patch affects both your kernel and iptables. There are two ways to
    specify that IPSEC is to be used when communicating with a set of hosts;
    both methods involve the new /etc/shorewall/ipsec file:</li>
  <li style="list-style: none"><ol style="list-style-type: lower-alpha;">
      <li>If encrypted communication is used with all hosts in a zone, then
        you can designate the zone as an "ipsec" zone by placing 'Yes" in the
        IPSEC ONLY column in /etc/shorewall/ipsec:<br>
        <br>
        <span style="font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp;
        &nbsp;&nbsp;&nbsp; IPSEC&nbsp;&nbsp;&nbsp; OPTIONS ...</span><br
        style="font-family: monospace;">
        <span style="font-family: monospace;">#&nbsp;&nbsp;&nbsp;
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ONLY</span><br
        style="font-family: monospace;">
        <span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes</span><br>
        <br>
        The hosts in the zone (if any) must be specified in
        /etc/shorewall/hosts but you do not need to specify the 'ipsec'
        option on the entries in that file (see below). Dynamic zones
        involving IPSEC must use that technique.<br>
        <br>
        Example:Under 2.4 Kernel FreeS/Wan:<br>
        <br>
        /etc/shorewall/zones:<br>
        <br>
        <span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
        Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
        style="font-family: monospace;">
        <span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
        VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
        <br>
        /etc/shorewall/interfaces:<br>
        <br>
        <span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
        eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
        <span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
        ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
        <br>
        Under 2.6 Kernel with this new support:<br>
        <br>
        /etc/shorewall/zones:<br>
        <br>
        <span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
        Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
        style="font-family: monospace;">
        <span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
        VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
        <br>
        /etc/shorewall/interfaces:<br>
        <br>
        <span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
        eth0&nbsp;&nbsp;&nbsp; ...</span><br>
        <br>
        /etc/shorewall/hosts:<br>
        <br>
        <span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
        eth0:0.0.0.0/0</span><br>
        <br>
        /etc/shorewall/ipsec<br>
        <br>
        <span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp; Yes<br>
        <br>
        </span></li>
      <li>If only part of the hosts in a zone require encrypted
        communication, you may use of the new 'ipsec' option in
        /etc/shorewall/hosts to designate those hosts.<br>
        <br>
        Example:<br>
        <br>
        Under 2.4 Kernel FreeS/Wan:<br>
        <br>
        /etc/shorewall/zones:<br>

        <pre>net    Net    The big bad Internet<br>
loc    Local  Extended local zone</pre>
        /etc/shorewall/interfaces:<br>
        <br>
        <span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
        eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
        <span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
        eth1&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
        <span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
        ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
        <br>
        Under 2.6 Kernel with this new support:<br>
        <br>
        /etc/shorewall/zones:<br>
        <br>
        <span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
        &nbsp;&nbsp;&nbsp; Net&nbsp;&nbsp;&nbsp; The big bad
        Internet</span><br style="font-family: monospace;">
        <span
        style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        &nbsp; VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
        <br>
        /etc/shorewall/interfaces:<br>
        <br>
        <span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
        eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
        <span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
        eth1&nbsp;&nbsp;&nbsp; ...</span><br>
        <br>
        /etc/shorewall/hosts:<br>
        <br>
        <span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
        eth0:0.0.0.0/0&nbsp;&nbsp;&nbsp; ipsec,...</span> </li>
    </ol>
  </li>
</ol>

<div style="margin-left: 40px;">
Regardless of which technique you choose, you can specify additional SA
options for the zone in the /etc/shorewall/ipsec entry.<br>
<br>
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the input-output,
input and output characteristics of the security associations to be used to
decrypt (input) or encrypt (output) traffic to/from the zone.<br>
<br>
The available options are:<br>
</div>

<div style="margin-left: 2em">
<ul>
  <li>reqid[!]=&lt;number&gt; where &lt;number&gt; is specified using
    setkey(8) using the 'unique:&lt;number&gt;' option for the SPD level.</li>
  <li>spi[!]=&lt;number&gt; where &lt;number&gt; is the SPI of the SA. Since
    different SAs are used to encrypt and decrypt traffic, this option should
    only be listed in the IN OPTIONS and OUT OPTIONS columns.</li>
  <li>proto[!]=ah|esp|ipcomp</li>
  <li>mss=&lt;number&gt; (sets the MSS value in TCP SYN packets and is not
    related to policy matching)</li>
  <li>mode[!]=transport|tunnel</li>
  <li>tunnel-src[!]=&lt;address&gt;[/&lt;mask&gt;] (only available with
    mode=tunnel)</li>
  <li>tunnel-dst[!]=&lt;address&gt;[/&lt;mask&gt;] (only available with
    mode=tunnel). Because tunnel source and destination are dependent on the
    direction of the traffic, these options should only appear in the IN
    OPTIONS and OUT OPTIONS columns.</li>
  <li>strict&nbsp; (if specified, packets must match all policies; policies
    are delimited by 'next').</li>
  <li>next&nbsp;&nbsp;&nbsp; (only available with strict)</li>
</ul>
</div>

<div style="margin-left: 40px;">
Examples:<br>
<br>
<span style="font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp; IPSEC&nbsp;
OPTIONS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IN&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OUT</span><br style="font-family: monospace;">
<span
style="font-family: monospace;">#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ONLY&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
OPTIONS&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Yes&nbsp;&nbsp;&nbsp; mode=tunnel,proto=esp&nbsp;&nbsp;&nbsp;
spi=1000&nbsp;&nbsp;&nbsp; spi=1001</span><br style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
No&nbsp;&nbsp;&nbsp;&nbsp; reqid=44,mode=transport</span><br>
<br>
The /etc/shorewall/masq file has a new IPSEC column added. If you specify Yes
or yes in that column then the unencrypted packets will have their source
address changed. Otherwise, the unencrypted packets will not have their
source addresses changed. This column may also contain a comma-separated list
of the options specified above in which case only those packets that will be
encrypted by an SA matching the given options will have their source address
changed.<br>
</div>
<ol start="8">
  <li>To improve interoperability, tunnels of type 'ipsec' no longer enforce
    the use of source port 500 for ISAKMP and OpenVPN tunnels no longer
    enforce use of the specified port as both the source and destination
    ports.</li>
  <li>A new 'allowBcast' builtin action has been added -- it silently allows
    broadcasts and multicasts.</li>
  <li>The -c option in /sbin/shorewall commands is now deprecated. The
    commands where -c was previously allowed now permit you to specify a
    configuration directory after the command:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall check&nbsp;&nbsp; [
    &lt;configuration-directory&gt; ]<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall restart [
    &lt;configuration-directory&gt; ]<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall start&nbsp;&nbsp; [
    &lt;configuration-directory&gt; ]<br>
    <br>
  </li>
  <li>Normally, when SNAT or MASQUERADE is applied to a tcp or udp
    connection, Netfilter attempts to retain the source port number. If it
    has to change to port number to avoid&nbsp; &lt;source
    address&gt;,&lt;source port&gt; conflicts, it tries to do so within port
    ranges ( &lt; 512, 512-1023, and &gt; 1023). You may now specify an
    explicit range of source ports to be used by following the address or
    address range (if any) in the ADDRESS column with ":" and a port range in
    the format &lt;low-port&gt;-&lt;high-port&gt;. You must specify either
    "tcp" or "udp" in the PROTO column.<br>
    <br>
    Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; #INTERFACE
    SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
    ADDRESS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; PROTO</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
    eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.0/24&nbsp;
    :4000-5000&nbsp;&nbsp;&nbsp;&nbsp; tcp</span><br
    style="font-family: monospace;">
    <br>
    Example 2 -- SNAT with udp source ports 7000-8000:<br>
    <br>
    &nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">#INTERFACE
    SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
    ADDRESS&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    PROTO</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;
    eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    10.0.0.0/8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    192.0.2.44:7000-8000&nbsp;&nbsp;&nbsp; udp<br>
    <br>
    </span></li>
  <li>You may now account by user/group ID for outbound traffic from the
    firewall itself with entries in /etc/shorewall/accounting. Such
    accounting rules must be placed in the OUTPUT chain. See the comments at
    the top of /etc/shorewall/accounting for details.</li>
  <li>Shorewall now verifies that your kernel and iptables have physdev match
    support if BRIDGING=Yes in shorewall.conf.</li>
  <li>Beginning with this release, if your kernel and iptables have iprange
    match support (see the output from "shorewall check"), then with the
    exception of the /etc/shorewall/netmap file, anywhere that a network
    address may appear an IP address range of the form &lt;low
    address&gt;-&lt;high address&gt; may also appear.</li>
  <li>Support has been added for the iptables CLASSIFY target. That target
    allows you to classify packets for traffic shaping directly rather than
    indirectly through fwmark. Simply enter the &lt;major&gt;:&lt;minor&gt;
    classification in the first column of /etc/shorewall/tcrules:<br>
    <br>
    Example:<br>
    <br>
    <span
    style="font-family: monospace;">#MARK/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    DEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROTO&nbsp;&nbsp;&nbsp;&nbsp;
    PORT(S)</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">#CLASSIFY</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">1:30&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp; &nbsp; tcp&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp; 25</span><br>
    <br>
    Note that when using this form of rule, it is acceptable to include the
    name of an interface in the DEST column.<br>
    <br>
    Marking using the CLASSIFY target always occurs in the POSTROUTING chain
    of the mangle table and is not affected by the setting of
    MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
  <li>During "shorewall start", IP addresses to be added as a consequence of
    ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted when
    /etc/shorewall/nat and /etc/shorewall/masq are processed then they are
    re-added later. This is done to help ensure that the addresses can be
    added with the specified labels but can have the undesirable side effect
    of causing routes to be quietly deleted. A new RETAIN_ALIASES option has
    been added to shorewall.conf; when this option is set to Yes, existing
    addresses will not be deleted. Regardless of the setting of
    RETAIN_ALIASES, addresses added during "shorewall start" are still
    deleted at a subsequent "shorewall stop" or "shorewall restart".</li>
  <li>Users with a large black list (from /etc/shorewall/blacklist) may want
    to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When
    DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before
    loading the blacklist rules. While this may allow connections from
    blacklisted hosts to slip by during construction of the blacklist, it can
    substantially reduce the time that all new connections are disabled
    during "shorewall [re]start".</li>
  <li>Using the default LOGFORMAT, chain names longer than 11 characters
    (such as in user-defined actions) may result in log prefix truncation. A
    new shorewall.conf action&nbsp; LOGTAGONLY has been added to deal with
    this problem. When LOGTAGONLY=Yes, logging rules that specify a log tag
    will substitute the tag for the chain name in the log prefix.<br>
    <br>
    Example -- file /etc/shorewall/action.thisisaverylogactionname:<br>
    <br>
    &nbsp;&nbsp;&nbsp; Rule:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
    style="font-family: monospace;">DROP:info:ftp&nbsp;&nbsp;&nbsp;
    0.0.0.0/0&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 21</span><br>
    &nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=No:<br>
    <br>
    &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; <span
    style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
    <br>
    &nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=Yes:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
    style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
    <br>
  </li>
  <li>Shorewall now resets the 'accept_source_route' flag for all interfaces.
    If you wish to accept source routing on an interface, you must specify
    the new 'sourceroute' interface option in /etc/shorewall/interfaces.</li>
  <li>The default Drop and Reject actions now invoke the new standard action
    'AllowICMPs'. This new action accepts critical ICMP types:<br>
    &nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp; Type 3 code 4 (fragmentation needed)<br>
    &nbsp;&nbsp;&nbsp; Type 11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (TTL
    exceeded)<br>
    <br>
  </li>
  <li>Explicit control over the kernel's Martian logging is now provided
    using the new 'logmartians' interface option. If you include
    'logmartians' in the interface option list then logging of Martian
    packets on will be enabled on the specified interface. If you wish to
    globally enable martian logging, you can set LOG_MARTIANS=Yes in
    shorewall.conf.</li>
  <li>You may now cause Shorewall to use the '--set-mss' option of the TCPMSS
    target. In other words, you can cause Shorewall to set the MSS field of
    SYN packets passing through the firewall to the value you specify. This
    feature extends the existing CLAMPMSS option in
    /etc/shorewall/shorewall.conf by allowing that option to have a numeric
    value as well as the values "Yes" and "No".<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; CLAMPMSS=1400<br>
    <br>
  </li>
  <li>Shorewall now includes support for the ipp2p match facility. This is a
    departure from my usual policy in that the ipp2p match facility is
    included in Patch-O-Matic-NG and is unlikely to ever be included in the
    kernel.org source tree. Questions about how to install the patch or how
    to build your kernel and/or iptables should not be posted on the
    Shorewall mailing lists.<br>
    <br>
    In the following files, the "PROTO" or "PROTOCOL" column may contain
    "ipp2p":<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/rules<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/tcrules<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/accounting<br>
    <br>
    When the PROTO or PROTOCOL column contains "ipp2p" then the DEST PORT(S)
    or PORT(S) column may contain a recognized ipp2p option; for a list of
    the options and their meaning, at a root prompt:<br>
    <br>
    &nbsp;&nbsp;&nbsp; iptables -m ipp2p --help<br>
    <br>
    You must not include the leading "--" on the option; Shorewall will
    supply those characters for you. If you do not include an option then
    "ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</li>
  <li>Shorewall now has support for the CONNMARK target from iptables. See
    the /etc/shorewall/tcrules file for details.</li>
  <li>A new debugging option LOGALLNEW has been added to shorewall.conf. When
    set to a log level, this option causes Shorewall to generaate a logging
    rule as the first rule in each builtin chain.<br>
    <br>
    &nbsp;&nbsp;&nbsp; - The table name is used as the chain name in the log
    prefix.<br>
    &nbsp;&nbsp;&nbsp; - The chain name is used as the target in the log
    prefix.<br>
    <br>
    Example: Using the default LOGFORMAT, the log prefix for logging from the
    nat table's PREROUTING chain is:<br>
    <br>
    &nbsp;&nbsp;&nbsp; &nbsp;<span
    style="font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
    <br>
    IMPORTANT: There is no rate limiting on these logging rules so use
    LOGALLNEW at your own risk; it may cause high CPU and disk utilization
    and you may not be able to control your firewall after you enable this
    option.<br>
    <br>
    DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE SENT
    TO ANOTHER SYSTEM.<br>
    <br>
  </li>
  <li>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.</li>
  <li>The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).</li>
  <li>For consistency, the CLIENT PORT(S) column in the tcrules file has been
    renamed SOURCE PORT(S).</li>
  <li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown in
    the output of "shorewall status".</li>
  <li>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.</li>
  <li>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).<br>
    <br>
    &nbsp;&nbsp;&nbsp; Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
    style="font-family: monospace;">ursa:/etc/shorewall # shorewall show
    zones</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
    Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
    2004</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; loc</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
    eth0:192.168.1.0/24</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
    eth1:1.2.3.4</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
    eth0:0.0.0.0/0</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; WiFi</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
    eth1:0.0.0.0/0</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; sec</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
    eth1:0.0.0.0/0</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
    ursa:/etc/shorewall #</span><br>
    <br>
  </li>
  <li>Variable expansion may now be used with the INCLUDE directive.<br>
    <br>
    &nbsp;&nbsp;&nbsp; Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; /etc/shorewall/params<br>
    <br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span
    style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config file:<br>
    <br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span
    style="font-family: monospace;">INCLUDE $FILE</span><br>
    <br>
  </li>
  <li>The output of "shorewall status" now includes the results of "ip -stat
    link ls". This helps diagnose performance problems caused by link
  errors.</li>
  <li>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.</li>
  <li>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.<br>
    <br>
    The new kernel code can be disabled by including this command in your
    /etc/shorewall/init file:<br>
    <br>
    &nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">echo 1 &gt;
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
    <br>
    Additional kernel logging about INVALID TCP packets may be obtained by
    adding this command to /etc/shorewall/init:<br>
    <br>
    &nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">echo 1 &gt;
    /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
    <br>
    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.<br>
    <br>
    If not specified or if specified as empty (e.g., DROPINVALID="") then
    DROPINVALID=Yes is assumed.<br>
    <br>
  </li>
  <li>The "shorewall add" and "shorewall delete" commands now accept a list
    of hosts to add or delete.<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">shorewall add
    eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp; shorewall delete
    eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
    <br>
    &nbsp;&nbsp;&nbsp; The above commands may also be written:<br>
    <br>
    &nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">shorewall add
    eth1:1.2.3.4,2.3.4.5 z12</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp; shorewall delete
    eth1:1.2.3.4,2.3.4.5 z12</span><br>
    &nbsp;&nbsp;<br>
  </li>
  <li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type.
    OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
    <br>
    &nbsp;&nbsp;&nbsp; <span
    style="font-family: monospace;">openvpn[:{tcp|udp}][:&lt;port&gt;]&nbsp;&nbsp;&nbsp;
    &lt;zone&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
    &lt;gateway&gt;</span><br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
    style="font-family: monospace;">openvpn:tcp&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; 1.2.3.4&nbsp;&nbsp;&nbsp;
    # TCP tunnel on port 1194</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
    openvpn:3344&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    1.2.3.4&nbsp;&nbsp;&nbsp; # UDP on port 3344</span><br
    style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
    openvpn:tcp:4455&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    1.2.3.4&nbsp;&nbsp;&nbsp; # TCP on port 4455</span><br>
    <br>
  </li>
  <li>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).<br>
    <br>
    This script is intended for use on Roadwarrior laptops for establishing
    an IPSEC SA to/from remote networks. The script has some limitations:</li>
</ol>

<div style="margin-left: 2em">
<ul>
  <li>Only one instance of the script may be used at a time.</li>
  <li>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.</li>
</ul>
</div>
<ol start="39">
  <li>The output of "shorewall status" now lists the loaded netfilter kernel
    modules.</li>
  <li>The range of UDP ports opened by the AllowTrcrt action has been
    increased to 33434:33524.</li>
  <li>The IANA has recently registered port 1194 for use by OpenVPN. In
    previous versions of Shorewall (and OpenVPN), the default port was 5000
    but has been changed to 1194 to conform to the new OpenVPN default.</li>
</ol>

<p><span style="font-weight: bold;">01/17/2005 - Shorewall 2.2.0 RC5<br>
<br>
</span> Problems Corrected:<br>
</p>
<ol>
  <li>The AllowTrcrt action has been changed to allow up to 30 hops (same as
    default for 'traceroute'). Previously, the action was documented as
    allowing 20 hops but actually only allowed for 6 hops.<br>
  </li>
  <li>Using some lightweight shells, valid entries in /etc/shorewall/ecn
    produce startup errors.</li>
</ol>
New Features:<br>

<ol>
  <li>A new AllowInvalid standard built-in action has been added. This action
    accepts packets that are in the INVALID connection-tracking state.</li>
</ol>
<span style="font-weight: bold;"><a name="Mirrors"></a>01/16/2005 - New
Shorewall Mirrors<br>
<br>
</span> Thanks to Lorenzo Martignoni and Nick Slikey, there are now Shorewall
<a href="shorewall_mirrors.htm">mirrors</a> in Milan Italy and in Austin
Texas. Thanks Lorenzo and Nick!<br>
<span style="font-weight: bold;"><br>
<a name="2_0_15"></a>01/12/2005 - Shorewall 2.0.15<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>The range of ports opened by the AllowTrcrt action has been expanded to
    33434:33524 to allow for a maximum of 30 hops.</li>
  <li>Code mis-ported from 2.2.0 in release 2.0.14 caused the following error
    during "shorewall start" where SYN rate-limiting is present in
    /etc/shorewall/policy:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bad argument `DROP'<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Try `iptables -h' or 'iptables --help' for
    more information.<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_RC4"></a>01/06/2005 -
Shorewall 2.2.0 RC4<br>
</span> <br>
New Features:<br>

<ol>
  <li>A listing of loaded iptables kernel modules is now included in the
    output of "shorewall status".<br>
  </li>
</ol>
Problems Corrected.<br>

<ol>
  <li>Several problems associated with processing the IPSEC colummn in
    /etc/shorewall/masq have been corrected.<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_0_14"></a>01/03/2005 - Shorewall
2.0.14<br>
</span> <br>
New Features:<br>

<ol>
  <li>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.<br>
  </li>
</ol>
Problems Corrected:<br>

<ol>
  <li>A typo in the /etc/shorewall/interfaces file has been fixed.</li>
  <li>"bad variable" error messages occurring during "shorewall stop" and
    "shorewall clear" have been eliminated.</li>
  <li>A misleading typo in /etc/shorewall/tunnels has been corrected. The
    TYPE column for an IPIP tunnel should contain "ipip" rather than "ip".<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="MandrakeRPMS"></a>12/31/2004 -
Mandrake-specific RPMs available<br>
<br>
</span> Jack Coates has generously volunteered to provide Shorewall RPMs for
use under Mandrake. You can download Jack's RPMs from <a target="_top"
href="http://www.monkeynoodle.org/tmp/">http://www.monkeynoodle.org/tmp/</a><br>
<br>
<span style="font-weight: bold;"><a name="Redhat_Fedora"></a>12/31/2004 -
Redhat/Fedora-specific RPMs available<br>
</span> <br>
Simon Matter has graciously volunteered to provide RPMs tailored for Redhat
and Fedora. You can download Simon's RPMs from <a target="_top"
href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
<br>
Thanks, Simon!<br>
<br>
<span style="font-weight: bold;"><a name="2_2_0_RC3"></a>12/30/2004 -
Shorewall 2.2.0 RC3<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>The following error message could appear during "shorewall stop" or
    "shorewall clear":<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    local: lo:: bad variable name<br>
    <br>
  </li>
  <li>The rate limiting example in /etc/shorewall/rules has been changed to
    use the RATE LIMIT column.</li>
  <li>Entries in /etc/shorewall/masq with the INTERFACE column containing
    &lt;ifname&gt;:: (e.g., "eth0::") would generate a progress message but
    would not generate an iptables rule.</li>
  <li>A misleading typo in /etc/shorewall/tunnels has been corrected.<br>
  </li>
</ol>

<p><br>
</p>

<p><span style="font-weight: bold;">12/24/2004 - Shorewall 2.2.0 RC2<br>
<br>
</span> New Features:<br>
</p>
<ol>
  <li>By popular demand, the default port for Open VPN tunnels is now 1194
    (the IANA-reserved port number for Open VPN).</li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_RC1"></a>12/19/2004 -
Shorewall 2.2.0 RC1<br>
<br>
</span> Problems Corrected:<br>

<ol>
  <li>The syntax of the add and delete command has been clarified in the help
    summary produced by /sbin/shorewall.</li>
</ol>
New Features:<br>

<ol>
  <li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type.
    OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
    <br>
    &nbsp;&nbsp;&nbsp; openvpn[:{tcp|udp}][:&lt;port&gt;]&nbsp;&nbsp;&nbsp;
    &lt;zone&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;gateway&gt;<br>
    <br>
    Examples:<br>

    <pre>    openvpn:tcp         net    1.2.3.4    # TCP tunnel on port 5000<br>
    openvpn:3344        net    1.2.3.4    # UDP on port 3344<br>
    openvpn:tcp:4455    net    1.2.3.4    # TCP on port 4455</pre>
  </li>
  <li>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).<br>
    <br>
    This script is intended for use on Roadwarrior laptops for establishing
    an IPSEC SA to/from remote networks. The script has some limitations:<br>
    <br>
    &nbsp;&nbsp;&nbsp; - Only one instance of the script may be used at a
    time.<br>
    &nbsp;&nbsp;&nbsp; - 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.<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_Beta8"></a>12/11/2004 -
Shorewall 2.2.0 Beta 8<br>
<br>
</span> Problems Corrected:<br>

<ol>
  <li>A typo in the /etc/shorewall/interfaces file has been corrected.</li>
  <li>Previously, the "add" and "delete" commands were generating incorrect
    policy matches when policy match support was available.</li>
</ol>
New Features:<br>

<ol>
  <li>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.<br>
    <br>
    The new kernel code can be disabled by including this command in your
    /etc/shorewall/init file:<br>
    <br>
    &nbsp;&nbsp;&nbsp; echo 1 &gt;
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
    <br>
    Additional kernel logging about INVALID TCP packets may be obtained by
    adding this command to /etc/shorewall/init:<br>
    <br>
    &nbsp;&nbsp;&nbsp; echo 1 &gt;
    /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
    <br>
    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.<br>
    <br>
    If not specified or if specified as empty (e.g., DROPINVALID="") then
    DROPINVALID=Yes is assumed.<br>
    <br>
  </li>
  <li>The "shorewall add" and "shorewall delete" commands now accept a list
    of hosts to add or delete.<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp; shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12<br>
    &nbsp;&nbsp;&nbsp; shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12<br>
    <br>
    The above commands may also be written:<br>
    <br>
    &nbsp;&nbsp;&nbsp; shorewall add eth1:1.2.3.4,2.3.4.5 z12<br>
    &nbsp;&nbsp;&nbsp; shorewall delete eth1:1.2.3.4,2.3.4.5 z12<br>
    &nbsp;&nbsp;<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_Beta7"></a>12/04/2004 -
Shorewall 2.2.0 Beta 7<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>The "shorewall add" and "shorewall delete" commands now work in a
    bridged environment. The syntax is:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall
    add &lt;interface&gt;[:&lt;port&gt;]:&lt;address&gt; &lt;zone&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall
    delete &lt;interface&gt;[:&lt;port&gt;]:&lt;address&gt; &lt;zone&gt;<br>
    &nbsp;<br>
    &nbsp;&nbsp; Examples:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall
    add br0:eth2:192.168.1.3 OK<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall
    delete br0:eth2:192.168.1.3 OK<br>
    <br>
  </li>
  <li>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.<br>
    <br>
    To accomplish this change, the "restore base" file
    (/var/lib/shorewall/restore-base) has been split into two files:<br>
    &nbsp;<br>
    /var/lib/shorewall/restore-base -- commands to be executed before
    Netfilter the configuration is restored.<br>
    &nbsp;<br>
    /var/lib/shorewall/restore-tail -- commands to be executed after the
    Netfilter configuration is restored.<br>
    <br>
  </li>
  <li>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-&gt;Z
    policies and rules. This has been corrected.</li>
  <li>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.</li>
</ol>
New Features:<br>

<ol>
  <li>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).<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp; Example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ursa:/etc/shorewall #
    shorewall show zones<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Shorewall-2.2.0-Beta7 Zones at
    ursa - Sat Nov 27 11:18:25 PST 2004<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    eth0:192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    eth1:1.2.3.4<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; net<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    eth0:0.0.0.0/0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WiFi<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    eth1:0.0.0.0/0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sec<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    eth1:0.0.0.0/0<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ursa:/etc/shorewall #<br>
    <br>
  </li>
  <li>Variable expansion may now be used with the INCLUDE directive.<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp; Example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/params<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    FILE=/etc/foo/bar<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config file:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    INCLUDE $FILE<br>
    <br>
  </li>
  <li>The output of "shorewall status" now includes the results of "ip -stat
    link ls". This helps diagnose performance problems caused by link
  errors.</li>
  <li>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<br>
    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.<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_0_13"></a>12/02/2004 - Shorewall
2.0.13<br>
<br>
</span> Problems Corrected:<br>

<ol>
  <li>A typo in /usr/share/shorewall/firewall caused the "shorewall add" to
    issue an error message:<br>

    <pre class="programlisting">/usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found</pre>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_0_12"></a>12/01/2004 - Shorewall
2.0.12<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>A typo in shorewall.conf (NETNOTSYN) has been corrected.</li>
  <li>The "shorewall add" and "shorewall delete" commands now work in a
    bridged environment. The syntax is:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall add
    &lt;interface&gt;[:&lt;bridge port&gt;][:&lt;address&gt;] &lt;zone&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall delete
    &lt;interface&gt;[:&lt;bridge port&gt;][:&lt;address&gt;] &lt;zone&gt;<br>
    &nbsp;<br>
    Examples:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall add br0:eth2:192.168.1.3 OK<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall delete br0:eth2:192.168.1.3
    OK<br>
    <br>
  </li>
  <li>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.<br>
    &nbsp;<br>
    To accomplish this change, the "restore base" file
    (/var/lib/shorewall/restore-base) has been split into two files:<br>
    &nbsp;<br>
    &nbsp;&nbsp; /var/lib/shorewall/restore-base -- commands to be executed
    before the Netfilter configuration is restored.<br>
    &nbsp;<br>
    &nbsp;&nbsp; /var/lib/shorewall/restore-tail -- commands to be executed
    after the Netfilter configuration is restored.<br>
    <br>
  </li>
  <li>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-&gt;Z
    policies and rules. This has been corrected.</li>
</ol>
New Features:<br>

<ol>
  <li>Variable expansion may now be used with the INCLUDE directive.<br>
    &nbsp;<br>
    Example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/params<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    FILE=/etc/foo/bar<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config file:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    INCLUDE $FILE<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_Beta6"></a>11/26/2004 -
Shorewall 2.2.0 Beta 6<br>
<br>
</span> Beta 5 was more or less DOA. Here's Beta 6.<br>
<br>
Problems Corrected:<br>

<ol>
  <li>Fixed a number of problems associated with not having an IPTABLES value
    assigned in shorewall.conf</li>
  <li>Corrected a 'duplicate chain' error on "shorewall add" when the 'mss'
    option is present in /etc/shorewall/ipsec.<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_Beta5"></a>11/26/2004 -
Shorewall 2.2.0 Beta 5<br>
</span> <br>
Problems corrected:<br>

<ol>
  <li>A typo in shorewall.conf (NETNOTSYN) has been corrected.</li>
</ol>
New Features:<br>

<ol>
  <li>For consistency, the CLIENT PORT(S) column in the tcrules file has been
    renamed SOURCE PORT(S).</li>
  <li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown in
    the output of "shorewall status".</li>
  <li>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.<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_0_11"></a>11/23/2004 - Shorewall
2.0.11<br>
</span> <br>
Problems corrected:<br>

<ol>
  <li>The INSTALL file now include special instructions for Slackware
  users.</li>
  <li>The bogons file has been updated.</li>
  <li>Service names are replaced by port numbers in /etc/shorewall/tos.</li>
  <li>A typo in the install.sh file that caused an error during a new install
    has been corrected.</li>
</ol>
New Features:<br>

<ol>
  <li>The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_Beta4"></a>11/19/2004 -
Shorewall 2.2.0 Beta 4<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>A cut and paste error resulted in some nonsense in the description of
    the IPSEC column in /etc/shorewall/masq.</li>
  <li>A typo in /etc/shorewall/rules has been corrected.</li>
  <li>The bogons file has been updated.</li>
  <li>The "shorewall add" command previously reported success but did nothing
    -- now it works.</li>
</ol>
New Features:<br>

<ol>
  <li>The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_Beta3"></a>11/09/2004 -
Shorewall 2.2.0 Beta 3<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>Missing '#' in the rfc1918 file has been corrected.</li>
  <li>The INSTALL file now includes special instructions for Slackware
  users.</li>
</ol>
New Features:<br>

<ol>
  <li>In CLASSIFY rules (/etc/shorewall/tcrules), an interface name may now
    appear in the DEST column as in:<br>

    <pre>        #MARK/      SOURCE       DEST      PROTO     PORT(S)<br>
        #CLASSIFY<br>
        1:30        -            eth0      tcp       25</pre>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0_Beta2"></a>11/02/2004 -
Shorewall 2.2.0 Beta 2<br>
<br>
</span> Problems Corrected:<br>

<ol>
  <li>The "shorewall check" command results in the (harmless) error
    message:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /usr/share/shorewall/firewall:
    line 2753:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    check_dupliate_zones: command not found<br>
    <br>
  </li>
  <li>The AllowNTP standard action now allows outgoing responses to
    broadcasts.</li>
  <li>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.</li>
</ol>
New Features:<br>

<ol>
  <li>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.<br>
  </li>
</ol>
<span style="font-weight: bold;"><a name="2_0_10"></a>10/25/2004 - Shorewall
2.0.10<br>
</span> <br>
Problems Corrected:<br>

<ol>
  <li>The GATEWAY column was previously ignored in 'pptpserver' entries in
    /etc/shorewall/tunnels.</li>
  <li>When log rule numbers are included in the LOGFORMAT, duplicate rule
    numbers could previously be generated.</li>
  <li>The /etc/shorewall/tcrules file now includes a note to the effect that
    rule evaluation continues after a match.</li>
  <li>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.<br>
  </li>
</ol>
New Features:<br>

<ol>
  <li>The "shorewall status" command has been enhanced to include the values
    of key /proc settings:<br>
    <br>
    Example from a two-interface firewall:<br>
    <br>
    /proc<br>
    <br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/ip_forward = 1<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/all/proxy_arp = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/all/arp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/all/rp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/default/proxy_arp = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/default/arp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/default/rp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth0/arp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth0/rp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth1/arp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth1/rp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/lo/proxy_arp = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/lo/arp_filter = 0<br>
    &nbsp;&nbsp; /proc/sys/net/ipv4/conf/lo/rp_filter = 0<br>
  </li>
</ol>
<br>
<span style="font-weight: bold;"><a name="2_2_0_Beta1"></a>10/24/2004 -
Shorewall 2.2.0 Beta1<br>
<br>
</span> The first beta in the 2.2 series is now available. Download location
is:<br>
<br>


<div style="margin-left: 40px;">
<a
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
<a target="_top"
href="ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
</div>

<p>The features available in this release and the migration considerations
are covered in the <a
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1/releasenotes.txt">release
notes</a>. Highlights include:<br>
</p>
<ol>
  <li>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.</li>
  <li>Support for the 2.6 Kernel's native IPSEC implementation is now
    available.</li>
  <li>Support for ipp2p is included.</li>
  <li>Support for the iptables CONNMARK facility is now included in
  Shorewall.</li>
  <li>A new LOGALLNEW option facilitates problem analysis.</li>
  <li>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 <span style="font-weight: bold;">shorewall [re]start</span>.</li>
  <li>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.</li>
  <li>Accepting of source routing and martian logging may now be
    enabled/disabled on each interface.</li>
  <li>Shorewall now supports the CLASSIFY iptable target.</li>
</ol>

<p><span style="font-weight: bold;"><a name="2_0_9"></a>9/23/2004 - Shorewall
2.0.9<br>
</span><br>
Problems Corrected:<br>
</p>
<ol>
  <li>Previously, an empty PROTO column or a value of "all" in that column
    would cause errors when processing the /etc/shorewall/tcrules file.</li>
</ol>
New Features:<br>

<ol>
  <li>The "shorewall status" command now includes the output of "brctl show"
    if the bridge tools are installed.<br>
  </li>
</ol>

<p><a name="SupportChange"><b>9/20/2004 &acirc;&#x80;&#x93; Change in
Shorewall Support</b></a></p>

<p style="">Friends,</p>

<p style="">The demands that my job and my personal life are currently
placing on me are such that supporing Shorewall to the extent that I have
been doing is just not possible any more.</p>

<p style="">I will continue to be active on the development list and will
continue to develop Shorewall if at all possible.</p>

<p style="">I will also continue to read the user's list and will help with
problems that interest me. But I am no longer going to hop on every problem
as soon as I see it.</p>

<p style="">This change means that I'm going to have to depend on you folks
to help each other; I'm confident that we can make this work.</p>

<p><a name="2_0_8"></a><b>8/22/2004 - Shorewall 2.0.8<br>
</b><br>
Problems Corrected:</p>
<ol>
  <li><p>Entries in the USER/GROUP column of an action file (made from
    action.template) may be ignored or cause odd errors.</p>
  </li>
</ol>

<p><a name="2_0_7"></a><b>7/29/2004 - Shorewall 2.0.7<br>
<br>
</b> Problems Corrected:</p>
<ol>
  <li><p style="margin-bottom: 0in;">The PKTTYPE option introduced in version
    2.0.6 is now used when generating rules to REJECT packets. Broadcast
    packets are silently dropped rather than being rejected with an ICMP
    (which is a protocol violation) and users whose kernels have broken
    packet type match support are likely to see messages reporting this
    violation. Setting PKTTYPE=No should cause these messages to cease.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Multiple interfaces with the 'blacklist'
    option no longer result in an error message at startup.</p>
  </li>
  <li><p>The following has been added to /etc/shorewall/bogons:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0&nbsp;&nbsp; RETURN<br>
    <br>
    This prevents the 'nobogons' option from logging DHCP 'DISCOVER'
    broadcasts.</p>
  </li>
</ol>

<p>New Features:</p>
<ol>
  <li><p>To improve supportability, the "shorewall status" command now
    includes IP and Route configuration information.<br>
    <br>
    &nbsp;&nbsp; Example:<br>
    <br>
    &nbsp;&nbsp; <font face="monospace">IP Configuration</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">1: lo: &lt;LOOPBACK,UP&gt; mtu 16436
    qdisc noqueue</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">link/loopback
    00:00:00:00:00:00 brd 00:00:00:00:00:00</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet 127.0.0.1/8
    brd 127.255.255.255 scope host lo</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet6 ::1/128 scope
    host</font><br>
    &nbsp;&nbsp; <font face="monospace">2: eth0:
    &lt;BROADCAST,MULTICAST,PROMISC,UP&gt; mtu 1500 qdisc pfifo_fast qlen
    1000</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">link/ether
    00:a0:c9:15:39:78 brd ff:ff:ff:ff:ff:ff</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet6
    fe80::2a0:c9ff:fe15:3978/64 scope link</font><br>
    &nbsp;&nbsp; <font face="monospace">3: eth1:
    &lt;BROADCAST,MULTICAST,PROMISC,UP&gt; mtu 1500 qdisc pfifo_fast qlen
    1000</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">link/ether
    00:a0:c9:a7:d7:bf brd ff:ff:ff:ff:ff:ff</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet6
    fe80::2a0:c9ff:fea7:d7bf/64 scope link</font><br>
    &nbsp;&nbsp; <font face="monospace">5: sit0@NONE: &lt;NOARP&gt; mtu 1480
    qdisc noop</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">link/sit 0.0.0.0
    brd 0.0.0.0</font><br>
    &nbsp;&nbsp; <font face="monospace">6: eth2:
    &lt;BROADCAST,MULTICAST,PROMISC,UP&gt; mtu 1500 qdisc pfifo_fast qlen
    1000</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">link/ether
    00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet6
    fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
    &nbsp;&nbsp; <font face="monospace">7: br0:
    &lt;BROADCAST,MULTICAST,NOTRAILERS,UP&gt; mtu 1500 qdisc
    noqueue</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">link/ether
    00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet 192.168.1.3/24
    brd 192.168.1.255 scope global br0</font><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet6
    fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">Routing Rules</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">0:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from
    all lookup local</font><br>
    &nbsp;&nbsp; <font face="monospace">32765:&nbsp; from all
    fwmark&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ca lookup www.out</font><br>
    &nbsp;&nbsp; <font face="monospace">32766:&nbsp; from all lookup
    main</font><br>
    &nbsp;&nbsp; <font face="monospace">32767:&nbsp; from all lookup
    default</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">Table local:</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">broadcast 192.168.1.0 dev br0&nbsp;
    proto kernel&nbsp; scope link&nbsp; src 192.168.1.3</font><br>
    &nbsp;&nbsp; <font face="monospace">broadcast 127.255.255.255 dev
    lo&nbsp; proto kernel&nbsp; scope link&nbsp; src 127.0.0.1</font><br>
    &nbsp;&nbsp; <font face="monospace">local 192.168.1.3 dev br0&nbsp; proto
    kernel&nbsp; scope host&nbsp; src 192.168.1.3</font><br>
    &nbsp;&nbsp; <font face="monospace">broadcast 192.168.1.255 dev br0&nbsp;
    proto kernel&nbsp; scope link&nbsp; src 192.168.1.3</font><br>
    &nbsp;&nbsp; <font face="monospace">broadcast 127.0.0.0 dev lo&nbsp;
    proto kernel&nbsp; scope link&nbsp; src 127.0.0.1</font><br>
    &nbsp;&nbsp; <font face="monospace">local 127.0.0.1 dev lo&nbsp; proto
    kernel&nbsp; scope host&nbsp; src 127.0.0.1</font><br>
    &nbsp;&nbsp; <font face="monospace">local 127.0.0.0/8 dev lo&nbsp; proto
    kernel&nbsp; scope host&nbsp; src 127.0.0.1</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">Table www.out:</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">default via 192.168.1.3 dev
    br0</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">Table main:</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">192.168.1.0/24 dev br0&nbsp; proto
    kernel&nbsp; scope link&nbsp; src 192.168.1.3</font><br>
    &nbsp;&nbsp; <font face="monospace">default via 192.168.1.254 dev
    br0</font><br>
    <br>
    &nbsp;&nbsp; <font face="monospace">Table default:</font></p>
  </li>
</ol>

<p><a name="2_0_6"></a><b>7/16/2004 - Shorewall 2.0.6<br>
<br>
</b> Problems Corrected:</p>
<ul>
  <li><p style="margin-bottom: 0in;">Some users have reported the packet type
    match option in iptables/Netfilter failing to match certain broadcast
    packets. The result is that the firewall log shows a lot of broadcast
    packets.<br>
    <br>
    Other users have complained of the following message when starting
    Shorewall:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    modprobe: cant locate module ipt_pkttype<br>
    <br>
    Users experiencing either of these problems can use PKTTYPE=No in
    shorewall.conf to cause Shorewall to use IP address filtering of
    broadcasts rather than packet type.</p>
  </li>
  <li><p style="margin-bottom: 0in;">The shorewall.conf and zones file are no
    longer given execute permission by the installer script.</p>
  </li>
  <li><p>ICMP packets that are in the INVALID state are now dropped by the
    Reject and Drop default actions. They do so using the new 'dropInvalid'
    builtin action.</p>
  </li>
</ul>

<p><a name="2_0_5"></a><b>7/10/2004 - Shorewall 2.0.5<br>
</b><br>
Problems Corrected:</p>
<ul>
  <li><p style="margin-bottom: 0in;">If DISABLE_IPV6=Yes in shorewall.conf
    then harmless error messages referring to $RESTOREBASE are generated
    during <b>shorewall stop</b>.</p>
  </li>
  <li><p>An anachronistic comment concerning a mangle option has been removed
    from shorewall.conf.</p>
  </li>
</ul>

<p><a name="2_0_4"></a><b>7/06/2004 - Shorewall 2.0.4<br>
</b><br>
Problems Corrected:</p>
<ul>
  <li><p>Rules with $FW as the source zone and that specify logging can cause
    "shorewall start" to fail.</p>
  </li>
</ul>

<p><a name="Release_Model"></a><b>7/03/2004 - New Shorewall Release Model<br>
<br>
</b> Effective today, Shorewall is adopting a new release model which takes
ideas from the one used in the Linux Kernel and from the release model for
Postfix.</p>
<ol>
  <li><p style="margin-bottom: 0in;">Releases continue to have a three-level
    identification <i>x.y.z</i> (e.g., 2.0.3).</p>
  </li>
  <li><p style="margin-bottom: 0in;">The first two levels (<i>x.y)</i>
    designate the <i>Major Release Number</i> (e.g., 2.0)</p>
  </li>
  <li><p style="margin-bottom: 0in;">The third level (<i>z</i>) designates
    the <i>Minor Release Number</i>.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Even numbered major releases (e.g.,
    <i>1.4, 2.0, 2.2, ...)</i> are <i>Stable Releases</i>. No new features
    are added to stable releases and new minor releases of a stable release
    will only contain bug fixes. Installing a new minor release for the major
    release that you are currently running involves no migration issues (for
    example, if you are running 1.4.10 and I release 1.4.11, your current
    configuration is 100% compatible with the new release).</p>
  </li>
  <li><p style="margin-bottom: 0in;">Support is available through the <a
    href="http://lists.shorewall.net/">Mailing List</a> for the two most
    recent Stable Releases.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Odd numbered major releases (e.g., 2.1,
    2.3, ...) are <i>Development Releases</i>. Development releases are where
    new functionality is introduced. Documentation for new features will be
    available but it may not be up to the standards of the stable release
    documentation. Sites running Development Releases should be prepared to
    play an active role in testing new features. Bug fixes and problem
    resolution for the development release take a back seat to support of the
    stable releases. Problem reports for the current development release
    should be sent to the <a
    href="mailto:shorewall-devel@lists.shorewall.net">Shorewall Development
    Mailing List</a>.</p>
  </li>
  <li><p style="margin-bottom: 0in;">When the level of functionality of the
    current development release is judged adaquate, the Beta period for a new
    Stable release will begin. Beta releases have identifications of the form
    <i>x.y.0-BetaN</i> where <i>x.y</i> is the number of the next Stable
    Release and <i>N</i>=1,2,3... . Betas are expected to occur rougly once
    per year. Beta releases may contain new functionality not present in the
    previous beta release (e.g., 2.2.0-Beta4 may contain functionality not
    present in 2.2.0-Beta3). When I'm confident that the current Beta release
    is stable, I will release the first <i>Release Candidate.</i> Release
    candidates have identifications of the form <i>x.y.0-RCn</i> where
    <i>x.y</i> is the number of the next Stable Release and <i>n</i>=1,2,3...
    . Release candidates contain no new functionailty -- they only contain
    bug fixes. When the stability of the current release candidate is judged
    to be sufficient then that release candidate will be released as the new
    stable release (e.g., 2.2.0). At that time, the new stable release and
    the prior stable release are those that are supported.</p>
  </li>
  <li><p style="margin-bottom: 0in;">What does it mean for a major release to
    be <i>supported?</i> It means that I will answer questions about the
    release and that if a bug is found, I will fix the bug and include the
    fix in the next minor release.</p>
  </li>
  <li><p>Between minor releases, bug fixes will continue to be made available
    through the Errata page for each major release.</p>
  </li>
</ol>

<p>The immediate implications of this change are as follows:</p>
<ol>
  <li><p style="margin-bottom: 0in;">The functionality of the 2.0 major
    release is frozen at the level of minor release 2.0.3.</p>
  </li>
  <li><p style="margin-bottom: 0in;">The two major releases currently
    supported are 1.4 and 2.0.</p>
  </li>
  <li><p style="margin-bottom: 0in;">I will be opening the 2.1 development
    release shortly with the release of 2.1.0.</p>
  </li>
  <li><p>Bug-fix releases with identifications of the form <i>x.y.zX</i>
    where X=a,b,c,... (e.g., 2.0.3c) will not be seen in the future.</p>
  </li>
</ol>

<p><a name="2_0_3c"></a><b>7/02/2004 - Shorewall 2.0.3c<br>
<br>
</b> Problems Corrected<b>:</b></p>
<ol>
  <li><p style="margin-bottom: 0in;">Error messages regarding $RESTOREBASE
    occur during <b>shorewall stop</b></p>
  </li>
  <li><p>If CLEAR_TC=Yes in <tt>shorewall.conf</tt>, <b>shorewall stop</b>
    fails without removing the lock file.</p>
  </li>
</ol>

<p><a name="2_0_3b"></a><b><br>
6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g<br>
<br>
</b> Problems Corrected:</p>
<ol>
  <li><p style="margin-bottom: 0in;">The security vulnerability fix released
    in Shorewall 2.0.3a failed under Slackware 9.1.</p>
  </li>
  <li><p>The security vulnerability fix released in Shorewall 2.0.3a failed
    if mktemp was not installed.</p>
  </li>
</ol>

<p><a name="2_0_3a"></a><b>6/28/2004 - Shorewall 2.0.3a and Shorewall
1.4.10f<br>
<br>
</b> Problems Corrected:</p>
<ol>
  <li><p style="margin-bottom: 0in;">Javier Fern&Atilde;&iexcl;ndez-Sanguino
    Pe&Atilde;&plusmn;a has discovered an exploitable vulnerability in the
    way that Shorewall handles temporary files and directories. The
    vulnerability can allow a non-root user to cause arbitrary files on the
    system to be overwritten. LEAF Bering and Bering uClibc users are
    generally not at risk due to the fact that LEAF boxes do not typically
    allow logins by non-root users.</p>
  </li>
  <li><p>(2.0.3a only) A non-empty DEST entry in /etc/shorewall/tcrules will
    generate an error and Shorewall fails to start.</p>
  </li>
</ol>

<p style="margin-left: 0.42in;">Note:: Slackware users may need the
'functions' file from CVS (STABLE/ project for 1.4.10f and STABLE2/ project
for 2.0.3a) to prevent startup errors with these versions installed. These
updatged files are also available from the Errata (<a
href="errata.htm">2.0,</a> <a href="1.4/errata.htm">1.4</a>).</p>

<p><a name="2_0_3"></a><b>6/23/2004 - Shorewall 2.0.3<br>
<br>
</b> Problems Corrected:</p>
<ol>
  <li><p style="margin-bottom: 0in;">The 'firewall' script is not purging
    temporary restore files in /var/lib/shorewall. These files have names of
    the form "restore-nnnnn".</p>
  </li>
  <li><p style="margin-bottom: 0in;">The /var/lib/shorewall/restore script
    did not load the kernel modules specified in /etc/shorewall/modules.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Specifying a null common action in
    /etc/shorewall/actions (e.g., :REJECT) results in a startup error.</p>
  </li>
  <li><p style="margin-bottom: 0in;">If /var/lib/shorewall does not exist,
    shorewall start fails.</p>
  </li>
  <li><p style="margin-bottom: 0in;">DNAT rules with a dynamic source zone
    don't work properly. When used, these rules cause the rule to be checked
    against ALL input, not just input from the designated zone.</p>
  </li>
  <li><p style="margin-bottom: 0in;">The install.sh script reported
    installing some files in /etc/shorewall when the files were actually
    installed in /usr/share/shorewall.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Shorewall checks netfilter capabilities
    before loading kernel modules. Hence if kernel module autoloading isn't
    enabled, the capabilities will be misdetected.</p>
  </li>
  <li><p style="margin-bottom: 0in;">The 'newnotsyn' option in
    /etc/shorewall/hosts has no effect.</p>
  </li>
  <li><p style="margin-bottom: 0in;">The file /etc/init.d/shorewall now gets
    proper ownership when the RPM is built by a non-root user.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Rules that specify bridge ports in both
    the SOURCE and DEST columns no longer cause "shorewall start" to fail.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Comments in the rules file have been
    added to advise users that "all" in the SOURCE or DEST column does not
    affect intra-zone traffic.</p>
  </li>
  <li><p>With BLACKLISTNEWONLY=Yes, ICMP packets with state INVALID are now
    passed through the blacklisting chains. Without this change, it is not
    possible to blacklist hosts that are mounting certain types of ICMP-based
    DOS attacks.</p>
  </li>
</ol>

<p>Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:</p>
<ol>
  <li><p>The 'dropNonSyn' standard builtin action has been replaced with the
    'dropNotSyn' standard builtin action. The old name can still be used but
    will generate a warning.</p>
  </li>
</ol>

<p>New Features:</p>
<ol>
  <li><p style="margin-bottom: 0in;">Shorewall now supports multiple saved
    configurations.</p>
    <ol>
      <li><p style="margin-bottom: 0in;">The default saved configuration
        (restore script) in /var/lib/shorewall is now specified using the
        RESTOREFILE option in shorewall.conf. If this variable isn't set then
        to maintain backward compatibility, 'restore' is assumed.<br>
        <br>
        The value of RESTOREFILE must be a simple file name; no slashes ("/")
        may be included.</p>
      </li>
      <li><p style="margin-bottom: 0in;">The "save" command has been extended
        to be able to specify the name of a saved configuration.<br>
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        shorewall save [ &lt;file name&gt; ]<br>
        <br>
        The current state is saved to /var/lib/shorewall/&lt;file name&gt;.
        If no &lt;file name&gt; is given, the configuration is saved to the
        file determined by the RESTOREFILE setting.</p>
      </li>
      <li><p style="margin-bottom: 0in;">The "restore" command has been
        extended to be able to specify the name of a saved configuration:<br>
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall
        restore [ &lt;file name&gt; ]<br>
        <br>
        The firewall state is restored from /var/lib/shorewall/&lt;file
        name&gt;. If no &lt;file name&gt; is given, the firewall state is
        restored from the file determined by the RESTOREFILE setting.</p>
      </li>
      <li><p style="margin-bottom: 0in;">The "forget" command has changed.
        Previously, the command unconditionally removed the
        /var/lib/shorewall/save file which records the current dynamic
        blacklist. The "forget" command now leaves that file alone.<br>
        <br>
        Also, the "forget" command has been extended to be able to specify
        the name of a saved configuration:<br>
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        shorewall forget [ &lt;file name&gt; ]<br>
        <br>
        The file /var/lib/shorewall/&lt;file name&gt; is removed. If no
        &lt;file name&gt; is given, the file determined by the RESTOREFILE
        setting is removed.</p>
      </li>
      <li><p style="margin-bottom: 0in;">The "shorewall -f start" command
        restores the state from the file determined by the RESTOREFILE
        setting.</p>
      </li>
    </ol>
  </li>
  <li><p style="margin-bottom: 0in;">"!" is now allowed in accounting
    rules.</p>
  </li>
  <li><p style="margin-bottom: 0in;">Interface names appearing within the
    configuration are now verified. Interface names must match the name of an
    entry in /etc/shorewall/interfaces (or if bridging is enabled, they must
    match the name of an entry in /etc/shorewall/interfaces or the name of a
    bridge port appearing in /etc/shorewall/hosts).</p>
  </li>
  <li><p style="margin-bottom: 0in;">A new 'rejNotSyn' built-in standard
    action has been added. This action responds to "New not SYN" packets with
    an RST.<br>
    <br>
    The 'dropNonSyn' action has been superceded by the new 'dropNotSyn'
    action. The old name will be accepted until the next major release of
    Shorewall but will generate a warning.<br>
    <br>
    Several new logging actions involving "New not SYN" packets have been
    added:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; logNewNotSyn&nbsp; -- logs the
    packet with disposition = LOG<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dLogNewNotSyn -- logs the
    packet with disposition = DROP<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rLogNewNotSyn -- logs the
    packet with disposition = REJECT<br>
    <br>
    The packets are logged at the log level specified in the LOGNEWNOTSYN
    option in shorewall.conf. If than option is empty or not specified, then
    'info' is assumed.<br>
    <br>
    Examples (In all cases, set NEWNOTSYN=Yes in shorewall.conf):</p>
    <ol>
      <li><p style="margin-bottom: 0in;">To simulate the behavior of
        NEWNOTSYN=No:</p>
        <ol>
          <li><p style="margin-bottom: 0in;">Add 'NoNewNotSyn' to
            /etc/shorewall/actions.</p>
          </li>
          <li><p>Create /etc/shorewall/action.NoNewNotSyn containing:<br>
            <br>
            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            dLogNotSyn<br>
            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            dropNotSyn</p>
          </li>
          <li><p>Early in your rules file, place:<br>
            <br>
            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            NoNewNotSyn&nbsp;&nbsp; all&nbsp;&nbsp;
            all&nbsp;&nbsp;&nbsp;&nbsp; tcp</p>
          </li>
        </ol>
      </li>
      <li><p style="margin-bottom: 0in;">Drop 'New not SYN' packets from the
        net only. Don't log them:</p>
        <ol>
          <li><p>Early in your rules file, place:<br>
            <br>
            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            dropNotSyn&nbsp;&nbsp;&nbsp;
            net&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all&nbsp;&nbsp;
            tcp</p>
          </li>
        </ol>
      </li>
    </ol>
  </li>
  <li><p>Slackware users no longer have to modify the install.sh script
    before installation. Tuomo Soini has provided a change that allows the
    INIT and FIREWALL variables to be specified outside the script as in:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DEST=/etc/rc.d INIT=rc.firewall
    ./install.sh</p>
  </li>
</ol>

<p><b>6/3/2004 - Shorewall 2.0.2f<br>
</b></p>

<p>Fixes one problem:<br>
</p>
<ol>
  <li>Versions 2.0.2d and 2.0.2e fail to load kernel modules unless
    MODULE_SUFFIX is set in shorewall.conf<br>
  </li>
</ol>

<p><b>6/2/2004 - Shorewall 2.0.2e<br>
</b></p>

<p>One problem corrected:<br>
</p>
<ol>
  <li>LOG rules within an action generate two Netfilter logging rules.<br>
  </li>
</ol>

<p><b>5/28/2004 - Shorewall 2.0.2d<br>
</b><br>
One problem corrected:<br>
</p>
<ol>
  <li>Shorewall was checking capabilities before loading kernel modules.
    Consequently, if kernel module autoloading was disabled, the capabilities
    were mis-detected.<br>
  </li>
</ol>

<p><b>5/21/2004 - Shorewall 2.0.2c</b></p>
One problem corrected:<br>

<ol>
  <li>&nbsp;DNAT rules with a dynamic source zone don't work properly. When
    used, these rules cause the rule to be checked against ALL input,&nbsp;
    not just input from the designated zone.<br>
  </li>
</ol>

<p><b>5/18/2004 - Shorewall 2.0.2b</b><b>&nbsp;</b></p>

<p>Corrects two problems:</p>
<ol>
  <li>Specifying a null common action in /etc/shorewall/actions (e.g.,
    :REJECT) results in a startup error.<br>
    <br>
  </li>
  <li>If /var/lib/shorewall does not exist, shorewall start fails.<br>
  </li>
</ol>

<p><b>5/15/2004 - Shorewall 2.0.2a</b><br>
</p>

<p>Corrects two problems:<br>
</p>
<ol>
  <li>Temporary restore files were not being removed from /var/lib/shorewall.
    These files have names of the form 'restore-nnnnn'.&nbsp; You can remove
    files that have accumulated with the command:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;rm -f /var/lib/shorewall/restore-[0-9]*<br>
    <br>
  </li>
  <li>The restore script did not load kernel modules. The result was that
    after a cold load, applications like FTP and IRC DCC didn't work.<br>
    <br>
    To correct:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;1) Install 2.0.2a<br>
    &nbsp;&nbsp;&nbsp;&nbsp;2) "shorewall restart"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;3) "shorewall save"</li>
</ol>

<p><b>5/13/2004 - Shorewall 2.0.2</b><b>&nbsp;</b></p>

<p>Problems Corrected since 2.0.1<br>
</p>
<ol>
  <li>The /etc/init.d/shorewall script installed on Debian by install.sh
    failed silently due to a missing file (/usr/share/shorewall/wait4ifup).
    That file is not part of the normal Shorewall distribution and is
    provided by the Debian maintainer.</li>
  <li>A meaningless warning message out of the proxyarp file processing has
    been eliminated.</li>
  <li>The "shorewall delete" command now correctly removes all dynamic rules
    pertaining to the host(s) being deleted. Thanks to Stefan Engel for this
    correction.</li>
</ol>
Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:<br>

<ol>
  <li>Extension Scripts -- In order for extension scripts to work properly
    with the new iptables-save/restore integration (see New Feature 1 below),
    some change may be required to your extension scripts. If your extension
    scripts are executing commands other than iptables then those commands
    must also be written to the restore file (a temporary file in
    /var/lib/shorewall that is renamed /var/lib/shorewall/restore-base at the
    end of the operation).<br>
    <br>
    The following functions should be of help:<br>
    <br>
    A. save_command() -- saves the passed command to the restore file.<br>
    <br>
    &nbsp;&nbsp;&nbsp; Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; save_command echo Operation
    Complete<br>
    <br>
    &nbsp;&nbsp; That command would simply write "echo Operation Complete" to
    the restore file.<br>
    <br>
    B. run_and_save_command() -- saves the passed command to the restore file
    then executes it. The return value is the exit status of the command.<br>
    <br>
    &nbsp; &nbsp; Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; run_and_save_command "echo 1 &gt;
    /proc/sys/net/ipv4/icmp_echo_ignore_all"<br>
    <br>
    &nbsp;&nbsp;&nbsp; Note that as in this example, when the command
    involves file redirection then the entire command must be enclosed in
    quotes. This applies to all of the functions described here.<br>
    <br>
    C. ensure_and_save_command() -- runs the passed command. If the command
    fails, the firewall is restored to it's prior saved state and the
    operation is terminated. If the command succeeds, the command is written
    to the restore file.<br>
    <br>
  </li>
  <li>Dynamic Zone support -- If you don't need to use the "shorewall add"
    and "shorewall delete commands, you should set DYNAMIC_ZONES=No in
    /etc/shorewall/shorewall.conf.</li>
</ol>
New Features:<br>

<ol>
  <li>Shorewall has now been integrated with iptables-save/iptables-restore
    to provide very fast start and restart. The elements of this integration
    are as follows:<br>
    <br>
    a) The 'shorewall save' command now saves the current configuration in
    addition to the current dynamic blacklist. If you have dynamic zones, you
    will want to issue 'shorewall save' when the zones are empty or the
    current contents of the zones will be restored by the 'shorewall restore'
    and 'shorewall -f start' commands.<br>
    <br>
    b) The 'shorewall restore' command has been added. This command restores
    the configuration at the time of the last 'save'.<br>
    <br>
    c) The -f (fast) option has been added to 'shorewall start'. When
    specified (e.g. 'shorewall -f start'), shorewall will perform a
    'shorewall restore' if there is a saved configuration. If there is no
    saved configuration, a normal 'shorewall start' is performed.<br>
    <br>
    d) The /etc/init.d/shorewall script now translates the 'start' command
    into 'shorewall -f start' so that fast restart is possible.<br>
    <br>
    e) When a state-changing command encounters an error and there is current
    saved configuration, that configuration will be restored (currently, the
    firewall is placed in the 'stopped' state).<br>
    <br>
    f) If you have previously saved the running configuration and want
    Shorewall to discard it, use the 'shorewall forget' command. WARNING:
    iptables 1.2.9 is broken with respect to iptables-save; if your kernel
    has connection tracking match support, you must patch iptables 1.2.9 with
    the iptables patch availale from the Shorewall errata page.<br>
    <br>
  </li>
  <li>The previous implementation of dynamic zones was difficult to maintain.
    I have changed the code to make dynamic zones optional under the control
    of the DYNAMIC_ZONES option in /etc/shorewall/shorewall.conf.<br>
    <br>
  </li>
  <li>In earlier Shorewall 2.0 releases, Shorewall searches in order the
    following directories for configuration files.<br>
    <br>
    a) The directory specified in a 'try' command or specified using the -c
    option.<br>
    b) /etc/shorewall<br>
    c) /usr/share/shorewall<br>
    <br>
    In this release, the CONFIG_PATH option is added to shorewall.conf.
    CONFIG_PATH contains a list of directory names separated by colons (":").
    If not set or set to a null value (e.g., CONFIG_PATH="") then
    "CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed. Now
    Shorewall searches for shorewall.conf according to the old rules and for
    other configuration files as follows:<br>
    <br>
    a) The directory specified in a 'try' command or specified using the -c
    option.<br>
    b) Each directory in $CONFIG_PATH is searched in sequence.<br>
    <br>
    In case it is not obvious, your CONFIG_PATH should include
    /usr/share/shorewall and your shorewall.conf file must be in the
    directory specified via -c or in a try command, in /etc/shorewall or in
    /usr/share/shorewall.<br>
    <br>
    For distribution packagers, the default CONFIG_PATH is set in
    /usr/share/shorewall/configpath. You can customize this file to have a
    default that differs from mine.<br>
    <br>
  </li>
  <li>Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL column
    would only take effect if the ALL INTERFACES column also contained Yes or
    yes. Now, the LOCAL columns contents are treated independently of the
    contents of the ALL INTERFACES column.<br>
    <br>
  </li>
  <li>The folks at Mandrake have created yet another kernel module naming
    convention (module names end in "ko.gz"). As a consequence, beginning
    with this release, if MODULE_SUFFIX isn't specified in shorewall.conf,
    then the default value is "o gz ko o.gz ko.gz".<br>
    <br>
  </li>
  <li>An updated bogons file is included in this release.<br>
    <br>
  </li>
  <li>In /etc/shorewall/rules and in action files generated from
    /usr/share/shorewall/action.template, rules that perform logging can
    specify an optional "log tag". A log tag is a string of alphanumeric
    characters and is specified by following the log level with ":" and the
    log tag.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT:info:ftp
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 21<br>
    <br>
    The log tag is appended to the log prefix generated by the LOGPREFIX
    variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
    prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate
    "Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum
    length of a log prefix supported by iptables is 29 characters; if a
    larger prefix is generated, Shorewall will issue a warning message and
    will truncate the prefix to 29 characters.<br>
    <br>
  </li>
  <li>A new "-q" option has been added to /sbin/shorewall commands. It causes
    the start, restart, check and refresh commands to produce much less
    output so that warning messages are more visible (when testing this
    change, I discovered a bug where a bogus warning message was being
    generated).<br>
    <br>
  </li>
  <li>Shorewall now uses 'modprobe' to load kernel modules if that utility is
    available in the PATH; otherwise, 'insmod' is used.<br>
    <br>
  </li>
  <li>It is now possible to restrict entries in the /etc/shorewall/masq file
    to particular protocols and destination port(s). Two new columns (PROTO
    and PORT(S)) have been added to the file.<br>
    <br>
    Example:<br>
    <br>
    You want all outgoing SMTP traffic entering the firewall on eth1 to be
    sent from eth0 with source IP address 206.124.146.177. You want all other
    outgoing traffic from eth1 to be sent from eth0 with source IP address
    206.124.146.176.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp;
    eth1&nbsp;&nbsp;&nbsp; 206.124.146.177 tcp&nbsp;&nbsp;&nbsp;&nbsp; 25<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp;
    eth1&nbsp;&nbsp;&nbsp; 206.124.146.176<br>
    <br>
    THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!<br>
    <br>
    Assuming that 10.0.0.0/8 is the only host/network connected to eth1, the
    progress message at "shorewall start" would be:<br>
    <br>
    &nbsp;&nbsp;&nbsp; Masqueraded Networks and Hosts:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To 0.0.0.0/0 (tcp 25) from
    10.0.0.0/8 through eth0 using 206.124.146.177<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To 0.0.0.0/0 (all) from 10.0.0.0/8
    through eth0 using 206.124.146.176<br>
    <br>
  </li>
  <li>Two new actions are available in the /etc/shorewall/rules file.<br>
    <br>
    &nbsp;&nbsp;&nbsp; ACCEPT+&nbsp;&nbsp;&nbsp; -- Behaves like ACCEPT with
    the exception that it exempts matching connections from subsequent
    DNAT[-] and REDIRECT[-] rules.<br>
    &nbsp;&nbsp;&nbsp; NONAT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Exempts
    matching connections from subsequent DNAT[-] and REDIRECT[-] rules.<br>
    <br>
  </li>
  <li>A new extension script 'initdone' has been added. This script is
    invoked at the same point as the 'common' script was previously and is
    useful for users who mis-used that script under Shorewall 1.x (the script
    was intended for adding rules to the 'common' chain but many users
    treated it as a script for adding rules before Shorewall's).<br>
    <br>
  </li>
  <li>Installing/Upgrading Shorewall on Slackware has been improved.
    Slackware users must use the tarball and must modify settings in the
    install.sh script before running it as follows:<br>
    <br>
    &nbsp;&nbsp;&nbsp; DEST="/etc/rc.d"<br>
    &nbsp;&nbsp;&nbsp; INIT="rc.firewall"<br>
    <br>
    Thanks to Alex Wilms for helping with this change.</li>
</ol>

<p><b>4/17/2004 - Presentation at LinuxFest NW</b><b><br>
</b></p>
Today I gave a presentation at LinuxFest NW in Bellingham. The presentation
was entitled "<a
href="http://lists.shorewall.net/Shorewall_and_the_Enterprise.htm"
target="_blank">Shorewall and the Enterprise</a>" and described the history
of Shorewall and gave an overview of its features. 

<p><b>4/5/2004 - Shorewall 2.0.1</b><br>
</p>
Problems Corrected since 2.0.0<br>
<br>

<ol>
  <li>Using actions in the manner recommended in the documentation results in
    a Warning that the rule is a policy.</li>
  <li>When a zone on a single interface is defined using
    /etc/shorewall/hosts, superfluous rules are generated in the
    &lt;zone&gt;_frwd chain.</li>
  <li>Thanks to Sean Mathews, a long-standing problem with Proxy ARP and
    IPSEC has been corrected. Thanks Sean!!!</li>
  <li>The "shorewall show log" and "shorewall logwatch" commands incorrectly
    displayed type 3 ICMP packets.<br>
  </li>
</ol>
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:<br>
<br>

<ol>
  <li>The function of 'norfc1918' is now split between that option and a new
    'nobogons' option.<br>
    <br>
    The rfc1918 file released with Shorewall now contains entries for only
    those three address ranges reserved by RFC 1918. A 'nobogons' interface
    option has been added which handles bogon source addresses (those which
    are reserved by the IANA, those reserved for DHCP auto-configuration and
    the class C test-net reserved for testing and documentation examples).
    This will allow users to perform RFC 1918 filtering without having to
    deal with out of date data from IANA. Those who are willing to update
    their /usr/share/shorewall/bogons file regularly can specify the
    'nobogons' option in addition to 'norfc1918'.<br>
    <br>
    The level at which bogon packets are logged is specified in the new
    BOGON_LOG_LEVEL variable in shorewall.conf. If that option is not
    specified or is specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon
    packets whose TARGET is 'logdrop' in /usr/share/shorewall/bogons are
    logged at the 'info' level.</li>
</ol>
New Features:<br>
<br>

<ol>
  <li>Support for Bridging Firewalls has been added. For details, see<br>
    <br>
    <a
    href="http://shorewall.net/bridge.html">http://shorewall.net/bridge.html</a><br>
    <br>
  </li>
  <li>Support for NETMAP has been added. NETMAP allows NAT to be defined
    between two network:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
    a.b.c.1&nbsp;&nbsp;&nbsp; -&gt; x.y.z.1<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    a.b.c.2&nbsp;&nbsp;&nbsp; -&gt; x.y.z.2<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    a.b.c.3&nbsp;&nbsp;&nbsp; -&gt; x.y.z.3<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>
    <br>
    &nbsp; <a
    href="http://shorewall.net/netmap.htm">http://shorewall.net/netmap.htm</a><br>
    <br>
  </li>
  <li>The /sbin/shorewall program now accepts a "-x" option to cause iptables
    to print out the actual packet and byte counts rather than abbreviated
    counts such as "13MB".<br>
    <br>
    Commands affected by this are:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    shorewall -x show [ &lt;chain&gt;[ &lt;chain&gt; ...] ]<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    shorewall -x show tos|mangle<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    shorewall -x show nat<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    shorewall -x status<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    shorewall -x monitor [ &lt;interval&gt; ]<br>
    <br>
  </li>
  <li>Shorewall now traps two common zone definition errors:<br>

    <ul>
      <li>Including the firewall zone in a /etc/shorewall/hosts record.</li>
      <li>Defining an interface for a zone in both /etc/shorewall/interfaces
        and /etc/shorewall/hosts.<br>
        <br>
      </li>
    </ul>
  </li>
  <li>In the second case, the following will appear during "shorewall
    [re]start" or "shorewall check":<br>
    <br>
    &nbsp;&nbsp; Determining Hosts in Zones...<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: Invalid zone definition for zone
    &lt;name of zone&gt;<br>
    &nbsp;&nbsp; Terminated<br>
    <br>
  </li>
  <li>To support bridging, the following options have been added to entries
    in /etc/shorewall/hosts:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; norfc1918<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nobogons<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; blacklist<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tcpflags<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nosmurfs<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; newnotsyn<br>
    <br>
    With the exception of 'newnotsyn', these options are only useful when the
    entry refers to a bridge port.<br>
    <br>
    &nbsp;&nbsp; Example:<br>
    <br>
    &nbsp;&nbsp; #ZONE&nbsp;&nbsp; HOST(S)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    OPTIONS<br>
    &nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;&nbsp; br0:eth0&nbsp;&nbsp;&nbsp;&nbsp;
    norfc1918,nobogons,blacklist,tcpflags,nosmurfs</li>
</ol>

<p><b>3/14/2004 - Shorewall 2.0.0b&nbsp;</b></p>
Corrects two problems:<br>

<ol>
  <li>Thanks to Sean Mathews, the long-standing problem with Proxy ARP and
    IPSEC has been eliminated!</li>
  <li>The default value of the ALL INTERFACES column in /etc/shorewall/nat is
    documented as 'No' but the default continued to be 'Yes' as it was in
    Shorewall 1.4.<br>
  </li>
</ol>

<p><b>3/14/2004 - Shorewall 2.0.0a&nbsp;</b></p>

<p>Corrects one problem:<br>
</p>
<ul>
  <li>Rules of the form:<br>
    <br>
    &lt;action&gt;&nbsp;&nbsp;&nbsp;&nbsp;
    zone1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; zone2<br>
    <br>
    generated a warning stating that the rule was a policy.<br>
  </li>
</ul>

<p><b>3/14/2004 - Shorewall 2.0.0</b> <b><br>
</b></p>

<p>Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February 23, 2004<br>
</p>

<p>Problems Corrected since 1.4.10<br>
</p>
<ol>
  <li>A blank USER/GROUP column in /etc/shorewall/tcrules no longer causes a
    [re]start error.</li>
  <li>The 'fgrep' utility is no longer required (caused startup problems on
    LEAF/Bering).</li>
  <li>The "shorewall add" command no longer inserts rules before checking of
    the blacklist.</li>
  <li>The 'detectnets' and 'routeback' options may now be used together with
    the intended effect.</li>
  <li>The following syntax previously produced an error:<br>
    <br>
    DNAT&nbsp; z1!z2,z3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; z4...<br>
  </li>
</ol>

<p>Problems Corrected since RC2<br>
<br>
</p>
<ol>
  <li>CONTINUE rules now work again.</li>
  <li>A comment in the rules file has been corrected.<br>
  </li>
</ol>

<p>Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:<br>
</p>
<ol>
  <li>The 'dropunclean' and 'logunclean' interface options are no longer
    supported. If either option is specified in /etc/shorewall/interfaces, an
    threatening message will be generated.</li>
  <li>The NAT_BEFORE_RULES option has been removed from shorewall.conf. The
    behavior of Shorewall is as if NAT_BEFORE_RULES=No had been specified. In
    other words, DNAT rules now always take precidence over one-to-one NAT
    specifications.</li>
  <li>The default value for the ALL INTERFACES column in /etc/shorewall/nat
    has changed. In Shorewall 1.*, if the column was left empty, a value of
    "Yes" was assumed. This has been changed so that a value of "No" is now
    assumed.</li>
  <li>The following files don't exist in Shorewall 2.0:<br>
    /etc/shorewall/common.def<br>
    /etc/shorewall/common<br>
    /etc/shorewall/icmpdef<br>
    /etc/shorewall/action.template (Moved to /usr/share/shorewall)<br>
    /etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).<br>
    <br>
    The /etc/shorewall/action file now allows an action to be designated as
    the "common" action for a particular policy type by following the action
    name with ":" and the policy (DROP, REJECT or ACCEPT).<br>
    <br>
    The file /usr/share/shorewall/actions.std has been added to define those
    actions that are released as part of Shorewall. In that file are two
    actions as follows:<br>
    <br>
    &nbsp;&nbsp;&nbsp; Drop:DROP<br>
    &nbsp;&nbsp; Reject:REJECT<br>
    <br>
    The "Drop" action is the common action for DROP policies while the
    "Reject" action is the default action for "REJECT" policies. These
    actions will be performed on packets prior to applying the DROP or REJECT
    policy respectively. In the first release, the difference between
    "Reject" and "Drop" is that "Reject" REJECTs SMB traffic while "Drop"
    silently drops such traffic.<br>
    <br>
    As described above, Shorewall allows a common action for ACCEPT policies
    but does not specify such an action in the default configuration.<br>
    <br>
    If for some reason, you don't wish to have a common DROP or REJECT
    action, just include :DROP or :REJECT respectively in your
    /etc/shorewall/actions file.<br>
    <br>
    The file /usr/share/shorewall/actions.std catalogs the standard actions
    and is processed prior to /etc/shorewall/actions. This causes a large
    number of actions to be defined. The files which define these aactions
    are also located in /usr/share/shorewall as is the he action template
    file (action.template).<br>
    <br>
    These actions may be used in the ACTION column of the rules column. So
    for example, to allow FTP from your loc zone to your firewall, you would
    place this rule in /etc/shorewall/rules:<br>
    <br>
    &nbsp; #ACTION&nbsp;&nbsp;&nbsp;&nbsp;
    SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DEST<br>
    &nbsp; AllowFTP&nbsp;&nbsp;&nbsp;&nbsp;
    loc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;
    &nbsp; &nbsp; fw<br>
    <br>
    If you want to redefine any of the Shorewall-defined actions, simply copy
    the appropriate action file from /usr/share/shorewall to /etc/shorewall
    and modify the copy as desired. Your modified copy will be used rather
    than the original one in /usr/share/shorewall.<br>
    <br>
    Note: The 'dropBcast' and 'dropNonSyn' actions are built into Shorewall
    and may not be changed.<br>
    <br>
    Beginning with version 2.0.0-Beta2, Shorewall will only create a chain
    for those actions that are actually used.<br>
    <br>
  </li>
  <li>The /etc/shorewall directory no longer contains a 'users' file or a
    'usersets' file. Similar functionality is now available using
    user-defined actions.<br>
    <br>
    Now, action files created by copying /usr/share/shorewall/action.template
    may specify a USER and or GROUP name/id in the final column just like in
    the rules file (see below). It is thus possible to create actions that
    control traffic from a list of users and/or groups.<br>
    <br>
    The last column in /etc/shorewall/rules is now labeled USER/GROUP and may
    contain:<br>
    <br>
    &nbsp;&nbsp;&nbsp; [!]&lt;user number&gt;[:]<br>
    &nbsp;&nbsp;&nbsp; [!]&lt;user name&gt;[:]<br>
    &nbsp;&nbsp;&nbsp; [!]:&lt;group number&gt;<br>
    &nbsp;&nbsp;&nbsp; [!]:&lt;group name&gt;<br>
    &nbsp;&nbsp;&nbsp; [!]&lt;user number&gt;:&lt;group number&gt;<br>
    &nbsp;&nbsp;&nbsp; [!]&lt;user number&gt;:&lt;group name&gt;<br>
    &nbsp;&nbsp;&nbsp; [!]&lt;user name&gt;:&lt;group number&gt;<br>
    &nbsp;&nbsp;&nbsp; [!]&lt;user name&gt;:&lt;group name&gt;<br>
    &nbsp;<br>
  </li>
  <li>It is no longer possible to specify rate limiting in the ACTION column
    of /etc/shorewall/rules -- you must use the RATE LIMIT column.<br>
    <br>
  </li>
  <li>Depending on which method you use to upgrade, if you have your own
    version of /etc/shorewall/rfc1918, you may have to take special action to
    restore it after the upgrade. Look for /etc/shorewall/rfc1918*, locate
    the proper file and rename it back to /etc/shorewall/rfc1918. The
    contents of that file will supercede the contents of
    /usr/share/shorewall/rfc1918.</li>
</ol>

<p>New Features:<br>
</p>
<ol>
  <li>The INCLUDE directive now allows absolute file names.</li>
  <li>A 'nosmurfs' interface option has been added to
    /etc/shorewall/interfaces. When specified for an interface, this option
    causes smurfs (packets with a broadcast address as their source) to be
    dropped and optionally logged (based on the setting of a new
    SMURF_LOG_LEVEL option in shorewall.conf).</li>
  <li>fw-&gt;fw traffic may now be controlled by Shorewall. There is no need
    to define the loopback interface in /etc/shorewall/interfaces; you simply
    add a fw-&gt;fw policy and fw-&gt;fw rules. If you have neither a
    fw-&gt;fw policy nor fw-&gt;fw rules, all fw-&gt;fw traffic is
  allowed.</li>
  <li>There is a new PERSISTENT column in the proxyarp file. A value of "Yes"
    in this column means that the route added by Shorewall for this host will
    remain after a "shorewall stop" or "shorewall clear".</li>
  <li>"trace" is now a synonym for "debug" in /sbin/shorewall commands. So to
    trace the "start" command, you could enter:<br>
    <br>
    shorewall trace start 2&gt; /tmp/trace<br>
    <br>
    The trace information would be written to the file /tmp/trace.<br>
    <br>
  </li>
  <li>When defining an ipsec tunnel in /etc/shorewall/tunnels, if you follow
    the tunnel type ("ipsec" or "ipsecnet") with ":noah" (e.g.,
    "ipsec:noah"), then Shorewall will only create rules for ESP (protocol
    50) and will not create rules for AH (protocol 51).</li>
  <li>A new DISABLE_IPV6 option has been added to shorewall.conf. When this
    option is set to "Yes", Shorewall will set the policy for the IPv6 INPUT,
    OUTPUT and FORWARD chains to DROP during "shorewall [re]start" and
    "shorewall stop". Regardless of the setting of this variable, "shorewall
    clear" will silently attempt to set these policies to ACCEPT.<br>
    <br>
    If this option is not set in your existing shorewall.conf then a setting
    of DISABLE_IPV6=No is assumed in which case, Shorewall will not touch any
    IPv6 settings except during "shorewall clear".</li>
  <li>The CONTINUE target is now available in action definitions. CONTINUE
    terminates processing of the current action and returns to the point
    where that action was invoked.</li>
</ol>

<p><b>2/15/2004 - Shorewall 1.4.10c&nbsp;</b></p>

<p>Corrects one problem:<br>
</p>
Entries in /etc/shorewall/tcrules with an empty USER/GROUP column would cause
a startup error. 

<p><b>2/12/2004 - Shorewall 1.4.10b&nbsp;</b></p>

<p>Corrects one problem:<br>
</p>
<ul>
  <li>In the /etc/shorewall/masq entry &acirc;&#x80;&#x9c;<span
    class="quote">eth0:!10.1.1.150 &nbsp; &nbsp;0.0.0.0/0!10.1.0.0/16 &nbsp;
    &nbsp; 10.1.2.16</span>&acirc;&#x80;&#x9d;, the &acirc;&#x80;&#x9c;<span
    class="quote">!10.1.0.0/16</span>&acirc;&#x80;&#x9d; is ignored.</li>
</ul>

<p><b>2/8/2004 - Shorewall 1.4.10a&nbsp;</b></p>

<p>Corrects two problems:<br>
</p>
<ul>
  <li>A problem which can cause [re]start to fail inexplicably while
    processing /etc/shorewall/masq.</li>
  <li>Interfaces using the Atheros WiFi card to use the 'maclist' option.</li>
</ul>

<p><b>1/30/2004 - Shorewall 1.4.10</b></p>

<p>Problems Corrected since version 1.4.9</p>
<ol>
  <li>The column descriptions in the action.template file did not match the
    column headings. That has been corrected.</li>
  <li>The presence of IPV6 addresses on devices generated error messages
    during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
    specified in /etc/shorewall/shorewall.conf. These messages have been
    eliminated.</li>
  <li value="3">The CONTINUE action in /etc/shorewall/rules now works
    correctly. A couple of problems involving rate limiting have been
    corrected. These bug fixes courtesy of Steven Jan Springl.</li>
  <li>Shorewall now tried to avoid sending an ICMP response to broadcasts and
    smurfs.</li>
  <li>Specifying "-" or "all" in the PROTO column of an action no longer
    causes a startup error.</li>
</ol>
Migragion Issues:<br>
<br>
&nbsp;&nbsp;&nbsp; None.<br>
<br>
New Features:<br>

<ol>
  <li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
    destination list.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
    &nbsp;&nbsp;&nbsp; eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
    <br>
    If the list begins with "!" then SNAT will occur only if the destination
    IP address is NOT included in the list.<br>
    <br>
  </li>
  <li>Output traffic control rules (those with the firewall as the source)
    may now be qualified by the effective userid and/or effective group id of
    the program generating the output. This feature is courtesy of&nbsp;
    Fr&Atilde;&copy;d&Atilde;&copy;ric LESPEZ.<br>
    <br>
    A new USER column has been added to /etc/shorewall/tcrules. It may
    contain :<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or number&gt;]:[&lt;group
    name or number&gt;]<br>
    <br>
    The colon is optionnal when specifying only a user.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john / :users /
    john:users<br>
    <br>
  </li>
  <li>A "detectnets" interface option has been added for entries in
    /etc/shorewall/interfaces. This option automatically tailors the
    definition of the zone named in the ZONE column to include just&nbsp;
    those hosts that have routes through the interface named in the INTERFACE
    column. The named interface must be UP when Shorewall is [re]started.<br>
    <br>
    &nbsp;WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
    &nbsp;&nbsp;</li>
</ol>

<p><b>1/27/2004 - Shorewall 1.4.10 RC3</b></p>

<p><a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
</p>

<p>Problems Corrected since version 1.4.9</p>
<ol>
  <li>The column descriptions in the action.template file did not match the
    column headings. That has been corrected.</li>
  <li>The presence of IPV6 addresses on devices generated error messages
    during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
    specified in /etc/shorewall/shorewall.conf. These messages have been
    eliminated.</li>
  <li value="3">The CONTINUE action in /etc/shorewall/rules now works
    correctly. A couple of problems involving rate limiting have been
    corrected. These bug fixes courtesy of Steven Jan Springl.</li>
  <li>Shorewall now tried to avoid sending an ICMP response to broadcasts and
    smurfs.<br>
  </li>
</ol>
Migragion Issues:<br>
<br>
&nbsp;&nbsp;&nbsp; None.<br>
<br>
New Features:<br>

<ol>
  <li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
    destination list.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
    &nbsp;&nbsp;&nbsp; eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
    <br>
    If the list begins with "!" then SNAT will occur only if the destination
    IP address is NOT included in the list.<br>
    <br>
  </li>
  <li>Output traffic control rules (those with the firewall as the source)
    may now be qualified by the effective userid and/or effective group id of
    the program generating the output. This feature is courtesy of&nbsp;
    Fr&Atilde;&copy;d&Atilde;&copy;ric LESPEZ.<br>
    <br>
    A new USER column has been added to /etc/shorewall/tcrules. It may
    contain :<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or number&gt;]:[&lt;group
    name or number&gt;]<br>
    <br>
    The colon is optionnal when specifying only a user.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john / :users /
    john:users<br>
    <br>
  </li>
  <li>A "detectnets" interface option has been added for entries in
    /etc/shorewall/interfaces. This option automatically tailors the
    definition of the zone named in the ZONE column to include just&nbsp;
    those hosts that have routes through the interface named in the INTERFACE
    column. The named interface must be UP when Shorewall is [re]started.<br>
    <br>
    &nbsp;WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
    &nbsp;&nbsp;</li>
</ol>

<p><b>1/24/2004 - Shorewall 1.4.10 RC2</b><b>&nbsp;</b></p>

<p><a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
</p>

<p>Problems Corrected since version 1.4.9</p>
<ol>
  <li>The column descriptions in the action.template file did not match the
    column headings. That has been corrected.</li>
  <li>The presence of IPV6 addresses on devices generated error messages
    during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
    specified in /etc/shorewall/shorewall.conf. These messages have been
    eliminated.</li>
</ol>
Migragion Issues:<br>
<br>
&nbsp;&nbsp;&nbsp; None.<br>
<br>
New Features:<br>

<ol>
  <li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
    destination list.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
    &nbsp;&nbsp;&nbsp; eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
    <br>
    If the list begins with "!" then SNAT will occur only if the destination
    IP address is NOT included in the list.<br>
    <br>
  </li>
  <li>Output traffic control rules (those with the firewall as the source)
    may now be qualified by the effective userid and/or effective group id of
    the program generating the output. This feature is courtesy of&nbsp;
    Fr&Atilde;&copy;d&Atilde;&copy;ric LESPEZ.<br>
    <br>
    A new USER column has been added to /etc/shorewall/tcrules. It may
    contain :<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or number&gt;]:[&lt;group
    name or number&gt;]<br>
    <br>
    The colon is optionnal when specifying only a user.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john / :users /
    john:users<br>
    <br>
  </li>
  <li>A "detectnets" interface option has been added for entries in
    /etc/shorewall/interfaces. This option automatically tailors the
    definition of the zone named in the ZONE column to include just&nbsp;
    those hosts that have routes through the interface named in the INTERFACE
    column. The named interface must be UP when Shorewall is [re]started.<br>
    <br>
    &nbsp;WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!</li>
</ol>

<p><b>1/22/2004 - Shorewall 1.4.10 RC1</b><b>&nbsp;</b></p>

<p>Problems Corrected since version 1.4.9</p>
<ol>
  <li>The column descriptions in the action.template file did not match the
    column headings. That has been corrected.</li>
  <li>The presence of IPV6 addresses on devices generated error messages
    during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
    specified in /etc/shorewall/shorewall.conf. These messages have been
    eliminated.</li>
</ol>
Migragion Issues:<br>
<br>
&nbsp;&nbsp;&nbsp; None.<br>
<br>
New Features:<br>

<ol>
  <li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
    destination list.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp; SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
    &nbsp;&nbsp;&nbsp; eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
    <br>
    If the list begins with "!" then SNAT will occur only if the destination
    IP address is NOT included in the list.<br>
    <br>
  </li>
  <li>Output traffic control rules (those with the firewall as the source)
    may now be qualified by the effective userid and/or effective group id of
    the program generating the output. This feature is courtesy of&nbsp;
    Fr&Atilde;&copy;d&Atilde;&copy;ric LESPEZ.<br>
    <br>
    A new USER column has been added to /etc/shorewall/tcrules. It may
    contain :<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or number&gt;]:[&lt;group
    name or number&gt;]<br>
    <br>
    The colon is optionnal when specifying only a user.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john / :users /
    john:users&nbsp;&nbsp;&nbsp;<br>
  </li>
</ol>

<p><b>1/13/2004 - Shorewall 1.4.9</b><b><br>
</b></p>

<p>Problems Corrected since version 1.4.8:<br>
</p>
<ol>
  <li>There has been a low continuing level of confusion over the terms
    "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
    instances of "Static NAT" have been replaced with "One-to-one NAT" in the
    documentation and configuration files.</li>
  <li>The description of NEWNOTSYN in shorewall.conf has been reworded for
    clarity.</li>
  <li>Wild-card rules (those involving "all" as SOURCE or DEST) will no
    longer produce an error if they attempt to add a rule that would override
    a NONE policy. The logic for expanding these wild-card rules now simply
    skips those (SOURCE,DEST) pairs that have a NONE policy.</li>
  <li>DNAT rules that also specified SNAT now work reliably. Previously,
    there were cases where the SNAT specification was effectively
  ignored.</li>
</ol>

<p>Migration Issues:<br>
<br>
&nbsp;&nbsp;&nbsp; None.<br>
<br>
New Features:<br>
</p>
<ol>
  <li>The documentation has been completely rebased to Docbook XML. The
    documentation is now released as separate HTML and XML packages.</li>
  <li>To cut down on the number of "Why are these ports closed rather than
    stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
    have been changed from 'reject' to 'DROP'.</li>
  <li>For easier identification, packets logged under the 'norfc1918'
    interface option are now logged out of chains named 'rfc1918'.
    Previously, such packets were logged under chains named 'logdrop'.</li>
  <li>Distributors and developers seem to be regularly inventing new naming
    conventions for kernel modules. To avoid the need to change Shorewall
    code for each new convention, the MODULE_SUFFIX option has been added to
    shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
    in your particular distribution. If MODULE_SUFFIX is not set in
    shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
    <br>
    To see what suffix is used by your distribution:<br>
    <br>
    ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
    <br>
    All of the files listed should have the same suffix (extension). Set
    MODULE_SUFFIX to that suffix.<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kzo" then set
    MODULE_SUFFIX="kzo"<br>
    &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kz.o" then set
    MODULE_SUFFIX="kz.o"</li>
  <li>Support for user defined rule ACTIONS has been implemented through two
    new files:<br>
    <br>
    /etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
    /etc/shorewall/action.template - For each user defined &lt;action&gt;,
    copy this file to /etc/shorewall/action.&lt;action&gt; and add the
    appropriate rules for that &lt;action&gt;. Once an &lt;action&gt; has
    been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
    DROP, etc.) in /etc/shorewall/rules.<br>
    <br>
    Example: You want an action that logs a packet at the 'info' level and
    accepts the connection.<br>
    <br>
    In /etc/shorewall/actions, you would add:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; LogAndAccept<br>
    <br>
    You would then copy /etc/shorewall/action.template to
    /etc/shorewall/action.LogAndAccept and in that file, you would add the
    two rules:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOG:info<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT</li>
  <li>The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
    TCP packets that are not part of an existing connection are filtered
    according to the rules and policies rather than being dropped). I have
    made this change for two reasons:<br>
    <br>
    a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
    timeout during TCP session tear down results in the firewall dropping all
    of the retries.<br>
    <br>
    b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
    of confusing messages when a connection got "stuck". While I could have
    changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
    defaults that silently throw away packets.</li>
  <li>The common.def file now contains an entry that silently drops ICMP
    packets with a null source address. Ad Koster reported a case where these
    were occuring frequently as a result of a broken system on his external
    network.</li>
</ol>

<p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b></p>

<div style="margin-left: 40px;">
<a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a> </div>

<p>Problems Corrected since version 1.4.8:</p>
<ol>
  <li>There has been a low continuing level of confusion over the terms
    "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
    instances of "Static NAT" have been replaced with "One-to-one NAT" in the
    documentation and configuration files.</li>
  <li>The description of NEWNOTSYN in shorewall.conf has been reworded for
    clarity.</li>
  <li>Wild-card rules (those involving "all" as SOURCE or DEST) will no
    longer produce an error if they attempt to add a rule that would override
    a NONE policy. The logic for expanding these wild-card rules now simply
    skips those (SOURCE,DEST) pairs that have a NONE policy.</li>
  <li>DNAT rules that also specified SNAT now work reliably. Previously,
    there were cases where the SNAT specification was effectively ignored.<br>
  </li>
</ol>

<p>Migration Issues:</p>

<p>&nbsp;&nbsp;&nbsp; None.<br>
<br>
New Features:</p>
<ol>
  <li>The documentation has been completely rebased to Docbook XML. The
    documentation is now released as separate HTML and XML packages.<br>
  </li>
  <li>To cut down on the number of "Why are these ports closed rather than
    stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
    have been changed from 'reject' to 'DROP'.</li>
  <li>For easier identification, packets logged under the 'norfc1918'
    interface option are now logged out of chains named 'rfc1918'.
    Previously, such packets were logged under chains named 'logdrop'.</li>
  <li>Distributors and developers seem to be regularly inventing new naming
    conventions for kernel modules. To avoid the need to change Shorewall
    code for each new convention, the MODULE_SUFFIX option has been added to
    shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
    in your particular distribution. If MODULE_SUFFIX is not set in
    shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
    <br>
    To see what suffix is used by your distribution:<br>
    <br>
    ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
    <br>
    All of the files listed should have the same suffix (extension). Set
    MODULE_SUFFIX to that suffix.<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kzo" then set
    MODULE_SUFFIX="kzo"<br>
    &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kz.o" then set
    MODULE_SUFFIX="kz.o"</li>
  <li>Support for user defined rule ACTIONS has been implemented through two
    new files:<br>
    <br>
    /etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
    /etc/shorewall/action.template - For each user defined &lt;action&gt;,
    copy this file to /etc/shorewall/action.&lt;action&gt; and add the
    appropriate rules for that &lt;action&gt;. Once an &lt;action&gt; has
    been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
    DROP, etc.) in /etc/shorewall/rules.<br>
    <br>
    Example: You want an action that logs a packet at the 'info' level and
    accepts the connection.<br>
    <br>
    In /etc/shorewall/actions, you would add:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; LogAndAccept<br>
    <br>
    You would then copy /etc/shorewall/action.template to
    /etc/shorewall/action.LogAndAccept and in that file, you would add the
    two rules:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOG:info<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT<br>
  </li>
  <li>The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
    TCP packets that are not part of an existing connection are filtered
    according to the rules and policies rather than being dropped). I have
    made this change for two reasons:<br>
    <br>
    a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
    timeout during TCP session tear down results in the firewall dropping all
    of the retries.<br>
    <br>
    b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
    of confusing messages when a connection got "stuck". While I could have
    changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
    defaults that silently throw away packets.<br>
    <br>
  </li>
</ol>

<p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back On-line</b>
<b><br>
</b></p>

<p>Our high-capacity server has been restored to service -- please let <a
href="mailto:webmaster@shorewall.net">us</a> know if you find any
problems.</p>

<p><b>12/29/2003 - Shorewall 1.4.9 Beta 1</b></p>

<div style="margin-left: 40px;">
<a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a> </div>

<p>Problems Corrected since version 1.4.8:</p>
<ol>
  <li>There has been a low continuing level of confusion over the terms
    "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
    instances of "Static NAT" have been replaced with "One-to-one NAT" in the
    documentation and configuration files.</li>
  <li>The description of NEWNOTSYN in shorewall.conf has been reworded for
    clarity.</li>
  <li>Wild-card rules (those involving "all" as SOURCE or DEST) will no
    longer produce an error if they attempt to add a rule that would override
    a NONE policy. The logic for expanding these wild-card rules now simply
    skips those (SOURCE,DEST) pairs that have a NONE policy.</li>
</ol>

<p>Migration Issues:</p>

<p>&nbsp;&nbsp;&nbsp; None.<br>
<br>
New Features:</p>
<ol>
  <li>To cut down on the number of "Why are these ports closed rather than
    stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
    have been changed from 'reject' to 'DROP'.</li>
  <li>For easier identification, packets logged under the 'norfc1918'
    interface option are now logged out of chains named 'rfc1918'.
    Previously, such packets were logged under chains named 'logdrop'.</li>
  <li>Distributors and developers seem to be regularly inventing new naming
    conventions for kernel modules. To avoid the need to change Shorewall
    code for each new convention, the MODULE_SUFFIX option has been added to
    shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
    in your particular distribution. If MODULE_SUFFIX is not set in
    shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
    <br>
    To see what suffix is used by your distribution:<br>
    <br>
    ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
    <br>
    All of the files listed should have the same suffix (extension). Set
    MODULE_SUFFIX to that suffix.<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kzo" then set
    MODULE_SUFFIX="kzo"<br>
    &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kz.o" then set
    MODULE_SUFFIX="kz.o"</li>
  <li>Support for user defined rule ACTIONS has been implemented through two
    new files:<br>
    <br>
    /etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
    /etc/shorewall/action.template - For each user defined &lt;action&gt;,
    copy this file to /etc/shorewall/action.&lt;action&gt; and add the
    appropriate rules for that &lt;action&gt;. Once an &lt;action&gt; has
    been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
    DROP, etc.) in /etc/shorewall/rules.<br>
    <br>
    Example: You want an action that logs a packet at the 'info' level and
    accepts the connection.<br>
    <br>
    In /etc/shorewall/actions, you would add:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; LogAndAccept<br>
    <br>
    You would then copy /etc/shorewall/action.template to
    /etc/shorewall/action.LogAndAccept and in that file, you would add the
    two rules:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOG:info<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT<br>
  </li>
  <li>The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
    TCP packets that are not part of an existing connection are filtered
    according to the rules and policies rather than being dropped). I have
    made this change for two reasons:<br>
    <br>
    a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
    timeout during TCP session tear down results in the firewall dropping all
    of the retries.<br>
    <br>
    b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
    of confusing messages when a connection got "stuck". While I could have
    changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
    defaults that silently throw away packets.</li>
</ol>

<p><b>12/03/2003 - Support Torch Passed</b></p>
Effective today, I am reducing my participation in the day-to-day support of
Shorewall. As part of this shift to community-based Shorewall support a new
<a
href="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">Shorewall
Newbies mailing list</a> has been established to field questions and problems
from new users. I will not monitor that list personally. I will continue my
active development of Shorewall and will be available via the development
list to handle development issues -- Tom. 

<p><b>11/07/2003 - Shorewall 1.4.8<br>
<br>
</b> Problems Corrected since version 1.4.7:<br>
</p>
<ol>
  <li>Tuomo Soini has supplied a correction to a problem that occurs using
    some versions of 'ash'. The symptom is that "shorewall start" fails
    with:<br>
    &nbsp;<br>
    &nbsp;&nbsp; local: --limit: bad variable name<br>
    &nbsp;&nbsp; iptables v1.2.8: Couldn't load match
    `-j':/lib/iptables/libipt_-j.so:<br>
    &nbsp;&nbsp; cannot open shared object file: No such file or directory<br>
    &nbsp;&nbsp; Try `iptables -h' or 'iptables --help' for more
  information.</li>
  <li>Andres Zhoglo has supplied a correction that avoids trying to use the
    multiport match iptables facility on ICMP rules.<br>
    &nbsp;<br>
    &nbsp;&nbsp; Example of rule that previously caused "shorewall start" to
    fail:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc&nbsp; $FW&nbsp;
    icmp&nbsp;&nbsp;&nbsp; 0,8,11,12<br>
    <br>
  </li>
  <li>Previously, if the following error message was issued, Shorewall was
    left in an inconsistent state.<br>
    &nbsp;<br>
    &nbsp;&nbsp; Error: Unable to determine the routes through interface
    xxx<br>
    <br>
  </li>
  <li>Handling of the LOGUNCLEAN option in shorewall.conf has been
  corrected.</li>
  <li>In Shorewall 1.4.2, an optimization was added. This optimization
    involved creating a chain named "&lt;zone&gt;_frwd" for most zones
    defined using the /etc/shorewall/hosts file. It has since been discovered
    that in many cases these new chains contain redundant rules and that the
    "optimization" turns out to be less than optimal. The implementation has
    now been corrected.</li>
  <li>When the MARK value in a tcrules entry is followed by ":F" or ":P", the
    ":F" or ":P" was previously only applied to the first Netfilter rule
    generated by the entry. It is now applied to all entries.</li>
  <li>An incorrect comment concerning Debian's use of the SUBSYSLOCK option
    has been removed from shorewall.conf.</li>
  <li>Previously, neither the 'routefilter' interface option nor the
    ROUTE_FILTER parameter were working properly. This has been corrected
    (thanks to Eric Bowles for his analysis and patch). The definition of the
    ROUTE_FILTER option has changed however. Previously, ROUTE_FILTER=Yes was
    documented as enabling route filtering on all interfaces (which didn't
    work). Beginning with this release, setting ROUTE_FILTER=Yes will enable
    route filtering of all interfaces brought up while Shorewall is started.
    As a consequence, ROUTE_FILTER=Yes can coexist with the use of the
    'routefilter' option in the interfaces file.</li>
  <li>If MAC verification was enabled on an interface with a /32 address and
    a broadcast address then an error would occur during startup.</li>
  <li>The NONE policy's intended use is to suppress the generating of rules
    that can't possibly be traversed. This means that a policy of NONE is
    inappropriate where the source or destination zone is $FW or "all".
    Shorewall now generates an error message if such a policy is given in
    /etc/shorewall/policy. Previously such a policy caused "shorewall start"
    to fail.</li>
  <li>The 'routeback' option was broken for wildcard interfaces (e.g.,
    "tun+"). This has been corrected so that 'routeback' now works as
    expected in this case.<br>
  </li>
</ol>
Migration Issues:<br>

<ol>
  <li>The definition of the ROUTE_FILTER option in shorewall.conf has changed
    as described in item 8) above.<br>
  </li>
</ol>
New Features:<br>

<ol>
  <li>A new QUEUE action has been introduced for rules. QUEUE allows you to
    pass connection requests to a user-space filter such as ftwall
    (http://p2pwall.sourceforge.net). The ftwall program allows for effective
    filtering of p2p applications such as Kazaa. For example, to use ftwall
    to filter P2P clients in the 'loc' zone, you would add the following
    rules:<br>
    <br>
    &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; tcp<br>
    &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; udp<br>
    &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;&nbsp; udp<br>
    <br>
    You would normally want to place those three rules BEFORE any ACCEPT
    rules for loc-&gt;net udp or tcp.<br>
    <br>
    Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), Shorewall
    will only pass connection requests (SYN packets) to user space. This is
    for compatibility with ftwall.</li>
  <li>A BLACKLISTNEWNONLY option has been added to shorewall.conf. When this
    option is set to "Yes", the blacklists (dynamic and static) are only
    consulted for new connection requests. When set to "No" (the default if
    the variable is not set), the blacklists are consulted on every
    packet.<br>
    <br>
    Setting this option to "No" allows blacklisting to stop existing
    connections from a newly blacklisted host but is more expensive in terms
    of packet processing time. This is especially true if the blacklists
    contain a large number of entries.</li>
  <li>Chain names used in the /etc/shorewall/accounting file may now begin
    with a digit ([0-9]) and may contain embedded dashes ("-").</li>
</ol>

<p><b>10/30/2003 - Shorewall 1.4.8 RC1<br>
</b></p>
Given the small number of new features and the relatively few lines of code
that were changed, there will be no Beta for 1.4.8.<br>


<p><b><a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
<br>
</b> Problems Corrected since version 1.4.7:<br>
</p>
<ol>
  <li>Tuomo Soini has supplied a correction to a problem that occurs using
    some versions of 'ash'. The symptom is that "shorewall start" fails
    with:<br>
    &nbsp;<br>
    &nbsp;&nbsp; local: --limit: bad variable name<br>
    &nbsp;&nbsp; iptables v1.2.8: Couldn't load match
    `-j':/lib/iptables/libipt_-j.so:<br>
    &nbsp;&nbsp; cannot open shared object file: No such file or directory<br>
    &nbsp;&nbsp; Try `iptables -h' or 'iptables --help' for more
  information.</li>
  <li>Andres Zhoglo has supplied a correction that avoids trying to use the
    multiport match iptables facility on ICMP rules.<br>
    &nbsp;<br>
    &nbsp;&nbsp; Example of rule that previously caused "shorewall start" to
    fail:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc&nbsp; $FW&nbsp;
    icmp&nbsp;&nbsp;&nbsp; 0,8,11,12<br>
    <br>
  </li>
  <li>Previously, if the following error message was issued, Shorewall was
    left in an inconsistent state.<br>
    &nbsp;<br>
    &nbsp;&nbsp; Error: Unable to determine the routes through interface
    xxx<br>
    <br>
  </li>
  <li>Handling of the LOGUNCLEAN option in shorewall.conf has been
  corrected.</li>
  <li>In Shorewall 1.4.2, an optimization was added. This optimization
    involved creating a chain named "&lt;zone&gt;_frwd" for most zones
    defined using the /etc/shorewall/hosts file. It has since been discovered
    that in many cases these new chains contain redundant rules and that the
    "optimization" turns out to be less than optimal. The implementation has
    now been corrected.</li>
  <li>When the MARK value in a tcrules entry is followed by ":F" or ":P", the
    ":F" or ":P" was previously only applied to the first Netfilter rule
    generated by the entry. It is now applied to all entries.</li>
  <li>An incorrect comment concerning Debian's use of the SYBSYSLOCK option
    has been removed from shorewall.conf.</li>
  <li>Previously, neither the 'routefilter' interface option nor the
    ROUTE_FILTER parameter were working properly. This has been corrected
    (thanks to Eric Bowles for his analysis and patch). The definition of the
    ROUTE_FILTER option has changed however. Previously, ROUTE_FILTER=Yes was
    documented as enabling route filtering on all interfaces (which didn't
    work). Beginning with this release, setting ROUTE_FILTER=Yes will enable
    route filtering of all interfaces brought up while Shorewall is started.
    As a consequence, ROUTE_FILTER=Yes can coexist with the use of the
    'routefilter' option in the interfaces file.</li>
</ol>
Migration Issues:<br>

<ol>
  <li>The definition of the ROUTE_FILTER option in shorewall.conf has changed
    as described in item 8) above.<br>
  </li>
</ol>
New Features:<br>

<ol>
  <li>A new QUEUE action has been introduced for rules. QUEUE allows you to
    pass connection requests to a user-space filter such as ftwall
    (http://p2pwall.sourceforge.net). The ftwall program allows for effective
    filtering of p2p applications such as Kazaa. For example, to use ftwall
    to filter P2P clients in the 'loc' zone, you would add the following
    rules:<br>
    <br>
    &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; tcp<br>
    &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; udp<br>
    &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    &nbsp;&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;&nbsp; udp<br>
    <br>
    You would normally want to place those three rules BEFORE any ACCEPT
    rules for loc-&gt;net udp or tcp.<br>
    <br>
    Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), Shorewall
    will only pass connection requests (SYN packets) to user space. This is
    for compatibility with ftwall.</li>
  <li>A BLACKLISTNEWNONLY option has been added to shorewall.conf. When this
    option is set to "Yes", the blacklists (dynamic and static) are only
    consulted for new connection requests. When set to "No" (the default if
    the variable is not set), the blacklists are consulted on every
    packet.<br>
    <br>
    Setting this option to "No" allows blacklisting to stop existing
    connections from a newly blacklisted host but is more expensive in terms
    of packet processing time. This is especially true if the blacklists
    contain a large number of entries.</li>
  <li>Chain names used in the /etc/shorewall/accounting file may now begin
    with a digit ([0-9]) and may contain embedded dashes ("-").<br>
  </li>
</ol>

<p><b>10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag awards</b>
<b><img style="border: 0px solid ; width: 50px; height: 80px;"
src="images/j0233056.gif" title="" alt="" align="middle" />Shorewall 1.4.7c
released.</b></p>
<ol>
  <li>The saga with "&lt;zone&gt;_frwd" chains continues. The 1.4.7c script
    produces a ruleset that should work for everyone even if it is not quite
    optimal. My apologies for this ongoing mess.<br>
  </li>
</ol>

<p><b>10/24/2003 - Shorewall 1.4.7b</b></p>
This is a bugfx rollup of the 1.4.7a fixes plus:<br>

<ol>
  <li>The fix for problem 5 in 1.4.7a was wrong with the result that
    "&lt;zone&gt;_frwd" chains might contain too few rules. That wrong code
    is corrected in this release.<br>
  </li>
</ol>

<p><b>10/21/2003 - Shorewall 1.4.7a<br>
</b></p>

<p>This is a bugfix rollup of the following problem corrections:<br>
</p>
<ol>
  <li>Tuomo Soini has supplied a correction to a problem that occurs using
    some versions of 'ash'. The symptom is that "shorewall start" fails
    with:<br>
    &nbsp;<br>
    &nbsp;&nbsp; local: --limit: bad variable name<br>
    &nbsp;&nbsp; iptables v1.2.8: Couldn't load match
    `-j':/lib/iptables/libipt_-j.so:<br>
    &nbsp;&nbsp; cannot open shared object file: No such file or directory<br>
    &nbsp;&nbsp; Try `iptables -h' or 'iptables --help' for more
    information.<br>
    <br>
  </li>
  <li>Andres Zhoglo has supplied a correction that avoids trying to use the
    multiport match iptables facility on ICMP rules.<br>
    &nbsp;<br>
    &nbsp;&nbsp; Example of rule that previously caused "shorewall start" to
    fail:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc&nbsp; $FW&nbsp;
    icmp&nbsp;&nbsp;&nbsp; 0,8,11,12<br>
    <br>
  </li>
  <li>Previously, if the following error message was issued, Shorewall was
    left in an inconsistent state.<br>
    &nbsp;<br>
    &nbsp;&nbsp; Error: Unable to determine the routes through interface
    xxx<br>
    <br>
  </li>
  <li>Handling of the LOGUNCLEAN option in shorewall.conf has been
  corrected.</li>
  <li>In Shorewall 1.4.2, an optimization was added. This optimization
    involved creating a chain named "&lt;zone&gt;_frwd" for most zones
    defined using the /etc/shorewall/hosts file. It has since been discovered
    that in many cases these new chains contain redundant rules and that the
    "optimization" turns out to be less than optimal. The implementation has
    now been corrected.</li>
  <li>When the MARK value in a tcrules entry is followed by ":F" or ":P", the
    ":F" or ":P" was previously only applied to the first Netfilter rule
    generated by the entry. It is now applied to all entries.<br>
  </li>
</ol>

<p><b>10/06/2003 - Shorewall 1.4.7</b><b><br>
</b></p>
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
since 1.4.7 RC2).</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages</li>
  <li>Interface-specific dynamic blacklisting chains are now displayed by
    "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").</li>
  <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
  <li value="7">The 'shorewall reject' and 'shorewall drop' commands now
    delete any existing rules for the subject IP address before adding a new
    DROP or REJECT rule. Previously, there could be many rules for the same
    IP address in the dynamic chain so that multiple 'allow' commands were
    required to re-enable traffic to/from the address.</li>
  <li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
    /etc/shorewall/masq resulted in a startup error:<br>
    &nbsp;<br>
    &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
    206.124.146.20-206.124.146.24<br>
    <br>
  </li>
  <li>Shorewall previously choked over IPV6 addresses configured on
    interfaces in contexts where Shorewall needed to detect something about
    the interface (such as when "detect" appears in the BROADCAST column of
    the /etc/shorewall/interfaces file).</li>
  <li>Shorewall will now load module files that are formed from the module
    name by appending ".o.gz".</li>
  <li>When Shorewall adds a route to a proxy ARP host and such a route
    already exists, two routes resulted previously. This has been corrected
    so that the existing route is replaced if it already exists.</li>
  <li>The rfc1918 file has been updated to reflect recent allocations.</li>
  <li>The documentation of the USER SET column in the rules file has been
    corrected.</li>
  <li>If there is no policy defined for the zones specified in a rule, the
    firewall script previously encountered a shell syntax error:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [: NONE: unexpected
    operator<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    Now, the absence of a policy generates an error message and the firewall
    is stopped:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No policy defined from zone
    &lt;source&gt; to zone &lt;dest&gt;<br>
    <br>
  </li>
  <li>Previously, if neither /etc/shorewall/common nor
    /etc/shorewall/common.def existed, Shorewall would fail to start and
    would not remove the lock file. Failure to remove the lock file resulted
    in the following during subsequent attempts to start:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp; Loading /usr/share/shorewall/functions...<br>
    &nbsp;&nbsp;&nbsp; Processing /etc/shorewall/params ...<br>
    &nbsp;&nbsp;&nbsp; Processing /etc/shorewall/shorewall.conf...<br>
    &nbsp;&nbsp;&nbsp; Giving up on lock file /var/lib/shorewall/lock<br>
    &nbsp;&nbsp;&nbsp; Shorewall Not Started<br>
    <br>
    Shorewall now reports a fatal error if neither of these two files exist
    and correctly removes the lock fille.</li>
  <li>The order of processing the various options has been changed such that
    blacklist entries now take precedence over the 'dhcp' <span
    style="font-weight: bold;">i</span>nterface setting.</li>
  <li>The log message generated from the 'logunclean' interface option has
    been changed to reflect a disposition of LOG rather than DROP.</li>
  <li><span style="font-weight: bold;">When a user name and/or a group name
    was specified in the USER SET column and the destination zone was
    qualified with a IP address, the user and/or group name was not being
    used to qualify the rule.<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp; Example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp; ACCEPT fw&nbsp; net:192.0.2.12 tcp 23 - - -
    vladimir:<br>
    <br>
    </span></li>
  <li><span style="font-weight: bold;">The /etc/shorewall/masq file has had
    the spurious "/" character at the front removed.<br>
    <br>
    </span></li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
    see the <a href="Accounting.html">Accounting Page</a> for details.</li>
  <li>The Uset Set capability introduced in SnapShot 20030821 has changed --
    see the <a href="UserSets.html">User Set page</a> for details.</li>
  <li>The per-interface Dynamic Blacklisting facility introduced in the first
    post-1.4.6 Snapshot has been removed. The facility had too many
    idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
  </li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.</li>
  <li>The ADDRESS column in /etc/shorewall/masq may now include a
    comma-separated list of addresses and/or address ranges. Netfilter will
    use all listed addresses/ranges in round-robin fashion. \</li>
  <li>An /etc/shorewall/accounting file has been added to allow for traffic
    accounting.&nbsp; See the <a href="Accounting.html">accounting
    documentation</a> for a description of this facility.</li>
  <li>Bridge interfaces (br[0-9]) may now be used in
  /etc/shorewall/maclist.</li>
  <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
    /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
    rules, rate limiting occurs in the nat table DNAT rule; the corresponding
    ACCEPT rule in the filter table is not rate limited. If you want to limit
    the filter table rule, you will need o create two rules; a DNAT- rule and
    an ACCEPT rule which can be rate-limited separately.<br>
    &nbsp;<br>
    <span style="font-weight: bold;">Warning:</span> When rate limiting is
    specified on a rule with "all" in the SOURCE or DEST fields, the limit
    will apply to each pair of zones individually rather than as a single
    limit for all pairs of covered by the rule.<br>
    &nbsp;<br>
    To specify a rate limit,<br>
    <br>
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
    &nbsp;<br>
    &nbsp; where<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
    &lt;interval&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
    accepted within an &lt;interval&gt;. If not given, the default of 5 is
    assumed.<br>
    &nbsp;<br>
    There may be no white space between the ACTION and "&lt;" nor there may
    be any white space within the burst specification. If you want to specify
    logging of a rate-limited rule, the ":" and log level comes after the
    "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
    <br>
    b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
    file. You may specify the rate limit there in the format:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
    &nbsp;<br>
    Let's take an example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
    &nbsp;&nbsp;&nbsp;<br>
    The first time this rule is reached, the packet will be accepted; in
    fact, since the burst is 4, the first four packets will be accepted.
    After this, it will be 500ms (1 second divided by the rate<br>
    of 2) before a packet will be accepted from this rule, regardless of how
    many packets reach it. Also, every 500ms which passes without matching a
    packet, one of the bursts will be regained; if no packets hit the rule
    for 2 second, the burst will be fully recharged; back where we
    started.<br>
  </li>
  <li>Multiple chains may now be displayed in one "shorewall show" command
    (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
  <li>Output rules (those with $FW as the SOURCE) may now be limited to a set
    of local users and/or groups. See <a
    href="UserSets.html">http://shorewall.net/UserSets.html</a> for
  details.</li>
</ol>

<p><b>10/02/2003 - Shorewall 1.4.7 RC2</b><b><br>
</b></p>

<p><b><a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
</b></p>
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
since 1.4.7 RC 1).</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages</li>
  <li>Interface-specific dynamic blacklisting chains are now displayed by
    "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").</li>
  <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
  <li value="7">The 'shorewall reject' and 'shorewall drop' commands now
    delete any existing rules for the subject IP address before adding a new
    DROP or REJECT rule. Previously, there could be many rules for the same
    IP address in the dynamic chain so that multiple 'allow' commands were
    required to re-enable traffic to/from the address.</li>
  <li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
    /etc/shorewall/masq resulted in a startup error:<br>
    &nbsp;<br>
    &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
    206.124.146.20-206.124.146.24<br>
    <br>
  </li>
  <li>Shorewall previously choked over IPV6 addresses configured on
    interfaces in contexts where Shorewall needed to detect something about
    the interface (such as when "detect" appears in the BROADCAST column of
    the /etc/shorewall/interfaces file).</li>
  <li>Shorewall will now load module files that are formed from the module
    name by appending ".o.gz".</li>
  <li>When Shorewall adds a route to a proxy ARP host and such a route
    already exists, two routes resulted previously. This has been corrected
    so that the existing route is replaced if it already exists.</li>
  <li>The rfc1918 file has been updated to reflect recent allocations.</li>
  <li><span style="font-weight: bold;">The documentation of the USER SET
    column in the rules file has been corrected.</span></li>
  <li><span style="font-weight: bold;">If there is no policy defined for the
    zones specified in a rule, the firewall script previously encountered a
    shell syntax error:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [: NONE: unexpected
    operator<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    Now, the absence of a policy generates an error message and the firewall
    is stopped:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No policy defined from zone
    &lt;source&gt; to zone &lt;dest&gt;<br>
    <br>
    </span></li>
  <li><span style="font-weight: bold;">Previously, if neither
    /etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall
    would fail to start and would not remove the lock file. Failure to remove
    the lock file resulted in the following during subsequent attempts to
    start:<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;&nbsp;&nbsp; Loading /usr/share/shorewall/functions...<br>
    &nbsp;&nbsp;&nbsp; Processing /etc/shorewall/params ...<br>
    &nbsp;&nbsp;&nbsp; Processing /etc/shorewall/shorewall.conf...<br>
    &nbsp;&nbsp;&nbsp; Giving up on lock file /var/lib/shorewall/lock<br>
    &nbsp;&nbsp;&nbsp; Shorewall Not Started<br>
    <br>
    Shorewall now reports a fatal error if neither of these two files exist
    and correctly removes the lock fille.</span></li>
  <li><span style="font-weight: bold;">The order of processing the various
    options has been changed such that blacklist entries now take precedence
    over the 'dhcp' interface setting.</span></li>
  <li><span style="font-weight: bold;">The log message generated from the
    'logunclean' interface option has been changed to reflect a disposition
    of LOG rather than DROP.</span></li>
  <li><span style="font-weight: bold;">The RFC1918 file has been updated to
    reflect recent IANA allocations.<br>
    </span></li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
    see the <a href="Accounting.html">Accounting Page</a> for details.</li>
  <li>The Uset Set capability introduced in SnapShot 20030821 has changed --
    see the <a href="UserSets.html">User Set page</a> for details.</li>
  <li>The per-interface Dynamic Blacklisting facility introduced in the first
    post-1.4.6 Snapshot has been removed. The facility had too many
    idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
  </li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.</li>
  <li>The ADDRESS column in /etc/shorewall/masq may now include a
    comma-separated list of addresses and/or address ranges. Netfilter will
    use all listed addresses/ranges in round-robin fashion. \</li>
  <li>An /etc/shorewall/accounting file has been added to allow for traffic
    accounting.&nbsp; See the <a href="Accounting.html">accounting
    documentation</a> for a description of this facility.</li>
  <li>Bridge interfaces (br[0-9]) may now be used in
  /etc/shorewall/maclist.</li>
  <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
    /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
    rules, rate limiting occurs in the nat table DNAT rule; the corresponding
    ACCEPT rule in the filter table is not rate limited. If you want to limit
    the filter table rule, you will need o create two rules; a DNAT- rule and
    an ACCEPT rule which can be rate-limited separately.<br>
    &nbsp;<br>
    <span style="font-weight: bold;">Warning:</span> When rate limiting is
    specified on a rule with "all" in the SOURCE or DEST fields, the limit
    will apply to each pair of zones individually rather than as a single
    limit for all pairs of covered by the rule.<br>
    &nbsp;<br>
    To specify a rate limit,<br>
    <br>
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
    &nbsp;<br>
    &nbsp; where<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
    &lt;interval&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
    accepted within an &lt;interval&gt;. If not given, the default of 5 is
    assumed.<br>
    &nbsp;<br>
    There may be no white space between the ACTION and "&lt;" nor there may
    be any white space within the burst specification. If you want to specify
    logging of a rate-limited rule, the ":" and log level comes after the
    "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
    <br>
    b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
    file. You may specify the rate limit there in the format:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
    &nbsp;<br>
    Let's take an example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
    &nbsp;&nbsp;&nbsp;<br>
    The first time this rule is reached, the packet will be accepted; in
    fact, since the burst is 4, the first four packets will be accepted.
    After this, it will be 500ms (1 second divided by the rate<br>
    of 2) before a packet will be accepted from this rule, regardless of how
    many packets reach it. Also, every 500ms which passes without matching a
    packet, one of the bursts will be regained; if no packets hit the rule
    for 2 second, the burst will be fully recharged; back where we
    started.<br>
  </li>
  <li>Multiple chains may now be displayed in one "shorewall show" command
    (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
  <li>Output rules (those with $FW as the SOURCE) may now be limited to a set
    of local users and/or groups. See <a
    href="UserSets.html">http://shorewall.net/UserSets.html</a> for
  details.</li>
</ol>

<p><b>9/18/2003 - Shorewall 1.4.7 RC 1</b><b><br>
</b></p>

<p><b><a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
</b></p>
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
since 1.4.7 Beta 1).</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages</li>
  <li>Interface-specific dynamic blacklisting chains are now displayed by
    "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").</li>
  <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
  <li value="7">The 'shorewall reject' and 'shorewall drop' commands now
    delete any existing rules for the subject IP address before adding a new
    DROP or REJECT rule. Previously, there could be many rules for the same
    IP address in the dynamic chain so that multiple 'allow' commands were
    required to re-enable traffic to/from the address.</li>
  <li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
    /etc/shorewall/masq resulted in a startup error:<br>
    &nbsp;<br>
    &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
    206.124.146.20-206.124.146.24<br>
    <br>
  </li>
  <li>Shorewall previously choked over IPV6 addresses configured on
    interfaces in contexts where Shorewall needed to detect something about
    the interface (such as when "detect" appears in the BROADCAST column of
    the /etc/shorewall/interfaces file).</li>
  <li>Shorewall will now load module files that are formed from the module
    name by appending ".o.gz".</li>
  <li style="font-weight: bold;">When Shorewall adds a route to a proxy ARP
    host and such a route already exists, two routes resulted previously.
    This has been corrected so that the existing route is replaced if it
    already exists.</li>
  <li><span style="font-weight: bold;">The rfc1918 file has been updated to
    reflect recent allocations.</span><br>
  </li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
    see the <a href="Accounting.html">Accounting Page</a> for details.</li>
  <li>The Uset Set capability introduced in SnapShot 20030821 has changed --
    see the <a href="UserSets.html">User Set page</a> for details.</li>
  <li>The per-interface Dynamic Blacklisting facility introduced in the first
    post-1.4.6 Snapshot has been removed. The facility had too many
    idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
  </li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.</li>
  <li>The ADDRESS column in /etc/shorewall/masq may now include a
    comma-separated list of addresses and/or address ranges. Netfilter will
    use all listed addresses/ranges in round-robin fashion. \</li>
  <li>An /etc/shorewall/accounting file has been added to allow for traffic
    accounting.&nbsp; See the <a href="Accounting.html">accounting
    documentation</a> for a description of this facility.</li>
  <li>Bridge interfaces (br[0-9]) may now be used in
  /etc/shorewall/maclist.</li>
  <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
    /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
    rules, rate limiting occurs in the nat table DNAT rule; the corresponding
    ACCEPT rule in the filter table is not rate limited. If you want to limit
    the filter table rule, you will need o create two rules; a DNAT- rule and
    an ACCEPT rule which can be rate-limited separately.<br>
    &nbsp;<br>
    <span style="font-weight: bold;">Warning:</span> When rate limiting is
    specified on a rule with "all" in the SOURCE or DEST fields, the limit
    will apply to each pair of zones individually rather than as a single
    limit for all pairs of covered by the rule.<br>
    &nbsp;<br>
    To specify a rate limit,<br>
    <br>
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
    &nbsp;<br>
    &nbsp; where<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
    &lt;interval&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
    accepted within an &lt;interval&gt;. If not given, the default of 5 is
    assumed.<br>
    &nbsp;<br>
    There may be no white space between the ACTION and "&lt;" nor there may
    be any white space within the burst specification. If you want to specify
    logging of a rate-limited rule, the ":" and log level comes after the
    "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
    <br>
    b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
    file. You may specify the rate limit there in the format:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
    &nbsp;<br>
    Let's take an example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
    &nbsp;&nbsp;&nbsp;<br>
    The first time this rule is reached, the packet will be accepted; in
    fact, since the burst is 4, the first four packets will be accepted.
    After this, it will be 500ms (1 second divided by the rate<br>
    of 2) before a packet will be accepted from this rule, regardless of how
    many packets reach it. Also, every 500ms which passes without matching a
    packet, one of the bursts will be regained; if no packets hit the rule
    for 2 second, the burst will be fully recharged; back where we
    started.<br>
  </li>
  <li>Multiple chains may now be displayed in one "shorewall show" command
    (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
  <li>Output rules (those with $FW as the SOURCE) may now be limited to a set
    of local users and/or groups. See <a
    href="UserSets.html">http://shorewall.net/UserSets.html</a> for
  details.</li>
</ol>

<p><b>9/15/2003 - Shorewall 1.4.7 Beta 2</b> <b><br>
</b></p>

<p><b><a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
</b></p>
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
since 1.4.7 Beta 1).</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages</li>
  <li>Interface-specific dynamic blacklisting chains are now displayed by
    "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").</li>
  <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
  <li value="7" style="font-weight: bold;">The 'shorewall reject' and
    'shorewall drop' commands now delete any existing rules for the subject
    IP address before adding a new DROP or REJECT rule. Previously, there
    could be many rules for the same IP address in the dynamic chain so that
    multiple 'allow' commands were required to re-enable traffic to/from the
    address.</li>
  <li style="font-weight: bold;">When ADD_SNAT_ALIASES=Yes in shorewall.conf,
    the following entry in /etc/shorewall/masq resulted in a startup
    error:<br>
    &nbsp;<br>
    &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
    206.124.146.20-206.124.146.24<br>
    <br>
  </li>
  <li style="font-weight: bold;">Shorewall previously choked over IPV6
    addresses configured on interfaces in contexts where Shorewall needed to
    detect something about the interface (such as when "detect" appears in
    the BROADCAST column of the /etc/shorewall/interfaces file).</li>
  <li><span style="font-weight: bold;">Shorewall will now load module files
    that are formed from the module name by appending ".o.gz".</span><br>
  </li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
    see the <a href="Accounting.html">Accounting Page</a> for details.</li>
  <li>The Uset Set capability introduced in SnapShot 20030821 has changed --
    see the <a href="UserSets.html">User Set page</a> for details.</li>
  <li>The per-interface Dynamic Blacklisting facility introduced in the first
    post-1.4.6 Snapshot has been removed. The facility had too many
    idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
  </li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.</li>
  <li>The ADDRESS column in /etc/shorewall/masq may now include a
    comma-separated list of addresses and/or address ranges. Netfilter will
    use all listed addresses/ranges in round-robin fashion. \</li>
  <li>An /etc/shorewall/accounting file has been added to allow for traffic
    accounting.&nbsp; See the <a href="Accounting.html">accounting
    documentation</a> for a description of this facility.</li>
  <li>Bridge interfaces (br[0-9]) may now be used in
  /etc/shorewall/maclist.</li>
  <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
    /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
    rules, rate limiting occurs in the nat table DNAT rule; the corresponding
    ACCEPT rule in the filter table is not rate limited. If you want to limit
    the filter table rule, you will need o create two rules; a DNAT- rule and
    an ACCEPT rule which can be rate-limited separately.<br>
    &nbsp;<br>
    <span style="font-weight: bold;">Warning:</span> When rate limiting is
    specified on a rule with "all" in the SOURCE or DEST fields, the limit
    will apply to each pair of zones individually rather than as a single
    limit for all pairs of covered by the rule.<br>
    &nbsp;<br>
    To specify a rate limit,<br>
    <br>
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
    &nbsp;<br>
    &nbsp; where<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
    &lt;interval&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
    accepted within an &lt;interval&gt;. If not given, the default of 5 is
    assumed.<br>
    &nbsp;<br>
    There may be no white space between the ACTION and "&lt;" nor there may
    be any white space within the burst specification. If you want to specify
    logging of a rate-limited rule, the ":" and log level comes after the
    "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
    <br>
    b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
    file. You may specify the rate limit there in the format:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
    &nbsp;<br>
    Let's take an example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
    &nbsp;&nbsp;&nbsp;<br>
    The first time this rule is reached, the packet will be accepted; in
    fact, since the burst is 4, the first four packets will be accepted.
    After this, it will be 500ms (1 second divided by the rate<br>
    of 2) before a packet will be accepted from this rule, regardless of how
    many packets reach it. Also, every 500ms which passes without matching a
    packet, one of the bursts will be regained; if no packets hit the rule
    for 2 second, the burst will be fully recharged; back where we
    started.<br>
  </li>
  <li>Multiple chains may now be displayed in one "shorewall show" command
    (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
  <li>Output rules (those with $FW as the SOURCE) may now be limited to a set
    of local users and/or groups. See <a
    href="UserSets.html">http://shorewall.net/UserSets.html</a> for
  details.</li>
</ol>

<p><b>8/27/2003 - Shorewall Mirror in Australia</b></p>

<p>Thanks to Dave Kempe and Solutions First (<a
href="http://www.solutionsfirst.com.au"><font
size="3">http://www.solutionsfirst.com.au</font></a>), there is now a
Shorewall Mirror in Australia:</p>

<div style="margin-left: 40px;">
<a href="http://www.shorewall.com.au" target="_top"><font
size="3">http://www.shorewall.com.au</font></a><br>
<a href="ftp://ftp.shorewall.com.au"><font
size="3">ftp://ftp.shorewall.com.au</font></a> </div>

<p><b>8/26/2003 - French Version of the Shorewall Setup Guide&nbsp;</b></p>
Thanks to Fabien <font size="3">Demassieux, there is now a <a
href="shorewall_setup_guide_fr.htm">French translation of the Shorewall Setup
Guide</a>. Merci Beacoup, Fabien!</font> 

<p><b>8/25/2003 - Shorewall 1.4.7 Beta 1</b> <b><br>
</b></p>

<p><b><a
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://shorewall.net/pub/shorewall/Beta"
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
</b></p>
<b>Problems Corrected since version 1.4.6</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages</li>
  <li>Interface-specific dynamic blacklisting chains are now displayed by
    "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").</li>
  <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
    <br>
  </li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
    see the <a href="Accounting.html">Accounting Page</a> for details.</li>
  <li>The Uset Set capability introduced in SnapShot 20030821 has changed --
    see the <a href="UserSets.html">User Set page</a> for details.</li>
  <li>The per-interface Dynamic Blacklisting facility introduced in the first
    post-1.4.6 Snapshot has been removed. The facility had too many
    idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
  </li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.</li>
  <li>The ADDRESS column in /etc/shorewall/masq may now include a
    comma-separated list of addresses and/or address ranges. Netfilter will
    use all listed addresses/ranges in round-robin fashion. \</li>
  <li>An /etc/shorewall/accounting file has been added to allow for traffic
    accounting.&nbsp; See the <a href="Accounting.html">accounting
    documentation</a> for a description of this facility.</li>
  <li>Bridge interfaces (br[0-9]) may now be used in
  /etc/shorewall/maclist.</li>
  <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
    /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
    rules, rate limiting occurs in the nat table DNAT rule; the corresponding
    ACCEPT rule in the filter table is not rate limited. If you want to limit
    the filter table rule, you will need o create two rules; a DNAT- rule and
    an ACCEPT rule which can be rate-limited separately.<br>
    &nbsp;<br>
    <span style="font-weight: bold;">Warning:</span> When rate limiting is
    specified on a rule with "all" in the SOURCE or DEST fields, the limit
    will apply to each pair of zones individually rather than as a single
    limit for all pairs of covered by the rule.<br>
    &nbsp;<br>
    To specify a rate limit,<br>
    <br>
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
    &nbsp;<br>
    &nbsp; where<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
    &lt;interval&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
    accepted within an &lt;interval&gt;. If not given, the default of 5 is
    assumed.<br>
    &nbsp;<br>
    There may be no white space between the ACTION and "&lt;" nor there may
    be any white space within the burst specification. If you want to specify
    logging of a rate-limited rule, the ":" and log level comes after the
    "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
    <br>
    b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
    file. You may specify the rate limit there in the format:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
    &nbsp;<br>
    Let's take an example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
    &nbsp;&nbsp;&nbsp;<br>
    The first time this rule is reached, the packet will be accepted; in
    fact, since the burst is 4, the first four packets will be accepted.
    After this, it will be 500ms (1 second divided by the rate<br>
    of 2) before a packet will be accepted from this rule, regardless of how
    many packets reach it. Also, every 500ms which passes without matching a
    packet, one of the bursts will be regained; if no packets hit the rule
    for 2 second, the burst will be fully recharged; back where we
    started.<br>
  </li>
  <li>Multiple chains may now be displayed in one "shorewall show" command
    (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
  <li>Output rules (those with $FW as the SOURCE) may now be limited to a set
    of local users and/or groups. See <a
    href="UserSets.html">http://shorewall.net/UserSets.html</a> for
    details.<br>
  </li>
</ol>

<p><b>8/23/2003 - Snapshot 1.4.6_2003082</b><span
style="font-weight: bold;">3</span></p>

<blockquote>
  <p><a
  href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
  <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
  target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
</blockquote>
<b>Problems Corrected since version 1.4.6</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages</li>
  <li>Interface-specific dynamic blacklisting chains are now displayed by
    "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").</li>
  <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
    <br>
  </li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Once you have installed this version of Shorewall, you must restart
    Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
    commands.</li>
  <li>To maintain strict compatibility with previous versions, current uses
    of "shorewall drop" and "shorewall reject" should be replaced with
    "shorewall dropall" and "shorewall rejectall"</li>
  <li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
    see the <a href="Accounting.html">Accounting Page</a> for details.</li>
  <li>The Uset Set capability introduced in SnapShot 20030821 has changed --
    see the <a href="UserSets.html">User Set page</a> for details.</li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Shorewall now creates a dynamic blacklisting chain for each interface
    defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
    use the routing table to determine which of these chains is to be used
    for blacklisting the specified IP address(es).<br>
    <br>
    Two new commands ('dropall' and 'rejectall') have been introduced that do
    what 'drop' and 'reject' used to do; namely, when an address is
    blacklisted using these new commands, it will be blacklisted on all of
    your firewall's interfaces.</li>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.</li>
  <li>The ADDRESS column in /etc/shorewall/masq may now include a
    comma-separated list of addresses and/or address ranges. Netfilter will
    use all listed addresses/ranges in round-robin fashion. \</li>
  <li>An /etc/shorewall/accounting file has been added to allow for traffic
    accounting.&nbsp; See the <a href="Accounting.html">accounting
    documentation</a> for a description of this facility.</li>
  <li>Bridge interfaces (br[0-9]) may now be used in
  /etc/shorewall/maclist.</li>
  <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
    /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
    rules, rate limiting occurs in the nat table DNAT rule; the corresponding
    ACCEPT rule in the filter table is not rate limited. If you want to limit
    the filter table rule, you will need o create two rules; a DNAT- rule and
    an ACCEPT rule which can be rate-limited separately.<br>
    &nbsp;<br>
    <span style="font-weight: bold;">Warning:</span> When rate limiting is
    specified on a rule with "all" in the SOURCE or DEST fields, the limit
    will apply to each pair of zones individually rather than as a single
    limit for all pairs of covered by the rule.<br>
    &nbsp;<br>
    To specify a rate limit,<br>
    <br>
    a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
    &nbsp;<br>
    &nbsp; where<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
    &lt;interval&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
    accepted within an &lt;interval&gt;. If not given, the default of 5 is
    assumed.<br>
    &nbsp;<br>
    There may be no white space between the ACTION and "&lt;" nor there may
    be any white space within the burst specification. If you want to specify
    logging of a rate-limited rule, the ":" and log level comes after the
    "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
    <br>
    b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
    file. You may specify the rate limit there in the format:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
    &nbsp;<br>
    Let's take an example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
    &nbsp;&nbsp;&nbsp;<br>
    The first time this rule is reached, the packet will be accepted; in
    fact, since the burst is 4, the first four packets will be accepted.
    After this, it will be 500ms (1 second divided by the rate<br>
    of 2) before a packet will be accepted from this rule, regardless of how
    many packets reach it. Also, every 500ms which passes without matching a
    packet, one of the bursts will be regained; if no packets hit the rule
    for 2 second, the burst will be fully recharged; back where we
    started.<br>
  </li>
  <li>Multiple chains may now be displayed in one "shorewall show" command
    (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
  <li>Output rules (those with $FW as the SOURCE) may now be limited to a set
    of local users and/or groups. See <a
    href="UserSets.html">http://shorewall.net/UserSets.html</a> for
    details.<br>
  </li>
</ol>

<p><b>8/13/2003 - Snapshot 1.4.6_20030813</b><b>&nbsp;</b></p>

<blockquote>
  <p><a
  href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
  <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
  target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
</blockquote>
<b>Problems Corrected since version 1.4.6</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages</li>
  <li>&nbsp;Interface-specific dynamic blacklisting chains are now displayed
    by "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").<br>
    <br>
  </li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Once you have installed this version of Shorewall, you must restart
    Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
    commands.</li>
  <li>To maintain strict compatibility with previous versions, current uses
    of "shorewall drop" and "shorewall reject" should be replaced with
    "shorewall dropall" and "shorewall rejectall"</li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Shorewall now creates a dynamic blacklisting chain for each interface
    defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
    use the routing table to determine which of these chains is to be used
    for blacklisting the specified IP address(es).<br>
    <br>
    Two new commands ('dropall' and 'rejectall') have been introduced that do
    what 'drop' and 'reject' used to do; namely, when an address is
    blacklisted using these new commands, it will be blacklisted on all of
    your firewall's interfaces.</li>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.</li>
  <li>The ADDRESS column in /etc/shorewall/masq may now include a
    comma-separated list of addresses and/or address ranges. Netfilter will
    use all listed addresses/ranges in round-robin fashion. \</li>
  <li>An /etc/shorewall/accounting file has been added to allow for traffic
    accounting.&nbsp; See the <a href="Accounting.html">accounting
    documentation</a> for a description of this facility.</li>
  <li>Bridge interfaces (br[0-9]) may now be used in
  /etc/shorewall/maclist.</li>
  <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
    /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
    rules, rate limiting occurs in the nat table DNAT rule; the corresponding
    ACCEPT rule in the filter table is not rate limited. If you want to limit
    the filter table rule, you will need o create two rules; a DNAT- rule and
    an ACCEPT rule which can be rate-limited separately.<br>
    &nbsp;<br>
    <span style="font-weight: bold;">Warning:</span> When rate limiting is
    specified on a rule with "all" in the SOURCE or DEST fields, the limit
    will apply to each pair of zones individually rather than as a single
    limit for all pairs of covered by the rule.<br>
    &nbsp;<br>
    To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG
    with<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
    &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
    &nbsp;<br>
    &nbsp;&nbsp; where<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained rate per
    &lt;interval&gt;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or "min"<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest burst
    accepted within an &lt;interval&gt;. If not given, the default of 5 is
    assumed.<br>
    &nbsp;<br>
    There may be no white space between the ACTION and "&lt;" nor there may
    be any white space within the burst specification. If you want to specify
    logging of a rate-limited rule, the ":" and log level comes after the
    "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
    &nbsp;<br>
    Let's take an example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
    tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
    &nbsp;&nbsp;&nbsp;<br>
    The first time this rule is reached, the packet will be accepted; in
    fact, since the burst is 4, the first four packets will be accepted.
    After this, it will be 500ms (1 second divided by the rate<br>
    of 2) before a packet will be accepted from this rule, regardless of how
    many packets reach it. Also, every 500ms which passes without matching a
    packet, one of the bursts will be regained; if no packets hit the rule
    for 2 second, the burst will be fully recharged; back where we
    started.<br>
  </li>
</ol>

<p><b>8/9/2003 - Snapshot 1.4.6_20030809</b><b>&nbsp;</b></p>

<blockquote>
  <p><a
  href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
  <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
  target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
</blockquote>
<b>Problems Corrected since version 1.4.6</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages<br>
  </li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Once you have installed this version of Shorewall, you must restart
    Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
    commands.</li>
  <li>To maintain strict compatibility with previous versions, current uses
    of "shorewall drop" and "shorewall reject" should be replaced with
    "shorewall dropall" and "shorewall rejectall"</li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Shorewall now creates a dynamic blacklisting chain for each interface
    defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
    use the routing table to determine which of these chains is to be used
    for blacklisting the specified IP address(es).<br>
    <br>
    Two new commands ('dropall' and 'rejectall') have been introduced that do
    what 'drop' and 'reject' used to do; namely, when an address is
    blacklisted using these new commands, it will be blacklisted on all of
    your firewall's interfaces.</li>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
  <li>Given the wide range of VPN software, I can never hope to add specific
    support for all of it. I have therefore decided to add "generic" tunnel
    support.<br>
    &nbsp;<br>
    Generic tunnels work pretty much like any of the other tunnel types. You
    usually add a zone to represent the systems at the other end of the
    tunnel and you add the appropriate rules/policies to<br>
    implement your security policy regarding traffic to/from those
    systems.<br>
    &nbsp;<br>
    In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
    <br>
    generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp; &lt;zone&gt;&nbsp; &lt;ip
    address&gt;&nbsp;&nbsp;&nbsp; &lt;gateway zones&gt;<br>
    &nbsp;<br>
    where:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the protocol
    used by the tunnel<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if the protocol
    is 'udp' or 'tcp' then this is the destination port number used by the
    tunnel.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is the zone of
    the remote tunnel gateway<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is the IP address
    of the remote tunnel gateway.<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway zone&gt;&nbsp;&nbsp;
    Optional. A comma-separated list of zone names. If specified, the remote
    gateway is to be considered part of these zones.</li>
  <li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
    file. This option causes
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
    result that this interface will only answer ARP 'who-has' requests from
    hosts that are routed out through that interface. Setting this option
    facilitates testing of your firewall where multiple firewall interfaces
    are connected to the same HUB/Switch (all interfaces connected to the
    single HUB/Switch should have this option specified). Note that using
    such a configuration in a production environment is strongly recommended
    against.<br>
  </li>
</ol>

<p><b>8/5/2003 - Shorewall-1.4.6b</b><b>&nbsp;<br>
</b></p>
<b>Problems Corrected since version 1.4.6:</b><br>

<ol>
  <li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
    Shorewall would fail to start with the error "ERROR: &nbsp;Traffic
    Control requires Mangle"; that problem has been corrected.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error
  messages.</li>
</ol>

<p><b>8/5/2003 - Shorewall-1.4.6b</b> <b><br>
</b></p>
<b>Problems Corrected since version 1.4.6:</b><br>

<ol>
  <li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
    Shorewall would fail to start with the error "ERROR: &nbsp;Traffic
    Control requires Mangle"; that problem has been corrected.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
  command.</li>
  <li>The "shorewall stop" command is now disabled when
    /etc/shorewall/startup_disabled exists. This prevents people from
    shooting themselves in the foot prior to having configured Shorewall.</li>
  <li>A change introduced in version 1.4.6 caused error messages during
    "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
    added to a PPP interface; the addresses were successfully added in spite
    of the messages.<br>
    &nbsp;&nbsp;<br>
    The firewall script has been modified to eliminate the error messages.<br>
  </li>
</ol>

<p><b>7/31/2003 - Snapshot 1.4.6_20030731</b></p>

<blockquote>
  <p><a
  href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
  <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
  target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
</blockquote>

<p><b>Problems Corrected since version 1.4.6:</b><br>
</p>
<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
    command.<br>
  </li>
</ol>

<p><b>Migration Issues:</b><br>
</p>
<ol>
  <li>Once you have installed this version of Shorewall, you must restart
    Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
    commands.</li>
  <li>To maintain strict compatibility with previous versions, current uses
    of "shorewall drop" and "shorewall reject" should be replaced with
    "shorewall dropall" and "shorewall rejectall"</li>
</ol>

<p><b>New Features:</b><br>
</p>
<ol>
  <li>Shorewall now creates a dynamic blacklisting chain for each interface
    defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
    use the routing table to determine which of these chains is to be used
    for blacklisting the specified IP address(es).<br>
    <br>
    Two new commands ('dropall' and 'rejectall') have been introduced that do
    what 'drop' and 'reject' used to do; namely, when an address is
    blacklisted using these new commands, it will be blacklisted on all of
    your firewall's interfaces.</li>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).</li>
  <li>A new option "ADMINISABSENTMINDED" has been added to
    /etc/shorewall/shorewall.conf. This option has a default value of "No"
    for existing users which causes Shorewall's 'stopped' state &nbsp;to
    continue as it has been; namely, in the stopped state only traffic
    to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
    <br>
    With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
    to traffic to/from the hosts listed in /etc/shorewall/routestopped,
    Shorewall will allow:<br>
    <br>
    &nbsp;&nbsp; a) All traffic originating from the firewall itself; and<br>
    &nbsp;&nbsp; b) All traffic that is part of or related to an
    already-existing connection.<br>
    <br>
    &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
    entered through an ssh session will not kill the session.<br>
    <br>
    &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it is still
    possible for people to shoot themselves in the foot.<br>
    <br>
    &nbsp;Example:<br>
    <br>
    &nbsp;/etc/shorewall/nat:<br>
    <br>
    &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
    eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
    <br>
    &nbsp;/etc/shorewall/rules:<br>
    <br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
    loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
    fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    <br>
    From a remote system, I ssh to 206.124.146.178 which establishes an SSH
    connection with local system 192.168.1.5. I then create a second SSH
    connection from that computer to the firewall and confidently type
    "shorewall stop". As part of its stop processing, Shorewall removes
    eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
</ol>

<p><b>7/27/2003 - Snapshot 1.4.6_20030727</b></p>

<blockquote>
  <p><a
  href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
  <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
  target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
</blockquote>
<b>Problems Corrected since version 1.4.6</b><br>

<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
    command.<br>
  </li>
</ol>
<b>Migration Issues:</b><br>

<ol>
  <li>Once you have installed this version of Shorewall, you must restart
    Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
    commands.</li>
  <li>To maintain strict compatibility with previous versions, current uses
    of "shorewall drop" and "shorewall reject" should be replaced with
    "shorewall dropall" and "shorewall rejectall"</li>
</ol>
<b>New Features:</b><br>

<ol>
  <li>Shorewall now creates a dynamic blacklisting chain for each interface
    defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
    use the routing table to determine which of these chains is to be used
    for blacklisting the specified IP address(es).<br>
    <br>
    Two new commands ('dropall' and 'rejectall') have been introduced that do
    what 'drop' and 'reject' used to do; namely, when an address is
    blacklisted using these new commands, it will be blacklisted on all of
    your firewall's interfaces.</li>
  <li>Thanks to Steve Herber, the 'help' command can now give
    command-specific help (e.g., shorewall help &lt;command&gt;).<br>
  </li>
</ol>

<p><b>7/26/2003 - Snapshot 1.4.6_20030726</b></p>

<blockquote>
  <p><a
  href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
  <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
  target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
</blockquote>

<p><b>Problems Corrected since version 1.4.6:</b><br>
</p>
<ol>
  <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
    tested before it was set.</li>
  <li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
    file. Previously, these addresses resulted in an invalid iptables
    command.<br>
  </li>
</ol>

<p><b>Migration Issues:</b><br>
</p>
<ol>
  <li>Once you have installed this version of Shorewall, you must restart
    Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
    commands.</li>
  <li>To maintain strict compatibility with previous versions, current uses
    of "shorewall drop" and "shorewall reject" should be replaced with
    "shorewall dropall" and "shorewall rejectall"</li>
</ol>

<p><b>New Features:</b><br>
</p>
Shorewall now creates a dynamic blacklisting chain for each interface defined
in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
routing table to determine which of these chains is to be used for
blacklisting the specified IP address(es).<br>
<br>
Two new commands ('dropall' and 'rejectall') have been introduced that do
what 'drop' and 'reject' used to do; namely, when an address is blacklisted
using these new commands, it will be blacklisted on all of your firewall's
interfaces. 

<p><b>7/22/2003 - Shorewall-1.4.6a</b> <b><br>
</b></p>
<b>Problems Corrected:</b><br>

<ol>
  <li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
    Shorewall would fail to start with the error "ERROR: &nbsp;Traffic
    Control requires Mangle"; that problem has been corrected.</li>
</ol>

<p><b>7/20/2003 - Shorewall-1.4.6</b> <b><br>
</b></p>

<p><b>Problems Corrected:</b><br>
</p>
<ol>
  <li>A problem seen on RH7.3 systems where Shorewall encountered start
    errors when started using the "service" mechanism has been worked
    around.<br>
    <br>
  </li>
  <li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
    rule, Shorewall incorrectly created multiple DNAT rules in the nat table
    (one for each element in the list). Shorewall now correctly creates a
    single DNAT rule with multiple "--to-destination" clauses.<br>
    <br>
  </li>
  <li>Corrected a problem in Beta 1 where DNS names containing a "-" were
    mis-handled when they appeared in the DEST column of a rule.<br>
    <br>
  </li>
  <li>A number of problems with rule parsing have been corrected. Corrections
    involve the handling of "z1!z2" in the SOURCE column as well as lists in
    the ORIGINAL DESTINATION column.<br>
    <br>
  </li>
  <li>The message "Adding rules for DHCP" is now suppressed if there are no
    DHCP rules to add.<br>
  </li>
</ol>

<p><b>Migration Issues:</b><br>
</p>
<ol>
  <li>In earlier versions, an undocumented feature allowed entries in the
    host file as follows:<br>
    <br>
    &nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
    <br>
    This capability was never documented and has been removed in 1.4.6 to
    allow entries of the following format:<br>
    <br>
    &nbsp; &nbsp; z&nbsp;&nbsp; eth1:192.168.1.0/24,192.168.2.0/24<br>
    <br>
  </li>
  <li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
    from /etc/shorewall/shorewall.conf. These capabilities are now
    automatically detected by Shorewall (see below).<br>
  </li>
</ol>

<p><b>New Features:</b><br>
</p>
<ol>
  <li>A 'newnotsyn' interface option has been added. This option may be
    specified in /etc/shorewall/interfaces and overrides the setting
    NEWNOTSYN=No for packets arriving on the associated interface.<br>
    <br>
  </li>
  <li>The means for specifying a range of IP addresses in /etc/shorewall/masq
    to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
    address ranges.<br>
    <br>
  </li>
  <li>Shorewall can now add IP addresses to subnets other than the first one
    on an interface.<br>
    <br>
  </li>
  <li>DNAT[-] rules may now be used to load balance (round-robin) over a set
    of servers. Servers may be specified in a range of addresses given as
    &lt;first address&gt;-&lt;last address&gt;.<br>
    <br>
    Example:<br>
    <br>
    &nbsp; &nbsp; DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
    <br>
  </li>
  <li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
    have been removed and have been replaced by code that detects whether
    these capabilities are present in the current kernel. The output of the
    start, restart and check commands have been enhanced to report the
    outcome:<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    Verifying Configuration...<br>
    <br>
  </li>
  <li>Support for the Connection Tracking Match Extension has been added.
    This extension is available in recent kernel/iptables releases and allows
    for rules which match against elements in netfilter's connection tracking
    table. Shorewall automatically detects the availability of this extension
    and reports its availability in the output of the start, restart and
    check commands.<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    &nbsp; &nbsp;Connection Tracking Match: Available<br>
    Verifying Configuration...<br>
    <br>
    If this extension is available, the ruleset generated by Shorewall is
    changed in the following ways:</li>
  <li
  style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
      <li>To handle 'norfc1918' filtering, Shorewall will not create chains
        in the mangle table but will rather do all 'norfc1918' filtering in
        the filter table (rfc1918 chain).</li>
      <li>Recall that Shorewall DNAT rules generate two netfilter rules; one
        in the nat table and one in the filter table. If the Connection
        Tracking Match Extension is available, the rule in the filter table
        is extended to check that the original destination address was the
        same as specified (or defaulted to) in the DNAT rule.<br>
        <br>
      </li>
    </ul>
  </li>
  <li>The shell used to interpret the firewall script
    (/usr/share/shorewall/firewall) may now be specified using the
    SHOREWALL_SHELL parameter in shorewall.conf.<br>
    <br>
  </li>
  <li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt; &lt;netmask&gt; |
    &lt;address&gt;/&lt;vlsm&gt; ]<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
    192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    BROADCAST=192.168.1.255<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
    192.168.1.0 255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    BROADCAST=192.168.1.255<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
    <br>
    Warning:<br>
    <br>
    If your shell only supports 32-bit signed arithmatic (ash or dash), then
    the ipcalc command produces incorrect information for IP addresses
    128.0.0.0-1 and for /1 networks. Bash should produce correct information
    for all valid IP addresses.<br>
    <br>
  </li>
  <li>An 'iprange' command has been added to /sbin/shorewall.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iprange &lt;address&gt;-&lt;address&gt;<br>
    <br>
    This command decomposes a range of IP addressses into a list of network
    and host addresses. The command can be useful if you need to construct an
    efficient set of rules that accept connections from a range of network
    addresses.<br>
    <br>
    Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
    then the range may not span 128.0.0.0.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]# shorewall iprange
    192.168.1.4-192.168.12.9<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]#<br>
    <br>
  </li>
  <li>A list of host/net addresses is now allowed in an entry in
    /etc/shorewall/hosts.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
    eth1:192.168.1.0/24,192.168.2.0/24<br>
    <br>
  </li>
  <li>The "shorewall check" command now includes the chain name when printing
    the applicable policy for each pair of zones.<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp; Example:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Policy for dmz to net is
    REJECT using chain all2all<br>
    &nbsp;<br>
    This means that the policy for connections from the dmz to the internet
    is REJECT and the applicable entry in the /etc/shorewall/policy was the
    all-&gt;all policy.<br>
    <br>
  </li>
  <li>Support for the 2.6 Kernel series has been added.<br>
  </li>
</ol>

<p><b>7/15/2003 - New Mirror in Brazil</b><b><br>
</b></p>
Thanks to the folks at securityopensource.org.br, there is now a <a
href="http://shorewall.securityopensource.org.br" target="_top">Shorewall
mirror in Brazil</a>. 

<p><b>7/15/2003 - Shorewall-1.4.6 RC 1</b> <b><br>
</b></p>

<p><b>Problems Corrected:</b><br>
</p>
<ol>
  <li>A problem seen on RH7.3 systems where Shorewall encountered start
    errors when started using the "service" mechanism has been worked
    around.<br>
    <br>
  </li>
  <li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
    rule, Shorewall incorrectly created multiple DNAT rules in the nat table
    (one for each element in the list). Shorewall now correctly creates a
    single DNAT rule with multiple "--to-destination" clauses.<br>
    <br>
  </li>
  <li>Corrected a problem in Beta 1 where DNS names containing a "-" were
    mis-handled when they appeared in the DEST column of a rule.<br>
    <br>
  </li>
  <li>A number of problems with rule parsing have been corrected. Corrections
    involve the handling of "z1!z2" in the SOURCE column as well as lists in
    the ORIGINAL DESTINATION column.<br>
  </li>
</ol>

<p><b>Migration Issues:</b><br>
</p>
<ol>
  <li>In earlier versions, an undocumented feature allowed entries in the
    host file as follows:<br>
    <br>
    &nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
    <br>
    This capability was never documented and has been removed in 1.4.6 to
    allow entries of the following format:<br>
    <br>
    &nbsp; &nbsp; z&nbsp;&nbsp; eth1:192.168.1.0/24,192.168.2.0/24<br>
    <br>
  </li>
  <li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
    from /etc/shorewall/shorewall.conf. These capabilities are now
    automatically detected by Shorewall (see below).<br>
  </li>
</ol>

<p><b>New Features:</b><br>
</p>
<ol>
  <li>A 'newnotsyn' interface option has been added. This option may be
    specified in /etc/shorewall/interfaces and overrides the setting
    NEWNOTSYN=No for packets arriving on the associated interface.<br>
    <br>
  </li>
  <li>The means for specifying a range of IP addresses in /etc/shorewall/masq
    to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
    address ranges.<br>
    <br>
  </li>
  <li>Shorewall can now add IP addresses to subnets other than the first one
    on an interface.<br>
    <br>
  </li>
  <li>DNAT[-] rules may now be used to load balance (round-robin) over a set
    of servers. Servers may be specified in a range of addresses given as
    &lt;first address&gt;-&lt;last address&gt;.<br>
    <br>
    Example:<br>
    <br>
    &nbsp; &nbsp; DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
    <br>
  </li>
  <li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
    have been removed and have been replaced by code that detects whether
    these capabilities are present in the current kernel. The output of the
    start, restart and check commands have been enhanced to report the
    outcome:<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    Verifying Configuration...<br>
    <br>
  </li>
  <li>Support for the Connection Tracking Match Extension has been added.
    This extension is available in recent kernel/iptables releases and allows
    for rules which match against elements in netfilter's connection tracking
    table. Shorewall automatically detects the availability of this extension
    and reports its availability in the output of the start, restart and
    check commands.<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    &nbsp; &nbsp;Connection Tracking Match: Available<br>
    Verifying Configuration...<br>
    <br>
    If this extension is available, the ruleset generated by Shorewall is
    changed in the following ways:</li>
  <li
  style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
      <li>To handle 'norfc1918' filtering, Shorewall will not create chains
        in the mangle table but will rather do all 'norfc1918' filtering in
        the filter table (rfc1918 chain).</li>
      <li>Recall that Shorewall DNAT rules generate two netfilter rules; one
        in the nat table and one in the filter table. If the Connection
        Tracking Match Extension is available, the rule in the filter table
        is extended to check that the original destination address was the
        same as specified (or defaulted to) in the DNAT rule.<br>
        <br>
      </li>
    </ul>
  </li>
  <li>The shell used to interpret the firewall script
    (/usr/share/shorewall/firewall) may now be specified using the
    SHOREWALL_SHELL parameter in shorewall.conf.<br>
    <br>
  </li>
  <li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt; &lt;netmask&gt; |
    &lt;address&gt;/&lt;vlsm&gt; ]<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
    192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    BROADCAST=192.168.1.255<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
    192.168.1.0 255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    BROADCAST=192.168.1.255<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
    <br>
    Warning:<br>
    <br>
    If your shell only supports 32-bit signed arithmatic (ash or dash), then
    the ipcalc command produces incorrect information for IP addresses
    128.0.0.0-1 and for /1 networks. Bash should produce correct information
    for all valid IP addresses.<br>
    <br>
  </li>
  <li>An 'iprange' command has been added to /sbin/shorewall.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iprange &lt;address&gt;-&lt;address&gt;<br>
    <br>
    This command decomposes a range of IP addressses into a list of network
    and host addresses. The command can be useful if you need to construct an
    efficient set of rules that accept connections from a range of network
    addresses.<br>
    <br>
    Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
    then the range may not span 128.0.0.0.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]# shorewall iprange
    192.168.1.4-192.168.12.9<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]#<br>
    <br>
  </li>
  <li>A list of host/net addresses is now allowed in an entry in
    /etc/shorewall/hosts.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
    eth1:192.168.1.0/24,192.168.2.0/24</li>
</ol>

<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b></p>

<p><b>Problems Corrected:</b><br>
</p>
<ol>
  <li>A problem seen on RH7.3 systems where Shorewall encountered start
    errors when started using the "service" mechanism has been worked
    around.<br>
    <br>
  </li>
  <li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
    rule, Shorewall incorrectly created multiple DNAT rules in the nat table
    (one for each element in the list). Shorewall now correctly creates a
    single DNAT rule with multiple "--to-destination" clauses.<br>
    <br>
  </li>
  <li>Corrected a problem in Beta 1 where DNS names containing a "-" were
    mis-handled when they appeared in the DEST column of a rule.<br>
  </li>
</ol>

<p><b>Migration Issues:</b><br>
</p>
<ol>
  <li>In earlier versions, an undocumented feature allowed entries in the
    host file as follows:<br>
    <br>
    &nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
    <br>
    This capability was never documented and has been removed in 1.4.6 to
    allow entries of the following format:<br>
    <br>
    &nbsp; &nbsp; z&nbsp;&nbsp; eth1:192.168.1.0/24,192.168.2.0/24<br>
    <br>
  </li>
  <li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
    from /etc/shorewall/shorewall.conf. These capabilities are now
    automatically detected by Shorewall (see below).<br>
  </li>
</ol>

<p><b>New Features:</b><br>
</p>
<ol>
  <li>A 'newnotsyn' interface option has been added. This option may be
    specified in /etc/shorewall/interfaces and overrides the setting
    NEWNOTSYN=No for packets arriving on the associated interface.<br>
    <br>
  </li>
  <li>The means for specifying a range of IP addresses in /etc/shorewall/masq
    to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
    address ranges.<br>
    <br>
  </li>
  <li>Shorewall can now add IP addresses to subnets other than the first one
    on an interface.<br>
    <br>
  </li>
  <li>DNAT[-] rules may now be used to load balance (round-robin) over a set
    of servers. Servers may be specified in a range of addresses given as
    &lt;first address&gt;-&lt;last address&gt;.<br>
    <br>
    Example:<br>
    <br>
    &nbsp; &nbsp; DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
    <br>
  </li>
  <li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
    have been removed and have been replaced by code that detects whether
    these capabilities are present in the current kernel. The output of the
    start, restart and check commands have been enhanced to report the
    outcome:<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    Verifying Configuration...<br>
    <br>
  </li>
  <li>Support for the Connection Tracking Match Extension has been added.
    This extension is available in recent kernel/iptables releases and allows
    for rules which match against elements in netfilter's connection tracking
    table. Shorewall automatically detects the availability of this extension
    and reports its availability in the output of the start, restart and
    check commands.<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    &nbsp; &nbsp;Connection Tracking Match: Available<br>
    Verifying Configuration...<br>
    <br>
    If this extension is available, the ruleset generated by Shorewall is
    changed in the following ways:</li>
  <li
  style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
      <li>To handle 'norfc1918' filtering, Shorewall will not create chains
        in the mangle table but will rather do all 'norfc1918' filtering in
        the filter table (rfc1918 chain).</li>
      <li>Recall that Shorewall DNAT rules generate two netfilter rules; one
        in the nat table and one in the filter table. If the Connection
        Tracking Match Extension is available, the rule in the filter table
        is extended to check that the original destination address was the
        same as specified (or defaulted to) in the DNAT rule.<br>
        <br>
      </li>
    </ul>
  </li>
  <li>The shell used to interpret the firewall script
    (/usr/share/shorewall/firewall) may now be specified using the
    SHOREWALL_SHELL parameter in shorewall.conf.<br>
    <br>
  </li>
  <li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt; &lt;netmask&gt; |
    &lt;address&gt;/&lt;vlsm&gt; ]<br>
    <br>
    Examples:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
    192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    BROADCAST=192.168.1.255<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall ipcalc
    192.168.1.0 255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CIDR=192.168.1.0/24<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETMASK=255.255.255.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NETWORK=192.168.1.0<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    BROADCAST=192.168.1.255<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
    <br>
    Warning:<br>
    <br>
    If your shell only supports 32-bit signed arithmatic (ash or dash), then
    the ipcalc command produces incorrect information for IP addresses
    128.0.0.0-1 and for /1 networks. Bash should produce correct information
    for all valid IP addresses.<br>
    <br>
  </li>
  <li>An 'iprange' command has been added to /sbin/shorewall.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iprange &lt;address&gt;-&lt;address&gt;<br>
    <br>
    This command decomposes a range of IP addressses into a list of network
    and host addresses. The command can be useful if you need to construct an
    efficient set of rules that accept connections from a range of network
    addresses.<br>
    <br>
    Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
    then the range may not span 128.0.0.0.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]# shorewall iprange
    192.168.1.4-192.168.12.9<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]#<br>
    <br>
  </li>
  <li>A list of host/net addresses is now allowed in an entry in
    /etc/shorewall/hosts.<br>
    <br>
    Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
    eth1:192.168.1.0/24,192.168.2.0/24<br>
    <br>
  </li>
</ol>

<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b></p>

<p><b>Problems Corrected:</b><br>
</p>
<ol>
  <li>A problem seen on RH7.3 systems where Shorewall encountered start
    errors when started using the "service" mechanism has been worked
    around.<br>
    <br>
  </li>
  <li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
    rule, Shorewall incorrectly created multiple DNAT rules in the nat table
    (one for each element in the list). Shorewall now correctly creates a
    single DNAT rule with multiple "--to-destination" clauses.<br>
  </li>
</ol>

<p><b>New Features:</b><br>
</p>
<ol>
  <li>A 'newnotsyn' interface option has been added. This option may be
    specified in /etc/shorewall/interfaces and overrides the setting
    NEWNOTSYN=No for packets arriving on the associated interface.<br>
    <br>
  </li>
  <li>The means for specifying a range of IP addresses in /etc/shorewall/masq
    to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
    address ranges.<br>
    <br>
  </li>
  <li>Shorewall can now add IP addresses to subnets other than the first one
    on an interface.<br>
    <br>
  </li>
  <li>DNAT[-] rules may now be used to load balance (round-robin) over a set
    of servers. Up to 256 servers may be specified in a range of addresses
    given as &lt;first address&gt;-&lt;last address&gt;.<br>
    <br>
    Example:<br>
    <br>
    &nbsp; &nbsp; DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
    <br>
    Note that this capability has previously been available using a
    combination of a DNAT- rule and one or more ACCEPT rules. That technique
    is still preferable for load-balancing over a large number of servers
    (&gt; 16) since specifying a range in the DNAT rule causes one filter
    table ACCEPT rule to be generated for each IP address in the range.<br>
    <br>
  </li>
  <li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
    have been removed and have been replaced by code that detects whether
    these capabilities are present in the current kernel. The output of the
    start, restart and check commands have been enhanced to report the
    outcome:<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    Verifying Configuration...<br>
    <br>
  </li>
  <li>Support for the Connection Tracking Match Extension has been added.
    This extension is available in recent kernel/iptables releases and allows
    for rules which match against elements in netfilter's connection tracking
    table. Shorewall automatically detects the availability of this extension
    and reports its availability in the output of the start, restart and
    check commands.<br>
    <br>
    Shorewall has detected the following iptables/netfilter capabilities:<br>
    &nbsp; &nbsp;NAT: Available<br>
    &nbsp; &nbsp;Packet Mangling: Available<br>
    &nbsp; &nbsp;Multi-port Match: Available<br>
    &nbsp; &nbsp;Connection Tracking Match: Available<br>
    Verifying Configuration...<br>
    <br>
    If this extension is available, the ruleset generated by Shorewall is
    changed in the following ways:</li>
  <li
  style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
      <li>To handle 'norfc1918' filtering, Shorewall will not create chains
        in the mangle table but will rather do all 'norfc1918' filtering in
        the filter table (rfc1918 chain).</li>
      <li>Recall that Shorewall DNAT rules generate two netfilter rules; one
        in the nat table and one in the filter table. If the Connection
        Tracking Match Extension is available, the rule in the filter table
        is extended to check that the original destination address was the
        same as specified (or defaulted to) in the DNAT rule.<br>
        <br>
      </li>
    </ul>
  </li>
  <li>The shell used to interpret the firewall script
    (/usr/share/shorewall/firewall) may now be specified using the
    SHOREWALL_SHELL parameter in shorewall.conf.<br>
  </li>
</ol>

<p><b>6/17/2003 - Shorewall-1.4.5</b></p>

<p>Problems Corrected:<br>
</p>
<ol>
  <li>The command "shorewall debug try &lt;directory&gt;" now correctly
    traces the attempt.</li>
  <li>The INCLUDE directive now works properly in the zones file; previously,
    INCLUDE in that file was ignored.</li>
  <li>/etc/shorewall/routestopped records with an empty second column are no
    longer ignored.<br>
  </li>
</ol>

<p>New Features:<br>
</p>
<ol>
  <li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now
    contain a list of addresses. If the list begins with "!' then the rule
    will take effect only if the original destination address in the
    connection request does not match any of the addresses listed.</li>
</ol>

<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b></p>

<p>The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and
iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
have been encountered with this set of software. The Shorewall version is
1.4.4b plus the accumulated changes for 1.4.5.<br>
</p>

<p><b>6/8/2003 - Updated Samples</b></p>

<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
version 1.4.4.</p>

<p><b>5/29/2003 - Shorewall-1.4.4b</b></p>

<p>Groan -- This version corrects a problem whereby the --log-level was not
being set when logging via syslog. The most commonly reported symptom was
that Shorewall messages were being written to the console even though console
logging was correctly configured per FAQ 16.<br>
</p>

<p><b>5/27/2003 - Shorewall-1.4.4a</b></p>
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out that
the code in 1.4.4 restricts the length of short zone names to 4 characters.
I've produced version 1.4.4a that restores the previous 5-character limit by
conditionally omitting the log rule number when the LOGFORMAT doesn't contain
'%d'. <br>


<p><b>5/23/2003 - Shorewall-1.4.4</b></p>
I apologize for the rapid-fire releases but since there is a potential
configuration change required to go from 1.4.3a to 1.4.4, I decided to make
it a full release rather than just a bug-fix release. <br>
<br>
<b>&nbsp;&nbsp;&nbsp; Problems corrected:</b><br>


<blockquote>
  None.<br>
</blockquote>
<b>&nbsp;&nbsp;&nbsp; New Features:<br>
</b> 
<ol>
  <li>A REDIRECT- rule target has been added. This target behaves for
    REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter nat
    table REDIRECT rule is added but not the companion filter table ACCEPT
    rule.<br>
    <br>
  </li>
  <li>The LOGMARKER variable has been renamed LOGFORMAT and has been changed
    to a 'printf' formatting template which accepts three arguments (the
    chain name, logging rule number and the disposition). To use LOGFORMAT
    with fireparse (<a
    href="http://www.fireparse.com">http://www.fireparse.com</a>), set it
    as:<br>
    &nbsp;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOGFORMAT="fp=%s:%d a=%s "<br>
    &nbsp;<br>
    <b>CAUTION:</b> /sbin/shorewall uses the leading part of the LOGFORMAT
    string (up to but not including the first '%') to find log messages in
    the 'show log', 'status' and 'hits' commands. This part should not be
    omitted (the LOGFORMAT should not begin with "%") and the leading part
    should be sufficiently unique for /sbin/shorewall to identify Shorewall
    messages.<br>
    <br>
  </li>
  <li>When logging is specified on a DNAT[-] or REDIRECT[-] rule, the logging
    now takes place in the nat table rather than in the filter table. This
    way, only those connections that actually undergo DNAT or redirection
    will be logged.<br>
  </li>
</ol>

<p><b>5/20/2003 - Shorewall-1.4.3a</b><br>
</p>
This version primarily corrects the documentation included in the .tgz and in
the .rpm. In addition: <br>

<ol>
  <li>(This change is in 1.4.3 but is not documented) If you are running
    iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject
    replies as follows:<br>
    &nbsp;&nbsp; a) tcp - RST<br>
    &nbsp;&nbsp; b) udp - ICMP port unreachable<br>
    &nbsp;&nbsp; c) icmp - ICMP host unreachable<br>
    &nbsp;&nbsp; d) Otherwise - ICMP host prohibited<br>
    If you are running earlier software, Shorewall will follow it's
    traditional convention:<br>
    &nbsp;&nbsp; a) tcp - RST<br>
    &nbsp;&nbsp; b) Otherwise - ICMP port unreachable</li>
  <li>UDP port 135 is now silently dropped in the common.def chain. Remember
    that this chain is traversed just before a DROP or REJECT policy is
    enforced.<br>
  </li>
</ol>

<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
</p>
&nbsp;&nbsp;&nbsp; <b>Problems Corrected:<br>
</b> 
<ol>
  <li>There were several cases where Shorewall would fail to remove a
    temporary directory from /tmp. These cases have been corrected.</li>
  <li>The rules for allowing all traffic via the loopback interface have been
    moved to before the rule that drops status=INVALID packets. This insures
    that all loopback traffic is allowed even if Netfilter connection
    tracking is confused.</li>
</ol>
&nbsp;&nbsp;&nbsp; <b>New Features:<br>
</b> 
<ol>
  <li>&nbsp;IPV6-IPV4 (6to4) tunnels are now supported in the
    /etc/shorewall/tunnels file.</li>
  <li value="2">You may now change the leading portion of the --log-prefix
    used by Shorewall using the LOGMARKER variable in shorewall.conf. By
    default, "Shorewall:" is used.<br>
  </li>
</ol>

<p><b>5/10/2003 - Shorewall Mirror in Asia<br>
</b></p>

<p>Ed Greshko has established a mirror in Taiwan -- Thanks Ed!<br>
</p>

<p><b>5/8/2003 - Shorewall Mirror in Chile</b></p>
Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile. 

<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b></p>

<p>Thanks to Francesca Smith, the sample configurations are now upgraded to
Shorewall version 1.4.2.</p>

<p><b>4/9/2003 - Shorewall 1.4.2</b><br>
</p>

<p><b>&nbsp;&nbsp;&nbsp; Problems Corrected:</b></p>

<blockquote>
  <ol>
    <li>TCP connection requests rejected out of the <b>common</b> chain are
      now properly rejected with TCP RST; previously, some of these requests
      were rejected with an ICMP port-unreachable response.</li>
    <li>'traceroute -I' from behind the firewall previously timed out on the
      first hop (e.g., to the firewall). This has been worked around.</li>
  </ol>
</blockquote>

<p><b>&nbsp;&nbsp;&nbsp; New Features:</b></p>
<ol>
  <li>Where an entry in the/etc/shorewall/hosts file specifies a particular
    host or network, Shorewall now creates an intermediate chain for handling
    input from the related zone. This can substantially reduce the number of
    rules traversed by connections requests from such zones.<br>
    <br>
  </li>
  <li>Any file may include an INCLUDE directive. An INCLUDE directive
    consists of the word INCLUDE followed by a file name and causes the
    contents of the named file to be logically included into the file
    containing the INCLUDE. File names given in an INCLUDE directive are
    assumed to reside in /etc/shorewall or in an alternate configuration
    directory if one has been specified for the command.<br>
    &nbsp;<br>
    &nbsp;&nbsp; Examples:<br>
    &nbsp;&nbsp; shorewall/params.mgmt:<br>
    &nbsp;&nbsp; MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3<br>
    &nbsp;&nbsp; TIME_SERVERS=4.4.4.4<br>
    &nbsp;&nbsp; BACKUP_SERVERS=5.5.5.5<br>
    &nbsp;&nbsp; ----- end params.mgmt -----<br>
    &nbsp;<br>
    &nbsp;<br>
    &nbsp;&nbsp; shorewall/params:<br>
    &nbsp;&nbsp; # Shorewall 1.3 /etc/shorewall/params<br>
    &nbsp;&nbsp; [..]<br>
    &nbsp;&nbsp; #######################################<br>
    &nbsp;<br>
    &nbsp; &nbsp;INCLUDE params.mgmt&nbsp;&nbsp;&nbsp;<br>
    &nbsp;<br>
    &nbsp;&nbsp; # params unique to this host here<br>
    &nbsp;&nbsp; #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT
    REMOVE<br>
    &nbsp;&nbsp; ----- end params -----<br>
    &nbsp;<br>
    &nbsp;<br>
    &nbsp;&nbsp; shorewall/rules.mgmt:<br>
    &nbsp;&nbsp; ACCEPT
    net:$MGMT_SERVERS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    $FW&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ACCEPT
    $FW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net:$TIME_SERVERS&nbsp;&nbsp;&nbsp; udp&nbsp;&nbsp;&nbsp; 123<br>
    &nbsp;&nbsp; ACCEPT
    $FW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    net:$BACKUP_SERVERS&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
    &nbsp;&nbsp; ----- end rules.mgmt -----<br>
    &nbsp;<br>
    &nbsp;&nbsp; shorewall/rules:<br>
    &nbsp;&nbsp; # Shorewall version 1.3 - Rules File<br>
    &nbsp;&nbsp; [..]<br>
    &nbsp;&nbsp; #######################################<br>
    &nbsp;<br>
    &nbsp;&nbsp; INCLUDE rules.mgmt&nbsp;&nbsp;&nbsp;&nbsp;<br>
    &nbsp;<br>
    &nbsp;&nbsp; # rules unique to this host here<br>
    &nbsp;&nbsp; #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT
    REMOVE<br>
    &nbsp;&nbsp; ----- end rules -----<br>
    &nbsp;<br>
    INCLUDE's may be nested to a level of 3 -- further nested INCLUDE
    directives are ignored with a warning message.<br>
    <br>
  </li>
  <li>Routing traffic from an interface back out that interface continues to
    be a problem. While I firmly believe that this should never happen,
    people continue to want to do it. To limit the damage that such nonsense
    produces, I have added a new 'routeback' option in
    /etc/shorewall/interfaces and /etc/shorewall/hosts. When used in
    /etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; in
    other words, 'routeback' can't be used as an option for a multi-zone
    interface. The 'routeback' option CAN be specified however on individual
    group entries in /etc/shorewall/hosts.<br>
    &nbsp;<br>
    The 'routeback' option is similar to the old 'multi' option with two
    exceptions:<br>
    &nbsp;<br>
    &nbsp;&nbsp; a) The option pertains to a particular
    zone,interface,address tuple.<br>
    &nbsp;<br>
    &nbsp;&nbsp; b) The option only created infrastructure to pass traffic
    from (zone,interface,address) tuples back to themselves (the 'multi'
    option affected all (zone,interface,address) tuples associated with the
    given 'interface').<br>
    &nbsp;<br>
    See the '<a href="upgrade_issues.htm">Upgrade Issues</a>' for information
    about how this new option may affect your configuration.<br>
  </li>
</ol>

<p><b>3/24/2003 - Shorewall 1.4.1</b></p>

<p>This release follows up on 1.4.0. It corrects a problem introduced in
1.4.0 and removes additional warts.<br>
<br>
<b>Problems Corrected:</b><br>
</p>
<ol>
  <li>When Shorewall 1.4.0 is run under the ash shell (such as on
    Bering/LEAF), it can attempt to add ECN disabling rules even if the
    /etc/shorewall/ecn file is empty. That problem has been corrected so that
    ECN disabling rules are only added if there are entries in
    /etc/shorewall/ecn.</li>
</ol>
<b>New Features:</b><br>


<blockquote>
  Note: In the list that follows, the term <i>group</i> refers to a
  particular network or subnetwork (which may be 0.0.0.0/0 or it may be a
  host address) accessed through a particular interface. Examples:<br>


  <blockquote>
    eth0:0.0.0.0/0<br>
    eth2:192.168.1.0/24<br>
    eth3:192.0.2.123<br>
  </blockquote>
  You can use the "shorewall check" command to see the groups associated with
  each of your zones.<br>
</blockquote>
<ol>
  <li>Beginning with Shorewall 1.4.1, if a zone Z comprises more than one
    group then if there is no explicit Z to Z policy and there are no rules
    governing traffic from Z to Z then Shorewall will permit all traffic
    between the groups in the zone.</li>
  <li>Beginning with Shorewall 1.4.1, Shorewall will never create rules to
    handle traffic from a group to itself.</li>
  <li>A NONE policy is introduced in 1.4.1. When a policy of NONE is
    specified from Z1 to Z2:</li>
</ol>
<ul>
  <li>There may be no rules created that govern connections from Z1 to
  Z2.</li>
  <li>Shorewall will not create any infrastructure to handle traffic from Z1
    to Z2.</li>
</ul>
See the <a href="upgrade_issues.htm">upgrade issues</a> for a discussion of
how these changes may affect your configuration. 

<p><b>3/17/2003 - Shorewall 1.4.0</b></p>
Shorewall 1.4 represents the next step in the evolution of Shorewall. The
main thrust of the initial release is simply to remove the cruft that has
accumulated in Shorewall over time. <br>
<br>
<b>IMPORTANT: Shorewall 1.4.0 requires</b> <b>the iproute package ('ip'
utility).</b><br>
<br>
Function from 1.3 that has been omitted from this version include:<br>

<ol>
  <li>The MERGE_HOSTS variable in shorewall.conf is no longer supported.
    Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.<br>
    <br>
  </li>
  <li>Interface names of the form &lt;device&gt;:&lt;integer&gt; in
    /etc/shorewall/interfaces now generate an error.<br>
    <br>
  </li>
  <li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
    OLD_PING_HANDLING=Yes will generate an error at startup as will
    specification of the 'noping' or 'filterping' interface options.<br>
    <br>
  </li>
  <li>The 'routestopped' option in the /etc/shorewall/interfaces and
    /etc/shorewall/hosts files is no longer supported and will generate an
    error at startup if specified.<br>
    <br>
  </li>
  <li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
    accepted.<br>
    <br>
  </li>
  <li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
    Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
    <br>
  </li>
  <li>The icmp.def file has been removed.<br>
  </li>
</ol>
Changes for 1.4 include:<br>

<ol>
  <li>The /etc/shorewall/shorewall.conf file has been completely reorganized
    into logical sections.<br>
    <br>
  </li>
  <li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
    <br>
  </li>
  <li>The firewall script and version file are now installed in
    /usr/share/shorewall.<br>
    <br>
  </li>
  <li>Late arriving DNS replies are now silently dropped in the common chain
    by default.<br>
    <br>
  </li>
  <li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 no
    longer unconditionally accepts outbound ICMP packets. So if you want to
    'ping' from the firewall, you will need the appropriate rule or
    policy.<br>
    <br>
  </li>
  <li>CONTINUE is now a valid action for a rule (/etc/shorewall/rules).<br>
    <br>
  </li>
  <li>802.11b devices with names of the form wlan&lt;n&gt; now support the
    'maclist' option.<br>
    <br>
  </li>
  <li>Explicit Congestion Notification (ECN - RFC 3168) may now be turned off
    on a host or network basis using the new /etc/shorewall/ecn file. To use
    this facility:<br>
    <br>
    &nbsp;&nbsp; a) You must be running kernel 2.4.20<br>
    &nbsp;&nbsp; b) You must have applied the patch in<br>
    &nbsp;&nbsp; http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
    &nbsp;&nbsp; c) You must have iptables 1.2.7a installed.<br>
    <br>
  </li>
  <li>The /etc/shorewall/params file is now processed first so that variables
    may be used in the /etc/shorewall/shorewall.conf file.<br>
    <br>
  </li>
  <li value="10">Shorewall now gives a more helpful diagnostic when the
    'ipchains' compatibility kernel module is loaded and a 'shorewall start'
    command is issued.<br>
    <br>
  </li>
  <li>The SHARED_DIR variable has been removed from shorewall.conf. This
    variable was for use by package maintainers and was not documented for
    general use.<br>
    <br>
  </li>
  <li>Shorewall now ignores 'default' routes when detecting masq'd
  networks.</li>
</ol>

<p><b>3/10/2003 - Shoreall 1.3.14a</b></p>

<p>A roleup of the following bug fixes and other updates:</p>
<ul>
  <li>There is an updated rfc1918 file that reflects the resent allocation of
    222.0.0.0/8 and 223.0.0.0/8.</li>
</ul>
<ul>
  <li>The documentation for the routestopped file claimed that a
    comma-separated list could appear in the second column while the code
    only supported a single host or network address.</li>
  <li>Log messages produced by 'logunclean' and 'dropunclean' were not
    rate-limited.</li>
  <li>802.11b devices with names of the form <i>wlan</i>&lt;n&gt; don't
    support the 'maclist' interface option.</li>
  <li>Log messages generated by RFC 1918 filtering are not rate limited.</li>
  <li>The firewall fails to start in the case where you have "eth0 eth1" in
    /etc/shorewall/masq and the default route is through eth1</li>
</ul>

<p><b>2/8/2003 - Shoreawall 1.3.14</b></p>

<p>New features include</p>
<ol>
  <li>An OLD_PING_HANDLING option has been added to shorewall.conf. When set
    to Yes, Shorewall ping handling is as it has always been (see
    http://www.shorewall.net/ping.html).<br>
    <br>
    When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
    policies just like any other connection request. The FORWARDPING=Yes
    option in shorewall.conf and the 'noping' and 'filterping' options in
    /etc/shorewall/interfaces will all generate an error.<br>
    <br>
  </li>
  <li>It is now possible to direct Shorewall to create a "label" such
    as&nbsp; "eth0:0" for IP addresses that it creates under
    ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
    the label instead of just the interface name:<br>
    &nbsp;<br>
    &nbsp;&nbsp; a) In the INTERFACE column of /etc/shorewall/masq<br>
    &nbsp;&nbsp; b) In the INTERFACE column of /etc/shorewall/nat<br>
    &nbsp;</li>
  <li>Support for OpenVPN Tunnels.<br>
    <br>
  </li>
  <li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
    eth0.0)<br>
    <br>
  </li>
  <li>In /etc/shorewall/tcrules, the MARK value may be optionally followed by
    ":" and either 'F' or 'P' to designate that the marking will occur in the
    FORWARD or PREROUTING chains respectively. If this additional
    specification is omitted, the chain used to mark packets will be
    determined by the setting of the MARK_IN_FORWARD_CHAIN option in <a
    href="Documentation.htm#Conf">shorewall.conf</a>.<br>
    <br>
  </li>
  <li>When an interface name is entered in the SUBNET column of the
    /etc/shorewall/masq file, Shorewall previously masqueraded traffic from
    only the first subnet defined on that interface. It did not masquerade
    traffic from:<br>
    &nbsp;<br>
    &nbsp;&nbsp; a) The subnets associated with other addresses on the
    interface.<br>
    &nbsp;&nbsp; b) Subnets accessed through local routers.<br>
    &nbsp;<br>
    Beginning with Shorewall 1.3.14, if you enter an interface name in the
    SUBNET column, shorewall will use the firewall's routing table to
    construct the masquerading/SNAT rules.<br>
    &nbsp;<br>
    Example 1 -- This is how it works in 1.3.14.<br>
    &nbsp;&nbsp;<br>

    <pre>   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
    <pre>   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
 </pre>
    <pre>   [root@gateway test]# shorewall start<br>
   ...<br>
   Masqueraded Subnets and Hosts:<br>
       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
   Processing /etc/shorewall/tos...</pre>
    &nbsp;<br>
    When upgrading to Shorewall 1.3.14, if you have multiple local subnets
    connected to an interface that is specified in the SUBNET column of an
    /etc/shorewall/masq entry, your /etc/shorewall/masq file will need
    changing. In most cases, you will simply be able to remove redundant
    entries. In some cases though, you might want to change from using the
    interface name to listing specific subnetworks if the change described
    above will cause masquerading to occur on subnetworks that you don't wish
    to masquerade.<br>
    &nbsp;<br>
    Example 2 -- Suppose that your current config is as follows:<br>
    &nbsp;&nbsp;<br>

    <pre>   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   eth0                    192.168.10.0/24         206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
    <pre>   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#</pre>
    &nbsp;<br>
    &nbsp;&nbsp; In this case, the second entry in /etc/shorewall/masq is no
    longer required.<br>
    &nbsp;<br>
    Example 3 -- What if your current configuration is like this?<br>
    &nbsp;<br>

    <pre>   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
    <pre>   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#</pre>
    &nbsp;<br>
    &nbsp;&nbsp; In this case, you would want to change the entry in&nbsp;
    /etc/shorewall/masq to:<br>

    <pre>   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    192.168.1.0/24          206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
  </li>
</ol>

<p><br>
<b>2/5/2003 - Shorewall Support included in Webmin 1.060</b></p>

<p>Webmin version 1.060 now has Shorewall support included as standard. See
<a href="http://www.webmin.com">http://www.webmin.com</a>.<br>
<b><br>
2/4/2003 - Shorewall 1.3.14-RC1</b></p>

<p>Includes the Beta 2 content plus support for OpenVPN tunnels.</p>

<p><b>1/28/2003 - Shorewall 1.3.14-Beta2</b></p>

<p>Includes the Beta 1 content plus restores VLAN device names of the form
$dev.$vid (e.g., eth0.1)</p>

<p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b><br>
</p>

<p>The Beta includes the following changes:<br>
</p>
<ol>
  <li>An OLD_PING_HANDLING option has been added to shorewall.conf. When set
    to Yes, Shorewall ping handling is as it has always been (see
    http://www.shorewall.net/ping.html).<br>
    <br>
    When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
    policies just like any other connection request. The FORWARDPING=Yes
    option in shorewall.conf and the 'noping' and 'filterping' options in
    /etc/shorewall/interfaces will all generate an error.<br>
    <br>
  </li>
  <li>It is now possible to direct Shorewall to create a "label" such
    as&nbsp; "eth0:0" for IP addresses that it creates under
    ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
    the label instead of just the interface name:<br>
    &nbsp;<br>
    &nbsp;&nbsp; a) In the INTERFACE column of /etc/shorewall/masq<br>
    &nbsp;&nbsp; b) In the INTERFACE column of /etc/shorewall/nat<br>
    &nbsp;</li>
  <li>When an interface name is entered in the SUBNET column of the
    /etc/shorewall/masq file, Shorewall previously masqueraded traffic from
    only the first subnet defined on that interface. It did not masquerade
    traffic from:<br>
    &nbsp;<br>
    &nbsp;&nbsp; a) The subnets associated with other addresses on the
    interface.<br>
    &nbsp;&nbsp; b) Subnets accessed through local routers.<br>
    &nbsp;<br>
    Beginning with Shorewall 1.3.14, if you enter an interface name in the
    SUBNET column, shorewall will use the firewall's routing table to
    construct the masquerading/SNAT rules.<br>
    &nbsp;<br>
    Example 1 -- This is how it works in 1.3.14.<br>
    &nbsp;&nbsp;<br>

    <pre>   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
    <pre>   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
 </pre>
    <pre>   [root@gateway test]# shorewall start<br>
   ...<br>
   Masqueraded Subnets and Hosts:<br>
       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
   Processing /etc/shorewall/tos...</pre>
    &nbsp;<br>
    When upgrading to Shorewall 1.3.14, if you have multiple local subnets
    connected to an interface that is specified in the SUBNET column of an
    /etc/shorewall/masq entry, your /etc/shorewall/masq file will need
    changing. In most cases, you will simply be able to remove redundant
    entries. In some cases though, you might want to change from using the
    interface name to listing specific subnetworks if the change described
    above will cause masquerading to occur on subnetworks that you don't wish
    to masquerade.<br>
    &nbsp;<br>
    Example 2 -- Suppose that your current config is as follows:<br>
    &nbsp;&nbsp;<br>

    <pre>   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   eth0                    192.168.10.0/24         206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
    <pre>   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#</pre>
    &nbsp;<br>
    &nbsp;&nbsp; In this case, the second entry in /etc/shorewall/masq is no
    longer required.<br>
    &nbsp;<br>
    Example 3 -- What if your current configuration is like this?<br>
    &nbsp;<br>

    <pre>   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
    <pre>   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#</pre>
    &nbsp;<br>
    &nbsp;&nbsp; In this case, you would want to change the entry in&nbsp;
    /etc/shorewall/masq to:<br>

    <pre>   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    192.168.1.0/24          206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
  </li>
</ol>

<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format</b></p>

<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
documenation. the PDF may be downloaded from</p>
&nbsp;&nbsp;&nbsp; <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
&nbsp;&nbsp;&nbsp; <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a> 

<p><b>1/17/2003 - shorewall.net has MOVED</b><b>&nbsp;</b></p>

<p>Thanks to the generosity of Alex Martin and <a
href="http://www.rettc.com">Rett Consulting</a>, www.shorewall.net and
ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A big
thanks to Alex for making this happen.<br>
</p>

<p><b>1/13/2003 - Shorewall 1.3.13<br>
</b></p>

<p>Just includes a few things that I had on the burner:<br>
</p>
<ol>
  <li>A new 'DNAT-' action has been added for entries in the
    /etc/shorewall/rules file. DNAT- is intended for advanced users who wish
    to minimize the number of rules that connection requests must
    traverse.<br>
    <br>
    A Shorewall DNAT rule actually generates two iptables rules: a header
    rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter'
    table. A DNAT- rule only generates the first of these rules. This is
    handy when you have several DNAT rules that would generate the same
    ACCEPT rule.<br>
    <br>
    &nbsp;&nbsp; Here are three rules from my previous rules file:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT&nbsp;&nbsp; net&nbsp;
    dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT&nbsp;&nbsp; net&nbsp;
    dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
    dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
    <br>
    &nbsp;&nbsp; These three rules ended up generating _three_ copies of<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
    dmz:206.124.146.177 tcp smtp<br>
    <br>
    &nbsp;&nbsp; By writing the rules this way, I end up with only one copy
    of the ACCEPT rule.<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT-&nbsp; net&nbsp;
    dmz:206.124.146.177 tcp smtp -&nbsp; 206.124.146.178<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT-&nbsp; net&nbsp;
    dmz:206.124.146.177 tcp smtp -&nbsp; 206.124.146.179<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
    dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
    <br>
  </li>
  <li>The 'shorewall check' command now prints out the applicable policy
    between each pair of zones.<br>
    <br>
  </li>
  <li>A new CLEAR_TC option has been added to shorewall.conf. If this option
    is set to 'No' then Shorewall won't clear the current traffic control
    rules during [re]start. This setting is intended for use by people that
    prefer to configure traffic shaping when the network interfaces come up
    rather than when the firewall is started. If that is what you want to do,
    set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an
    /etc/shorewall/tcstart file. That way, your traffic shaping rules can
    still use the 'fwmark' classifier based on packet marking defined in
    /etc/shorewall/tcrules.<br>
    <br>
  </li>
  <li>A new SHARED_DIR variable has been added that allows distribution
    packagers to easily move the shared directory (default
    /usr/lib/shorewall). Users should never have a need to change the value
    of this shorewall.conf setting.<br>
  </li>
</ol>

<p><b>1/6/2003 - <big><big><big>BURNOUT</big></big></big></b></p>

<p><b>Until further notice, I will not be involved in either Shorewall
Development or Shorewall Support</b></p>

<p><b>-Tom Eastep</b><br>
</p>

<p><b>12/30/2002 - Shorewall Documentation in PDF Format</b></p>

<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
documenation. the PDF may be downloaded from</p>

<p>&nbsp;&nbsp;&nbsp; <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
&nbsp;&nbsp;&nbsp; <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>

<p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>

<p>Features include:<br>
</p>
<ol>
  <li>"shorewall refresh" now reloads the traffic shaping rules (tcrules and
    tcstart).</li>
  <li>"shorewall debug [re]start" now turns off debugging after an error
    occurs. This places the point of the failure near the end of the trace
    rather than up in the middle of it.</li>
  <li>"shorewall [re]start" has been speeded up by more than 40% with my
    configuration. Your milage may vary.</li>
  <li>A "shorewall show classifiers" command has been added which shows the
    current packet classification filters. The output from this command is
    also added as a separate page in "shorewall monitor"</li>
  <li>ULOG (must be all caps) is now accepted as a valid syslog level and
    causes the subject packets to be logged using the ULOG target rather than
    the LOG target. This allows you to run ulogd (available from <a
    href="http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</a>)
    and log all Shorewall messages <a href="shorewall_logging.html">to a
    separate log file</a>.</li>
  <li>If you are running a kernel that has a FORWARD chain in the mangle
    table ("shorewall show mangle" will show you the chains in the mangle
    table), you can set MARK_IN_FORWARD_CHAIN=Yes in <a
    href="Documentation.htm#Conf">shorewall.conf</a>. This allows for marking
    input packets based on their destination even when you are using
    Masquerading or SNAT.</li>
  <li>I have cluttered up the /etc/shorewall directory with empty 'init',
    'start', 'stop' and 'stopped' files. If you already have a file with one
    of these names, don't worry -- the upgrade process won't overwrite your
    file.</li>
  <li>I have added a new RFC1918_LOG_LEVEL variable to <a
    href="Documentation.htm#Conf">shorewall.conf</a>. This variable specifies
    the syslog level at which packets are logged as a result of entries in
    the /etc/shorewall/rfc1918 file. Previously, these packets were always
    logged at the 'info' level.<br>
  </li>
</ol>

<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3<br>
</b></p>
This version corrects a problem with Blacklist logging. In Beta 2, if
BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall would fail to
start and "shorewall refresh" would also fail.<br>


<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b></p>

<p>The first public Beta version of Shorewall 1.3.12 is now available (Beta 1
was made available only to a limited audience).<br>
</p>
Features include:<br>

<ol>
  <li>"shorewall refresh" now reloads the traffic shaping rules (tcrules and
    tcstart).</li>
  <li>"shorewall debug [re]start" now turns off debugging after an error
    occurs. This places the point of the failure near the end of the trace
    rather than up in the middle of it.</li>
  <li>"shorewall [re]start" has been speeded up by more than 40% with my
    configuration. Your milage may vary.</li>
  <li>A "shorewall show classifiers" command has been added which shows the
    current packet classification filters. The output from this command is
    also added as a separate page in "shorewall monitor"</li>
  <li>ULOG (must be all caps) is now accepted as a valid syslog level and
    causes the subject packets to be logged using the ULOG target rather than
    the LOG target. This allows you to run ulogd (available from <a
    href="http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</a>)
    and log all Shorewall messages <a href="shorewall_logging.html">to a
    separate log file</a>.</li>
  <li>If you are running a kernel that has a FORWARD chain in the mangle
    table ("shorewall show mangle" will show you the chains in the mangle
    table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This
    allows for marking input packets based on their destination even when you
    are using Masquerading or SNAT.</li>
  <li>I have cluttered up the /etc/shorewall directory with empty 'init',
    'start', 'stop' and 'stopped' files. If you already have a file with one
    of these names, don't worry -- the upgrade process won't overwrite your
    file.</li>
</ol>
You may download the Beta from:<br>


<blockquote>
  <a
  href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
  <a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
  target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>

<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
alt="Powered by Mandrake Linux" border="0" height="21" width="140" />
</a></b></p>
Shorewall is at the center of MandrakeSoft's recently-announced <a
href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&amp;id_art=250&amp;LANG_=en#GOTO_250">Multi
Network Firewall (MNF)</a> product. Here is the <a
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
release</a>.<br>


<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b></p>

<p>Two months and 3 days after I ordered Mandrake 9.0, it was finally
delivered. I have installed 9.0 on one of my systems and I am now in a
position to support Shorewall users who run Mandrake 9.0.</p>

<p><b>12/6/2002 - Debian 1.3.11a Packages Available<br>
</b></p>

<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>

<p><b>12/3/2002 - Shorewall 1.3.11a</b></p>

<p>This is a bug-fix roll up which includes Roger Aich's fix for DNAT with
excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users who don't
need rules of this type need not upgrade to 1.3.11.</p>

<p><b>11/24/2002 - Shorewall 1.3.11</b></p>

<p>In this version:</p>
<ul>
  <li>A 'tcpflags' option has been added to entries in <a
    href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. This
    option causes Shorewall to make a set of sanity check on TCP packet
    header flags.</li>
  <li>It is now allowed to use 'all' in the SOURCE or DEST column in a <a
    href="Documentation.htm#Rules">rule</a>. When used, 'all' must appear by
    itself (in may not be qualified) and it does not enable intra-zone
    traffic. For example, the rule<br>
    <br>
    &nbsp; &nbsp; ACCEPT loc all tcp 80<br>
    <br>
    does not enable http traffic from 'loc' to 'loc'.</li>
  <li>Shorewall's use of the 'echo' command is now compatible with bash
    clones such as ash and dash.</li>
  <li>fw-&gt;fw policies now generate a startup error. fw-&gt;fw rules
    generate a warning and are ignored</li>
</ul>

<p><b>11/14/2002 - Shorewall Documentation in PDF Format</b></p>

<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10
documenation. the PDF may be downloaded from</p>

<p>&nbsp;&nbsp;&nbsp; <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
&nbsp;&nbsp;&nbsp; <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>

<p><b>11/09/2002 - Shorewall is Back at SourceForge</b></p>

<p>The main Shorewall 1.3 web site is now back at SourceForge at <a
href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>.<br>
</p>

<p><b>11/09/2002 - Shorewall 1.3.10</b></p>

<p>In this version:</p>
<ul>
  <li>You may now <a href="IPSEC.htm#Dynamic">define the contents of a zone
    dynamically</a> with the <a
    href="starting_and_stopping_shorewall.htm">"shorewall add" and "shorewall
    delete" commands</a>. These commands are expected to be used primarily
    within <a href="http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
    scripts.</li>
  <li>Shorewall can now do <a href="MAC_Validation.html">MAC verification</a>
    on ethernet segments. You can specify the set of allowed MAC addresses on
    the segment and you can optionally tie each MAC address to one or more IP
    addresses.</li>
  <li>PPTP Servers and Clients running on the firewall system may now be
    defined in the <a href="PPTP.htm">/etc/shorewall/tunnels</a> file.</li>
  <li>A new 'ipsecnat' tunnel type is supported for use when the <a
    href="IPSEC.htm">remote IPSEC endpoint is behind a NAT gateway</a>.</li>
  <li>The PATH used by Shorewall may now be specified in <a
    href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
  <li>The main firewall script is now /usr/lib/shorewall/firewall. The script
    in /etc/init.d/shorewall is very small and uses /sbin/shorewall to do the
    real work. This change makes custom distributions such as for Debian and
    for Gentoo easier to manage since it is /etc/init.d/shorewall that tends
    to have distribution-dependent code</li>
</ul>

<p><b>10/24/2002 - Shorewall is now in Gentoo Linux</b> <a
href="http://www.gentoo.org"><br>
</a></p>
Alexandru Hartmann reports that his Shorewall package is now a part of <a
href="http://www.gentoo.org">the Gentoo Linux distribution</a>. Thanks
Alex!<br>


<p><b>10/23/2002 - Shorewall 1.3.10 Beta 1</b></p>
In this version:<br>

<ul>
  <li>You may now <a href="IPSEC.htm#Dynamic">define the contents of a zone
    dynamically</a> with the <a
    href="starting_and_stopping_shorewall.htm">"shorewall add" and "shorewall
    delete" commands</a>. These commands are expected to be used primarily
    within <a href="http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
    scripts.</li>
  <li>Shorewall can now do <a href="MAC_Validation.html">MAC verification</a>
    on ethernet segments. You can specify the set of allowed MAC addresses on
    the segment and you can optionally tie each MAC address to one or more IP
    addresses.</li>
  <li>PPTP Servers and Clients running on the firewall system may now be
    defined in the <a href="PPTP.htm">/etc/shorewall/tunnels</a> file.</li>
  <li>A new 'ipsecnat' tunnel type is supported for use when the <a
    href="IPSEC.htm">remote IPSEC endpoint is behind a NAT gateway</a>.</li>
  <li>The PATH used by Shorewall may now be specified in <a
    href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
  <li>The main firewall script is now /usr/lib/shorewall/firewall. The script
    in /etc/init.d/shorewall is very small and uses /sbin/shorewall to do the
    real work. This change makes custom distributions such as for Debian and
    for Gentoo easier to manage since it is /etc/init.d/shorewall that tends
    to have distribution-dependent code.</li>
</ul>
You may download the Beta from:<br>

<ul>
  <li><a
    href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a></li>
  <li><a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
    target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a></li>
</ul>

<p><b>10/10/2002 - &nbsp;Debian 1.3.9b Packages Available<br>
</b></p>

<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>

<p><b>10/9/2002 - Shorewall 1.3.9b</b></p>
This release rolls up fixes to the installer and to the firewall script.<br>


<p><b>10/6/2002 - Shorewall.net now running on RH8.0<br>
</b><br>
The firewall and server here at shorewall.net are now running RedHat release
8.0.<br>
<b><br>
9/30/2002 - Shorewall 1.3.9a</b></p>
Roles up the fix for broken tunnels.<br>


<p><b>9/30/2002 - TUNNELS Broken in 1.3.9!!!</b></p>
There is an updated firewall script at <a
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
-- copy that file to /usr/lib/shorewall/firewall.<br>


<p><b>9/28/2002 - Shorewall 1.3.9</b></p>

<p>In this version:<br>
</p>
<ul>
  <li><a href="configuration_file_basics.htm#dnsnames">DNS Names</a> are now
    allowed in Shorewall config files (although I recommend against using
    them).</li>
  <li>The connection SOURCE may now be qualified by both interface and IP
    address in a <a href="Documentation.htm#Rules">Shorewall rule</a>.</li>
  <li>Shorewall startup is now disabled after initial installation until the
    file /etc/shorewall/startup_disabled is removed. This avoids nasty
    surprises during reboot for users who install Shorewall but don't
    configure it.</li>
  <li>The 'functions' and 'version' files and the 'firewall' symbolic link
    have been moved from /var/lib/shorewall to /usr/lib/shorewall to appease
    the LFS police at Debian.<br>
  </li>
</ul>

<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
Restored</b><br>
</p>
<img src="images/j0233056.gif" alt="Brown Paper Bag" align="left" height="86"
width="50" /> A couple of recent configuration changes at www.shorewall.net
broke the Search facility:<br>


<blockquote>
  <ol>
    <li>Mailing List Archive Search was not available.</li>
    <li>The Site Search index was incomplete</li>
    <li>Only one page of matches was presented.</li>
  </ol>
</blockquote>
Hopefully these problems are now corrected. 

<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
Restored<br>
</b></p>
A couple of recent configuration changes at www.shorewall.net had the
negative effect of breaking the Search facility:<br>

<ol>
  <li>Mailing List Archive Search was not available.</li>
  <li>The Site Search index was incomplete</li>
  <li>Only one page of matches was presented.</li>
</ol>
Hopefully these problems are now corrected.<br>


<p><b>9/18/2002 - &nbsp;Debian 1.3.8 Packages Available<br>
</b></p>

<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>

<p><b>9/16/2002 - Shorewall 1.3.8</b></p>

<p>In this version:<br>
</p>
<ul>
  <li>A <a href="Documentation.htm#Conf">NEWNOTSYN</a> option has been added
    to shorewall.conf. This option determines whether Shorewall accepts TCP
    packets which are not part of an established connection and that are not
    'SYN' packets (SYN flag on and ACK flag off).</li>
  <li>The need for the 'multi' option to communicate between zones za and zb
    on the same interface is removed in the case where the chain 'za2zb'
    and/or 'zb2za' exists. 'za2zb' will exist if:</li>
  <li
  style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
      <li>There is a policy for za to zb; or</li>
      <li>There is at least one rule for za to zb.</li>
    </ul>
  </li>
</ul>
<ul>
  <li>The /etc/shorewall/blacklist file now contains three columns. In
    addition to the SUBNET/ADDRESS column, there are optional PROTOCOL and
    PORT columns to block only certain applications from the blacklisted
    addresses.<br>
  </li>
</ul>

<p><b>9/11/2002 - Debian 1.3.7c Packages Available</b></p>

<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

<p><b>9/2/2002 - Shorewall 1.3.7c</b></p>

<p>This is a role up of a fix for "DNAT" rules where the source zone is $FW
(fw).</p>

<p><b>8/31/2002 - I'm not available</b></p>

<p>I'm currently on vacation&nbsp; -- please respect my need for a couple of
weeks free of Shorewall problem reports.</p>

<p>-Tom</p>

<p><b>8/26/2002 - Shorewall 1.3.7b</b></p>

<p>This is a role up of the "shorewall refresh" bug fix and the change which
reverses the order of "dhcp" and "norfc1918" checking.</p>

<p><b>8/26/2002 - French FTP Mirror is Operational</b></p>

<p><a target="_blank"
href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
is now available.</p>

<p><b>8/25/2002 - Shorewall Mirror in France</b></p>

<p>Thanks to a Shorewall user in Paris, the Shorewall web site is now
mirrored at <a target="_top"
href="http://france.shorewall.net">http://france.shorewall.net</a>.</p>

<p><b>8/25/2002 - Shorewall 1.3.7a Debian Packages Available</b></p>

<p>Lorenzo Martignoni reports that the packages for version 1.3.7a are
available at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

<p><b>8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author
-- Shorewall 1.3.7a released<img src="images/j0233056.gif"
alt="Brown Paper Bag Graphic" align="middle" border="0" height="80"
width="50" /></b></p>

<p>1.3.7a corrects problems occurring in rules file processing when starting
Shorewall 1.3.7.</p>

<p><b>8/22/2002 - Shorewall 1.3.7 Released 8/13/2002</b></p>

<p>Features in this release include:</p>
<ul>
  <li>The 'icmp.def' file is now empty! The rules in that file were required
    in ipchains firewalls but are not required in Shorewall. Users who have
    ALLOWRELATED=No in <a href="Documentation.htm#Conf">shorewall.conf</a>
    should see the <a href="errata.htm#Upgrade">Upgrade Issues</a>.</li>
  <li>A 'FORWARDPING' option has been added to <a
    href="Documentation.htm#Conf">shorewall.conf</a>. The effect of setting
    this variable to Yes is the same as the effect of adding an ACCEPT rule
    for ICMP echo-request in <a
    href="shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>. Users
    who have such a rule in icmpdef are encouraged to switch to
    FORWARDPING=Yes.</li>
  <li>The loopback CLASS A Network (127.0.0.0/8) has been added to the
    rfc1918 file.</li>
  <li>Shorewall now works with iptables 1.2.7</li>
  <li>The documentation and web site no longer uses FrontPage themes.</li>
</ul>

<p>I would like to thank John Distler for his valuable input regarding TCP
SYN and ICMP treatment in Shorewall. That input has led to marked improvement
in Shorewall in the last two releases.</p>

<p><b>8/13/2002 - Documentation in the <a target="_top"
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
Repository</a></b></p>

<p>The Shorewall-docs project now contains just the HTML and image files -
the Frontpage files have been removed.</p>

<p><b>8/7/2002 - <i>STABLE</i></b> <b>branch added to <a target="_top"
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
Repository</a></b></p>

<p>This branch will only be updated after I release a new version of
Shorewall so you can always update from this branch to get the latest stable
tree.</p>

<p><b>8/7/2002 - <a href="errata.htm#Upgrade">Upgrade Issues</a> section
added to the <a href="errata.htm">Errata Page</a></b></p>

<p>Now there is one place to go to look for issues involved with upgrading to
recent versions of Shorewall.</p>

<p><b>8/7/2002 - Shorewall 1.3.6</b></p>

<p>This is primarily a bug-fix rollup with a couple of new features:</p>
<ul>
  <li>The latest <a href="shorewall_quickstart_guide.htm">QuickStart
    Guides</a> including the <a href="shorewall_setup_guide.htm">Shorewall
    Setup Guide.</a></li>
  <li>Shorewall will now DROP TCP packets that are not part of or related to
    an existing connection and that are not SYN packets. These "New not SYN"
    packets may be optionally logged by setting the LOGNEWNOTSYN option in <a
    href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
  <li>The processing of "New not SYN" packets may be extended by commands in
    the new <a href="shorewall_extension_scripts.htm">newnotsyn extension
    script</a>.</li>
</ul>

<p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>

<p>This interim release:</p>
<ul>
  <li>Causes the firewall script to remove the lock file if it is killed.</li>
  <li>Once again allows lists in the second column of the <a
    href="Documentation.htm#Hosts">/etc/shorewall/hosts</a> file.</li>
  <li>Includes the latest <a href="shorewall_quickstart_guide.htm">QuickStart
    Guides</a>.</li>
</ul>

<p><b>7/29/2002 - New Shorewall Setup Guide Available</b></p>

<p>The first draft of this guide is available at <a
href="http://www.shorewall.net/shorewall_setup_guide.htm">http://www.shorewall.net/shorewall_setup_guide.htm</a>.
The guide is intended for use by people who are setting up Shorewall to
manage multiple public IP addresses and by people who want to learn more
about Shorewall than is described in the single-address guides. Feedback on
the new guide is welcome.</p>

<p><b>7/28/2002 - Shorewall 1.3.5 Debian Package Available</b></p>

<p>Lorenzo Martignoni reports that the packages are version 1.3.5a and are
available at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

<p><b>7/27/2002 - Shorewall 1.3.5a Released</b></p>

<p>This interim release restores correct handling of REDIRECT rules.</p>

<p><b>7/26/2002 - Shorewall 1.3.5 Released</b></p>

<p>This will be the last Shorewall release for a while. I'm going to be
focusing on rewriting a lot of the documentation.</p>

<p><b>&nbsp;</b> In this version:</p>
<ul>
  <li>Empty and invalid source and destination qualifiers are now detected in
    the rules file. It is a good idea to use the 'shorewall check' command
    before you issue a 'shorewall restart' command be be sure that you don't
    have any configuration problems that will prevent a successful
  restart.</li>
  <li>Added <b>MERGE_HOSTS</b> variable in <a
    href="Documentation.htm#Conf">shorewall.conf</a> to provide saner
    behavior of the /etc/shorewall/hosts file.</li>
  <li>The time that the counters were last reset is now displayed in the
    heading of the 'status' and 'show' commands.</li>
  <li>A <b>proxyarp</b> option has been added for entries in <a
    href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. This
    option facilitates Proxy ARP sub-netting as described in the Proxy ARP
    subnetting mini-HOWTO (<a
    href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>).
    Specifying the proxyarp option for an interface causes Shorewall to set
    /proc/sys/net/ipv4/conf/&lt;interface&gt;/proxy_arp.</li>
  <li>The Samples have been updated to reflect the new capabilities in this
    release.</li>
</ul>

<p><b>7/16/2002 - New Mirror in Argentina</b></p>

<p>Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in
Argentina. Thanks Buanzo!!!</p>

<p><b>7/16/2002 - Shorewall 1.3.4 Released</b></p>

<p>In this version:</p>
<ul>
  <li>A new <a
    href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>
    file has been added. This file is intended to eventually replace the
    <b>routestopped</b> option in the /etc/shorewall/interface and
    /etc/shorewall/hosts files. This new file makes remote firewall
    administration easier by allowing any IP or subnet to be enabled while
    Shorewall is stopped.</li>
  <li>An /etc/shorewall/stopped <a href="Documentation.htm#Scripts">extension
    script</a> has been added. This script is invoked after Shorewall has
    stopped.</li>
  <li>A <b>DETECT_DNAT_ADDRS</b> option has been added to <a
    href="Documentation.htm#Conf">/etc/shoreall/shorewall.conf</a>. When this
    option is selected, DNAT rules only apply when the destination address is
    the external interface's primary IP address.</li>
  <li>The <a href="shorewall_quickstart_guide.htm">QuickStart Guide</a> has
    been broken into three guides and has been almost entirely rewritten.</li>
  <li>The Samples have been updated to reflect the new capabilities in this
    release.</li>
</ul>

<p><b>7/8/2002 - Shorewall 1.3.3 Debian Package Available</b></p>

<p>Lorenzo Marignoni reports that the packages are available at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

<p><b>7/6/2002 - Shorewall 1.3.3 Released</b></p>

<p>In this version:</p>
<ul>
  <li>Entries in /etc/shorewall/interface that use the wildcard character
    ("+") now have the "multi" option assumed.</li>
  <li>The 'rfc1918' chain in the mangle table has been renamed 'man1918' to
    make log messages generated from that chain distinguishable from those
    generated by the 'rfc1918' chain in the filter table.</li>
  <li>Interface names appearing in the hosts file are now validated against
    the interfaces file.</li>
  <li>The TARGET column in the rfc1918 file is now checked for
  correctness.</li>
  <li>The chain structure in the nat table has been changed to reduce the
    number of rules that a packet must traverse and to correct problems with
    NAT_BEFORE_RULES=No</li>
  <li>The "hits" command has been enhanced.</li>
</ul>

<p><b>6/25/2002 - Samples Updated for 1.3.2</b></p>

<p>The comments in the sample configuration files have been updated to
reflect new features introduced in Shorewall 1.3.2.</p>

<p><b>6/25/2002 - Shorewall 1.3.1 Debian Package Available</b></p>

<p>Lorenzo Marignoni reports that the package is available at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

<p><b>6/19/2002 - Documentation Available in PDF Format</b></p>

<p>Thanks to Mike Martinez, the Shorewall Documentation is now available for
<a href="download.htm">download</a> in <a
href="http://www.adobe.com">Adobe</a> PDF format.</p>

<p><b>6/16/2002 - Shorewall 1.3.2 Released</b></p>

<p>In this version:</p>
<ul>
  <li>A <a href="Documentation.htm#Starting">logwatch command</a> has been
    added to /sbin/shorewall.</li>
  <li>A <a href="blacklisting_support.htm">dynamic blacklist facility</a> has
    been added.</li>
  <li>Support for the <a href="Documentation.htm#Conf">Netfilter multiport
    match function</a> has been added.</li>
  <li>The files <b>firewall, functions</b> and <b>version</b> have been moved
    from /etc/shorewall to /var/lib/shorewall.</li>
</ul>

<p><b>6/6/2002 - Why CVS Web access is Password Protected</b></p>

<p>Last weekend, I installed the CVS Web package to provide brower-based
access to the Shorewall CVS repository. Since then, I have had several
instances where my server was almost unusable due to the high load generated
by website copying tools like HTTrack and WebStripper. These mindless
tools:</p>
<ul>
  <li>Ignore robot.txt files.</li>
  <li>Recursively copy everything that they find.</li>
  <li>Should be classified as weapons rather than tools.</li>
</ul>

<p>These tools/weapons are particularly damaging when combined with CVS Web
because they doggedly follow every link in the cgi-generated HTML resulting
in 1000s of executions of the cvsweb.cgi script. Yesterday, I spend several
hours implementing measures to block these tools but unfortunately, these
measures resulted in my server OOM-ing under even moderate load.</p>

<p>Until I have the time to understand the cause of the OOM (or until I buy
more RAM if that is what is required), CVS Web access will remain Password
Protected.</p>

<p><b>6/5/2002 - Shorewall 1.3.1 Debian Package Available</b></p>

<p>Lorenzo Marignoni reports that the package is available at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

<p><b>6/2/2002 - Samples Corrected</b></p>

<p>The 1.3.0 samples configurations had several serious problems that
prevented DNS and SSH from working properly. These problems have been
corrected in the <a href="/pub/shorewall/samples-1.3.1">1.3.1 samples.</a></p>

<p><b>6/1/2002 - Shorewall 1.3.1 Released</b></p>

<p>Hot on the heels of 1.3.0, this release:</p>
<ul>
  <li>Corrects a serious problem with "all <i>&lt;zone&gt;</i> CONTINUE"
    policies. This problem is present in all versions of Shorewall that
    support the CONTINUE policy. These previous versions optimized away the
    "all2<i>&lt;zone&gt;</i>" chain and replaced it with the "all2all" chain
    with the usual result that a policy of REJECT was enforced rather than
    the intended CONTINUE policy.</li>
  <li>Adds an <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</a>
    file for defining the exact behavior of the <a
    href="Documentation.htm#Interfaces">'norfc1918' interface option</a>.</li>
</ul>

<p><b>5/29/2002 - Shorewall 1.3.0 Released</b></p>

<p>In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0
includes:</p>
<ul>
  <li>A 'filterping' interface option that allows ICMP echo-request (ping)
    requests addressed to the firewall to be handled by entries in
    /etc/shorewall/rules and /etc/shorewall/policy.</li>
</ul>

<p><b>5/23/2002 - Shorewall 1.3 RC1 Available</b></p>

<p>In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92)
incorporates the following:</p>
<ul>
  <li>Support for the /etc/shorewall/whitelist file has been withdrawn. If
    you need whitelisting, see <a
    href="/1.3/whitelisting_under_shorewall.htm">these instructions</a>.</li>
</ul>

<p><b>5/19/2002 - Shorewall 1.3 Beta 2 Available</b></p>

<p>In addition to the changes in Beta 1, this release which carries the
designation 1.2.91 adds:</p>
<ul>
  <li>The structure of the firewall is changed markedly. There is now an
    INPUT and a FORWARD chain for each interface; this reduces the number of
    rules that a packet must traverse, especially in complicated setups.</li>
  <li><a href="Documentation.htm#Exclude">Sub-zones may now be excluded from
    DNAT and REDIRECT rules.</a></li>
  <li>The names of the columns in a number of the configuration files have
    been changed to be more consistent and self-explanatory and the
    documentation has been updated accordingly.</li>
  <li>The sample configurations have been updated for 1.3.</li>
</ul>

<p><b>5/17/2002 - Shorewall 1.3 Beta 1 Available</b></p>

<p>Beta 1 carries the version designation 1.2.90 and implements the following
features:</p>
<ul>
  <li>Simplified rule syntax which makes the intent of each rule clearer and
    hopefully makes Shorewall easier to learn.</li>
  <li>Upward compatibility with 1.2 configuration files has been maintained
    so that current users can migrate to the new syntax at their
  convenience.</li>
  <li><b><font color="#CC6666">WARNING:&nbsp; Compatibility with the old
    parameterized sample configurations has NOT been maintained. Users still
    running those configurations should migrate to the new sample
    configurations before upgrading to 1.3 Beta 1.</font></b></li>
</ul>

<p><b>5/4/2002 - Shorewall 1.2.13 is Available</b></p>

<p>In this version:</p>
<ul>
  <li><a href="Documentation.htm#Whitelist">White-listing</a> is
  supported.</li>
  <li><a href="Documentation.htm#Policy">SYN-flood protection</a> is
  added.</li>
  <li>IP addresses added under <a
    href="Documentation.htm#Conf">ADD_IP_ALIASES and ADD_SNAT_ALIASES</a> now
    inherit the VLSM and Broadcast Address of the interface's primary IP
    address.</li>
  <li>The order in which port forwarding DNAT and Static DNAT <a
    href="Documentation.htm#Conf">can now be reversed</a> so that port
    forwarding rules can override the contents of <a
    href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</li>
</ul>

<p><b>4/30/2002 - Shorewall Debian News</b></p>

<p>Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the <a
href="http://packages.debian.org/testing/net/shorewall.html">Debian Testing
Branch</a> and the <a
href="http://packages.debian.org/unstable/net/shorewall.html">Debian Unstable
Branch</a>.</p>

<p><b>4/20/2002 - Shorewall 1.2.12 is Available</b></p>
<ul>
  <li>The 'try' command works again</li>
  <li>There is now a single RPM that also works with SUSE.</li>
</ul>

<p><b>4/17/2002 - Shorewall Debian News</b></p>

<p>Lorenzo Marignoni reports that:</p>
<ul>
  <li>Shorewall 1.2.10 is in the <a
    href="http://packages.debian.org/testing/net/shorewall.html">Debian
    Testing Branch</a></li>
  <li>Shorewall 1.2.11 is in the <a
    href="http://packages.debian.org/unstable/net/shorewall.html">Debian
    Unstable Branch</a></li>
</ul>

<p>Thanks, Lorenzo!</p>

<p><b>4/16/2002 - Shorewall 1.2.11 RPM Available for SUSE</b></p>

<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan Mohr</a>, there
is now a Shorewall 1.2.11 <a
href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm">SUSE
RPM</a> available.</p>

<p><b>4/13/2002 - Shorewall 1.2.11 Available</b></p>

<p>In this version:</p>
<ul>
  <li>The 'try' command now accepts an optional timeout. If the timeout is
    given in the command, the standard configuration will automatically be
    restarted after the new configuration has been running for that length of
    time. This prevents a remote admin from being locked out of the firewall
    in the case where the new configuration starts but prevents access.</li>
  <li>Kernel route filtering may now be enabled globally using the new
    ROUTE_FILTER parameter in <a
    href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
  <li>Individual IP source addresses and/or subnets may now be excluded from
    masquerading/SNAT.</li>
  <li>Simple "Yes/No" and "On/Off" values are now case-insensitive in
    /etc/shorewall/shorewall.conf.</li>
</ul>

<p><b>4/13/2002 - Hamburg Mirror now has FTP</b></p>

<p>Stefan now has an FTP mirror at <a target="_blank"
href="ftp://germany.shorewall.net/pub/shorewall">ftp://germany.shorewall.net/pub/shorewall</a>.&nbsp;
Thanks Stefan!</p>

<p><b>4/12/2002 - New Mirror in Hamburg</b></p>

<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan Mohr</a>, there
is now a mirror of the Shorewall website at <a target="_top"
href="http://germany.shorewall.net">http://germany.shorewall.net</a>.</p>

<p><b>4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available</b></p>

<p><a href="shorewall_quickstart_guide.htm">Version 1.1 of the QuickStart
Guide</a> is now available. Thanks to those who have read version 1.0 and
offered their suggestions. Corrections have also been made to the sample
scripts.</p>

<p><b>4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available</b></p>

<p><a href="shorewall_quickstart_guide.htm">Version 1.0 of the QuickStart
Guide</a> is now available. This Guide and its accompanying sample
configurations are expected to provide a replacement for the recently
withdrawn parameterized samples.</p>

<p><b>4/8/2002 - Parameterized Samples Withdrawn</b></p>

<p>Although the <a
href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized
samples</a> have allowed people to get a firewall up and running quickly,
they have unfortunately set the wrong level of expectation among those who
have used them. I am therefore withdrawing support for the samples and I am
recommending that they not be used in new Shorewall installations.</p>

<p><b>4/2/2002 - Updated Log Parser</b></p>

<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided an
updated version of his <a href="pub/shorewall/parsefw/">CGI-based log
parser</a> with corrected date handling.</p>

<p><b>3/30/2002 - Shorewall Website Search Improvements</b></p>

<p>The quick search on the home page now excludes the mailing list archives.
The <a href="htdig/search.html">Extended Search</a> allows excluding the
archives or restricting the search to just the archives. An archive search
form is also available on the <a
href="http://lists.shorewall.net/mailing_list.htm">mailing list information
page</a>.</p>

<p><b>3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)</b></p>
<ul>
  <li>The 1.2.10 Debian Package is available at <a
    href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
  <li>Shorewall 1.2.9 is now in the <a
    href="http://packages.debian.org/unstable/net/shorewall.html">Debian
    Unstable Distribution</a>.</li>
</ul>

<p><b>3/25/2002 - Log Parser Available</b></p>

<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided a <a
href="pub/shorewall/parsefw/">CGI-based log parser</a> for Shorewall. Thanks
John.</p>

<p><b>3/20/2002 - Shorewall 1.2.10 Released</b></p>

<p>In this version:</p>
<ul>
  <li>A "shorewall try" command has been added (syntax: shorewall try
    <i>&lt;configuration directory&gt;</i>). This command attempts "shorewall
    -c <i>&lt;configuration directory&gt;</i> start" and if that results in
    the firewall being stopped due to an error, a "shorewall start" command
    is executed. The 'try' command allows you to create a new <a
    href="Documentation.htm#Configs">configuration</a> and attempt to start
    it; if there is an error that leaves your firewall in the stopped state,
    it will automatically be restarted using the default configuration (in
    /etc/shorewall).</li>
  <li>A new variable ADD_SNAT_ALIASES has been added to <a
    href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>. If this
    variable is set to "Yes", Shorewall will automatically add IP addresses
    listed in the third column of the <a
    href="Documentation.htm#Masq">/etc/shorewall/masq</a> file.</li>
  <li>Copyright notices have been added to the documenation.</li>
</ul>

<p><b>3/11/2002 - Shorewall 1.2.9 Released</b></p>

<p>In this version:</p>
<ul>
  <li>Filtering by <a href="Documentation.htm#MAC">MAC address</a> has been
    added. MAC addresses may be used as the source address in: 
    <ul>
      <li>Filtering rules (<a
        href="Documentation.htm#Rules">/etc/shorewall/rules</a>)</li>
      <li>Traffic Control Classification Rules (<a
        href="traffic_shaping.htm#tcrules">/etc/shorewall/tcrules</a>)</li>
      <li>TOS Rules (<a
      href="Documentation.htm#TOS">/etc/shorewall/tos</a>)</li>
      <li>Blacklist (<a
        href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a>)</li>
    </ul>
  </li>
  <li>Several bugs have been fixed</li>
  <li>The 1.2.9 Debian Package is also available at <a
    href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
</ul>

<p><b>3/1/2002 - 1.2.8 Debian Package is Available</b></p>

<p>See <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

<p><b>2/25/2002 - New Two-interface Sample</b></p>

<p>I've enhanced the two interface sample to allow access from the firewall
to servers in the local zone - <a
href="http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz">http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz</a></p>

<p><b>2/23/2002 - Shorewall 1.2.8 Released</b></p>

<p>Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects
problems associated with the lock file used to prevent multiple
state-changing operations from occuring simultaneously. My apologies for any
inconvenience my carelessness may have caused.</p>

<p><b>2/22/2002 - Shorewall 1.2.7 Released</b></p>

<p>In this version:</p>
<ul>
  <li>UPnP probes (UDP destination port 1900) are now silently dropped in the
    <i>common</i> chain</li>
  <li>RFC 1918 checking in the mangle table has been streamlined to no longer
    require packet marking. RFC 1918 checking in the filter table has been
    changed to require half as many rules as previously.</li>
  <li>A 'shorewall check' command has been added that does a cursory
    validation of the zones, interfaces, hosts, rules and policy files.</li>
</ul>

<p><b>2/18/2002 - 1.2.6 Debian Package is Available</b></p>

<p>See <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

<p><b>2/8/2002 - Shorewall 1.2.6 Released</b></p>

<p>In this version:</p>
<ul>
  <li>$-variables may now be used anywhere in the configuration files except
    /etc/shorewall/zones.</li>
  <li>The interfaces and hosts files now have their contents validated before
    any changes are made to the existing Netfilter configuration. The
    appearance of a zone name that isn't defined in /etc/shorewall/zones
    causes "shorewall start" and "shorewall restart" to abort without
    changing the Shorewall state. Unknown options in either file cause a
    warning to be issued.</li>
  <li>A problem occurring when BLACKLIST_LOGLEVEL was not set has been
    corrected.</li>
</ul>

<p><b>2/4/2002 - Shorewall 1.2.5 Debian Package Available</b></p>

<p>see <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

<p><b>2/1/2002 - Shorewall 1.2.5 Released</b></p>

<p>Due to installation problems with Shorewall 1.2.4, I have released
Shorewall 1.2.5. Sorry for the rapid-fire development.</p>

<p>In version 1.2.5:</p>
<ul>
  <li>The installation problems have been corrected.</li>
  <li><a href="Documentation.htm#Masq">SNAT</a> is now supported.</li>
  <li>A "shorewall version" command has been added</li>
  <li>The default value of the STATEDIR variable in
    /etc/shorewall/shorewall.conf has been changed to /var/lib/shorewall in
    order to conform to the GNU/Linux File Hierarchy Standard, Version
  2.2.</li>
</ul>

<p><b>1/28/2002 - Shorewall 1.2.4 Released</b></p>
<ul>
  <li>The "fw" zone <a href="Documentation.htm#FW">may now be given a
    different name</a>.</li>
  <li>You may now place end-of-line comments (preceded by '#') in any of the
    configuration files</li>
  <li>There is now protection against against two state changing operations
    occuring concurrently. This is implemented using the 'lockfile' utility
    if it is available (lockfile is part of procmail); otherwise, a less
    robust technique is used. The lockfile is created in the STATEDIR defined
    in /etc/shorewall/shorewall.conf and has the name "lock".</li>
  <li>"shorewall start" no longer fails if "detect" is specified in <a
    href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a> for an
    interface with subnet mask 255.255.255.255.</li>
</ul>

<p><b>1/27/2002 - Shorewall 1.2.3 Debian Package Available</b> -- see <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

<p><b>1/20/2002 - Corrected firewall script available&nbsp;</b></p>

<p>Corrects a problem with BLACKLIST_LOGLEVEL. See <a href="errata.htm">the
errata</a> for details.</p>

<p><b>1/19/2002 - Shorewall 1.2.3 Released</b></p>

<p>This is a minor feature and bugfix release. The single new feature is:</p>
<ul>
  <li>Support for TCP MSS Clamp to PMTU -- This support is usually required
    when the internet connection is via PPPoE or PPTP and may be enabled
    using the <a href="Documentation.htm#ClampMSS">CLAMPMSS</a> option in
    /etc/shorewall/shorewall.conf.</li>
</ul>

<p>The following problems were corrected:</p>
<ul>
  <li>The "shorewall status" command no longer hangs.</li>
  <li>The "shorewall monitor" command now displays the icmpdef chain</li>
  <li>The CLIENT PORT(S) column in tcrules is no longer ignored</li>
</ul>

<p><b>1/18/2002 - Shorewall 1.2.2 packaged with new</b> <a
href="http://leaf.sourceforge.net">LEAF</a> <b>release</b></p>

<p>Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF
distribution that includes Shorewall 1.2.2. See <a
href="http://leaf.sourceforge.net/devel/jnilo">http://leaf.sourceforge.net/devel/jnilo</a>
for details.</p>

<p><b>1/11/2002 - Debian Package (.deb) Now Available -</b> Thanks to <a
href="mailto:lorenzo.martignoni@milug.org">Lorenzo Martignoni</a>, a 1.2.2
Shorewall Debian package is now available. There is a link to Lorenzo's site
from the <a href="download.htm">Shorewall download page</a>.</p>

<p><b>1/9/2002 - Updated 1.2.2 /sbin/shorewall available -</b> <a
href="/pub/shorewall/errata/1.2.2/shorewall">This corrected version</a>
restores the "shorewall status" command to health.</p>

<p><b>1/8/2002 - Shorewall 1.2.2 Released</b></p>

<p>In version 1.2.2</p>
<ul>
  <li>Support for IP blacklisting has been added 
    <ul>
      <li>You specify whether you want packets from blacklisted hosts dropped
        or rejected using the <a
        href="Documentation.htm#BLDisposition">BLACKLIST_DISPOSITION</a>
        setting in /etc/shorewall/shorewall.conf</li>
      <li>You specify whether you want packets from blacklisted hosts logged
        and at what syslog level using the <a
        href="Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL</a> setting in
        /etc/shorewall/shorewall.conf</li>
      <li>You list the IP addresses/subnets that you wish to blacklist in <a
        href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a></li>
      <li>You specify the interfaces you want checked against the blacklist
        using the new "<a href="Documentation.htm#BLInterface">blacklist</a>"
        option in /etc/shorewall/interfaces.</li>
      <li>The black list is refreshed from /etc/shorewall/blacklist by the
        "shorewall refresh" command.</li>
    </ul>
  </li>
  <li>Use of TCP RST replies has been expanded&nbsp; 
    <ul>
      <li>TCP connection requests rejected because of a REJECT policy are now
        replied with a TCP RST packet.</li>
      <li>TCP connection requests rejected because of a protocol=all rule in
        /etc/shorewall/rules are now replied with a TCP RST packet.</li>
    </ul>
  </li>
  <li>A <a href="Documentation.htm#Logfile">LOGFILE</a> specification has
    been added to /etc/shorewall/shorewall.conf. LOGFILE is used to tell the
    /sbin/shorewall program where to look for Shorewall messages.</li>
</ul>

<p><b>1/5/2002 - New Parameterized Samples (<a
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.2.0/"
target="_blank">version 1.2.0</a>) released.</b> These are minor updates to
the previously-released samples. There are two new rules added:</p>
<ul>
  <li>Unless you have explicitly enabled Auth connections (tcp port 113) to
    your firewall, these connections will be REJECTED rather than DROPPED.
    This speeds up connection establishment to some servers.</li>
  <li>Orphan DNS replies are now silently dropped.</li>
</ul>

<p>See the README file for upgrade instructions.</p>

<p><b>1/1/2002 - <u><font color="#FF6633">Shorewall Mailing List
Moving</font></u></b></p>

<p>The Shorewall mailing list hosted at <a
href="http://sourceforge.net">Sourceforge</a> is moving to Shorewall.net. If
you are a current subscriber to the list at Sourceforge, please <a
href="shorewall_mailing_list_migration.htm">see these instructions</a>. If
you would like to subscribe to the new list, visit <a
href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>.</p>

<p><b>12/31/2001 - Shorewall 1.2.1 Released</b></p>

<p>In version 1.2.1:</p>
<ul>
  <li><a href="Documentation.htm#LogUncleanOption">Logging of Mangled/Invalid
    Packets</a> is added.&nbsp;</li>
  <li>The <a href="IPIP.htm">tunnel script</a> has been corrected.</li>
  <li>'shorewall show tc' now correctly handles tunnels.</li>
</ul>

<p><b>12/21/2001 - Shorewall 1.2.0 Released!</b> - <b>I couldn't resist
releasing 1.2 on 12/21/2001</b></p>

<p>Version 1.2 contains the following new features:</p>
<ul>
  <li>Support for <a href="traffic_shaping.htm">Traffic
  Control/Shaping</a></li>
  <li>Support for <a href="Documentation.htm#Unclean">Filtering of
    Mangled/Invalid Packets</a></li>
  <li>Support for <a href="IPIP.htm">GRE Tunnels</a></li>
</ul>

<p>For the next month or so, I will continue to provide corrections to
version 1.1.18 as necessary so that current version 1.1.x users will not be
forced into a quick upgrade to 1.2.0 just to have access to bug fixes.</p>

<p>For those of you who have installed one of the Beta RPMS, you will need to
use the "--oldpackage" option when upgrading to 1.2.0:</p>

<blockquote>
  <p>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</p>
</blockquote>

<p><b>12/19/2001 - Thanks to <a href="mailto:scowles@infohiiway.com">Steve
Cowles</a>, there is now a Shorewall mirror in Texas.</b> This web site is
mirrored at <a href="http://www.infohiiway.com/shorewall"
target="_top">http://www.infohiiway.com/shorewall</a> and the ftp site is at
<a
href="ftp://ftp.infohiiway.com/pub/mirrors/shorewall">ftp://ftp.infohiiway.com/pub/mirrors/shorewall</a>.
<b>&nbsp;</b></p>

<p><b>11/30/2001 - A new set of the parameterized <a
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample
Configurations</a> has been released</b>. In this version:</p>
<ul>
  <li>Ping is now allowed between the zones.</li>
  <li>In the three-interface configuration, it is now possible to configure
    the internet services that are to be available to servers in the
    DMZ.&nbsp;</li>
</ul>

<p><b>11/20/2001 - The current version of Shorewall is 1.1.18.&nbsp;</b></p>

<p>In this version:</p>
<ul>
  <li>The spelling of ADD_IP_ALIASES has been corrected in the shorewall.conf
    file</li>
  <li>The logic for deleting user-defined chains has been simplified so that
    it avoids a bug in the LRP version of the 'cut' utility.</li>
  <li>The /var/lib/lrpkg/shorwall.conf file has been corrected to properly
    display the NAT entry in that file.</li>
</ul>

<p><b>11/19/2001 - Thanks to <a href="mailto:shorewall@timelord.sk">Juraj
Ontkanin</a>, there is now a Shorewall mirror in the Slovak Republic</b>. The
website is now mirrored at <a href="http://www.nrg.sk/mirror/shorewall"
target="_top">http://www.nrg.sk/mirror/shorewall</a> and the FTP site is
mirrored at <a
href="ftp://ftp.nrg.sk/mirror/shorewall">ftp://ftp.nrg.sk/mirror/shorewall</a>.</p>

<p><b>11/2/2001 - Announcing Shorewall Parameter-driven Sample
Configurations.</b> There are three sample configurations:</p>
<ul>
  <li>One Interface -- for a standalone system.</li>
  <li>Two Interfaces -- A masquerading firewall.</li>
  <li>Three Interfaces -- A masquerading firewall with DMZ.</li>
</ul>

<p>Samples may be downloaded from <a
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17">ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17</a>
. See the README file for instructions.</p>

<p><b>11/1/2001 - The current version of Shorewall is 1.1.17</b>.&nbsp; I
intend this to be the last of the 1.1 Shorewall releases.</p>

<p>In this version:</p>
<ul>
  <li>The handling of <a href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>
    has been corrected.&nbsp;</li>
</ul>

<p><b>10/22/2001 - The current version of Shorewall is 1.1.16</b>. In this
version:</p>
<ul>
  <li>A new "shorewall show connections" command has been added.</li>
  <li>In the "shorewall monitor" output, the currently tracked connections
    are now shown on a separate page.</li>
  <li>Prior to this release, Shorewall unconditionally added the external IP
    adddress(es) specified in /etc/shorewall/nat. Beginning with version
    1.1.16, a new parameter (<a
    href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>) may be set to "no"
    (or "No") to inhibit this behavior. This allows IP aliases created using
    your distribution's network configuration tools to be used in static
    NAT.&nbsp;</li>
</ul>

<p><b>10/15/2001 - The current version of Shorewall is 1.1.15.</b> In this
version:</p>
<ul>
  <li>Support for nested zones has been improved. See <a
    href="Documentation.htm#Nested">the documentation</a> for details</li>
  <li>Shorewall now correctly checks the alternate configuration directory
    for the 'zones' file.</li>
</ul>

<p><b>10/4/2001 - The current version of Shorewall is 1.1.14.</b> In this
version</p>
<ul>
  <li>Shorewall now supports alternate configuration directories. When an
    alternate directory is specified when starting or restarting Shorewall
    (e.g., "shorewall -c /etc/testconf restart"), Shorewall will first look
    for configuration files in the alternate directory then in
    /etc/shorewall. To create an alternate configuration simply:<br>
    1. Create a New Directory<br>
    2. Copy to that directory any of your configuration files that you want
    to change.<br>
    3. Modify the copied files as needed.<br>
    4. Restart Shorewall specifying the new directory.</li>
  <li>The rules for allowing/disallowing icmp echo-requests (pings) are now
    moved after rules created when processing the rules file. This allows you
    to add rules that selectively allow/deny ping based on source or
    destination address.</li>
  <li>Rules that specify multiple client ip addresses or subnets no longer
    cause startup failures.</li>
  <li>Zone names in the policy file are now validated against the zones
  file.</li>
  <li>If you have <a href="Documentation.htm#MangleEnabled">packet
    mangling</a> support enabled, the "<a
    href="Documentation.htm#Interfaces">norfc1918</a>" interface option now
    logs and drops any incoming packets on the interface that have an RFC
    1918 destination address.</li>
</ul>

<p><b>9/12/2001 - The current version of Shorewall is 1.1.13</b>. In this
version</p>
<ul>
  <li>Shell variables can now be used to parameterize Shorewall rules.</li>
  <li>The second column in the hosts file may now contain a comma-separated
    list.<br>
    <br>
    Example:<br>
    &nbsp;&nbsp;&nbsp; sea&nbsp;&nbsp;&nbsp;
    eth0:130.252.100.0/24,206.191.149.0/24</li>
  <li>Handling of multi-zone interfaces has been improved. See the <a
    href="Documentation.htm#Interfaces">documentation for the
    /etc/shorewall/interfaces file</a>.</li>
</ul>

<p><b>8/28/2001 - The current version of Shorewall is 1.1.12</b>. In this
version</p>
<ul>
  <li>Several columns in the rules file may now contain comma-separated
  lists.</li>
  <li>Shorewall is now more rigorous in parsing the options in
    /etc/shorewall/interfaces.</li>
  <li>Complementation using "!" is now supported in rules.</li>
</ul>

<p><b>7/28/2001 - The current version of Shorewall is 1.1.11</b>. In this
version</p>
<ul>
  <li>A "shorewall refresh" command has been added to allow for refreshing
    the rules associated with the broadcast address on a dynamic interface.
    This command should be used in place of "shorewall restart" when the
    internet interface's IP address changes.</li>
  <li>The /etc/shorewall/start file (if any) is now processed after all
    temporary rules have been deleted. This change prevents the accidental
    removal of rules added during the processing of that file.</li>
  <li>The "dhcp" interface option is now applicable to firewall interfaces
    used by a DHCP server running on the firewall.</li>
  <li>The RPM can now be built from the .tgz file using "rpm -tb"&nbsp;</li>
</ul>

<p><b>7/6/2001 - The current version of Shorewall is 1.1.10.</b> In this
version</p>
<ul>
  <li>Shorewall now enables Ipv4 Packet Forwarding by default. Packet
    forwarding may be disabled by specifying IP_FORWARD=Off in
    /etc/shorewall/shorewall.conf. If you don't want Shorewall to enable or
    disable packet forwarding, add IP_FORWARDING=Keep to your
    /etc/shorewall/shorewall.conf file.</li>
  <li>The "shorewall hits" command no longer lists extraneous service names
    in its last report.</li>
  <li>Erroneous instructions in the comments at the head of the firewall
    script have been corrected.</li>
</ul>

<p><b>6/23/2001 - The current version of Shorewall is 1.1.9.</b> In this
version</p>
<ul>
  <li>The "tunnels" file <u>really</u> is in the RPM now.</li>
  <li>SNAT can now be applied to port-forwarded connections.</li>
  <li>A bug which would cause firewall start failures in some dhcp
    configurations has been fixed.</li>
  <li>The firewall script now issues a message if you have the name of an
    interface in the second column in an entry in /etc/shorewall/masq and
    that interface is not up.</li>
  <li>You can now configure Shorewall so that it <a
    href="Documentation.htm#NatEnabled">doesn't require the NAT and/or mangle
    netfilter modules</a>.</li>
  <li>Thanks to Alex&nbsp; Polishchuk, the "hits" command from seawall is now
    in shorewall.</li>
  <li>Support for <a href="IPIP.htm">IPIP tunnels</a> has been added.</li>
</ul>

<p><b>6/18/2001 - The current version of Shorewall is 1.1.8</b>. In this
version</p>
<ul>
  <li>A typo in the sample rules file has been corrected.</li>
  <li>It is now possible to restrict masquerading by <a
    href="Documentation.htm#Masq">destination host or subnet.</a></li>
  <li>It is now possible to have static <a href="NAT.htm#LocalPackets">NAT
    rules applied to packets originating on the firewall itself</a>.</li>
</ul>

<p><b>6/2/2001 - The current version of Shorewall is 1.1.7.</b> In this
version</p>
<ul>
  <li>The TOS rules are now deleted when the firewall is stopped.</li>
  <li>The .rpm will now install regardless of which version of iptables is
    installed.</li>
  <li>The .rpm will now install without iproute2 being installed.</li>
  <li>The documentation has been cleaned up.</li>
  <li>The sample configuration files included in Shorewall have been
    formatted to 80 columns for ease of editing on a VGA console.</li>
</ul>

<p><b>5/25/2001 - The current version of Shorewall is 1.1.6</b>. In this
version</p>
<ul>
  <li><a href="Documentation.htm#lograte">You may now rate-limit the packet
    log.</a></li>
  <li>Previous versions of Shorewall have an implementation of Static NAT
    which violates the principle of least surprise.&nbsp; NAT only occurs for
    packets arriving at (DNAT) or send from (SNAT) the interface named in the
    INTERFACE column of /etc/shorewall/nat. Beginning with version 1.1.6, NAT
    effective regardless of which interface packets come from or are destined
    to. To get compatibility with prior versions, I have added a new "ALL <a
    href="NAT.htm#AllInterFaces">"ALL INTERFACES"&nbsp; column to
    /etc/shorewall/nat</a>. By placing "no" or "No" in the new column, the
    NAT behavior of prior versions may be retained.&nbsp;</li>
  <li>The treatment of <a href="IPSEC.htm#RoadWarrior">IPSEC Tunnels where
    the remote gateway is a standalone system has been improved</a>.
    Previously, it was necessary to include an additional rule allowing UDP
    port 500 traffic to pass through the tunnel. Shorewall will now create
    this rule automatically when you place the name of the remote peer's zone
    in a new GATEWAY ZONE column in /etc/shorewall/tunnels.&nbsp;</li>
</ul>

<p><b>5/20/2001 - The current version of Shorewall is 1.1.5.</b> In this
version</p>
<ul>
  <li><a href="Documentation.htm#modules">You may now pass parameters when
    loading netfilter modules and you can specify the modules to
  load.</a></li>
  <li>Compressed modules are now loaded. This requires that you modutils
    support loading compressed modules.</li>
  <li><a href="Documentation.htm#TOS">You may now set the Type of Service
    (TOS) field in packets.</a></li>
  <li>Corrected rules generated for port redirection (again).</li>
</ul>

<p><b>5/10/2001 - The current version of Shorewall is 1.1.4.</b> In this
version</p>
<ul>
  <li><a href="Documentation.htm#Conf">Accepting RELATED connections is now
    optional.</a></li>
  <li>Corrected problem where if "shorewall start" aborted early (due to
    kernel configuration errors for example), superfluous 'sed' error
    messages were reported.</li>
  <li>Corrected rules generated for port redirection.</li>
  <li>The order in which iptables kernel modules are loaded has been
    corrected (Thanks to Mark Pavlidis).&nbsp;</li>
</ul>

<p><b>4/28/2001 - The current version of Shorewall is 1.1.3.</b> In this
version</p>
<ul>
  <li>Correct message issued when Proxy ARP address added (Thanks to Jason
    Kirtland).</li>
  <li>/tmp/shorewallpolicy-$$ is now removed if there is an error while
    starting the firewall.</li>
  <li>/etc/shorewall/icmp.def and /etc/shorewall/common.def are now used to
    define the icmpdef and common chains unless overridden by the presence of
    /etc/shorewall/icmpdef or /etc/shorewall/common.</li>
  <li>In the .lrp, the file /var/lib/lrpkg/shorwall.conf has been corrected.
    An extra space after "/etc/shorwall/policy" has been removed and
    "/etc/shorwall/rules" has been added.</li>
  <li>When a sub-shell encounters a fatal error and has stopped the firewall,
    it now kills the main shell so that the main shell will not continue.</li>
  <li>A problem has been corrected where a sub-shell stopped the firewall and
    main shell continued resulting in a perplexing error message referring to
    "common.so" resulted.</li>
  <li>Previously, placing "-" in the PORT(S) column in /etc/shorewall/rules
    resulted in an error message during start. This has been corrected.</li>
  <li>The first line of "install.sh" has been corrected -- I had
    inadvertently deleted the initial "#".</li>
</ul>

<p><b>4/12/2001 - The current version of Shorewall is 1.1.2.</b> In this
version</p>
<ul>
  <li>Port redirection now works again.</li>
  <li>The icmpdef and common chains <a href="Documentation.htm#Icmpdef">may
    now be user-defined</a>.</li>
  <li>The firewall no longer fails to start if "routefilter" is specified for
    an interface that isn't started. A warning message is now issued in this
    case.</li>
  <li>The LRP Version is renamed "shorwall" for 8,3 MSDOS file system
    compatibility.</li>
  <li>A couple of LRP-specific problems were corrected.</li>
</ul>

<p><b>4/8/2001 - Shorewall is now affiliated with the <a
href="http://leaf.sourceforge.net">Leaf Project</a></b> <a
href="http://leaf.sourceforge.net"><img src="images/leaflogo.gif"
alt="Leaf Logo" border="0" height="36" width="49" /></a></p>

<p><b>4/5/2001 - The current version of Shorewall is 1.1.1. In this
version:</b></p>
<ul>
  <li>The common chain is traversed from INPUT, OUTPUT and FORWARD before
    logging occurs</li>
  <li>The source has been cleaned up dramatically</li>
  <li>DHCP DISCOVER packets with RFC1918 source addresses no longer generate
    log messages. Linux DHCP clients generate such packets and it's annoying
    to see them logged.&nbsp;</li>
</ul>

<p><b>3/25/2001 - The current version of Shorewall is 1.1.0. In this
version:</b></p>
<ul>
  <li>Log messages now indicate the packet disposition.</li>
  <li>Error messages have been improved.</li>
  <li>The ability to define zones consisting of an enumerated set of hosts
    and/or subnetworks has been added.</li>
  <li>The zone-to-zone chain matrix is now sparse so that only those chains
    that contain meaningful rules are defined.</li>
  <li>240.0.0.0/4 and 169.254.0.0/16 have been added to the source
    subnetworks whose packets are dropped under the <i>norfc1918</i>
    interface option.</li>
  <li>Exits are now provided for executing an user-defined script when a
    chain is defined, when the firewall is initialized, when the firewall is
    started, when the firewall is stopped and when the firewall is
  cleared.</li>
  <li>The Linux kernel's route filtering facility can now be specified
    selectively on network interfaces.</li>
</ul>

<p><b>3/19/2001 - The current version of Shorewall is 1.0.4. This
version:</b></p>
<ul>
  <li>Allows user-defined zones. Shorewall now has only one pre-defined zone
    (fw) with the remaining zones being defined in the new configuration file
    /etc/shorewall/zones. The /etc/shorewall/zones file released in this
    version provides behavior that is compatible with Shorewall
  1.0.3.&nbsp;</li>
  <li>Adds the ability to specify logging in entries in the
    /etc/shorewall/rules file.</li>
  <li>Correct handling of the icmp-def chain so that only ICMP packets are
    sent through the chain.</li>
  <li>Compresses the output of "shorewall monitor" if awk is installed.
    Allows the command to work if awk isn't installed (although it's not
    pretty).</li>
</ul>

<p><b>3/13/2001 - The current version of Shorewall is 1.0.3. This is a
bug-fix release with no new features.</b></p>
<ul>
  <li>The PATH variable in the firewall script now includes /usr/local/bin
    and /usr/local/sbin.</li>
  <li>DMZ-related chains are now correctly deleted if the DMZ is deleted.</li>
  <li>The interface OPTIONS for "gw" interfaces are no longer ignored.</li>
</ul>

<p><b>3/8/2001 - The current version of Shorewall is 1.0.2. It supports an
additional "gw" (gateway) zone for tunnels and it supports IPSEC tunnels with
end-points on the firewall. There is also a .lrp available now.</b></p>
</body>
</html>