forked from extern/shorewall_code
4d9473e8ca
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@8490 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
854 lines
30 KiB
Plaintext
854 lines
30 KiB
Plaintext
Shorewall 4.1 Patch Release 8.
|
|
|
|
----------------------------------------------------------------------------
|
|
R E L E A S E 4 . 1 H I G H L I G H T S
|
|
----------------------------------------------------------------------------
|
|
1) Support is included for multiple internet providers through the same
|
|
ethernet interface.
|
|
|
|
2) Support for NFLOG has been added.
|
|
|
|
3) Enhanced operational logging.
|
|
|
|
4) The tarball installers now work under Cygwin.
|
|
|
|
5) Shorewall-perl now supports IFB devices which allow traffic shaping of
|
|
incoming traffic.
|
|
|
|
6) Shorewall-perl supports definition of u32 traffic classification
|
|
filters.
|
|
|
|
Migration Issues.
|
|
|
|
1) Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
|
|
mark values < 256 to be assigned in the OUTPUT chain. This has been
|
|
changed so that only high mark values may be assigned
|
|
there. Packet marking rules for traffic shaping of packets
|
|
originating on the firewall must be coded in the POSTROUTING table.
|
|
|
|
2) Previously, Shorewall did not range-check the value of the
|
|
VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.1:
|
|
|
|
a) A VERBOSITY setting outside the range -1 through 2 is rejected.
|
|
b) After the -v and -q options are applied, the resulting value is
|
|
adjusted to fall within the range -1 through 2.
|
|
|
|
3) Specifying a destination zone in a NAT-only rule now generates a
|
|
warning and the destination zone is ignored. NAT-only rules are:
|
|
|
|
NONAT
|
|
REDIRECT-
|
|
DNAT-
|
|
|
|
4) The default value for LOG_MARTIANS has been changed. Previously,
|
|
the defaults were:
|
|
|
|
Shorewall-perl - 'Off'
|
|
Shorewall-shell - 'No'
|
|
|
|
The new default values are:
|
|
|
|
Shorewall-perl - 'On'
|
|
Shorewall-shell - 'Yes'.
|
|
|
|
Shorewall-perl users may:
|
|
|
|
a) Accept the new default -- martians will be logged from all
|
|
interfaces with route filtering except those with log_martians=0
|
|
in /etc/shorewall/interfaces.
|
|
|
|
b) Explicitly set LOG_MARTIANS=Off to maintain compatibility with
|
|
prior versions of Shorewall.
|
|
|
|
Shorewall-shell users may:
|
|
|
|
a) Accept the new default -- martians will be logged from all
|
|
interfaces with the route filtering enabled.
|
|
|
|
b) Explicitly set LOG_MARTIONS=No to maintain compatibility with
|
|
prior versions of Shorewall.
|
|
|
|
5) The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has
|
|
been changed from Yes to No.
|
|
|
|
6) The 'norfc1918' option is deprecated. Use explicit rules instead.
|
|
Note that there is a new 'Rfc1918' macro that acts on addresses
|
|
reserved by RFC 1918.
|
|
|
|
Problems Corrected in Shorewall 4.1.8
|
|
|
|
1) Changes to your configuration made by NULL_ROUTE_RFC1918=Yes are
|
|
now reversed during 'shorewall stop' and 'shoreawll restart'.
|
|
|
|
2) The init script on Debian now reads and utilizes the value of the
|
|
OPTIONS variable from /etc/default/shorewall[-lite]. Previously,
|
|
the value of that variable was not passed to the shorewall[-lite]
|
|
command.
|
|
|
|
3) With both Shorewall and Shorewall Lite, the 'start' and 'restart'
|
|
commands now support a '-p' option. This option causes the
|
|
Netfilter connection tracking table to be flushed (purged) as part
|
|
of the operation. The 'conntrack' utility must be installed to use
|
|
this option.
|
|
|
|
Other Changes in Shoreall 4.1.8.
|
|
|
|
1) When using Shorewall-perl, the CEIL and RATE columns must now
|
|
contain arithmetic expressions consisting of:
|
|
|
|
a) Numeric digits (Hex numbers not allowed).
|
|
b) Parentheses.
|
|
c) The arithmetic operators +-* and /.
|
|
d) The word 'full'.
|
|
|
|
2) The installers (install.sh) now auto-detect a Cygwin environment
|
|
and install under the current user's ID if OWNER and GROUP are not
|
|
given.
|
|
|
|
3) The 'start' and 'restart' commands now support a '-p' (purge)
|
|
option which cause all entries to be removed from the Netfilter
|
|
conntrack table. In order to use this option, the 'conntrack'
|
|
utility must be installed on your system. Although it is generally
|
|
not installed by default, Most distributions have this utility in
|
|
their repositories.
|
|
|
|
New Features in Shorewall 4.1.
|
|
|
|
1) Shorewall 4.1 contains support for multiple Internet providers
|
|
through a single ethernet interface. Configuring two providers
|
|
through a single interface differs from two providers through two
|
|
interfaces in several ways.
|
|
|
|
a) Only ethernet (or ethernet-like) interfaces can be used. For
|
|
inbound traffic, the MAC addresses of the gateway routers is used
|
|
to determine which provider a packet was received through. Note
|
|
that only routed traffic can be categorized using this technique.
|
|
|
|
b) You must specify the address on the interface that corresponds to
|
|
a particular provider in the INTERFACE column by following the
|
|
interface name with a colon (":") and the address.
|
|
|
|
c) Entries in /etc/shorewall/masq must be qualified by the provider
|
|
name (or number).
|
|
|
|
d) This feature requires Realm Match support in your kernel and
|
|
iptables. If you use a capabilities file, you need to regenerate
|
|
the file with Shorewall 4.1 or Shorewall-lite 4.1.
|
|
|
|
e) You must add route_rules entries for networks that are accessed
|
|
through a particular provider.
|
|
|
|
f) If you have additional IP addresses through either provider,
|
|
you must add route_rules to direct traffic FROM each of those
|
|
addresses through the appropriate provider.
|
|
|
|
g) You must add MARK rules for any traffic that you know originates
|
|
from a particular provider.
|
|
|
|
Example:
|
|
|
|
Providers Blarg (1) and Avvanta (2) are both connected to
|
|
eth0. The firewall's IP address with Blarg is 206.124.146.176/24
|
|
(gateway 206.124.146.254) and the IP address from Avvanta is
|
|
130.252.144.8/24 (gateway 130.252.144.254). We have a second IP
|
|
address (206.124.146.177) from Blarg.
|
|
|
|
/etc/shorewall/providers:
|
|
|
|
#PROVIDER NUMBER MARK DUPLICATE INTERFACE GATEWAY
|
|
Blarg 1 1 main eth0:206.124.146.176 206.124.146.254 ...
|
|
Avvanta 2 2 main eth0:130.252.144.8 130.252.144.254 ...
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0(Blarg) 130.252.144.8 206.124.146.176
|
|
eth0(Avvanta) 206.124.146.176 130.252.144.8
|
|
eth0(Blarg) eth1 206.124.146.176
|
|
eth0(Avvanta) eth1 130.252.144.8
|
|
|
|
/etc/shorewall/route_rules:
|
|
|
|
#SOURCE DEST PROVIDER PRIORITY
|
|
- 206.124.146.0/24 Blarg 1000
|
|
- 130.252.144.0/24 Avvanta 1000
|
|
206.124.146.177 - Blarg 26000
|
|
|
|
/etc/shorewall/tcrules
|
|
|
|
#MARK/CLASSIFY SOURCE DEST
|
|
1 eth0:206.124.146.0/24 0.0.0.0/0
|
|
2 eth0:130.242.144.0/24 0.0.0.0/0
|
|
|
|
2) You may now include the name of a table (nat, mangle or filter) in
|
|
a 'shorewall refresh' command by following the table name with a
|
|
colon (e.g., mangle:). This causes all non-builtin chains in the
|
|
table to be reloaded.
|
|
|
|
Example:
|
|
|
|
shorewall refresh nat:
|
|
|
|
3) When no chain name is given to the 'shorewall refresh' command, the
|
|
mangle table is refreshed along with the blacklist chain (if
|
|
any). This allows you to modify /etc/shorewall/tcrules and install
|
|
the changes using 'shorewall refresh'.
|
|
|
|
4) Support for the NFLOG log target has been added. NFLOG is a
|
|
successor to ULOG. In addition, both ULOG and NFLOG may be followed
|
|
by a list of up to three numbers in parentheses.
|
|
|
|
The first number specifies the netlink group (1-32). If omitted
|
|
(e.g., NFLOG(,0,10)) then a value of 1 is assumed.
|
|
|
|
The second number specifies the maximum number of bytes to copy. If
|
|
omitted, 0 (no limit) is assumed.
|
|
|
|
The third number specifies the number of log messages that should
|
|
be buffered in the kernel before they are sent to user space. The
|
|
default is 1.
|
|
|
|
Examples:
|
|
|
|
/etc/shorewall/shorewall.conf:
|
|
|
|
MACLIST_LOG_LEVEL=NFLOG(1,0,1)
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080
|
|
|
|
5) Shorewall-perl 4.1 implements an alternative syntax for macro
|
|
parameters and for the NFQUEUE queue number. Rather than following
|
|
the macro name (or NFQUEUE) with a slash ("/") and the parameter,
|
|
the parameter may be enclosed in parentheses.
|
|
|
|
Examples -- each pair shown below are equivalent:
|
|
|
|
DNS/ACCEPT DNS(ACCEPT)
|
|
NFQUEUE/3 NFQUEUE(3)
|
|
|
|
The old syntax will still be accepted but will cease to be documented
|
|
in some future Shorewall release.
|
|
|
|
6) Shorewall 4.1 contains enhanced operational logging capabilities
|
|
through a set of related enhancements to Shorewall-common and
|
|
Shorewall-perl. The enhancements are not supported by
|
|
Shorewall-shell nor are they supported by Shorewall-lite except
|
|
when the script is compiled using Shorewall-perl.
|
|
|
|
a) The STARTUP_LOG option in /etc/shorewall/shorewall.conf gives
|
|
the name of the Shorewall operational log. The log will be
|
|
created if it does not exist.
|
|
|
|
b) The LOG_VERBOSITY option in /etc/shorewall/shorewall.conf gives
|
|
the verbosity at which logging will occur. It uses the same
|
|
value range as VERBOSITY:
|
|
|
|
-1 Do not log
|
|
0 Almost quiet
|
|
1 Only major steps
|
|
2 Verbose
|
|
|
|
c) An absolute VERBOSITY may be specified on the command line
|
|
using the -v option followed by -1,0,1 or 2.
|
|
|
|
Example:
|
|
|
|
shorewall -v2 check
|
|
|
|
d) The /etc/init.d/shorewall script supplied with the
|
|
shorewall.net packages sets '-v0' as the default. This may be
|
|
overridden with the OPTIONS setting in /etc/defaults/shorewall or
|
|
/etc/sysconfig/shorewall.
|
|
|
|
Logging occurs on both Shorewall-perl and the generated script when
|
|
the following commands are issued:
|
|
|
|
start
|
|
restart
|
|
refresh
|
|
|
|
Messages in the log are always timestamped.
|
|
|
|
This change implemented two new options to the Shorewall-perl
|
|
compiler (/usr/share/shorewall-perl/compiler.pl).
|
|
|
|
--log=<logfile>
|
|
--log_verbosity={-1|0-2}
|
|
|
|
The --log option is ignored when --log_verbosity is not supplied or
|
|
is supplied with value -1.
|
|
|
|
To avoid a proliferation of parameters to
|
|
Shorewall::Compiler::compile(), that function has been changed to
|
|
use named parameters. Parameter names are:
|
|
|
|
object Object file. If omitted or '', the
|
|
configuration is syntax checked.
|
|
directory Directory. If omitted or '', configuration
|
|
files are located using
|
|
CONFIG_PATH. Otherwise, the directory named by
|
|
this parameter is searched first.
|
|
verbosity Verbosity; range -1 to 2
|
|
timestamp 0|1 -- timestamp messages.
|
|
debug 0|1 -- include stack trace in warning/error
|
|
messages.
|
|
export 0|1 -- compile for export.
|
|
chains List of chains to be reloaded by 'refresh'.
|
|
log File to log compiler messages to.
|
|
log_verbosity Log Verbosity; range -1 to 2.
|
|
|
|
Those parameters that are supplied must have defined values.
|
|
|
|
Defaults are:
|
|
|
|
object '' ('check' command)
|
|
directory ''
|
|
verbosity 1
|
|
timestamp 0
|
|
debug 0
|
|
export 0
|
|
chains ''
|
|
log ''
|
|
log_verbosity -1
|
|
|
|
|
|
Example:
|
|
|
|
use lib '/usr/share/shorewall-perl/';
|
|
use Shorewall::Compiler;
|
|
|
|
compiler( object => '/root/firewall',
|
|
log => '/root/compile.log',
|
|
log_verbosity => 2 );
|
|
|
|
7) Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
|
|
mark values < 256 to be assigned in the OUTPUT chain. This has been
|
|
changed so that only high mark values may be assigned
|
|
there. Packet marking rules for traffic shaping of packets
|
|
originating on the firewall must be coded in the POSTROUTING chain.
|
|
|
|
8) Previously, Shorewall did not range-check the value of the
|
|
VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.1:
|
|
|
|
a) A VERBOSITY setting outside the range -1 through 2 is rejected.
|
|
b) After the -v and -q options are applied, the resulting value is
|
|
adjusted to fall within the range -1 through 2.
|
|
|
|
9) The tcdevices file has been extended to include an OPTIONS
|
|
column. Currently only a single option is defined.
|
|
|
|
classify When specified, you must use explicit CLASSIFY tcrules
|
|
to classify traffic by class. Shorewall will not create
|
|
any CLASSIFY rules to classify traffic by mark value.
|
|
|
|
See http://www.shorewall.net/traffic_shaping.htm for further
|
|
information.
|
|
|
|
10) COMMENT lines are now supported in macro bodies by Shorewall-perl
|
|
and are ignored by the Shorewall-shell compiler.
|
|
|
|
COMMENT lines in macros work slightly differently from COMMENT
|
|
lines in other files. COMMENT lines in macros are ignored if
|
|
COMMENT support is not available or if there was a COMMENT in use
|
|
when the top-level macro was invoked. This allows the
|
|
following:
|
|
|
|
/etc/shorewall/macro.SSH:
|
|
|
|
#ACTION SOURCE PROTO DEST SOURCE RATE USER/
|
|
# PORT(S) PORT(S) LIMIT GROUP
|
|
COMMENT My SSH Macro
|
|
PARAM - - tcp 22
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
COMMENT Allow SSH from home
|
|
SSH/ALLOW net:$MYIP $FW
|
|
COMMENT
|
|
|
|
The comment line in macro.SSH will not override the
|
|
COMMENT line in the rules file and the generated rule will show
|
|
|
|
/* Allow SSH from home */
|
|
|
|
when displayed through the Shorewall show and dump commands.
|
|
|
|
If a macro is invoked and there is no current comment, then the
|
|
name of the macro automatically becomes the current comment. This
|
|
makes macros self-commenting.
|
|
|
|
11) If the program named in SHOREWALL_SHELL doesn't exist or is not
|
|
executable, Shorewall and Shorewall-lite now both fall back to
|
|
/bin/sh after issuing a warning message. Previously, both
|
|
terminated with a fatal error.
|
|
|
|
12) Shorewall-perl now generates fatal error conditions if there are
|
|
no IPv4 zones defined or there are no interfaces defined.
|
|
|
|
13) Shorewall now unconditionally uses tc filter rules to classify
|
|
traffic by MARK value. Previously, Shorewall used the CLASSIFY
|
|
target in the POSTROUTING chain if it was available.
|
|
|
|
14) The Shorewall installers (install.sh) now work on Windows
|
|
under Cygwin. By default, they install under the user id and group
|
|
of the person doing the install. This can be overridden by
|
|
specifying OWNER and GROUP explicitly.
|
|
|
|
Example:
|
|
|
|
OWNER=foo GROUP=bar ./install.sh
|
|
|
|
To install Shorewall-perl under Cygwin:
|
|
|
|
$ tar -zxf shorewall-perl-4.x.y.tar.bz2
|
|
$ tar -zxf shorewall-common-4.x.y.tar.bz2
|
|
$ cd shorewall-perl-4.x.y
|
|
$ ./install.sh
|
|
$ cd ../shorewall-common-4.x.y
|
|
$ ./install.sh
|
|
|
|
The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).
|
|
|
|
15) When installing on Cygwin, /etc/shorewall is no longer fully
|
|
populated. Rather, only the shorewall.conf and params files are
|
|
installed. As always, the full configuration file set is installed
|
|
in /usr/share/shorewall/configfiles.
|
|
|
|
16) Specifying a destination zone in a NAT-only rule now generates a
|
|
warning and the destination zone is ignored. NAT-only rules are:
|
|
|
|
NONAT
|
|
REDIRECT-
|
|
DNAT-
|
|
|
|
17) The /etc/shorewall/masq and /etc/shorewall/nat file now accept a
|
|
comma-separated list of interface names where before only a single
|
|
interface name could be listed (Shorewall-perl only).
|
|
|
|
This feature is not for beginners. It iterates over the
|
|
list of interfaces, substituting each interface in place of the
|
|
list and processing the resulting entry according to the semantics
|
|
of earlier Shorewall versions. If you don't know where to use this,
|
|
don't try.
|
|
|
|
Example 1:
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0,eth1 eth2 1.2.3.4
|
|
|
|
equivalent to:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0 eth2 1.2.3.4
|
|
eth1 eth2 1.2.3.4
|
|
|
|
Example 2:
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0,eth1::192.168.1.0/24 eth2 1.2.3.4
|
|
|
|
equivalent to:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0::192.168.1.0/24 eth2 1.2.3.4
|
|
eth1::192.168.1.0/24 eth2 1.2.3.4
|
|
|
|
Example 3:
|
|
|
|
/etc/shorewall/nat:
|
|
|
|
#EXTERNAL INTERFACE INTERNAL
|
|
206.124.146.178 eth0,wlan0 192.168.1.3
|
|
|
|
equivalent to:
|
|
|
|
#EXTERNAL INTERFACE INTERNAL
|
|
206.124.146.178 eth0 192.168.1.3
|
|
206.124.146.178 wlan0 192.168.1.3
|
|
|
|
18) Previously, the INTERFACE name used in the masq, nat and netmap
|
|
files had to exactly match the name of an interface from the
|
|
interfaces file. Beginning with Shorewall-perl 4.1.4, the
|
|
interface may loosely match a wildcard entry in the interfaces
|
|
file.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
vpn tun+
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
tun1 192.168.4.0/24
|
|
|
|
19) Previously, Shorewall classified non-firewall zones as either
|
|
'simple' or 'complex'. Attributes of a zone which made it 'complex'
|
|
included:
|
|
|
|
- The zone was of type 'ipsec' or 'ipsec4' or it had a hosts
|
|
entry with the 'ipsec' options.
|
|
- The zone had OPTIONS, IN OPTIONS or OUT OPTIONS
|
|
- The zone had more than one network on a given interface
|
|
- The zone had a hosts file entry with an exclusion.
|
|
- The zone had a hosts file entry specifying an ipset.
|
|
|
|
The handling of 'simple' and 'complex' zones was different.
|
|
|
|
- complex zones had their own 'forward' chain (named
|
|
'<zone>_frwd').
|
|
- complex zones with exclusions had their own 'input' and
|
|
'output' chains.
|
|
|
|
Beginning with Shorewall-perl 4.1, all non-firewall zones will be
|
|
treated as 'complex'. This will have the effect of one additional
|
|
filter chain per zone but in most cases, the average number of
|
|
filter rules traversed by a connection request will be reduced.
|
|
|
|
20) The need for interface-specific chains (such as eth0_in, eth4_fwd,
|
|
etc.) in the filter table has been drastically reduced. This has
|
|
the effect of reducing the average number of rules that each packet
|
|
must traverse.
|
|
|
|
21) The default value for LOG_MARTIANS is now 'Yes' ('On' in
|
|
Shorewall-perl). Previously, the default value was 'No' ('Off' in
|
|
Shorewall-perl). The shorewall.conf file has also been
|
|
updated to specify a value of 'Yes' (which is interpreted as 'On'
|
|
by Shorewall-perl).
|
|
|
|
22) Shorewall-perl now generates an error when a MAC address appears in
|
|
a traffic shaping rule in the OUTPUT or POSTROUTING chains.
|
|
|
|
23) Macros are now self-commenting under control of a new AUTO_COMMENT
|
|
option in shorewall.conf. When this option is set, if there is not
|
|
a current comment when a macro is invoked, the behavior under
|
|
Shorewall-perl is as if the first line of the macro file was
|
|
"COMMENT <macro name>".
|
|
|
|
So, if you have this rule:
|
|
|
|
SSH/ACCEPT loc fw
|
|
|
|
then the generated netfilter rule will include "/* SSH */" when
|
|
viewed with 'iptables -L' or 'shorewall show loc2fw' or 'shorewall
|
|
dump'.
|
|
|
|
The AUTO_COMMENT option has a default value of 'Yes' and is only
|
|
available under Shorewall-perl. The option is ignored by
|
|
Shorewall-shell.
|
|
|
|
24) The default value for the IMPLICIT_CONTINUE option has been changed
|
|
to 'No'.
|
|
|
|
25) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP
|
|
port 1701 in both directions and assumes that the source port will
|
|
also be 1701. Some implementations (particularly OS X) use a
|
|
different source port. In that case, you should use
|
|
'generic:udp:1701' rather than 'l2tp'.
|
|
|
|
26) The /etc/shorewall/tcdevices and /etc/shorewall/tcclasses files
|
|
have undergone some changes, especially when the 'classify' option
|
|
has been specified.
|
|
|
|
Normally Shorewall assigns interface numbers sequentially to
|
|
devices listed in /etc/shorewall/tcdevices. Beginning with
|
|
Shorewall 4.1.6, you can explicitly specify inteface numbers by
|
|
prefixing the interface name with the interface number and a colon:
|
|
|
|
Example:
|
|
|
|
#INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS
|
|
1:eth0 1300kbit 384kbit classify
|
|
2:eth1 5600kbit 1000kbit
|
|
|
|
In /etc/shorewall/tcclasses:
|
|
|
|
a) You can specify the INTERFACE using either the interface name
|
|
or interface number.
|
|
|
|
b) classes associated with devices which have the 'classify'
|
|
option _must_ specify a class number by following the interface
|
|
name/number with a colon (":") and the class number. The same
|
|
class number may be used for classes defined on different
|
|
interfaces but a class number may not be the same as any
|
|
interface number.
|
|
|
|
A class number may be specified when 'classify' has not been
|
|
specified for the associated device. When a class number has not
|
|
been given, the default class number remains the mark value
|
|
prefixed by "1".
|
|
|
|
27) Shorewall now supports Intermediate Functional Block (IFB) devices.
|
|
These devices allow shaping of incoming traffic.
|
|
|
|
The 'ifb' module is available in the kernels included with today's
|
|
distributions. You must load the module manually:
|
|
|
|
If your distribution has modprobe:
|
|
|
|
modprobe ifb [ numifbs=<number> ]
|
|
|
|
Otherwise:
|
|
|
|
insmod <path to net driver modules>/ifb.ko [ numifbs=<number> ]
|
|
|
|
By default, the module automatically creates two IFB devices (ifb0
|
|
and ifb1). To create only one, specify 'numifbs=1'.
|
|
|
|
Example:
|
|
|
|
ursa:~ # modprobe ifb numifbs=1
|
|
ursa:~ # ip link ls
|
|
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
|
|
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
|
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
|
|
link/ether cc:2b:cb:24:1b:00 brd ff:ff:ff:ff:ff:ff
|
|
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
|
|
link/ether 00:1a:73:db:8c:35 brd ff:ff:ff:ff:ff:ff
|
|
4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop qlen 32
|
|
link/ether 26:99:d8:7d:32:26 brd ff:ff:ff:ff:ff:ff
|
|
ursa:~ #
|
|
|
|
After you have created the IFB(s), you must bring it(them) up:
|
|
|
|
ip link set dev ifb0 up
|
|
|
|
You can place all of this in /etc/shorewall/init as follows:
|
|
|
|
modprobe ifb numifbs=1
|
|
ip link set dev ifb0 up
|
|
|
|
The /etc/shorewall/tcdevices file has been extended to include an
|
|
additional REDIRECTED DEVICES column. To convert your configuration
|
|
to use an IFB:
|
|
|
|
a) Look at your current /etc/shorewall/tcdevices file. Suppose you
|
|
have:
|
|
|
|
#INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS
|
|
eth0 1300kbit 384kbit -
|
|
|
|
Change it as follows:
|
|
|
|
#INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED
|
|
# DEVICES
|
|
eth0 - 384kkbit -
|
|
ifb0 - 1300kbit - eth0
|
|
|
|
Note that the old IN-BANDWIDTH for eth0 has become the
|
|
OUT-BANDWIDTH for ifb0 and that neither device has an
|
|
IN-BANDWIDTH in the new configuration.
|
|
|
|
Finally note that eth0 has been specified as a REDIRECTED device
|
|
for the IFB.
|
|
|
|
b) There are no Netfilter hooks between the real device (eth0) and
|
|
the IFB (ifb0). So tcrules cannot be used to specify shaping of
|
|
traffic leaving the IFB. To allow that traffic to be classified,
|
|
a new /etc/shorewall/tcfilters file has been added.
|
|
|
|
/etc/shorewall/tcfilters can be used for classifying traffic on
|
|
any interface. When using entries in that file, it is important
|
|
to realize that those entries act on packets as they appear 'on
|
|
the wire'. That means that on output, SNAT/MASQUERADE has been
|
|
applied and on input (output to an IFB), DNAT has not yet been
|
|
applied.
|
|
|
|
Columns in the file are:
|
|
|
|
INTERFACE:CLASS
|
|
|
|
The interface name or number followed by a colon (":")
|
|
and the class number.
|
|
|
|
SOURCE
|
|
Source IP address. May be a host or network address.
|
|
Specify "-" if any SOURCE address should match.
|
|
|
|
DEST
|
|
Destination IP address. May be a host or network
|
|
address. Specify "-" if any DEST address should match.
|
|
|
|
PROTO
|
|
Protocol Name/Number. Specify "-" if any PROTO should
|
|
match.
|
|
|
|
DEST PORT(S)
|
|
A comma-separated list of destination ports. May only
|
|
be given if the PROTO is tcp, udp, icmp or
|
|
sctp. Port ranges may be used, except when the PROTO is
|
|
icmp. Specify "-" if any PORT should match.
|
|
|
|
SOURCE PORT(S)
|
|
A comma-separated list of source port. May only be
|
|
given if the PROTO is tcp, udp or sctp. Port ranges
|
|
may be used unless the protocol is icmp. Specify "-" if
|
|
any PORT should match.
|
|
|
|
Entries in /etc/shorewall/tcfilters generate U32 tc filters which
|
|
may be displayed using the "shorewall show filters" ("shorewall-lite
|
|
show filters") command. Note: The 'show filters' command is an
|
|
alias for the existing 'show classifiers' command.
|
|
|
|
Note that /etc/shorewall/tcfilters provides a usable alternative to
|
|
HIGH_ROUTE_MARKS=Yes. You can use marks to select between providers
|
|
and use entries in /etc/shorewall/tcfilters (or CLASSIFY tcrules)
|
|
for traffic shaping.
|
|
|
|
28) If an interface fails when using balanced multi-ISP routing, the
|
|
default route is lost. If there are remaining working interfaces
|
|
with dynamic gateway addresses, Shorewall will be unable to
|
|
determine those gateways.
|
|
|
|
Beginning with Shorewall (Shorewall-lite) 4.1.7, the 'init' script
|
|
may participate in gateway detection by setting variables with
|
|
pre-determined names as follows:
|
|
|
|
<gw>_GATEWAY
|
|
|
|
where <gw> is the interface name:
|
|
|
|
- in upper case
|
|
- with any characters not allowed in shell variable names
|
|
replaced by '_'.
|
|
|
|
Example (from OpenWRT):
|
|
|
|
Interface: eth0.1
|
|
Variable: ETH0_1_GATEWAY
|
|
/etc/shorewall/init:
|
|
|
|
ETH0_1_GATEWAY=$(uci get /var/state/network.wan0.gateway)
|
|
|
|
29) A new CONNBYTES column has been added to the tcrules file. The
|
|
column defines a byte or packet range that the connection must fall
|
|
within in order for the rule to match. The contents are:
|
|
|
|
[!]<min>:[<max>[:{O|R|B}[:{B|P|A}]]]
|
|
|
|
! matches if the the packet/byte count is not within the range
|
|
defined by <min> and <max>.
|
|
|
|
<min> is an integer which defines the beginning of the byte/packet
|
|
range.
|
|
|
|
<max> is an integer which defines the end of the byte/packet range.
|
|
If omitted, only the beginning of the range is checked.
|
|
|
|
The first letter gives the direction which the range refers to:
|
|
|
|
O - The original direction of the connection.
|
|
R - The opposite direction from the original connection.
|
|
B - The total of both directions.
|
|
|
|
If omitted, 'B' is assumed.
|
|
|
|
The second letter determins what the range refers to.
|
|
|
|
B - Bytes
|
|
P - Packets
|
|
A - Average packet size.
|
|
|
|
If omitted, 'B' is assumed.
|
|
|
|
Examples:
|
|
|
|
1000000: - Connection has transferred a total of
|
|
at least 1,000,000 bytes.
|
|
|
|
1000000::R - Connection has transferred at least
|
|
1,000,000 bytes in the direction opposite
|
|
of the original direction (typical of a
|
|
large download).
|
|
|
|
1000000::O:P - Connection has sent at least 1,000,000
|
|
packets in the direction of the original
|
|
connection.
|
|
|
|
30) A new MANGLE_ENABLED option is added to shorewall.conf. The default
|
|
setting is 'Yes' which causes Shorewall to assume responsibility for
|
|
the Netfilter mangle table.
|
|
|
|
When MANGLE_ENABLED is set to 'No', Shorewall assumes no
|
|
responsibility for that table. In this setting:
|
|
|
|
a) Shorewall doesn't alter the mangle table.
|
|
b) You may not use Shorewall Traffic Shaping (TC_ENABLED must be
|
|
set to 'No'.
|
|
c) The tcrules file is ignored.
|
|
d) The providers file must be empty.
|
|
e) All entries in tcdevices must specify the 'classify' option and
|
|
traffic classification may only occur using the tcfilters file.
|
|
|
|
This allows for another application running on your firewall to
|
|
take over the mangle table and use it for it's own purposes.
|
|
|
|
31) Shorewall-perl now supports an ORIGINAL DEST column in macro files.
|
|
The column must be left empty if the macro is to be used in the
|
|
body of an action.
|
|
|
|
The new column is placed between the SOURCE PORT(S) and RATE LIMIT
|
|
columns. So that Shorewall-perl can determine which column layout
|
|
each macro has, a new FORMAT directive is added:
|
|
|
|
FORMAT {1|2}
|
|
|
|
The default is FORMAT 1 which is the old format. FORMAT 2 specifies
|
|
that the macro is in the new format.
|
|
|
|
32) Shorewall-perl implements a new Rfc1918 macro that deals with
|
|
RFC 1918 addresses. This macro should be used in place of
|
|
the 'norfc1918' interface option which is deprecated.
|
|
|
|
The macro body is:
|
|
|
|
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
|
|
# PORT(S) PORT(S) DEST LIMIT GROUP
|
|
FORMAT 2
|
|
PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \
|
|
DEST - - - - - -
|
|
PARAM SOURCE DEST - - - 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
|
|
|
|
The 'norfc1918' option on the interface associated with zone 'z'
|
|
and with RFC1018_STRICT=Yes is equivalent to:
|
|
|
|
Rfc1918(DROP) z all
|
|
|
|
33) A better way to perform RFC 1918 filtration is to null-route the
|
|
address ranges reserved by RFC 1918. You can do that by setting the
|
|
new NULL_ROUTE_RFC1918 option to 'Yes' in shorewall.conf.
|
|
|
|
It is highly recommended that you also set ROUTE_FILTER=Yes to get
|
|
Martian messages. These will help diagnose problems where you need
|
|
to be able to access hosts with RFC 1918 addresses that are outside
|
|
of your local networks. Sometimes, these can be subtle such as the
|
|
case where your ISP is using RFC 1918 addresses on their DHCP
|
|
servers.
|
|
|
|
NULL_ROUTE_RFC1918 defaults to 'No' and is only supported by
|
|
Shorewall-perl; Shorewall-shell ignores the option.
|
|
|
|
34) There is now a macro.SANE which supports network-attached
|
|
scanners. Shorewall now automatically loads the sane connection
|
|
tracking helper module.
|
|
|
|
Thanks for this feature go to Tuomo Soini.
|
|
|
|
35) Previously, when IP_FORWARDING=Yes in shorewall.conf, Shorewall
|
|
would enable ip forwarding before instantiating the rules. This
|
|
could lead to incorrect connection tracking entries being created
|
|
|
|
between the time that forwarding was enabled and when the nat table
|
|
rules were instantiated.
|
|
|
|
Beginning with Shorewall 4.0.11 and 4.1.7, enabling of forwarding
|
|
is deferred until after the rules are in place.
|
|
|