<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.<
