mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-11 08:51:13 +01:00
3306 lines
140 KiB
XML
3306 lines
140 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>shorewall.conf</refentrytitle>
|
|
|
|
<manvolnum>5</manvolnum>
|
|
|
|
<refmiscinfo>Configuration Files</refmiscinfo>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>shorewall.conf</refname>
|
|
|
|
<refpurpose>Shorewall global configuration file</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>/etc/shorewall/shorewall.conf</command>
|
|
</cmdsynopsis>
|
|
|
|
<cmdsynopsis>
|
|
<command>/etc/shorewall6/shorewall6.conf</command>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>The IPv4 and IPv6 environments each have their own configuration.
|
|
The IPv4 configuration resides in /etc/shorewall/ while the IPv6
|
|
configuration resides in /etc/shorewall6/.</para>
|
|
|
|
<para>The .conf files set options that apply to Shorewall and Shorewall6
|
|
as a whole.</para>
|
|
|
|
<para>The .conf files consist of Shell comments (lines beginning with
|
|
'#'), blank lines and assignment statements
|
|
(<emphasis>variable</emphasis>=<emphasis>value</emphasis>). If the
|
|
<emphasis>value</emphasis> contains shell meta characters or white-space,
|
|
then it must be enclosed in quotes. Example:
|
|
MACLIST_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 Shorewall 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 Shorewall logging, a level of 6 (info) is appropriate.
|
|
Shorewall log messages are generated by NetFilter and are logged using
|
|
facility 'kern' and the level that you specify. 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 ULOG (IPv4 only) and/or NFLOG
|
|
target support, you may also specify a log level of ULOG and/or NFLOG
|
|
(must be all caps). Rather than log its messages to syslogd, Shorewall
|
|
will direct netfilter to log the messages via the ULOG or 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).</para>
|
|
|
|
<note>
|
|
<para>If you want to specify parameters to ULOG or NFLOG (e.g.,
|
|
NFLOG(1,0,1)), then you must quote the setting.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting>LOG_LEVEL="NFLOG(1,0,1)"</programlisting>
|
|
</note>
|
|
|
|
<para>Beginning with Shorewall 5.0.0, the log level may be followed by a
|
|
colon (":") and a <firstterm>log tag</firstterm>. The log tag normally
|
|
follows the packet disposition in Shorewall-generated Netfilter log
|
|
messages, separated from the disposition by a colon (e.g, "DROP:mytag").
|
|
See LOGTAGONLY below for additional information.</para>
|
|
|
|
<para>Beginning with Shorewall 4.4.22, LOGMARK is also a valid level which
|
|
logs the packet's mark value along with the other usual information. The
|
|
syntax is:</para>
|
|
|
|
<simplelist>
|
|
<member><emphasis
|
|
role="bold">LOGMARK[</emphasis><replaceable>(priority)</replaceable><emphasis
|
|
role="bold">]</emphasis></member>
|
|
</simplelist>
|
|
|
|
<para>where <replaceable>priority</replaceable> is one of the levels
|
|
listed in the list above. If omitted, the default is info (6).</para>
|
|
|
|
<para>The following options may be set in shorewall.conf.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">ACCEPT_DEFAULT=</emphasis>{<emphasis>action</emphasis>[(<replaceable>parameters</replaceable>)][:<replaceable>level</replaceable>][,...]|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">BLACKLIST_DEFAULT=</emphasis>{<emphasis>action</emphasis>[(<replaceable>parameters</replaceable>)][:<replaceable>level</replaceable>][,...]|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">DROP_DEFAULT=</emphasis>{<emphasis>action</emphasis>[(<replaceable>parameters</replaceable>)][:<replaceable>level</replaceable>][,...]|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">NFQUEUE_DEFAULT=</emphasis>{<emphasis>action</emphasis>[(<replaceable>parameters</replaceable>)][:<replaceable>level</replaceable>][,...]|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">QUEUE_DEFAULT=</emphasis>{<emphasis>action</emphasis>[(<replaceable>parameters</replaceable>)][:<replaceable>level</replaceable>][,...]|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">REJECT_DEFAULT=</emphasis>{<emphasis>action</emphasis>[(<replaceable>parameters</replaceable>)][:<replaceable>level</replaceable>][,...]|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>In earlier Shorewall versions, a "<firstterm>default
|
|
action</firstterm>" for DROP and REJECT policies was specified in
|
|
the file /usr/share/shorewall/actions.std.</para>
|
|
|
|
<para>In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT,
|
|
ACCEPT_DEFAULT, QUEUE_DEFAULT and NFQUEUE_DEFAULT options were
|
|
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>. The
|
|
name may optionally be followed by a comma-separated list of
|
|
parameters enclosed in parentheses if the specified action accepts
|
|
parameters (e.g., 'Drop(audit)').</member>
|
|
|
|
<member>c) <emphasis role="bold">None</emphasis> or <emphasis
|
|
role="bold">none</emphasis></member>
|
|
</simplelist>
|
|
|
|
<para>Prior to Shorewall 5.1.2, the default values are:</para>
|
|
|
|
<simplelist>
|
|
<member>DROP_DEFAULT="Drop"</member>
|
|
|
|
<member>REJECT_DEFAULT="Reject"</member>
|
|
|
|
<member>BLACKLIST_DEFAULT="Drop" (added in Shorewall
|
|
5.1.1)</member>
|
|
|
|
<member>ACCEPT_DEFAULT="none"</member>
|
|
|
|
<member>QUEUE_DEFAULT="none"</member>
|
|
|
|
<member>NFQUEUE_DEFAULT="none"</member>
|
|
</simplelist>
|
|
|
|
<para>Beginning with Shorewall 5.1.2, the default value is 'none'
|
|
for all of these. Note that the sample configuration files do,
|
|
however, provide settings for DROP_DEFAULT, BLACKLIST_DEFAULT and
|
|
REJECT_DEFAULT.</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="/manpages/shorewall-policy.html">shorewall-policy</ulink>(5).</para>
|
|
|
|
<para>You can pass <replaceable>parameters</replaceable> to the
|
|
specified action (e.g.,
|
|
<emphasis>myaction(audit,DROP)</emphasis>).</para>
|
|
|
|
<para>Beginning with Shorewall 4.5.10, the action name can be
|
|
followed optionally by a colon and a log
|
|
<replaceable>level</replaceable>. The level will be applied to each
|
|
rule in the action or body that does not already have a log
|
|
level.</para>
|
|
|
|
<para>Beginning with Shorewall 5.1.2, multiple
|
|
<replaceable>action</replaceable>[(<replaceable>parameters</replaceable>)][:<replaceable>level</replaceable>]
|
|
specifications may be listed, separated by commas.</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, Shorewall accounting
|
|
is enabled (see <ulink
|
|
url="/manpages/shorewall-accounting.html">shorewall-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="/manpages/shorewall-accounting.html">shorewall-accounting</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ADD_IP_ALIASES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines whether Shorewall automatically adds
|
|
the external address(es) in <ulink
|
|
url="/manpages/shorewall-nat.html">shorewall-nat</ulink>(5), and is
|
|
only available in IPv4 configurations. If the variable is set to
|
|
<emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis> then Shorewall automatically adds these
|
|
aliases. If it is set to <emphasis role="bold">No</emphasis> or
|
|
<emphasis role="bold">no</emphasis>, you must add these aliases
|
|
yourself using your distribution's network configuration
|
|
tools.</para>
|
|
|
|
<para>If this variable is not set or is given an empty value
|
|
(ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.</para>
|
|
|
|
<warning>
|
|
<para>Addresses added by ADD_IP_ALIASES=Yes are deleted and
|
|
re-added during <emphasis role="bold">shorewall reload</emphasis>
|
|
and <emphasis role="bold">shorewall restart</emphasis>. As a
|
|
consequence, connections using those addresses may be
|
|
severed.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ADD_SNAT_ALIASES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines whether Shorewall automatically adds
|
|
the SNAT ADDRESS in <ulink
|
|
url="/manpages/shorewall-masq.html">shorewall-masq</ulink>(5), and
|
|
is only available in IPv4 configurations. If the variable is set to
|
|
<emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis> then Shorewall automatically adds these
|
|
addresses. If it is set to <emphasis role="bold">No</emphasis> or
|
|
<emphasis role="bold">no</emphasis>, you must add these addresses
|
|
yourself using your distribution's network configuration
|
|
tools.</para>
|
|
|
|
<para>If this variable is not set or is given an empty value
|
|
(ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.</para>
|
|
|
|
<warning>
|
|
<para>Addresses added by ADD_SNAT_ALIASES=Yes are deleted and
|
|
re-added during <emphasis role="bold">shorewall reload</emphasis>
|
|
and <emphasis role="bold">shorewall restart</emphasis>. As a
|
|
consequence, connections using those addresses may be
|
|
severed.</para>
|
|
</warning>
|
|
</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 Shorewall's stopped state.
|
|
The behavior differs depending on whether <ulink
|
|
url="/manpages/shorewall-routestopped.html">shorewall-routestopped</ulink>(5)
|
|
or <ulink
|
|
url="/manpages/shorewall-stoppedrules.html">shorewall-stoppedrules</ulink>(5)
|
|
is used:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>routestopped</term>
|
|
|
|
<listitem>
|
|
<para>When ADMINISABSENTMINDED=No, only traffic to/from those
|
|
addresses listed in <filename>routestopped</filename> is
|
|
accepted when Shorewall is stopped. When
|
|
ADMINISABSENTMINDED=Yes, in addition to traffic to/from
|
|
addresses in <filename>routestopped</filename>, connections
|
|
that were active when Shorewall stopped continue to work and
|
|
all new connections from the firewall system itself are
|
|
allowed.</para>
|
|
|
|
<para>Note that the routestopped file is not supported in
|
|
Shorewall 5.0 and later versions.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>stoppedrules</term>
|
|
|
|
<listitem>
|
|
<para>All existing connections continue to work. To sever all
|
|
existing connections when the firewall is stopped, install the
|
|
conntrack utility and place the command <command>conntrack
|
|
-F</command> in the stopped user exit
|
|
(<filename>/etc/shorewall/stopped</filename>).</para>
|
|
|
|
<para>If ADMINISABSENTMINDED=No, only new connections matching
|
|
entries in <filename>stoppedrules</filename> are accepted when
|
|
Shorewall is stopped. Response packets and related connections
|
|
are automatically accepted.</para>
|
|
|
|
<para>If ADMINISABSENTMINDED=Yes, in addition to connections
|
|
matching entries in <filename>stoppedrules</filename>, all new
|
|
connections from the firewall system itself are allowed when
|
|
the firewall is stopped. Response packets and related
|
|
connections are automatically accepted.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>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">ARPTABLES=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.12 and available in IPv4 only. This
|
|
parameter names the arptables executable to be used by Shorewall. If
|
|
not specified or if specified as a null value, then the arptables
|
|
executable located using the PATH option is used.</para>
|
|
|
|
<para>Regardless of how the arptables utility is located (specified
|
|
via arptables= or located via PATH), Shorewall uses the
|
|
arptables-restore and arptables-save utilities from that same
|
|
directory.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">AUTOCOMMENT=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Formerly named AUTO_COMMENT. 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>". If not
|
|
specified, the AUTO_COMMENT option has a default value of
|
|
'Yes'.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">AUTOHELPERS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.7. When set to <option>Yes</option>
|
|
(the default), the generated ruleset will automatically associate
|
|
helpers with applications that require them (FTP, IRC, etc.). When
|
|
configuring your firewall on systems running kernel 3.5 or later, it
|
|
is recommended that you:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Set AUTOHELPERS=No.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Modify the HELPERS setting (see below) to list the helpers
|
|
that you need.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Either:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Modify <ulink
|
|
url="/manpages/shorewall-conntrack.html">shorewall-conntrack</ulink>
|
|
(5) to only apply helpers where they are required; or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Specify the appropriate helper in the HELPER column in
|
|
<ulink
|
|
url="/manpages/shorewall-rules.html">shorewall-rules</ulink>
|
|
(5).</para>
|
|
|
|
<note>
|
|
<para>The macros for those applications requiring a helper
|
|
automatically specify the appropriate HELPER where
|
|
required.</para>
|
|
</note>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</orderedlist>
|
|
</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>,
|
|
<emphasis role="bold">reload</emphasis> and
|
|
<command>restart</command> commands are changed; if no files in
|
|
CONFIG_PATH (see below) have been changed since the last successful
|
|
<command>start, reload</command> or <command>restart</command>
|
|
command, then the compilation step is skipped and the compiled
|
|
script that executed the last <command>start</command>, <emphasis
|
|
role="bold">reload</emphasis> or <command>restart</command> command
|
|
is used. If not specified, the default is AUTOMAKE=No.</para>
|
|
|
|
<para>The setting of the AUTOMAKE option is ignored if the
|
|
<command>start</command>, <emphasis role="bold">reload</emphasis> or
|
|
<command>restart</command> command includes a directory name
|
|
(e.g.,<command> shorewall restart
|
|
/etc/shorewall.new</command>).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">BALANCE_PROVIDERS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option
|
|
determines whether the <option>balance</option> provider option (see
|
|
<ulink
|
|
url="/manpages/shorewall-providers.html">shorewall-providers(5)</ulink>)
|
|
is the default. When BALANCE_PROVIDERS=Yes, then the
|
|
<option>balance</option> option is assumed unless the
|
|
<option>fallback</option>, <option>loose</option>,
|
|
<option>load</option> or <option>tproxy</option> option is
|
|
specified. If this option is not set or is set to the empty value,
|
|
then the default value is the value of USE_DEFAULT_RT.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">BASIC_FILTERS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall-4.6.0. When set to <emphasis
|
|
role="bold">Yes</emphasis>, causes entries in <ulink
|
|
url="/manpages/shorewall-tcfilters.html">shorewall-tcfilters(5)</ulink>
|
|
to generate a basic filter rather than a u32 filter. This setting
|
|
requires the <firstterm>Basic Ematch</firstterm> capability in your
|
|
kernel and iptables.</para>
|
|
|
|
<note>
|
|
<para>One of the advantages of basic filters is that ipset matches
|
|
are supported in newer iproute2 and kernel versions. Because
|
|
Shorewall cannot reliably detect this capability, use of basic
|
|
filters is controlled by this option.</para>
|
|
</note>
|
|
|
|
<para>The default value is <emphasis role="bold">No</emphasis> which
|
|
causes u32 filters to be generated.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">BLACKLIST=</emphasis>[{<emphasis
|
|
role="bold">ALL</emphasis>|<emphasis
|
|
role="bold"><replaceable>state</replaceable>[,...]</emphasis>}]</term>
|
|
|
|
<listitem>
|
|
<para>where state is one of NEW, ESTABLISHED, RELATED, INVALID,or
|
|
UNTRACKED.</para>
|
|
|
|
<para>Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY
|
|
option. Specifies the connection tracking states that are to be
|
|
subject to blacklist screening. If BLACKLIST is not specified then
|
|
the states subject to blacklisting are
|
|
NEW,ESTABLISHED,INVALID,UNTRACKED.</para>
|
|
|
|
<para>ALL sends all packets through the blacklist chains.</para>
|
|
|
|
<para>Note: The ESTABLISHED state may not be specified if
|
|
FASTACCEPT=Yes is specified.</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.</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 iptables.</para>
|
|
|
|
<para>The BLACKLIST_DISPOSITION setting has no effect on entries in
|
|
the BLACKLIST section of <ulink
|
|
url="/manpages/shorewall-rules.html">shorewall-rules</ulink> (5). It
|
|
determines the disposition of packets sent to the <emphasis
|
|
role="bold">blacklog</emphasis> target of <ulink
|
|
url="/manpages/shorewall-blrules.html">shorewall-blrules
|
|
</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">BLACKLIST_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]]</term>
|
|
|
|
<listitem>
|
|
<para>Formerly named BLACKLIST_LOGLEVEL. 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_LOG_LEVEL=debug). If you do not assign a
|
|
value or if you assign an empty value then packets from blacklisted
|
|
hosts are not logged. The setting determines the log level of
|
|
packets sent to the <emphasis role="bold">blacklog</emphasis> target
|
|
of <ulink
|
|
url="/manpages/shorewall-blrules.html">shorewall-blrules</ulink>(5).</para>
|
|
</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 Shorewall won't clear the current traffic control rules during
|
|
[<command>re</command>]<command>start</command> or
|
|
<command>reload</command>. This setting is intended for use by
|
|
people who 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/shorewall/tcstart file. That way, your traffic
|
|
shaping rules can still use the “fwmark” classifier based on packet
|
|
marking defined in <ulink
|
|
url="/manpages/shorewall-tcrules.html">shorewall-tcrules</ulink>(5).
|
|
If not specified, CLEAR_TC=Yes is assumed.</para>
|
|
|
|
<warning>
|
|
<para>When you specify TC_ENABLED=shared (see below), then you
|
|
should also specify CLEAR_TC=No.</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 Shorewall 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 Shorewall 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
|
|
shorewall[6].conf may be found. CONFIG_PATH is specifies as a list
|
|
of directory names separated by colons (":"). When looking for a
|
|
configuration file:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If the command is "try" or a "<configuration
|
|
directory>" was specified in the command (e.g.,
|
|
<command>shorewall [-6] 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>
|
|
|
|
<para>If CONFIG_PATH is not given or if it is set to the empty value
|
|
then the contents of /usr/share/shorewall/configpath are used. As
|
|
released from shorewall.net, that file sets the CONFIG_PATH to
|
|
/etc/shorewall:/usr/share/shorewall but your particular distribution
|
|
may set it differently. See the output of shorewall show config for
|
|
the default on your system.</para>
|
|
|
|
<para>Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may
|
|
begin with a colon (":"), to signal that the first
|
|
<replaceable>directory</replaceable> listed will be skipped if the
|
|
user performing a compilation is not root or if the configuration is
|
|
being compiled for export (-e option specified or if running one of
|
|
the remote-* commands) . This prevents the compiler from looking in
|
|
<filename>/etc/shorewall[6]</filename>/ when compilation is being
|
|
done by a non-root user or if the generated script is to be sent to
|
|
a remote firewall system.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DEFER_DNS_RESOLUTION=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.12. When set to 'Yes' (the default),
|
|
DNS names are validated in the compiler and then passed on to the
|
|
generated script where they are resolved by ip[6]tables-restore.
|
|
This is an advantage if you use AUTOMAKE=Yes and the IP address
|
|
associated with the DNS name is subject to change. When
|
|
DEFER_DNS_RESOLUTION=No, DNS names are converted into IP addresses
|
|
by the compiler. This has the advantage that when AUTOMAKE=Yes, the
|
|
<command>start</command>, <emphasis role="bold">reload</emphasis>
|
|
and <command>restart</command> commands will succeed even if no DNS
|
|
server is reachable (assuming that the configuration hasn't changed
|
|
since the compiled script was last generated).</para>
|
|
|
|
<important>
|
|
<para>When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS
|
|
change makes it necessary to recompile an existing firewall
|
|
script, the <option>-c</option> option must be used with the
|
|
<command>reload</command> or <command>restart</command> command to
|
|
force recompilation.</para>
|
|
</important>
|
|
</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/shorewall[6]/rtrules 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">DETECT_DNAT_IPADDRS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>If set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, Shorewall will detect the first IP
|
|
address of the interface to the source zone and will include this
|
|
address in DNAT rules as the original destination IP address. If set
|
|
to <emphasis role="bold">No</emphasis> or <emphasis
|
|
role="bold">no</emphasis>, Shorewall will not detect this address
|
|
and any destination IP address will match the DNAT rule. If not
|
|
specified or empty, “DETECT_DNAT_IPADDRS=Yes” is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DISABLE_IPV6=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>If set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, IPv6 traffic to, from and through the
|
|
firewall system is disabled. If set to <emphasis
|
|
role="bold">No</emphasis> or <emphasis role="bold">no</emphasis>,
|
|
Shorewall will take no action with respect to allowing or
|
|
disallowing IPv6 traffic. If not specified or empty,
|
|
“DISABLE_IPV6=No” is assumed.</para>
|
|
|
|
<para>It is important to note that changing DISABLE_IPV6=Yes to
|
|
DISABLE_IPV6=No does <emphasis>not</emphasis> enable IPV6. The
|
|
recommended approach for enabling IPv6 on your system is:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Install, configure and start <ulink
|
|
url="/IPv6Support.html">Shorewall6</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Change DISABLE_IPV6=Yes to DISABLE_IPV6=No in
|
|
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Reload Shorewall</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DOCKER=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.0.6. When set to <option>Yes</option>,
|
|
the generated script will save Docker-generated rules before and
|
|
restore them after executing the <command>start</command>,
|
|
<command>stop</command>, <command>reload</command> and
|
|
<command>restart</command> commands. If set to <option>No</option>
|
|
(the default), the generated script will delete any Docker-generated
|
|
rules when executing those commands. See<ulink url="/Docker.html">
|
|
http://www.shorewall.net/Docker.html</ulink> for additional
|
|
information.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">DONT_LOAD=</emphasis>[<emphasis>module</emphasis>[,<emphasis>module</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>Causes Shorewall 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>||<emphasis
|
|
role="bold">ipset</emphasis>[<emphasis
|
|
role="bold">-only</emphasis>][<replaceable>,option</replaceable>[,...]][:[<replaceable>setname</replaceable>][:<replaceable>log_level</replaceable>|:l<replaceable>og_tag</replaceable>]]]}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.4.7. When set to <emphasis
|
|
role="bold">No</emphasis> or <emphasis role="bold">no</emphasis>,
|
|
chain-based dynamic blacklisting using <command>shorewall [-6] [-l]
|
|
drop</command>, <command>shorewall [-6] [-l] reject</command>,
|
|
<command>shorewall logdrop</command> and <command>shorewall [-6]
|
|
[-l] logreject</command> is disabled. Default is <emphasis
|
|
role="bold">Yes</emphasis>. Beginning with Shorewall 5.0.8,
|
|
ipset-based dynamic blacklisting using the <command>shorewall
|
|
blacklist</command> command is also supported. The name of the set
|
|
(<replaceable>setname</replaceable>) and the level
|
|
(<replaceable>log_level</replaceable>), if any, at which blacklisted
|
|
traffic is to be logged may also be specified. The default IPv4 set
|
|
name is SW_DBL4 and the default IPv6 set name is SW_DBL6. The
|
|
default log level is <option>none</option> (no logging). If
|
|
<option>ipset-only</option> is given, then chain-based dynamic
|
|
blacklisting is disabled just as if DYNAMIC_BLACKLISTING=No had been
|
|
specified.</para>
|
|
|
|
<para>Possible <replaceable>option</replaceable>s are:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>src-dst</term>
|
|
|
|
<listitem>
|
|
<para>Normally, only packets whose source address matches an
|
|
entry in the ipset are dropped. If <option>src-dst</option> is
|
|
included, then packets whose destination address matches an
|
|
entry in the ipset are also dropped.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>disconnect</option></term>
|
|
|
|
<listitem>
|
|
<para>The <option>disconnect</option> option was added in
|
|
Shorewall 5.0.13 and requires that the conntrack utility be
|
|
installed on the firewall system. When an address is
|
|
blacklisted using the <command>blacklist</command> command,
|
|
all connections originating from that address are
|
|
disconnected. if the <option>src-dst</option> option was also
|
|
specified, then all connections to that address are also
|
|
disconnected.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>timeout</option>=<replaceable>seconds</replaceable></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.0.13. Normally, Shorewall creates
|
|
the dynamic blacklisting ipset with timeout 0 which means that
|
|
entries are permanent. If you want entries in the set that are
|
|
not accessed for a period of time to be deleted from the set,
|
|
you may specify that period using this option. Note that the
|
|
<command>blacklist</command> command can override the ipset's
|
|
timeout setting.</para>
|
|
|
|
<important>
|
|
<para>Once the dynamic blacklisting ipset has been created,
|
|
changing this option setting requires a complete restart of
|
|
the firewall; <command>shorewall [-6] restart</command> if
|
|
RESTART=restart, otherwise <command>shorewall [-6] [-l] stop
|
|
&& shorewall [-6] [-l] start</command></para>
|
|
</important>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>When ipset-based dynamic blacklisting is enabled, the contents
|
|
of the blacklist will be preserved over
|
|
<command>stop</command>/<command>reboot</command>/<command>start</command>
|
|
sequences if SAVE_IPSETS=Yes, SAVE_IPSETS=ipv4 or if
|
|
<replaceable>setname</replaceable> is included in the list of sets
|
|
to be saved in SAVE_IPSETS.</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 thes 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 'net-all'
|
|
('net2all if ZONE2ZONE=2) 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 Shorewall Lite (<command>shorewall [-6]
|
|
remote-start</command>, <command>shorewall [-6] remote-reload,
|
|
shorewall [-6] remote-restart </command>or <command>shorewall [-6]
|
|
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/shorewall[6]</filename>
|
|
but will copy those found in another location on the
|
|
CONFIG_PATH.</para>
|
|
|
|
<para>When compiling for direct use by Shorewall, 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">FASTACCEPT=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally, Shorewall 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
|
|
'loc-net' or 'loc2net' chain, depending on the setting of ZONE2ZONE
|
|
(see below).</para>
|
|
|
|
<para>If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED 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="/manpages/shorewall-rules.html">shorewall-rules</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">FIREWALL</emphasis>=[<emphasis>dnsname-or-ip-address</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This option was added in Shorewall 5.0.13 and may be used on
|
|
an administrative system in directories containing the
|
|
configurations of remote firewalls. The contents of the variable are
|
|
the default value for the <replaceable>system</replaceable>
|
|
parameter to the <command>remote-start</command>,
|
|
<command>remote-reload</command> and
|
|
<command>remote-restart</command> commands.</para>
|
|
</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. 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">GEOIPDIR</emphasis>=[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.4. Specifies the pathname of the
|
|
directory containing the <firstterm>GeoIP Match</firstterm>
|
|
database. See <ulink
|
|
url="/ISO-3661.html">http://www.shorewall.net/ISO-3661.html</ulink>.
|
|
If not specified, the default value is
|
|
<filename>/usr/share/xt_geoip/LE</filename> which is the default
|
|
location of the little-endian database.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">HELPERS</emphasis>=[<emphasis>helper</emphasis>[,<replaceable>helper</replaceable>...]]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.7. This option specifies a
|
|
comma-separated list naming the Netfilter application helpers that
|
|
are to be enabled. If not specified, the default is to enable all
|
|
helpers.</para>
|
|
|
|
<para>Possible values for <replaceable>helper</replaceable>
|
|
are:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">amanda</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">ftp</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">h323</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">irc</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">netbios-ns</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">none</emphasis> - This special value
|
|
was added in Shorewall 4.5.16 and indicates that no helpers are
|
|
to be enabled. It also prevents the compiler for probing for
|
|
helper support; such probing generates messages on the system
|
|
log of the form "xt_CT: No such helper XXX" where XXX is the
|
|
helper name. When used, <emphasis role="bold">none</emphasis>
|
|
must be the only helper specified.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">pptp</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">sane</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">sip</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">snmp</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">tftp</emphasis></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>When HELPERS is specified on a system running Kernel 3.5.0 or
|
|
later, automatic association of helpers to connections is
|
|
disabled.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">IGNOREUNKNOWNVARIABLES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.11. Normally, if an unknown shell
|
|
variable is encountered in a configuration file (except in ?IF and
|
|
?ELSIF directives), the compiler raises a fatal error. If
|
|
IGNOREUNKNOWNVARIABLES is set to <emphasis
|
|
role="bold">Yes</emphasis>, then such variables simply expand to an
|
|
empty string. Default is <emphasis role="bold">No</emphasis>.</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="/manpages/shorewall-zones.html">shorewall-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="/manpages/shorewall-nesting.html">shorewall-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">INLINE_MATCHES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.6.0. Traditionally in <ulink
|
|
url="/manpages/shorewall-rules.html">shorewall-rules</ulink>(5), a
|
|
semicolon separates column-oriented specifications on the left from
|
|
<ulink url="/configuration_file_basics.htm#Pairs">alternative
|
|
specificaitons</ulink> on the right.. When INLINE_MATCHES=Yes is
|
|
specified, the specifications on the right are interpreted as if
|
|
INLINE had been specified in the ACTION column. This also applies to
|
|
<ulink url="/manpages/shorewall-masq.html">shorewall-masq(5)</ulink>
|
|
and <ulink
|
|
url="/manpages/shorewall-mangle.html">shorewall-mangle(5</ulink>)
|
|
which also support INLINE. If not specified or if specified as the
|
|
empty value, the value 'No' is assumed for backward
|
|
compatibility.</para>
|
|
|
|
<para>Beginning with Shorewall 5.0.0, it is no longer necessary to
|
|
set INLINE_MATCHES=Yes in order to be able to specify your own
|
|
iptables text in a rule and INLINE_MATCHES=Yes is deprecated.
|
|
Beginning with 5.0.0, you may simply preface your text with a pair
|
|
of semicolons (";;"). If alternate input is also specified in the
|
|
rule, it should appear before the semicolons and may be separated
|
|
from normal column input by a single semicolon or enclosed in curly
|
|
braces ("{....}").</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.13. Shorewall has traditionally passed
|
|
INVALID packets through the NEW section of <ulink
|
|
url="/manpages/shorewall-rules.html">shorewall-rules</ulink> (5).
|
|
When a packet in INVALID state fails to match any rule in the
|
|
INVALID section, the packet is disposed of based on this setting.
|
|
The default value is CONTINUE for compatibility with earlier
|
|
versions.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">INVALID_LOG_LEVEL=</emphasis><emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.13. Packets in the INVALID state that
|
|
do not match any rule in the INVALID section of <ulink
|
|
url="/manpages/shorewall-rules.html">shorewall-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">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 IPv4 parameter determines whether Shorewall enables or
|
|
disables IPv4 Packet Forwarding
|
|
(<filename>/proc/sys/net/ipv4/ip_forward</filename>). In an IPv6
|
|
configuration, this parameter determines the setting of
|
|
<filename>/proc/sys/net/ipv6/config/all/ip_forwarding</filename>.</para>
|
|
|
|
<para>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>Shorewall will neither enable nor disable packet
|
|
forwarding.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>If this variable is not set or is given an empty value
|
|
(IP_FORWARD="") then IP_FORWARD=On is assumed.</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">IPSET_WARNINGS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.2. Default is Yes. When set, causes the
|
|
rules compiler to issue a warning when:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The compiler is being run by root and an ipset specified
|
|
in the configuration does not exists. Only one warning is issued
|
|
for each missing ipset.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>When [src] is specified in a destination column and when
|
|
[dst] is specified in a source column.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">IPTABLES=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>This parameter names the iptables executable to be used by
|
|
Shorewall. If not specified or if specified as a null value, then
|
|
the iptables executable located using the PATH option is
|
|
used.</para>
|
|
|
|
<para>Regardless of how the iptables utility is located (specified
|
|
via IPTABLES= or located via PATH), Shorewall uses the
|
|
iptables-restore and iptables-save utilities from that same
|
|
directory.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">IP6TABLES=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>IPv6 only.</para>
|
|
|
|
<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">KEEP_RT_TABLES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>IPv4:</para>
|
|
|
|
<blockquote>
|
|
<para>When set to <option>Yes</option>, this option prevents
|
|
generated scripts from altering the /etc/iproute2/rt_tables
|
|
database when there are entries in
|
|
<filename>/etc/shorewall/providers</filename>. If you set this
|
|
option to <option>Yes</option> while Shorewall (Shorewall-lite) is
|
|
running, you should remove the file
|
|
<filename>/var/lib/shorewall/rt_tables</filename>
|
|
(<filename>/var/lib/shorewall-lite/rt_tables</filename>) before
|
|
your next <command>stop</command>, <command>refresh</command>,
|
|
<command>restore</command>, <emphasis
|
|
role="bold">reload</emphasis> or <command>restart</command>
|
|
command.</para>
|
|
</blockquote>
|
|
|
|
<para>IPv6:</para>
|
|
|
|
<blockquote>
|
|
<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>, <emphasis
|
|
role="bold">reload</emphasis> or <command>restart</command>
|
|
command.</para>
|
|
</blockquote>
|
|
|
|
<important>
|
|
<para>When both IPv4 and IPv6 Shorewall configurations are
|
|
present, KEEP_RT_TABLES=No should be specified in only one of the
|
|
two configurations unless the two provider configurations are
|
|
identical with respect to interface and provider names and
|
|
numbers.</para>
|
|
</important>
|
|
|
|
<para>The default is KEEP_RT_TABLES=No.</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
|
|
<filename>/var/lib/shorewall[6]/helpers</filename> 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">LOCKFILE</emphasis>=[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Specifies the name of the Shorewall[6] lock file, used to
|
|
prevent simultaneous state-changing commands. If not specified,
|
|
${VARDIR}/shorewall[6]/lock is assumed (${VARDIR} is normally
|
|
/var/lib but can be changed when Shorewall-core is installed -- see
|
|
the output of <command>shorewall show vardir</command>).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOG_BACKEND=</emphasis>[<emphasis>backend</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.6.4. LOG_BACKEND determines the logging
|
|
backend to be used for the <command>iptrace</command> command (see
|
|
<ulink url="manpages/shorewall.html">shorewall(8)</ulink>).</para>
|
|
|
|
<para><replaceable>backend</replaceable> is one of:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>LOG</term>
|
|
|
|
<listitem>
|
|
<para>Use standard kernel logging.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>ULOG</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>Use ULOG logging to ulogd.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>netlink</term>
|
|
|
|
<listitem>
|
|
<para>Use netlink logging to ulogd version 2 or later.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOG_LEVEL=</emphasis><emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.1.2. Beginning with that release, the
|
|
sample configurations use this as the default log level and changing
|
|
it will change all packet logging done by the configuration. In any
|
|
configuration file (except <ulink
|
|
url="/manpages/shorewall-params.html">shorewall-params(5)</ulink>),
|
|
$LOG_LEVEL will expand to this value.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOG_MARTIANS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|Keep]</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>If set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, sets
|
|
<filename>/proc/sys/net/ipv4/conf/*/log_martians</filename> to 1
|
|
with the exception of
|
|
<filename>/proc/sys/net/ipv4/conf/all/log_martians which is set to
|
|
0</filename>. The default value is <emphasis
|
|
role="bold">Yes</emphasis> which sets both of the above to one. If
|
|
you do not enable martian logging for all interfaces, you may still
|
|
enable it for individual interfaces using the <emphasis
|
|
role="bold">logmartians</emphasis> interface option in <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5).</para>
|
|
|
|
<para>The value <emphasis role="bold">Keep</emphasis> causes
|
|
Shorewall to ignore the option. If the option is set to <emphasis
|
|
role="bold">Yes</emphasis>, then martians are logged on all
|
|
interfaces. If the option is set to <emphasis
|
|
role="bold">No</emphasis>, then martian logging is disabled on all
|
|
interfaces except those specified in <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5).</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 Shorewall 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>
|
|
|
|
<blockquote>
|
|
<para>For example, using the default LOGFORMAT, the log prefix for
|
|
logging from the nat table's PREROUTING chain is as follows in
|
|
versions prior to 5.1.0:</para>
|
|
|
|
<programlisting> Shorewall:nat:PREROUTING
|
|
</programlisting>
|
|
|
|
<para>In Shorewall 5.1.0 and later releases, the log prefix
|
|
is:</para>
|
|
|
|
<programlisting> nat:PREROUTING
|
|
</programlisting>
|
|
|
|
<important>
|
|
<para>To help insure that all packets in the NEW state are
|
|
logged, rate limiting (LOGLIMIT) 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/>
|
|
|
|
<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>|<option>systemd</option>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter tells the /sbin/shorewall program where to look
|
|
for Shorewall 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. For further information, see <ulink
|
|
url="shorewall-logging.html">shorewall-logging(8)</ulink>. Beginning
|
|
with Shorewall 5.0.10.1, you may specify <option>systemd</option> to
|
|
use <command>journelctl -r</command> to read the log.</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 Shorewall 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
|
|
“Shorewall:%s:%s:” is assumed.</para>
|
|
|
|
<note>
|
|
<para>The setting of LOGFORMAT has an effect of the permitted
|
|
length of zone names. See <ulink
|
|
url="/manpages/shorewall-zones.html">shorewall-zones</ulink>
|
|
(5).</para>
|
|
</note>
|
|
|
|
<caution>
|
|
<para>Beginning with Shorewall 5.1.0, the default and sample
|
|
shorewall[6].conf files set LOGFORMAT="%s %s ".</para>
|
|
|
|
<para>Regardless of the LOGFORMAT setting, Shorewall IPv4 log
|
|
messages that use this LOGFORMAT can be uniquely identified using
|
|
the following regular expression:</para>
|
|
|
|
<simplelist>
|
|
<member>'IN=.* OUT=.* SRC=.*\..* DST='</member>
|
|
</simplelist>
|
|
|
|
<para>and Shorewall IPv6 log messages can be uniquely identified
|
|
using the following regular expression:</para>
|
|
|
|
<simplelist>
|
|
<member>'IN=.* OUT=.* SRC=.*:.* DST='</member>
|
|
</simplelist>
|
|
|
|
<para>To match all Netfilter log messages (Both IPv4 and IPv6 and
|
|
regardless of the LOGFORMAT setting), use:</para>
|
|
|
|
<simplelist>
|
|
<member>'IN=.* OUT=.* SRC=.* DST='</member>
|
|
</simplelist>
|
|
</caution>
|
|
</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">second|min</emphasis>|<emphasis
|
|
role="bold">minute|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>
|
|
|
|
<para>The keywords <emphasis role="bold">second</emphasis> and
|
|
<emphasis role="bold">minute</emphasis> are accepted beginning with
|
|
Shorewall 4.6.13.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOGTAGONLY=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Using LOGFORMAT=“Shorewall:%s:%s:”, chain names may not exceed
|
|
5 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>
|
|
|
|
<para>Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have
|
|
more control over the generated log prefix. Beginning with that
|
|
release, the tag is interpreted as a <replaceable>chain
|
|
name</replaceable> and a <replaceable>disposition</replaceable>
|
|
separated by a comma. So this rule:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST
|
|
LOG:info:foo,bar net fw</programlisting>
|
|
|
|
<para>would generate the following log prefix when using
|
|
LOGFORMAT=“Shorewall:%s:%s:”:</para>
|
|
|
|
<simplelist>
|
|
<member>Shorewall:foo:bar:</member>
|
|
</simplelist>
|
|
|
|
<para>Similarly,</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST
|
|
LOG:info:,bar net fw</programlisting>
|
|
|
|
<para>would generate</para>
|
|
|
|
<simplelist>
|
|
<member>Shorewall:net2fw:bar:</member>
|
|
</simplelist>
|
|
</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 ip[6]tables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MACLIST_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]]</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 or
|
|
MACLIST_DISPOSITION=A_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="/manpages/shorewall-maclist.html">shorewall-maclist</ulink>(5)
|
|
can be improved by setting the MACLIST_TTL variable in <ulink
|
|
url="/manpages/shorewall.conf.html">shorewall[6].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="/manpages/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">MAPOLDACTIONS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>This option is included for compatibility with old Shorewall
|
|
configuration. New installs should always have
|
|
MAPOLDACTIONS=No.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MINIUPNPD=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.0.8. If set to Yes, Shorewall will create
|
|
a chain in the nat table named MINIUPNPD-POSTROUTING and will add
|
|
jumps from POSTROUTING to that chain for each interface with the
|
|
<option>upnpd</option> option specified. Default is No.</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">shorewall [-6] 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). Prior to Shorewall 5.0.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>
|
|
|
|
<para>From 5.0.0 onward, the default value of MASK_BITS is 8, the
|
|
default value of PROVIDER_BITS, TC_BITS, MASK_BITS and
|
|
PROVIDER_OFFSET is 8.</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, Shorewall will supply the value
|
|
"/lib/modules/$uname/kernel/net/ipv${g_family}/netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
|
|
where <emphasis role="bold">uname</emphasis> holds the output of
|
|
'<command>uname -r</command>' and <emphasis
|
|
role="bold">g_family</emphasis> holds '4' in IPv4 configurations and
|
|
'6' in IPv6 configurations.</para>
|
|
|
|
<para>The option plus sign ('+') was added in Shorewall 5.0.3 and
|
|
causes the listed pathnames to be appended to the default list
|
|
above.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MULTICAST=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>This option will normally be set to 'No' (the default). It
|
|
should be set to 'Yes' under the following circumstances:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>You have an interface that has parallel zones defined via
|
|
/etc/shorewall/hosts.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You want to forward multicast packets to two or more of
|
|
those parallel zones.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>In such cases, you will configure a <option>destonly</option>
|
|
network on each zone receiving multicasts.</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 Shorewall[6]
|
|
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">shorewall [-6] restart</emphasis>
|
|
command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">NFACCT=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.7. Specifies the pathname of the nfacct
|
|
utility. If not specified, Shorewall will use the PATH setting to
|
|
find the program.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">NULL_ROUTE_RFC1918=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|<emphasis
|
|
role="bold">blackhole</emphasis>|<emphasis
|
|
role="bold">unreachable</emphasis>|<emphasis
|
|
role="bold">prohibit</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>When set to Yes, causes Shorewall to null-route the IPv4
|
|
address ranges reserved by RFC1918. The default value is
|
|
'No'.</para>
|
|
|
|
<para>When combined with route filtering (ROUTE_FILTER=Yes or
|
|
<option>routefilter</option> in <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5)),
|
|
this option ensures that packets with an RFC1918 source address are
|
|
only accepted from interfaces having known routes to networks using
|
|
such addresses.</para>
|
|
|
|
<para>Beginning with Shorewall 4.5.15, you may specify
|
|
<option>blackhole</option>, <option>unreachable</option> or
|
|
<option>prohibit</option> to set the type of route to be created.
|
|
See <ulink
|
|
url="/MultiISP.html#null_routing">http://www.shorewall.net/MultiISP.html#null_routing</ulink>.</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>
|
|
|
|
<para>Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All
|
|
to enable all optimization categories, and you may also specify
|
|
OPTIMIZE=None to disable optimization.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Optimization category 1 - Traditionally, Shorewall has
|
|
created rules for the complete matrix of host groups defined by
|
|
the zones, interfaces and hosts files. 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>
|
|
|
|
<note>
|
|
<para>Optimization level 1 is ignored when optimization level
|
|
4 is also selected, since level 4 performs similar
|
|
optimizations in a more robust way.</para>
|
|
</note>
|
|
</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
|
|
precede 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>
|
|
|
|
<listitem>
|
|
<para>forwardUPnP</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>UPnP (nat table)</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>
|
|
|
|
<para>An additional optimization was added in Shorewall 4.5.4.
|
|
If the last rule in a chain is an unqualified jump to a simple
|
|
target, then all immediately preceding rules with the same
|
|
simple target are omitted.</para>
|
|
|
|
<para>For example, consider this chain:</para>
|
|
|
|
<programlisting> -A fw-net -p udp --dport 67:68 -j ACCEPT
|
|
-A fw-net -p udp --sport 1194 -j ACCEPT
|
|
-A fw-net -p 41 -j ACCEPT
|
|
-A fw-net -j ACCEPT
|
|
</programlisting>
|
|
|
|
<para>Since all of the rules are jumps to the simple target
|
|
ACCEPT, this chain is totally optimized away and jumps to the
|
|
chain are replace with jumps to ACCEPT.</para>
|
|
</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 compatible 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
|
|
concatenated 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 attempts 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>
|
|
|
|
<para>Beginning in Shorewall 4.5.10, this option also suppresses
|
|
duplicate adjacent rules and duplicate non-adjacent rules that
|
|
don't include <emphasis role="bold">mark</emphasis>, <emphasis
|
|
role="bold">connmark</emphasis>, <emphasis
|
|
role="bold">dscp</emphasis>, <emphasis
|
|
role="bold">ecn</emphasis>, <emphasis
|
|
role="bold">set</emphasis>, <emphasis role="bold">tos</emphasis>
|
|
or <emphasis role="bold">u32</emphasis> matches.</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 result 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>In versions prior to 5.1.0, the default value is zero which
|
|
disables all optimizations. Beginning with Shorewall 5.1.0, the
|
|
default value is All which enables 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">PAGER=</emphasis><emphasis>pathname</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.0.6. Specifies a path name of a pager
|
|
program like <command>less</command> or <command>more</command>.
|
|
When PAGER is given, the output of verbose <command>status</command>
|
|
commands and the <command>dump</command> command are piped through
|
|
the named program when the output file is a terminal.</para>
|
|
|
|
<para>Beginning with Shorewall 5.0.12, the default value of this
|
|
option is the DEFAULT_PAGER setting in shorewallrc.</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 Shorewall 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 Shorewall falls back to
|
|
<filename>/usr/bin/perl</filename></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">PERL_HASH_SEED=</emphasis><emphasis
|
|
role="bold"><replaceable>seed</replaceable><emphasis
|
|
role="bold">|random</emphasis></emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.1.4. Sets the Perl hash
|
|
<replaceable>seed</replaceable> (an integer in the range 0-99999)
|
|
when running the Shorewall rules compiler. If not specified, the
|
|
value 0 is assumed. If <option>random</option> is specified, a
|
|
random seed will be chosed by Perl. See perlsec(1) for additional
|
|
information.</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>]If</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/>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RSH_COMMAND="</emphasis><replaceable>command</replaceable><emphasis
|
|
role="bold">"</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Earlier generations of Shorewall 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 shorewall.conf:</para>
|
|
|
|
<simplelist>
|
|
<member>RSH_COMMAND</member>
|
|
|
|
<member>RCP_COMMAND</member>
|
|
</simplelist>
|
|
|
|
<para>The default values for these are as follows:</para>
|
|
|
|
<programlisting>RSH_COMMAND: ssh ${root}@${system} ${command}
|
|
RCP_COMMAND: scp ${files} ${root}@${system}:${destination}</programlisting>
|
|
|
|
<para>Shell variables that will be set when the commands are invoked
|
|
are as follows:</para>
|
|
|
|
<programlisting><replaceable>root</replaceable> - root user. Normally <option>root</option> but may be overridden using the '-r' option.
|
|
<replaceable>system</replaceable> - The name/IP address of the remote firewall system.
|
|
<replaceable>command</replaceable> - For RSH_COMMAND, the command to be executed on the firewall system.
|
|
<replaceable>files</replaceable> - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
|
|
<replaceable>destination</replaceable> - The directory on the remote system that the files are to be copied into.</programlisting>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]</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="/manpages/shorewall-rules.html">shorewall-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>[:<replaceable>log-tag</replaceable>]</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">shorewall-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">REJECT_ACTION=</emphasis><emphasis>action</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.21. When a REJECT target is specified,
|
|
Shorewall normally handles the response as follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If the destination address of the packet is a broadcast or
|
|
multicast address, the packet is dropped.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>if the protocol is ICMP (2) then the packet is
|
|
dropped.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>if the protocol is TCP (6) then the packet is rejected
|
|
with an RST.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>if the protocol is UDP (17) then the packet is rejected
|
|
with an 'port-unreachable' ICMP.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>if the protocol is ICMP (1) then the packet is rejected
|
|
with a 'host-unreachable' ICMP.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>if the protocol is ICMP6 (1) then the packet is rejected
|
|
with a 'icmp6-addr-unreachable' ICMP6.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>otherwise, the packet is rejected with a 'host-prohibited'
|
|
ICMP.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>You can modify this behavior by implementing your own
|
|
<replaceable>action</replaceable> that handles REJECT and specifying
|
|
it's name in this option. The <emphasis role="bold">nolog</emphasis>
|
|
and <emphasis role="bold">noinline</emphasis> options will
|
|
automatically be assumed for the specified
|
|
<replaceable>action</replaceable>.</para>
|
|
|
|
<para>The following action implements the default reject
|
|
action:</para>
|
|
|
|
<programlisting>?format 2
|
|
#TARGET SOURCE DEST PROTO
|
|
Broadcast(DROP) - - -
|
|
DROP - - 2
|
|
INLINE - - 6 ;; -j REJECT --reject-with tcp-reset
|
|
?if __ENHANCED_REJECT
|
|
INLINE - - 17 ;; -j REJECT
|
|
?if __IPV4
|
|
INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable
|
|
INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited
|
|
?else
|
|
INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable
|
|
INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited
|
|
?endif
|
|
?else
|
|
INLINE - - - ;; -j REJECT
|
|
?endif</programlisting>
|
|
</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">RESTART=</emphasis>[<emphasis
|
|
role="bold">restart</emphasis>|<emphasis
|
|
role="bold">reload</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was
|
|
added in Shorewall 5.0.0. In that release, the <emphasis
|
|
role="bold">reload</emphasis> command was redefined to do what
|
|
<emphasis role="bold">restart</emphasis> had done in earlier
|
|
releases and <emphasis role="bold">restart</emphasis> became a true
|
|
restart (equivalent to <emphasis role="bold">stop</emphasis>
|
|
followed by <emphasis role="bold">start</emphasis>). When
|
|
RESTART=reload, the <emphasis role="bold">restart</emphasis> command
|
|
performs the same operation as the <emphasis
|
|
role="bold">reload</emphasis> command making it compatible with
|
|
earlier releases. If not specified, RESTART=reload is
|
|
assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RESTORE_DEFAULT_ROUTE=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This option determines whether to restore the default route
|
|
saved when here are 'balance' providers defined but all of them are
|
|
down.</para>
|
|
|
|
<para>The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
|
|
pre-4.2.6 behavior.</para>
|
|
|
|
<para>RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
|
|
default route in the main table (USE_DEFAULT_RT=No) or in the
|
|
default table (USE_DEFAULT_RT=Yes) when there are no balance
|
|
providers available. In that case, RESTORE_DEFAULT_ROUTE=No will
|
|
cause any default route in the relevant table to be deleted.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">RESTORE_ROUTEMARKS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.9. When set to <emphasis
|
|
role="bold">Yes</emphasis> (the default), provider marks are
|
|
restored unconditionally at the top of the mangle OUTPUT and
|
|
PREROUTING chains, even if the saved mark is zero. When this option
|
|
is set to <emphasis role="bold">No</emphasis>, the mark is restored
|
|
only if it is non-zero. If you have problems with IPSEC ESP packets
|
|
not being routed correctly on output, try setting this option to
|
|
<emphasis role="bold">No</emphasis>.</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/shorewall to
|
|
be used as the default restore script in the <emphasis
|
|
role="bold">shorewall [-6] save</emphasis>, <emphasis
|
|
role="bold">shorewall [-6] restore</emphasis>, <emphasis
|
|
role="bold">shorewall [-6] forget </emphasis>and <emphasis
|
|
role="bold">shorewall [6] -f start</emphasis> commands.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">RETAIN_ALIASES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>IPv4 only.</para>
|
|
|
|
<para>During <emphasis role="bold">shorewall star</emphasis>t, IP
|
|
addresses to be added as a consequence of ADD_IP_ALIASES=Yes and
|
|
ADD_SNAT_ALIASES=Yes are quietly deleted when <ulink
|
|
url="/manpages/shorewall-nat.html">shorewall-nat</ulink>(5) and
|
|
<ulink url="/manpages/shorewall-masq.html">shorewall-masq</ulink>(5)
|
|
are processed then are re-added later. This is done to help ensure
|
|
that the addresses can be added with the specified labels but can
|
|
have the undesirable side effect of causing routes to be quietly
|
|
deleted. When RETAIN_ALIASES is set to Yes, existing addresses will
|
|
not be deleted. Regardless of the setting of RETAIN_ALIASES,
|
|
addresses added during <emphasis role="bold">shorewall
|
|
start</emphasis> are still deleted at a subsequent <emphasis
|
|
role="bold">shorewall [stop</emphasis>, <emphasis
|
|
role="bold">shorewall reload</emphasis> or <emphasis
|
|
role="bold">shorewall restart</emphasis>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ROUTE_FILTER=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|Keep]</term>
|
|
|
|
<listitem>
|
|
<para>If this parameter is given the value <emphasis
|
|
role="bold">Yes</emphasis> or <emphasis role="bold">yes</emphasis>
|
|
then route filtering (anti-spoofing) is enabled on all network
|
|
interfaces which are brought up while Shorewall is in the started
|
|
state. The default value is <emphasis
|
|
role="bold">no</emphasis>.</para>
|
|
|
|
<para>The value <emphasis role="bold">Keep</emphasis> causes
|
|
Shorewall to ignore the option. If the option is set to <emphasis
|
|
role="bold">Yes</emphasis>, then route filtering occurs on all
|
|
interfaces. If the option is set to <emphasis
|
|
role="bold">No</emphasis>, then route filtering is disabled on all
|
|
interfaces except those specified in <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5).</para>
|
|
|
|
<important>
|
|
<para>If you need to disable route filtering on any interface,
|
|
then you must set ROUTE_FILTER=No then set routefilter=1 or
|
|
routefilter=2 on those interfaces where you want route filtering.
|
|
See <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5)
|
|
for additional details.</para>
|
|
</important>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">RPFILTER_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">DROP</emphasis>|<emphasis
|
|
role="bold">REJECT</emphasis>|A_DROP|A_REJECT]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.7. Determines the disposition of
|
|
packets entering from interfaces the <option>rpfilter</option>
|
|
option (see <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5)).
|
|
Packets disposed of by this option are those whose response packets
|
|
would not be sent through the same interface receiving the
|
|
packet.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RPFILTER_LOG_LEVEL=</emphasis><emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in shorewall 4.5.7. Determines the logging of packets
|
|
disposed via the RPFILTER_DISPOSITION. The default value is
|
|
<option>info</option>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SAVE_ARPTABLES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.12. If SAVE_ARPTABLES=Yes, then the
|
|
current arptables contents will be saved by <emphasis
|
|
role="bold">shorewall save</emphasis> command and restored by
|
|
<emphasis role="bold">shorewall restore</emphasis> command. Default
|
|
value is No.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SAVE_IPSETS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No|ipv4|<replaceable>setlist</replaceable></emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the
|
|
current contents of your ipsets will be saved by the <emphasis
|
|
role="bold">shorewall stop</emphasis> and <emphasis
|
|
role="bold">shorewall save</emphasis> commands and restored by the
|
|
<emphasis role="bold">shorewall start</emphasis> and <emphasis
|
|
role="bold">shorewall restore</emphasis> commands.</para>
|
|
|
|
<para>Beginning with Shorewall 4.6.4, you can restrict the set of
|
|
ipsets saved by specifying a setlist (a comma-separated list of ipv4
|
|
ipset names). You may also restrict the saved sets to just the ipv4
|
|
ones by specifying <emphasis role="bold">ipv4</emphasis>.</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>sfilter</option> option (see <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-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></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SFILTER_LOG_LEVEL=</emphasis><emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added on Shorewall 4.4.20. Determines the logging of packets
|
|
matching the <option>sfilter</option> option (see <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-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> 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">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="/manpages/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
|
|
iptables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SMURF_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]]</term>
|
|
|
|
<listitem>
|
|
<para>Specifies the logging level for smurf packets (see the
|
|
nosmurfs option in <ulink
|
|
url="/manpages/shorewall-interfaces.html">shorewall-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">STARTUP_ENABLED=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Determines if Shorewall 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>,
|
|
Shorewall may be started. Used as a guard against Shorewall 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 Shorewall will log the details
|
|
of each <emphasis role="bold">start</emphasis>, <emphasis
|
|
role="bold">reload</emphasis>, <emphasis
|
|
role="bold">restart</emphasis>, <emphasis
|
|
role="bold">refresh</emphasis>, <emphasis
|
|
role="bold">try</emphasis>, and <emphasis
|
|
role="bold">safe-</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 Shorewall to work with
|
|
your distribution's initscripts. For OpenSuSE, this should be set to
|
|
/var/lock/subsys/shorewall (var/lock/subsys/shorewall-lite if
|
|
building for export). For Gentoo, it should be set to
|
|
/run/lock/shorewall (/run/lock/shorewall-lite). For Redhat and
|
|
derivatives as well as Debian and derivatives, the pathname should
|
|
be omitted.</para>
|
|
|
|
<important>
|
|
<para>Beginning with Shorewall 5.1.0, this setting is ignored when
|
|
SERVICEDIR is non-empty in
|
|
<filename>${SHAREDIR}/shorewall/shorewallrc</filename> (usually
|
|
<filename>/usr/share/shorewall/shorewallrc</filename>).</para>
|
|
</important>
|
|
</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>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</emphasis>|<emphasis
|
|
role="bold">Simple</emphasis>|<emphasis
|
|
role="bold">Shared</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If you say <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis> here, Shorewall 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=Simple (Shorewall 4.4.6 and later),
|
|
simple traffic shaping using <ulink
|
|
url="/manpages/shorewall-tcinterfaces.html">shorewall-tcinterfaces</ulink>(5)
|
|
and <ulink
|
|
url="/manpages/shorewall-tcpri.html">shorewall-tcpri</ulink>(5) is
|
|
enabled.</para>
|
|
|
|
<para>If you set TC_ENABLED=Internal or internal or leave the option
|
|
empty then Shorewall will use its builtin traffic shaper
|
|
(tc4shorewall written by Arne Bernin.</para>
|
|
|
|
<para>Beginning with Shorewall 4.4.15, you can set
|
|
TC_ENABLED=Shared. This allows you to configure the tcdevices and
|
|
tcclasses in your Shorewall6 configuration yet make them available
|
|
to the compiler when compiling your Shorewall configuration. In
|
|
addition to setting TC_ENABLED=Shared, you need to create symbolic
|
|
links from your Shorewall configuration directory (normally
|
|
/etc/shorewall/) to the tcdevices and tcclasses files in your
|
|
Shorewall6 configuration directory (normally
|
|
/etc/shorewall6/).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TC_EXPERT=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally, Shorewall 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="/manpages/shorewall-providers.html">shorewall-providers</ulink>(5).</para>
|
|
|
|
<para>If you know what you are doing, you can set TC_EXPERT=Yes and
|
|
Shorewall 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="/manpages/shorewall-tcpri.html">shorewall-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>|A_DROP|A_REJECT]</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="/manpages/shorewall-interfaces.html">shorewall-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>
|
|
|
|
<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 iptables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TCP_FLAGS_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]]</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="/manpages/shorewall-providers.html">shorewall-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="/manpages/shorewall-tcrules.html">shorewall-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 rtrules 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">TRACK_RULES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|File}</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.20. If set to <emphasis
|
|
role="bold">Yes</emphasis>, causes the compiler to add a comment to
|
|
iptables rules to indicate the file name and line number of the
|
|
configuration entry that generated the rule. If set to <emphasis
|
|
role="bold">No</emphasis> (the default), then no such comments are
|
|
added.</para>
|
|
|
|
<para>Setting this option to <emphasis role="bold">Yes</emphasis>
|
|
requires the <firstterm>Comments</firstterm> capability in iptables
|
|
and kernel.</para>
|
|
|
|
<para>Beginning with Shorewall 5.0.5, the option may also be set to
|
|
<emphasis role="bold">File</emphasis>. That setting causes similar
|
|
comments to be added to the
|
|
<filename>.iptables-restore-input</filename> file, which is normally
|
|
created in <filename>/var/lib/shorewall</filename>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.13. Shorewall has traditionally passed
|
|
UNTRACKED packets through the NEW section of <ulink
|
|
url="/manpages/shorewall-rules.html">shorewall-rules</ulink> (5).
|
|
When a packet in UNTRACKED state fails to match any rule in the
|
|
UNTRACKED section, the packet is disposed of based on this setting.
|
|
The default value is CONTINUE for compatibility with earlier
|
|
versions.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">UNTRACKED_LOG_LEVEL=</emphasis><emphasis>log-level</emphasis>[:<replaceable>log-tag</replaceable>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.13. Packets in the UNTRACKED state that
|
|
do not match any rule in the UNTRACKED section of <ulink
|
|
url="/manpages/shorewall-rules.html">shorewall-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">USE_DEFAULT_RT=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>When set to 'Yes', this option causes the Shorewall multi-ISP
|
|
feature to create a 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 Shorewall-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="/manpages/shorewall-providers.html">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>If running Shorewall 5.1.0 or earlier or if
|
|
BALANCE_PROVIDERS=Yes (Shorewall 5.1.1 or later), then the
|
|
<emphasis role="bold">balance</emphasis> provider option is
|
|
assumed unless the <option>fallback</option>,
|
|
<option>loose</option>, <option>load</option> or
|
|
<option>tproxy</option> option is specified.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Packets are sent through the main routing table by a rule
|
|
with priority 999. In <ulink
|
|
url="/manpages/shorewall-rtrules.html">shorewall-rtrules</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.<note>
|
|
<para><emphasis role="bold">detect</emphasis> may be
|
|
specified for interfaces whose configuration is managed by
|
|
dhcpcd. Shorewall will use dhcpcd's database to find the
|
|
interface's gateway.</para>
|
|
</note></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You should disable all default route management outside of
|
|
Shorewall. 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>Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if
|
|
it was set to the empty string then USE_DEFAULT_RT=No was assumed.
|
|
Beginning with Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes
|
|
and use of USE_DEFAULT_RT=No is deprecated.</para>
|
|
|
|
<warning>
|
|
<para>The <command>enable</command>, <command>disable</command>
|
|
and <command>reenable</command> commands do not work correctly
|
|
when USE_DEFAULT_RT=No.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">USE_NFLOG_SIZE=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.1.5. The second parameter to the NFLOG
|
|
target specifies how many bytes of the packet to copy to the log; if
|
|
omitted or if supplied as zero, the entire packet is copied. This
|
|
feature has traditionally been implemented using the --nflog-range
|
|
option to the NFLOG iptables target. Unfortuntely, the --nflog-range
|
|
option never worked (the entire packet was always copied). To deal
|
|
with this issue, the Netfilter team:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Added a warning message when --nflog-range is used</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Added --nflog-size which works like --nflog-range was
|
|
intended to work.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new
|
|
--nflog-size feature. If that feature is not available in the
|
|
running kernel and ip[6]tables, an error is raised.</para>
|
|
|
|
<para>When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is
|
|
assumed. When USE_NFLOG_SIZE is added by shorewall update, it is
|
|
added with setting No.</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
|
|
interface'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">USE_RT_NAMES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will
|
|
use routing table (provider) names in the generated script rather
|
|
than table numbers. When set to 'No' (the default), routing table
|
|
numbers will be used.</para>
|
|
|
|
<caution>
|
|
<para>If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you
|
|
must insure that all of your providers have entries in
|
|
/etc/iproute2/rt_tables as well as the following entries:</para>
|
|
|
|
<simplelist>
|
|
<member>255 local</member>
|
|
|
|
<member>254 main</member>
|
|
|
|
<member>253 default</member>
|
|
|
|
<member>250 balance</member>
|
|
|
|
<member>0 unspec</member>
|
|
</simplelist>
|
|
|
|
<para>Without these entries, the firewall will fail to
|
|
start.</para>
|
|
</caution>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">VERBOSE_MESSAGES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.0.9. When Yes (the default), messages
|
|
produced by the ?INFO and ?WARNING directives include the filename
|
|
and linenumber of the directive. When set to No, that additional
|
|
information is omitted. The setting may be overridden on a directive
|
|
by directive basis by following ?INFO or ?WARNING with '!' (no
|
|
intervening white space).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">VERBOSITY=</emphasis>[<emphasis>number</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Shorewall 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 Shorewall-3.2.0
|
|
behavior)</member>
|
|
</simplelist>
|
|
|
|
<para>If not specified, then 2 is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">WARNOLDCAPVERSION=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.5.12. When set to <emphasis
|
|
role="bold">Yes</emphasis> (the default), the compiler issues a
|
|
warning when it finds a capabilities file that doesn't specify all
|
|
of the capabilities supported by the compiler. When
|
|
WARNOLDCAPVERSION is set to <emphasis role="bold">No</emphasis>, no
|
|
warning is issued.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">WORKAROUNDS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 4.6.11. Over time, there have been a number
|
|
of changes in Shorewall that work around defects in other products
|
|
such as iptables and ipset. When WORKAROUNDS=Yes, these workarounds
|
|
are enabled; when WORKAROUNDS=No, they are disabled. If not
|
|
specified or if specified as empty, WORKAROUNDS=Yes is
|
|
assumed.</para>
|
|
|
|
<warning>
|
|
<para>Do not set WORKAROUNDS=Yes if you need to be able to use
|
|
Shorewall-generated scripts (such as created by the
|
|
<command>save</command> command) built by Shorewall 4.4.7 or
|
|
older.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ZERO_MARKS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Added in Shorewall 5.0.12, this is a workaround for an issue
|
|
where packet marks are not zeroed by the kernel. It should be set to
|
|
No (the default) unless you find that incoming packets are being
|
|
mis-routed for no apparent reasons.</para>
|
|
|
|
<caution>
|
|
<para>Do not set this option to Yes if you have IPSEC software
|
|
running on the firewall system.</para>
|
|
</caution>
|
|
</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'. Beginning
|
|
with Shorewall 4.6.0, the default is '-' (e.g., fw-net); prior to
|
|
that release, the default was '2' (e.g., fw2net).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>FILES</title>
|
|
|
|
<para>/etc/shorewall/shorewall.conf</para>
|
|
|
|
<para>/etc/shorewall6/shorewall6.conf</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See ALSO</title>
|
|
|
|
<para>shorewall(8)</para>
|
|
</refsect1>
|
|
</refentry>
|