Shorewall 3.4.0 RC2 Release Highlights 1) Shorewall can now be tailored to reduce its footprint on embedded systems. As part of this change, actions are now completely optional. See http://www.shorewall.net/Modularization.html for details. 2) Exclusion is now possible in /etc/shorewall/hosts. This is required for bridge/firewalls under kernel 2.6.20 and later. See http://www.shorewall.net/NewBridge.html. 3) Shorewall and Shorewall Lite now include man pages. There is a man page for shorewall(8), one for shorewall-lite(8) and one for each configuration file. As part of this change, all documentation has been removed from Shorewall configuration files. This should make it easier from users to upgrade from one release to the next since the configuration files will only change when column is added or renamed. See http://www.shorewall.net/manpages/Manpages.html 4) Shorewall now remembers the changes that it has made to routing as a result of entries in /etc/shorewall/providers and /etc/shorewall/route_rules and reverses those changes when appropriate. Problems Corrected in 3.4.0 RC2 None. Other Changes in 3.4.0 RC 1 1) In spite of my claim that I would not introduce any changes other than bug fixes in a release candidate, I'm going to do so anyway. Beginning with Shorewall 3.4.0, Shorewall will only process /etc/shorewall/params during the compile phase. Any shell variables needed at run-time must be set in /etc/shorewall/init. In a Shorewall/Shorewall Lite environment, this allows /etc/shorewall/params to be written to run exclusively on the administrative system while /etc/shorewall/init runs exclusively on the firewall system. So shell variables required at compile time may be set in /etc/shorewall/params and those required at run-time may be set in /etc/shorewall/init. As part of this change, extra white space is no longer removed from /etc/shorewall/params as it was in RC1. Migration Considerations: If you are migrating from a Shorewall version earlier than 3.2.0 then please see the 3.2.8 release notes for additional migration information. http://www.shorewall.net/pub/shorewall/3.2/shorewall-3.2.8/releasenotes.txt 1) Beginning with Shorewall 3.4.0, Shorewall will only process /etc/shorewall/params during the compile phase. Any shell variables needed at run-time must be set in /etc/shorewall/init. In a Shorewall/Shorewall Lite environment, this allows /etc/shorewall/params to be written to run exclusively on the administrative system while /etc/shorewall/init runs exclusively on the firewall system. So shell variables required at compile time may be set in /etc/shorewall/params and those required at run-time may be set in /etc/shorewall/init. 2) Shorewall supports the notion of "default actions". A default action defines a set of rules that are applied before a policy is enforced. Default actions accomplish two goals: a) Relieve log congestion. Default actions typically include rules to silently drop or reject traffic that would otherwise be logged when the policy is enforced. b) Insure correct operation. Default actions can also avoid common pitfalls like dropping connection requests on TCP port 113. If these connections are dropped (rather than rejected) then you may encounter problems connecting to internet services that utilize the AUTH protocol of client authentication. In prior Shorewall versions, default actions (action.Drop and action.Reject) were defined for DROP and REJECT policies in /usr/share/shorewall/actions.std. These could be overridden in /etc/shorewall/actions. This approach has two drawbacks: a) All DROP policies must use the same default action and all REJECT policies must use the same default action. b) Now that we have modularized action processing (see the New Features section below), we need a way to define default rules for a policy that does not involve actions. If you have not overridden the defaults using entries in /etc/shorewall/actions then you need make no changes to migrate to Shorewall version 3.4. Otherwise, please see item 3) in the New Features below. 3) The 'Limit' action is now a builtin. If you have 'Limit' listed in /etc/shorewall/actions, remove the entry. Also remove the files /etc/shorewall/action.Limit and/or /etc/shorewall/Limit if you have them. 4) This issue only applies if you have entries in /etc/shorewall/providers. Previously, Shorewall has not attempted to undo the changes it has made to the firewall's routing as a result of entries in /etc/shorewall/providers and /etc/shorewall/routes. Beginning with this release, Shorewall will attempt to undo these changes. See item 15 under new features below for additional information. This change can present a migration issue in that the initial routing configuration when this version of Shorewall is installed has probably been changed by Shorewall already. Hence, when Shorewall restores the original configuration, it will be installing a configuration that the previously-installed version has already modified. The steps to correcting this after you have installed this version of Shorewall are as follows: a) "shorewall[-lite] stop" b) Be sure that the files /var/lib/shorewall[-lite]/default_route and /var/lib/shorewall[-lite]/undo_routing do not exist. If they do exist, remove them. b) Either restart networking or reboot. 5) This issue only applies if you run Shorewall Lite. The /etc/shorewall-lite/shorewall.conf file has been renamed /etc/shorewall-lite/shorewall-lite.conf. When you upgrade, your shorewall.conf file will be renamed shorewall-lite.conf. 6) Previously, 'ipsecnat' tunnels allowed AH traffic by default (unless 'isecnat:noah' was given). Given that AH is incompatible with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah' and the latter is now redundant. New Features in Shorewall 3.4: 1) In order to accomodate small embedded applications, Shorewall 3.4 is now modularized. In addition to the base files, there are loadable "libraries" that may be included or omitted from an embedded system as required. Loadable Shorewall libraries reside in /usr/share/shorewall/ and have names that begin with "lib.". The following libraries are included in Shorewall 3.4: - lib.accounting. Must be available if you include entries in /etc/shorewall/accounting. - lib.actions. Must be available if you do not specify USE_ACTIONS=No in /etc/shorewall/shorewall.conf. - lib.base. The base Shorewall library required by all programs, including compiled firewall scripts. This library is also released as part of Shorewall Lite and is installed in /usr/share/shorewall-lite/. - lib.cli. Library containing the code common to /sbin/shorewall, /sbin/shorewall-lite. This library is also released as part of Shorewall Lite and is installed in /usr/share/shorewall-lite/. - lib.config. Library containing the code that is common to /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. - lib.dynamiczones. Must be available if you specify DYNAMIC_ZONES=Yes in shorewall.conf. - lib.maclist. Must be available if you specify the 'maclist' option in /etc/shorewall/interfaces or /etc/shorewall/hosts. - lib.nat. Must be available if you have entries in /etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap or if you use DNAT or REDIRECT rules. - lib.providers. Must be available if you have entries in /etc/shorewall/providers. - lib.proxyarp. Must be available if you have entries in /etc/shorewall/proxyarp or if you specify the 'proxyarp' option in /etc/shorewall/interfaces. - lib.tc. Must be available if you have entries in /etc/shorewall/tcdevices and /etc/shorewall/tcclasses. - lib.tcrules. Must be available if you have entries in /etc/shorewall/tcrules. - lib.tunnels. Must be available if you have entries in /etc/shorewall/tunnels. Embedded applications can further decrease the size of the Shorewall footprint by: - Omitting the macro files. - Omitting all unused extension scripts. See http://www.shorewall.net/Modularization.html for additional details. 2) As hinted in the previous bullet, there is a new USE_ACTIONS option in /etc/shorewall/shorewall.conf. Shorewall actions can be very powerful but they also require a lot of code to implement. Embedded applications can omit that code by setting USE_ACTIONS=No. Shorewall will ignore all action-related files including /usr/share/shorewall/actions.std and /etc/shorewall/actions. Builtin actions will still be available for use in rules and macros. The 'Limit' action has been converted to a builtin so that Limit is available even when USE_ACTIONS=No. See the next item for more information. 3) Prior to Shorewall 3.4, default actions were specified in /usr/share/shorewall/actions.std or in /etc/shorewall/actions. This approach has two drawbacks: a) All DROP policies must use the same default action and all REJECT policies must use the same default action. b) Now that we have modularized action processing (see the New Features section below), we need a way to define default rules for a policy that does not involve actions. The solution is two-fold: - Four new options have been added to the /etc/shorewall/shorewall.conf file that allow specifying the default action for DROP, REJECT, ACCEPT and QUEUE. The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT. DROP_DEFAULT describes the rules to be applied before a connection request is dropped by a DROP policy; REJECT_DEFAULT describes the rules to be applied if a connection request is rejected by a REJECT policy. The other two are similar for ACCEPT and QUEUE policies. The value assigned to these may be: a) The name of an action. b) The name of a macro c) 'None' or 'none' The default values are: DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" ACCEPT_DEFAULT=none QUEUE_DEFAULT=none If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and macro.Reject. If you set the value of either option to "None" then no default action will be used and the default action or macro (if any) must be specified in /etc/shorewall/policy - The POLICY column in /etc/shorewall/policy has been extended. In /etc/shorewall/policy, when the POLICY is DROP, REJECT, ACCEPT or QUEUE then the policy may be followed by ":" and one of the following: a) The word "None" or "none". This causes any default action defined in /etc/shorewall/shorewall.conf to be omitted for this policy. b) The name of an action (requires that USE_ACTIONS=Yes in shorewall.conf). That action will be invoked before the policy is enforced. c) The name of a macro. The rules in that macro will be applied before the policy is enforced. This does not require USE_ACTIONS=Yes. Example: #SOURCE DEST POLICY LOG # LEVEL loc net ACCEPT net all DROP:MyDrop info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT:MyReject info 4) For users whose kernel and iptables have Extended MARK Target support, it is now possible to logically AND or OR a value into the current packet mark by preceding the mark value (and optional mask) with an ampersand ("&") or vertical bar ("|") respectively. Example: To logically OR the value 4 into the mark value for packets from 192.168.1.1: #MARK SOURCE |4 192.168.1.1 5) Previously, zone names were restricted to five characters in length. That limit derives from the --log-prefix in Netfilter log messages which must be 29 bytes or less in length. With the standard Shorewall LOGFORMAT, that leaves 11 characters for the chain name; given that many chain names are of the form 2, that gives a maximum zone name length of 5. Beginning with this release, the maximum length of a zone name is dependent on the LOGFORMAT (the maximum length may never be less than 5 but it may be greater than 5). For example, setting LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters. 6) Netfilter provides support for attachment of comments to Netfilter rules. Comments can be up to 255 bytes in length and are visible using the "shorewall show ", "shorewall show nat", "shorewall show mangle" and "shorewall dump" commands. Comments are delimited by '/* ... */" in the output. Beginning with Shorewall 3.4, you may place COMMENT lines in the /etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat and /etc/shorewall/masq files and in action files. The remainder of the line is treated as a comment and it will be attached as a Netfilter comment to the rule(s) generated by succeding entries in the file. Note: Do not prefix the comment with "#". Shorewall's two-pass compiler strips off "#" comments in the first pass and processes COMMENT lines in the second pass. Hence, by the time that COMMENT is processed, the "#" and everything following it has been removed (see example below). To stop the current comment from being attached to further rules, simply include COMMENT on a line by itself (so that the following rules will have no comment) or specify a new COMMENT. If you do not have Comment support in your iptables/kernel (see the output of "shorewall[-lite] show capabilities") then COMMENTS are ignored with this warning: COMMENT ignored -- requires comment support in iptables/Netfilter Example from my rules file: #SOURCE SOURCE DEST PROTO DEST PORT(S) COMMENT Stop Microsoft Noise REJECT loc net tcp 137,445 REJECT loc net udp 137:139 COMMENT # Stop comment from being attached to rules below The output of "shorewall show loc2net" includes (folded): 0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 137,445 /* Stop Microsoft Noise */ 0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139 /* Stop Microsoft Noise */ 7) A new macro (macro.RDP) has been added for Microsoft Remote Desktop. This macro was contributed by Tuomo Soini. 8) A new 'maclog' extension file has been added. This file is processed just before logging based on the setting of MACLIST_LOG_LEVEL is done. When the extension is invoked, the CHAIN variable will contain the name of the chain where rules should be inserted. Remember that if you have specified MACLIST_TABLE=mangle, then your run_iptables commands should include "-t mangle". 9) The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to more accurately describe the contents of the column. 10) Previously, it was not possible to use exclusion in /etc/shorewall/hosts. Beginning with this release, you may now use exclusion lists in entries in this file. Exclusion lists are discussed at: http://www.shorewall.net/configuration_file_basics.htm#Exclusion. Example: loc eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28 In that example, the 'loc' zone is defined to be the subnet 192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4 and hosts in the sub-network 192.168.1.16/28. 11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing" commands have been added. The first produces the same output as "ip addr ls". The second produces a report about your routing rules and tables. 12) Beginning with this release, Shorewall and Shorewall Lite will share common change logs and release notes. 13) In Shorewall versions prior to 3.4, multiple jumps to a '2all' chain could be generated in succession. Example from an earlier shorewall version: gateway:~ # shorewall-lite show eth2_fwd Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006 Counters reset Thu Oct 19 08:34:47 PDT 2006 Chain eth2_fwd (1 references) pkts bytes target prot opt in out source destination 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 0 0 wifi2all all -- * eth0 0.0.0.0/0 0.0.0.0/0 0 0 wifi2all all -- * br0 0.0.0.0/0 0.0.0.0/0 0 0 wifi2all all -- * eth3 0.0.0.0/0 0.0.0.0/0 0 0 wifi2all all -- * tun+ 0.0.0.0/0 0.0.0.0/0 gateway:~ # This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf. gateway:~ # shorewall-lite show eth2_fwd Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006 Counters reset Thu Oct 19 09:15:19 PDT 2006 Chain eth2_fwd (1 references) pkts bytes target prot opt in out source destination 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 0 0 wifi2all all -- * * 0.0.0.0/0 0.0.0.0/0 gateway:~ # Note that with OPTIMIZE=1, traffic destined for an interface/Address that falls outside of all defined zones may now be logged out of a '2all' chain rather than out of the FORWARD chain. The OPTIMIZE setting also controls the suppression of redundant wildcard rules (those specifying "all" in the SOURCE or DEST column). A wildcard rule is considered to be redundant when it has the same ACTION and Log Level as the applicable policy. Example: /etc/shorewall/policy #SOURCE DEST POLICY LEVEL loc net ACCEPT /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST # PORT(S) ... ACCEPT all all icmp 8 OPTIMIZE=0 gateway:~ # shorewall show loc2net Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006 Counters reset Thu Oct 26 07:54:58 PDT 2006 Chain loc2net (1 references) pkts bytes target prot opt in out source destination ... 0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 gateway:~ OPTIMIZE=1 gateway:~ # shorewall show loc2net Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006 Counters reset Thu Oct 26 07:56:38 PDT 2006 Chain loc2net (1 references) pkts bytes target prot opt in out source destination ... 0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 gateway:~ If you really want a rule that duplicates the policy, follow the action with "!": #ACTION SOURCE DEST PROTO DEST # PORT(S) ... ACCEPT! all all icmp 8 14) IP Address ranges are now allowed in the drop, reject, allow and logdrop shorewall[-lite] commands. 15) Previously, Shorewall has not attempted to undo the changes it has made to the firewall's routing as a result of entries in /etc/shorewall/providers and /etc/shorewall/routes. Beginning with this release, Shorewall will attempt to undo these changes. When Shorewall starts or is restarted and there are entries in /etc/shorewall/providers, Shorewall will capture the contents of /etc/shorewall/rt_tables and will restore that database when Shorewall is stopped or restarted. Similarly, the default route will be captured the first time that you [re]start Shorewall using this version and will be restored under the following conditions: a) shorewall stop b) shorewall clear c) shorewall restart or restore and there are no entries in /etc/shorewall/providers. Once the default route has been restored, Shorewall will delete the saved copy so that it will once again be captured at the next shorewall start or shorewall restore. 16) Shorewall no longer includes policy matches in its generated ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC networks are defined using the 'ipsec' option in /etc/shorewall/hosts). 17) The Makefile installed in /usr/share/shorewall/configfiles/ is now the same one mentioned at http://www.shorewall.net/CompiledPrograms.html. Once the file is copied into an export directory, you modify the setting of the HOST variable to match the name of the remote firewall. The default target is the "firewall" script so "make" compiles the firewall script if any of the configuration files have changed. "make install" builds "firewall" if necessary then installs it on the remote firewall. "make capabilities" will generate the "capabilities" file. "make save" will save the running configuration on the remote firewall. 18) Shorewall and Shorewall Lite now include the following manpages. shorewall-accounting(5) shorewall-actions(5) shorewall-blacklist(5) shorewall.conf(5) shorewall-ecn(5) shorewall-exclusion(5) shorewall-hosts(5) shorewall-interfaces(5) shorewall-lite.conf(5) shorewall-lite(8) shorewall-maclist(5) shorewall-masq(5) shorewall-nat(5) shorewall-nesting(5) shorewall-netmap(5) shorewall-params(5) shorewall-policy(5) shorewall-providers(5) shorewall-proxyarp(5) shorewall-rfc1918(5) shorewall-route_rules(5) shorewall-routestopped(5) shorewall-rules(5) shorewall-tcclasses(5) shorewall-tcdevices(5) shorewall-tcrules(5) shorewall-template(5) shorewall-tos(5) shorewall-tunnels(5) shorewall(8) shorewall-zones(5) Now that the manpages are in place, command-specific help has been removed since it duplicates information in the man pages. 19) From the beginning, the Shorewall configuration files in /etc/shorewall/ have contained documentary comments. While these comments are useful, they present an upgrade problem. Beginning with this release, these comments are removed from the configuration files themselves and are replaced by the manpages described in the preceding release note entry. 20) Shorewall now uses tc fwmark filters to classify packets for traffic shaping when the DEVICE isn't an interface described in /etc/shorewall/interfaces. This is in preparation for the upcoming change to the way that --physdev-out works in iptables/Netfilter; that change is now scheduled for kernel 2.6.20. 21) If your kernel and iptables have extended multiport support, then Shorewall will use that support for the destination port when generating rules from entries in the /etc/shorewall/tcrules file. 22) The 'safe-start' and 'safe-restart' command have been improved. Both now accept an optional directory name; if supplied, Shorewall will look first in that directory for configuration files. The commands have also been enhanced to only restore the configuration once in the event of a failure. Previously, if there was a current 'save' command in effect, then that configuration would be restored on a failure and then the last-running configuration would be restored. 23) The 'try' command has been reimplemented with new semantics. If Shorewall is started then the firewall state is saved to a temporary saved configuration (/var/lib/shorewall/.try). Next, if Shorewall is currently started then a restart command is issued; otherwise, a start command is performed. if an error occurs during the compliation phase of the restart or start, the command terminates without changing the Shorewall state. If an error occurs during the restart phase, then a 'shorewall restore' is performed using the saved configuration. If an error occurs during the start phase, then Shorewall is cleared. If the start/restart succeeds and a timeout is specified then a 'clear' or 'restore' is performed after timeout seconds. 24) The syntax of the 'export' command has been made slightly friendlier. The old syntax: export [user@]system:[] It is now: export [user@]system[:] In other words, if you don't need to specify , you may omit the colon (":") following the system name. The old syntax is still accepted -- that is, you can still type: export firewall2: which is equivalent to export firewall2 25) Shorewall commands may be speeded up slightly by using a 'capabilities' file. The 'capabilities' file was originally designed for use with Shorewall Lite and records the iptables/Netfilter features available on the target system. To generate a capabilities file, execute the following command as root: shorewall show -f capabilities > /etc/shorewall/capabilities When you install a new kernel and/or iptables, be sure to generate a new capabilities file. 26) When syslogd is run with the -C option (which in some implementations causes syslogd to log to an in-memory circular buffer), /sbin/shorewall will now use the 'logread' command to read the log from that buffer. This is for combatibility with OpenWRT. 27) There is now a ":T" qualifier in /etc/shorewall/tcrules which causes the resulting rule to be inserted into the POSTROUTING chain. 28) The program /usr/share/shorewall/wait4ifup can be used to wait for a network device (such as a ppp device) to reach the UP state. /usr/share/shorewall/wait4ifup [ ] The program will wait for up to seconds for the named to reach the UP state. If is not given, 60 seconds is assumed. The exit status is zero if comes up within seconds and non-zero otherwise. 29) Previously, 'ipsecnat' tunnels allowed AH traffic by default (unless 'isecnat:noah' was given). Given that AH is incompatible with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'. 30) Shorewall now generates half as many rules as previously in the 'blacklst' chain when BLACKLIST_LOGLEVEL is specified. Problems Corrected in 3.4.0 Beta 1. 1) It is now possible to place entries in the IPSEC column of /etc/shorewall/masq without having specified ipsec zones or hosts. 2) The /etc/shorewall/masq file is no longer ignored when the /etc/shorewall/nat file is empty. Problems Corrected in 3.4.0 Beta 2 1) If 'blacklist' was specified on an interface and the /etc/shorewall/blacklist file was empty, then the generated firewall script contained a syntax error (the function load_blacklist() was empty). 2) If the file /etc/shorewall/init did not exist, then the compiler would incorrectly copy /usr/share/shorewall/init into the compiled script. /usr/share/shorewall/init is a symbolic link to the Shorewall init script (usually /etc/init.d/shorewall). 3) To allow Shorewall and Shorewall Lite to coexist on a single system, the Shorewall section 5 manpages are no longer included in Shorewall Lite. In addition, the Shorewall Lite manpage for "shorewall.conf" has been renamed "shorewall-lite.conf". This has resulted in a similar change to the actual file -- /etc/shorewall-lite/shorewall.conf has been renamed /etc/shorewall-lite/shorewall-lite.conf. Problems Corrected in 3.4.0 Beta 3 1) Shorewall now supports VLAN interfaces with names of the form vlan@ethX. 2) Previously, "ipp2p:udp" was incorrectly rejected in the PROTO column of an action definition. 3) Previously, if an invalid DISPOSITION was specified in a record in /etc/shorewall/maclist, then a confusing error message would result. Example: /etc/shorewall/mac: ALOW:info eth0 02:0C:03:04:05:06 Error message: ERROR: No hosts on ALOW:info have the maclist option specified The new error message is: ERROR: Invalid DISPOSITION (ALOW:info) in rule "ALOW:info eth0 02:0C:03:04:05:06" Problems Corrected in 3.4.0 RC1 1) While most distributions store the Shorewall Lite compiled program in /var/lib/shorewall/, Shorewall includes features that allow that location to be changed on a per-distribution basis. The default for a particular distribution may be determined by the command "shorewall[-lite] show config". teastep@lists:~/shorewall/trunk$ shorewall show config Default CONFIG_PATH is /etc/shorewall:/usr/share/shorewall LITEDIR is /var/lib/shorewall-lite teastep@lists:~/shorewall/trunk$ The LITEDIR setting is the location where the compiled script should be placed. Unfortunately, the "shorewall [re]load" command previously used the setting on the administrative system rather than the one from the firewall system so it was possible for that command to upload the compiled script to the wrong directory. To work around this problem, Shorewall now determines the LITEDIR setting on the firewall system and uses that setting for uploading the compiled script and its companion .conf file. 2) Previously, IP ranges and ipset names were handled incorrectly in the last column of the maclist file with the result that run-time errors occured. 3) The Beta3 manpages are sprinked with .html filenames enclosed in square brackets. Example: ...set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf [shorewall.conf.html](5) and have... These were generated by elements in the XML source which were added to provide inter-document links in the HTML rendition of the manpages. s were previously ignored by the XML->man conversion tool; unfortunately, the latest release of the tool no longer ignores these elements but rather produces the ugly result shown above. This problem has been corrected in RC1. 4) Previously, if "INCLUDE " appeared in /etc/shorewall/params then run-time errors occurred. As part of the fix for this problem, the mechanism by which /etc/shorewall/params is copied into the compiler output was changed. As a result, extra white space is removed from the text during the copy operation so code in /etc/shorewall/params should not depend on precise white-space, even in quoted strings. Other Changes in 3.4.0 RC 1 1) A macro that handles SixXS has been contributed by Christian Roessner.