Because the 4.0.5 release contains an unusually large number of new features for a dot release, I'm making the first pre-release available earlier than normal to provide extra testing time.
I've called the release 4.0.5-RC1 to make migration to the final release smoother for those of you who use the RPMs. It is available at: http://www1.shorewall.net/pub/shorewall/development/4.0/shorewall-4.0.5-RC1 ftp://ftp1.shorewall.net/pub/shorewall/development/4.0/shorewall-4.0.5-RC1 Problems corrected in Shoreawll 4.0.5. 1) Previously, Shorewall-perl misprocessed $FW::<port> in the DEST column of a REDIRECT rule. 2) If the PROTOCOL (PROTO) column contained 'TCP' or 'UDP' and SOURCE PORT(S) or DEST PORT(S) were given, then the entry was rejected with the error: ERROR: SOURCE/DEST PORT(S) not allowed with PROTO TCP : /etc/shorewall/rules ... The rule was accepted if 'tcp' or 'udp' is used instead. Other changes in Shorewall 4.0.5. 1) Two new options have been added to /etc/shorewall/hosts (Shorewall-perl only). broadcast: Permits limited broadcast (destination 255.255.255.255) to the zone. destonly: Normally used with the Multi-cast range. Specifies that traffic will be sent to the specified net(s) but that no traffic will be received from the net(s). Example: wifi eth1:192.168.3.0/24 broadcast wifi eth1:224.0.0.0/4 destonly In that example, limited broadcasts from the firewall with a source IP in the 192.168.3.0/24 range will be acccepted as will multicasts (with any source address). 2) A MULTICAST option has been added to shorewall.conf. This option will normally be set to 'No' (the default). It should be set to 'Yes' under the following circumstances: a) You have an interface that has parallel zones defined via /etc/shorewall/hosts. b) You want to forward multicast packets to two or more of those parallel zones. In such cases, you will configure a 'destonly' network on each zone receiving multicasts. The MULTICAST option is only recognized by Shorewall-perl and is ignored by Shorewall-shell. 3) As announced in the Shorewall 4.0.4 release notes, Shorewall-perl no longer supports the 'detectnets' option. Specifying that option now results in the following message: WARNING: Support for the 'detectnets' option has been removed It is suggested that 'detectnets' be replaced by 'routefilter,logmartians'. That will produce the same filtering effect as 'detectnets' while eliminating 1-2 rules per connection. One user has asked how to retain the output of 'shorewall show zones' if the 'detectnets' option is removed. While I don't advise doing so, you can reproduce the current 'shorewall show' behavior zones' if the 'detectnets' option is removed. While I don't advise doing so, you can reproduce the current 'shorewall show' behavior as follows. Suppose that you have a zone named 'wifi' that produces the following output with 'detectnets': wifi (ipv4) eth1:192.168.3.0/24 You can reproduce this behavior as follows: /etc/shorewall/interfaces: - eth1 detect ... /etc/shorewall/hosts: wifi eth1:192.168.3.0/24 broadcast If you send multicast to the 'wifi' zone, you also need this entry in your hosts file: wifi eth1:224.0.0.0/4 destonly 4) (Shorewall-perl only) The server port in a DNAT or REDIRECT rule may now be specified as a service name from /etc/services. Additionally: a) A port-range may be specified as the service port expressed in the format <low port>-<high port>. Connections are assigned to server ports in round-robin fashion. b) The compiler only permits a server port to be specified if the protocol is tcp or udp. c) The compiler ensures that the server IP address is valid (note that it is still not permitted to specify the server address as a DNS name). 5) (Shorewall-perl only) Users are complaining that when they migrate to Shorewall-perl, they have to restrict their port lists to 15 ports. In this release, we relax that restriction on destination port lists. Since the SOURCE PORT(s) column in the config files is rarely used, we have no plans to relax the restriction in that column. 6) There have been several cases where iptables-restore has failed while executing a COMMIT command in the .iptables_restore_input file. This gives neither the user nor Shorewall support much to go on when analyzing the problem. As a new debugging aid, the meaning of 'trace' and 'debug' have been changed. Traditionally, /sbin/shorewall and /sbin/shorewall-lite have allowed either 'trace' or 'debug' as the first run-line parameter. Prior to 4.0.5, the two words produced the same effect. Beginning with Shorewall 4.0.5, the two words have different effects when Shorewall-perl is used. trace - Like the previous behavior. In the Shorewall-perl compiler, generate a stack trace on WARNING and ERROR messages. In the generated script, sets the shell's -x option to trace execution of the script. debug - Ignored by the Shorewall-perl compiler. In the generated script, causes the commands in .iptables_restore_input to be executed as discrete iptables commands. The failing command can thus be identified and a diagnosis of the cause can be made. Users of Shorewall-lite will see the following change when using a script that was compiled with Shorewall-perl 4.0.5 or later. trace - In the generated script, sets the shell's -x option to trace execution of the script. debug - In the generated script, causes the commands in .iptables_restore_input to be executed as discrete iptables commands. The failing command can thus be identified and a diagnosis of the cause can be made. In all other cases, 'debug' and 'trace' remain synonymous. In particular, users of Shorewall-shell will see no change in behavior. WARNING: The 'debug' feature is strictly for problem analysis. When 'debug' is used: a) The firewall is made 'wide open' before the rules are applied. b) The routestopped file is not consulted. c) The rules are applied in the canonical iptables-restore order. So if you need critical hosts to be always available during start/restart, you may not be able to use 'debug'. 7) /usr/share/shorewall-perl/buildports.pl, /usr/share/shorewall-perl/FallbackPorts.pm and /usr/share/shorewall-perl/Shorewall/Ports.pm have been removed. Shorewall now resolves protocol and port names using Perl's interface to the the standard C library APIs getprotobyname() and getservbyname(). It may be a bit slower on large configurations but it keeps the distribution maintainers happy. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
