<pre>Problems corrected in Shorewall-perl 4.0.8.<br><br>1) Mark tests (such as in the TEST column of tcrules or the MARK<br> column of the rules file) were ignoring the value 0. As part of<br> this fix, the default mask generated by entries in these columns<br> has been changed from 0xFF to 0xFFFF for compatibility with<br> Shorewall-shell.<br><br>2) The compilation date recorded in the firewall.conf file produced by<br> Shorewall-perl was previously mangled.<br><br>3) The ability to specify a DEST IP range (round-robin) in a DNAT rule<br> has been restored. In versions 4.0.5 - 4.0.7, an IP range was<br> incorrectly flagged as an error.<br><br>Problems corrected in Shorewall-shell 4.0.8.<br><br>1) Shorewall-shell now properly parses comma separated SOURCE (formerly<br> SUBNET) values in the masq configuration file. Previously, the comma<br> separated list was not split up into its components, resulting in an<br> invalid address being passed to the iptables command.<br><br> Example:<br><br> # /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC<br> eth0 192.168.2.1,192.168.2.3<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.8.<br><br>None.<br></pre>
<pre> This problem was experienced mostly by Debian users and users of<br> Debian derivatives such as Ubuntu.</pre>
<pre>2) The iptables utility doesn't retry operations that fail due to<br> resource shortage. Beginning with this release, Shorewall reruns<br> iptables when such a failure occurs.</pre>
<pre>3) Previously, Shorewall-perl did not accept log levels in upper case<br> (e.g., INFO). Beginning with 4.0.7, log levels are treated in a<br> case-insensitive manner by Shorewall-perl.</pre>
<pre>4) The column headers in macro files were not aligned. This has been<br> corrected, along with some inaccuracies in the macro.template file.</pre>
<pre>5) The shorewall.conf files in the Samples did not contain some<br> recently-defined options. They are now up to date.</pre>
<pre>6) The names of the Jabber macros were shuffled. They are now named<br> correctly.</pre>
<pre>7) If ADD_IP_ALIASES=Yes, an alias was incorrectly added when the<br> specified INTERFACE ended with ":" (e.g., eth0:).</pre>
<pre>8) Shorewall-shell generated an incorrect iptables rule from the<br> following:</pre>
<pre>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.</pre>
<pre>Other changes in 4.0.7</pre>
<pre>1) If the program named in SHOREWALL_SHELL doesn't exist or is not<br> executable, Shorewall and Shorewall-lite now both fall back to<br> /bin/sh after issuing a warning message. Previously, both<br> terminated with a fatal error.</pre>
<pre>2) The error message has been improved when a non-root user attempts<br> "shorewall show capabilities".</pre>
<pre>3) Shorewall-perl now generates fatal error conditions when there are<br> no IPv4 zones defined and when there are no interfaces defined.<hr></pre>
<pre>1) If NFLOG or ULOG was specified with parameters, the resulting<br> iptables-restore input contained elements that were incorrectly<br> up-cased.</pre>
<pre>2) If STARTUP_LOG is specified without LOG_VERBOSITY, /sbin/shorewall<br> produces an error.</pre>
<pre>3) If LOG_VERBOSITY is specified without STARTUP_LOG, run-time error<br> messages are produced.</pre>
<pre>4) Shorewall-shell was mishandling the entries in /etc/shorewall/rules<br> and in /etc/shorewall/tcrules where both a SOURCE interface and MAC<br> address were specified.</pre>
<pre>1) If the program named in SHOREWALL_SHELL doesn't exist or is not<br> executable, Shorewall and Shorewall-lite now both fall back to<br> /bin/sh after issuing a warning message. Previously, both<br> terminated with a fatal error.</pre>
<pre>2) The error message has been improved when a non-root user attempts<br> "shorewall show capabilities".</pre>
<pre>3) Shorewall-perl now generates fatal error conditions when there are<br> no IPv4 zones defined and when there are no interfaces defined.</pre>
<pre>4) Shorewall now unconditionally uses tc filter rules to classify<br> traffic by MARK value. Previously, Shorewall used the CLASSIFY<br> target in the POSTROUTING chain if it was available.</pre>
<pre>5) The Shorewall-common installer (install.sh) now works on Windows<br> under Cygwin.</pre>
<pre> To install Shorewall-perl under Cygwin:</pre>
<pre> $ tar -xf shorewall-perl-4.1.3.tar.bz2<br> $ tar -xf shorewall-common-4.1.3.tar.bz2<br> $ cd shorewall-perl-4.1.3<br> $ ./install.sh<br> $ cd ../shorewall-common-4.1.3<br> $ USER=<your user id> GROUP=None ./install.sh<br> <br> The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).<hr></pre>
<pre>Problems corrected in Shorewall-perl 4.0.6.<br><br>1) In a DNAT or REDIRECT rule, if no serverport was given and the DEST<br> PORT(S) list contained a service name containing a hyphen ("-") then<br> an ERROR was generated.<br><br> Example -- Rules file:<br><br> DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125<br><br> Results in:<br><br> ERROR: Invalid port range (ms:wbt:server) : rules (line 49)<br><br> Problem was introduced in Shorewall 4.0.5 and does not occur in<br> earlier releases.<br><br>2) If a long destination port list needed to be broken at a port pair,<br> the generated rule contained an extra comma which resulted in an<br> iptables-restore failure.<br><br>3) Several problems involving port ranges and port lists in REDIRECT<br> rules have been corrected.<br><br>4) Shorewall-perl no longer requires an address in the GATEWAY column<br> of /etc/shorewall/tunnels. If the column is left empty (or contains<br> '-') then 0.0.0.0/0 is assumed.<br><br>5) Previously with Shorewall-perl, redirecting both STDOUT and STDERR<br> to the same file descriptor resulted in scrambled output between<br> the two. The error messages were often in the middle of the<br> regular output far ahead of the point where the error occurred.<br><br> This problem was possible in the Debian Shorewall init script<br> (/etc/init.d/shorewall) which redirects output to the<br> Debian-specific /var/log/shorewall-init.log file in this way:<br><br> $SRWL $SRWL_OPTS start >> $INITLOG 2>&1 && ...<br><br>6) With both compilers, when HIGH_ROUTE_MARKS=Yes, unpredictable<br> results could occur when marking in the PREROUTING or OUTPUT<br> chains. When a rule specified a mark value > 255, the compilers<br> were using the '--or-mark' operator rather than the '--set-mark'<br> operator. Consequently, when a packet matched more than one<br> rule, the resulting routing mark was the logical product of the<br> mark values in the matching rules rather than the mark value from<br> the last matching rule.<br><br> Example:<br><br> 0x100 192.168.1.44 0.0.0.0/0<br> 0x200 0.0.0.0/0 0.0.0.0/0 tcp 25<br><br> A TCP packet from 192.168.1.44 with destination port 25 would have<br> a mark value of 0x300 rather than the expected value of 0x200.<br><br>7) Previously, a 'start -f' on Shorewall Lite would produce the<br> following distressing output before starting the firewall:<br><br> make: *** No rule to make target `/firewall', needed by<br> `/var/lib/shorewall-lite/restore'. Stop.<br><br> Furthermore, the Makefile for both Shorewall and Shorewall Lite<br> failed to take into account the /etc/shorewall/vardir file.<br><br> This has been corrected. As part of the fix, both /sbin/shorewall<br> and /sbin/shorewall-lite support a "show vardir" command that<br> displays the VARDIR setting.<br><br>8) Shorewall-perl was previously ignoring the USER/GROUP column of the<br> tcrules file.<br><br>9) Supplying the name of a built-in chain in the 'refresh' command<br> caused entries in the chain to be duplicated. Since this is a<br> feature of iptables-restore with the '-n' option, built-in chains<br> in the 'refresh' list will now be rejected.<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in Shorewall 4.0.6.<br><br>1) Shorewall-perl now uses the '--physdev-is-bridged' option when it<br> is available. This option will suppress messages like the following:<br><br> kernel: physdev match: using --physdev-out in the OUTPUT, FORWARD and<br> POSTROUTING chains for non-bridged traffic is not supported<br> anymore.<br><br> This change only affects users who use bport/bport4 zones in a<br> briged configuration and requires that capabilities fil
<pre>Problems corrected in Shorewall 4.0.5.<br><br>1) Previously, Shorewall-perl misprocessed $FW::<port> in the DEST<br> column of a REDIRECT rule, generating an error. '$FW::<port>' now<br> produces the same effect as '<port>'.<br><br>2) If the PROTOCOL (PROTO) column contained 'TCP' or 'UDP' and SOURCE<br> PORT(S) or DEST PORT(S) were given, then Shorewall-perl rejected<br> the entry with the error:<br><br> ERROR: SOURCE/DEST PORT(S) not allowed with PROTO TCP : /etc/shorewall/rules <br><br> The rule was accepted if 'tcp' or 'udp' was used instead.<br><br>3) Shorewall-shell now removes any default bindings of ipsets before<br> attempting to reload them. Previously, default bindings were not<br> removed with the result that the ipsets could not be destroyed.<br><br>Other changes in Shorewall 4.0.5.<br><br>1) Two new options have been added to /etc/shorewall/hosts<br> (Shorewall-perl only).<br><br> broadcast: Permits limited broadcast (destination 255.255.255.255)<br> to the zone.<br><br> destonly: Normally used with the Multi-cast range. Specifies that<br> traffic will be sent to the specified net(s) but that <br> no traffic will be received from the net(s).<br><br> Example:<br><br> wifi eth1:192.168.3.0/24 broadcast<br> wifi eth1:224.0.0.0/4 destonly<br><br> In that example, limited broadcasts from the firewall with a source<br> IP in the 192.168.3.0/24 range will be acccepted as will multicasts<br> (with any source address).<br><br>2) A MULTICAST option has been added to shorewall.conf. This option<br> will normally be set to 'No' (the default). It should be set to <br> 'Yes' under the following circumstances:<br><br> a) You have an interface that has parallel zones defined via<br> /etc/shorewall/hosts.<br> b) You want to forward multicast packets to two or more of those<br> parallel zones.<br><br> In such cases, you will configure a 'destonly' network on each <br> zone receiving multicasts.<br><br> The MULTICAST option is only recognized by Shorewall-perl and is<br> ignored by Shorewall-shell.<br><br>3) As announced in the Shorewall 4.0.4 release notes, Shorewall-perl<br> no longer supports the 'detectnets' option. Specifying that option<br> now results in the following message:<br><br> WARNING: Support for the 'detectnets' option has been removed<br><br> It is suggested that 'detectnets' be replaced by<br> 'routefilter,logmartians'. That will produce the same filtering<br> effect as 'detectnets' while eliminating 1-2 rules per connection.<br><br> One user has asked how to retain the output of 'shorewall show<br> zones' if the 'detectnets' option is removed. While I don't advise<br> doing so, you can reproduce the current 'shorewall show' behavior<br> as follows.<br><br> Suppose that you have a zone named 'wifi' that produces the<br> following output with 'detectnets':<br><br> wifi (ipv4)<br> eth1:192.168.3.0/24<br><br> You can reproduce this behavior as follows:<br><br> /etc/shorewall/interfaces:<br><br> - eth1 detect ...<br><br> /etc/shorewall/hosts:<br><br> wifi eth1:192.168.3.0/24 broadcast<br><br> If you send multicast to the 'wifi' zone, you also need this entry<br> in your hosts file:<br><br> wifi eth1:224.0.0.0/4 destonly<br><br>4) (Shorewall-perl only) The server port in a DNAT or REDIRECT rule<br> may now be specified as a service name from<br> /etc/services. Additionally:<br><br> a) A port-range may be specified as the service port expressed in<br> the format <low port>-<high port>. Connections are assigned to<br> server ports in round-robin fashion.<br><br> b) The compiler only permits a server port to be specified if the<br> protocol is tcp or udp.<br><br> c) The compiler ensures that the server IP address is valid (note<br> that it is still not permitted t
<pre>Problems Corrected in Shorewall 3.4.7<br><br>1) A bug prevented proper handling of PREROUTING marks when<br> HIGH_ROUTE_MARKS=No and the track option was specified in<br> /etc/shorewall/providers.<br><br>2) Previously, if the following sequence of routing rules was<br> specified, then the first rule would always be omitted.<br><br> #SOURCE DEST PROVIDER PRIORITY<br> $SRC_A $DESTIP1 ISP1 1000<br> $SRC_A $DESTIP2 SOMEISP 1000<br> $SRC_A - ISP2 1000<br><br> The reason for this omission was that Shorewall uses a<br> delete-before-add approach and attempting to delete the third rule<br> resulted in the deletion of the first one instead. <br><br> This problem occurred with both compilers.<br><br>3) When using Shorewall-shell, provider numbers were not recognized in<br> the PROVIDER column of /etc/shorewall/route_rules.</pre>
<pre>Problems Corrected in Shorewall 4.0.4<br><br>1) If no interface had the 'blacklist' option, then when using<br> Shorewall-perl, the 'start' and 'restart' command failed:<br><br> ERROR: No filter chain found with name blacklst<br><br> New Shorewall-perl 4.0.3 packages were released that corrected this<br> problem; it is included here for completeness.<br><br>2) If no interface had the 'blacklist' option, then when using<br> Shorewall-perl, the generated script would issue this harmless<br> message during 'shorewall refresh':<br><br> chainlist_reload: Not found<br><br>3) If /bin/sh was a light-weight shell such as ash or dash, then<br> 'shorewall refresh' failed.<br><br>4) During start/restart, the script generated by Shorewall-perl was<br> clearing the proxy_arp flag on all interfaces; that is not the<br> documented behavior.<br><br>5) If the module-init-tools package was not installed and<br> /etc/shorewall/modules did not exist or was non-empty, then<br> Shorewall-perl would fail with the message:<br><br> ERROR: Can't run lsmod : /etc/shorewall/modules (line 0)<br><br>6) Shorewall-perl now makes a compile-time check to insure that<br> iptables-restore exists and is executable. This check is made when<br> the compiler is being run by root and the -e option is not<br> given.<br><br> Note that iptables-restore must reside in the same directory as the<br> iptables executable specified by IPTABLES in shorewall.conf or<br> located by the PATH in the event that IPTABLES is not specified.<br><br>7) When using Shorewall-perl, if an action was invoked with more than<br> 10 different combinations of log-levels/tags, some of those<br> invocations would have incorrect logging.<br><br>8) Previously, when 'shorewall restore' was executed, the<br> iptables-restore utility was always located using the PATH setting<br> rather than the IPTABLES setting.<br><br> With Shorewall-perl, the IPTABLES setting is now used to locate<br> this utility during 'restore' as it is during the processing of<br> other commands.<br><br>9) Although the shorewall.conf manpage indicates that the value<br> 'internal' is allowed for TC_ENABLED, that value was previously<br> rejected ('Internal' was accepted).<br><br>10) The meaning of the 'loose' provider option was accidentally reversed<br> in Shorewall-perl. Rather than causing certain routing rules to be<br> omitted when specified, it actually caused them to be added (these<br> rules were omitted when the option was NOT specified).<br><br>11) If the 'bridge' option was specified on an interface but there were<br> no bport zones, then traffic originating on the firewall was not<br> passed through the accounting chain.<br><br>12) In commands such as:<br><br> shorewall compile <directory><br> shorewall restart <directory><br> shorewall check <directory><br><br> if the name of the <directory> contained a period ("."), then<br> Shorewall-perl would incorrectly substitute the current working<br> directory for the name.<br><br>13) Previously, if the following sequence of routing rules was<br> specified, then the first rule would always be omitted.<br><br> #SOURCE DEST PROVIDER PRIORITY<br> $SRC_A $DESTIP1 ISP1 1000<br> $SRC_A $DESTIP2 SOMEISP 1000<br> $SRC_A - ISP2 1000<br><br> The reason for this omission was that Shorewall uses a<br> delete-before-add approach and attempting to delete the third rule<br> resulted in the deletion of the first one instead. <br><br> This problem occurred with both compilers.<br><br>14) When using Shorewall-shell, provider numbers were not recognized in<br> the PROVIDER column of /etc/shorewall/route_rules.<br><br>15) An off-by-one problem in Shorewall-perl caused the value 255 to be<br> rejected in the MARK column of /etc/shorewall/tcclasses.<br><br>16) When HIGH_ROUTE_MARKS=Yes, marks with values > 255 must be a<br> mu
<pre>Problems Corrected in 4.0.3<br><br>1) Using the LOG target in the rules file could result in two LOG<br> rules being generated by Shorewall-shell. Additionally, using an IP<br> address range in a rule that performed logging could result in an<br> invalid iptables command.<br><br>2) Shorewall now loads the act_police kernel module needed by traffic<br> shaping.<br><br>3) Previously, "shorewall show -f capabilities" and "shorecap" omitted<br> the "TCPMSS Match" capability. This made it appear to a compiler<br> using a capabilities file that the TCPMSS Match capability was not<br> available.<br><br>4) Previously, Shorewall would truncate long log prefixes to 29<br> characters. This resulted in there being no space between the log<br> prefix and the IN= part of the message.<br><br> Example: fw2net:LOG:HTTPSoutIN= OUT=eth0<br><br> Beginning with this release, Shorewall will truncate the prefix to<br> 28 bytes and add a trailing space.<br><br> Example: fw2net:LOG:HTTPSou IN= OUT=eth0<br><br>5) Previously, if:<br><br> - FASTACCEPT=No<br> - The policy from Z1 to Z2 was CONTINUE<br> - Neither Z1 nor Z2 had parent zones<br> - There were no Z1->Z2 rules<br><br> then connections from Z2->Z1 would fail even if there were<br> rules/policies allowing them. This has been<br> corrected.<br><br>6) The 'shorewall add' and 'shorewall delete' command would fail when:<br><br> - The running configuration was compiled with Shorewall-perl.<br> - The name of the interface specified in the command contained an<br> embedded special character such as '.' or '-'.<br><br> This problem was the result of the change in Shorewall 4.0.2 that<br> removed the legacy mapping of interface names when embedding such<br> names in a Netfilter chain name. To correct the problem, the<br> pre-4.0.2 name mapping is restored when DYNAMIC_ZONES=Yes.<br><br>5) A bug in Shorewall-shell prevented proper handling of PREROUTING<br> marks when HIGH_ROUTE_MARKS=No and the track option was specified<br> in /etc/shorewall/providers.<br><br>6) With Shorewall-perl, if EXPORTPARAMS=Yes then INCLUDE directives in<br> the params file would fail at script execution time with "INCLUDE:<br> not found". This has been corrected.<br><br>7) Shorewall-perl was mis-sorting the zone list when zones were nested<br> more than one deep.<br><br>8) Stale references to http://www.shorewall.net/Documentation.htm have<br> been removed from the config files (including samples). That URL<br> has been replaced by the online manpages.<br><br>Other Changes in 4.0.3<br><br>1) A script generated by Shorewall-perl now tries to modify/restore<br> /etc/iproute2/rt_tables only if the file is writable. This prevents<br> run-time errors when /etc is mounted read-only.<br><br> A new KEEP_RT_TABLES option has been added to shorewall.conf. When<br> set to Yes, this option prevents Shorewall from altering the<br> /etc/iproute2/rt_tables database. The KEEP_RT_TABLES option is only<br> recognized by Shorewall-perl and is ignored by Shorewall-shell.<br><br>2) Shorewall-perl now requires the FindBin Perl module.<br><br>3) When an optional provider is not available, a script generated by<br> Shorewall-perl will no longer add the corresponding<br> routing rules.<br><br>4) A new 'isusable' extension script has been added. This script<br> allows you to extend the availability test that Shorewall performs<br> on optional providers.<br><br> Here's an example that uses ping to ensure that the default<br> gateways through eth0 and eth1 are reachable:<br><br> case $1 in<br> eth0)<br> ping -c 4 -I eth0 206.124.146.254 > /dev/null 2>&1<br> return<br> ;;<br> eth1)<br> ping -c 4 -I eth1 192.168.12.254 > /dev/null 2>&1<br> return<br> ;;<br> *)<br> # Assume we don't need to do any additional testing<br> # for this interface beyond Shorewall's<br>
<pre>Problems Corrected in 3.4.6.<br><br>1) If the "Mangle FORWARD Chain" capability was supported, entries in<br> the /etc/shorewall/ecn file would cause invalid iptables<br> commands to be generated.<br><br>2) Certain errors occurring during<br> start/restart/safe-start/safe-restart/try processing could cause<br> the lockfile to be left behind. This resulted in a 60-second delay<br> the next time one of these commands was run.<br><br>3) It was not previously possible to define traffic shaping on a<br> bridge port; the generated script complained that the<br> interface was not up and configured.<br><br>4) Previously, using a port list in the DEST PORT(S) column of the<br> rules file or in an action file caused an invalid iptables command<br> to be generated.<br><br>5) Using the LOG target in the rules file could result in two LOG<br> rules being generated. Additionally, using an IP address range in a<br> rule that performed logging could result in an invalid iptables<br> command.<br><br>6) Shorewall now loads the act_police kernel module needed by traffic<br> shaping.<br><br>7) Previously, "shorewall show -f capabilities" and "shorecap" omitted<br> the "TCPMSS Match" capability. This made it appear to a compiler<br> using a capabilities file that the TCPMSS Match capability was not<br> available.<br><br>8) Previously, Shorewall would truncate long log prefixes to 29<br> characters. This resulted in there being no space between the log<br> prefix and the IN= part of the message.<br><br> Example: fw2net:LOG:HTTPSoutIN= OUT=eth0<br><br> Beginning with this release, Shorewall will truncate the prefix to<br> 28 bytes and add a trailing space.<br><br> Example: fw2net:LOG:HTTPSou IN= OUT=eth0<br><br>9) Previously, if:<br><br> - FASTACCEPT=No<br> - The policy from Z1 to Z2 was CONTINUE<br> - Z1 and Z2 were orphans (neither had parent zones)<br> - There were no Z1->Z2 rules<br><br> then connections from Z2->Z1 would fail even if there were<br> rules/policies allowing them. This has been<br> corrected. <br><br>Other changes in 3.4.6.<br><br>1) Processing of the message log in the 'show log', 'logwatch' and<br> 'dump' commands has been speeded up thanks to a suggestion by<br> Andrew Suffield.</pre>
<pre>Problems corrected in 4.0.2<br><br>1) The Shorewall-perl compiler was still generating invalid<br> iptables-restore input from entries in /etc/shorewall/ecn.<br><br>2) When using Shorewall-perl, unless an interface was specified as<br> 'optional' in the interfaces file, the 'restore' command would<br> fail if the routes through the interface or the addresses on the<br> interface could not be detected.<br><br> Route detection occurs when the interface is named in the SOURCE<br> column of the masq file. Address detection occurs when<br> DETECT_DNAT_IPADDRS=Yes and the interface is the SOURCE for a DNAT<br> or REDIRECT rule or when 'maclist' is specified for the interface.<br><br> Since the 'restore' command doesn't use the detected information,<br> detection is now skipped if the command is 'restore'.<br><br>3) It was not previously possible to define traffic shaping on a<br> bridge port; the generated script complained that the<br> interface was not up and configured.<br><br>4) When Shorewall-shell was not installed, certain options in<br> /etc/shorewall/interfaces and /etc/shorewall/hosts would cause the<br> 'add' and 'delete' commands to fail with a missing library error.<br><br> OPTION FILE<br> maclist interfaces,hosts<br> proxyarp interfaces<br><br>5) The /var/lib/shorewall/zones file was being overwritten during<br> processing of the 'refresh' command by a script generated with<br> Shorewall-perl. The result was that hosts previously added to<br> dynamic zones could not be deleted after the 'refresh'.<br><br>6) If the file named as the output file in a Shorewall-perl 'compile'<br> command was a symbolic link, the generated error message<br> erroneously stated that the file's parent directory was a symbolic<br> link.<br><br> As part of this change, cosmetic changes were made to a number of<br> other error messages.<br><br>7) Some intra-zone rules were missing when a zone involved multiple<br> interfaces or when a zone included both IPSEC and non-IPSEC<br> networks.<br><br>8) Shorewall was not previously loading the xt_multiport kernel<br> module.<br><br>9) The Russian and French translations no longer have English headings<br> on notes, cautions, etc..<br><br>10) Previously, using a port list in the DEST PORT(S) column of the<br> rules file or in an action file could cause an invalid iptables<br> command to be generated by Shorewall-shell.<br><br>11) If there were no bridges in a configuration, Shorewall-perl would<br> ignore the CHAIN column in /etc/shorewall/accounting.<br><br>Other changes in 4.0.2<br><br>1) Shorewall-perl now detects when a port range is included in a list<br> of ports and iptables/kernel support for Extended Multi-port Match<br> is not available. This avoids an iptables-restore failure at<br> run-time.<br><br>2) Most chains created by Shorewall-shell have names that can be<br> embedded within shell variable names. This is a workaround for<br> limitations in the shell programming language which has no<br> equivalent to Perl hashes. Often chain names must have the name of<br> a network interface encoded in them. Given that interface names can<br> contain characters that are invalid in a shell variable name,<br> Shorewall-shell performs a name mapping which was carried forward to<br> Shorewall-perl:<br><br> - Trailing '+' is dropped.<br> - The characters ".", "-", "%' and "@" are translated to "_".<br><br> This mapping has been elminated in the 4.0.2 release of Shorewall-<br> perl. So where before you would see chain "eth0_0_in", you may now<br> see the same chain named "eth0.0_in". Similarly, a chain previously<br> named "ppp_fwd" may now be called "ppp+_fwd".<br><br>3) Shorewall-perl now uses the contents of the BROADCAST column in<br> /etc/shorewall/interfaces when the Address Type match capability is<br> not available.</pre>
<pre>Problems corrected in 4.0.1.<br><br>1) The Shorewall Lite installer was producing an empty shorewall-lite<br> manpage. Since the installer runs as part of creating the RPM, the<br> RPM also suffered from this problem. The 4.0.0 Shorewall-lite <br> packages were re-uploaded with this problem corrected.<br><br>2) The Shorewall Lite uninstaller incorrectly removed /sbin/shorewall<br> rather than /sbin/shorewall-lite.<br><br>3) Both the Shorewall and Shorewall Lite uninstallers did a "shorewall<br> clear" if Shorewall [Lite] was running. Now, the Shorewall Lite<br> uninstaller correctly does "shorewall-lite clear" and both<br> uninstallers only perform the 'clear' operation if the other<br> product is not installed. This prevents the removal of one of the<br> two products from clearing the firewall configuration established<br> by the other one.<br><br>4) The 'ipsec' OPTION in /etc/shorewall/hosts was mis-handled by<br> Shorewall-perl. If the zone type was changed to 'ipsec' or<br> 'ipsec4' and the 'ipsec' option removed from the hosts file entry,<br> the configuration worked properly.<br><br>5) If a CLASSID was specified in a tcrule and TC_ENABLED=No, then<br> Shorewall-perl produced the following:<br><br> Compiling...<br> Use of uninitialized value in string ne at /usr/share/shorewall-perl/Shorewall/Tc.pm line 285, <$currentfile> line 18.<br> ERROR: Class Id n:m is not associated with device eth0 : /etc/shorewall/tcrules (line 18)<br><br>6) If IPTABLES was not specified in shorewall.conf, Shorewall-perl was<br> locating the binary using the PATH environmental variable rather<br> than the PATH setting in shorewall.conf. If no PATH was available<br> when Shorewall-perl was run and IPTABLES was not set in<br> shorewall.conf, the following messages were issued:<br><br> Use of uninitialized value in split at /usr/share/shorewall-perl/Shorewall/Config.pm line 1054.<br> ERROR: Can't find iptables executable<br> ERROR: Shorewall restart failed<br><br>7) If the "Mangle FORWARD Chain" capability was supported, entries in<br> the /etc/shorewall/ecn file would cause invalid iptables commands<br> to be generated. This problem occurred with both compilers.<br><br>8) Shorewall now starts at reboot after an upgrade from shorewall <<br> 4.0.0. Previously, Shorewall was not started automatically at<br> reboot after an upgrade using the RPMs.<br><br>9) Shorewall-perl was generating invalid iptables-restore input when a<br> log level was specified with the dropBcast and allowBcast builtin<br> actions and when a log level followed by '!' was used with any<br> builtin actions.<br><br>10) Shorewall-perl was incorrectly rejecting 'min' as a valid unit of<br> time in rate-limiting specifications.<br><br>11) Certain errors occurring during<br> start/restart/safe-start/safe-restart/try processing could cause<br> the lockfile to be left behind. This resulted in a 60-second delay<br> the next time one of these commands was run.<br><br>Other changes in Shorewall 4.0.1.<br><br>1) A new EXPAND_POLICIES option is added to shorewall.conf. The<br> option is recognized by Shorewall-perl and is ignored by<br> Shorewall-shell.<br><br> Normally, when the SOURCE or DEST columns in shorewall-policy(5)<br> contains 'all', a single policy chain is created and the policy is<br> enforced in that chain. For example, if the policy entry is<br><br> #SOURCE DEST POLICY LOG<br> # LEVEL<br> net all DROP info<br><br> then the chain name is 'net2all' which is also the chain named in<br> Shorewall log messages generated as a result of the policy. If<br> EXPAND_POLICIES=Yes, then Shorewall-perl will create a separate<br> chain for each pair of zones covered by the policy. This makes the<br> resulting log messages easier to interpret since the chain in the<br> messages will have a name of the form 'a2b' where 'a' is the SOURCE<br> zone and 'b' i
<pre>----------------------------------------------------------------------------<br> R E L E A S E H I G H L I G H T S<br>----------------------------------------------------------------------------<br>1) This is the first Shorewall release that fully integrates the new<br> Shorewall-perl compiler. See the "New Features" section below.<br><br>2) You are now offered a choice as to which compiler(s) you install. In<br> 4.0.0, there are the following packages:<br><br> - Shorewall-common ( common files )<br> - Shorewall-shell ( the shell-based compiler )<br> - Shorewall-perl (the Perl-based compiler )<br><br> You must install at least one of the compiler packages (you may<br> install them both) along with Shorewall-common.<br><br> YOU DO NOT NEED TO UNINSTALL ANY OF YOUR CURRENT PACKAGES.<br><br> See the Migration Considerations below for further information.<br><br>3) The facilities for supporting bridge/firewalls under earlier<br> releases are deprecated and their documentation is omitted from the<br> 4.0 distribution. New bridge support is implemented in the<br> Shorewall-perl compiler. This support utilizes the reduced-function<br> physdev match support available in Linux kernel 2.6.20 and later.<br><br>Problems corrected in 4.0.0 Final.<br><br>1) The shorewall-lite install.sh may now be run multiple times from<br> the same directory. Previously, the manpages were gzipped in-place<br> which made it impossible to rerun the script.<br><br>2) If shorewall.conf contained SHOREWALL_COMPILER=shell (which it can<br> on Shorewall 3.4.2-4 systems) and the shorewall-shell RPM was<br> removed, subsequent "shorewall [re]start" operations failed. When<br> shorewall-shell is removed, the shorewall.conf file is modified to<br> specify SHOREWALL_COMPILER= and the original is saved in<br> shorewall.conf.rpmsave.<br><br>3) The contents of the LOG LEVEL column in /etc/shorewall/policy are<br> now validated at compile time by Shorewall-perl.<br><br>Other changes in Shorewall 4.0.0 Final.<br><br>1) The Perl modules in /usr/share/shorewall-perl/Shorewall/ have been<br> consolidated somewhat, leading to slightly faster compilation.<br><br>Migration Considerations:<br><br>1) Beginning with Shorewall 4.0.0, there is no single 'shorewall'<br> package. Rather there are two compiler packages (shorewall-shell<br> and shorewall-perl) and a set of base files (shorewall-common)<br> which are required by either compiler package.<br><br> Although the names of the packages are changing, you can upgrade<br> without having to uninstall/reinstall.<br><br> To repeat: YOU DO NOT NEED TO UNINSTALL ANY EXISTING PACKAGE.<br><br> If you attempt to upgrade using the shorewall-common RPM, you get<br> this result:<br> gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm <br> error: Failed dependencies:<br> shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch<br> gateway:~ #<br><br> You must either:<br><br> rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \<br> shorewall-common-4.0.0.noarch.rpm<br><br> or<br><br> rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \<br> shorewall-perl-4.0.0.noarch.rpm \<br> shorewall-common-4.0.0.noarch.rpm<br><br> If you don't want to use shorewall-perl exclusively then use the<br> second command above then<br><br> rpm -e shorewall-shell<br><br> If you are upgrading using the tarball, you must install <br> shorewall-shell and/or shorewall-perl before you upgrade<br> using shorewall-common. Otherwise, the install.sh script fails with:<br><br> ERROR: No Shorewall compiler is installed<br><br> The shorewall-shell and shorewall-perl packages are installed from<br> the tarball in the expected way; untar the package, and run the<br> install.sh script.<br><br> Example 1: You have 'shorewall' installed and you want to continue<br> to use the shorewall-shell compiler.<br><br> tar -jxf shorewall-common-4.0.0.tar.bz2<br>
<pre>Problems Corrected in 3.4.5.<br><br>1) DYNAMIC_ZONES=Yes can now coexist with Shorewall-perl's 'bport'<br> zones. Those zones themselves may not be dynamically modified but<br> the presence of bport zones no longer causes the 'shorewall add'<br> command to fail.<br><br>2) Shorewall's internal traffic shaper once again works when the 'sed'<br> utility is provided by the Busybox package.<br><br>3) Version 3.4.4 erroneously accepted the values On, Off, on, off, ON<br> and OFF for the IP_FORWARDING option. These values were treated<br> like 'Keep'. The listed values are now once again flagged as an<br> error.<br><br>4) If 'routeback' and 'detectnets' were specified on an interface,<br> limited broadcasts (to 255.255.255.255) and multicasts were dropped<br> when forwarded through the interface. This could cause<br> broadcast-based and multicast applications to fail when running<br> through a bridge with 'detectnets'.<br><br>5) The 'hits' command works once again.<br><br>6) IPSECFILE=ipsec (either explicitly or defaulted) works<br> now. Previously, processing of the ipsec file was bypassed; often<br> with a confusing "missing file" message.<br><br>7) If DETECT_DNAT_IPADDRS=Yes in shorewall.conf but you did't have conntrack<br> match support, then the generated script was missing 'done's.<br><br>Other changes in 3.4.5.<br><br>1) When a Shorewall release includes detection of an additional<br> capability, existing capabilities files become out of<br> date. Previously, this condition was not detected.<br><br> Beginning with this release, each generated capabilities file<br> contains a CAPVERSION specification which defines the capabilities<br> version of the file. If the CAPVERSION in a capabilities file is<br> less than the current CAPVERSION, then Shorewall will issue the<br> following message:<br><br> WARNING: <file> is out of date -- it does not contain all of<br> the capabilities defined by Shorewall version <version><br><br> where<br><br><file> is the name of the capabilities file.<br><version> is the current Shorewall version.<br><br> Existing capabilities files contain no CAPVERSION. When such a file<br> is read, Shorewall will issue this message:<br><br> WARNING: <file> may be not contain all of the capabilities defined<br> by Shorewall version <version><br><br>2) When a directory is specified in a command such as 'start' or<br> 'compile', Shorewall now reads the shorewall.conf file (if any) in<br> that directory before deciding which compiler to use. So if<br> SHOREWALL_COMPILER is not specified in<br> /etc/shorewall/shorewall.conf and the -C option was not specified<br> on the run-line, then if Shorewall-perl is installed, the additional<br> shorewall.conf file is read to see if it specifies a<br> SHOREWALL_COMPILER.<br><br>3) The 'save' command now uses iptables-save from the same directory<br> containing iptables. Previously, iptables-save was located via the<br> PATH setting.</pre>
<pre>Problems corrected in 3.4.4:<br><br>1) The commands "shorewall add <interface><zone>" and "shorewall<br> delete <interface><zone>" no longer produce spurious error<br> messages.<br><br>2) The command "shorewall delete <interface><zone>" now actually deletes<br> entries when it successfully completes. Previously, it would appear<br> to remove an entry, even when removing that entry should fail. <br><br>3) Setting HIGH_ROUTE_MARKS=No no longer causes TC_EXPERT flagging.<br><br>4) When run as root, the 'shorewall load' and 'shorewall reload'<br> commands would fail if the LOGFILE setting in<br> /etc/shorewall/shorewall.conf specified a non-existant file.<br><br>5) Entries in /etc/shorewall/tcrules that specify both a source and<br> destination port fail with the following diagnostic:<br><br> iptables v1.3.3: multiport can only have one option<br><br>6) Previously, Shorewall-lite did not allow DHCP traffic through an<br> interface when the interface was a bridge with 'dhcp' specified<br> unless there was a bridge on the administrative system with the<br> same name.<br><br>7) SOURCE and DEST are now flagged as invalid zone name to avoid<br> problems with macros that use those names as keywords.<br><br>8) Previously, Shorewall could *increase* the MSS under some<br> circumstances. This possibility is now eliminated, provided that<br> the system has TCPMSS match support (be sure to update your<br> capabilities files!).<br><br>9) Firewall zone names other than 'fw' no longer cause a error when<br> IPSECFILE is not set or is set to 'ipsec'.<br><br>10) The 'proxyarp' option on an interface was previously ignored when<br> the /etc/shorewall/proxyarp file was empty.<br><br>11) Previously, if action 'a' was defined then the following <br> rule generated an error:<br><br> a: z1 z2 ...<br><br> The trailing ":" is now ignored.<br><br>12) Previously, if a RATE/LIMIT was specified on a REJECT rule, the<br> generated error messages referred to the rule as a DROP rule.<br><br>13) The 'nolock' keyword was previously ignored on several<br> /sbin/shorewall[-lite] commands. <br><br>Other changes in 3.4.4:<br><br>1) The accounting, masq, rules and tos files now have a 'MARK' column<br> similar to the column of the same name in the tcrules file. This<br> column allows filtering by MARK value.<br><br>2) The "shorewall show zones" command now flags zone members that have<br> been added using "shorewall add" by preceding them with a plus sign<br> ("+").<br><br> Example:<br><br> Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007<br><br> fw (firewall)<br> net (ipv4)<br> eth0:0.0.0.0/0<br> loc (ipv4)<br> br0:0.0.0.0/0<br> eth4:0.0.0.0/0<br> eth5:0.0.0.0/0<br> +eth1:0.0.0.0/0<br> dmz (ipv4)<br> eth3:0.0.0.0/0<br> vpn (ipv4)<br> tun+:0.0.0.0/0<br><br> In the above output, "eth1:0.0.0.0/0" was dynamically added to the<br> 'loc' zone. As part of this change, "shorewall delete" will only<br> delete entries that have been added dynamically. In earlier<br> versions, any entry could be deleted although the ruleset was only<br> changed by deleting entries that had been added dynamically.<br><br>3) Eariler generations of Shorewall Lite required that remote root<br> login via ssh be enabled in order to use the 'load' and 'reload'<br> commands.<br><br> Beginning with this release, you may define an alternative means<br> for accessing the remote firewall system.<br><br> Two new options have been added to shorewall.conf:<br><br> RSH_COMMAND<br> RCP_COMMAND<br><br> The default values for these are as follows:<br><br> RSH_COMMAND: ssh ${root}@${system} ${command}<br> RCP_COMMAND: scp ${files} ${root}@${system}:${destination}<br><br> Shell variables that will be set when the commands are envoked are<br> as follows:<br><br> root - root user. Normally 'root' but ma
<p><strong>2007-06-12 New Host for www.shorewall.net and
ftp.shorewall.net</strong></p>
<pre>I'm pleased to announce that Ty Christiansen and the folks at Master Mind<br>Productions (http://mastermindpro.com) have volunteered to host<br>www.shorewall.net and ftp.shorewall.net.<br><br>The new site is up and running and I've just changed DNS to point to the new<br>server. Let me know if you experience any problems.<br><br>Please join me in thanking Ty and Master Mind for their support of the<br>Shorewall project.</pre>
<pre>Problems Corrected in 3.2.10<br><br>1) Previously, if a 'start' or 'restart' command failed during the<br> compilation step, /sbin/shorewall erroneously returned an exit<br> status of zero.<br><br>2) If IMPLICIT_CONTINUE=Yes was in effect, then sub-zones received the<br> implicit CONTINUE policy for their intra-zone traffic (rather than<br> the implicit ACCEPT policy for such traffic). This could cause<br> intra-zone traffic to be rejected by rules in one of the parent<br> zones.<br><br>3) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. With this<br> change, shorewall will only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>4) The /usr/share/shorewall[-lite]/modules file has been updated for<br> kernel 2.6.20.<br><br>5) The /proc/net/ip_conntrack pseudo-file has been inexplicably<br> renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli<br> library has been updated to look for both files.<br><br>6) Tunnels of type 'ipsecnat' failed to work properly due to a missing<br> rule.<br><br>7) The 'shorecap' program was not loading modules correctly. <br><span
<pre>Problems corrected in Shorewall 3.4.2<br><br>1) The /usr/share/shorewall[-lite]/modules file has been updated for<br> kernel 2.6.20.<br><br>2) The /proc/net/ip_conntrack pseudo-file has been inexplicably<br> renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli<br> library has been updated to look for both files.<br><br>3) Shoreall 3.4 was not consistent with respect to its treatment of<br> log level 'none' and 'none!' and built-in actions. In particular,<br> specifying 'none' with the Limit action produced a run-time error.<br> Shorewall now correctly suppresses generation of log messages when<br> a log level of 'none' or 'none!' is given to a built-in action.<br><br>4) Tunnels of type 'ipsecnat' would sometimes fail to work because of<br> a missing rule.<br></pre>
<pre>Problems Corrected in 3.4.1<br><br>1) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. There was a<br> partial fix included in 3.4.0; unfortunately, it did not correct the<br> problem completely. Shorewall 3.4.1 includes the rest of the change <br> necessarey to only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>2) If the log-prefix in a log message exceeded 29 characters, <br> 'shorewall restart' fails with 'truncate: command not found' and a<br> possible segmentation fault in iptables.<br><br>3) Log messages specifying a log tag had two spaces appended to the<br> log prefix. This could cause mysterious "log-prefix truncated"<br> messages. <br><br>4) When nested zones were defined in the /etc/shorewall/zones file and<br> IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,<br> shell error messages ( usually '<zone>: not found' ) during<br> compilation resulted.<br><br>5) Use of CONTINUE policies lead to startup errors with a message<br> such as the following:<br><br> Applying Policies...<br> iptables v1.3.7: Couldn't load target<br> `CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open<br> shared object file: No such file or directory<br><br> Try `iptables -h' or 'iptables --help' for more information.<br><br> ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"<br> Failed<br><br>6) If there were hosts defined as 'critical' in<br> /etc/shorewall/routestopped then problems occured in two cases:<br><br> i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall<br> clear' was issued.<br><br> ii) On Shorewall or Shorewall lite system when 'start' or 'restart'<br> failed during execution of the compiled script and there was no saved<br> configuration ('shorewall[-lite] save' has not been issued).<br><br> The symptoms were that the following shell messages were issued and<br> the 'critical' hosts were not enabled:<br><br> /var/lib/shorewall/.start: line nnn: source_ip_range: command not found<br> /var/lib/shorewall/.start: line nnm: dest_ip_range: command not found<br><br>Other changes in 3.4.1<br><br>1) Several changes are included which allow testing of experimental<br> versions of Shorewall on systems with 3.4.1 and later 3.4 releases<br> installed. Among these changes is the detection and reporting of<br> "Address Type Match" which may be used in future 3.4 releases.<br> These changes have no effect on normal Shorewall operation. </pre>
<pre>Shorewall 3.4.0<br><br>Release Highlights<br><br>1) Shorewall can now be tailored to reduce its footprint on embedded<br> systems. As part of this change, actions are now completely<br> optional.<br><br> See http://www.shorewall.net/Modularization.html for details.<br><br>2) Exclusion is now possible in /etc/shorewall/hosts. This is required<br> for bridge/firewalls under kernel 2.6.20 and later.<br><br> See http://www.shorewall.net/NewBridge.html.<br><br>3) Shorewall and Shorewall Lite now include man pages. There is a <br> man page for shorewall(8), one for shorewall-lite(8) and one for<br> each configuration file. As part of this change, all documentation<br> has been removed from Shorewall configuration files. This should<br> make it easier from users to upgrade from one release to the next<br> since the configuration files will only change when column is added<br> or renamed.<br><br> See http://www.shorewall.net/manpages/Manpages.html<br><br>4) Shorewall now remembers the changes that it has made to routing as<br> a result of entries in /etc/shorewall/providers and<br> /etc/shorewall/route_rules and reverses those changes when<br> appropriate.<br><br>Problems Corrected in 3.4.0 Final.<br><br>1) In the rules file, following the action with "!" is supposed to<br> exempt the rule from being suppressed by OPTIMIZE=1. That feature<br> was not working.<br><br>2) If both a macro body and a macro invocation contained an entry in the<br> SOURCE or DEST column, then compilation failed with the error:<br><br> merge_macro_source_dest: command not found<br><br>3) An obscure bug in rule activation having to do with the new<br> exclusion feature in /etc/shorewall/hosts has been corrected.<br><br>4) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. With this<br> change, shorewall will only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>New Features in Shorewall 3.4:<br><br>1) In order to accomodate small embedded applications, Shorewall 3.4<br> is now modularized. In addition to the base files, there are<br> loadable "libraries" that may be included or omitted from an<br> embedded system as required.<br><br> Loadable Shorewall libraries reside in /usr/share/shorewall/ and<br> have names that begin with "lib.". The following libraries are<br> included in Shorewall 3.4:<br><br> - lib.accounting. Must be available if you include entries in<br> /etc/shorewall/accounting.<br><br> - lib.actions. Must be available if you do not specify<br> USE_ACTIONS=No in /etc/shorewall/shorewall.conf.<br><br> - lib.base. The base Shorewall library required by all programs,<br> including compiled firewall scripts. This library is also<br> released as part of Shorewall Lite and is installed in<br> /usr/share/shorewall-lite/.<br><br> - lib.cli. Library containing the code common to /sbin/shorewall,<br> /sbin/shorewall-lite. This library is also released as part of<br> Shorewall Lite and is installed in /usr/share/shorewall-lite/.<br><br> - lib.config. Library containing the code that is common to<br> /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. <br><br> - lib.dynamiczones. Must be available if you specify<br> DYNAMIC_ZONES=Yes in shorewall.conf.<br><br> - lib.maclist. Must be available if you specify the 'maclist'<br> option in /etc/shorewall/interfaces or /etc/shorewall/hosts.<br><br> - lib.nat. Must be available if you have entries in<br> /etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap<br> or if you use DNAT or REDIRECT rules.<br><br> - lib.providers. Must be available if you have entries in<br> /etc/shorewall/providers.<br><br> - lib.proxyarp. Must be available if you have entries in<br> /etc/
