From d7b7e3f9cf00ccca7fbe0c44ad776f415a7a49e2 Mon Sep 17 00:00:00 2001 From: teastep Date: Mon, 9 Apr 2007 03:15:26 +0000 Subject: [PATCH] Fix strip_file bug in do_initialize() (again) git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5865 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-common/install.sh | 22 +- Shorewall-common/releasenotes.txt | 770 ++---------------------------- 2 files changed, 48 insertions(+), 744 deletions(-) diff --git a/Shorewall-common/install.sh b/Shorewall-common/install.sh index 320f4f56e..e539c38f4 100755 --- a/Shorewall-common/install.sh +++ b/Shorewall-common/install.sh @@ -195,15 +195,19 @@ if [ -n "$PREFIX" ]; then install -d $OWNERSHIP -m 755 ${PREFIX}/sbin install -d $OWNERSHIP -m 755 ${PREFIX}${DEST} -elif [ -d /etc/apt -a -e /usr/bin/dpkg ]; then - DEBIAN=yes -elif [ -f /etc/slackware-version ] ; then - DEST="/etc/rc.d" - INIT="rc.firewall" -elif [ -f /etc/arch-release ] ; then - DEST="/etc/rc.d" - INIT="shorewall" - ARCHLINUX=yes +else + [ -x /usr/share/shorewall-shell/compiler -o -x /usr/share/shorewall-perl/compiler.pl ] || \ + { echo " ERROR: No Shorewall compiler is installed" >&2; exit 1; } + if [ -d /etc/apt -a -e /usr/bin/dpkg ]; then + DEBIAN=yes + elif [ -f /etc/slackware-version ] ; then + DEST="/etc/rc.d" + INIT="rc.firewall" + elif [ -f /etc/arch-release ] ; then + DEST="/etc/rc.d" + INIT="shorewall" + ARCHLINUX=yes + fi fi # diff --git a/Shorewall-common/releasenotes.txt b/Shorewall-common/releasenotes.txt index 8d4c5070e..3fe087e44 100644 --- a/Shorewall-common/releasenotes.txt +++ b/Shorewall-common/releasenotes.txt @@ -1,759 +1,59 @@ -Shorewall 3.4.2 +Shorewall 3.9.1 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. +1) This is the first Shorewall release that fully integrates the new + Shorewall-perl compiler. - See http://www.shorewall.net/Modularization.html for details. +2) You are now offered a choice as to which compiler(s) you install. In + 3.9.1, there are the following packages: -2) Exclusion is now possible in /etc/shorewall/hosts. This is required - for bridge/firewalls under kernel 2.6.20 and later. + - Shorewall ( common files ) + - Shorewall-shell ( the shell-based compiler ) + - Shorewall-perl (the Perl-based compiler ) - See http://www.shorewall.net/NewBridge.html. +You must install Shorewall and at least one of the compiler packages +(you may install them both). -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 Shorewall 3.4.2 - -1) The /usr/share/shorewall[-lite]/modules file has been updated for - kernel 2.6.20. - -2) The /proc/net/ip_conntrack pseudo-file has been inexplicably - renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli - library has been updated to look for both files. - -3) Shoreall 3.4 was not consistent with respect to its treatment of - log level 'none' and 'none!' and built-in actions. In particular, - specifying 'none' with the Limit action produced a run-time error. - Shorewall now correctly suppresses generation of log messages when - a log level of 'none' or 'none!' is given to a built-in action. - -4) Tunnels of type 'ipsecnat' would sometimes fail to work because of - a missing rule. +Problems corrected in Shorewall 3.9.1 Migration Considerations: -If you are migrating from a Shorewall version earlier than 3.2.0 then -please see the 3.2.9 release notes for additional migration -information. +1) You cannot simply upgrade your existing Shorewall package. You must + upgrade Shorewall *and* install one or both of the compilers. -http://www.shorewall.net/pub/shorewall/3.2/shorewall-3.2.9/releasenotes.txt + If you attempt to upgrade using the RPM, you get this result: -1) 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. - -2) 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. - -3) 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. - -4) 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. - -5) This issue only applies if you use Shorewall Lite or if you use an - /etc/shorewall/capabilities file to speed up [re]start. - - Shorewall now detects additional capabilities which need to be - recorded in your capabilities file(s). Be sure to regenerate that - (those) file(s) after you have installed Shorewall 3.4.x. - -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:~ # rpm -Uvh shorewall-3.9.1-1.noarch.rpm + error: Failed dependencies: + shorewall_compiler is needed by shorewall-3.9.1-1.noarch gateway:~ # - This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf. + You must either: - 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 + rpm -U shorewall-3.9.1.noarch.rpm shorewall-shell-3.9.1.noarch.rpm - Counters reset Thu Oct 19 09:15:19 PDT 2006 + or - 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. + rpm -U shorewall-3.9.1.noarch.rpm shorewall-perl-3.9.1.noarch.rpm -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. + or + rpm -i shorewall-shell-3.9.1.noarch.rpm + rpm -U shorewall-3.9.1.noarch.rpm -27) There is now a ":T" qualifier in /etc/shorewall/tcrules which - causes the resulting rule to be inserted into the POSTROUTING - chain. + or + rpm -i shorewall-perl-3.9.1.noarch.rpm + rpm -U shorewall-3.9.1.noarch.rpm -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 [ ] + If you are upgrading using the tarball, you must install either + shorewall-shell or shorewall-perl before you upgrade + Shorewall. Otherwise, the install.sh script fails with: - The program will wait for up to seconds for the - named to reach the UP state. If is not given, - 60 seconds is assumed. + ERROR: No Shorewall compiler is installed - The exit status is zero if comes up within - seconds and non-zero otherwise. + The shorewall-shell and shorewall-perl packages are installed from + the tarball in the expected way; untar the package, and run the + install.sh script. -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. - -31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in - shorewall.conf then Shorewall will not process - /etc/shorewall/params when the compiled script is run. With - EXPORTPARAMS=No, 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. - - Note 1: If you need shell variables values in your - /etc/shorewall/stop or /etc/shorewall/stopped script, then you need - to set their values in /etc/shorewall/stop. /etc/shorewall/init is - not invoked during processing of the 'stop' and 'clear' commands. - - Note 2: EXPORTPARAMS was actually introduced in Shorewall version - 3.2.9. It is described here for the benefit of those who did not - install that version. - -Problems Corrected in 3.4.1 - -1) The "shorewall-[lite] [re]start and stop" commands reset the - proxy_arp flag on all interfaces on the system making it impossible - to control proxy arp manually with Shorewall installed. There was a - partial fix included in 3.4.0; unfortunately, it did not correct the - problem completely. Shorewall 3.4.1 includes the rest of the change - necessarey to only clear proxy arp if there were entries in - /etc/shorewall/proxyarp the last time that Shorewall was - [re]started. - -2) If the log-prefix in a log message exceeded 29 characters, - 'shorewall restart' fails with 'truncate: command not found' and a - possible segmentation fault in iptables. - -3) Log messages specifying a log tag had two spaces appended to the - log prefix. This could cause mysterious "log-prefix truncated" - messages. - -4) When nested zones were defined in the /etc/shorewall/zones file and - IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf, - shell error messages ( usually ': not found' ) during - compilation resulted. - -5) Use of CONTINUE policies lead to startup errors with a message - such as the following: - - Applying Policies... - iptables v1.3.7: Couldn't load target - `CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open - shared object file: No such file or directory - - Try `iptables -h' or 'iptables --help' for more information. - - ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE" - Failed - -6) If there were hosts defined as 'critical' in - /etc/shorewall/routestopped then problems occured in two cases: - - i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall - clear' was issued. - - ii) On Shorewall or Shorewall lite system when 'start' or 'restart' - failed during execution of the compiled script and there was no saved - configuration ('shorewall[-lite] save' has not been issued). - - The symptoms were that the following shell messages were issued and - the 'critical' hosts were not enabled: - - /var/lib/shorewall/.start: line nnn: source_ip_range: command not found - /var/lib/shorewall/.start: line nnm: dest_ip_range: command not found - -Other changes in 3.4.1 - -1) Several changes are included which allow testing of experimental - versions of Shorewall on systems with 3.4.1 and later 3.4 releases - installed. Among these changes is the detection and reporting of - "Address Type Match" which may be used in future 3.4 releases. - These changes have no effect on normal Shorewall operation. +New Features in Shorewall 3.9: