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 \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
-------------------------------------------------------------------------
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/