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