forked from extern/shorewall_code
1987 lines
82 KiB
XML
1987 lines
82 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<refentry>
|
|
<refmeta>
|
|
<refentrytitle>shorewall6.conf</refentrytitle>
|
|
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>shorewall6.conf</refname>
|
|
|
|
<refpurpose>Shorewall6 global configuration file</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>/etc/shorewall6/shorewall6.conf</command>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>This file sets options that apply to Shorewall6 as a whole.</para>
|
|
|
|
<para>The file consists of Shell comments (lines beginning with '#'),
|
|
blank lines and assignment statements
|
|
(<emphasis>variable</emphasis>=<emphasis>value</emphasis>). If the
|
|
<emphasis>value</emphasis> contains shell metacharacters or white-space,
|
|
then it must be enclosed in quotes. Example:
|
|
LOG_LEVEL="NFLOG(1,0,1)".</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>OPTIONS</title>
|
|
|
|
<para>Many options have as their value a <emphasis>log-level</emphasis>.
|
|
Log levels are a method of describing to syslog (8) the importance of a
|
|
message and a number of parameters in this file have log levels as their
|
|
value.</para>
|
|
|
|
<para>These levels are defined by syslog and are used to determine the
|
|
destination of the messages through entries in /etc/syslog.conf (5). The
|
|
syslog documentation refers to these as "priorities"; Netfilter calls them
|
|
"levels" and Shorewall6 also uses that term.</para>
|
|
|
|
<para>Valid levels are:</para>
|
|
|
|
<programlisting> 7 debug
|
|
6 info
|
|
5 notice
|
|
4 warning
|
|
3 err
|
|
2 crit
|
|
1 alert
|
|
0 emerg</programlisting>
|
|
|
|
<para>For most Shorewall6 logging, a level of 6 (info) is appropriate.
|
|
Shorewall6 log messages are generated by NetFilter and are logged using
|
|
facility 'kern' and the level that you specifify. If you are unsure of the
|
|
level to choose, 6 (info) is a safe bet. You may specify levels by name or
|
|
by number.</para>
|
|
|
|
<para>If you have built your kernel with NFLOG target support, you may
|
|
also specify a log level of NFLOG (must be all caps). Rather than log its
|
|
messages to syslogd, Shorewall6 will direct netfilter to log the messages
|
|
via the NFLOG target which will send them to a process called 'ulogd'.
|
|
ulogd is available with most Linux distributions (although it probably
|
|
isn't installed by default). Ulogd is also available from <ulink
|
|
url="http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</ulink>
|
|
and can be configured to log all Shorewall6 message to their own log
|
|
file</para>
|
|
|
|
<para>The following options may be set in shorewall6.conf.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">ACCEPT_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">DROP_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">NFQUEUE_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">QUEUE_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">REJECT_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>To allow for default rules to be applied when USE_ACTIONS=No,
|
|
the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT, QUEUE_DEFAULT and
|
|
NFQUEUE_DEFAULT options have been added.</para>
|
|
|
|
<para>DROP_DEFAULT describes the rules to be applied before a
|
|
connection request is dropped by a DROP policy; REJECT_DEFAULT
|
|
describes the rules to be applied if a connection request is
|
|
rejected by a REJECT policy. The other three are similar for ACCEPT,
|
|
QUEUE and NFQUEUE policies.</para>
|
|
|
|
<para>The value applied to these may be:</para>
|
|
|
|
<simplelist>
|
|
<member>a) The name of an
|
|
<replaceable>action</replaceable>.</member>
|
|
|
|
<member>b) The name of a <replaceable>macro</replaceable>
|
|
(Shorewall6-shell only)</member>
|
|
|
|
<member>c) <emphasis role="bold">None</emphasis> or <emphasis
|
|
role="bold">none</emphasis></member>
|
|
</simplelist>
|
|
|
|
<para>The default values are:</para>
|
|
|
|
<simplelist>
|
|
<member>DROP_DEFAULT="Drop"</member>
|
|
|
|
<member>REJECT_DEFAULT="Reject"</member>
|
|
|
|
<member>ACCEPT_DEFAULT="none"</member>
|
|
|
|
<member>QUEUE_DEFAULT="none"</member>
|
|
|
|
<member>NFQUEUE_DEFAULT="None"</member>
|
|
</simplelist>
|
|
|
|
<para>If USE_ACTIONS=Yes, then these values refer to action.Drop and
|
|
action.Reject respectively. If USE_ACTIONS=No, then these values
|
|
refer to macro.Drop and macro.Reject.</para>
|
|
|
|
<para>If you set the value of either option to "None" then no
|
|
default action will be used and the default action or macro must be
|
|
specified in <ulink
|
|
url="shorewall6-policy.html">shorewall6-policy</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ACCOUNTING=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.7. If set to Yes, Shorewall6 accounting
|
|
is enabled (see <ulink
|
|
url="shorewall6-accounting.html">shorewall6-accounting</ulink>(5)).
|
|
If not specified or set to the empty value, ACCOUNTING=Yes is
|
|
assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ACCOUNTING_TABLE=</emphasis>[<emphasis
|
|
role="bold">filter</emphasis>|<emphasis
|
|
role="bold">mangle</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.20. This setting determines which
|
|
Netfilter table the accounting rules are added in. By default,
|
|
ACCOUNTING_TABLE=filter is assumed. See also <ulink
|
|
url="shorewall-accounting.html">shorewall-accounting</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ADMINISABSENTMINDED=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this variable affects Shorewall6's stopped state.
|
|
When ADMINISABSENTMINDED=No, only traffic to/from those addresses
|
|
listed in <ulink
|
|
url="shorewall6-routestopped.html">shorewall6-routestopped</ulink>(5)
|
|
is accepted when Shorewall6 is stopped. When
|
|
ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
|
|
<ulink
|
|
url="shorewall6-routestopped.html">shorewall6-routestopped</ulink>(5),
|
|
connections that were active when Shorewall6 stopped continue to
|
|
work and all new connections from the firewall system itself are
|
|
allowed. If this variable is not set or is given the empty value
|
|
then ADMINISABSENTMINDED=No is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">AUTO_COMMENT=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If set, if there is not a current comment when a macro is
|
|
invoked, the behavior is as if the first line of the macro file was
|
|
"COMMENT <macro name>". The AUTO_COMMENT option has a default
|
|
value of 'Yes'.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">AUTOMAKE=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If set, the behavior of the <command>start</command> and
|
|
<command>restart</command> commands is change; if no files in
|
|
<filename><filename
|
|
class="directory">/etc/shorewall</filename></filename> have been
|
|
changed since the last successful <command>start</command> or
|
|
<command>restart</command> command, then the compilation step is
|
|
skipped and the compiled script that executed the last
|
|
<command>start</command> or <command>restart</command> command is
|
|
used. The default is AUTOMAKE=No.</para>
|
|
|
|
<para>The setting of the AUTOMAKE option is ignored if the
|
|
<command>start</command> or <command>restart</command> command
|
|
includes a directory name (e.g.,<command> shorewall6 restart
|
|
/etc/shorewall.new</command>).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">BLACKLIST_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">DROP</emphasis>|A_DROP|<emphasis
|
|
role="bold">REJECT|A_REJECT</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines the disposition of packets from
|
|
blacklisted hosts. It may have the value DROP if the packets are to
|
|
be dropped or REJECT if the packets are to be replied with an ICMP
|
|
port unreachable reply or a TCP RST (tcp only). If you do not assign
|
|
a value or if you assign an empty value then DROP is assumed. The
|
|
BLACKLIST_DISPOSITION setting has no effect on entries in the
|
|
BLACKLIST section of <ulink
|
|
url="shorewall6-rules.html">shorewall6-rules</ulink> (5). It
|
|
determines the disposition of packets sent to the <emphasis
|
|
role="bold">blacklog</emphasis> target of <ulink
|
|
url="shorewall6-blrules.html">shorewall6-blrules</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">BLACKLIST_LOGLEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines if packets from blacklisted hosts
|
|
are logged and it determines the syslog level that they are to be
|
|
logged at. Its value is a syslog level (Example:
|
|
BLACKLIST_LOGLEVEL=debug). If you do not assign a value or if you
|
|
assign an empty value then packets from blacklisted hosts are not
|
|
logged. The BLACKLIST_LOGLEVEL setting has no effect on entries in
|
|
the BLACKLIST section of <ulink
|
|
url="shorewall6-rules.html">shorewall6-rules</ulink> (5). It
|
|
determines the log level of packets sent to the <emphasis
|
|
role="bold">blacklog</emphasis> target of <ulink
|
|
url="shorewall6-blrules.html">shorewall6-blrules</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">BLACKLISTNEWONLY=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>When set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, blacklists are only consulted for new
|
|
connections. This includes entries in the <ulink
|
|
url="???">shorewall-blrules</ulink> (5) file and in the BLACKLIST
|
|
section of <ulink
|
|
url="shorewall6-rules.html">shorewall6-rules</ulink> (5).</para>
|
|
|
|
<para>When set to <emphasis role="bold">No</emphasis> or <emphasis
|
|
role="bold">no</emphasis>, blacklists are consulted for every packet
|
|
(will slow down your firewall noticably if you have large
|
|
blacklists). If the BLACKLISTNEWONLY option is not set or is set to
|
|
the empty value then BLACKLISTNEWONLY=No is assumed.</para>
|
|
|
|
<note>
|
|
<para>BLACKLISTNEWONLY=No is incompatible with
|
|
FASTACCEPT=Yes.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">CLAMPMSS=[</emphasis><emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|<emphasis>value</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter enables the TCP Clamp MSS to PMTU feature of
|
|
Netfilter and is usually required when your internet connection is
|
|
through PPPoE or PPTP. If set to <emphasis
|
|
role="bold">Yes</emphasis> or <emphasis role="bold">yes</emphasis>,
|
|
the feature is enabled. If left blank or set to <emphasis
|
|
role="bold">No</emphasis> or <emphasis role="bold">no</emphasis>,
|
|
the feature is not enabled.</para>
|
|
|
|
<para><emphasis role="bold">Important</emphasis>: This option
|
|
requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.</para>
|
|
|
|
<para>You may also set CLAMPMSS to a numeric
|
|
<emphasis>value</emphasis> (e.g., CLAMPMSS=1400). This will set the
|
|
MSS field in TCP SYN packets going through the firewall to the
|
|
<emphasis>value</emphasis> that you specify.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">CLEAR_TC=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If this option is set to <emphasis role="bold">No</emphasis>
|
|
then Shorewall6 won't clear the current traffic control rules during
|
|
[re]start. This setting is intended for use by people that prefer to
|
|
configure traffic shaping when the network interfaces come up rather
|
|
than when the firewall is started. If that is what you want to do,
|
|
set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an
|
|
/etc/shorewall6/tcstart file. That way, your traffic shaping rules
|
|
can still use the “fwmark” classifier based on packet marking
|
|
defined in <ulink
|
|
url="shorewall6-tcrules.html">shorewall6-tcrules</ulink>(5). If not
|
|
specified, CLEAR_TC=No is assumed.</para>
|
|
|
|
<warning>
|
|
<para>If you also run Shorewall and if you have
|
|
TC_ENABLED=Internal in your <ulink
|
|
url="../manpages/shorewall.conf.html">shorewall-conf</ulink>(5),
|
|
then you will want CLEAR_TC=No in this file.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">COMPLETE=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall6 4.4.12. When you set this option to Yes,
|
|
you are asserting that the configuration is complete so that your
|
|
set of zones encompasses any hosts that can send or receive traffic
|
|
to/from/through the firewall. This causes Shorewall6 to omit the
|
|
rules that catch packets in which the source or destination IP
|
|
address is outside of any of your zones. Default is No. It is
|
|
recommended that this option only be set to Yes if:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>You have defined an interface whose effective physical
|
|
setting is '+'.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>That interface is assigned to a zone.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You have no CONTINUE policies or rules.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">CONFIG_PATH</emphasis>=[<emphasis>directory</emphasis>[:<emphasis>directory</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>Specifies where configuration files other than shorewall6.conf
|
|
may be found. CONFIG_PATH is specifies as a list of directory names
|
|
separated by colons (":"). When looking for a configuration file
|
|
other than shorewall6.conf:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If the command is "try" or a "<configuration
|
|
directory>" was specified in the command (e.g.,
|
|
<command>shorewall6 check ./gateway</command>) then the
|
|
directory given in the command is searched first.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Next, each directory in the CONFIG_PATH setting is
|
|
searched in sequence.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<blockquote>
|
|
<para>If CONFIG_PATH is not given or if it is set to the empty
|
|
value then the contents of /usr/share/shorewall6/configpath are
|
|
used. As released from shorewall.net, that file sets the
|
|
CONFIG_PATH to
|
|
/etc/shorewall6:/usr/share/shorewall6:/usr/share/shorewall but
|
|
your particular distribution may set it differently. See the
|
|
output of shorewall6 show config for the default on your
|
|
system.</para>
|
|
|
|
<para>Note that the setting in /usr/share/shorewall6/configpath is
|
|
always used to locate shorewall6.conf.</para>
|
|
</blockquote>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DELETE_THEN_ADD=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>If set to Yes (the default value), entries in the
|
|
/etc/shorewall6/route_stopped files cause an 'ip rule del' command
|
|
to be generated in addition to an 'ip rule add' command. Setting
|
|
this option to No, causes the 'ip rule del' command to be
|
|
omitted.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">DONT_LOAD=</emphasis>[<emphasis>module</emphasis>[,<emphasis>module</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>Causes Shorewall6 to not load the listed kernel
|
|
modules.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DYNAMIC_BLACKLIST=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.7. When set to <emphasis
|
|
role="bold">No</emphasis> or <emphasis role="bold">no</emphasis>,
|
|
dynamic blacklisting using the <command>shorewall6 drop</command>,
|
|
<command>shorewall6 reject</command>, <command>shorewall6
|
|
logdrop</command> and <command>shorewall6 logreject</command> is
|
|
disabled. Default is <emphasis role="bold">Yes</emphasis>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">EXPAND_POLICIES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally, when the SOURCE or DEST columns in
|
|
shorewall-policy(5) contains 'all', a single policy chain is created
|
|
and the policy is enforced in that chain. For example, if the policy
|
|
entry is<programlisting>#SOURCE DEST POLICY LOG
|
|
# LEVEL
|
|
net all DROP info</programlisting>then the chain name is 'net2all'
|
|
which is also the chain named in Shorewall log messages generated as
|
|
a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will
|
|
create a separate chain for each pair of zones covered by the
|
|
policy. This makes the resulting log messages easier to interpret
|
|
since the chain in the messages will have a name of the form 'a2b'
|
|
where 'a' is the SOURCE zone and 'b' is the DEST zone.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">EXPORTMODULES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.17. When set to Yes when compiling for
|
|
use by Shorewall6 Lite (<command>shorewall6 load</command>,
|
|
<command>shorewall6 reload </command>or <command>shorewall6
|
|
export</command> commands), the compiler will copy the modules or
|
|
helpers file from the administrative system into the script. When
|
|
set to No or not specified, the compiler will not copy the modules
|
|
or helpers file from <filename>/usr/share/shorewall6</filename> but
|
|
will copy the found in another location on the CONFIG_PATH.</para>
|
|
|
|
<para>When compiling for direct use by Shorewall6, causes the
|
|
contents of the local module or helpers file to be copied into the
|
|
compiled script. When set to No or not set, the compiled script
|
|
reads the file itself.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">EXPORTPARAMS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Deprecated beginning with Shorewall 4.4.17.</para>
|
|
|
|
<para>Beginning with Shorewall 4.4.17, the variables set in the
|
|
'params' file at compile time are available at run time with
|
|
EXPORTPARAMS=No. As a consequence, beginning with that version the
|
|
recommended setting is EXPORTPARAMS=No.</para>
|
|
|
|
<para>It is quite difficult to code a 'params' file that assigns
|
|
other than constant values such that it works correctly with
|
|
Shorewall6 Lite. The EXPORTPARAMS option works around this problem.
|
|
When EXPORTPARAMS=No, the 'params' file is not copied to the
|
|
compiler output.</para>
|
|
|
|
<para>With EXPORTPARAMS=No, if you need to set environmental
|
|
variables on the firewall system for use by your extension scripts,
|
|
then do so in the init extension script.</para>
|
|
|
|
<para>The default is EXPORTPARAMS=Yes which is the recommended
|
|
setting unless you are running Shorewall6 Lite.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">FASTACCEPT=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally, Shorewall6 defers accepting ESTABLISHED/RELATED
|
|
packets until these packets reach the chain in which the original
|
|
connection was accepted. So for packets going from the 'loc' zone to
|
|
the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the
|
|
'loc2net' chain.</para>
|
|
|
|
<para>If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets
|
|
are accepted early in the INPUT, FORWARD and OUTPUT chains. If you
|
|
set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED
|
|
or RELATED sections of <ulink
|
|
url="shorewall6-rules.html">shorewall6-rules</ulink>(5).</para>
|
|
|
|
<note>
|
|
<para>FASTACCEPT=Yes is incompatible with
|
|
BLACKLISTNEWONLY=No.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">FORWARD_CLEAR_MARK=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.11 Beta 3. Traditionally, Shorewall has
|
|
cleared the packet mark in the first rule in the mangle FORWARD
|
|
chain. This behavior is maintained with the default setting of this
|
|
option (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to
|
|
'No', packet marks set in the mangle PREROUTING chain are retained
|
|
in the FORWARD chains.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">HIGH_ROUTE_MARKS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Deprecated in Shorewall 4.4.26 in favor of
|
|
PROVIDER_OFFSET.</para>
|
|
|
|
<para>You may set HIGH_ROUTE_MARKS=Yes in to effectively divide the
|
|
packet mark and connection mark into two mark fields.</para>
|
|
|
|
<para>The width of the fields are determined by the setting of the
|
|
WIDE_TC_MARKS option.</para>
|
|
|
|
<para>When WIDE_TC_MARKS=No (the default):</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The MARK field in the providers file must have a value
|
|
that is less than 65536 and that is a multiple of 256 (using hex
|
|
representation, the values are 0x0100-0xFF00 with the low-order
|
|
8 bits being zero).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You may only set those mark values in the PREROUTING
|
|
chain.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Marks used for traffic shaping must still be in the range
|
|
of 1-255 and may still not be set in the PREROUTING
|
|
chain.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>When WIDE_TC_MARKS=Yes:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The MARK field in the providers file must have a value
|
|
that is a multiple of 65536 (using hex representation, the
|
|
values are 0x010000-0xFF0000 with the low-order 16 bits being
|
|
zero).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You may only set those mark values in the PREROUTING
|
|
chain.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Marks used for traffic shaping must be in the range of
|
|
1-16383 and may still not be set in the PREROUTING chain.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Regardless of the setting of WIDE_TC_MARKS, when you SAVE or
|
|
RESTORE in tcrules, only the TC mark value is saved or restored.
|
|
Shorewall handles saving and restoring the routing (provider)
|
|
marks.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">IMPLICIT_CONTINUE=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>When this option is set to <emphasis
|
|
role="bold">Yes</emphasis>, it causes subzones to be treated
|
|
differently with respect to policies.</para>
|
|
|
|
<para>Subzones are defined by following their name with ":" and a
|
|
list of parent zones (in <ulink
|
|
url="shorewall6-zones.html">shorewall6-zones</ulink>(5)). Normally,
|
|
you want to have a set of special rules for the subzone and if a
|
|
connection doesn't match any of those subzone-specific rules then
|
|
you want the parent zone rules and policies to be applied; see
|
|
<ulink url="shorewall6-nesting.html">shorewall6-nesting</ulink>(5).
|
|
With IMPLICIT_CONTINUE=Yes, that happens automatically.</para>
|
|
|
|
<para>If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set,
|
|
then subzones are not subject to this special treatment. With
|
|
IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
|
|
by including an explicit policy (one that does not specify "all" in
|
|
either the SOURCE or the DEST columns).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">IP</emphasis>=[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If specified, gives the pathname of the 'ip' executable. If
|
|
not specified, 'ip' is assumed and the utility will be located using
|
|
the current PATH setting.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">IP_FORWARDING=</emphasis>[<emphasis
|
|
role="bold">On</emphasis>|<emphasis
|
|
role="bold">Off</emphasis>|<emphasis
|
|
role="bold">Keep</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This rather useless parameter determines whether Shorewall6
|
|
enables or disables IPV6 Packet Forwarding on all interfaces
|
|
(/proc/sys/net/ipv6/config/all/forwarding). Possible values
|
|
are:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">On</emphasis> or <emphasis
|
|
role="bold">on</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>packet forwarding will be enabled.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Off</emphasis> or <emphasis
|
|
role="bold">off</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>packet forwarding will be disabled.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Keep</emphasis> or <emphasis
|
|
role="bold">keep</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Shorewall6 will neither enable nor disable packet
|
|
forwarding</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<blockquote>
|
|
<para>If this variable is not set or is given an empty value
|
|
(IP_FORWARD="") then IP_FORWARD=On is assumed.</para>
|
|
</blockquote>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">IP6TABLES=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter names the ip6tables executable to be used by
|
|
Shorewall6. If not specified or if specified as a null value, then
|
|
the ip6tables executable located using the PATH option is
|
|
used.</para>
|
|
|
|
<para>Regardless of how the ip6tables utility is located (specified
|
|
via IP6TABLES= or located via PATH), Shorewall6 uses the
|
|
ip6tables-restore and ip6tables-save utilities from that same
|
|
directory.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">IPSET</emphasis>=[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If specified, gives the pathname of the 'ipset' executable. If
|
|
not specified, 'ipset' is assumed and the utility will be located
|
|
using the current PATH setting.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">KEEP_RT_TABLES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>When set to <option>Yes</option>, this option prevents scripts
|
|
generated by Shorewall6 from altering the /etc/iproute2/rt_tables
|
|
database when there are entries in
|
|
<filename>/etc/shorewall6/providers</filename>. If you set this
|
|
option to <option>Yes</option> while Shorewall6 (Shorewall6-lite) is
|
|
running, you should remove the file
|
|
<filename>/var/lib/shorewall6/rt_tables</filename>
|
|
(<filename>/var/lib/shorewall6-lite/rt_tables</filename>) before
|
|
your next <command>stop</command>, <command>refresh</command>,
|
|
<command>restore</command> on <command>restart</command>
|
|
command.</para>
|
|
|
|
<para>The default is KEEP_RT_TABLES=No.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LEGACY_FASTSTART=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall6 4.4.20. If not specified, the default is
|
|
Yes which preserves the legacy behavior of <command>start
|
|
-f</command> (the modification times of the files in
|
|
<filename>/etc/shorewall6</filename> are compare with that of
|
|
<filename>/var/lib/shorewall6/restore</filename>). If set to No,
|
|
then the times are compared with that of
|
|
/var/lib/shorewall6/firewall, which is consistant with the way that
|
|
<command>restart -f</command> works.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOAD_HELPERS_ONLY=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.7. When set to Yes, restricts the set
|
|
of modules loaded by shorewall to those listed in
|
|
/var/lib/shorewall6/helpers and those that are actually used. When
|
|
not set, or set to the empty value, LOAD_HELPERS_ONLY=No is
|
|
assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOG_VERBOSITY=</emphasis>[<emphasis>number</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This option controls the amount of information logged to the
|
|
file specified in the STARTUP_LOG option.</para>
|
|
|
|
<para>Values are:</para>
|
|
|
|
<simplelist>
|
|
<member>-1 - Logging is disabled</member>
|
|
|
|
<member>0 - Silent. Only error messages are logged.</member>
|
|
|
|
<member>1 - Major progress messages logged.</member>
|
|
|
|
<member>2 - All progress messages logged</member>
|
|
</simplelist>
|
|
|
|
<para>If not specified, then -1 is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGALLNEW=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This option is intended for use as a debugging aid. When set
|
|
to a log level, this option causes Shorewall6 to generate a logging
|
|
rule as the first rule in each builtin chain.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The table name is used as the chain name in the log
|
|
prefix.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The chain name is used as the target in the log
|
|
prefix.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para></para>
|
|
|
|
<blockquote>
|
|
<para>For example, using the default LOGFORMAT, the log prefix for
|
|
logging from the nat table's PREROUTING chain is:</para>
|
|
|
|
<programlisting> Shorewall:nat:PREROUTING
|
|
</programlisting>
|
|
|
|
<important>
|
|
<para>To help insure that all packets in the NEW state are
|
|
logged, rate limiting (LOGBURST and LOGRATE) should be disabled
|
|
when using LOGALLNEW. Use LOGALLNEW at your own risk; it may
|
|
cause high CPU and disk utilization and you may not be able to
|
|
control your firewall after you enable this option.</para>
|
|
</important>
|
|
|
|
<para></para>
|
|
|
|
<caution>
|
|
<para>Do not use this option if the resulting log messages will
|
|
be sent to another system.</para>
|
|
</caution>
|
|
</blockquote>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGFILE=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter tells the /sbin/shorewall6 program where to
|
|
look for Shorewall6 messages when processing the <emphasis
|
|
role="bold">dump</emphasis>, <emphasis
|
|
role="bold">logwatch</emphasis>, <emphasis role="bold">show
|
|
log</emphasis>, and <emphasis role="bold">hits</emphasis> commands.
|
|
If not assigned or if assigned an empty value, /var/log/messages is
|
|
assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOGFORMAT=</emphasis>[<emphasis
|
|
role="bold">"</emphasis><emphasis>formattemplate</emphasis><emphasis
|
|
role="bold">"</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this variable generate the --log-prefix setting
|
|
for Shorewall6 logging rules. It contains a “printf” formatting
|
|
template which accepts three arguments (the chain name, logging rule
|
|
number (optional) and the disposition). To use LOGFORMAT with
|
|
fireparse, set it as:</para>
|
|
|
|
<programlisting> LOGFORMAT="fp=%s:%d a=%s "</programlisting>
|
|
|
|
<para>If the LOGFORMAT value contains the substring “%d” then the
|
|
logging rule number is calculated and formatted in that position; if
|
|
that substring is not included then the rule number is not included.
|
|
If not supplied or supplied as empty (LOGFORMAT="") then
|
|
“Shorewall6:%s:%s:” is assumed.</para>
|
|
|
|
<note>
|
|
<para>The setting of LOGFORMAT has an effect of the permitted
|
|
length of zone names. See <ulink
|
|
url="shorewall6-zones.html">shorewall6-zones</ulink> (5).</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGLIMIT=[</emphasis>[{<emphasis>s</emphasis>|<emphasis
|
|
role="bold">d</emphasis>}:]<emphasis>rate</emphasis><emphasis
|
|
role="bold">/</emphasis>{<emphasis
|
|
role="bold">sec</emphasis>|<emphasis
|
|
role="bold">min</emphasis>|<emphasis
|
|
role="bold">hour</emphasis>|<emphasis
|
|
role="bold">day</emphasis>}[:<emphasis>burst</emphasis>]]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.12. Limits the logging rate, either
|
|
overall, or by source or destination IP address.</para>
|
|
|
|
<para>If the value starts with 's:' then logging is limited per
|
|
source IP. If the value starts with 'd:', then logging is limited
|
|
per destination IP. Otherwise, the overall logging rate is
|
|
limited.</para>
|
|
|
|
<para>If <replaceable>burst</replaceable> is not specified, then a
|
|
value of 5 is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGBURST=</emphasis>[<emphasis>burst</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Deprecated in Shorewall 4.4.12.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGRATE=</emphasis>[<emphasis>rate</emphasis>/{<emphasis
|
|
role="bold">minute</emphasis>|<emphasis
|
|
role="bold">second</emphasis>}]</term>
|
|
|
|
<listitem>
|
|
<para>As of Shorewall 4.4.12, these parameters are
|
|
Deprecated.</para>
|
|
|
|
<para>These parameters set the match rate and initial burst size for
|
|
logged packets. Please see ip6tables(8) for a description of the
|
|
behavior of these parameters (the ip6tables option --limit is set by
|
|
LOGRATE and --limit-burst is set by LOGBURST). If both parameters
|
|
are set empty, no rate-limiting will occur. If you supply one of
|
|
these, then you should also supply the other.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting> LOGRATE=10/minute
|
|
LOGBURST=5</programlisting>
|
|
|
|
<para>For each logging rule, the first time the rule is reached, the
|
|
packet will be logged; in fact, since the burst is 5, the first five
|
|
packets will be logged. After this, it will be 6 seconds (1 minute
|
|
divided by the rate of 10) before a message will be logged from the
|
|
rule, regardless of how many packets reach it. Also, every 6
|
|
seconds, one of the bursts will be regained; if no packets hit the
|
|
rule for 30 seconds, the burst will be fully recharged; back where
|
|
we started.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOGTAGONLY=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Using the default LOGFORMAT, chain names may not exceed 11
|
|
characters or truncation of the log prefix may occur. Longer chain
|
|
names may be used with log tags if you set LOGTAGONLY=Yes. With
|
|
LOGTAGONLY=Yes, if a log tag is specified then the tag is included
|
|
in the log prefix in place of the chain name.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MACLIST_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">ACCEPT</emphasis>|<emphasis
|
|
role="bold">DROP</emphasis>|<emphasis
|
|
role="bold">REJECT</emphasis>|A_DROP|A_REJECT]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the disposition of connections requests that fail
|
|
MAC Verification and must have the value ACCEPT (accept the
|
|
connection request anyway), REJECT (reject the connection request)
|
|
or DROP (ignore the connection request). If not set or if set to the
|
|
empty value (e.g., MACLIST_DISPOSITION="") then
|
|
MACLIST_DISPOSITION=REJECT is assumed.</para>
|
|
|
|
<para>A_DROP and A_REJECT are audited versions of DROP and REJECT
|
|
respectively and were added in Shorewall 4.4.20. They require
|
|
AUDIT_TARGET in the kernel and ip6tables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MACLIST_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the syslog level for logging connection requests
|
|
that fail MAC Verification. The value must be a valid syslogd log
|
|
level. If you don't want to log these connection requests, set to
|
|
the empty value (e.g., MACLIST_LOG_LEVEL="").</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MACLIST_TABLE=</emphasis>[<emphasis
|
|
role="bold">filter</emphasis>|<emphasis
|
|
role="bold">mangle</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Normally, MAC verification occurs in the filter table (INPUT
|
|
and FORWARD) chains. When forwarding a packet from an interface with
|
|
MAC verification to a bridge interface, that doesn't work.</para>
|
|
|
|
<para>This problem can be worked around by setting
|
|
MACLIST_TABLE=mangle which will cause Mac verification to occur out
|
|
of the PREROUTING chain. Because REJECT isn't available in that
|
|
environment, you may not specify MACLIST_DISPOSITION=REJECT with
|
|
MACLIST_TABLE=mangle.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MACLIST_TTL=[</emphasis><emphasis>number</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The performance of configurations with a large numbers of
|
|
entries in <ulink
|
|
url="shorewall-maclist.html">shorewall-maclist</ulink>(5) can be
|
|
improved by setting the MACLIST_TTL variable in <ulink
|
|
url="shorewall.conf.html">shorewall.conf</ulink>(5).</para>
|
|
|
|
<para>If your iptables and kernel support the "Recent Match" (see
|
|
the output of "shorewall check" near the top), you can cache the
|
|
results of a 'maclist' file lookup and thus reduce the overhead
|
|
associated with MAC Verification.</para>
|
|
|
|
<para>When a new connection arrives from a 'maclist' interface, the
|
|
packet passes through then list of entries for that interface in
|
|
<ulink url="shorewall-maclist.html">shorewall-maclist</ulink>(5). If
|
|
there is a match then the source IP address is added to the 'Recent'
|
|
set for that interface. Subsequent connection attempts from that IP
|
|
address occurring within $MACLIST_TTL seconds will be accepted
|
|
without having to scan all of the entries. After $MACLIST_TTL from
|
|
the first accepted connection request from an IP address, the next
|
|
connection request from that IP address will be checked against the
|
|
entire list.</para>
|
|
|
|
<para>If MACLIST_TTL is not specified or is specified as empty (e.g,
|
|
MACLIST_TTL="" or is specified as zero then 'maclist' lookups will
|
|
not be cached).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MANGLE_ENABLED=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines whether Shorewall will generate rules in the
|
|
Netfilter mangle table. Setting MANGLE_ENABLED=No disables all
|
|
Shorewall features that require the mangle table. The default is
|
|
MANGLE_ENABLED=Yes.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MARK_IN_FORWARD_CHAIN=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If your kernel has a FORWARD chain in the mangle table, you
|
|
may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in
|
|
the tcrules file to occur in that chain rather than in the
|
|
PREROUTING chain. This permits you to mark inbound traffic based on
|
|
its destination address when DNAT is in use. To determine if your
|
|
kernel has a FORWARD chain in the mangle table, use the <emphasis
|
|
role="bold">/sbin/shorewall6 show mangle</emphasis> command; if a
|
|
FORWARD chain is displayed then your kernel will support this
|
|
option. If this option is not specified or if it is given the empty
|
|
value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No
|
|
is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry id="MASK_BITS">
|
|
<term><emphasis
|
|
role="bold">MASK_BITS</emphasis>=[<replaceable>number</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.26. Number of bits on the right of the
|
|
32-bit packet mark to be masked when clearing the traffic shaping
|
|
mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if
|
|
PROVIDER_OFFSET > 0). Default value and the default values of the
|
|
other mark layout options is determined as follows:</para>
|
|
|
|
<table frame="none">
|
|
<title>Default Packet Mark Layout</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry>WIDE_TC_MARKS=No, HIGH_ROUTE_MARKS=No</entry>
|
|
|
|
<entry>TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=0,
|
|
MASK_BITS=8</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>WIDE_TC_MARKS=No, HIGH_ROUTE_MARKS=Yes</entry>
|
|
|
|
<entry>TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=8,
|
|
MASK_BITS=8</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>WIDE_TC_MARKS=Yes, HIGH_ROUTE_MARKS=No</entry>
|
|
|
|
<entry>TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=0,
|
|
MASK_BITS=16</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>WIDE_TC_MARKS=Yes, HIGH_ROUTE_MARKS=Yes</entry>
|
|
|
|
<entry>TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=16,
|
|
MASK_BITS=16</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MODULE_SUFFIX=</emphasis>[<emphasis
|
|
role="bold">"</emphasis><emphasis>extension</emphasis> ...<emphasis
|
|
role="bold">"</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this option determines the possible file
|
|
extensions of kernel modules. The default value is "ko ko.gz o o.gz
|
|
gz".</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MODULESDIR=</emphasis>[<emphasis>pathname</emphasis>[<emphasis
|
|
role="bold">:</emphasis><emphasis>pathname</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter specifies the directory/directories where your
|
|
kernel netfilter modules may be found. If you leave the variable
|
|
empty, Shorewall6 will supply "/lib/modules/`uname
|
|
-r`/kernel/net/ipv4/netfilter:/lib/modules/`uname
|
|
-r`/kernel/net/ipv4/netfilter".</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MUTEX_TIMEOUT=</emphasis>[<emphasis>seconds</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this variable determines the number of seconds
|
|
that programs will wait for exclusive access to the Shorewall6 lock
|
|
file. After the number of seconds corresponding to the value of this
|
|
variable, programs will assume that the last program to hold the
|
|
lock died without releasing the lock.</para>
|
|
|
|
<para>If not set or set to the empty value, a value of 60 (60
|
|
seconds) is assumed.</para>
|
|
|
|
<para>An appropriate value for this parameter would be twice the
|
|
length of time that it takes your firewall system to process a
|
|
<emphasis role="bold">shorewall6 restart</emphasis> command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">OPTIMIZE=</emphasis>[<replaceable>value</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>The specified <replaceable>value</replaceable> enables certain
|
|
optimizations. Each optimization category is associated with a power
|
|
of two. To enable multiple optimization categories, simply add their
|
|
corresponding numbers together.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Optimization category 1 - Traditionally, Shorewall has
|
|
created rules for <ulink
|
|
url="../ScalabilityAndPerformance.html">the complete matrix of
|
|
host groups defined by the zones, interfaces and hosts
|
|
files</ulink>. Any traffic that didn't correspond to an element
|
|
of that matrix was rejected in one of the built-in chains. When
|
|
the matrix is sparse, this results in lots of largely useless
|
|
rules.</para>
|
|
|
|
<para>These extra rules can be eliminated by setting the 1 bit
|
|
in OPTIMIZE.</para>
|
|
|
|
<para>The 1 bit setting also controls the suppression of
|
|
redundant wildcard rules (those specifying "all" in the SOURCE
|
|
or DEST column). A wildcard rule is considered to be redundant
|
|
when it has the same ACTION and Log Level as the applicable
|
|
policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Optimization category 2 - Added in Shorewall 4.4.7. When
|
|
set, 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.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Optimization category 4 - Added in Shorewall 4.4.7. When
|
|
set, causes short chains (those with less than 2 rules) to be
|
|
optimized away. The following chains are excluded from
|
|
optimization:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>accounting chains (unless
|
|
OPTIMIZE_ACCOUNTING=Yes)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>action chains (user-defined)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>'blacklst' chain</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>dynamic</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Additionally:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>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.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Chains with no references are deleted.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Accounting chains are subject to optimization if the
|
|
OPTIMIZE_ACCOUNTING option is set to 'Yes'.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Optimization category 8 - Added in Shorewall 4.4.9. When
|
|
set, causes chains with identical rules to be collapsed into a
|
|
single chain.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Optimization category 16 - Added in Shorewall 4.4.26. When
|
|
set, causes sequences of <firstterm>compatible</firstterm> rules
|
|
to be combined into a single rule. Rules are considered
|
|
compatible if they differ only in their destination ports and
|
|
comments.</para>
|
|
|
|
<para>A sequence of combatible rules is often generated when
|
|
macros are invoked in sequence.</para>
|
|
|
|
<para>The ability to combine adjacent rules is limited by two
|
|
factors:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Destination port lists may only be combined up to a
|
|
maximum of 15 ports, where a port-pair counts as two
|
|
ports.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Rules may only be combined until the length of their
|
|
concatinated comment reaches 255 characters.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>When either of these limits would be exceeded, the current
|
|
combined rule is emitted and the compiler attemts to combine
|
|
rules beginning with the one that would have exceeded the limit.
|
|
Adjacent combined comments are separated by ', '. Empty comments
|
|
at the front of a group of combined comments are replaced by
|
|
'Others and'. Empty comments at the end of a group of combined
|
|
comments are replaced by 'and others'.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Example 1:</term>
|
|
|
|
<listitem>
|
|
<para>Rules with comments "FOO", <empty> and "BAR"
|
|
would result in the combined comment "FOO and others,
|
|
BAR".</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Example 2:</term>
|
|
|
|
<listitem>
|
|
<para>Rules with comments <empty>, "FOO" and "BAR"
|
|
would reult in the combined comment "Others and FOO, BAR".
|
|
Note: Optimize level 16 requires "Extended Multi-port
|
|
Match" in your iptables and kernel.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The default value is zero which disables all
|
|
optimizations.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">OPTIMIZE_ACCOUNTING=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
|
|
changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not
|
|
specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is
|
|
assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">PATH=</emphasis><emphasis>pathname</emphasis>[<emphasis
|
|
role="bold">:</emphasis><emphasis>pathname</emphasis>]...</term>
|
|
|
|
<listitem>
|
|
<para>Determines the order in which Shorewall6 searches directories
|
|
for executable files.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">PERL=</emphasis><emphasis>pathname</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.11 RC1. Specifies the path name of the
|
|
Perl executable. Default is <filename>/usr/bin/perl</filename>. If
|
|
the pathname specified by this option does not exist or the named
|
|
file is not executable, then Shorewall6 falls back to
|
|
<filename>/usr/bin/perl/</filename></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">PROVIDER_BITS</emphasis>=[<replaceable>number</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.26. The number of bits in the 32-bit
|
|
packet mark to be used for provider numbers. May be zero. See <link
|
|
linkend="MASK_BITS">MASK_BITS</link> above for default value.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">PROVIDER_OFFSET</emphasis>=[<replaceable>number</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.26. The offset from the right
|
|
(low-order end) of the provider number field in the 32-bit packet
|
|
mark. If non-zero, must be >= TC_BITS (Shorewall automatically
|
|
adjusts PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS +
|
|
ZONE_BITS must be < 32. See <link
|
|
linkend="MASK_BITS">MASK_BITS</link> above for default value.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RCP_COMMAND="</emphasis><replaceable>command</replaceable><emphasis
|
|
role="bold">"</emphasis></term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RSH_COMMAND="</emphasis><replaceable>command</replaceable><emphasis
|
|
role="bold">"</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Eariler generations of Shorewall6 Lite required that remote
|
|
root login via ssh be enabled in order to use the
|
|
<command>load</command> and <command>reload</command> commands.
|
|
Beginning with release 3.9.5, you may define an alternative means
|
|
for accessing the remote firewall system. In that release, two new
|
|
options were added to shorewall6.conf:<simplelist>
|
|
<member>RSH_COMMAND</member>
|
|
|
|
<member>RCP_COMMAND</member>
|
|
</simplelist>The default values for these are as
|
|
follows:<simplelist>
|
|
<member>RSH_COMMAND: ssh ${root}@${system} ${command}</member>
|
|
|
|
<member>RCP_COMMAND: scp ${files}
|
|
${root}@${system}:${destination}</member>
|
|
</simplelist>Shell variables that will be set when the commands
|
|
are envoked are as follows:<simplelist>
|
|
<member><replaceable>root</replaceable> - root user. Normally
|
|
<option>root</option> but may be overridden using the '-r'
|
|
option.</member>
|
|
|
|
<member><replaceable>system</replaceable> - The name/IP address
|
|
of the remote firewall system.</member>
|
|
|
|
<member><replaceable>command</replaceable> - For RSH_COMMAND,
|
|
the command to be executed on the firewall system.</member>
|
|
|
|
<member><replaceable>files</replaceable> - For RCP_COMMAND, a
|
|
space-separated list of files to be copied to the remote
|
|
firewall system.</member>
|
|
|
|
<member><replaceable>destination</replaceable> - The directory
|
|
on the remote system that the files are to be copied
|
|
into.</member>
|
|
</simplelist></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT]</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.27. Shorewall has traditionally
|
|
ACCEPTed RELATED packets that don't match any rule in the RELATED
|
|
section of <ulink
|
|
url="manpages6/shorewall6-rules.html">shorewall6-rules</ulink> (5).
|
|
Concern about the safety of this practice resulted in the addition
|
|
of this option. When a packet in RELATED state fails to match any
|
|
rule in the RELATED section, the packet is disposed of based on this
|
|
setting. The default value is ACCEPT for compatibility with earlier
|
|
versions.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RELATED_LOG_LEVEL=</emphasis><emphasis>log-level</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.27. Packets in the related state that
|
|
do not match any rule in the RELATED section of <ulink
|
|
url="manpages/shorewall-rules.html">shorewall6-rules</ulink> (5) are
|
|
logged at this level. The default value is empty which means no
|
|
logging is performed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">REQUIRE_INTERFACE=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.10. The default is No. If set to Yes,
|
|
at least one optional interface must be up in order for the firewall
|
|
to be in the started state. Intended to be used with the <ulink
|
|
url="../Manpages/shorewall-init.html">Shorewall Init
|
|
Package</ulink>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RESTOREFILE=</emphasis><emphasis>filename</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Specifies the simple name of a file in /var/lib/shorewall6 to
|
|
be used as the default restore script in the <emphasis
|
|
role="bold">shorewall6 save</emphasis>, <emphasis
|
|
role="bold">shorewall6 restore</emphasis>, <emphasis
|
|
role="bold">shorewall6 forget </emphasis>and <emphasis
|
|
role="bold">shorewall6 -f start</emphasis> commands.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SHOREWALL_SHELL=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This option is used to specify the shell program to be used to
|
|
interpret the compiled script. If not specified or specified as a
|
|
null value, /bin/sh is assumed. Using a light-weight shell such as
|
|
ash or dash can significantly improve performance.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SMURF_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">DROP</emphasis>|A_DROP]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.20. The default setting is DROP which
|
|
causes smurf packets (see the nosmurfs option in <ulink
|
|
url="shorewall-interfaces.html">shorewall-interfaces</ulink>(5)) to
|
|
be dropped. A_DROP causes the packets to be audited prior to being
|
|
dropped and requires AUDIT_TARGET support in the kernel and
|
|
ip6tables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SMURF_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Specifies the logging level for smurf packets (see the
|
|
nosmurfs option in <ulink
|
|
url="shorewall6-interfaces.html">shorewall6-interfaces</ulink>(5)).
|
|
If set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not
|
|
logged.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SFILTER_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">DROP</emphasis>|<emphasis
|
|
role="bold">REJECT</emphasis>|A_DROP|A_REJECT]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.20. Determines the disposition of
|
|
packets matching the <option>filter</option> option (see <ulink
|
|
url="shorewall6-interfaces.html">shorewall6-interfaces</ulink>(5))
|
|
and of <firstterm>hairpin</firstterm> packets on interfaces without
|
|
the <option>routeback</option> option.<footnote>
|
|
<para>Hairpin packets are packets that are routed out of the
|
|
same interface that they arrived on.</para>
|
|
</footnote> interfaces without the routeback option.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SFILTER_LOG_LEVEL=</emphasis><emphasis>log-level</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added on Shorewall 4.4.20. Determines the logging of packets
|
|
matching the <option>filter</option> option (see <ulink
|
|
url="shorewall6-interfaces.html">shorewall6-interfaces</ulink>(5))
|
|
and of <firstterm>hairpin</firstterm> packets on interfaces without
|
|
the <option>routeback</option> option.<footnote>
|
|
<para>Hairpin packets are packets that are routed out of the
|
|
same interface that they arrived on.</para>
|
|
</footnote> interfaces without the routeback option. The default
|
|
is <option>info</option>. If you don't wish for these packets to be
|
|
logged, use SFILTER_LOG_LEVEL=none.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">STARTUP_ENABLED=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Determines if Shorewall6 is allowed to start. As released from
|
|
shorewall.net, this option is set to <emphasis
|
|
role="bold">No</emphasis>. When set to <emphasis
|
|
role="bold">Yes</emphasis> or <emphasis role="bold">yes</emphasis>,
|
|
Shorewall6 may be started. Used as a guard against Shorewall6 being
|
|
accidentally started before it has been configured.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">STARTUP_LOG=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If specified, determines where Shorewall6 will log the details
|
|
of each <emphasis role="bold">start</emphasis>, <emphasis
|
|
role="bold">restart</emphasis> and <emphasis
|
|
role="bold">refresh</emphasis> command. Logging verbosity is
|
|
determined by the setting of LOG_VERBOSITY above.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SUBSYSLOCK=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter should be set to the name of a file that the
|
|
firewall should create if it starts successfully and remove when it
|
|
stops. Creating and removing this file allows Shorewall6 to work
|
|
with your distribution's initscripts. For RedHat, this should be set
|
|
to /var/lock/subsys/shorewall6. For Debian, the value is
|
|
/var/lock/shorewall6 and in LEAF it is /var/run/shorwall.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TC</emphasis>=[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If specified, gives the pathname of the 'tc' executable. If
|
|
not specified, 'tc' is assumed and the utility will be located using
|
|
the current PATH setting.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TC_BITS</emphasis>=[<replaceable>number</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.26. The number of bits at the low end
|
|
of the 32-bit packet mark to be used for traffic shaping marking.
|
|
May be zero. See <link linkend="MASK_BITS">MASK_BITS</link> above
|
|
for default value.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TC_ENABLED=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|<emphasis
|
|
role="bold">Internal|Shared</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If you say <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis> here, Shorewall6 will use a script that
|
|
you supply to configure traffic shaping. The script must be named
|
|
'tcstart' and must be placed in a directory on your
|
|
CONFIG_PATH.</para>
|
|
|
|
<para>If you say <emphasis role="bold">No</emphasis> or <emphasis
|
|
role="bold">no</emphasis> then traffic shaping is not
|
|
enabled.</para>
|
|
|
|
<para>If you set TC_ENABLED=Internal or internal or leave the option
|
|
empty then Shorewall6 will use its builtin traffic shaper
|
|
(tc4shorewall6 written by Arne Bernin.</para>
|
|
|
|
<para>Beginning with Shorewall 4.4.15, if you set TC_ENABLED=Shared
|
|
or shared, then you should create symbolic links from your
|
|
Shorewall6 configuration directory (normally
|
|
<filename>/etc/shorewall6/</filename>) to your Shorewall
|
|
<filename>tcdevices</filename> and <filename>tcclasses</filename>
|
|
files. This allows the compiler to have access to your Shorewall
|
|
traffic shaping configuration so that it can validate CLASSIFY rules
|
|
in <ulink url="shorewall-tcrules.html">shorewall6-tcrules</ulink>
|
|
(5).</para>
|
|
|
|
<warning>
|
|
<para>If you also run Shorewall and if you have
|
|
TC_ENABLED=Internal in your <ulink
|
|
url="../manpages/shorewall.conf.html">shorewall-conf</ulink>(5),
|
|
then you will want TC_ENABLED=No or TC_ENABLED=Shared in this
|
|
file.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TC_EXPERT=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally, Shorewall6 tries to protect users from themselves by
|
|
preventing PREROUTING and OUTPUT tcrules from being applied to
|
|
packets that have been marked by the 'track' option in <ulink
|
|
url="shorewall6-providers.html">shorewall6-providers</ulink>(5).</para>
|
|
|
|
<para>If you know what you are doing, you can set TC_EXPERT=Yes and
|
|
Shorewall6 will not include these cautionary checks.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TC_PRIOMAP</emphasis>=<emphasis>map</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.6. Determines the mapping of a packet's
|
|
TOS field to priority bands. See <ulink
|
|
url="shorewall6-tcpri.html">shorewall6-tcpri</ulink>(5). The
|
|
<emphasis>map</emphasis> consists of 16 space-separated digits with
|
|
values 1, 2 or 3. A value of 1 corresponds to Linux priority 0, 2 to
|
|
Linux priority 1, and 3 to Linux Priority 2. The first entry gives
|
|
the priority of TOS value 0, the second of TOS value 1, and so on.
|
|
See tc-prio(8) for additional information.</para>
|
|
|
|
<para>The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2
|
|
2 2".</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TCP_FLAGS_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">ACCEPT</emphasis>|<emphasis
|
|
role="bold">DROP</emphasis>|<emphasis
|
|
role="bold">REJECT</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the disposition of TCP packets that fail the checks
|
|
enabled by the <emphasis role="bold">tcpflags</emphasis> interface
|
|
option (see <ulink
|
|
url="shorewall6-interfaces.html">shorewall6-interfaces</ulink>(5))
|
|
and must have a value of ACCEPT (accept the packet), REJECT (send an
|
|
RST response) or DROP (ignore the packet). If not set or if set to
|
|
the empty value (e.g., TCP_FLAGS_DISPOSITION="") then
|
|
TCP_FLAGS_DISPOSITION=DROP is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TCP_FLAGS_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the syslog level for logging packets that fail the
|
|
checks enabled by the tcpflags interface option. The value must be a
|
|
valid syslogd log level. If you don't want to log these packets, set
|
|
to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TRACK_PROVIDERS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.3. When set to Yes, causes the
|
|
<option>track</option> option to be assumed on all providers defined
|
|
in <ulink
|
|
url="shorewall6-providers.html">shorewall6-providers</ulink>(5). May
|
|
be overridden on an individual provider through use of the
|
|
<option>notrack</option> option. The default value is 'No'.</para>
|
|
|
|
<para>Beginning in Shorewall 4.4.6, setting this option to 'Yes'
|
|
also simplifies PREROUTING rules in <ulink
|
|
url="shorewall6-tcrules.html">shorewall6-tcrules</ulink>(5).
|
|
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. The <ulink
|
|
url="shorewall6-rtrules.html">shorewall6-rtrules</ulink>(5)
|
|
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. Beginning
|
|
with Shorewall 4.4.6, 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.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">USE_DEFAULT_RT=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall6 4.4.25. When set to 'Yes', this option
|
|
causes the Shorewall6 multi-ISP feature to create a different set of
|
|
routing rules which are resilient to changes in the main routing
|
|
table. Such changes can occur for a number of reasons, VPNs going up
|
|
and down being an example. The idea is to send packets through the
|
|
main table prior to applying any of the Shorewall6-generated routing
|
|
rules. So changes to the main table will affect the routing of
|
|
packets by default.</para>
|
|
|
|
<para>When USE_DEFAULT_RT=Yes:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Both the DUPLICATE and the COPY columns in <ulink
|
|
url="shorewall6-providers.html">shorewall6-providers</ulink>(5)
|
|
file must remain empty (or contain "-").</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The default route is added to the the 'default' table
|
|
rather than to the main table.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">balance</emphasis> is assumed unless
|
|
<emphasis role="bold">loose</emphasis> is specified.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Packets are sent through the main routing table by a rule
|
|
with priority 999. In <ulink
|
|
url="shorewall6-routing_rules.html">shorewall6-routing_rules</ulink>(5),
|
|
the range 1-998 may be used for inserting rules that bypass the
|
|
main table.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>All provider gateways must be specified explicitly in the
|
|
GATEWAY column. <emphasis role="bold">detect</emphasis> may not
|
|
be specified.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You should disable all default route management outside of
|
|
Shorewall6. If a default route is added to the main table while
|
|
Shorewall is started, then all policy routing will stop working
|
|
(except for those routing rules in the priority range
|
|
1-998).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If USE_DEFAULT_RT is not set or if it is set to the empty
|
|
string then USE_DEFAULT_RT=No is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">USE_PHYSICAL_NAMES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.27. Normally, when Shorewall creates a
|
|
Netfilter chain that relates to an interface, it uses the
|
|
interfaces's logical name as the base of the chain name. For
|
|
example, if the logical name for an interface is OAKLAND, then the
|
|
input chain for traffic arriving on that interface would be
|
|
'OAKLAND_in'. If this option is set to Yes, then the physical name
|
|
of the interface will be used the base of the chain name.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">VERBOSITY=</emphasis>[<emphasis>number</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Shorewall6 has traditionally been very noisy (produced lots of
|
|
output). You may set the default level of verbosity using the
|
|
VERBOSITY OPTION.</para>
|
|
|
|
<para>Values are:</para>
|
|
|
|
<simplelist>
|
|
<member>0 - Silent. You may make it more verbose using the -v
|
|
option</member>
|
|
|
|
<member>1 - Major progress messages displayed</member>
|
|
|
|
<member>2 - All progress messages displayed (pre Shorewall6-3.2.0
|
|
behavior)</member>
|
|
</simplelist>
|
|
|
|
<para>If not specified, then 2 is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">WIDE_TC_MARKS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Deprecated in Shorewall 4.4.26 in favor of TC_BITS and
|
|
MASK_BITS.</para>
|
|
|
|
<para>When set to No (the default), traffic shaping marks are 8
|
|
bytes wide (possible values are 1-255). When WIDE_TC_MARKS=Yes,
|
|
traffic shaping marks are 14 bytes wide (values 1-16383). The
|
|
setting of WIDE_TC_MARKS also has an effect on the HIGH_ROUTE_MARKS
|
|
option (see above).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">ZONE_BITS</emphasis>=[<replaceable>number</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.26. When non-zero, enables automatic
|
|
packet marking by source zone and determines the number of bits in
|
|
the 32-bit packet mark to be used for the zone mark. Default value
|
|
is 0.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">ZONE2ZONE</emphasis>={<option>2</option>|<option>-</option>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.4. This option determines how Shorewall
|
|
constructs chain names involving zone names and/or 'all'. The
|
|
default is '2' (e.g., fw2net).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>FILES</title>
|
|
|
|
<para>/etc/shorewall6/shorewall6.conf</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See ALSO</title>
|
|
|
|
<para>shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
|
|
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
|
|
shorewall6-ipsec(5), shorewall6-maclist(5), shorewall6-masq(5),
|
|
shorewall6-nat(5), shorewall6-netmap(5),
|
|
shoewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
|
|
shorewall6-providers(5), shorewall6-proxyarp(5),
|
|
shorewall6-rtrules(5), shorewall6-routestopped(5),
|
|
shorewall6-rules(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
|
|
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
|
|
shorewall6-zones(5)</para>
|
|
</refsect1>
|
|
</refentry>
|