2010-02-24 02:00:26 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-06-06 22:37:56 +02:00
|
|
|
S H O R E W A L L 4 . 4 . 1 0
|
2010-02-24 02:00:26 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
I. RELEASE 4.4 HIGHLIGHTS
|
|
|
|
II. MIGRATION ISSUES
|
|
|
|
III. PROBLEMS CORRECTED IN THIS RELEASE
|
|
|
|
IV. KNOWN PROBLEMS REMAINING
|
|
|
|
V. NEW FEATURES IN THIS RELEASE
|
|
|
|
VI. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES
|
2008-12-07 19:17:26 +01:00
|
|
|
|
2008-12-17 22:06:30 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-02-24 02:00:26 +01:00
|
|
|
I. R E L E A S E 4 . 4 H I G H L I G H T S
|
2008-12-17 22:06:30 +01:00
|
|
|
----------------------------------------------------------------------------
|
2008-12-13 21:45:23 +01:00
|
|
|
|
2009-11-23 20:15:33 +01:00
|
|
|
1) Support for Shorewall-shell has been discontinued. Shorewall-perl
|
|
|
|
has been combined with Shorewall-common to produce a single
|
|
|
|
Shorewall package.
|
|
|
|
|
|
|
|
2) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing
|
|
|
|
discipline has been added. HFSC is superior to the "Hierarchical
|
|
|
|
Token Bucket" queuing discipline where realtime traffic such as
|
|
|
|
VOIP is being used.
|
|
|
|
|
|
|
|
HTB remains the default queuing discipline.
|
|
|
|
|
|
|
|
3) Support for the "flow" traffic classifier has been added. This
|
|
|
|
classifier can help prevent multi-connection applications such as
|
|
|
|
BitTorrent from using an unfair amount of bandwidth.
|
|
|
|
|
|
|
|
4) The Shorewall documentation and man pages have been purged of
|
|
|
|
information about earlier Shorewall releases. The documentation
|
|
|
|
describes only the behavior of Shorewall 4.4 and later versions.
|
|
|
|
|
|
|
|
5) The interfaces file OPTIONs have been extended to largely remove the
|
|
|
|
need for the hosts file.
|
|
|
|
|
|
|
|
6) It is now possible to define PREROUTING and OUTPUT marking rules
|
|
|
|
that cause new connections to use the same provider as an existing
|
|
|
|
connection of the same kind.
|
|
|
|
|
|
|
|
7) Dynamic Zone support is once again available for IPv4; ipset support is
|
|
|
|
required in your kernel and in iptables.
|
|
|
|
|
|
|
|
8) A new AUTOMAKE option has been added to shorewall.conf and
|
|
|
|
shorewall6.conf. Setting this option will allow Shorewall to skip
|
|
|
|
the compilation phase during start/restart if no configuration
|
|
|
|
changes have occurred since the last start/restart.
|
|
|
|
|
|
|
|
9) The LIMIT:BURST column in /etc/shorewall/policy
|
|
|
|
(/etc/shorewall6/policy) and the RATE LIMIT column in
|
|
|
|
/etc/shorewall/rules (/etc/shorewall6/rules) may now be used to
|
|
|
|
limit on a per source IP or per destination IP basis.
|
|
|
|
|
|
|
|
10) Support for per-IP traffic shaping classes has been added.
|
|
|
|
|
|
|
|
11) Support for netfilter's TRACE facility has been added. TRACE allows
|
|
|
|
you to trace selected packets through Netfilter, including marking
|
|
|
|
by tcrules.
|
2009-08-11 17:02:36 +02:00
|
|
|
|
2010-01-13 00:32:50 +01:00
|
|
|
12) You may now preview the generated ruleset by using the '-r' option
|
|
|
|
to the 'check' command (e.g., "shorewall check -r").
|
|
|
|
|
2010-01-13 05:12:31 +01:00
|
|
|
13) A new simplified Traffic Shaping facility is now available.
|
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
14) Additional ruleset optimization options are available.
|
|
|
|
|
2010-01-17 17:20:15 +01:00
|
|
|
15) TPROXY support has been added.
|
|
|
|
|
2009-03-01 20:46:30 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-02-24 02:00:26 +01:00
|
|
|
I I. M I G R A T I O N I S S U E S
|
2009-03-01 20:46:30 +01:00
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
1) If you are currently using Shorewall-shell:
|
|
|
|
|
|
|
|
a) In shorewall.conf, if you have specified
|
|
|
|
"SHOREWALL_COMPILER=shell" then you must either:
|
|
|
|
|
|
|
|
- change that specification to "SHOREWALL_COMPILER=perl"; or
|
|
|
|
- change that specification to "SHOREWALL_COMPILER="; or
|
|
|
|
- delete the specification altogether.
|
|
|
|
|
|
|
|
Failure to do so will result in the following warning:
|
|
|
|
|
|
|
|
WARNING: SHOREWALL_COMPILER=shell ignored. Shorewall-shell
|
|
|
|
support has been removed in this release.
|
|
|
|
|
|
|
|
b) Review the migration issues at
|
|
|
|
http://www.shorewall.net/LennyToSqueeze.html and make changes as
|
|
|
|
required.
|
|
|
|
|
|
|
|
We strongly recommend that you migrate to Shorewall-perl on your
|
|
|
|
current Shorewall version before upgrading to Shorewall 4.4.0. That
|
|
|
|
way, you can have both Shorewall-shell and Shorewall-perl available
|
|
|
|
until you are certain that Shorewall-perl is working correctly for
|
|
|
|
you.
|
|
|
|
|
|
|
|
2) The 'shorewall stop', 'shorewall clear', 'shorewall6 stop' and
|
|
|
|
'shorewall6 clear' commands no longer read the 'routestopped'
|
|
|
|
file. The 'routestopped' file used is the one that was present at
|
|
|
|
the last 'start', 'restart' or 'restore' command.
|
|
|
|
|
|
|
|
IMPORTANT: If you modify the routestopped file, you must refresh or
|
|
|
|
restart Shorewall before the changes to that file take effect.
|
|
|
|
|
|
|
|
3) The old macro parameter syntax (e.g., SSH/ACCEPT) is now deprecated
|
|
|
|
in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.4 documentation
|
|
|
|
uses the new syntax exclusively, although the old syntax
|
|
|
|
continues to be supported.
|
|
|
|
|
|
|
|
The sample configurations also use the new syntax.
|
|
|
|
|
|
|
|
4) Support for the SAME target in /etc/shorewall/masq and
|
|
|
|
/etc/shorewall/rules has been removed, following the removal of the
|
|
|
|
underlying support in the Linux kernel.
|
|
|
|
|
|
|
|
5) Supplying an interface name in the SOURCE column of
|
|
|
|
/etc/shorewall/masq is now deprecated. Entering the name of an
|
|
|
|
interface there will result in a compile-time warning:
|
|
|
|
|
|
|
|
WARNING: Using an interface as the masq SOURCE requires the
|
|
|
|
interface to be up and configured when Shorewall
|
|
|
|
starts/restarts
|
|
|
|
|
|
|
|
To avoid this warning, replace interface names by the corresponding
|
|
|
|
network(s) in CIDR format (e.g., 192.168.144.0/24).
|
|
|
|
|
|
|
|
6) Previously, Shorewall has treated traffic shaping class IDs as
|
|
|
|
decimal numbers (or pairs of decimal numbers). That worked fine
|
|
|
|
until IPMARK was implemented. IPMARK requires Shorewall to generate
|
|
|
|
class Ids in numeric sequence. In 4.3.9, that didn't work correctly
|
|
|
|
because Shorewall was generating the sequence "..8,9,10,11..." when
|
|
|
|
the correct sequence was "...8,9,a,b,...". Shorewall now treats
|
|
|
|
class IDs as hex, as do 'tc' and 'iptables'.
|
|
|
|
|
|
|
|
This should only be an issue if you have more than 9 interfaces
|
|
|
|
defined in /etc/shorewall/tcdevices and if you use class IDs in
|
|
|
|
/etc/shorewall/tcrules or /etc/shorewall/tcfilters. You will need
|
|
|
|
to renumber the class IDs for devices 10 and greater.
|
|
|
|
|
|
|
|
7) Support for the 'norfc1918' interface and host option has been
|
|
|
|
removed. If 'norfc1918' is specified for an entry in either the
|
|
|
|
interfaces or the hosts file, a warning is issued and the option is
|
|
|
|
ignored. Simply remove the option to avoid the warning.
|
|
|
|
|
|
|
|
Similarly, if RFC1918_STRICT=Yes or a non-empty RFC1918_LOG_LEVEL
|
|
|
|
is given in shorewall.conf, a warning will be issued and the option
|
|
|
|
will be ignored.
|
|
|
|
|
|
|
|
You may simply delete the RFC1918-related options from your
|
|
|
|
shorewall.conf file if you are seeing warnings regarding them.
|
|
|
|
|
|
|
|
Users who currently use 'norfc1918' are encouraged to consider
|
|
|
|
using NULL_ROUTE_RFC1918=Yes instead.
|
|
|
|
|
|
|
|
8) The install.sh scripts in the Shorewall and Shorewall6 packages no
|
|
|
|
longer create a backup copy of the existing configuration. If you
|
|
|
|
want your configuration backed up prior to upgrading, you will
|
|
|
|
need to do that yourself.
|
|
|
|
|
|
|
|
As part of this change, the fallback.sh scripts are no longer
|
|
|
|
released.
|
|
|
|
|
|
|
|
9) In earlier releases, if an ipsec zone was defined as a sub-zone of
|
|
|
|
an ipv4 or ipv6 zone using the special <child>:<parent>,... syntax,
|
|
|
|
CONTINUE policies for the sub-zone did not work as
|
|
|
|
expected. Traffic that was not matched by a sub-zone rule was not
|
|
|
|
compared against the parent zone(s) rules.
|
|
|
|
|
|
|
|
In 4.4.0, such traffic IS compared against the parent zone rules.
|
|
|
|
|
|
|
|
10) The name 'any' is now reserved and may not be used as a zone name.
|
|
|
|
|
|
|
|
11) Perl module initialization has changed in Shorewall
|
|
|
|
4.4.1. Previously, each Shorewall Perl package would initialize its
|
|
|
|
global variables for IPv4 in an INIT block. Then, if the
|
|
|
|
compilation turned out to be for IPv6,
|
|
|
|
Shorewall::Compiler::compiler() would reinitialize them for IPv6.
|
|
|
|
|
|
|
|
Beginning in Shorewall 4.4.1, the modules do not initialize
|
|
|
|
themselves in an INIT block. So if you use Shorewall modules
|
|
|
|
outside of the Shorewall compilation environment, then you must
|
|
|
|
explicitly call the module's 'initialize' function after the module
|
|
|
|
has been loaded.
|
|
|
|
|
|
|
|
12) Checking for zone membership has been tighened up. Previously,
|
|
|
|
a zone could contain <interface>:0.0.0.0/0 along with other hosts;
|
|
|
|
now, if the zone has <interface>:0.0.0.0/0 (even with exclusions),
|
|
|
|
then it may have no additional members in /etc/shorewall/hosts.
|
|
|
|
|
2010-02-02 17:16:41 +01:00
|
|
|
13) ADD_IP_ALIASES=No is now the setting in the released shorewall.conf
|
|
|
|
and in all of the samples. This will not affect you during upgrade
|
|
|
|
unless you choose to replace your current shorewall.conf with the
|
|
|
|
one from the release (not recommended).
|
|
|
|
|
2010-02-25 21:18:41 +01:00
|
|
|
14) The names of interface configuration variables in generated scripts
|
|
|
|
have been changed to insure uniqueness. These names now begin with
|
|
|
|
SW_.
|
|
|
|
|
|
|
|
This change will only affect you if your extension scripts are
|
|
|
|
using one or more of these variables.
|
|
|
|
|
|
|
|
Old Variable Name New Variable Name
|
|
|
|
-----------------------------------------------------
|
|
|
|
iface_ADDRESS SW_iface_ADDRESS
|
|
|
|
iface_BCASTS SW_iface_BCASTS
|
|
|
|
iface_ACASTS SW_iface_ACASTS
|
|
|
|
iface_GATEWAY SW_iface_GATEWAY
|
|
|
|
iface_ADDRESSES SW_iface_ADDRESSES
|
|
|
|
iface_NETWORKS SW_iface_NETWORKS
|
|
|
|
iface_MAC SW_iface_MAC
|
|
|
|
|
2010-02-26 01:35:19 +01:00
|
|
|
provider_IS_USABLE SW_provider_IS_USABLE
|
2010-02-25 21:18:41 +01:00
|
|
|
|
2010-02-25 21:37:22 +01:00
|
|
|
where 'iface' is a capitalized interface name (e.g., ETH0) and
|
2010-02-25 21:18:41 +01:00
|
|
|
'provider' is the capitalized name of a provider.
|
|
|
|
|
2010-02-12 00:46:57 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-02-24 02:00:26 +01:00
|
|
|
I I I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
|
2010-02-12 00:46:57 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
2010-05-18 23:42:39 +02:00
|
|
|
1) Startup Errors (those that are detected before the state of the
|
|
|
|
system has been altered), were previously not sent to the
|
|
|
|
STARTUP_LOG.
|
|
|
|
|
|
|
|
2) A regression of sorts occurred in Shorewall 4.4.9. Previously, a
|
|
|
|
Perl extension script could end with a call to add_rule(). Such a
|
2010-05-31 17:05:33 +02:00
|
|
|
script fails under Shorewall 4.4.9 unless the 'trace' option is
|
2010-05-18 23:42:39 +02:00
|
|
|
specified on the run line.
|
|
|
|
|
|
|
|
While this issue has been corrected, users are advised to always
|
|
|
|
end their Perl extension scripts with the following line to insure
|
|
|
|
that the script returns a 'true' value:
|
|
|
|
|
2010-05-29 18:13:52 +02:00
|
|
|
1;
|
|
|
|
|
|
|
|
3) Under rare circumstances involving a complex configuration,
|
|
|
|
OPTIMIZE=13 and OPTIMIZE=15 could cause invalid iptables-restore
|
|
|
|
input to be generated.
|
|
|
|
|
|
|
|
Sample error message:
|
|
|
|
|
|
|
|
iptables-restore v1.4.8: Couldn't load target
|
|
|
|
`sys2sys':/usr/local/libexec/xtables/libipt_sys2sys.so:
|
|
|
|
cannot open shared object file: No such file or directory
|
2010-05-18 23:42:39 +02:00
|
|
|
|
2010-06-04 16:18:55 +02:00
|
|
|
4) Previously, if the 'optional' option was given to an interface with
|
|
|
|
a wildcard physical name, specific instances of the interface were
|
|
|
|
never considered usable.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
|
|
net ppp+ - optional
|
|
|
|
|
|
|
|
/etc/shorewall/providers:
|
|
|
|
|
|
|
|
#PROVIDER NUMBER MARK DUPLICATE INTERFACE ...
|
|
|
|
XYZTEL 1 - main ppp0
|
|
|
|
|
|
|
|
The XYZTEL provider was never usable.
|
|
|
|
|
2010-06-04 17:46:29 +02:00
|
|
|
This configuration now works correctly.
|
2010-06-04 16:18:55 +02:00
|
|
|
|
2010-06-07 22:21:59 +02:00
|
|
|
5) The 'forget' command now correctly removes saved ipsets.
|
|
|
|
|
2010-05-18 23:42:39 +02:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
I V. K N O W N P R O B L E M S R E M A I N I N G
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
None.
|
|
|
|
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
V. N E W F E A T U R E S I N T H I S R E L E A S E
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
|
|
|
1) Shorewall 4.4.10 includes a new 'Shorewall Init' package. This new
|
|
|
|
package provides two related features:
|
|
|
|
|
|
|
|
a) It allows the firewall to be closed prior to bringing up
|
|
|
|
network devices. This insures that unwanted connections are not
|
|
|
|
allowed between the time that the network comes up and when the
|
|
|
|
firewall is started.
|
|
|
|
|
|
|
|
b) It integrates with NetworkManager and distribution ifup/ifdown
|
|
|
|
systems to allow for 'event-driven' startup and shutdown.
|
|
|
|
|
|
|
|
The two facilities can be enabled separately.
|
|
|
|
|
|
|
|
When Shorewall-init is first installed, it does nothing until you
|
|
|
|
configure it.
|
|
|
|
|
|
|
|
The configuration file is /etc/default/shorewall-init on
|
|
|
|
Debian-based systems and /etc/sysconfig/shorewall-init otherwise.
|
|
|
|
|
|
|
|
There are two settings in the file:
|
|
|
|
|
|
|
|
PRODUCTS - lists the Shorewall packages that you want to
|
|
|
|
integrate with Shorewall-init. Example:
|
|
|
|
|
|
|
|
PRODUCTS="shorewall shorewall6"
|
|
|
|
|
|
|
|
IFUPDOWN When set to 1, enables integration with
|
|
|
|
NetworkManager and the ifup/ifdown scripts.
|
|
|
|
|
|
|
|
To close your firewall before networking starts:
|
|
|
|
|
|
|
|
a) in the Shorewall-init configuration file, set PRODUCTS to the
|
|
|
|
firewall products installed on your system.
|
|
|
|
|
|
|
|
b) be sure that your current firewall script(s) (normally in
|
|
|
|
/var/lib/<product>/firewall) is(are) compiled with the 4.4.10
|
|
|
|
compiler.
|
|
|
|
|
|
|
|
Shorewall and Shorewall6 users can execute these commands:
|
|
|
|
|
|
|
|
shorewall compile
|
|
|
|
shorewall6 compile
|
|
|
|
|
|
|
|
Shorewall-lite and Shorewall6-lite users can execute these
|
|
|
|
commands on the administrative system.
|
|
|
|
|
|
|
|
shorewall export <firewall-name-or-ip-address>
|
|
|
|
shorewall6 export <firewall-name-or-ip-address>
|
|
|
|
|
|
|
|
That's all that is required.
|
|
|
|
|
|
|
|
To integrate with NetworkManager and ifup/ifdown, additional steps
|
2010-05-18 23:55:16 +02:00
|
|
|
are required. You probably don't want to enable this feature if you
|
|
|
|
run a link status monitor like swping or LSM.
|
2010-05-18 23:42:39 +02:00
|
|
|
|
|
|
|
a) In the Shorewall-init configuration file, set IFUPDOWN=1.
|
|
|
|
|
|
|
|
b) In your Shorewall interfaces file(s), set the 'required' option
|
|
|
|
on any interfaces that must be up in order for the firewall to
|
2010-05-19 05:40:03 +02:00
|
|
|
start. At least one interface must have the 'required' or
|
2010-06-04 19:35:45 +02:00
|
|
|
'optional' option if you perform the next optional step. If
|
|
|
|
'required' is specified on an interface with a wildcard name
|
|
|
|
(the physical name ends with '+'), then at least one interface
|
|
|
|
that matches the name must be in a usable state for the
|
|
|
|
firewall to start successfully.
|
2010-05-18 23:42:39 +02:00
|
|
|
|
|
|
|
c) (Optional) -- If you have specified at least one 'required'
|
2010-05-19 05:40:03 +02:00
|
|
|
or 'optional interface, you can then disable automatic firewall
|
|
|
|
startup at boot time.
|
2010-05-18 23:42:39 +02:00
|
|
|
|
2010-05-21 02:06:53 +02:00
|
|
|
On Debian-based systems, set startup=0 in /etc/default/<product>.
|
2010-05-18 23:42:39 +02:00
|
|
|
|
|
|
|
On other systems, use your service startup configuration tool
|
|
|
|
(chkconfig, insserv, ...) to disable startup.
|
|
|
|
|
|
|
|
The following actions occur when an interface comes up:
|
|
|
|
|
|
|
|
FIREWALL INTERFACE ACTION
|
2010-05-19 05:29:03 +02:00
|
|
|
STATE
|
2010-05-18 23:42:39 +02:00
|
|
|
----------------------------------
|
2010-05-19 05:29:03 +02:00
|
|
|
Any Required start
|
|
|
|
stopped Optional start
|
|
|
|
started - restart
|
2010-05-18 23:42:39 +02:00
|
|
|
|
|
|
|
The following actions occur when an interface goes down:
|
|
|
|
|
|
|
|
In the INTERFACE column, '-' indicates neither required nor
|
|
|
|
optional
|
|
|
|
|
|
|
|
FIREWALL INTERFACE ACTION
|
2010-05-19 05:29:03 +02:00
|
|
|
STATE
|
2010-05-18 23:42:39 +02:00
|
|
|
----------------------------------
|
2010-05-19 05:29:03 +02:00
|
|
|
Any Required stop
|
|
|
|
stopped Optional start
|
|
|
|
started - restart
|
2010-05-18 23:42:39 +02:00
|
|
|
|
|
|
|
For optional interfaces, the /var/lib/<product>/<interface>.state
|
|
|
|
files are maintained to reflect the state of the interface.
|
|
|
|
|
2010-05-19 00:30:53 +02:00
|
|
|
Please note that the action is carried out using the current
|
|
|
|
compiled script; the configuration is not recompiled.
|
|
|
|
|
2010-05-19 16:32:02 +02:00
|
|
|
A new option has been added to shorewall.conf and
|
|
|
|
shorewall6.conf. The REQUIRE_INTERFACE option determines the
|
|
|
|
outcome when an attempt to start/restart/restore/refresh the
|
|
|
|
firewall is made and none of the optional interfaces are available.
|
|
|
|
With REQUIRE_INTERFACE=No (the default), the operation is
|
|
|
|
performed. If REQUIRE_INTERFACE=Yes, then the operation fails and
|
|
|
|
the firewall is placed in the stopped state. This option is
|
|
|
|
suitable for a laptop with both ethernet and wireless
|
|
|
|
interfaces. If either come up, the firewall starts. If neither
|
|
|
|
comes up, the firewall remains in the stopped state. Similarly, if
|
|
|
|
an optional interface goes down and there are no optional
|
|
|
|
interfaces remaining in the up state, then the firewall is stopped.
|
|
|
|
|
2010-05-20 15:32:34 +02:00
|
|
|
Shorewall-init may be installed on Debian-based systems, SuSE-based
|
2010-05-27 15:49:49 +02:00
|
|
|
systems and RedHat-based systems.
|
2010-05-20 15:32:34 +02:00
|
|
|
|
2010-05-25 16:16:02 +02:00
|
|
|
On Debian-based systems, during system shutdown the firewall is
|
|
|
|
opened prior to network shutdown (/etc/init.d/shorewall stop
|
|
|
|
performs a 'clear' operation rather than a 'stop'). This is
|
|
|
|
required by Debian standards. You can change this default behavior
|
|
|
|
by setting SAFESTOP=1 in /etc/default/shorewall
|
|
|
|
(/etc/default/shorewall6, ...).
|
|
|
|
|
2010-05-31 17:05:33 +02:00
|
|
|
2) All of the CLIs now support the -a option of the 'version' command.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
gateway:~# shorewall6 version -a
|
|
|
|
4.4.10-RC1
|
|
|
|
shorewall: 4.4.10-RC1
|
|
|
|
shorewall-lite: 4.4.10-RC1
|
|
|
|
shorewall6-lite: 4.4.10-RC1
|
|
|
|
shorewall-init: 4.4.10-RC1
|
|
|
|
gateway:~#
|
|
|
|
|
2010-06-07 22:21:59 +02:00
|
|
|
3) Beginning with this release, the 'restart' command now retains the
|
2010-06-07 23:44:55 +02:00
|
|
|
contents of the dynamic blacklist as well as the current UPnP rules.
|
|
|
|
The dynamic blacklist is also preserved over stop/start.
|
2010-06-07 22:21:59 +02:00
|
|
|
|
2010-05-18 23:42:39 +02:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
V I. P R O B L E M S C O R R E C T E D A N D N E W F E A T U R E S
|
|
|
|
I N P R I O R R E L E A S E S
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 9
|
|
|
|
----------------------------------------------------------------------------
|
2010-03-25 20:13:52 +01:00
|
|
|
1) Logical interface names in the EXTERNAL column of
|
|
|
|
/etc/shorewall/proxyarp were previously not mapped to their
|
|
|
|
corresponding physical interface names. This could cause 'start' or
|
|
|
|
'restart' to fail.
|
2010-03-20 15:06:47 +01:00
|
|
|
|
2010-04-07 23:43:50 +02:00
|
|
|
2) If find_first_interface_address() was unable to detect an address,
|
|
|
|
then Shorewall 4.4.8 would issue an obscure message
|
|
|
|
(startup_error: command not found) and continue.
|
|
|
|
|
|
|
|
Now, a meaningful error message is produced and the calling process
|
|
|
|
stops.
|
|
|
|
|
|
|
|
3) If LOG_VERBOSITY=0 in shorewall.conf, then when the compiled script
|
|
|
|
was executed, messages such as the following would be issued:
|
|
|
|
|
|
|
|
/var/lib/shorewall6/.restart: line 65: [: -gt: unary operator
|
|
|
|
expected
|
|
|
|
|
2010-04-09 16:32:21 +02:00
|
|
|
4) With optimize 4, if an unnecessary NONAT rule was included in
|
|
|
|
/etc/shorewall/rules (there was no DNAT or REDIRECT rule with the
|
2010-04-08 22:14:51 +02:00
|
|
|
same source zone), then 'shorewall start' and/or 'shorewall restart'
|
2010-04-09 16:32:21 +02:00
|
|
|
could fail with invalid iptables-restore input.
|
|
|
|
|
|
|
|
5) The tarball installers now check for the presence of the CLI
|
|
|
|
program (/sbin/shorewall, /sbin/shorewall6, etc) to determine if a
|
|
|
|
fresh install or an upgrade should be performed. Previously, the
|
|
|
|
installers used the presense of the configuration directory
|
|
|
|
(/etc/shorewall, /etc/shorewall6, etc.) which led to incomplete
|
|
|
|
installations where there was an existing configuration directory.
|
2010-04-08 05:18:56 +02:00
|
|
|
|
2010-04-09 16:43:36 +02:00
|
|
|
6) The fallback.sh scripts have been removed from Shorewall-lite,
|
|
|
|
Shorewall6, and Shorewall6-lite. These scripts no longer work and
|
|
|
|
should have been removed in 4.4.0.
|
|
|
|
|
2010-04-10 20:54:54 +02:00
|
|
|
7) The -lite products previously were inconsistent in how they
|
|
|
|
referred to their startup log. Some references included '-lite'
|
|
|
|
where some did not. This was particularly bad in the case of the
|
|
|
|
Shorewall-lite logrotate file which duplicated the name used by the
|
|
|
|
Shorewall package. This inconsistency could cause logrotate to
|
|
|
|
fail if both packages were installed.
|
|
|
|
|
2010-04-15 21:44:37 +02:00
|
|
|
8) Two additional problems with optimize 4 have been corrected. One
|
|
|
|
manifested as invalid iptables-restore input involving the 'tcpre'
|
|
|
|
mangle chain. The other involved wildcard interface names (those
|
|
|
|
ending in '+') and would likely also result in invalid
|
|
|
|
iptables-restore input.
|
|
|
|
|
2010-04-16 21:29:51 +02:00
|
|
|
9) Previously, Shorewall would set up infrastructure to handle traffic
|
|
|
|
from the firewall to bport zones. Such infrastructure could never
|
|
|
|
be used. Now, Shorewall avoids setting up these unneeded chains
|
|
|
|
and/or rules.
|
|
|
|
|
2010-04-22 20:55:13 +02:00
|
|
|
10) If optimization level 2 and there were no OUTPUT rules and the only
|
|
|
|
effective output policy was $FW->all ACCEPT, then the OUTPUT chain
|
|
|
|
was empty and no packets could be sent.
|
|
|
|
|
2010-04-23 21:18:51 +02:00
|
|
|
11) If find_first_interface_address() was called in the params file, a
|
|
|
|
fatal error occured on start/restart.
|
|
|
|
|
2010-04-27 01:32:53 +02:00
|
|
|
12) The following valid configuration produced invalid
|
2010-04-29 20:21:31 +02:00
|
|
|
iptables-restore input with optimization level 4.
|
2010-04-27 01:32:53 +02:00
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
2010-04-28 17:09:10 +02:00
|
|
|
vpn tun+ -
|
|
|
|
|
|
|
|
/etc/shorewall/masq:
|
2010-04-27 01:32:53 +02:00
|
|
|
|
2010-04-28 17:09:10 +02:00
|
|
|
#INTERFACE SOURCE ADDRESS PROTO PORT
|
|
|
|
tun0 192.168.1.0/24
|
2010-04-27 01:32:53 +02:00
|
|
|
|
2010-04-28 17:09:10 +02:00
|
|
|
Use of tunN in the nat and netmap files also produced invalid
|
|
|
|
iptables-restore input.
|
2010-04-27 01:32:53 +02:00
|
|
|
|
2010-05-29 17:59:45 +02:00
|
|
|
2) '/sbin/shorewall version -a' now shows the versions of all installed
|
|
|
|
Shorewall packages.
|
|
|
|
|
2010-03-20 15:06:47 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-05-18 23:42:39 +02:00
|
|
|
N E W F E A T U R E S I N 4 . 4 . 9
|
2010-03-20 15:06:47 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
2010-03-23 16:58:44 +01:00
|
|
|
1) The compiler now auto-detects bridges for the purpose of setting
|
|
|
|
the 'routeback' option. Auto-detection is disabled when compiling
|
|
|
|
for export (-e option); note that -e is implicit in the 'load' and
|
|
|
|
'reload' commands.
|
2010-03-20 15:06:47 +01:00
|
|
|
|
2010-03-29 00:31:05 +02:00
|
|
|
2) When 'trace' is specified on a command that involves the compiler
|
|
|
|
(e.g., shorewall trace check), the compiler now creates a trace to
|
|
|
|
standard output.
|
2010-03-28 23:37:22 +02:00
|
|
|
|
|
|
|
Trace entries are of three types:
|
|
|
|
|
|
|
|
Input --- begin with IN===>. Input read from configuration
|
2010-03-29 16:23:17 +02:00
|
|
|
files. Comments have been
|
2010-03-29 18:50:42 +02:00
|
|
|
stripped, continuation lines
|
|
|
|
combined and shell variables
|
|
|
|
expanded.
|
2010-03-28 23:37:22 +02:00
|
|
|
|
2010-03-29 18:50:42 +02:00
|
|
|
Output --- begin with GS----->. Text written to the generated
|
2010-03-28 23:37:22 +02:00
|
|
|
script.
|
|
|
|
|
2010-03-29 16:23:17 +02:00
|
|
|
Netfilter -- begin with NF-(x)->. Updates to the compiler's chain
|
|
|
|
table, where 'x' is one of the
|
|
|
|
following:
|
|
|
|
|
2010-03-30 16:23:17 +02:00
|
|
|
N - Create a chain.
|
|
|
|
A - Append a rule to a chain.
|
|
|
|
R - Replace a rule in a chain.
|
|
|
|
I - Inserted a rule into a chain.
|
|
|
|
T - Shell source text appended/inserted into a chain --
|
|
|
|
converted into rules at run-time.
|
2010-04-09 18:38:03 +02:00
|
|
|
D - Deleted Rule from a chain; note that this causes the
|
|
|
|
following rules to be renumbered.
|
2010-03-30 16:23:17 +02:00
|
|
|
X - Deleted a chain
|
2010-04-22 22:38:38 +02:00
|
|
|
P - Change a built-in chains policy. Chains in the filter table
|
|
|
|
are created with a DROP policy. All other builtin chains
|
|
|
|
have policy ACCEPT.
|
2010-04-30 23:58:07 +02:00
|
|
|
! Followed by one or more of the following to indicate that
|
|
|
|
the operation is not allowed on the chain.
|
|
|
|
|
|
|
|
O - Optimize
|
|
|
|
D - Delete
|
|
|
|
M - Move rules
|
2010-03-30 16:23:17 +02:00
|
|
|
|
|
|
|
Netfilter trace records indicate the table and chain being
|
|
|
|
changed. If the change involves a particular rule, then the rule
|
|
|
|
number is also included.
|
|
|
|
|
|
|
|
Example (append the first rule to the filter FORWARD chain):
|
|
|
|
|
2010-04-09 18:38:03 +02:00
|
|
|
NF-(A)-> filter:FORWARD:1 ...
|
2010-03-30 16:23:17 +02:00
|
|
|
|
|
|
|
If the trace record involves the chain itself, then no rule number
|
|
|
|
is present.
|
|
|
|
|
|
|
|
Example (Delete the mangle tcpost chain):
|
|
|
|
|
|
|
|
NF-(X)-> mangle:tcpost
|
|
|
|
|
2010-04-15 02:12:25 +02:00
|
|
|
3) Thanks to Vincent Smeets, there is now an IPv6 mDNS macro.
|
|
|
|
|
|
|
|
4) Optimize 8 has been added. This optimization level eliminates
|
2010-04-16 18:17:12 +02:00
|
|
|
duplicate chains. So to set all possible optimizations, specify
|
|
|
|
OPTIMIZE=15.
|
2010-04-04 00:57:50 +02:00
|
|
|
|
2010-04-19 22:02:21 +02:00
|
|
|
5) The command-line tools now support 'show log <regex>' where <regex>
|
|
|
|
is a regular expression to search for in the LOGFILE. The command
|
|
|
|
searches the current LOGFILE for Netfilter messages matching the
|
|
|
|
supplied regex.
|
2010-04-19 19:20:28 +02:00
|
|
|
|
2010-04-27 21:26:58 +02:00
|
|
|
6) There are some instances where a bridge with no IP address is
|
|
|
|
configured. Prior to Shorewall 4.4.9, this required the following:
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
|
|
dummy br0 - routeback
|
|
|
|
|
|
|
|
/etc/shorewall/policy:
|
|
|
|
#SOURCE DEST POLICY
|
2010-04-28 15:57:45 +02:00
|
|
|
dummy all DROP
|
|
|
|
all dummy DROP
|
2010-04-27 21:26:58 +02:00
|
|
|
|
|
|
|
Beginning in this release, a single entry will suffice:
|
|
|
|
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
2010-04-28 00:23:38 +02:00
|
|
|
- br0 - bridge
|
2010-04-27 21:26:58 +02:00
|
|
|
|
2010-04-28 17:09:10 +02:00
|
|
|
7) The generated ruleset now uses conntrack match for state matching,
|
|
|
|
if it is available.
|
2010-04-27 21:26:58 +02:00
|
|
|
|
2010-05-03 21:31:11 +02:00
|
|
|
8) In /etc/shorewall/routestopped, the 'routeback' option is assumed
|
|
|
|
if the interface has 'routeback' specified (either explicitly or
|
|
|
|
detected).
|
|
|
|
|
2010-05-06 17:17:17 +02:00
|
|
|
9) Apple Macs running OS X may now be used as a Shorewall
|
|
|
|
administrative system. Simply install using the tarball installer.
|
|
|
|
|
2010-03-20 15:06:47 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-05-18 23:42:39 +02:00
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 9
|
2010-03-20 15:06:47 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
2010-02-18 16:12:36 +01:00
|
|
|
1) A CONTINUE rule specifying a log level would cause the compiler to
|
2010-02-17 15:49:13 +01:00
|
|
|
generate an incorrect rule sequence. The packet would be logged
|
|
|
|
but the CONTINUE action would not occur.
|
|
|
|
|
2010-02-18 16:12:36 +01:00
|
|
|
2) If multiple entries were present in /etc/shorewall/tcdevices and
|
|
|
|
globally unique class numbers were not explicitly specified in
|
|
|
|
/etc/shorewall/tcclasses, then 'shorewall start' would fail with a
|
2010-02-17 15:49:13 +01:00
|
|
|
diagnostic such as:
|
|
|
|
|
|
|
|
Setting up Traffic Control...
|
|
|
|
RTNETLINK answers: File exists
|
|
|
|
ERROR: Command "tc qdisc add dev eth1 parent 2:2 handle 2: sfq quantum
|
|
|
|
1500 limit 127 perturb 10" Failed
|
|
|
|
Processing /etc/shorewall/stop ...
|
|
|
|
|
2010-02-18 16:12:36 +01:00
|
|
|
3) Previously, when a low per-IP rate limit (such as 1/hour) was
|
|
|
|
specified, the effective enforced rate was much higher
|
|
|
|
(approximately 6/min). The Shorewall compiler now configures the
|
|
|
|
hashlimit table idle timeout based on the rate units (min, hour,
|
|
|
|
...) so that the rate is more accurately enforced.
|
2010-02-18 00:41:12 +01:00
|
|
|
|
|
|
|
As part of this change, a unique hash table name is assigned to
|
2010-02-18 16:12:36 +01:00
|
|
|
each per-IP rate limiting rule that does not specify a table name
|
|
|
|
in the rule. The assigned names are of the form 'shorewallN' where
|
|
|
|
N is an integer. Previously, all such rules shared a single
|
|
|
|
'shorewall' table which lead to unexpected results.
|
|
|
|
|
2010-02-20 17:34:47 +01:00
|
|
|
4) All versions of Shorewall-perl mishandle per-IP rate limiting in
|
|
|
|
REDIRECT, DNAT and ACCEPT+ rules. The effective rate and burst are
|
|
|
|
1/2 of the values given in the rule.
|
|
|
|
|
|
|
|
5) Detection of the 'Old hashlimit match' capability was broken in
|
|
|
|
/sbin/shorewall, /sbin/shorewall-lite and in the IPv4 version of
|
|
|
|
shorecap.
|
|
|
|
|
|
|
|
6) On older distributions such as RHEL5 and derivatives, Shorewall
|
|
|
|
would fail to start if a TYPE was specified in
|
|
|
|
/etc/shorewall/tcinterfaces and LOAD_HELPERS_ONLY had been
|
|
|
|
specified in /etc/shorewall/shorewall.conf.
|
|
|
|
|
|
|
|
7) The Debian init scripts are modified to include $remote_fs in the
|
|
|
|
Required-start and Required-stop specifications.
|
|
|
|
|
|
|
|
8) Previously, when a supported command failed, the Debian Shorewall
|
|
|
|
init script would still return a success (zero) exit status. It now
|
|
|
|
returns a failure status (1) when the command fails.
|
2010-02-18 00:41:12 +01:00
|
|
|
|
2010-02-25 17:44:28 +01:00
|
|
|
9) Previously, if a queue number was specified in an NFQUEUE policy
|
|
|
|
(e.g., NFQUEUE(0)), invalid iptables-restore input would be
|
|
|
|
generated.
|
|
|
|
|
2010-03-01 17:40:20 +01:00
|
|
|
10) Previously, with optimization 4, users of ipsec on older releases
|
|
|
|
such as RHEL5 and CentOS, could encounter an error similar to this
|
|
|
|
one:
|
|
|
|
|
|
|
|
Running /sbin/iptables-restore...
|
|
|
|
iptables-restore v1.3.5: Unknown arg `out'
|
|
|
|
Error occurred at line: 93
|
|
|
|
Try `iptables-restore -h' or 'iptables-restore --help' for more
|
|
|
|
information.
|
|
|
|
ERROR: iptables-restore Failed. Input is in
|
|
|
|
/var/lib/shorewall/.iptables-restore-input
|
|
|
|
|
2010-03-22 14:46:48 +01:00
|
|
|
11) Previously, with optimization 4, the 'blacklst' chain could be
|
|
|
|
optimized away. If the blacklist file was then changed and a
|
|
|
|
'shorewall refresh' executed, those new changes would not be included
|
|
|
|
in the active ruleset.
|
|
|
|
|
2010-03-25 18:14:39 +01:00
|
|
|
12) In 4.4.7, it was documented that setting the 'bridge' option in an
|
|
|
|
interfaces file entry also set 'routeback'. That feature was
|
|
|
|
incomplete with the result that 'routeback' still needed to be
|
|
|
|
specified.
|
|
|
|
|
2010-02-12 00:46:57 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-03-20 15:06:47 +01:00
|
|
|
N E W F E A T U R E S I N 4 . 4 . 8
|
2010-02-12 00:46:57 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
2010-02-25 21:18:41 +01:00
|
|
|
1) To avoid variable name collisions, a number of shell variable names
|
|
|
|
that Shorewall uses and that are in all capital letters have been
|
|
|
|
changed. The following variables are now safe to use in your
|
|
|
|
/etc/shorewall/params file and in your extension scripts:
|
|
|
|
|
|
|
|
DEBUG
|
|
|
|
ECHO_E
|
|
|
|
ECHO_N
|
|
|
|
EXPORT
|
|
|
|
FAST
|
2010-03-03 19:28:09 +01:00
|
|
|
HOSTNAME
|
2010-02-25 21:18:41 +01:00
|
|
|
IPT_OPTIONS
|
2010-03-03 19:28:09 +01:00
|
|
|
NOROUTES
|
|
|
|
PREVIEW
|
|
|
|
PRODUCT
|
2010-02-25 21:18:41 +01:00
|
|
|
PROFILE
|
|
|
|
PURGE
|
2010-03-03 19:28:09 +01:00
|
|
|
RECOVERING
|
2010-02-26 17:35:50 +01:00
|
|
|
RESTOREPATH
|
2010-02-25 21:18:41 +01:00
|
|
|
RING_BELL
|
2010-03-03 19:28:09 +01:00
|
|
|
STOPPING
|
2010-02-25 21:18:41 +01:00
|
|
|
TEST
|
2010-03-03 19:28:09 +01:00
|
|
|
TIMESTAMP
|
2010-02-25 21:18:41 +01:00
|
|
|
USE_VERBOSITY
|
2010-03-01 02:58:01 +01:00
|
|
|
VERBOSE
|
2010-02-25 21:18:41 +01:00
|
|
|
VERBOSE_OFFSET
|
2010-03-03 19:28:09 +01:00
|
|
|
VERSION
|
2010-02-25 21:18:41 +01:00
|
|
|
|
|
|
|
See Migration Issue 14 above for additional information.
|
2010-02-12 00:46:57 +01:00
|
|
|
|
2010-02-27 20:48:39 +01:00
|
|
|
2) The Shorewall and Shorewall6 installers now accept a '-s' (sparse)
|
|
|
|
option. That option causes only shorewall.conf to be installed in
|
2010-02-28 16:37:16 +01:00
|
|
|
/etc/shorewall/.
|
2010-02-27 20:48:39 +01:00
|
|
|
|
2010-02-28 16:37:16 +01:00
|
|
|
3) An OpenPGP HTTP Keyserver Protocol (HKP) macro (macro.HKP) has been
|
|
|
|
contributed.
|
2010-03-07 17:36:26 +01:00
|
|
|
|
|
|
|
4) In an attempt to help those who don't read the documentation, the
|
|
|
|
compiler now flags apparent use of '-' as a port range separator
|
|
|
|
with an error message.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
/etc/shorewall/rules
|
|
|
|
|
|
|
|
#ACTION SOURCE DEST PROTO DEST
|
|
|
|
# PORT(S)
|
2010-03-07 17:39:09 +01:00
|
|
|
ACCEPT net fw tcp 21-22
|
2010-03-07 17:36:26 +01:00
|
|
|
|
|
|
|
Resulting error message
|
|
|
|
|
2010-03-07 17:39:09 +01:00
|
|
|
ERROR: The separator for a port range is ':', not '-' (21-22) :
|
2010-03-07 17:36:26 +01:00
|
|
|
/etc/shorewall/rules (line 3)
|
2010-03-16 17:42:50 +01:00
|
|
|
|
|
|
|
5) Support has been added for UDPLITE (proto 136) in that DEST PORT(S)
|
2010-03-16 20:39:35 +01:00
|
|
|
and SOURCE PORT(S) may now be specified for that protocol.
|
2010-03-17 18:10:56 +01:00
|
|
|
|
|
|
|
6) If a runtime error occurs during a 'start' or 'restart' operation
|
|
|
|
but a saved configuration is successfully restored, a subsequent
|
|
|
|
'status' command now gives the detailed status as 'Restored from
|
|
|
|
<filename>' rather than 'Started'; <filename> is the saved script
|
|
|
|
used to restore the configuration.
|
2010-02-28 16:37:16 +01:00
|
|
|
|
2009-11-23 20:15:33 +01:00
|
|
|
----------------------------------------------------------------------------
|
2010-03-17 18:10:56 +01:00
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 7
|
2009-11-23 20:15:33 +01:00
|
|
|
----------------------------------------------------------------------------
|
2009-03-16 19:01:42 +01:00
|
|
|
|
2010-01-22 19:35:27 +01:00
|
|
|
1) The tcinterfaces and tcpri files are now installed by the
|
|
|
|
installer and are included in the rpm.
|
|
|
|
|
|
|
|
2) An invalid octal number (e.g., 080) appearing in a port list
|
|
|
|
resulted in a perl error message.
|
|
|
|
|
|
|
|
As part of this fix, both hex and octal numbers are now accepted
|
|
|
|
for protocol and port numbers.
|
2010-01-13 22:24:24 +01:00
|
|
|
|
2010-02-02 01:22:57 +01:00
|
|
|
3) In 4.4.6, if a system:
|
|
|
|
|
|
|
|
a) Had mangle table support.
|
|
|
|
b) Had a FORWARD chain in the mangle table.
|
|
|
|
c) Did not have MARK Target support.
|
|
|
|
|
|
|
|
then 'shorewall start' would fail.
|
|
|
|
|
2010-02-04 00:03:15 +01:00
|
|
|
4) Previously, the 'nosmurfs' option was ignored in IPv6
|
|
|
|
compilations. As part of this fix, 'nosmurfs' handling when
|
|
|
|
SMURF_LOG_LEVEL is specified has been improved for both IPv4 and
|
|
|
|
IPv6.
|
|
|
|
|
2010-02-08 19:03:10 +01:00
|
|
|
5) Previously, specifying a TYPE in /etc/shorewall/tcinterfaces would
|
|
|
|
cause start/restart to fail on systems lacking 'flow' classifier
|
2010-02-11 23:35:12 +01:00
|
|
|
support. In Shorewall 4.4.7, we detect the ability of the 'tc'
|
|
|
|
utility to support that classifier.
|
|
|
|
|
|
|
|
There are two caveats:
|
|
|
|
|
|
|
|
- 'tc' may support 'flow' but the kernel does not. In that case,
|
|
|
|
start/restart will still fail.
|
|
|
|
|
|
|
|
- If you use a capabilities file, you will need to regenerate the
|
|
|
|
file using shorewall-lite 4.4.7 in order for 'flow' to be
|
|
|
|
accurately detected. If you do not regenerate the file, the
|
|
|
|
compiler will use other hints to try to determine if 'flow' is
|
|
|
|
available.
|
2010-02-08 19:03:10 +01:00
|
|
|
|
2009-08-05 22:00:10 +02:00
|
|
|
----------------------------------------------------------------------------
|
2010-01-16 17:11:13 +01:00
|
|
|
N E W F E A T U R E S I N 4 . 4 . 7
|
2009-08-05 22:00:10 +02:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) The OPTIMIZE option value is now a bit-map with each bit
|
|
|
|
controlling a separate set of optimizations.
|
|
|
|
|
|
|
|
- The low-order bit (value 1) controls optimizations available in
|
|
|
|
earlier releases. We refer to this optimization as "optimization
|
|
|
|
1".
|
|
|
|
|
|
|
|
- The next bit (value 2) suppresses superfluous ACCEPT rules in a
|
|
|
|
policy chain that implements an ACCEPT policy. Any ACCEPT rules
|
|
|
|
that immediately preceed the final blanket ACCEPT rule in the
|
|
|
|
chain are now omitted. We refer to this optimization as
|
|
|
|
"optimization 2".
|
|
|
|
|
|
|
|
- The next bit (value 4 or "optimization 4") enables the following
|
|
|
|
additional optimizations:
|
|
|
|
|
|
|
|
a) Empty chains are optimized away.
|
|
|
|
b) Chains with one rule are optimized away.
|
|
|
|
c) If a built-in chain has a single rule that branches to a
|
|
|
|
second chain, then the rules from the second chain are moved
|
|
|
|
to the built-in chain and the target chain is omitted.
|
|
|
|
d) Chains with no references are deleted.
|
|
|
|
e) Accounting chains are subject to optimization if the new
|
|
|
|
OPTIMIZE_ACCOUNTING option is set to 'Yes' (default is 'No').
|
|
|
|
f) If a chain ends with an unconditional branch to a second chain
|
|
|
|
(other than to 'reject'), then the branch is deleted from the
|
|
|
|
first chain and the rules from the second chain are appended
|
|
|
|
to it.
|
|
|
|
|
|
|
|
The following chains are exempted from optimization 4:
|
|
|
|
|
|
|
|
action chains (user-created).
|
|
|
|
accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
|
|
|
|
dynamic
|
|
|
|
forwardUPnP
|
|
|
|
logdrop
|
|
|
|
logreject
|
|
|
|
rules chains (those of the form zonea2zoneb or zonea-zoneb).
|
|
|
|
UPnP (nat table).
|
|
|
|
|
|
|
|
To enable all possible optimizations, set OPTIMIZE to 7 (1 + 2 +
|
|
|
|
4).
|
|
|
|
|
|
|
|
2) Shorewall now combines identical logging chains. Previously, a
|
|
|
|
separate chain was created for each logging rule.
|
|
|
|
|
|
|
|
3) Beginning with Shorewall 4.4.7, accounting can be disabled by
|
|
|
|
setting ACCOUNTING=No in shorewall.conf. This allows you to keep a
|
|
|
|
set of accounting rules configured in /etc/shorewall/accounting and
|
|
|
|
to then enable and disable them by simply toggling the setting of
|
|
|
|
ACCOUNTING.
|
|
|
|
|
|
|
|
Similarly, dynamic blacklisting can be disabled by setting
|
|
|
|
DYNAMIC_BLACKLIST=No. This saves a jump rule in the INPUT
|
|
|
|
and FORWARD filter chains..
|
|
|
|
|
|
|
|
4) Shorewall can now automatically assign mark values to providers in
|
|
|
|
cases where 'track' is specified (or TRACK_PROVIDERS=Yes) but
|
|
|
|
packet marking is otherwise not used for directing connections to a
|
|
|
|
particular provider. Simply specify '-' in the MARK column and
|
|
|
|
Shorewall will automatically assign a mark value.
|
2010-01-13 19:59:34 +01:00
|
|
|
|
2010-01-17 17:20:15 +01:00
|
|
|
5) Support for TPROXY has been added. See
|
|
|
|
http://www.shorewall.net/Shorewall_Squid_Usage.html#TPROXY.
|
|
|
|
|
2010-01-22 05:17:25 +01:00
|
|
|
6) Traditionally, Shorewall has loaded all modules that could possibly
|
|
|
|
be needed twice; once in the compiler, and once when the generated
|
|
|
|
script is initialized. The latter can be a time-consuming process
|
|
|
|
on slow hardware.
|
|
|
|
|
|
|
|
Beginning with 4.4.7, there is a LOAD_HELPERS_ONLY option in
|
|
|
|
shorewall.conf. For existing users, LOAD_HELPERS_ONLY=No is the
|
|
|
|
default.
|
|
|
|
|
|
|
|
For new users that employ the sample configurations,
|
|
|
|
LOAD_HELPERS_ONLY=Yes will be the default. That setting causes only
|
|
|
|
a small subset of modules to be loaded; it is assumed that the
|
2010-01-25 19:50:49 +01:00
|
|
|
remaining modules will be autoloaded. Additionally, capability
|
|
|
|
detection in the compiler is deferred until each capability is
|
|
|
|
actually used. As a consequence, no modules are autoloaded
|
|
|
|
unnecessarily.
|
2010-01-22 05:17:25 +01:00
|
|
|
|
2010-01-31 05:31:39 +01:00
|
|
|
Modules loaded when LOAD_HELPERS_ONLY=Yes are the protocol
|
|
|
|
helpers. These cannot be autoloaded.
|
2010-01-22 05:17:25 +01:00
|
|
|
|
|
|
|
In addition, the nf_conntrack_sip module is loaded with
|
|
|
|
sip_direct_media=0. This setting is slightly less secure than
|
|
|
|
sip_direct_media=1, but it solves many VOIP problems that users
|
|
|
|
routinely encounter.
|
|
|
|
|
2009-08-15 17:15:38 +02:00
|
|
|
----------------------------------------------------------------------------
|
2010-01-16 20:32:50 +01:00
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 6
|
2009-08-15 17:15:38 +02:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) A 'feature' of xtables-addons when applied to Debian Lenny causes
|
|
|
|
extra /31 networks to appear for nethash sets in the output of
|
|
|
|
"ipset -L" and "ipset -S". A hack has been added to prevent these
|
|
|
|
from being saved when Shorewall is saving IPSETS during 'stop'.
|
2009-11-21 22:56:40 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
As part of this change, the generated script is more careful about
|
|
|
|
verifying the existence of the correct ipset utility before using
|
|
|
|
it to save the contents of the sets.
|
2009-11-21 22:56:40 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) The mDNS macro previously did not include IGMP (protocol 2) and it
|
|
|
|
did not specify the mDNS multicast address (224.0.0.251). These
|
|
|
|
omissions have been corrected.
|
2009-11-21 22:56:40 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
N E W F E A T U R E S I N 4 . 4 . 6
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-21 22:56:40 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) In kernel 2.6.31, the handling of the rp_filter interface option was
|
|
|
|
changed incompatibly. Previously, the effective value was determined
|
|
|
|
by the setting of net.ipv4.config.dev.rp_filter logically ANDed with
|
|
|
|
the setting of net.ipv4.config.all.rp_filter.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Beginning with kernel 2.6.31, the value is the arithmetic MAX of
|
|
|
|
those two values.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Given that Shorewall sets net.ipv4.config.all.rp_filter to 1 if
|
|
|
|
there are any interfaces specifying 'routefilter', specifying
|
|
|
|
'routefilter' on any interface has the effect of setting the option
|
|
|
|
on all interfaces.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To allow Shorewall to handle this issue, a number of changes were
|
|
|
|
necessary:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) There is no way to safely determine if a kernel supports the
|
|
|
|
new semantics or the old so the Shorewall compiler uses the
|
|
|
|
kernel version reported by uname.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
b) This means that the kernel version is now recorded in
|
|
|
|
the capabilities file. So if you use capabilities files, you
|
|
|
|
need to regenerate the files with Shorewall[-lite] 4.4.6 or
|
|
|
|
later.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
c) If the capabilities file does not contain a kernel version,
|
|
|
|
the compiler assumes version 2.6.30 (the old rp_filter
|
|
|
|
behavior).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
d) The ROUTE_FILTER option in shorewall.conf now accepts the
|
|
|
|
following values:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
0 or No - Shorewall sets net.ipv4.config.all.rp_filter to 0.
|
|
|
|
1 or Yes - Shorewall sets net.ipv4.config.all.rp_filter to 1.
|
|
|
|
2 - Shorewall sets net.ipv4.config.all.rp_filter to 2.
|
|
|
|
Keep - Shorewall does not change the setting of
|
|
|
|
net.ipv4.config.all.rp_filter if the kernel version
|
|
|
|
is 2.6.31 or later.
|
|
|
|
|
|
|
|
The default remains Keep.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
e) The 'routefilter' interface option can have values 0,1 or 2. If
|
|
|
|
'routefilter' is specified without a value, the value 1 is
|
|
|
|
assumed.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) SAVE_IPSETS=Yes has been resurrected but in a different form. With
|
|
|
|
this setting, the contents of your ipsets are saved during 'shorewall
|
|
|
|
stop' and 'shorewall save' and they are restored during 'shorewall
|
|
|
|
start' and 'shorewall restore'. Note that the contents may only be
|
|
|
|
restored during 'restore' if the firewall is currently in the
|
|
|
|
stopped state and there are no ipsets currently in use. In
|
|
|
|
particular, when 'restore' is being executed to recover from a
|
|
|
|
failed start/restart, the contents of the ipsets are not changed.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When SAVE_IPSETS=Yes, you may not include ipsets in your
|
|
|
|
/etc/shorewall/routestopped configuration.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) IPv6 addresses following a colon (":") may either be surrounded by
|
|
|
|
<..> or by the more standard [..].
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) A DHCPfwd macro has been added that allows unicast DHCP traffic to
|
|
|
|
be forwarded through the firewall. Courtesy of Tuomo Soini.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) Shorewall (/sbin/shorewall) now supports a 'show macro' command:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
shorewall show macro <macro>
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
shorewall show macro LDAP
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The command displays the contents of the macro.<macro> file.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
6) You may now preview the generated ruleset by using the '-r' option
|
|
|
|
to the 'check' command (e.g., "shorewall check -r").
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The output is a shell script fragment, similar to the way it
|
|
|
|
appears in the generated script.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
7) It is now possible to enable a simplified traffic shaping
|
|
|
|
facility by setting TC_ENABLED=Simple in shorewall.conf.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
See http://www.shorewall.net/simple_traffic_shaping.html for
|
|
|
|
details.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
8) Previously, when TC_EXPERT=No, packets arriving through 'tracked'
|
|
|
|
provider interfaces were unconditionally passed to the PREROUTING
|
|
|
|
tcrules. This was done so that tcrules could reset the packet mark
|
|
|
|
to zero, thus allowing the packet to be routed using the 'main'
|
|
|
|
routing table. Using the main table allowed dynamic routes (such as
|
|
|
|
those added for VPNs) to be effective.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The route_rules file was created to provide a better alternative
|
|
|
|
to clearing the packet mark. As a consequence, passing these
|
|
|
|
packets to PREROUTING complicates things without providing any real
|
|
|
|
benefit.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Beginning with this release, when TRACK_PROVIDERS=Yes and TC_EXPERT=No,
|
|
|
|
packets arriving through 'tracked' interfaces will not be passed to
|
|
|
|
the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in
|
|
|
|
4.4.3, this change should be transparent to most, if not all, users.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 5
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) The change which removed the 15 port limitation on
|
|
|
|
/etc/shorewall/routestopped was incomplete. The result was that if
|
|
|
|
more than 15 ports were listed, an error was generated.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) If any interfaces had the 'bridge' option specified, compilation
|
|
|
|
failed with the error:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Undefined subroutine &Shorewall::Rules::match_source_interface called
|
|
|
|
at /usr/share/shorewall/Shorewall/Rules.pm line 2319.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) The compiler now flags port number 0 as an error in all
|
|
|
|
contexts. Previously, port 0 was allowed with the result that
|
|
|
|
invalid iptables-restore input could be generated in some cases.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) The 'show policies' command now works in Shorewall6 and
|
|
|
|
Shorewall6-lite.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) Traffic shaping modules from /lib/modules/<version>/net/sched/ are
|
|
|
|
now correctly loaded. Previously, that directory was not
|
|
|
|
searched. Additionally, Shorewall6 now tries to load the cls_flow
|
|
|
|
module; previously, only Shorewall attempts to load that module.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
6) The Shorewall6-lite shorecap program was previously including the
|
|
|
|
IPv4 base library rather than the IPv6 version. Also, Shorewall6
|
|
|
|
capability detection was determing the availablity of the mangle
|
|
|
|
capability before it had determined if ip6tables was installed.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
7) The setting of MODULE_SUFFIX was previously ignored except when
|
|
|
|
compiling for export.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
8) Detection of the Enhanced Reject capability in the compiler was
|
|
|
|
broken for IPv4 compilations.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
9) The 'reload -c' command would ignore the setting of DONT_LOAD in
|
|
|
|
shorewall.conf. The 'reload' command without '-c' worked as
|
|
|
|
expected.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
N E W F E A T U R E S I N 4 . 4 . 5
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) Shorewall now allows DNAT rules that change only the destination
|
|
|
|
port.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
DNAT loc net::456 udp 234
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
That rule will modify the destination port in UDP packets received
|
|
|
|
from the 'loc' zone from 456 to 234. Note that if the destination
|
|
|
|
is the firewall itself, then the destination port will be rewritten
|
|
|
|
but that no ACCEPT rule from the loc zone to the $FW zone will have
|
|
|
|
been created to handle the request. So such rules should probably
|
|
|
|
exclude the firewall's IP addresses in the ORIGINAL DEST column.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) Systems that do not log Netfilter messages locally can now set
|
|
|
|
LOGFILE=/dev/null in shorewall.conf.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) The 'shorewall show connections' and 'shorewall dump' commands now
|
|
|
|
display the current number of connections and the max supported
|
|
|
|
connections.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
shorewall show connections
|
|
|
|
Shorewall 4.5.0 Connections (62 out of 65536) at gateway - Sat ...
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
In that case, there were 62 current connections out of a maximum
|
|
|
|
number supported of 65536.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 4
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) In some simple one-interface configurations, the following Perl
|
|
|
|
run-time error messages were issued:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Generating Rule Matrix...
|
|
|
|
Use of uninitialized value in concatenation (.) or string at
|
|
|
|
/usr/share/shorewall/Shorewall/Chains.pm line 649.
|
|
|
|
Use of uninitialized value in concatenation (.) or string at
|
|
|
|
/usr/share/shorewall/Shorewall/Chains.pm line 649.
|
|
|
|
Creating iptables-restore input...
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) The Shorewall operations log (specified by STARTUP_LOG) is now
|
|
|
|
secured 0600.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) Previously, the compiler generated an incorrect test for interface
|
|
|
|
availability in the generated code for adding route rules. The
|
|
|
|
result was that the rules were always added, regardless of the
|
|
|
|
state of the provider's interface. Now, the rules are only added
|
|
|
|
when the interface is available.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) When TC_WIDE_MARKS=Yes and class numbers are not explicitly
|
|
|
|
specified in /etc/shorewall/tcclasses, duplicate class numbers
|
|
|
|
result. A typical error message is:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
ERROR: Command "tc class add dev eth3 parent 1:1 classid
|
|
|
|
1:1 htb rate 1024kbit ceil 100000kbit prio 1 quantum 1500"
|
|
|
|
Failed
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Note that the class ID of the class being added is a duplicate of
|
|
|
|
the parent's class ID.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Also, when TC_WIDE_MARKS=Yes, values > 255 in the MARK column of
|
|
|
|
/etc/shorewall/tcclasses were rejected.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
N E W F E A T U R E S I N 4 . 4 . 4
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) The Shorewall packages now include a logrotate configuration file.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) The limit of 15 entries in a port list has been relaxed in
|
|
|
|
/etc/shorewall/routestopped.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) The following seemingly valid configuration produces a fatal
|
|
|
|
error reporting "Duplicate interface name (p+)"
|
2009-11-23 18:33:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shorewall/zones:
|
2009-11-23 18:33:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#ZONE TYPE
|
|
|
|
fw firewall
|
|
|
|
world ipv4
|
|
|
|
z1:world bport4
|
|
|
|
z2:world bport4
|
2009-11-23 18:33:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shorewall/interfaces:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
|
|
world br0 - bridge
|
|
|
|
world br1 - bridge
|
|
|
|
z1 br0:p+
|
|
|
|
z2 br1:p+
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
This error occurs because the Shorewall implementation requires
|
|
|
|
that each bridge port must have a unique name.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To work around this problem, a new 'physical' interface option has
|
|
|
|
been created. The above configuration may be defined using the
|
|
|
|
following in /etc/shorewall/interfaces:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
|
|
world br0 - bridge
|
|
|
|
world br1 - bridge
|
|
|
|
z1 br0:x+ - physical=p+
|
|
|
|
z2 br1:y+ - physical=p+
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
In this configuration, 'x+' is the logical name for ports p+ on
|
|
|
|
bridge br0 while 'y+' is the logical name for ports p+ on bridge
|
|
|
|
br1.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If you need to refer to a particular port on br1 (for example
|
|
|
|
p1023), you write it as y1023; Shorewall will translate that name
|
|
|
|
to p1023 when needed.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
It is allowed to have a physical name ending in '+' with a logical
|
|
|
|
name that does not end with '+'. The reverse is not allowed; if the
|
|
|
|
logical name ends in '+' then the physical name must also end in
|
|
|
|
'+'.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
This feature is not restricted to bridge ports. Beginning with this
|
|
|
|
release, the interface name in the INTERFACE column can be
|
|
|
|
considered a logical name for the interface, and the actual
|
|
|
|
interface name is specified using the 'physical' option. If no
|
|
|
|
'physical' option is present, then the physical name is assumed to
|
|
|
|
be the same as the logical name. As before, the logical interface
|
|
|
|
name is used throughout the rest of the configuration to refer to
|
|
|
|
the interface.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) Previously, Shorewall has used the character '2' to form the name
|
|
|
|
of chains involving zones and/or the word 'all' (e.g., fw2net,
|
|
|
|
all2all). When zones names are given numeric suffixes, these
|
|
|
|
generated names are hard to read (e.g., foo1232bar). To make these
|
|
|
|
names clearer, a ZONE2ZONE option has been added.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
ZONE2ZONE has a default value of "2" but can also be given the
|
|
|
|
value "-" (e.g., ZONE2ZONE="-") which causes Shorewall to separate
|
|
|
|
the two parts of the name with a hyphen (e.g., foo123-bar).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) Only one instance of the following warning is now generated;
|
|
|
|
previously, one instance of a similar warning was generated for
|
|
|
|
each COMMENT encountered.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
COMMENTs ignored -- require comment support in iptables/Netfilter
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
6) The shorewall and shorewall6 utilities now support a 'show
|
|
|
|
policies' command. Once Shorewall or Shorewall6 has been restarted
|
|
|
|
using a script generated by this version, the 'show policies'
|
|
|
|
command will list each pair of zones and give the applicable
|
|
|
|
policy. If the policy is enforced in a chain, the name of the chain
|
|
|
|
is given.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
net => loc DROP using chain net2all
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Note that implicit intrazone ACCEPT policies are not displayed for
|
|
|
|
zones associated with a single network where that network
|
|
|
|
doesn't specify 'routeback'.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
7) The 'show' and 'dump' commands now support an '-l' option which
|
|
|
|
causes chain displays to include the rule number of each rule.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
(Type 'iptables -h' and look for '--line-number')
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 3
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1. Previously, if 'routeback' was specified in /etc/shorewall/routestopped:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) 'shorewall check' produced an internal error
|
|
|
|
b) The 'routeback' option didn't work
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) If an alias IP address was added and RETAIN_ALIASES=No in
|
|
|
|
shorewall.conf, then a compiler internal error resulted.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) Previously, the generated script would try to detect the values
|
|
|
|
for all run-time variables (such as IP addresses), regardless of
|
|
|
|
what command was being executed. Now, this information is only
|
|
|
|
detected when it is needed.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) Nested zones where the parent zone was defined by a wildcard
|
|
|
|
interface (name ends with +) in /etc/shorewall/interfaces did
|
|
|
|
not work correctly in some cases.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) IPv4 addresses embedded in IPv6 (e.g., ::192.168.1.5) were
|
|
|
|
incorrectly reported as invalid.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
6) Under certain circumstances, optional providers were not detected
|
|
|
|
as being usable.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Additionally, the messages issued when an optional provider was not
|
|
|
|
usable were confusing; the message intended to be issued when the
|
|
|
|
provider shared an interface ("WARNING: Gateway <gateway> is not
|
|
|
|
reachable -- Provider <name> (<number>) not Added") was being
|
|
|
|
issued when the provider did not share an interface. Similarly, the
|
|
|
|
message intended to be issued when the provider did not share an
|
|
|
|
interface ("WARNING: Interface <interface> is not usable --
|
|
|
|
Provider <name> (<number>) not Added") was being issued when the
|
|
|
|
provider did share an interface.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
N E W F E A T U R E S I N 4 . 4 . 3
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) On Debian systems, a default installation will now set
|
|
|
|
INITLOG=/dev/null in /etc/default/shorewall. In all configurations,
|
|
|
|
the default values for the log variables are changed to:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
STARTUP_LOG=/var/log/shorewall-init.log
|
|
|
|
LOG_VERBOSITY=2
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The effect is much the same as the old defaults, with the exception
|
|
|
|
that:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) Start, stop, etc. commands issued through /sbin/shorewall
|
|
|
|
will be logged.
|
|
|
|
b) Logging will occur at maximum verbosity.
|
|
|
|
c) Log entries will be date/time stamped.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
On non-Debian systems, new installs will now log all Shorewall
|
|
|
|
commands to /var/log/shorewall-init.log.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) A new TRACK_PROVIDERS option has been added in shorewall.conf.
|
|
|
|
The value of this option becomes the default for the 'track'
|
|
|
|
provider option in /etc/shorewall/providers.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) A new 'limit' option has been added to
|
|
|
|
/etc/shorewall/tcclasses. This option specifies the number of
|
|
|
|
packets that are allowed to be queued within the class. Packets
|
|
|
|
exceeding this limit are dropped. The default value is 127 which is
|
|
|
|
the value that earlier versions of Shorewall used. The option is
|
|
|
|
ignored with a warning if the 'pfifo' option has been specified.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 2
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) Detection of Persistent SNAT was broken in the rules compiler.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) Initialization of the compiler's chain table was occurring before
|
|
|
|
shorewall.conf had been read and before the capabilities had been
|
|
|
|
determined. This could lead to incorrect rules and Perl runtime
|
|
|
|
errors.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) The 'shorewall check' command previously did not detect errors in
|
|
|
|
/etc/shorewall/routestopped.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) In earlier versions, if a file with the same name as a built-in
|
|
|
|
action were present in the CONFIG_PATH, then the compiler would
|
|
|
|
process that file like it was an extension script.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The compiler now ignores the presence of such files.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) Several configuration issues which previously produced an error or
|
|
|
|
warning are now handled differently.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) MAPOLDACTIONS=Yes and MAPOLDACTIONS= in shorewall.conf are now
|
|
|
|
handled as they were by the old shell-based compiler. That is,
|
|
|
|
they cause pre-3.0 built-in actions to be mapped automatically
|
|
|
|
to the corresponding macro invocation.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
b) SAVE_IPSETS=Yes no longer produces a fatal error -- it is now a
|
|
|
|
warning.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
c) DYNAMIC_ZONES=Yes no longer produces a fatal error -- it is now
|
|
|
|
a warning.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
d) RFC1918_STRICT=Yes no longer produces a fatal error -- it is now
|
|
|
|
a warning.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
6) Previously, it was not possible to specify an IP address range in
|
|
|
|
the ADDRESS column of /etc/shorewall/masq. Thanks go to Jessee
|
|
|
|
Shrieve for the patch.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
7) The 'wait4ifup' script included for Debian compatibility now runs
|
|
|
|
correctly with no PATH.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
8) The new per-IP LIMIT feature now works with ancient iptables
|
|
|
|
releases (e.g., 1.3.5 as found on RHEL 5). This change required
|
|
|
|
testing for an additional capability which means that those who use
|
|
|
|
a capabilities file should regenerate that file after installing
|
|
|
|
4.4.2.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
9) One unintended difference between Shorewall-shell and
|
|
|
|
Shorewall-perl was that Shorewall-perl did not support the MARK
|
|
|
|
column in action bodies. This has been corrected.
|
2009-11-23 18:33:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
N E W F E A T U R E S I N 4 . 4 . 2
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) Prior to this release, line continuation has taken precedence over
|
|
|
|
#-style comments. This prevented us from doing the following:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
ACCEPT net:206.124.146.176,\ #Gateway
|
|
|
|
206.124.146.177,\ #Mail
|
|
|
|
206.124.146.178\ #Server
|
|
|
|
...
|
|
|
|
|
|
|
|
Now, unless a line ends with '\', any trailing comment is stripped
|
|
|
|
off (including any white-space preceding the '#'). Then if the line
|
|
|
|
ends with '\', it is treated as a continuation line as normal.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) Three new columns have been added to FORMAT-2 macro bodies.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
MARK
|
|
|
|
CONNLIMIT
|
|
|
|
TIME
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
These three columns correspond to the similar columns in
|
|
|
|
/etc/shorewall/rules and must be empty in macros invoked from an
|
|
|
|
action.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) Accounting chains may now have extension scripts. Simply place your
|
|
|
|
Perl script in the file /etc/shorewall/<chain> and when the
|
|
|
|
accounting chain named <chain> is created, your script will be
|
|
|
|
invoked.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
As usual, the variable $chainref will contain a reference to the
|
|
|
|
chain's table entry.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
P R O B L E M S C O R R E C T E D I N 4 . 4 . 1
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) If ULOG was specified as the LOG LEVEL in the all->all policy, the
|
|
|
|
rules at the end of the INPUT and OUTPUT chains would still use the
|
|
|
|
LOG target rather than ULOG.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) Using CONTINUE policies with a nested IPSEC zone was still broken
|
|
|
|
in some cases.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) The setting of IP_FORWARDING has been change to Off in the
|
|
|
|
one-interface sample configuration since forwarding is typically
|
|
|
|
not required with only a single interface.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) If MULTICAST=Yes in shorewall.conf, multicast traffic was
|
|
|
|
incorrectly exempted from ACCEPT policies.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) Previously, the definition of a zone that specified "nets=" in
|
|
|
|
/etc/shorewall/interfaces could not be extended by entries in
|
|
|
|
/etc/shorewall/hosts.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
6) Previously, "nets=" could be specified in a multi-zone interface
|
|
|
|
definition ("-" in the ZONES column) in /etc/shorewall/zones. This
|
|
|
|
now raises a fatal compilation error.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
7) MULTICAST=Yes generates an incorrect rule that limits its
|
|
|
|
effectiveness to a small part of the multicast address space.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
8) Checking for zone membership has been tighened up. Previously,
|
|
|
|
a zone could contain <interface>:0.0.0.0/0 along with other hosts;
|
|
|
|
now, if the zone has <interface>:0.0.0.0/0 (even with exclusions),
|
|
|
|
then it may have no additional members in /etc/shorewall/hosts.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
N E W F E A T U R E S I N 4 . 4 . 1
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) To replace the SAME keyword in /etc/shorewall/masq, support has
|
|
|
|
been added for 'persistent' SNAT. Persistent SNAT is required when
|
|
|
|
an address range is specified in the ADDRESS column and when you
|
|
|
|
want a client to always receive the same source/destination IP
|
|
|
|
pair. It replaces SAME: which was removed in Shorewall 4.4.0.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To specify persistence, follow the address range with
|
|
|
|
":persistent".
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
|
|
eth0 0.0.0.0/0 206.124.146.177-206.124.146.179:persistent
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
This feature requires Persistent SNAT support in your kernel and
|
|
|
|
iptables.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If you use a capabilities file, you will need to create a new one
|
|
|
|
as a result of this feature.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
WARNING: Linux kernels beginning with 2.6.29 include persistent
|
|
|
|
SNAT support. If your iptables supports persistent SNAT but your
|
|
|
|
kernel does not, there is no way for Shorewall to determine that
|
|
|
|
persistent SNAT isn't going to work. The kernel SNAT code blindly
|
|
|
|
accepts all SNAT flags without verifying them and returns them to
|
|
|
|
iptables when asked.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) A 'clean' target has been added to the Makefiles. It removes backup
|
|
|
|
files (*~ and .*~).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) The meaning of 'full' has been redefined when used in the context
|
|
|
|
of a traffic shaping sub-class. Previously, 'full' always meant the
|
|
|
|
OUT-BANDWIDTH of the device. In the case of a sub-class, however,
|
|
|
|
that definition is awkward to use because the sub-class is limited
|
|
|
|
by the parent class.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Beginning with this release, 'full' in a sub-class definition
|
|
|
|
refers to the specified rate defined for the parent class. So
|
|
|
|
'full' used in the RATE column refers to the parent class's RATE;
|
|
|
|
when used in the CEIL column, 'full' refers to the parent class's
|
|
|
|
CEIL.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
As part of this change, the compiler now issues a warning if the
|
|
|
|
sum of the top-level classes' RATEs exceeds the OUT-BANDWIDTH of
|
|
|
|
the device. Similarly, a warning is issued if the sum of the RATEs
|
|
|
|
of a class's sub-classes exceeds the rate of the CLASS.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) When 'nets=<network>' or 'nets=(<net1>,<net2>,...) is specified in
|
|
|
|
/etc/shorewall/interfaces, multicast traffic will now be sent to
|
|
|
|
the zone along with limited broadcasts.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) A flaw in the parsing logic for the zones file allowed most zone
|
|
|
|
types containing the character string 'ip' to be accepted as a
|
|
|
|
synonym for 'ipv4' (or ipv6 if compiling an IPv6 configuration).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
----------------------------------------------------------------------------
|
|
|
|
N E W F E A T U R E S I N 4 . 4 . 0
|
|
|
|
----------------------------------------------------------------------------
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1) The Shorewall packaging has been completely revamped in Shorewall
|
|
|
|
4.4.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The new packages are:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- Shorewall. Includes the former Shorewall-common and
|
|
|
|
Shorewall-perl packages. Includes everything needed
|
|
|
|
to create an IPv4 firewall.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Shorewall-shell is no longer available.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- Shorewall6. Requires Shorewall. Adds the components necessary to
|
|
|
|
create an IPv6 firewall.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- Shorewall-lite
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
May be installed on a firewall system to run
|
|
|
|
IPv4 firewall scripts generated by Shorewall.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- Shorewall6-lite
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
May be installed on a firewall system to run
|
|
|
|
IPv6 firewall scripts generated by Shorewall6.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
2) The interfaces file supports a new 'nets=' option. This option
|
|
|
|
allows you to restrict a zone's definition to particular networks
|
|
|
|
through an interface without having to use the hosts file.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example interfaces file:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
|
|
loc eth3 detect dhcp,logmartians=1,routefilter=1,nets=172.20.1.0/24
|
|
|
|
dmz eth4 detect logmartians=1,routefilter=1,nets=206.124.146.177
|
|
|
|
net eth0 detect dhcp,blacklist,tcpflags,optional,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177)
|
|
|
|
net eth2 detect dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177)
|
|
|
|
loc tun+ detect nets=172.20.0.0/24
|
|
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Note that when more than one network address is listed, the list
|
|
|
|
must be enclosed in parentheses. Notice also that exclusion may be
|
|
|
|
used.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The first entry in the above interfaces file is equivalent to the
|
|
|
|
following:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
interfaces:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
|
|
- eth0 detect dhcp,logmartians=1,routefilter=1
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
hosts:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#ZONE HOST(S) OPTIONS
|
|
|
|
loc $INT_IF:192.20.1.0/24 broadcast
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Note that the 'broadcast' option is automatically assumed and need
|
|
|
|
not be explicitly specified.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
3) Some websites run applications that require multiple connections
|
|
|
|
from a client browser. Where multiple 'balanced' providers are
|
|
|
|
configured, this can lead to problems when some of the connections
|
|
|
|
are routed through one provider and some through another.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To work around this issue, the SAME target has been added to
|
|
|
|
/etc/shorewall/tcrules. SAME may be used in the PREROUTING and
|
|
|
|
OUTPUT chains. When used in PREROUTING, it causes matching
|
|
|
|
connections from an individual local system to all use the same
|
|
|
|
provider.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
For example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
SAME:P 192.168.1.0/24 - tcp 80,443
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or
|
|
|
|
443 and it has sent a packet on either of those ports in the last
|
|
|
|
five minutes then the new connection will use the same provider as
|
|
|
|
the connection over which that last packet was sent.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When used in the OUTPUT chain, it causes all matching connections
|
|
|
|
to an individual remote system to use the same provider.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
For example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
SAME $FW - tcp 80,443
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If the firewall attempts a connection on TCP port 80 or
|
|
|
|
443 and it has sent a packet on either of those ports in the last
|
|
|
|
five minutes to the same remote system then the new connection will
|
|
|
|
use the same provider as the connection over which that last packet
|
|
|
|
was sent.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Important note: SAME only works with providers that have the
|
|
|
|
'track' option specified in /etc/shorewall/providers.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
4) The file /var/lib/shorewall/.restore has been renamed to
|
|
|
|
/var/lib/shorewall/firewall. A similar change has been made in
|
|
|
|
Shorewall6.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When a successful start or restart is completed, the script that
|
|
|
|
executed the command copies itself to
|
|
|
|
/var/lib/shorewall[6]/firewall.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
As always, /var/lib/shorewall[6] is the default directory which may
|
|
|
|
be overridden using the /etc/shorewall[6]/vardir file.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
5) Dynamic zone support is once again available for IPv4. This support
|
|
|
|
is built on top of ipsets so you must have the xtables-addons
|
|
|
|
installed on the firewall system.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
See http://www.shorewall.net/Dynamic.html for information about
|
|
|
|
this feature and for instructions for installing xtables-addons on
|
|
|
|
your firewall.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Dynamic zones are available when Shorewall-lite is used as well.
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
You define a zone as having dynamic content in one of two ways:
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- By specifying nets=dynamic in the OPTIONS column of an entry for
|
|
|
|
the zone in /etc/shorewall/interfaces; or
|
2009-12-05 00:04:59 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- By specifying <interface>:dynamic in the HOST(S) column of an
|
|
|
|
entry for the zone in /etc/shorewall/hosts.
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When there are any dynamic zones present in your configuration,
|
|
|
|
Shorewall (Shorewall-lite) will:
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) Execute the following commands during 'shorewall start' or
|
|
|
|
'shorewall-lite start'.
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
ipset -U :all: :all:
|
|
|
|
ipset -U :all: :default:
|
|
|
|
ipset -F
|
|
|
|
ipset -X
|
|
|
|
ipset -R < ${VARDIR}/ipsets.save
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
where $VARDIR normally contains /var/lib/shorewall
|
|
|
|
(/var/lib/shorewall-lite) but may be modified by
|
|
|
|
/etc/shorewall/vardir (/etc/shorewall-lite/vardir).
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
b) During 'start', 'restart' and 'restore' processing, Shorewall
|
|
|
|
will attempt to create an ipset named <zone>_<interface>
|
|
|
|
for each zone/interface pair that has been specified as
|
|
|
|
dynamic. The type of ipset created is 'iphash' so that only
|
|
|
|
individual IPv4 addresses may be added to the set.
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
c) Execute the following commands during 'shorewall stop' or
|
|
|
|
'shorewall-lite stop':
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
if ipset -S > ${VARDIR}/ipsets.tmp; then
|
|
|
|
mv -f ${VARDIR}/ipsets.tmp ${VARDIR}/ipsets.save
|
|
|
|
fi
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The 'shorewall add' and 'shorewall delete' commands are supported
|
|
|
|
with their original syntax:
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
add <interface>[:<host-list>] ... <zone>
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
delete <interface>[:<host-list>] ... <zone>
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
In addition, the 'show dynamic' command is added that lists the dynamic
|
|
|
|
content of a zone.
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
show dynamic <zone>
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
These commands are supported by shorewall-lite as well.
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
6) The generated program now attempts to detect all dynamic
|
|
|
|
information when it first starts. Dynamic information includes IP
|
|
|
|
addresses, default gateways, networks routed through an interface,
|
|
|
|
etc. If any of those steps fail, an error message is generated and
|
|
|
|
the state of the firewall is not changed.
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
7) To improve the readability of configuration files, Shorewall now
|
|
|
|
allows leading white space in continuation lines when the continued
|
|
|
|
line ends in ":" or ",".
|
2009-12-05 18:05:16 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example (/etc/shorewall/rules):
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#ACTION SOURCE DEST PROTO DEST
|
|
|
|
# PORT(S)
|
|
|
|
ACCEPT net:\
|
|
|
|
206.124.146.177,\
|
|
|
|
206.124.146.178,\
|
|
|
|
206.124.146.180\
|
|
|
|
dmz tcp 873
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The leading white space on the lines that contain just an IP
|
|
|
|
address is ignored so the SOURCE column effectively contains
|
|
|
|
"net:206.124.146.177,206.124.147.178,206.124.146.180".
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
8) The generated script now uses iptables[6]-restore to instantiate
|
|
|
|
the Netfilter ruleset during processing of the 'stop' command. As a
|
|
|
|
consequence, the 'critical' option in /etc/shorewall/route_stopped
|
|
|
|
is no longer needed and will result in a warning.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
9) A new AUTOMAKE option has been added to shorewall.conf and
|
|
|
|
shorewall6.conf. When set to 'Yes', this option causes new behavior
|
|
|
|
during processing of the 'start' and 'restart' commands; if no
|
|
|
|
files in /etc/shorewall/ (/etc/shorewall6) have changed since the last
|
|
|
|
'start' or 'restart', then the compilation step is skipped and the
|
|
|
|
script used during the last 'start' or 'restart' is used to
|
|
|
|
start/restart the firewall.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Note that if a <directory> is specified in the start/restart
|
|
|
|
command (e.g., "shorewall restart /etc/shorewall.new") then the
|
|
|
|
setting of AUTOMAKE is ignored.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Note that the 'make' utility must be installed on the firewall
|
|
|
|
system in order for AUTOMAKE=Yes to work correctly.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
10) The 'compile' command now allows you to omit the <pathname>. When
|
|
|
|
you do that, the <pathname> defaults to /var/lib/shorewall/firewall
|
|
|
|
(/var/lib/shorewall6/firewall) unless you have overridden VARDIR
|
|
|
|
using /etc/shorewall/vardir (/etc/shorewall6/vardir).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When combined with AUTOMAKE=Yes, it allows the following:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
gateway:~ # shorewall compile
|
|
|
|
Compiling...
|
|
|
|
Shorewall configuration compiled to /root/shorewall/firewall
|
|
|
|
gateway:~ #
|
|
|
|
...
|
|
|
|
gateway:~ # shorewall restart
|
|
|
|
Restarting Shorewall....
|
|
|
|
done.
|
|
|
|
gateway:~ #
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
In other words, you can compile the current configuration then
|
|
|
|
install it at a later time.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
11) Thanks to I. Buijs, it is now possible to rate-limit connections by
|
|
|
|
source IP or destination IP. The LIMIT:BURST column in
|
|
|
|
/etc/shorewall/policy (/etc/shorewall6/policy) and the RATE LIMIT
|
|
|
|
column /etc/shorewall/rules (/etc/shorewall6/rules) have been
|
|
|
|
extended as follows:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
[{s|d}:[[<name>]:]]<rate>/{sec|min}[:<burst>]
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When s: is specified, the rate is per source IP address.
|
|
|
|
When d: is specified, the rate is per destination IP address.
|
|
|
|
The <name> specifies the name of a hash table -- you get to choose
|
|
|
|
the name. If you don't specify a name, the name 'shorewall' is
|
|
|
|
assumed. Rules with the same name have their connection counts
|
|
|
|
aggregated and the individual rates are applied to the aggregate.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
ACCEPT net fw tcp 22 - - s:ssh:3/min
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
This will limit SSH connections from net->fw to 3 per minute.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
ACCEPT net fw tcp 25 - - s:mail:3/min
|
|
|
|
ACCEPT net fw tcp 587 - - s:mail:3/min
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Since the same hash table name is used in both rules, the above is
|
|
|
|
equivalent to this single rule:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
ACCEPT net fw tcp 25,587 - - s:mail:3/min
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
12) Rules that specify a log level with a target other than LOG or NFLOG
|
|
|
|
are now implemented through a separate chain. While this may increase
|
|
|
|
the processing cost slightly for packets that match these rules, it
|
|
|
|
is expected to reduce the overall cost of such rules because each
|
|
|
|
packet that doesn't match the rules only has to be processed once
|
|
|
|
per rule rather than twice.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shorewall/rules:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
REJECT:info loc net tcp 25
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
This previously generated these two rules (long rules folded):
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
-A loc2net -p 6 --dport 25 -j LOG --log-level 6
|
|
|
|
--log-prefix "Shorewall:loc2net:reject:"
|
|
|
|
-A loc2net -p 6 --dport 25 -j reject
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
It now generates these rules:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
:log0 - [0:0]
|
|
|
|
...
|
|
|
|
-A loc2net -p 6 --dport 25 -g log0
|
|
|
|
...
|
|
|
|
-A log0 -j LOG --log-level 6
|
|
|
|
--log-prefix "Shorewall:loc2net:REJECT:"
|
|
|
|
-A log0 -j reject
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Notice that now there is only a single rule generated in the
|
|
|
|
'loc2net' chain where before there were two. Packets for other than
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
TCP port 25 had to be processed by both rules.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Notice also that the new LOG rule reflects the original action
|
|
|
|
("REJECT") rather than what Shorewall maps that to ("reject").
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
13) Shorewall6 has now been tested on kernel 2.6.24 (Ubuntu Hardy) and
|
|
|
|
hence will now start successfully when running on that kernel.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
14) Three new options (IP, TC and IPSET) have been added to
|
|
|
|
shorewall.conf and shorwall6.conf. These options specify the name
|
|
|
|
of the executable for the 'ip', 'tc' and 'ipset' utilities
|
|
|
|
respectively.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If not specified, the default values are:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
IP=ip
|
|
|
|
TC=tc
|
|
|
|
IPSET=ipset
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
In other words, the utilities will be located via the current PATH
|
|
|
|
setting.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
15) There has been a desire in the user community to limit traffic by
|
|
|
|
IP address using Shorewall traffic shaping. Heretofore, that has
|
|
|
|
required a very inefficient process:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) Define a tcclass for each internal host (two, if shaping both in
|
|
|
|
and out).
|
|
|
|
b) Define a tcrule for each host to mark to classify the packets
|
|
|
|
accordingly.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Beginning with Shorewall 4.4, this process is made easier IF YOU
|
|
|
|
ARE WILLING TO INSTALL xtables-addons. The feature requires IPMARK
|
|
|
|
support in iptables[6] and your kernel. That support is available
|
|
|
|
in xtables-addons.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Instructions for installing xtables-addons may be found at
|
|
|
|
http://www.shorewall.net/Dynamic.html#xtables-addons.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The new facility has two components:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) A new IPMARK MARKing command in /etc/shorewall/tcrules.
|
|
|
|
b) A new 'occurs' OPTION in /etc/shorewall/tcclasses.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The facility is currently only available with IPv4.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
In a sense, the IPMARK target is more like an IPCLASSIFY target in
|
|
|
|
that the mark value is later interpreted as a class ID. A packet
|
|
|
|
mark is 32 bits wide; so is a class ID. The <major> class occupies
|
|
|
|
the high-order 16 bits and the <minor> class occupies the low-order
|
|
|
|
16 bits. So the class ID 1:4ff (remember that class IDs are always
|
|
|
|
in hex) is equivalent to a mark value of 0x104ff. Remember that
|
|
|
|
Shorewall uses the interface number as the <major> number where the
|
|
|
|
first interface in tcdevices has <major> number 1, the second has
|
|
|
|
<major> number 2, and so on.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The IPMARK target assigns a mark to each matching packet based on
|
|
|
|
the either the source or destination IP address. By default, it
|
|
|
|
assigns a mark value equal to the low-order 8 bits of the source
|
|
|
|
address.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The syntax is as follows:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
IPMARK[([{src|dst}][,[<mask1>][,[<mask2>][,[<shift>]]]])]
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Default values are:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
src
|
|
|
|
<mask1> = 0xFF
|
|
|
|
<mask2> = 0x00
|
|
|
|
<shift> = 0
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
'src' and 'dst' specify whether the mark is to be based on the
|
|
|
|
source or destination address respectively.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The selected address is first shifted right by <shift>, then
|
|
|
|
LANDed with <mask1> and then LORed with <mask2>. The <shift>
|
|
|
|
argument is intended to be used primarily with IPv6 addresses.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
IPMARK(src,0xff,0x10100)
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Destination IP address is 192.168.4.3 = 0xc0a80403
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
0xc0a80403 >> 0 = 0xc0a80403
|
|
|
|
0xc0a80403 LAND 0xFF = 0x03
|
|
|
|
0x03 LOR 0x10100 = 0x10103
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
So the mark value is 0x10103 which corresponds to class id
|
|
|
|
1:103.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
It is important to realize that, while class IDs are composed of a
|
|
|
|
<major> and a <minor> value, the set of <minor> values must be
|
|
|
|
unique. You must keep this in mind when deciding how to map IP
|
|
|
|
addresses to class IDs.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
For example, suppose that your internal network is 192.168.1.0/29
|
|
|
|
(host IP addresses 192.168.1.1 - 192.168.1.6). Your first notion
|
|
|
|
might be to use IPMARK(src,0xFF,0x10000) so as to produce class IDs
|
|
|
|
1:1 through 1:6. But 1:1 is the class ID of the base HTB class on
|
|
|
|
interface 1. So you might chose instead to use
|
|
|
|
IPMARK(src,0xFF,0x10100) as shown in the example above so as to
|
|
|
|
avoid minor class 1.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The 'occurs' option in /etc/shorewall/tcclasses causes the class
|
|
|
|
definition to be replicated many times. The synax is:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
occurs=<number>
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When 'occurs' is used:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
a) The associated device may not have the 'classify' option.
|
|
|
|
b) The class may not be the default class.
|
|
|
|
c) The class may not have any 'tos=' options (including
|
|
|
|
'tcp-ack').
|
|
|
|
d) The class should not specify a MARK value. Any MARK value
|
|
|
|
given is ignored with a warning.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The 'RATE' and 'CEIL' parameters apply to each instance of the
|
|
|
|
class. So the total RATE represented by an entry with 'occurs' will
|
|
|
|
be the listed RATE multiplied by the 'occurs' number.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shorewall/tcdevices:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#INTERFACE IN-BANDWIDTH OUT-BANDWIDTH
|
|
|
|
eth0 100mbit 100mbit
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shorewall/tcclasses:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#DEVICE MARK RATE CEIL PRIORITY OPTIONS
|
|
|
|
eth0:101 - 1kbit 230kbit 4 occurs=6
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The above defines 6 classes with class IDs 0x101-0x106. Each
|
|
|
|
class has a guaranteed rate of 1kbit/second and a ceiling of
|
|
|
|
230kbit.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shoreall/tcrules:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#MARK SOURCE DEST
|
|
|
|
IPMARK(src,0xff,0x10100):F 192.168.1.0/29 eth0
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
This change also altered the way in which Shorewall generates a
|
|
|
|
class number when none is given.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- Prior to this change, the class number was constructed by concatinating
|
|
|
|
the mark value with the either '1' or '10'. '10' was used when
|
|
|
|
there were more than 10 devices defined in /etc/shorewall/tcdevices.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- Beginning with this change, a new method is added; class numbers
|
|
|
|
are assigned sequentially beginning with 2.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The WIDE_TC_MARKS option in shorewall.conf selects which
|
|
|
|
construction to use. WIDE_TC_MARKS=No (the default) produces
|
|
|
|
pre-4.4 behavior. WIDE_TC_MARKS=Yes produces the new behavior.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
In addition to determining the method of constructing class Ids,
|
|
|
|
WIDE_TC_MARKS=Yes provides for larger mark values for traffic
|
|
|
|
shaping. Traffic shaping marks may have values up to 16383 (0x3fff)
|
|
|
|
with WIDE_TC_MARKS=Yes. This means that when both WIDE_TC_MARKS=Yes and
|
|
|
|
HIGH_ROUTE_MARKS=Yes, routing marks (/etc/shorewall/providers MARK
|
|
|
|
column) must be >= 65536 (0x10000) and must be a multiple of 65536
|
|
|
|
(0x1000, 0x20000, 0x30000, ...).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
16) In the 'shorewall compile' and 'shorewall6 compile' commands, the
|
|
|
|
filename '-' now causes the compiled script to be written to
|
|
|
|
Standard Out. As a side effect, the effective VERBOSITY is set to
|
|
|
|
-1 (silent).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Examples:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
shorewall compile -- - # Compile the configuration in
|
|
|
|
# /etc/shorewall and send the
|
|
|
|
# output to STDOUT
|
|
|
|
shorewall compile . - # Compile the configuration in the
|
|
|
|
# current working directory
|
|
|
|
# and send the output to STDOUT
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
17) Supplying an interface name in the SOURCE column of
|
|
|
|
/etc/shorewall/masq is now deprecated. Entering the name of an
|
|
|
|
interface there will result in a compile-time warning (see the
|
|
|
|
Migration Considerations above).
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
18) Shorewall now supports nested HTB traffic shaping classes. The
|
|
|
|
nested classes within a class can borrow from their parent class in
|
|
|
|
the same way as the first level classes can borrow from the root
|
|
|
|
class.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To use nested classes, you must explicitly number your
|
|
|
|
classes. That does not imply that you must use the 'classify'
|
|
|
|
option.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Example:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shorewall/tcdevices
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS
|
|
|
|
eth2 - 100mbps classify
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
/etc/shorewall/tcclasses
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
|
|
|
|
1:10 - full/2 full 1
|
|
|
|
1:100 - 16mbit 20mbit 2
|
|
|
|
1:100:101 - 8mbit 20mbit 3 default
|
|
|
|
1:100:102 - 8mbit 20mbit 3
|
|
|
|
|
|
|
|
/etc/shorewall/tcrules
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
#MARK SOURCE DEST
|
|
|
|
1:102 0.0.0.0/0 eth2:172.20.1.107
|
|
|
|
1:10 206.124.146.177 eth2
|
|
|
|
1:10 172.20.1.254 eth2
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The above controls download for internal interface eth2. The
|
|
|
|
external interface has a download rate of 20mbit so we guarantee
|
|
|
|
that to class 1:100. 1:100 has two subclasses, each of which is
|
|
|
|
guaranteed half of their parent's bandwidth.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Local traffic (that coming from the firewall and from the DMZ
|
|
|
|
server) is placed in the effectively unrestricted class 1:10. The
|
|
|
|
default class is guaranteed half of the download capacity and my
|
|
|
|
work system (172.20.1.107) is guarandeed the other half.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
19) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing
|
|
|
|
discipline has been added. HFSC is claimed to be superior to the
|
|
|
|
"Hierarchical Token Bucket" queuing discipline where realtime
|
|
|
|
traffic such as VOIP is being used.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
An excellent overview of HFSC on Linux may be found at
|
|
|
|
http://linux-ip.net/articles/hfsc.en/.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To use HFSC, several changes need to be made to your traffic
|
|
|
|
shaping configuration:
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- To use HFSC on an interface rather than HTB, specify the
|
|
|
|
'hfsc' option in the OPTIONS column in the interfaces's
|
|
|
|
entry in /etc/shorewall/tcdevices.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
- Modify the RATE colum for each 'leaf' class (class with no
|
|
|
|
parent class specified) defined for the interface.
|
2009-11-23 20:15:33 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When using HFSC, the RATE column may specify 1, 2 or 3
|
|
|
|
pieces of information separated by colons (":").
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
1. The Guaranteed bandwidth (as always).
|
|
|
|
2. The Maximum delay (DMAX) that the first queued packet
|
|
|
|
in the class should experience. The delay is expressed
|
|
|
|
in milliseconds and may be followed by 'ms' (e.g.,
|
|
|
|
10ms. Note that there may be no white space between the
|
|
|
|
number and 'ms').
|
|
|
|
3. The maximum transmission unit (UMAX) for this class of
|
|
|
|
traffic. If not specified, the MTU of the interface is
|
|
|
|
used. The length is specified in bytes and may be
|
|
|
|
followed by 'b' (e.g., 800b. Note that there may be no
|
|
|
|
white space between the number and 'b').
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
DMAX should be specified for each leaf class. The Shorewall
|
|
|
|
compiler will issue a warning if DMAX is omitted.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
full/2:10ms:1500b
|
|
|
|
|
|
|
|
Guaranteed bandwidth is 1/2 of the devices
|
|
|
|
OUT-BANDWIDTH. Maximum delay is 10ms. Maximum packet
|
|
|
|
size is 1500 bytes.
|
|
|
|
|
|
|
|
20) Optional TOS and LENGTH fields have been added to the tcfilters
|
|
|
|
file.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The TOS field may contain any of the following:
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
tos-minimize-delay
|
|
|
|
tos-maximuze-throughput
|
|
|
|
tos-maximize-reliability
|
|
|
|
tos-minimize-cost
|
|
|
|
tos-normal-service
|
|
|
|
Hex-number
|
|
|
|
Hex-number/Hex-number
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The hex numbers must have exactly two digits.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The LENGTH value must be a numeric power of two between 32 and 8192
|
|
|
|
inclusive. Packets with a total length that is strictly less that
|
|
|
|
the specified value will match the rule.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
21) Support for 'norfc1918' has been removed. See the Migration
|
|
|
|
Considerations above.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
22) A 'upnpclient' option has been added to
|
|
|
|
/etc/shorewall/interfaces. This option is intended for laptop users
|
|
|
|
who always run Shorewall on their system yet need to run
|
|
|
|
UPnP-enabled client apps such as Transmission (BitTorrent client).
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The option causes Shorewall to detect the default gateway through
|
|
|
|
the interface and to accept UDP packets from that gateway. Note
|
|
|
|
that, like all aspects of UPnP, this is a security hole so use this
|
|
|
|
option at your own risk.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
23) 'iptrace' and 'noiptrace' commands have been added to both
|
|
|
|
/sbin/shorewall and /sbin/shorewall6.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
These are low-level debugging commands that cause
|
|
|
|
iptables/ip6tables TRACE log messages to be generated. See 'man
|
|
|
|
iptables' and 'man ip6tables' for details.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The syntax for the commands is:
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
iptrace <iptables/ip6tables match expression>
|
|
|
|
noiptrace <iptables/ip6tables match expression>
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
iptrace starts the trace; noiptrace turns it off.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The match expression must be an expression that is legal in both
|
|
|
|
the raw table OUTPUT and PREROUTING chains.
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Examaple:
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To trace all packets destinted for IP address 206.124.146.176:
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
shorewall iptrace -d 206.124.146.176
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To turn that trace off:
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
shorewall noiptrace -d 206.124.146.176
|
2009-12-20 01:09:20 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
24) A USER/GROUP column has been added to /etc/shorewall/masq. The
|
|
|
|
column works similarly to USER/GROUP columns in other Shorewall
|
|
|
|
configuration files. Only locally-generated traffic is matched.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
25) A new extension script, 'lib.private' has been added. This file is
|
|
|
|
intended to include declarations of shell functions that will be
|
|
|
|
called by the other run-time extension scripts.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
26) Paul Gear has contributed the following macros:
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
macro.Webcache (originally named macro.DG)
|
|
|
|
macro.IPPbrd
|
|
|
|
macro.NTPbi
|
|
|
|
macro.RIPbi
|
|
|
|
macro.mDNS
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
27) The default value of DISABLE_IPV6 has been changed from 'Yes' to
|
|
|
|
'No' in all sample shorewall.conf files. Shorewall6 should be
|
|
|
|
installed to restrict IPv6 traffic.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
As part of this change, the ip6tables program in the directory
|
|
|
|
specified by the IPTABLES setting will be used to disable IPv6. If
|
|
|
|
the iptables utility is discovered using the PATH setting, then
|
|
|
|
ip6tables in the same directory as the discovered iptables will be
|
|
|
|
used.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
28) A 'flow=<keys>' option has been added to the
|
|
|
|
/etc/shorewall/tcclasses OPTIONS column.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Shorewall attaches an SFQ queuing discipline to each leaf HTB
|
|
|
|
and HFSC class. SFQ ensures that each flow gets equal access to the
|
|
|
|
interface. The default definition of a flow corresponds roughly to
|
|
|
|
a Netfilter connection. So if one internal system is running
|
|
|
|
BitTorrent, for example, it can have lots of 'flows' and can thus
|
|
|
|
take up a larger share of the bandwidth than a system having only a
|
|
|
|
single active connection. The flow classifier (module cls_flow)
|
|
|
|
works around this by letting you define what a 'flow' is.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The clasifier must be used carefully or it can block off all
|
|
|
|
traffic on an interface!
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
The flow option can be specified for an HTB or HFSC leaf class (one
|
|
|
|
that has no sub-classes). We recommend that you use the following:
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Shaping internet-bound traffic: flow=nfct-src
|
|
|
|
Shaping traffic bound for your local net: flow=dst
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
These will cause a 'flow' to consists of the traffic to/from each
|
|
|
|
internal system.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
When more than one key is give, they must be enclosed in
|
|
|
|
parenthesis and separated by commas.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
To see a list of the possible flow keys, run this command:
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
tc filter add flow help
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Those that begin with "nfct-" are Netfilter connection tracking
|
|
|
|
fields. As shown above, we recommend flow=nfct-src; that means that
|
|
|
|
we want to use the source IP address before SNAT as the key.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Note: Shorewall cannot determine ahead of time if the flow
|
|
|
|
classifier is available in your kernel (especially if it was built
|
|
|
|
into the kernel as opposed to being loaded as a
|
|
|
|
module). Consequently, you should check ahead of time to ensure
|
|
|
|
that both your kernel and 'tc' utility support the feature.
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
You can test the 'tc' utility by typing (as root):
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
tc filter add flow help
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If flow is supported, you will see:
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Usage: ... flow ...
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
[mapping mode]: map key KEY [ OPS ] ...
|
|
|
|
[hashing mode]: hash keys KEY-LIST ...
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
...
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If flow is not supported, you will see:
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
Unknown filter "flow", hence option "help" is unparsable
|
|
|
|
|
|
|
|
If your kernel supports module autoloading, just type (as root):
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
modprobe cls_flow
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If 'flow' is supported, no output is produced; otherwise, you will
|
|
|
|
see:
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
FATAL: Module cls_flow not found.
|
|
|
|
|
|
|
|
If your kernel is not modularized or does not support module
|
|
|
|
autoloading, look at your kernel configuration (either
|
|
|
|
/proc/config.gz or the .config file in
|
|
|
|
/lib/modules/<kernel-version>/build/
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
If 'flow' is supported, you will see:
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
NET_CLS_FLOW=m
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
or
|
2010-01-16 17:11:13 +01:00
|
|
|
|
2010-01-16 20:32:50 +01:00
|
|
|
NET_CLS_FLOW=y
|
|
|
|
|
|
|
|
For modularized kernels, Shorewall will attempt to load
|
|
|
|
/lib/modules/<kernel-version>/net/sched/cls_flow.ko by default.
|
|
|
|
|