forked from extern/shorewall_code
dc17a6976d
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@8321 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
731 lines
25 KiB
Plaintext
731 lines
25 KiB
Plaintext
Shorewall 4.1 Patch Release 6.
|
|
|
|
----------------------------------------------------------------------------
|
|
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.
|
|
|
|
Problems corrected in Shorewall-perl 4.1.6.
|
|
|
|
1) A problem introduced in 4.1.5 would result in the following error
|
|
message.
|
|
|
|
ERROR: Internal error in create_netfilter_load()
|
|
|
|
2) Under Shorewall-perl, if an empty action was invoked or was named
|
|
in one of the DEFAULT_xxx options in shorewall.conf, an
|
|
iptables-restore error occured.
|
|
|
|
3) If $ADMIN was empty, then the rule:
|
|
|
|
ACCEPT loc:$ADMIN all
|
|
|
|
became
|
|
|
|
ACCEPT loc net
|
|
|
|
It is now flagged as an error.
|
|
|
|
Problems corrected in Shorewall-shell 4.1.6.
|
|
|
|
1) Specifying a value for ACCEPT_DEFAULT or QUEUE_DEFAULT resulted in
|
|
a fatal error at compile time.
|
|
|
|
New Features in 4.1.6.
|
|
|
|
1) The default value for the IMPLICIT_CONTINUE option has been changed
|
|
to 'No'.
|
|
|
|
2) A REDIRECTED INTERFACES option has been added to the tcdevices file
|
|
to support using an IFB (Intermediate Functional Block) device.
|
|
|
|
IFBs can be used to shape incoming traffic by redirecting that
|
|
traffic through the IFB.
|
|
|
|
To use this feature:
|
|
|
|
a) Specify the name of your IFB in the INTERFACE column.
|
|
b) List the redirected device names (comma-separated) in the
|
|
REDIRECTED INTERFACES column.
|
|
|
|
Packets that are input from the redirected interface(s) will appear
|
|
as output packets on the IFB.
|
|
|
|
This support should be considered EXPERIMENTAL.
|
|
|
|
3) 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'.
|
|
|
|
4) 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".
|
|
|
|
5) 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> ]
|
|
|
|
The module automatically creates two IFB devices by default (ifb0
|
|
and ifb1). To create only one, specify 'numifbs'.
|
|
|
|
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 using 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 not be used. 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 not be used. 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.
|
|
|
|
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.
|
|
|
|
The 'classify' option should be specified when you want to do all
|
|
classification using CLASSIFY tcrules. Because CLASSIFY is not a
|
|
terminating target, every packet passes through all CLASSIFY
|
|
rules. 'classify' can prevent packets from having to pass through
|
|
useless additional rules.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/tcdevices
|
|
|
|
#INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS
|
|
$EXT_IF 1300kbit 384kbit classify
|
|
|
|
/etc/shorewall/tcclasses
|
|
|
|
#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
|
|
$EXT_IF 10 5*full/10 full 1 tcp-ack,tos-minimize-delay
|
|
$EXT_IF 20 2*full/10 6*full/10 2 default
|
|
$EXT_IF 30 2*full/10 6*full/10 3
|
|
|
|
/etc/shorewall/tcrules
|
|
|
|
#MARK SOURCE DEST PROTO PORT(S) SOURCE
|
|
# PORT(S)
|
|
1:110 192.168.0.0/22 $EXT_IF
|
|
1:130 206.124.146.177 $EXT_IF tcp - 873
|
|
|
|
This example shows my own simple traffic shaping configuration. I
|
|
have three classes; one for traffic from our local network, one for
|
|
rsync from the master shorewall.net server, and one for all other
|
|
DMZ traffic. I use CLASSIFY rules to assign traffic to the first
|
|
and third class and let the rest default to the second class.
|
|
|
|
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-common installer (install.sh) now works on Windows
|
|
under Cygwin.
|
|
|
|
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
|
|
$ USER=<your user id> GROUP=None ./install.sh
|
|
$ cd ../shorewall-common-4.x.y
|
|
$ USER=<your user id> GROUP=None ./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.
|
|
|