Shorewall 3.2.0 RC 5 Note to users upgrading from Shorewall 2.x or 3.0 Most problems associated with upgrades come from two causes: - The user didn't read and follow the migration considerations in these release notes. - The user mis-handled the /etc/shorewall/shorewall.conf file during upgrade. Shorewall is designed to allow the default behavior of the product to evolve over time. To make this possible, the design assumes that you will not replace your current shorewall.conf file during upgrades. If you feel absolutely compelled to have the latest comments and options in your shorewall.conf then you must proceed carefully. While you are at it, if you have a file named /etc/shorewall/rfc1918 then please check that file. If it has addresses listed that are NOT in one of these three ranges, then please rename the file to /etc/shorewall/rfc1918.old. 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 If you have a file named /etc/shorewall/modules, please remove it. The default modules file is now located in /usr/share/shorewall/ (see the "Migration Considerations" below). Please see the "Migration Considerations" below for additional upgrade information. Problems Corrected in 3.2.0 RC 5 1) DOA /sbin/shorewall: wifitipper:/etc/test # shorewall restart Compiling... ERROR: LITEDIR not defined in /usr/share/shorewall/configpath wifitipper: 2) The compiler was running iptables needlessly when DELAYBLACKLISTLOAD=Yes. This could also result in the blacklist not being loaded in some cases. 3) Some versions of 'ash' generate an error message when a log level is included in a rule. Other changes in 3.2.0 RC 5 None. Migration Considerations: 1) If you are upgrading from Shorewall 2.x, it is essential that you read the Shorewall 3.0.7 (or later) release notes: http://www.shorewall.net/pub/shorewall/3.0/shorewall-3.0.7/releasenotes.txt 2) A number of macros have been split into two. The macros affected are: IMAP LDAP NNTP POP3 SMTP Each of these macros now handles only traffic on the native (plaintext) port. There is a corresponding macro with S added to the end of the name for the SSL version of the same protocol. Thus each macro results in the insertion of only one port per invocation. The Web macro has not been split, but two new macros, HTTP and HTTPS have been created. The Web macro is deprecated in favour of these new macros, and may be removed from future Shorewall releases. These changes have been made to ensure no unexpected ports are opened due to the use of macros. 3) In previous Shorewall releases, DNAT and REDIRECT rules supported a special syntax for exclusion of a sub-zone from the effect of the rule. Example: Z2 is a subzone of Z1: DNAT Z1!Z2 loc:192.168.1.4 ... That feature has never worked correctly when Z2 is a dynamic zone. Furthermore, now that Shorewall supports exclusion lists, the capability is redundant since the above rule can now be written in the form: DNAT Z1:! loc:192.168.1.4 ... Beginning with Shorewall 3.2.0, the special exclusion syntax will no longer be supported. 4) Important if you use the QUEUE target. In the /etc/shorewall/rules file and in actions, you may now specify 'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also requires that the SYN flag is set and the RST, FIN and ACK flags be off ("--syn" is added to the iptables rule). As part of this change, Shorewall no longer adds the "--syn" option to TCP rules that specify QUEUE as their target. 5) Extension Scripts may require change In previous releases, extension scripts were executed during [re]start by using the Bourne Shell "." operator. In addition to executing commands during [re]start, these scripts had to "save" the commands to be executed during "shorewall restore". This clumsiness has been eliminated in Shorewall 3.2. In Shorewall 3.2, extension scripts are copied in-line into the compiled program and are executed in-line during "start", "restart" and "restore". This new approach has two implications for existing scripts. a) It is no longer necessary to save the commands; so functions like 'save_command', 'run_and_save_command' and 'ensure_and_save_command' need no longer be called. For convenience, the generated program will supply functions with these names: save_command() - does nothing run_and_save_command() - runs the passed command ensure_and_save_command() - runs the passed command and stops/restores the firewall if the command fails. These functions should provide for transparent migration of scripts that use them until you can get around to eliminating their use completely. b) When the extension script is copied into the compiled program, it is indented to line up with the surrounding code. If you have 'awk' installed on your system, the Shorewall compiler will correctly handle line continuation (last character on the line = "\"). If you do not have awk, it will not be possible to use line-continuation in your extension scripts. In no case is it possible to continue a quoted string over multiple lines without having additional whitespace inserted into the string. 6) Beginning with this release, the way in which packet marking in the PREROUTING chain interracts with the 'track' option in /etc/shorewall/providers has changed in two ways: a) Packets arriving on a tracked interface are now passed to the PREROUTING marking chain so that they may be marked with a mark other than the 'track' mark (the connection still retains the 'track' mark). b) When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets in the PREROUTING chain (i.e., you can specify a mark value of zero). 7) Kernel version 2.6.16 introduces 'xtables', a new common packet filtering and connection tracking facility that supports both IPv4 and IPv6. Because a different set of kernel modules must be loaded for xtables, Shorewall now includes two 'modules' files: a) /usr/share/shorewall/modules -- the former /etc/shorewall/modules b) /usr/share/shorewall/xmodules -- a new file that support xtables. If you wish to use the new file, then simply execute this command: cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules New Features: 1) Shorewall has always been very noisy (lots of messages). No longer. You set the default level of verbosity using the VERBOSITY option in shorewall.conf. If you don't set it (as would be the case of you use your old shorewall.conf file) then VERBOSITY defaults to a value of 2 which results in behavior compatible with previous Shorewall versions. A value of 1 suppresses some of the output (like the old -q option did) while a value of 0 makes Shorewall almost silent. A value of -1 suppresses all output except warning and error messages. The value specified in the 3.2 shorewall.conf is 1. So you can make Shorewall as verbose as previously using a single -v and you can make it silent by using a single -q. If the default is set at 2, you can still make a command silent by using two "q"s (e.g., shorewall -qq restart). In summary, each "q" subtracts one from VERBOSITY while each "v" adds one to VERBOSITY. The "shorewall show log", "shorewall logwatch" and "shorewall dump" commands require VERBOSITY to be greater than or equal to 3 to display MAC addresses.This is consistent with the previous implementation which required a single -v to enable MAC display but means that if you set VERBOSITY=0 in shorewall.conf, then you will need to include -vvv in commands that display log records in order to have MACs displayed. To make the display of MAC addresses let cumbersome, a '-m' option has been added to the "show" and logwatch commands: shorewall show -m log shorewall logwatch -m 2) A new 'shorewall compile' command has been added. shorewall compile [ -e ] [ ]