<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[:<address>] in which case the rule is processed out of the<br> OUTPUT chain.<br></pre>
<pre>Shorewall Problems corrected in 3.2.4<br><br>1) Previously, the directory name in the command "shorewall start<br><directory name>" 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>
<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é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 [ <directory1> ] [user@]<system>:[<directory2>]<br><br> If <directory1> is omitted, then the current working directory is<br> assumed.<br><br> Causes the shorewall configuration in <directory1> to be compiled<br> into a program called '<directory1>/firewall'. If compilation is<br> successful, the '<directory1>/firewall' script is copied via scp<br> to the specified <system>.<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 doin
<prewrap="">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> !<MAC address>. 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>
<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>
<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>
<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=<doesn't matter></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 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 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>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 ] [ <config directory> ] <script file><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><config directory> 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><script file> 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
<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> !<MAC address>. 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>
<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> !<MAC address>. Previously, a startup error occurred.<br></pre>
<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>
<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>
<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<->gw traffic was encrypted<br> b) The gw<->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<value>[/0x<mask>] (mask defaults to 0xff)<br> - this lets you define a classifier<br> for the given <value>/<mask> 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-<tosname> - 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 <=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-<tosname>' have changed slightly. Previously,<br> these were tested using a mask of 0xff (example: tos-minimize-delay was<br>
<pre>Problems Corrected in 3.0.4<br><br>1) The shorewall.conf file is once again "console friendly". Patch is<br> courtesy of Tuomo Soini.<br><br>2) A potential security hole has been closed. Previously, Shorewall ACCEPTed<br> all traffic from a bridge port that was sent back out on the same port. If<br> the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,<br> xenbr0:vif+), this could lead to traffic being passed in variance with the<br> supplied policies and rules.<br><br>3) Previously, an intra-zone policy of NONE would cause a startup error. That<br> problem has been corrected.<br><br>4) When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not<br> add the retained aliases. This means that the following sequence of<br> events resulted in missing aliases:<br><br> shorewall start<br> shorewall restart<br> shorewall save<br> reboot<br> shorewall -f start (which is the default during boot up)<br><br>5) When a 2.x standard action is invoked with a log level (example<br> "AllowPing:info"), logging does not occur.<br><br>New Features in 3.0.4<br><br>1) By popular demand, the 'Limit' action described at<br> http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard<br> action. Limit requires 'recent match' support in your kernel and iptables.<br><br>2) DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This<br> change is reported to improve Java startup time on some distributions.<br><br>3) Shorewall now contains support for wildcard ports. In<br> /etc/shorewall/hosts, you may specify the port name with trailing "+" then <br> use specific port names in rules.<br><br> Example:<br><br> /etc/shorewall/hosts<br><br> vpn br0:tap+<br><br> /etc/shorewall/rules<br><br> DROP vpn:tap0 vpn:tap1 udp 9999<br><br>4) For the benefit of those who run Shorewall on distributions that don't <br> autoload kernel modules, /etc/shorewall/modules now contains load commands <br> for a wide range of Netfilter modules.<br></pre>
<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>
<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>
<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.<
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>
